3

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 !

QBl
  • 55
  • 3

1 Answers1

0

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.

Riking
  • 304
  • 1
  • 9
  • 1
    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 03 '17 at 18:07
  • 1
    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 03 '17 at 19:19
  • @QBI: that part of the U2F/Fido standard is messed up. They were warned when establishing the standard that the counter would be a fail and it is a fail. Some in the commitee voiced opinions against this broken idea. People have fully working clone, defeating the purpose of the counter. There are not only the issues you mention but also people with fully working clones: and when you mention that it's radio silence. It's nearly as bad as their decision to use the broken RSA with PKCS 1V1.5 padding (with known attacks since years and years). Still, U2F is the "less bad" 2FA we have. Oh well : ) – Cedric Martin Oct 31 '19 at 12:58
  • By "people with working clone" I mean: legit users cloning, for very legitimate reason, their own U2F devices (like the Ledger Nano S and it's U2F app, where you can clone the counter on a newly initialized device : something which was supposed to never be doable according to the standard). – Cedric Martin Oct 31 '19 at 12:59