fyi: client nonce security analysis

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

Received on Wednesday, 6 September 2017 20:36:44 UTC