Re: [webauthn] Sign counter alg 507

Thanks,  your alternative option was what I was trying to articulate based on Jakob’s comment.


> On Sep 11, 2017, at 9:22 AM, Rolf Lindemann via GitHub <sysbot+gh@w3.org> wrote:
> 
> 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 23:25:01 UTC