What mechanism is embedded within, for instance, tram cards that you can use to check in and out of your train ride, that prevents you from copying the signal that is coming from that card ? I could maybe understand this for cards that have an account linked to them (e.g. bank cards or other personalised cards), but what about cards you just [top up](https://en.wikipedia.org/wiki/Stored-value_card?wprov=sfti1) (e.g. [train cards in the Netherlands](https://en.wikipedia.org/wiki/OV-chipkaart?wprov=sfti1)). Why couldn’t you just copy every signal that is coming out of that card and clone it to a different one making a receiving device think you have a topped up card?
In: 0
The card is an RFID device. When you take it near a reader, it is the radio waves coming from the reader that are used to power a tiny microchip on the card that is capable of receiving data, doing calculations and sending a reply to the reader.
To make a payment, you have three parties working together: the card, the POS terminal (Point of Sale or Piece of Shit depending on whether it decides to not work that day) aka the card reader and the bank’s (or credit card company’s) computer.
When a POS terminal is registered, it is given a cryptographic certificate to act as its little ID card from the bank. When starting up, it uses this to identify itself to the bank and be allowed to initiate payment requests.
Your card has a similar little ID key in it – it is known to nobody other than it. The bank has a pair of this key – another key that has the unique property that if it is used to encrypt something, only the other half of the pair can decrypt it out of all possible keys.
When a payment is initiated, the POS terminal does its own little authentication dance to the bank and when it is done, it’s your card’s turn. The bank chooses a secret message and encrypts it with the pair of the card key it has. The encrypted message is sent to the POS terminal (which can’t read it because it has neither key much less the super secret one on the card) and the terminal sends it to the card.
The card takes its own super secret key and attempts to decrypt the message. The result is sent back to the bank through the POS terminal. The bank checks the reply and if it is the same message it started with, then it can be sure that your card was the one to decrypt it and the transaction can go through.
The implications of this is such: if the challenge message is 1024 bits long, were you sneaking around and listening to the card talking to the POS terminal, you’d need to listen to circa 2808895523222368605827039360607851146278089029597354019897345018089573059460952548948569958162617750330001779372990521213418590137725259726450741103741783193402623334763523207442222181269470220616454421126328215138096104411600982523029892352200425580677351729446660909999175717788745567263052442650378502144 valid transactions *from that specific card* to have a ~1.56% chance of getting a challenge key you’ve already seen and know the answer to (and you probably get only one chance before the bank locks touch payment for that card). [That number is not button mashing.](https://www.wolframalpha.com/input?i=2%5E1024+%2F+64)
Another way to implement a similar arrangement is called [TOTP](https://en.wikipedia.org/wiki/Time-based_one-time_password). This is what two-factor authentication (Google Authenticator, Steam Guard, etc.) use. The secret key is know to both the device seeking authentication and the server. The challenge key is ever changing yet not flexible: the current time (usually down to about a minute or so). The server and the device both use the commonly known key and the current time to generate a password. The client sends it to the server and the server checks if they match – if they do, then it can know that the client also knows the secret key. Record and replay attacks are ruled out simply by the server checking the current time when it received the authentication request – in a given minute, the chance of guessing the correct reply for a certain key without knowing it for any given time is similarly miniscule as the above example, and the server can simply refuse to accept that key again until it expires.
Latest Answers