[dokument]

So basically U2F clones. It would be neat to have some sort of CA between U2F devices, device A could sign device B and be put away, and device B could store the signing and share that with sites. This would allow device A to revoke device B completely, but would require a change of u2f support.

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?

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

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

[dimonomid]

There's no easy way to increment the counter, so one would have to invent some automation for sending authentication challenges to the token and pressing the physical button every time. The time it'd take should be enough for me to get another pair or tokens, enroll it to my accounts and revoke the old one.

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.