Consider allowing authenticators to randomise signed hashes.

[agl]

In order to frustrate differential power analysis, hardware authenticators will typically randomise as many inputs to cryptographic processing as possible. However, as currently constructed, they don't have an obvious way to randomise the hashes to be signed.

If the authenticator data structure contained an opaque, 16-byte field then authenticators that wished to do so could fill it with random data, thus randomising the hash to be signed. (Those that don't care can fill it with zeros.)

The signCount field might have been intended to help with this problem, but since maintaining a count would involve a flash write for each signature, and would leak tracking information, I imagine most implementations would simply set it to zero every time. (Indeed, that field is not mentioned anywhere else in the spec that I can see and might be a candidate for removal.)

[rlin1]

When receiving a signatureCounter, the relying party should a) compare that the value is greater than the previously stored one and b) store the new value.

When putting random data in the field, the RP would have to understand when to ignore the counter value.
This makes it more complicated for the RP.

I propose to close this issue as won't fix.

[equalsJeffH]

so @jyasskin notes that: discussion in PR #539 supersedes the discussion in this issue. all decisions are getting made in PR #539

See also @jyasskin's summary here: https://github.com/w3c/webauthn/issues/125#issuecomment-322900204

[AngeloKai]

I don't see any reason for us to talk about this issue within a W3C web spec. At the end of the day, this spec is a web spec that aims at standardizing the behaviors of the user agents. This spec doesn't attempt to standardize or define the hardware design. Please, if you want to talk about hardware design, go talk about it in CTAP land, in U2F land, or in UAF land. @agl @rlin1 @equalsJeffH

The spec will describe what the authenticators' fields mean and the differences between the different authenticators. But that doesn't mean we make design decisions here.

We should close the issue asap to avoid distraction since the ask here is to re-do hardware interface design (like by next Tuesday).

[agl]

We should close the issue asap to avoid distraction since the ask here is to re-do hardware interface design

Isn't webauthn the source of things like section 9.3 (Generic Transaction Authorization Extension), and 9.7 (Location Extension)? If these sections are echoing things defined elsewhere then I have misunderstood the relation between the specs. But if webauthn is defining things that can be signed then saying "there should be something arbitrary so that tokens can randomise inputs" is related.

Although I do agree that if the specific idea of describing the signature counter as arbitrary is rejected (as it appears from #539 ) then this gets more complex, probably involves an extension and can be worried about in the future.

[AngeloKai]

@agl At the end of the day, the WebAuthn spec is a web spec and should only define the web interface. Defining an extension typically involves both defining a web interface and defining new authenticator interface. If there's an ask to add a new extension that requires change to the authenticator interface, both the UA and the underlying protocol need to accept the ask. In this case, you are asking for the authenticators to randomize hash so the ask should start at the underlying protocol layer.

Which layer to start the ask from can be confusing given that there is a couple of extensions that only require web interface change. For example, the FIDO AppId extension will only require web interface addition since the authenticator protocol (U2F) already defined the AppId interface. The Generic Transaction Authorization Extension only requires the UA to show additional texts in authentication prompt so there's no need to go down to the authenticator layer.

There are many things in this spec that are in the grey area zone between the web spec and the protocol specs. So understandably it is difficult navigate. Nevertheless, we should still aim for keeping a clear boundary so that we don't have too many repeated conversations.

[agl]

In any case, putting this in an extension is highly problematic because extensions are optional, and a side-channel defense that the attacker can choose to deny to the token isn't useful.

Repurposing the signature counter seemed like a solid win because we eliminate the counter (which I believe would be positive) and can use those bytes for optional randomisation. However, it all depends on eliminating the signature counter, and enough people seem to believe that it still has value.