2

My question is about the U2F protocol and more precisely cloning detection. According to the doc :

"If there is a possibility that a U2F token can be cloned, we also need some way to detect it. We can do this by having an operation counter. Every time a cryptographic operation is performed, the counter increases by 1. The value of the counter is signed and sent as part of the response to the relying party, which stores the value of the counter in its database. If the counter value in a future authentication response is less than the counter value stored by relying party, then the token has been cloned, and the relying party must decline the authentication request. It should probably also log the event occurrence and/or perform necessary actions to secure the user, by for example blocking token from further authentication attempts."

Why the counter value in a future authentication response would be less than the counter value stored by a relying party ? If an attacker has cloned the device, he has access to the current counter value stored in the original device, isn't it ? He could then send a counter value bigger than the counter stored in the database of the relying party, and the device will not be marked as compromised.

I'm certainly wrong but I am just wondering.

Thanks you in advance !

1

Let's plot out a scenario:

T = 1     Authenticate Real, Counter = 20
T = 2     Device is cloned into Real / Dup
T = 3     Authenticate Real, Counter = 21
T = 4     Authenticate Dup, Counter = 21

Because the server saw the same counter twice, obviously it was cloned.

The attacker could send a counter value bigger than the counter stored in the database of the relying party

Okay, let's try this, by e.g. adding 1000 to the counter.

T = 1     Authenticate Real, Counter = 20
T = 2     Device is cloned into Real / Dup
T = 3     Authenticate Real, Counter = 21
T = 4     Authenticate Dup, Counter = 1021

Seems fine...

T = 5     Authenticate Real, Counter = 22

Uh oh - 22 is less than 1021 - now the real key has been denied and the user knows something's up.

  • Ok, understood ! But there are two problems. Indeed, what if the real user get authenticate one month later after an attacker cloned his device ? It's messed up. Second is, we can't determine which one of the two users is the attacker. – QBl Jun 3 '17 at 18:07
  • Worse, if the customer loses his usb key right after his device has been cloned. What we have (the relying party) to do in theses cases ? – QBl Jun 3 '17 at 19:19

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.