I am trying to understand the FIDO2 standard. I know that a Relying Party has to implement a mechanism that checks the counter of the respective credentials. Most of the time, a counter is stored in the database of the server, which has to be smaller/equal to the sent counter. After a successful login, the counter is increased.

This assumes that the counter is also stored on the Authenticator. If I now assume that I can clone a key (however that works) - haven't I then also copied the counter and the credential works?

How can the relying party recognise the cloned key? Maybe I am understanding something completely wrong, please clarify. Cheers

1 Answer 1


After a device has been cloned we have two devices, the original and the cloned one. A cloned device is detected when the server receives a counter value that was lower than the previous one by using the fact that the two devices don't synchronize their counter.

When an attacker tries to authenticate with the cloned device before the user did the counter that is sent to the server will be greater than before, a clone can not yet be detected. As long as the user does not authenticate the attacker can use this device for further authentications. The counter of the original device does not get rolled forward when the attacker authenticates with the cloned device, but the counter on the server gets rolled forward by at least one for each authentication because the attacker has to send a higher counter value.

When the original user then tries to authenticate with his device the counter of his device has not been rolled forward and therefore the counter that the device sends has a value that is smaller or equal to that on the server, the server then knows that the authentication device was cloned.

Note that the server can not differentiate between the original and the cloned device. It could very well be the case that the user himself does the first authentication after the device is cloned, then the device with the invalid counter would be the cloned one.

Important: This explanation ignores the fact that the counter that is sent to the server may be skipped in the following way: The user wants to authenticate, the server sends the challenge to the client, the client forwards it to the device, the device calculates the response and increases the counter, the device sends the response with the counter to the client but the client is not able to forward the response to the server (eg. because of a connection timeout). On the next authentication with the device the counter gets incremented again, which results in the server not receiving the counter value that was used when the client connection timed out. An attacker would be able to use this lost counter value to authenticate without being detected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.