Re: fyi: client nonce security analysis

What I think is the relevant section of FIPS 196

Finally, by including a random number of its own in an authentication token, a claimant can preclude the signing of only data that is pre-defined by the verifier. If a claimant uses a private key for more than just signing authentication tokens, for example, then a verifier could maliciously create a challenge consisting of information which is meaningful in another context. This can be prevented when the claimant signs both the challenge and unpredictable, meaningless data - a random number. This is why the responder in the mutual authentication protocol generates a signature over both random numbers, instead of just signing the initiator's random number challenge. 

Thinking about it the only parts of the response signed by the authenticator/token that is not directly or indirectly provided by  by the verifier are the user presence byte and the counter.

The concern is if you have a key pair that can be used across protocls (or versions of the same protocol) that an attacker might be able to manipulate there facit-id and challenge to make the resulting signed message usable in the other protocol meaning something else.

My first observation is that in U2F the first 32bytes are the SHA256 hash (generated by the fido client) of the UTF-8 encoding of the application identity <https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html> (app identity or URI).  I think finding a useful collision in SHA256 is a touch unlikely for the forceable future and if not we have other problems.   So in the middle we have a more or less fixed byte for user presence the counter that could be fixed to -1 or some value, and at the end we have the challenge parameter another sha256 hash of ClientData ( typ | challenge | facit_id/origin | Chanel_id (or token binding id) ).

Massaging ClientData into a hash collision would also be a challenge especially if token binding is used as that value can’t be influenced by the verifier.

Perhaps the best argument for this not being a issue is that U2F key pairs are not used outside the U2F context, so I don’t think with or without a nonce a attacker stands any chance of getting something signed that could be misinterpreted as a Web Authentication token, given the entire encoding is diffrent.

We could use the negative values of counter as a nonce in new devices if the verification rules allowed that.  
e.g. say any negative value of counter indicates it is not used and must be ignored.

I don’t think it would add much in reality, it might make a auditor happy I guess.

That is probably the least disruptive place to add it in the existing U2F protocol,  but it is a mitigation against a non existent threat, and a better mitigation would be token binding that mitigates other threats that are far realer than cross protocol replay. (As pointed out by the security review) 

John B.



> On Sep 6, 2017, at 5:36 PM, =JeffH <Jeff.Hodges@KingsMountain.com> wrote:
> 
> Protocol Omits Client Nonce
> 
> Targets: Signed messages from the athenticator to the Relying Party
> 
> Description: the protocol lacks an authenticator-provided nonce that
> would prevent a fully predictable signed statement that could be
> used in another context. NIST FIPS Publication 196 [1][2], as well as ISO/IEC 9798-3, recommends including a client-generated nonce value
> that the Relying Party cannot predict. This results in the signature
> ultimately being calculated over a value that is not entirely
> predictable by either party.
> 
> However, in this protocol design, the exact structure of the signed
> data is well defined and also predictable by the server beforehand.
> Furthermore, because the signed data begins with a SHA256 hash, it
> would not be difficult to coerce an authenticator into signing a
> statement where the leading bytes were fully attacker-chosen.
> 
> Exploit Scenario: In a future version of the protocol, say, a
> version identifier is added to the beginning of the signed data. An
> attacker manipulates their AppId which allows them to cause a
> Relying Party to interpret a version 1 protocol  message in another
> context.
> 
> Recommendation: Include a client-generated nonce value in the signed
> statement. Additionally, placed fixed protocol fields (such as flag
> fields) in the beginning of the signed statement, to reduce attacker
> control over the prefix of the message.
> 
> 
> [1] http://csrc.nist.gov/publications/fips/fips196/fips196.pdf
> [ although this spec is 'withdrawn', the reasons a 'random challenge' from each party (their term for 'nonce') features in the protocol have not changed and remain legit. ]
> 
> [2] TLS' handshake protocol features a client nonce "ClientHello.random"
> https://tools.ietf.org/html/draft-ietf-tls-tls13
> 
> 
>