impl guidelines for signature counter

[equalsJeffH]

from: https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0070.html
the spec lacks description of the significance, use, and management of the signature counter.

Searching for ³counter² across the entire document only shows a few definitions of counters, not any description of their use. [...] And what about for assertion signatures ­ every time an authenticator asserts it should grab the last counter, bump it, sign it, and store the new value?

e.g., there could be some further language in the spec (eg Impl guidelines and sec considerations) regarding the signature counter.
see also: #116

[jyasskin]

To link everything up, @agl suggests in issue #453 that the counter field be repurposed for a place to inject some random data that authenticators can use to frustrate differential power analysis. In issue #507 (comment), @equalsJeffH recorded the statement in this morning's call that the counters are used to detect cloned authenticators, at least in the case that the authenticator maintains a count at all.

I also remember a statement (maybe from @rlin1?) that RPs need to detect whether or not an authenticator maintains the counter in order to know whether to try to use it to detect cloned authenticators, but I didn't catch the bits in the protocol that would let the RP detect that. The fix for this issue should describe the algorithm the RP needs to run.

If that algorithm can distinguish an unused-but-nonzero counter from a used counter, that might suffice to let some authenticators add randomness using the "counter" field, as desired in #453.

[rlin1]

See PR #539

[rlin1]

The U2F specs say (with regard to the counter, see https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html#authentication-response-message-success):
"This is the big-endian representation of a counter value that the U2F token increments every time it performs an authentication operation"

This sounds to me like a U2F Authenticator (supporting the counter) will never return a counter with value 0. Since the counter is only included in the signature assertion (as result to the first authentication operation)

[nadalin]

@equalsJeffH So if we take what is in the U2F Spec or reference the U2F spec would that be OK? as the authenticator has to support the counter, I can imagine some do and some don't. I can imagine that this will only currently be used by U2F authenticators

[rlin1]

the way I read the U2F specs, there is a field for the counter, but the Authenticator could always set the field to 0 in order to indicate that the counter isn't supported.

[ve7jtb]

In implementation considerations 2.6 the counter should start at 0.

In the limited tests I can do with the uninitialized key I have it sent one for the first authentication but I am guessing that just happened to be one vendors implementation.

A key sending 0 would be perfectly valid according to my reading of the spec, and I would probably have interpreted it that way.

I think the better solution is to ignore all negative numbers in verification as those don't support a counter. That lets people use a negative random value to protect against power analysis if they want, and it will be ignored by the verifier. Basically Jakobs proposal.

[rlin1]

See PR#539

[rlin1]

addressed by merging PR #539. Should close this issue.