News   Jan 15, 2025
News Roundup for January 15, 2025
 352     0 
News   Jan 15, 2025
Winter Delivery
 537     1 
News   Jan 14, 2025
Kazmir and Curio Condos Top Off Along The Queensway
 683     0 

London's Oyster card cracked

If everyone else wants to adopt tokens, by all means. But, that limits us to either the system we have now or a single flat fare for the entire GTA.
 
The Hong Kong Octopus hasn't been cracked...yet. With half-decent encryption, this could be prevented, especially since we're waiting so long for something off-the-shelf.
 
urbanfan89 said:
The Hong Kong Octopus hasn't been cracked...yet. With half-decent encryption, this could be prevented, especially since we're waiting so long for something off-the-shelf.
Click to expand...

'half-decent'? Crypto isn't really straightforward. It's very easy to overlook a flaw in a cryptography scheme.
 
In the past it was rumoured that you can add money to an Octopus Card by putting it in a microwave for about 15 seconds, which turned out to be false. There were also reports that home-made Octopus add-value machines could be bought at cheap electronics markets in Hong Kong.
 
It's incredibly difficult to make a robust, 'e-money' cryptography scheme. The problems often arise when non-experts (engineers), try their hand at cryptography. That's how we get things like WEP, which can only be described as a catastrophic failure.
 
I'm no engineer or crypto expert or anything like that, so bear that in mind, but it seems silly to me to use any kind of system, with any sort of crypto, which stores actual value on the card. I feel like it only makes sense to have some sort of ID on the card, which is then used to access a specific account via the network in a database somewhere, sort of like a debit card. Of course nothing you do to your debit card can ever put more value on your account, because the card itself doesn't store value. These transit cards should work the same way, I think.
 
BobBob said:
I'm no engineer or crypto expert or anything like that, so bear that in mind, but it seems silly to me to use any kind of system, with any sort of crypto, which stores actual value on the card. I feel like it only makes sense to have some sort of ID on the card, which is then used to access a specific account via the network in a database somewhere, sort of like a debit card. Of course nothing you do to your debit card can ever put more value on your account, because the card itself doesn't store value. These transit cards should work the same way, I think.
Click to expand...

It is appropriate to store the card value on the card PROVIDED it is used as a checksum against a central value as you indicated. The catch, of course, is the infrastructure required to run several thousand queries per second with sub-millisecond response times on a system with thousands of data entry locations across the city is rather difficult -- especially when implemented on roaming entry/exit points like buses.

An ID, if at all predictable or in a small space, isn't of much help either. Changing the ID on your card to feed off a different account than it was originally intended is equally effective. If you had a list of 30 active accounts and changed once a day the actual owners of the account might not even notice.

A large unique sparse keyspace will make the DB lookups longer.


Certainly, it is possible just a touch more expensive to implement. I'm fairly sure that Presto uses a centralized platform.
 
rbt said:
It is appropriate to store the card value on the card PROVIDED it is used as a checksum against a central value as you indicated. The catch, of course, is the infrastructure required to run several thousand queries per second with sub-millisecond response times on a system with thousands of data entry locations across the city is rather difficult -- especially when implemented on roaming entry/exit points like buses.
Click to expand...

I think it could be accomplished with a distributed database, with a each point of entry (a bus, subway station, whatever) having a full version, with ongoing synchronization. Synching shouldn't be an issue, as using one card in multiple locations is impossible without forgery. It basically gives very low latency without relying on balance info on the card.

Of course, this would be fairly costly, I imagine.
 
No system is going to be completely fail-safe. The honor system is only as honorable as its patrons chose to be. I for one, would often dodge-the-fare, or 'ride-black' as they call it in Vienna. That said, the token system also had flaws and it cost millions to have it upgraded.

I would much rather have a card system or honor system, over our present token/ticket/cash-fare system - both of which would greatly increase the speed of transit in this city and assist making the system more efficient.

p5
 
Yeah - let's use tokens - because no one has ever managed to counterfeit those before ...

I'm sure that even with this problem, that will soon be resolved, that TFL will lose less than TTC in forgeries.
 
afransen said:
I think it could be accomplished with a distributed database, with a each point of entry (a bus, subway station, whatever) having a full version, with ongoing synchronization. Synching shouldn't be an issue, as using one card in multiple locations is impossible without forgery. It basically gives very low latency without relying on balance info on the card.

Of course, this would be fairly costly, I imagine.
Click to expand...

I'm fairly certain that is how Paris is setup. It's also how the .ORG DNS environment is configured, though it is a mostly read environment. Many POS systems also work similarly to this.

Writes go to a log which is replayed against a single upstream master.


Oddly enough, at a certain point streaming all transactions to all replicated databases is very difficult. Synching subway station transactions to 1500+ mobile units on buses would be next to impossible. On the order of 1 to 2 million transactions within a 3 hour period and the delay allowed is not all that high. A person could clear at a subway turnstyle and checkout (expecting an account balance) at the first bus stop within a minute or two. This prevents significant batching from taking place.

Bandwidth is significantly lighter for the mobile units if they use on-demand queries. Infrastructure for 1500 mobile units is roughly 70% of the capacity required as more transactions would involve a bus/streetcar than subway -- per 2007 ridership stats.

So, designing subway turnstyles to function the same just makes sense.


All that said, there is no reason the central database cannot use various load distribution techniques to distribute across close proximity hardware.
 
I imagine they'd wanna have control over what happens with it moving into the future, not depend on the whims of some company and someone else's standard.

Also, it's not like Dexit is very widely used. I might be wrong in saying that, but I certainly don't know anyone who does.
 
You must log in or register to post here.

Back
Top