RE: [webauthn] FIDO U2F Attestation Statement Format doesn't say what to do with Counter

Hi Adam,

The counter was added to detect malware and / or phishing attack.  Higher counter value than the expected value would indicate to the RP that the key is being misused.  

My understanding is that there should be one counter per key not a single token-wide counter.  Single counter per key also does not pose any privacy issue.  If the spec is not clear about this, I think this point should be clarified.

-Ketan

-----Original Message-----
From: Adam Langley via GitHub [mailto:sysbot+gh@w3.org] 
Sent: Wednesday, August 16, 2017 1:58 PM
To: public-webauthn@w3.org
Subject: Re: [webauthn] FIDO U2F Attestation Statement Format doesn't say what to do with Counter

I believe that the signature counter was a mistake because of its limited utility and privacy risks.

The FIDO spec hints that the signature counter may be used to identify duplicated keys, but provides no guidance about how they see that happening. If a token fails to write to flash and thus repeats a counter, should sites reject that token and require a reenrollment? How is the latter to be authenticated? It seems to me that the base-rate of false positives would completely swamp the _extremely_ rare true-positives and thus nobody would bother.

On the other hand, in order to only need a constant amount of storage, U2F tokens generally maintain a single, token-wide counter. Thus the counter is a privacy leak between sites and adds a requirement that tokens maintain state.

Current U2F devices emit this counter and that has to be taken into account, but in #453 I suggest repurposing it as a randomisation field. This gives tokens (that want to use it as such) a defense against side-channel attacks and would allow future tokens to fix this privacy leak.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/507#issuecomment-322850700 using your GitHub account

Received on Sunday, 20 August 2017 11:53:52 UTC