Re: [webauthn] Sign counter alg 507

Now:
0 means: SignCounter not supported or first assertion.
Our rule is counterMismatch=(CounterOnFile>0)  // i.e. we got indication that signCounter is supported
            AND(CounterInAssertion<=CounterOnFile)
Relying party will update the CounterOnFile to CounterInAssertion if counterMismatch is FALSE

a) SignCounter field in attestation statement set to 0 - but NOT included in U2F to-be-signed object (according to U2F specs).
   The this first value is not asserted by the authenticator!
b) RP will remember 0 for (1) Authenticators NOT supporting signCounter and also for Authenticators supporting signCounter.
c) first signature assertion might also contain a 0,
    for (1) Authenticators NOT supporting signCounter 
    and (2) also for Authenticators supporting signCounter *and* implementing a "post" increment (like some U2F Authenticators do today).
    Note: implementing a "pre" increment would also be allowed according to U2F specs (today).
d) second signature assertion might contain a 
    (1) a value 0 for Authenticators NOT implementing signCounter or
    (2) a value >0 for Authenticators supporting both, per Credential or global signCounter.


Once the relying party received a non-zero signCounter value, it assumes that signCounter is supported.
The signCounter "signal" starts working on the 2nd signature assertion.

Notes: 
a) At this time any positive increment seems to be allowed - we do not expect the increment to be exactly 1.  
   It could also be time_t - assuming at leat one second time delay between two signature operations.
b) The authenticator will not function as expected after the signCounter hits the maximum value (i.e. 0xffffffff).


Alternative:
0 means first assertion when signCounter *is* supported.
MSB set to indicate signCounter is *not* supported.

Our rule is counterMismatch=(((CounterOnFile&0x80000000)==0)          // i.e. we got indication that signCounter is supported
                             AND(CounterInAssertion<=CounterOnFile) ) 
Relying party will update the CounterOnFile to CounterInAssertion if counterMismatch is FALSE
                              
a) SignCounter field in attestation statement set to some value if MSB set 
    - but NOT included in U2F to-be-signed object (according to U2F specs).
   The this first value is not asserted by the authenticator!
b) RP will remember that value with MSB set for 
     (1) Authenticators NOT supporting signCounter and also 
     (2) for Authenticators supporting signCounter.
c) first signature assertion might contain a 0 for Authenticators supporting signCounter 
   first signature assertion might contain s value with MSB set (i.e. >=0x8000000) for Authenticators NOT supporting signCounter.
d) second signature assertion might contain a 
    (1) a value with MSB set (i.e. >=0x8000000) for Authenticators NOT supporting signCounter, or
    (2) a value >0 for Authenticators supporting both, per Credential or global signCounter.

Once the relying party received a signCounter value without MSB set (i.e. <0x8000000), it assumes that signCounter is supported.
The signCounter "signal" starts working on the 2nd signature assertion.

With the second proposal we get
(1) half the range of the signCounter, i.e. time_t as SignCounter values will be challenging.
(2) support for authenticator generated Nonce (by repurposing the signCounter field)


-- 
GitHub Notification of comment by rlin1
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/539#issuecomment-328527178 using your GitHub account

Received on Monday, 11 September 2017 13:22:33 UTC