upvote
> Plus, the prepaid limit of 20k yen(local equivalent of $200) limits abuse potential of the system; it's not worth trying to commit blatant frauds on the train-and-sandwiches card.

I don't think a limit on the value stored on the card limits the potential of fraud. I'm not imagining someone would load tens of thousands of yen onto their card. I'm more imagining someone setting the card to have enough money to get through the gate, every time they want to use the train. I'd agree fare is cheap enough that it's probably not worth someone's time to figure that out, but it would add up over time if someone did it (and especially if the method for doing so got passed around).

I also understand that there's two-way communication with one-time/expiring keys that would prevent a simple replay attack from working. Really just interested in understanding the entire mechanism in more detail! It gets handwaved as just "encryption" in a lot of discussions, probably due to a combination of intentional obscurity (like you mentioned) and it just not being super interesting or relevant to most contexts.

(Also, good point that the servers would still allow significant deviations to be caught and the card rejected/flagged in the system-- I've also seen that concept mentioned elsewhere after trying to research it a bit more.)

reply
I remember the stored-value transit cards in Sweden in the 90's/00's. They were just magstripe cards with the value on it and a basic checksum value. It was not hard to figure out how to rewrite the card with a higher value, or just clone it, value and all, onto a separate card. No online component, as mobile networks weren't great when the system was designed.

They'd download their transaction logs out of the buses every night and do a reconciliation. If they found a card where the value went up or had impossible travel times, they'd look at the travel routes/dates and wait around on the "hackers" commute route with a police officer until they showed up. Very manual.

reply