Hacker News Reader

Comment by stevecat | Hacker News Reader

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?

View on HN

- 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.

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?

third party ticketing machines typically don't have an internet connection hence why offline validation is needed

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.

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.

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.

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.

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.

That doesn't work because ticket checks are far too rate to develop a statistical model for any one user.

You have no way of knowing that they generate tickets only when checked.

I have nearly no information about this scheme because the post got removed.

It has to be partially online, how do you pay without an online connection? Is there some kind of amount you have and then you can redeem them offline?

At one point you do require an online check in, that's for sure, that's when you find out whether the tickets were bought only when checked or not.

This is only a problem if you want gate-less tickets, i.e. get on a bus/train without scanning at a reader or network comms, which seems an overly strict requirement.

Gateless ticket control is a must if you want to do a fast all-doors boarding in a bus.

Buses and trams typically don't have gates, but a common solution is to have the check-in device right inside the doors.

That is only suitable for FDB.

And no comms between client device and internet endpoint for several minutes? Is so, you can say 'network down, manual scan required'. If client can get network, it buys a ticket online.

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?

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.

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.

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.

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)

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.

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).

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.

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.

Thanks - I had a different model of EMV in my head, this was very useful!

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?

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.

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.

Really interesting, thanks

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.)

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.

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

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.

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.

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.

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.

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.

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

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

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.

Reply on news.ycombinator.com