7 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?
- 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.
    - 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).
      - Reason077 7y ago
        London Underground and London Buses are both "semi-online". They don't generally try to immediately validate a transaction with your bank the moment you touch your card. Transactions are batched and applied overnight, after applying any discounts like daily/weekly fare caps, out-of-station interchanges, and the bus "hopper fare". The batching means that transactions can still be accepted if the terminal is offline for some reason. However, there is also a blacklist of card numbers that have outstanding balances against them. If you try to use a card that is declined, it will work the first day but not on subsequent days. If you go on TfL's website and clear the outstanding balance, the card will work again after 30 minutes (or in practice, less) once it is removed from the blacklist.
    - 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)
    - tialaramex 7y ago
      The EMV system (that makes contactless card payment work as well as "chip cards") has the card act as a representative for its owner (the card company, not you, you don't own the card and it tells you that when you get it) and it negotiates with the terminal for each transaction. The card (on behalf of its owner) gets to say e.g. "Hi, I am allowed to authorise $185 more offline before talking to my owner. I am allowed to do PIN transactions also I have a magstripe. What shall we do now?" And a terminal could say "OK, let's do an online $28 transaction, with proof of PIN" or, "I'm good, $5.80 offline and no need for a PIN". All this complexity opens up a bunch of potential problems (and EMV is guilty of not getting in a team of academics to figure out the cryptographic situation before shipping it, so it has had to be repeatedly patched and has a bunch of issues that needn't exist) but it allows Apple Pay to decide that e.g. you can spend up to $50 per time, and so long as you make an online transaction at least once per week and without spending more than $250 offline that's fine. Both the issuer of the card and the terminal's owner get to decide on their appetite for risk. Probably if you sell $500 gold chains from a location with bars on the windows and an airlock entrance you want to do online proof-of-PIN transactions only, even if the card itself says it's happy to spend $500 offline contactless - and if your bank is trying to rehabilitate someone with spending problems (in a country where just exploiting them isn't legal) its card may tell the guy with a street cart that alas you need to go online and do a PIN transaction even for their $6 bagel.
      - matthewmacleod 7y ago
        Thanks - I had a different model of EMV in my head, this was very useful!
  - jmkni 7y ago
    Surely Apple pay works offline because your balance is checked by the card reader before the transaction is approved, in the same way it is when you use a contactless debit card?
    - viraptor 7y ago
      They don't really check your balance on the contactless debit card. They just try to charge you. (This may mean authorising an outline transaction they try to execute later) It either works or not. But basically if it works, it's now between you and the bank.
      - tialaramex 7y ago
        There are two separate transactions for payment cards. Authorization and Settlement. Only Authorization involves all this clever technology like encryption and PINs, only Settlement actually moves any money anywhere. For some debit cards, the situation is that they only allow Authorization to occur online, and it will validate your balance before authorizing the transaction AND it will respond to Settlements which are unauthorised by always reversing them. Most people don't want this, because it's annoying, but it can be an option for people who have (some) money but can't be trusted with debt, for example some problem gamblers. It would never be reasonable to give them a card they can spend more than they have on, because they will spend uncontrollably. The distinction between Authorization and Settlement has a variety of weird consequences. For example: If you lose a card and it has to be blocked by the issuer, transactions you Authorized with that card can still be Settled hours, days or even very occasionally weeks later despite the block. Some merchants who determine their exposure to fraud is very low just don't bother with Authorization at all. They only do Settlement, and it Just Works™ because none of their customers were trying to defraud them or queries the bill. This is a really nice user experience, super low friction. Modern Authorization has anti-replay features, because it's built out of technologies where that was essentially free. So you can't execute any Authorization more than once (but Light Blue Touchpaper has an example incident where bad RNG allowed bad guys to attack this). But Settlement still acts like reel-to-reel tape is exciting new technology so it has no anti-replay, and periodically a batch of Settlements will accidentally be executed twice, taking money from customers and giving it to merchants until enough related complaints happen for somebody to realise the mistake and fix it.
  - jnty 7y ago
    What happens if you uninstall the app before going back online? You'd need to rely on the ticket being scanned at some point to ensure the person was charged, which isn't guaranteed on many transport systems (including the British rail network.)
- 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.
- 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?

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.
  - 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).
    - Reason077 7y ago
      London Underground and London Buses are both "semi-online". They don't generally try to immediately validate a transaction with your bank the moment you touch your card. Transactions are batched and applied overnight, after applying any discounts like daily/weekly fare caps, out-of-station interchanges, and the bus "hopper fare". The batching means that transactions can still be accepted if the terminal is offline for some reason. However, there is also a blacklist of card numbers that have outstanding balances against them. If you try to use a card that is declined, it will work the first day but not on subsequent days. If you go on TfL's website and clear the outstanding balance, the card will work again after 30 minutes (or in practice, less) once it is removed from the blacklist.
  - 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)
  - tialaramex 7y ago
    The EMV system (that makes contactless card payment work as well as "chip cards") has the card act as a representative for its owner (the card company, not you, you don't own the card and it tells you that when you get it) and it negotiates with the terminal for each transaction. The card (on behalf of its owner) gets to say e.g. "Hi, I am allowed to authorise $185 more offline before talking to my owner. I am allowed to do PIN transactions also I have a magstripe. What shall we do now?" And a terminal could say "OK, let's do an online $28 transaction, with proof of PIN" or, "I'm good, $5.80 offline and no need for a PIN". All this complexity opens up a bunch of potential problems (and EMV is guilty of not getting in a team of academics to figure out the cryptographic situation before shipping it, so it has had to be repeatedly patched and has a bunch of issues that needn't exist) but it allows Apple Pay to decide that e.g. you can spend up to $50 per time, and so long as you make an online transaction at least once per week and without spending more than $250 offline that's fine. Both the issuer of the card and the terminal's owner get to decide on their appetite for risk. Probably if you sell $500 gold chains from a location with bars on the windows and an airlock entrance you want to do online proof-of-PIN transactions only, even if the card itself says it's happy to spend $500 offline contactless - and if your bank is trying to rehabilitate someone with spending problems (in a country where just exploiting them isn't legal) its card may tell the guy with a street cart that alas you need to go online and do a PIN transaction even for their $6 bagel.
    - matthewmacleod 7y ago
      Thanks - I had a different model of EMV in my head, this was very useful!
- jmkni 7y ago
  Surely Apple pay works offline because your balance is checked by the card reader before the transaction is approved, in the same way it is when you use a contactless debit card?
  - viraptor 7y ago
    They don't really check your balance on the contactless debit card. They just try to charge you. (This may mean authorising an outline transaction they try to execute later) It either works or not. But basically if it works, it's now between you and the bank.
    - tialaramex 7y ago
      There are two separate transactions for payment cards. Authorization and Settlement. Only Authorization involves all this clever technology like encryption and PINs, only Settlement actually moves any money anywhere. For some debit cards, the situation is that they only allow Authorization to occur online, and it will validate your balance before authorizing the transaction AND it will respond to Settlements which are unauthorised by always reversing them. Most people don't want this, because it's annoying, but it can be an option for people who have (some) money but can't be trusted with debt, for example some problem gamblers. It would never be reasonable to give them a card they can spend more than they have on, because they will spend uncontrollably. The distinction between Authorization and Settlement has a variety of weird consequences. For example: If you lose a card and it has to be blocked by the issuer, transactions you Authorized with that card can still be Settled hours, days or even very occasionally weeks later despite the block. Some merchants who determine their exposure to fraud is very low just don't bother with Authorization at all. They only do Settlement, and it Just Works™ because none of their customers were trying to defraud them or queries the bill. This is a really nice user experience, super low friction. Modern Authorization has anti-replay features, because it's built out of technologies where that was essentially free. So you can't execute any Authorization more than once (but Light Blue Touchpaper has an example incident where bad RNG allowed bad guys to attack this). But Settlement still acts like reel-to-reel tape is exciting new technology so it has no anti-replay, and periodically a batch of Settlements will accidentally be executed twice, taking money from customers and giving it to merchants until enough related complaints happen for somebody to realise the mistake and fix it.
- jnty 7y ago
  What happens if you uninstall the app before going back online? You'd need to rely on the ticket being scanned at some point to ensure the person was charged, which isn't guaranteed on many transport systems (including the British rail network.)
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.
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.