SafetyNet Attestation Clarifications

[apowers313]

Splitting off the SafetyNet conversation from #950, as requested during the last call.

I think the questions are:

1. What is ver and how is it verified and / or used during verification?
2. Where do we find the root cert for SafetyNet?
3. What value gets put in the SafetyNet nonce (not part of Attestation validation issues #950, but perhaps some clarification is needed)?

cc: @agl @christiaanbrand @leshi @kpaulh

[yackermann]

@apowers313

2. SafetyNet uses google root certificates https://pki.goog/. Needs to be clarified in specs. Needs metadata.

3. That's actually clear in specs:

Concatenate authenticatorData and clientDataHash, perform SHA-256 hash of the concatenated string, and let the result of the hash form attToBeSigned.
Request a SafetyNet attestation, providing attToBeSigned as the nonce value. Set response to the result, and ver to the version of Google Play Services running in the authenticator.

Verify that the nonce in the response is identical to the SHA-256 hash of the concatenation of authenticatorData and clientDataHash.

[yackermann]

If successful, return attestation type Basic with the attestation trust path set to the above attestation certificate.

• Verify certificate chain in x5c against attestationRootCertificates in metadata statement
• Verify signature using leaf certificate of the x5c sequence

[emlun]

@arshadnoor writes in #950 (comment):

I had always thought that implementers could choose to do verification against the attestation root verified by the scheme OR use MDS (or both).

Implementers that are conscientious about protecting the RP will have to use both. Here's why:

• It is possible that the Authenticator manufacturer did not provide an AIA extension for a variety of reasons:

  i) They do not know have a PKI built up correctly to enable this capability;
  ii) They assume that because the WebAuthn spec indicates that the AIA extension
  makes id-ad-ocsp optional, they do not not have to put in the id-ad-caIssuers access method
  (thus making it impossible to programmatically verify the certificate-chain of the attestation certificate;
  iii) They have not revoked the attestation certificate of a compromised Authenticator for a variety
  of reasons;

• It is possible that the Authenticator manufacturer:

  i) Is not participating in the FIDO MDS capability;
  ii) Has forgotten to notify FIDO MDS about a compromised attestation key-pair or Authenticator;
  iii) Has gone out of business;

I realize neither the FIDO Alliance nor the W3C are responsible for "best practices" in the PKI industry; but to make both the CRLDP and the OCSP Responder URL optional in the attestation-certificate chain is irresponsible. There is no point in defining a protocol for strong-authentication to eliminate passwords off the internet if we weaken the scaffolding necessary to build trust in the WebAuthn protocols.

I would strongly recommend that that the WebAuthn spec remove the guidance in sections 8.2.1 and 8.3.1 about making the CRLDP and AIA extensions optional, and instead, recommend that Authenticator manufacturers follow "best practices" of the PKI industry in creating and managing their attestation certificate infrastructure. Or make participation in the FIDO MDS mandatory. If both capabilities cannot be relied upon by implementers, the FIDO ecosystem will setup RPs and their user-community for some unpleasant surprises.

[equalsJeffH]

@arshadnoor's comment ought to be a separate issue?

[yackermann]

@leshi @christiaanbrand Maybe we should add requirement that assertion timestamp must be not older than 1 or 5 minutes?

[nadalin]

@apowers313 seems best handled in a best practice guide and not in the main specification

[apowers313]

@Nadlin

From my original comment:

1. Is currently unimplementable and needs to be addressed in L1
2. Could be best practice, but would would be nice to fix if we are fixing Abstraction layer for attestations #1
3. May be a moot point, but I’d wait for a definitive answer from the Google team

[yackermann]

@christiaanbrand can you clarify what is the purpose of the ver field?

[emlun]

@apowers313 @herrjemand can this be closed with #1093 merged?

[yackermann]

@emlun Google team needs to clarify the meaning of "ver" verification step.

Any feedback @christiaanbrand @leshi @kpaulh ?

[bdewater]

1. What is ver and how is it verified and / or used during verification?

This is still not clear and I haven't been able to find any documentation on it.

[apowers313]

I think #1170 fixes all these problems except ver, which isn't mentioned in the SafetyNet docs or in WebAuthn and I'm not sure which one it belongs in. What should ver be? 1 until a new format of SafetyNet comes out? Should that be documented here or in the SafetyNet docs?