Support FIDO metadata service version 3 for attestations

[tcannonfodder]

Copied from: cedarcode/webauthn-ruby#375

From https://developers.yubico.com/WebAuthn/Concepts/Securing_WebAuthn_with_Attestation.html#_recommendations

You can find the root certificates used to sign attestations on manufacturer websites (Yubico’s is here) or in the FIDO metadata service version 3.

The FIDO Alliance Metadata Service (MDS) is a centralized repository of the Metadata Statement that is used by the relying parties to validate authenticator attestation and prove the genuineness of the device model. MDS also provides information about certification status of the authenticators, and found security issues. Organizations deploying FIDO Authentication are able to use this information to select specific certification levels as required for compliance, and work through the security notifications to ensure effective incident response.

From https://fidoalliance.org/metadata/

[tcannonfodder]

Once the new API is supported, I think we should update https://github.com/cedarcode/webauthn-ruby to remove its custom attestation code and instead document how to integrate the two gems. That way developers have a stable upgrade mechanism and the gems are easier to maintain (since we no longer have to push out gem updates for updates to the FIDO metadata)

[bdewater]

This has been on my mental to-do list, thanks for opening an issue. I was planning to drop v2 support entirely and do a major version bump.

I think we should update https://github.com/cedarcode/webauthn-ruby to remove its custom attestation code and instead document how to integrate the two gems

Not sure which code needs to be removed from webauthn-ruby, could you clarify?

[tcannonfodder]

Not sure which code needs to be removed from webauthn-ruby, could you clarify?

I saw this section of the README: https://github.com/cedarcode/webauthn-ruby#attestation

Plus the following snippet of code, which seems to have the root certificate for attestation statements stored as part of the code. I’m not 100% sure on how the FIDO metadata service works, but it seems like you’d pass the attestation statement to this gem, to see if the statement is valid (based on the metadata service’s data): https://github.com/cedarcode/webauthn-ruby/blob/master/lib/webauthn/attestation_statement/apple.rb

[bdewater]

Gotcha, definitely room for improvement in the webauthn-ruby readme on how to do attestation verification with this gem, but it's a fairly niche use case 99% of the people don't need.

I’m not 100% sure on how the FIDO metadata service works, but it seems like you’d pass the attestation statement to this gem, to see if the statement is valid (based on the metadata service’s data)

These are related but not in this way. WebAuthn attestation responses contain an attestation object. This has a specific format that describe the claim the authenticator makes about itself - like 'my AAGUID is c5ef55ff-ad9a-4b9f-b580-adebafe026d0 so that means I'm a YubiKey 5Ci'. The verification procedures are different per format, the MDS is a way (not the only way!) to verify such a claim for packed and fido-u2f attestation formats.

If the attestation response basically checks out, the MDS can be used to look up this AAGUID and then get additional metadata about it. Look for the "YubiKey 5 Series with Lightning" on https://opotonniee.github.io/fido-mds-explorer/ to see what exactly. The first important thing it that it has the manufacturer root certificate that can be used to verify the authenticator claim it's a genuine YubiKey. An alternative to trusting the MDS for this is going around and collecting all root certificates yourself from manufacturers you trust (which is kinda how TPM attestation works).

The second is that the MDS contains metadata (hah) about the authenticator, such as the type and strength of the key storage, quality of biometrics employed (if any) and any status reports about flaws that make the authenticator untrustworthy.

As I said it's niche, users need to consent to share the additional information. Passkeys due to their syncing nature will have none attestation IIRC and are expected to be the majority use case. Governments, military, banks and other regulated industries will need attestation for compliance reasons. For the majority rest of websites it's perfectly fine not knowing whether someone is using a secure modern smartphone or Chrome virtual WebAuthn authenticator - either is already a massive step up from passwords + weak multi-factor authentication and their common attack vectors (database leaks, SIM swapping, phishing, etc).

Hope this helps :)

[tcannonfodder]

Ahhh, gotcha!

Okay, so we should:

1. Update the README to note that attestation is a niche edge case, and isn't needed for 99% of use cases
2. Add that explanation above to the documentation on how attestation works. Maybe a wiki page?