I understand the counter piece, but let's say someone steals your primary U2F, can't they just increment the counter to 1000002 and it would keep working even if you have used your backup token?
If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way.
This doesn't matter in practice, however. No site is doing anything useful with the counter.
What do you mean? In the article I mentioned that at least Google and Github refuse to authenticate if the counter is less than the last seen value. So using backup token does invalidate the primary one.
> If they steal a primary yubikey token, no. The counter is stored and managed only in the secure element part of the device. If they steal a primary u2fzero token, which of course the proposal depends on, the counter is not protected in any meaningful way.
Where did you get the idea that the counter on u2f-zero is not protected in any meaningful way? The counter is maintained by the ATECC508A chip and is incremented on each authentication. And also see my adjacent comment about reliably preventing primary token from returning a counter which is as large as that of backup token.
In the u2fzero implementaiton, the counter is not used internally by the ATEC5508A in the signature generation. It's merely used as stable storage.
It's used much like unix advisory file locking. As long as you are not using it adversarially, it will work "correctly".
Once you attack the device, it's absolutely trivial to use any counter value you care to, not at all connected to the (yes, secure-enough) counter internally stored in the ATEC5508A.
Apologies about my incorrect statement about any site's usage of the counter. I was mistakenly thinking about the allowance of the counter to increase by any increment.
Still, this is a weakness of the U2F spec. In fact, there is no spec for counter usage on the RP (relying party) side, just an implementation consideration:
> Relying parties should implement their own remediation strategies if they suspect token cloning due to non-increasing counter values.
So you, the conscientious user, would need to verify with each site that they don't allow the counter to reset. Well, you would need to if the counter were implemented correctly with u2fzero.
Could you elaborate more on that? How exactly I could use any counter value?
Ok cool, I’ll update the article with that important detail.
But the primary token uses just `hardware_counter_value`, so its range is from `0` to `2097151`.
The important part is that the ranges of primary and backup tokens don't intersect.
Also let's make it not 1 000 000 but, say, 4 000 000 000, which still leaves plenty of values of a 32-bit value.