Open in app

Sign in

Write

Sign in

WebAuthn/FIDO2: Demystifying attestation and MDS

Ackermann Yuriy
WebAuthn Works
Published in
9 min readMay 24, 2021

--

This is continuation of our series on Webauthn and FIDO2.

The fancies of wine are authentic events
- Italo Svevo

There is no doubt that attestation is a misunderstood and sometimes controversial topic. I’ve been personally present at a few heated discussions, that some might mistaken for an upcoming fight scene, and thought that it might be the time to call the police. Gladly no police were involved and we would leave to a pub to change the topic and discuss life, hobbies, travel and family.

Attestation is one of the most important and in the same time useless mechanism… for majority of the people. Most that work with FIDO protocols rarely deal with it, and little information is published in a plain english, outside of the white-papers and critical pieces, so this article is here to fill that gap.

Table of contents

What is attestation?

Attestation is a FIDO protocols mechanism that identifies device model. It is a core part of all, FIDO2, U2F and UAF protocols. This mechanism provides ability to the relying parties, aka websites, to… well… identify device model. Pardon me for my blunt tautology.

The way this is generally works, is by the magic of PKI. Device has attestation batch certificate and private key. During the production of the keys, manufacturer generates one batch certificate and private key per 100,000 devices, and signs them with the manufacturer root certificate. That is done to reduce potential for tracking, as relying party has 1/100,000 chance to know that Bob with this security key, is actually Alice in disguise.

Why is this important? Well, if you are a bank, federal agency, department of defence, you have legal obligations under various certifications, that you legally required to obtain, to follow some policy and/or security guidelines. Most of these policies/guidelines in these sectors require for you to use certified cryptographic devices. Smartcards, crypto-tokes, FIDO security keys, are all to be FIPS certified for US federal agencies under the NIST AAL requirements, and Common Criterial for European agencies. Russia, Ukraine, Israel, China are all having similar requirements. Banking sector might want to have high assurance and need to ensure that they use genuine devices. All that is not possible without attestation.

And now a clear message for ninety-nine percent of the relying parties:

Most likely you do not need attestation

Here are four reason why you do not need attestation:

  1. Attestation is bad for user experience. — Attestation requires explicit user consent:

Considering constant bombardment with popups from everyone for notification, audio, video, camera, etc. etc. etc. and long growing distrust and raising privacy concerns, attestation will ruin your perfect authentication flows.

2. Privacy is not perfect— Attestation has privacy concerns. Even with 1/100,000 batch rules, on the scale, together with hundreds of other tracking parameters, this could become another data pointer.

3. Codebase management — To be fully FIDO certified you need to support packed, u2f, safety-net, tpm and apple attestations. This all means that you need to manage three to five thousands of lines of the code. Test it. Maintain it. Keep an expert that understands quiet complex code. If you want a taste of what you are going to manage, take a quick look through my “Verifying TPM2.0 attestation” article.

FIDO certification mandates correct support of those attestations, but not actually utilizing them, so just stick to the by-default “none” attestation behaviour.

4. Attestation is hard —Supporting attestation, is like being a professional Pokemon trainer. For each brand you need one, or more attestation root certificates. And they are not exactly public, so you need to contact as many manufacturers as you can. Get through their tech support. Win the battles with the legal teams. (̶̶̶U̶̶̶n̶̶̶l̶̶̶e̶̶̶s̶̶̶s̶̶̶ ̶̶̶y̶̶̶o̶̶̶u̶̶̶ ̶̶̶j̶̶̶u̶̶̶s̶̶̶t̶̶̶ ̶̶̶d̶̶̶o̶̶̶ ̶̶̶l̶̶̶i̶̶̶k̶̶̶e̶̶̶ ̶̶̶A̶̶̶W̶̶̶S̶̶̶,̶̶̶ ̶̶̶a̶̶̶n̶̶̶d̶̶̶ ̶̶̶o̶̶̶n̶̶̶l̶̶̶y̶̶̶ ̶̶̶a̶̶̶l̶̶̶l̶̶̶o̶̶̶w̶̶̶ ̶̶̶s̶̶̶e̶̶̶c̶̶̶u̶̶̶r̶̶̶i̶̶̶t̶̶̶y̶̶̶ ̶̶̶k̶̶̶e̶̶̶y̶̶̶s̶̶̶ ̶̶̶f̶̶̶r̶̶̶o̶̶̶m̶̶̶ ̶̶̶o̶̶̶n̶̶̶e̶̶̶ ̶̶̶m̶a̶n̶u̶f̶a̶c̶t̶u̶r̶e̶r̶)̶̶̶

And after all of that you need to keep them up to date when the new models are out, and keep an eye on security issues. Basically: GOTTA COLLECT THEM ALL, but while watching infamous Pokemon Ranger And The Temple Of The Sea.

So if you have survived all of that and have not turned around yet, then I must say that you are still wrong, and I am telling you that you do not need attestation…

…Unless you actually do need it a lot

So there are four reasons why you actually need attestation:

  • You are a bank or fintech
  • You are a government agency
  • You are a journalist, or a researcher for big pharma, aka big potential target
  • Someone cursed you to implement BSI requirements

In these cases, yes, you do need attestation, but which attestation and how might be a million dollar question, if you don’t do things correctly.

First: What attestation actually delivers?

The question that you need to ask your self: Why do you even need to know device model? Every answer you get, legal, compliance, security, is actually about one, and one only thing: assurance. You need to be sure that device that you are using will be too expensive to clone or hack. Attestation gives you provable knowledge that you can then use to asses the level of assurance that device can claim, and from there on make informed decisions based on that.

Second: Hardware Security Keys vs Mobile vs Platform authenticators

Each class of authenticators delivers different set of assurance criteria and different set of the features. Here are few key things about each class

Security Keys

Hardware devices. Think of Yubikey, Feitian, Trustkey etc. As a general rule, hardware backed cryptography with high quality certified chip from NXP, Thales, Infineon, etc. Security keys only support standard manufacturer attestation, and so their attestation is guaranteed by the manufacturer. If you buy security keys from trusted manufacturers, then since you trust manufacturer, you will trust the claims stated by manufacturers, and so by validating device attestation, you will trust that device is genuine.

Since hardware security keys are hardware, they can achieve high levels of certifications, like FIDO L2 and L3, FIPS140–2 and Common Criteria, which is really important for government and defence deployments. Hardware Security Keys as well are really important for highly vulnerable industries like journalism and R&D.

Mobile authenticators

Mobile authenticators as a rule can not have manufacturer attestation, because application developer does not control where the app is running, and so distributing the application as a compiled binary like APK/IPA, directly or via app stores. This means that potential attacker may simply disassemble the app, and extract private key from the package.

This does not mean that mobile apps can not provide any assurance. Today iOS and Android ecosystems have tools and mechanisms that we can use to get that assurance:

iOS

  • DeviceCheck — Is a device attestation that gives you assurance that device is genuinely an Apple device, and not some emulator. Documentation
  • AppAttest — Is an app attestation that provides you some assurance that application is genuinely signed by you and was not modified by an attacker. This means that if someone steals your app, and re-signs it, they would fail your app attest check. Documentation
  • Hardware backed crypto — This one you can generally be assured about, since the only currently supported models of apple devices are all have Apple T1/T2 chip for their Apple pay.

Android

  • SafetyNet Attestation — SafetyNet similar to iOS AppAttest. It’s a big-data analyzing shenanigan that is a part of every single Google backed phone. The SafetyNet will validate the state of the device, and the state of the app, and return you signed by Google attestation that contains information such as: Was your app modified? Was device rooted? Any malware? If you want to learn more, I suggest watching “34C3 — Inside Android’s SafetyNet Attestation: Attack and Defense”
  • Keystore Attestation — Android does not have such a consistent ecosystem, since there are hundreds of manufacturers of Android devices. To figure out the security of the Keystore(where your private keys are stored), you can call special Keystore Attestation during the generation of the private key and it will tell what kind of hardware or software backing you have. Based on that information you can trust less or more depending on the result. You, as a bank, may limit transaction size if device is a cheap Android 6 with software backed crypto, but allow larger transactions if you have Pixel 5 with Android 11 and hardware backed crypto. NTT Docomo and Noknok Labs have published a really good paper on deployments using Keystore Attestation

Mobile authenticators are the best for banking and controlled MFA deployments, and is highly popular in enterprise. They are really flexible and provide great level of control and deployment.

Platform authenticators

Every modern Android, iOS, MacOS, and Windows 10 device today supports FIDO in the core. Basically it’s an OS included authenticator. They all have different attestations and so different assurance:

  • Android—Android uses SafetyNet attestation. As I explained in the mobile section, safetynet provides assurance that device was not rooted, and that not malware is running on the device.
  • iOS /MacOS— Apple Anonymous Attestation. It’s a fairly standard anonymised CA attestation. It provides you with assurance that authenticator is runs genuinely on the Apple device.
  • Windows — TPM and SELF. Windows when available uses TPM(Trusted Platform Module) for key generation and management. TPM has another cool feature of supporting Attestation CA, which basically means that TPM generates unique attestation for each registration request via manufacturer CA, which issues attestation proof for the genuine TPM. This provides assurance that you have good, hardware backed crypto. When there is no TPM available, it uses software backed crypto, and SELF attestation, which is when response is just signed by the freshly generated private key.

Platform authenticators enable normal users to have access to secure, passwordless authentication. Most of the time platform authenticators provide adequate assurance that can be used in many scenarios. Platform authenticators are really popular in consumer deployment due to universal accessibility, and good user experience.

Third: Metadata and MDS

Searching for authenticator security properties via many long email threads would be detrimental to the health of anyone involved, so FIDO has created two very useful tools: Metadata and Metadata Service aka MDS.

Metadata or Metadata Statement — Is a structured JSON object that provides information about authenticator security and authenticator features. Things that relying party might want to know: What is the name of the authenticator? What authentication algorithms authenticator supports? What user verification methods(fingerpring/pin/face etc) can user perform? Are key hardware backed? etc. You can find sample metadata here.

Metadata Service aka MDS —Is basically a service that stores all of the metadata in one place. MDS provides automated and secure way for relying parties to acquire up-to-date metadata. MDS as well provides information about certification and security issues, so relying parties can keep track of known vulnerabilities and act accordingly, and use certification information to filter out authenticators based on required level of certification.

Fourth: Enterprise attestation — smart cards with FIDO flavour.

In FIDO2.1 new type of attestation was added, called Enterprise Attestation. The idea is that in some deployments you need to have tighter control over the devices that are entering your inventory. Maybe you have complete ban on the BYOD, but you can not afford to manually enroll every single user. In that case with FIDO2.1 you can request manufacturer to produce special set of device with included your own enterprise attestation that will only be accessible for a very limited list of domains.

For example: Company requests that manufacturer produces device with attestation set to their own certificate, that is accessible from “login.contoso.local” and “restricted.bigproject.com”. This allows complex enterprise deployments while restricting sites from enterprise attestation it for tracking.

In conclusion

Attestation is an important mechanism for enterprise and controlled deployments. It provides relying parties effective tools to manage inventory and ensuring that adequate level of assurance security is preserved.

In the same time it is need to be carefully considered as it has adverse affect on user experience and privacy. Cloudflare’s CAPTCHA replacement is a great example how not to use attestation. Use attestation when it is absolutely certainly necessary and avoid it in every other case, or in ninety-nine percent of situations.

Our blog on correct usage and processing of MDS and Metadata coming soon, together with our migration guide from MDS2 to MDS3.

Resources

License

This article is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0). So you are free to read, share, etc. If you are interested in commercial use of this article, or wish to translate it to a different language, please contact us at info(at)webauthn(dot)works

The code samples are licensed under MIT license.

Fido2
Webauthn
Fido2 Security Key
Attestation
Pki

--

--

Ackermann Yuriy
WebAuthn Works

Written by Ackermann Yuriy

513 Followers

FIDO, Identity, Standards

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams