It's largely the same as credit cards - the card have multiple data partitions and secure read/write are encrypted. Balances are logged on both the card and the station-level servers and correctable errors and/or mid-ride updates, if any, are propagated while the user is in motion, so that they can be written upon exit.

^ that was the official explanation for a long time, but they've reportedly transitioned to more credit-card like online system with no station-level servers, and also raised fees, which was negatively received by many rail operators aside JR East itself(which owns the system). There had been few rail companies experimenting with NFC credit card rides, though I'm personally suspecting it's more of bargaining power development.open threat than those lines seriously considering a switch.

The chips in the cards are secure enough that physical tampering is extremely difficult and software tampering is difficult enough with security by obscurity + encryption - the catch is that, it turns out, early Suica cards used DES(not even 3DES it seems), and they just didn't tell anybody until those went out of circulation. 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.

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