[jiveturkey]

> let's say someone steals your primary U2F, can't they just increment the counter to 1000002

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.

[dimonomid]

> 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.

[jiveturkey]

> The counter is maintained by the ATECC508A chip

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.

[dimonomid]

> 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.

Could you elaborate more on that? How exactly I could use any counter value?

[dimonomid]

I just realized that there IS a reliable solution to this issue with the counter. Accordingly to ATECC508A datasheet, its counters can count only up to 2097151, but the whole range of U2F counter is 0xffffffff (which is more than 4 000 000 000). So, the counter boost should be set to the value larger than 2097151, and then, the primary token would never be able to return counter which is that large. So once backup token is used, the primary one is invalidated for good.

Ok cool, I’ll update the article with that important detail.

[scott00]

Wouldn't that also invalidate your backup token after first use?

[dimonomid]

No, of course not. In backup, we basically use this as a counter: `hardware_counter_value + 2000000000`. We don't care that `hardware_counter_value` cannot be larger than `2097151`; the value we use for calculations is 32-bit, so effectively, for the backup token, the values will start at `2000000000` and the maximum possible value will be `2002097151`.

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.