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?

1 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.
  • If it was asymmetric the bank could forget about the private key and the public key data would be less valuable for anyone to steal. I just checked again and the first 3 digits jumped a larger step than when I was testing repeatedly with little time in between, so I guess it's a clock. Unit is not seconds, but still small enough for a wrap-around to occur routinely, if it really is a clock. Considering that the challenge is controlled by the bank, why not just never re-use challenges? 10^9 challenges seems enough for the lifetime of one card.
    – Nobody
    Jul 20, 2017 at 21:04
  • @Nobody "the public key data would be less valuable for anyone to steal": I can hardly imagine a situation where stealing the core secret and payment authorization keys of a bank could be "less valuable" to any attacker. Fortunately, you will not find them stored in any SQL database but in tamper resitant, self-destructive hardware security modules (HSM). Jul 20, 2017 at 21:13
  • Simply using a unique challenge would not prevent an attacker from generating a large number of answers by advance (typically in all these situations where you hand over your card such as restaurants, highways toll, etc.) in the hope that a fair number of the corresponding challenges have not been issued yet by the bank and may therefore be used to validate payments (obviously all this has to be automated, I don't talk about manually generating 10 challenges). Jul 20, 2017 at 21:16
  • Well, in principle the attacker couldn't derive the secret needed for payments from the stolen data, but I guess it's one of those "if this happens, then it's already too late" situations. But an attacker could only generate challenge/response pairs if they have my pin (and it needs to be re entered every time), so "attacker generating lots of challenge/response pairs" is also a "if this happens it's already too late" situation. This is not a card which works in the scenarios you mentioned, it won't authorize any transaction without pin.
    – Nobody
    Jul 20, 2017 at 21:32
  • (it's possible the card has a magnetic-stripe backwards-compatibility mode for developing countries where chip-cards are not universally supported, but that would be a completely different system)
    – Nobody
    Jul 20, 2017 at 21:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .