Webauthn: Attestation validation issues

[apowers313]

TPM:

• Doesn't mention to validate the x5c chain or where to find the root of trust
• Statements like Verify that x5c or If x5c contains an extension are unclear whether they are referring to "attestation public key in x5c" or "all certificates in x5c".

Android SafetyNet:

• Doesn't mention to validate the x5c chain or where to find the root of trust
• Doesn't mention to validate the JWS signature

[emlun]

• Doesn't mention to validate the x5c chain or where to find the root of trust

This is done separately in the RP Operations:

1. If validation is successful, obtain a list of acceptable trust anchors (attestation root certificates or ECDAA-Issuer public keys) for that attestation type and attestation statement format fmt, from a trusted source or from policy. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to obtain such information, using the aaguid in the attestedCredentialData in _authData_.

2. Assess the attestation trustworthiness using the outputs of the verification procedure in step 14, as follows:

   • If self attestation was used, check if self attestation is acceptable under Relying Party policy.
   • If ECDAA was used, verify that the identifier of the ECDAA-Issuer public key used is included in the set of acceptable trust anchors obtained in step 15.
   • Otherwise, use the X.509 certificates returned by the verification procedure to verify that the attestation public key correctly chains up to an acceptable root certificate.

---

Statements like Verify that x5c or If x5c contains an extension are unclear whether they are referring to "attestation public key in x5c" or "all certificates in x5c".

Agreed.

Doesn't mention to validate the JWS signature

I know almost nothing about Android SafetyNet, but I _think_ that might be implied by the verification procedure step "Verify that _response_ is a valid SafetyNet response of version _ver_.".

[emlun]

Marking this as editorial since no technical changes will be made here (even if the changes are normative, they won't affect interoperability since all the tech is already set in stone).

[emlun]

The packed format has the same issue with unclear use of x5c.

If we feel it's worthwhile, we could also touch up the android-key and fido-u2f verification procedures. android-key uses a verbose "the first certificate in x5c" wording everywhere, and fido-u2f introduces a new attCert name instead of reusing the attestnCert name defined in the syntax definition. None of these _necessitate_ a change, though. Should I do that?

[apowers313]

Step 16 of RP Operations handles my concern about not saying to validate the x5c Array; however, each attestation scheme has it's own root certificates. I have no idea where to grab the TPM root (or even if there's one root issued by TCG or each manufacturer has their own root). I'm guessing that I can probably search around for the SafetyNet root, but it sure would be nice to include a link to it in the spec.

In the SafetyNet Attestation API docs there is a section entitled Verify the compatibility check response that says to check the signature of the JWS... maybe a pointer to that is what is needed? @leshi

It's still not clear to me how to correlate the ver with the response to make sure the response is right. It's not like there's a version member inside the response payload:

{
  "nonce": "lWkIjx7O4yMpVANdvRDXyuORMFonUbVZu4/Xy7IpvdRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQKglxHyfnRKAZVqiJdIqtqf4I9dx0oO6/zAO8TnDojvEZAq2DZkByI1fcoWVQEq/O3FLH5aOwzbrrxrJ65U5dYqlAQIDJiABIVggh5OJfYRDzVGIowKqU57AnoVjjdmmjGi9zlMkjAVV9DAiWCDr0iSi0viIKNPMTIdN28gWNmkcwOr6DQx66MPff3Odm+u6eJqLBl1H2S2trABHLinknsyVMPm/BNUVZ2JFlr80",
  "timestampMs": 1528911634385,
  "apkPackageName": "com.google.android.gms",
  "apkDigestSha256": "JOC3UkslsuVz13eOpnFI9BpLoqBg9k1F6OfaPtB/GjM=",
  "ctsProfileMatch": false,
  "apkCertificateDigestSha256": [
    "GXWy8XF3vIml3/MfnmSmyuKBpT3B0dWbHRR/4cgq+gA="
  ],
  "basicIntegrity": false,
  "advice": "RESTORE_TO_FACTORY_ROM,LOCK_BOOTLOADER"
}

[emlun]

Yeah, it seems like where to get the root certs is intentionally left out except for the mention of the FIDO MDS.

In the SafetyNet Attestation API docs there is a section entitled Verify the compatibility check response that says to check the signature of the JWS... maybe a pointer to that is what is needed?

Thanks, that seems like a good solution to me!

It's still not clear to me how to correlate the ver with the response to make sure the response is right. It's not like there's a version member inside the response payload

I'm guessing the purpose of the ver response field is for selecting a verification algorithm, rather than something to compare the response against.

[emlun]

On second thought, though: how stable can we expect this link to the SafetyNet documentation to be in the future? @leshi

Considering the "SafetyNet API" link in §8.5. Android SafetyNet Attestation Statement Format is already half broken...

[gmandyam]

@emlun

I would go even further than that. SafetyNet is the only attestation format in the spec that is not specific to the credential itself. In my opinion, it makes more sense as an extension than as a Webauthn attestation. For instance, see the discussion in https://github.com/w3c/webauthn/issues/438.

[apowers313]

@gmandyam The SafetyNet nonce contains the authenticatorData which contains the new publicKey; and the nonce is signed over with a cert that chains back to a root of trust. Seems like worthwhile attestation to me.

@emlun

1. I like the idea of assigning attCert as x5c[0] and then consistently referring to attCert throughout the verifications.
2. So the TPM / Google root certs (should) be in MDS associated with every AAGUID that is dependent on them?
3. ver might be for choosing a verification algorithm, but there's still no documentation on how to use it to select a verification algorithm. Maybe there's something I'm missing for how ver would relate to different versions of the SafetyNet API documentation?

[emlun]

1. I believe that is the intent of the MDS, at least. @rlin1 care to comment?
2. I'm out of my depth here - someone from Google please take this one? @agl @christiaanbrand @leshi @kpaulh

[herrjemand]

And I think we need to clearly specify verification against the metadata in specs

[apowers313]

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

[arshadnoor]

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.

[emlun]

Parts of this is fixed in #952, remaining discussion continues in #968.