The need for provenance with BYO authenticators
The alternative to BYO authenticators
There is a strong desire to allow users of two-factor authentication to “bring your own” (BYO) physical authenticator (often referred to as a “token”). This relieves the user from keeping (and keeping track of) separate physical authenticators for each service, and spreads the cost of authenticators among multiple services. It also simplifies the process of enrolling a new user in an account when a physical authenticator does not need to be conveyed (e.g., mail, in person) to that user. Bringing your own authenticator, however, adds a new element of uncertainty.
The impact of an account breach is not limited to the user: the service, and often other users, are often also impacted. The service, at a minimum, has to bear the cost of incident response, even if that only involves aid to the user. Account breaches may affect other users on the service or impact the service itself (consider industrial control systems and critical infrastructure here). It isn’t just the user that has a stake in the security of authentication.
When authenticators, particularly hardware-based physical authenticators, are issued by the service itself, the service knows all about their strength. For example, if the user is issued a one-time password (OTP) device, the service knows that the authenticator secret is embedded in hardware, what the characteristics of that hardware are, and can assess the strength of authentication accordingly.
If the user brings their own authenticator, how can the service make that determination? For many authenticator types, particularly where the strength is determined by the authenticator’s hardware characteristics, more information is needed. For example, it is generally not possible to distinguish an authentication made using a cryptographic device (e.g., smart card) from one made using a software-based cryptographic certificate. The protocols for those two authenticators can be identical.
Fortunately, some authenticators are beginning to provide assertions of their provenance along with the authentication transaction. Most notably, FIDO authenticators supply signed assertions about the type of authenticator used, assuming of course that the authenticator maintains its integrity. In practice, this information is most valuable for high assurance authenticators, and these are the ones that protect their integrity the best.
For other BYO authenticators, it’s probably safest to assume the worst: that a relatively weak authenticator is being used. For client certificate-based authentication, assume that the certificate is held in software and is not protected by a passphrase. For one-time passwords, assume that a software implementation is being used in the absence of reliable information to the contrary.
It took me a while to appreciate the value of provenance assertions; at first, I had viewed them as a DRM-like feature to allow only licensed authenticators to be used. But they have real value in establishing the strength of the authentication transaction.
Image “RSA Tokens” by Flickr user Edwin Sarmiento used under Creative Commons BY-SA 2.0 license.
Altmode 
Thanks for writing this up!
The goals of attestation makes sense to me at face value: allow the Verifier to have a high assurance about characteristics of the authenticator being used.
However, things get a lot trickier in practice. Adam Langley has a great post on Webauthnn and speaks about potential problems with attestation when serving public users: https://www.imperialviolet.org/2018/03/27/webauthn.html#attestation.
Also, what happens when one of the authenticators in the batch of 100k that use the same attestation key becomes compromised? Now, all of those devices in the same batch can be impersonated. A Verifier cannot be sure that an attestation claiming to be from that batch is genuine, so do they reject it and only accept authentication requests from devices with “known good” attestation keys to be as sure as possible that the authenticators have certain security properties? If yes, then all of the devices in that 100k batch will now be rejected.
How often this will happen depends on a bunch of factors, but it is certainly bound to happen at some point.
Thoughts?
Thanks for pointing out Adam’s post; very relevant.
In most cases, transactions performed by “the public” only require AAL2 authentication strength as defined by NIST SP 800-63B https://pages.nist.gov/800-63-3/sp800-63b.html#sec4. Provenance (attestation) gets to be important if you need to prove that an authenticator has more strength, like that it is a hardware-based authenticator (for use at AAL3) or that it is a multi-factor authenticator (using a memorized secret or biometric to unlock the authentication secret). So I agree with Adam but would state it a bit differently: ignore attestation unless you need it to establish the authenticator strength.
Attestation generally is checked when the authenticator is registered on first use with a given CSP/RP. When subsequent authentications are done, it isn’t necessary to recheck the attestation, and I don’t think the FIDO protocol even offers it then. So if an attestation certificate needs to be revoked (not sure how this works) because of a private key compromise, registered authenticators would continue to function. It’s just that authenticators from that batch wouldn’t be able to be registered at sites requiring attestation. This isn’t to say that attestation key compromise isn’t a problem, but that it’s not as serious as “100k authenticators stop working”.