Re: [webauthn] Backup state of credentials (#1692)

> a) key/credential being generated in a very secure authenticator (e.g. secure element level key protection). Registration assertion truthfully reports multi-device capable, not backed up.

My feeling is that an authenticator is defined today effectively as "abstract thing that performs user presence and verification, and registers, asserts, and protects its public keys". There's nothing about the authenticator being a single device, being hardware or software, or whether it stores into a TPM-protected storage or into a GitHub gist.

The concept of a device is being added, and extensions are being added to give multi-device authenticators additional capabilities specifically because otherwise, relying party policies will reject their use.

An attestation continues to infer such implementation details to policy. How one receives access to private keys, via sync fabric of approved TPMs or a PIN-protected file or a CSV would be part of those details. The weakest security link drags everything down - if it is possible to recover into an arbitrary authenticator, that greatly decreases the trustworthiness of the original registered credential.

That is why there is a device public key extension proposed, which will give a device attestation on registration and on use. This effectively allows one to make judgements both based on the details of the device and on the original backup/restore capabilities.

> e) attacker performs authentication and authentication assertion maliciously reports "not backed up" (and potentially even "single device". Since the attacker has access to private key in the clear, any extension/authenticator flags could be generated and signed.

If anything, it sounds like we need to make it clearer that these flags on their own do not imply some security policy is met, just as UP and UV on their own make no guarantee that the user is present or verified.

But in addition - the backed-up flag is not meant for security use in general - it is meant to drive user experience for relying parties which want to eliminate passwords, but need a durable credential by which to replace them.

> (i) to have the option to request attestation and to have a description in the related MetadataStatement whether this authenticator supports multi-device keys in general or not

The device public key  extension has an attestation on use, which presumably would let a relying party know that an unapproved implementation has gained control of the private key and is attempting to use it. Depending on the policy this might cause this one authentication request to be rejected, additional user challenges to be made, or the public key credential itself marked as no longer trusted.

-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1692#issuecomment-1044337952 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 18 February 2022 10:59:09 UTC