In a multi-device passkey world, what can we know about a key?

Attestation, TOFU, and Provenance

intro

Here’s a code block:

 let Sig = attestationObject.attStmt.sig;
 let certInfo = attestationObject.attStmt.certInfo;
 objVerify.update(certInfo);
 let answer = objVerify.verify(objKeyInfo, Sig);

Feel smarter yet? What do we know? What is the answer?

what does authentication mean?

We’re told that authentication verifies “you are who you say you are” (as opposed to authorization that governs what you’re able to do). But authentication really verifies that you have certain credentials a particular app or website has seen before. Any translation of credentials into a person or identity is the result of a separate task not generally done on authentication – it’s done before, when the credential is created and enrolled.

multiple-choice question

Proof of possession of a key means very little unless you know something about the key

As a developer, when you receive a signed assertion, you might wonder about the status of the key used for the signature. Has it been compromised or disclosed? Is it strong and resistant to common attacks? Who are you actually communicating with?

what is attestation?

The WebAuthn spec says that “attestation is a statement serving to bear witness, confirm, or authenticate“ and that "attestation is employed to attest to the provenance of an authenticator and the data it emits” (the latter including credential key pairs and other data).

Attest means to affirm to be true or genuine. But what is provenance?.

a quick aside: the definition of provenance

For this conversation we’re going to learn a new word: provenance. Its etymology is Latin via French, or perhaps some Greek, with prefix “pro” meaning “before” (give or take), and root “venir” meaning “to come”.

So…“to come before”?

Give or take.

In its first sense, provenance is a more grandiose way of saying “source or origin”.

In its second sense, provenance means “the history of ownership of a valued object or work of art or literature”, a chain of custody for the art world.

attestation defined

So now we have it. For WebAuthn, attestation can be defined as a statement that affirms to be true or genuine the source, origin, and/or chain of custody of an authenticator and the data it emits.

It seems like a tall order. How can we know the life story of a key and therefore how to think about its assertions?

Webauthn attestation can provide the relying party with verifiable evidence as to the environment in which the credential was created and certain aspects of the credential itself including the key pair. This evidence is an attestation object, the signature within, and optionally additional metadata. It also provides a way to assert a trust level on that information via the attestation signing key and signature.

webauthn attestation in reality

There are a ton of details to WebAuthn attestation. The specs variously cover attestation type, format, conveyance preferences, attestation services implemented by various vendors, and the FIDO metadata service. A lot of that stuff still seems in flight, but here are some things to know:

1. WebAuthn attestation is PKI. Most if not every attestation I’ve seen involves an attestation statement signed by either the credential private key itself or a special attestation key. Learning how to validate this signature will help you on your attestation journey

2. Attestation is much more clearly defined for hardware based keys (security keys and platform / TPM keys) than software keys or multi-device keys. There’s an established model for attestation formats like “packed” and “TPM”, along with FIDO metadata statement lookup based on the authenticator make and model's identifier or "AAGUID". For software / app based and multi-device keys, things are still evolving.

3. This blog post will illustrate some real world attestation examples I’ve observed, and keep it as simple as possible. If interested please read on.

So like I said above, attestation statement parsing can seem like a high complexity and low payoff activity. You have to:

• choose which attestation conveyance (none, indirect/direct, enterprise) to request

• understand and implement the verification procedure(s) for the attestation format(s) you support (none/packed/tpm/etc)

• parse X509 certificates out of the attestation object

• figure out algorithms and verify signatures and chains

• verify the rest of the metadata from the authData and/or FIDO metadata statements, per the attestation format's verification procedure

All of this before you get to the part where you can actually decode cose to get the WebAuthn credential key out of a response and save it, to complete the registration.

So why do it? What does it get you?

The best answer I can give to this question is to think of it as analogous to verifying the server half of SSL/TLS. The part where you verify the server SSL certificate. That website may still be dodgy, but you’re reasonably sure it’s not fraudulent and dodgy.

a couple of real world examples

Windows Hello: attestation format ‘tpm’

Let’s take a look at registering a Windows Hello FIDO2 credential.

In this example we specify an attestation conveyance preference of ‘direct’, and we get back an attestation object with format ‘tpm’.

To find the attestation signature, we will look into the attStmt property of the attestationObject from the AuthenticatorResponse:

Attestation object showing the fmt, attStmt, and authData properties

Within this property is an object with several members, one of which is alg:

Attestation statement properties, showing the COSE algorithm identifier for RSA with SHA1 

The alg property contains the identifier of the attestation signature algorithm. Not to be confused with the credential’s algorithm, this is the algorithm of the attestation signing key, and the accompanying hash algorithm used to create the attestation signature we’ll be checking.

If we check the IANA COSEAlgorithmIdentifier list, we see that -65535 indicates “RSASSA-PKCS1-v1_5 using SHA-1”.

Note: I’m not going to cover why Windows is using SHA-1 here, as it seems to be a complicated story and would probably merit its own blog post. In short they shouldn’t be, and they probably have reasons involving legacy code and hardware compliance. Maybe I will cover that in the future. Here, I’ll simply illustrate that the algorithm affects the JavaScript code you need to use to check the signature.

Here are the relevant code snippets for checking the sha1 signature of the TPM attestation statement:

Example javascript code snippets to parse attestation object of fmt ‘tpm’

Note that the certInfo structure is a TPM specific thing as specified in webauthn and the referenced TPM document.

The above only covers the bare minimum: checking the signature itself. For more information about validating a TPM attestation statement, check out the webauthn spec section (see “Verification Procedure”) and/or this blog article.

Yubikey 5 NFC: attestation format ‘packed’

Now let’s look at a different example. This one is a security key that uses the attestation format ‘packed’.

For this authenticator and attestation type, we get the following attestation object:

Attestation statement properties, showing the COSE algorithm identifier for ECDSA with SHA256

As we can see the alg now is -7. That maps to “ECDSA w/ SHA-256”.  Good job Yubico 😊. So now we parse out the various pieces for signature verification as follows. Note that, for the ‘packed’ format, the signature is over the binary representation of the authData property, concatenated with the hash of the string representation of the clientDataJSON element of the AuthenticatorResponse.

Example javascript code snippets to parse attestation object of fmt ‘packed’

attestation format ‘none’

For attestation objects with fmt “none”, the attStmt will be an empty object. This may mean the RP did not request attestation, the authenticator cannot provide it, or otherwise “none” can be an indicator of a multi-device credential (as we saw in a previous post).

a hopefully-helpful table

I know I said I’d keep it simple and wouldn’t go into minutae of attestation, but before we move on, in the spirit of a map that shows the complexity of the terrain yet helps illuminate a way through it, I offer the following table. My intent is to illustrate, conceptually, some key attestation “types” and what that means about where to find the key to check the signature against:

Attestation type	RP request attestation conveyance preference	Resulting attestation statement fmt	Where to find the public key to check the signature
no attestation	“none”	“none”	Nowhere – there is no attestation statement therefore no attestation signature to check
self attestation	this seems to be the choice of the authenticator and not the RP	depends on the authenticator	Use the credential’s public key out of the attestation object’s authData property: attestationObject.authData.slice(55 + credentialIdLength);
all other attestation types	“indirect”, “direct”, or “enterprise”	not equal to “none”	Use the attestation key out of the first certificate located in the attestation object’s attStmt.x5c property: attestationObject.attStmt.x5c[0]

The above was time consuming, and all we did was verify a signature. If you made it this far, bravo!

Now let’s look more comprehensively at what we might want to know, ask or query about a credential.

what do we want to know about a credential?

Once an authentication key is created and enrolled, there are a bunch of things that could influence the veracity of future authentications. If we’re going to ask for info about a cred or key, what makes sense to ask about and what can we actually know?

What attestation covers

As we’ve seen above, there are aspects of key origin and provenance that can be gleaned well from WebAuthn authenticator attestation responses, at least for hardware keys.

key type

Was the credential key an RSA key, an ECC/ECDSA key, or something else? Does it use the current recommended key lengths? What about the attestation key and chain? The attestation response itself contains this information.

where the (hardware) key was generated

What type of environment was the key was generated in? Was it a physical security key, a computer, or a mobile device? Was the key created in a secure hardware element? In software? For hardware keys, the attestation statement provides this information via signed object and metadata.

what attestation misses

I’ve shown above how attestation creates evidence of what type of device a key was generated on, especially if that device was specialized hardware such as a security key, TPM, or platform secure element. Beyond this, there are variables that significantly affect key / authentication trust but that are not covered by attestation.

conditions of enrollment (and/or recovery)

As I mentioned in the factors we choose, not all sign in factors are equal, and that applies to enrollment factors as well. So it makes sense to ask what were the type(s) of factor(s) and evidence required as a condition of enrollment or to recover a lost key.  Was the key created and enrolled with no evidence (aka “trust on first use” or TOFU) or with additional evidence factors such as previous credentials or identity documents?

environment for software keys

While attestation objects and statements can specify well defined and understood hardware environments, keys created and maintained in software, such as in a browser or in an app, are subject to many more variable environmental factors, Things that vary across time include: Is the device platform and software up to date with security updates? Has it been jailbroken? What type(s) of application(s) are running? What type(s) of endpoint protection tools? There is a seemingly endless list of questions to ask to assess software environment safety and trust.

what has happened since enrollment

Passkeys are copy-able, and once a key is copied to a different device, promises made on the original attestation / provenance statement are void.

So another good question is what may or may not have happened to the key since enrollment? Is the key exportable from its platform? Is it part of an ecosystem that will copy it? Was it indeed exported or copied? Where is the credential information stored and maintained? Is it in a database, file, or public key certificate chain, and how is it protected? What is the access control and/or data protection? Has there been a relevant data breach of either private key information or public key to identity mapping?

attestation alternative: TOFU + continuous risk assessment

Trust is built over time. As a person or entity’s behavior is observed, patterns emerge that become increasingly intricate with more data, and risk assessments based on this behavior improve. In this way, the credentials accrete value with continued successful use.

Continuous risk assessment over the session has become a basic requirement for modern authentication. This principle applies to the credential lifecycle as well.

As an alternative or complement to WebAuthn attestation, continuous risk based assessment that looks at credential status w/r/t the questions above, on attested or un-attested keys, can provide good ongoing assurance of credential trust.

what’s next

there will be even more keys

One result of risk concerns about copyable keys will be: you guessed it, more keys.

The device public key or DPK protocol extension is in draft mode and specifies that a multi device WebAuthn credential can be supplemented with one or more device specific credentials upon request by the relying party. The device keys cannot be used on their own.  They provide additional risk mitigation information, as assertions signed by the device keys will supplement normal webauthn signed assertions via an extension to the protocol. The new keys can be enrolled based on possession of a user-level key, or can require more factors. This is up to the relying party.

more keys -> more attestation

The enrollment of more keys invites of course more attestation. DPK keys are device specific, which makes them somewhat of a natural fit for attestation. Within the DPK extension “attestation on device key enrollment” can provide attestation information about the device key itself.

Separately and also in draft mode is a generic ability to request attestation on WebAuthn get() calls rather than just on Create(). This is irrespective of DPK extension use and will provide another source of ongoing / continuous risk signals for sign on.

attestation adoption will follow the pattern of PKI

I expect that DoD’s and other government agencies will implement/deploy WebAuthn’s attestation specifications fully, though it will take some time.  I’d guess that other / regulated industries such as banks and healthcare organizations will do a combination: support the minimum (perhaps signature validation only and/or FIDO metadata existence check) but combine attestation with their own industry specific validation tools and algorithms. Other organizations and relying parties will either support the minimum or ignore attestation entirely (send conveyance preference ‘none’) and replace any attestation information with a policy of TOFU combined with a risk assessment engine they can query dynamically.

TOFU models combined with continuous risk assessment

Trust-on-first-use and multi-device keys (often in software) adopted for consumer scenarios and less regulated industries will enable their customers to enjoy the relative ease of use of these keys.

The WebAuthn attestation approach is heavy handed for these scenarios. A better and cheaper way will be for relying parties to focus energies on the ongoing health of their users’ sign on context.  My hope is that sign on risk assessment APIs and services that already exist will continue to evolve and remain open to third parties. I don’t know much about these services yet (as perhaps evidenced by the quality of those links), but I look forward to learning. If they do it well, this ecosystem can enable credential risk to become part of the authentication context while protecting anonymity and privacy.

conclusion

WebAuthn’s attestation model is a complex beast. The essentials of it are useful for developers and relying parties to know about. The rest will be good for governments and similar organizations. There are many relevant questions about key trust that cannot be answered by attestation, either because the keys are in software, the questions require more context, or both. Continuous risk assessment APIs and services will be more helpful for these questions.