Checking AAGUID when attestation type is "direct"

[chrismccaw]

I am using Chrome and the attestation type is "direct". When I register an additional popup appears asking to "Allow" or "Block" my authenticator details. Even though I "block" the request the #verify is still successful. Should the #verify check the presence of the AAGUID for fido when direct attestation is set?

[bdewater]

Hi @chrismccaw 👋

First off two small things:

• Full attestation checking is still WIP (Metadata service support #208)
• It's not recommended to request attestation for consumer use cases, and e.g. Chromium has put some expectations on sites following guidelines

Assuming you're sure you need attestation of a device: the PR shows a hint of what direction I believe this should go in. Per § 6.4. Attestation

It is expected that most authenticators will support a small number of attestation types and attestation statement formats, while Relying Parties will decide what attestation types are acceptable to them by policy. Relying Parties will also need to understand the characteristics of the authenticators that they trust, based on information they have about these authenticators. For example, the FIDO Metadata Service provides one way to access such information.

Whatever you application as an RP should accept can be dependant on so many different things that is impossible to encapsulate in a library. For example, to pass FIDO Conformance Tool tests we need to raise if the metadata has the authenticator is known to be compromised:

public_key_credential.verify(expected_challenge) 

reports = public_key_credential.response.metadata_entry.status_reports
raise("bad authenticator status") if reports.any? do |report|
  ["USER_VERIFICATION_BYPASS", "ATTESTATION_KEY_COMPROMISE", "USER_KEY_REMOTE_COMPROMISE",
   "USER_KEY_PHYSICAL_COMPROMISE", "REVOKED"].include?(report.status)
end

But your use case might be different, e.g. you could want to check with the MDS if the authenticator claiming to be capable of user verification is actually so before allowing it to be used as multi-factor login. Use cases I'd imagine are banks, employers, governments, etc.

Interesting to see Chrome now returns a "none" attestation format, that used to be a "NotAllowedError" DOMException. That means you can now check on your server whether the "none" attestation format is acceptable for your use cases via public_key_credential.response.attestation_format.

[chrismccaw]

@bdewater This is great information. I appreciate you putting it together including the references. The PR you have created looks like the right direction to go in for Full attestation and would be amazing to get the MDS in place

Does adding the "direct' attestation perform any sort of extra checking currently? Is there any point using it right now with this library?

[bdewater]

Currently from the top of my head only Safetynet does checks to verify the attestation certificates chain up correctly to a trusted root. The others do not so in theory anyone could have generated the attestation, so no security benefits at the moment.

[grzuy]

Chiming in just to share this link which is relevant to this discussion in some way: https://www.w3.org/TR/webauthn-2/#sctn-attestation-limitations.

[chrismccaw]

I think it is best to not use direct attestation at the moment until the MDS is implemented. I can try help out that effort.

The best short term solution is something like this:

https://www.w3.org/TR/webauthn-2/#sctn-attestation-limitations.
Attestation types other than Self Attestation and None can increase the difficulty of such attacks, since Relying Parties can possibly display authenticator information, e.g., model designation, to the user. An attacker might therefore need to use a genuine authenticator of the same model as the user’s authenticator, or the user might notice that the Relying Party reports a different authenticator model than the user expects.

[bdewater]

@chrismccaw #208 is ready for review, I would appreciate any feedback you might have :)

[chrismccaw]

Awesome. Will take a look

[grzuy]

Whatever you application as an RP should accept can be dependant on so many different things that is impossible to encapsulate in a library.

@bdewater I agree we wouldn't be able to capture every use case out there. I wonder, however, if we might be able to capture some very general policies regarding "Attestation".

I mean, back to the original question from @chrismccaw in this issue, shouldn't the user be able to configure in some way, e.g. that "None" is not an acceptable under policy (Step 16 in https://www.w3.org/TR/webauthn-2/#sctn-registering-a-new-credential), and get the library to fail verification?

[grzuy]

Hi,

Discussion here has been helpful and interesting.

However, closing for now, given I don't see any obvious actionable item based on the issue title and description.

If either of you think otherwise, let me know. We can re-open or create a new more concrete issue.

Thank you both!