Un-unsealable Oyster

Yesterday I’ve found myself in a bit of a nasty situation. There were severe delays almost every morning this week on the Tube line I use to get to work, so I used alternative route for several time (the office is between two stations of different lines).

I’ve never checked my Oyster card’s balance for I got used to my routine journeys to be covered by the Travelcard on it – and that turned out to be my silly mistake, because that alternative station while situated in a walking distance from the usual one still was in a farther zone. So every time I used that route, my PAYG balance decreased and finally became negative when I finished another morning journey.

I was ill-fated enough to realize that only when I tried to enter the station later in the evening. That’s how I learned that the Oyster card can’t be validated with a negative balance, even with an active and valid Travelcard on it. It’s actually no more than a trifle but not when you forget your money and bank card at home at the same day.

Geez! That was not a pleasant experience at all.

Of course I tried to access TfL website from my phone to top-up online, but in vain – the payment made online becomes active only the next day after the purchase, so I had to wait for Masha to arrive and help me out.

After that incident I got curious of how the Oyster infrastructure is organized. I wasn’t yet successful in understanding why the one-day delay is required for online transactions (perhaps this is not technically conditioned and has other explanations) but nevertheless there were two interesting facts discovered: firstly, Oyster is a value-storing card, not just an read-only ID tag (as in NYCT and other similar implementations) and secondly, all the travel records collected by readers are sent to the central warehouse at the end of the day, not simply as an opportunity arises (or in even real-time for stationary Tube readers).

There were some attempts before to hack Oyster system (surprisingly poorly described), but all of them were based on cloning cards, not on writing new values on them. Of course, after transactions committed at the end of the day two identical cards were easily spotted – and using only one in time didn’t make much sense. I don’t really understand why the new value can’t be written. My current idea is that the one-way encrypting is probably used like in PGP – say, the card is holding the “open key” only while the “closed key” is hold in the warehouse and used by readers. But that’s unlikely - as it was said, there is no permanent connection between readers and the warehouse. You can still buy a new Oyster and use it on a bus without any connection at all (which is obvious due to the bloody jumpy mobile internet in London). Maybe data of every card ever issued (even not yet sold) is loaded into every reader?

Don’t know that yet, but I am more than sure that the same system is used in a number of retail and other systems and is explained on the net. Have to read more about RFID technologies this weekend, stuff seems to be interesting. And the most important, check the wallet when leaving home next time!

Update: Oh, that's really simple! Shame on me.

One-day delay is required for online payment because all the communications with the warehouse happen at the end of the day - so the readers (in this case writers, actually) will be aware of your transaction made on central server the next day only.

That's why you need to specify a station to collect your purchase - apparently, the data is sent to that station only, authorizing its readers to top your card up, and that's still strange - why don't broadcast the data across all the stations?

Another strange thing is that when you make a purchase on the station, you can see my updated balance online immediately - so at least this type of communication is not limited to happen only in certain hours. But if you use online service, you have to wait. What's the principal difference?