Intent to Prototype: WebAuthn devicePubKey extension support

[Adam Langley]

Contact emails

a...@chromium.org

Specification

https://github.com/w3c/webauthn/pull/1663

Summary

The devicePubKey extension to WebAuthn permits a multi-device credential to also have a device-bound key. This allows sites to incorporate device identity information into risk analysis during sign-in. For example, a multi-device credential that is being presented from an unexpected geography might be able to skip additional authenticator challenges if the specific device is already known. Devices create local keys on demand and sign the same data as with the primary private key. No cross-credential tracking is possible as the additional device-bound keys are always specific to a single credential.

We wish to prototype an implementation in Chromium so that other members of the WebAuthn WG can test some interoperable implementations and build confidence that all the parts hang together correctly.

Blink component

Blink

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals: at least one security key vendor wishes to experiment with a Chromium implementation.

WebView application risks

WebAuthn is not exposed in WebView and so this change won't be visible there.

Debuggability

If this extension moved to a full implementation, we would likely expose it via the existing virtual authenticator support in Chromium. There it can be used with WebDriver-based tests and for manual testing via DevTools.

Is this feature fully tested by web-platform-tests?

Not yet—spec still changing.

Flag name

chrome://flags/#enable-experimental-web-platform-features

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5011158688333824

[Yifan Luo]

Hey! 

I'm taking a look at this feature as a security reviewer and I'm a bit lack of the background information of it. 

Would you mind adding some explainer/design doc for it? It would be great if you could also fill in a security-privacy-questionnaire for the feature.

Thanks a lot!

Yifan Luo

[Adam Langley]

On Tue, Aug 30, 2022 at 1:58 AM Yifan Luo <l...@google.com> wrote:

Hey! 

I'm taking a look at this feature as a security reviewer and I'm a bit lack of the background information of it. 

Would you mind adding some explainer/design doc for it? It would be great if you could also fill in a security-privacy-questionnaire for the feature.

 Hi there!

Yea, https://github.com/w3c/webauthn/pull/1663 is getting pretty long and large. Let me try and write an explainer here (and maybe this should go in the WebAuthn set of explainers):

WebAuthn today is all about hardware binding: whether you use a security key or the TPM in a laptop, the private key is created in secure hardware and never leaves. A credential is one-to-one with a physical device. (And we generally call these devices "authenticators".)

But since devices break and get lost, this means that we have to tell people that they need to register a backup authenticator and both a) keep it in a fire safe at all times, and b) make sure it's registered on all the sites they use. That's a logistical problem for users, a cost problem, and a bit of a contradiction. So while WebAuthn works great in an enterprise context, where there's a helpdesk to handle the edge cases, WebAuthn is very limited in the degree to which it can be broadly used. But that's bad! Nobody likes passwords.

So, across multiple platforms, we're building "passkeys". These are WebAuthn credentials that are synced and which can be restored after device loss. If you install the iOS 16 beta today, it'll create WebAuthn credentials that are saved in iCloud Keychain. If you can recover the iCloud Keychain contents then you can recover the passkeys, same as recovering passwords. You can also use the phone, with Bluetooth for proximity checks, and send a signature to e.g. Chrome running on Windows—so the phone serves like a security key too.

But for modern sites, sign-in is a risk-analysis question. And that risk analysis continues after sign-in and considers the actions that are being taken on the account. By syncing passkeys we've enabled their use broadly, but most of the time users will be using the same devices. The device-bound key extension tries to meet both sets of needs by adding a second signature when a synced WebAuthn credential is used. This second signature is from a device-bound key that's generated on demand when sites request it. So when a sign-in comes from an odd location (for that user) a site will be able to see that the second signature is from a device that the user has used before and be mollified. (Or perhaps it'll see no such signature and so present additional challenges.)

The device-bound keys are always per-passkey, so no cross-account correlation is possible.

In practice, this change in Chromium consists of the ability for sites to request this feature, which is expressed as an extension in the WebAuthn request, and the plumbing for Chromium to convey that back and forth from the authenticator. Apart from the Web API fields in the request, everything is encoded in the CTAP2-subset of CBOR (as is standard in WebAuthn). Chromium will end up parsing this from the authenticators that the user chooses to use, but they are known to be physically proximal and Chromium is already parsing CBOR from such authenticators.

Cheers

AGL