6 ms·

I've used these apps before in the UK, and it is great being able to generate a ticket offline, but it appears they've achieved that by including the private ke

I've used these apps before in the UK, and it is great being able to generate a ticket offline, but it appears they've achieved that by including the private keys in the app. Oh dear. Would there be any fool proof alternative to allow for offline ticket creation in a mobile app when that app can be reverse engineered?

matthewmacleod 7y ago
I don’t understand how offline ticket creation could work in any scenario, full-stop. Surely you need to have a data connection in order to purchase the ticket in the first place, right?
- southerndrift 7y ago
  While still online, let people download a bunch of signed tokens from a server in exchange for their public key, which is linked to their phone number and thus identity and credit card. Now when offline, they can create their tickets by linking a token to a fare and sign that with their private key. At check-in, collect those tickets and when online again, charge the credit card.
  - bschne 7y ago
    Off the top of my head, if the backend holds either the payment details or an alias to them from a payment service provider, you could also implement a solution where the turnstile/conductor is connected to a network and the payment gets done on the backend once a ticket generated offline gets scanned/used
  - matthewmacleod 7y ago
    Ah, so essentially require the inclusion of a pre-signed, server-generated token identifying the user in the ticket’s QR code and perform the actual charge when the ticket is used. That’s much better, though it’s subject to some edge cases similar to the London Underground, caused by the potential for using invalid payment methods. Not bad though; probably low-enough potential for abuse to ignore.
- mjlee 7y ago
  You could carry a balance on the app that gets reconciled when you're online. Alternatively, Apply Pay works offline for NFC transactions - I've not tried doing an in-app purchase offline but that might work too.
  - matthewmacleod 7y ago
    Oh, sure - I mean you could carry a balance, but that would be inherently insecure (clearly not something they are particularly fussed about). Apple Pay is a little different in that the terminal is online - I was under the impression all contactless terminals perform auth in real-time, but I may be mistaken.
    - jstanley 7y ago
      It wouldn't necessarily be insecure - the bus could reject an offline-generated ticket at the time the user tries to get on the bus if the user's account is unable to pay for it.
      - matthewmacleod 7y ago
        Sure, if the scanners are online that makes a great deal of sense (though you would have to perform that transaction in real-time, which would be slow)
    - mjlee 7y ago
      I've used Apple Pay completely offline - on trains, buses and planes for example. The terminals in London Underground stations might be constantly online, but I doubt very much there's a 100% guarantee for London Buses.
      - Nextgrid 7y ago
        Buses are online. I’ve seen them authenticate a new card in real-time (they charge £0.10 on a card they haven’t seen recently to check if it’s cancelled).
      - 7y ago
- DanBC 7y ago
  A bus ticket just says you've paid some money to get on a bus. It's not a booked seat or anything else like it. Also, historically bus tickets do not exist to keep passengers honest. They exist to keep the drivers honest. A valid ticket tells the bus company that the driver isn't taking passenger money but not declaring that money to the bus company.
esotericn 7y ago
Off the top of my head. Issue an asym key to a user upon them registering their official bank details. Backend holds one side of it (not sure whether to call this the pub or priv). User uses the asym key to sign a message and shows that message to the inspector (in reality, QR code or similar). If the user cheats you go after the account holder behind the key for reconciliation. edit: Doesn't work as you need to enforce buying even if unchecked.
- Freak_NL 7y ago
  You can't detect cheating if the user is using a custom client in this scenerio. At most, the software client used by the inspector could mark your ticket with the backend as 'checked', which would mean that any checked ticket that doesn't get reported as actually purchased at some point could indicate fraud. A sophisticated custom client could just actually purchase any ticket that gets checked though. It would still net you a rather significant discount depending on the coverage of ticket inspections. What does work is providing a way to check-in and out of transport via gates or poles not under the control of the traveller with a token like the Oyster card.
  - esotericn 7y ago
    Ah, I see the issue. It's the timestamping problem. You have no way of detecting whether a user "bought a ticket" on seeing the inspector or not.
    - lixtra 7y ago
      You can do statistical analysis if certain users get checked unusually often (I.e. generate tickets only when checked). After some time you can force those users into online only mode.
      - lonelappde 7y ago
        That doesn't work because ticket checks are far too rate to develop a statistical model for any one user.
aptwebapps 7y ago
By offline do we just mean the passenger's device? If the POS is online, then what might work would be to hash the ticket's details (user id, journey, time) with a per customer secret. Embed that in the QR code and it's basically a claim that, yes, this passenger would like to be billed for this ticket. The POS would then check the passenger's account balance or for a previously authorized credit card or whatever.
erpellan 7y ago
- Phone generates public/private key pair. - Phone registers public key with backend during signup. - Phone generates ticket signed with private key. - Backend checks signed ticket against registered public key to charge customer. Fraud is still possible but limited to individual customer accounts.
- em-bee 7y ago
  can we expand this? - phone displays the generated ticket to the ticket scanner in the bus. - the scanner connects to the backend to verify the ticket. this way the phone can remain offline after registration, and only need to get online to send money for your account. i see no way for possible fraud as in fact all the ticket is doing in that case is to verify your identity to the server. now how can we do the same thing but without revealing your identity, but just verifying that you paid?
  - scruffyfox 7y ago
    third party ticketing machines typically don't have an internet connection hence why offline validation is needed
sharperguy 7y ago
You'd have to generate "tickets" that actually just link to your account so you can be charged for them by the transport company when you scan them on entry to the vehicle. The vehicle ticket scanner would log all tickets and make sure they were charged.
zxcvbn4038 7y ago
I can’t think of an infallible means of issuing a ticket completely offline, that usually gets into security by obscurity and eventually someone will be motivated to break that. I think the signed ticket scheme would have been better used for redeeming already issued tickets or tickets to identity verified previously. Issuing a ticket with pre-signed identity token is essentially a good faith transaction - it is not guaranteed to be valid end to end - but you can compare against a blacklist of identities at redemption time to limit the impact of someone abusing the system. The commuter rail lines in New York want to charge a premium for issuing a ticket onboard so they have this whole scheme where you have to activate an e-ticket before you leave the station and then it’s only good for an hour, and 90% of the time they don’t validate it - just see that a QR code is on your phone - the other ten percent of the time they want you to swipe or do something to prove it’s not just a screen shot. It can lead to a lot of drama in areas where the cell service is weak or none, or accidentally closed the app, and people don’t have cash on them. I think signing the tickets could solve a lot of the drama. If the conductor has internet connectivity he can validate and redeem tickets in real time, if not then the conductor can validate in real time, make sure no one else on the train has a duplicate ticket, and redeem in bulk when they get into cell range again.
estel 7y ago
I think that a design constraint on these apps is that the ticket _reader_ also is expected to work offline.
bluesign 7y ago
Problem is reuse of existing ticket. I guess Ticket has 2 parts, some token (which you buy when you are online) and some time part (for validity), app signs this token, when you are using with some private key. So basically, as you can sign many times same token with different time value, there is no solution for offline generate and offline use scenario.
c22 7y ago
You could fund public transit with public taxes and make boarding "free" for everyone.
- redpola 7y ago
  They could adopt a different model like in Prague where a ticket is time-based and ticket inspectors roam and fine people. The tickets cover buses, trams, metro, funicular, ferries and you can buy a yearly ticket for about £150. The UK makes travelling by public transport as tedious as possible.

matthewmacleod 7y ago

I don’t understand how offline ticket creation could work in any scenario, full-stop. Surely you need to have a data connection in order to purchase the ticket in the first place, right?

southerndrift 7y ago
While still online, let people download a bunch of signed tokens from a server in exchange for their public key, which is linked to their phone number and thus identity and credit card. Now when offline, they can create their tickets by linking a token to a fare and sign that with their private key. At check-in, collect those tickets and when online again, charge the credit card.
- bschne 7y ago
  Off the top of my head, if the backend holds either the payment details or an alias to them from a payment service provider, you could also implement a solution where the turnstile/conductor is connected to a network and the payment gets done on the backend once a ticket generated offline gets scanned/used
- matthewmacleod 7y ago
  Ah, so essentially require the inclusion of a pre-signed, server-generated token identifying the user in the ticket’s QR code and perform the actual charge when the ticket is used. That’s much better, though it’s subject to some edge cases similar to the London Underground, caused by the potential for using invalid payment methods. Not bad though; probably low-enough potential for abuse to ignore.
mjlee 7y ago
You could carry a balance on the app that gets reconciled when you're online. Alternatively, Apply Pay works offline for NFC transactions - I've not tried doing an in-app purchase offline but that might work too.
- matthewmacleod 7y ago
  Oh, sure - I mean you could carry a balance, but that would be inherently insecure (clearly not something they are particularly fussed about). Apple Pay is a little different in that the terminal is online - I was under the impression all contactless terminals perform auth in real-time, but I may be mistaken.
  - jstanley 7y ago
    It wouldn't necessarily be insecure - the bus could reject an offline-generated ticket at the time the user tries to get on the bus if the user's account is unable to pay for it.
    - matthewmacleod 7y ago
      Sure, if the scanners are online that makes a great deal of sense (though you would have to perform that transaction in real-time, which would be slow)
  - mjlee 7y ago
    I've used Apple Pay completely offline - on trains, buses and planes for example. The terminals in London Underground stations might be constantly online, but I doubt very much there's a 100% guarantee for London Buses.
    - Nextgrid 7y ago
      Buses are online. I’ve seen them authenticate a new card in real-time (they charge £0.10 on a card they haven’t seen recently to check if it’s cancelled).
    - 7y ago
DanBC 7y ago
A bus ticket just says you've paid some money to get on a bus. It's not a booked seat or anything else like it. Also, historically bus tickets do not exist to keep passengers honest. They exist to keep the drivers honest. A valid ticket tells the bus company that the driver isn't taking passenger money but not declaring that money to the bus company.

esotericn 7y ago

Off the top of my head. Issue an asym key to a user upon them registering their official bank details. Backend holds one side of it (not sure whether to call this the pub or priv). User uses the asym key to sign a message and shows that message to the inspector (in reality, QR code or similar). If the user cheats you go after the account holder behind the key for reconciliation. edit: Doesn't work as you need to enforce buying even if unchecked.

Freak_NL 7y ago
You can't detect cheating if the user is using a custom client in this scenerio. At most, the software client used by the inspector could mark your ticket with the backend as 'checked', which would mean that any checked ticket that doesn't get reported as actually purchased at some point could indicate fraud. A sophisticated custom client could just actually purchase any ticket that gets checked though. It would still net you a rather significant discount depending on the coverage of ticket inspections. What does work is providing a way to check-in and out of transport via gates or poles not under the control of the traveller with a token like the Oyster card.
- esotericn 7y ago
  Ah, I see the issue. It's the timestamping problem. You have no way of detecting whether a user "bought a ticket" on seeing the inspector or not.
  - lixtra 7y ago
    You can do statistical analysis if certain users get checked unusually often (I.e. generate tickets only when checked). After some time you can force those users into online only mode.
    - lonelappde 7y ago
      That doesn't work because ticket checks are far too rate to develop a statistical model for any one user.

aptwebapps 7y ago

By offline do we just mean the passenger's device? If the POS is online, then what might work would be to hash the ticket's details (user id, journey, time) with a per customer secret. Embed that in the QR code and it's basically a claim that, yes, this passenger would like to be billed for this ticket. The POS would then check the passenger's account balance or for a previously authorized credit card or whatever.

erpellan 7y ago

- Phone generates public/private key pair. - Phone registers public key with backend during signup. - Phone generates ticket signed with private key. - Backend checks signed ticket against registered public key to charge customer. Fraud is still possible but limited to individual customer accounts.

em-bee 7y ago
can we expand this? - phone displays the generated ticket to the ticket scanner in the bus. - the scanner connects to the backend to verify the ticket. this way the phone can remain offline after registration, and only need to get online to send money for your account. i see no way for possible fraud as in fact all the ticket is doing in that case is to verify your identity to the server. now how can we do the same thing but without revealing your identity, but just verifying that you paid?
- scruffyfox 7y ago
  third party ticketing machines typically don't have an internet connection hence why offline validation is needed

sharperguy 7y ago

You'd have to generate "tickets" that actually just link to your account so you can be charged for them by the transport company when you scan them on entry to the vehicle. The vehicle ticket scanner would log all tickets and make sure they were charged.

zxcvbn4038 7y ago

I can’t think of an infallible means of issuing a ticket completely offline, that usually gets into security by obscurity and eventually someone will be motivated to break that. I think the signed ticket scheme would have been better used for redeeming already issued tickets or tickets to identity verified previously. Issuing a ticket with pre-signed identity token is essentially a good faith transaction - it is not guaranteed to be valid end to end - but you can compare against a blacklist of identities at redemption time to limit the impact of someone abusing the system. The commuter rail lines in New York want to charge a premium for issuing a ticket onboard so they have this whole scheme where you have to activate an e-ticket before you leave the station and then it’s only good for an hour, and 90% of the time they don’t validate it - just see that a QR code is on your phone - the other ten percent of the time they want you to swipe or do something to prove it’s not just a screen shot. It can lead to a lot of drama in areas where the cell service is weak or none, or accidentally closed the app, and people don’t have cash on them. I think signing the tickets could solve a lot of the drama. If the conductor has internet connectivity he can validate and redeem tickets in real time, if not then the conductor can validate in real time, make sure no one else on the train has a duplicate ticket, and redeem in bulk when they get into cell range again.

estel 7y ago

I think that a design constraint on these apps is that the ticket _reader_ also is expected to work offline.

bluesign 7y ago

Problem is reuse of existing ticket. I guess Ticket has 2 parts, some token (which you buy when you are online) and some time part (for validity), app signs this token, when you are using with some private key. So basically, as you can sign many times same token with different time value, there is no solution for offline generate and offline use scenario.

c22 7y ago

You could fund public transit with public taxes and make boarding "free" for everyone.

redpola 7y ago
They could adopt a different model like in Prague where a ticket is time-based and ticket inspectors roam and fine people. The tickets cover buses, trams, metro, funicular, ferries and you can buy a yearly ticket for about £150. The UK makes travelling by public transport as tedious as possible.