How can a debit card provide different answers when the same challenge is sent to it multiple times?

Question

I do only banking with my "PostFinance" debit card. The sign-in protocol works like this:

1. Enter user name and password into web form.
2. Get a 9 digit challenge number on website.
3. Type the challenge number into an offline standalone card reader with the debit card inserted.
4. Enter PIN into card reader.
5. Get a response 9 digit number from the card reader.
6. Type response number into web form.

I assumed this was some kind of asymmetric cryptography, with the card containing a private key unlocked with the pin, "signing" the challenge number and the bank verifying the signature with a "public" (not actually public) key.

But then I was idly wondering what the first thing would be that an attacker / security researcher would try and entered the challenge "1" multiple times. The answer was different each time:

The first 3 digits seam to increase monotonically in small steps (~10 samples). The other 6 digits didn't follow a pattern I picked up, i.e. they seemed random.

Does anyone know how this works?

Answer 1

Most probably there is a counter involved (or even better, if either the card or the reader is equipped with an internal clock and battery, a timestamp).

The secret key involved here may be either a symmetric or an asymmetric one, I do not think this would change anything here (there is no requirement for the bank to not know this secret).

However, as you were wondering, using this secret key to directly encode the challenge would allow an attacker to either generate a pile of answers by advance, or note the answer of the challenge you got and try to replay it to get another payment asking the same challenge accepted.

The goal here is to ensure that, even with the same challenge, the correct answer must always be different. For this, you will add either a counter (the cheap solution) or a timestamp (the most reliable one as it allows the answer to expire) to the challenge before applying the secret key to generate the answer.

On the server side:

• If a counter is used, it ensures that the answer you provides bears a counter strictly larger than the previous answer you provided, either for the same or a previous payment. If it happens that your answer seems valid but bears a smaller counter, this most likely mean that this answer has been replayed and that something fishy is currently going-on with your card (a few events like this and you may receive a notification from your bank, depending on their level of service).
• If a timestamp is used, the server simply has to check that the answer has been generated after the challenge has been sent to ensure that there is no replay attempt.