search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.19k stars 172 forks source link

Support for FIDO passkey with HMAC-Secret extension #1830

Closed Sebastian-Elfors-IDnow closed 1 year ago

Sebastian-Elfors-IDnow commented 1 year ago

Description

Currently, the HMAC-Secret extension is specified in the CTAP2 specification. Hence, the HMAC-Secret extension use case is limited to FIDO2 credentials on external hardware authenticators that can be accessed with native applications over CTAP2. This allows for an external hardware FIDO authenticator to generate HMAC-Secrets, which can be used as AES-keys for encryption/decryption, at multiple devices.

However, with the introduction of FIDO passkey (aka Multi-Device Credentials), the FIDO2 credentials can be roamed to multiple devices. In this scenario, it could be interesting to generate FIDO passkey with support for the HMAC-Secret extension. The use case for FIDO passkey with HMAC-Secret extension could be the following:

  1. At device A, create a FIDO passkey with the HMAC-Secret extension.
  2. At device A, use the FIDO passkey with the HMAC-Secret extension to generate an AES-key, which is used for encrypting data.
  3. Back up the encrypted sensitive data to a server.
  4. At device B, roam the FIDO passkey with the HMAC-Secret extension.
  5. At device B, download the encrypted data.
  6. At device B, use the FIDO passkey with the HMAC-Secret extension to generate the AES-key, which is used for decrypting the encrypted data.

This could be used for backup and restore of sensitive data between different devices, which could be useful for digital wallets.

So, here are the questions related to this feature request:

  1. Could FIDO passkey credentials support the HMAC-Secret extension (without the need for CTAP2)?
  2. Could the proposed WebAuthn L3 PRF-extension function be able to generate PRF values using FIDO passkey credentials with the HMAC-Secret extension?
  3. Can the output PRF values be used as AES-256 keys for encrypting/decrypting opaque data?

Related Links

emlun commented 1 year ago
  1. Could FIDO passkey credentials support the HMAC-Secret extension (without the need for CTAP2)?

Yes, they could implement a feature that is API-compatible with HMAC-Secret.

  1. Could the proposed WebAuthn L3 PRF-extension function be able to generate PRF values using FIDO passkey credentials with the HMAC-Secret extension?

Yes, this is one of the intended use cases of the PRF extension.

  1. Can the output PRF values be used as AES-256 keys for encrypting/decrypting opaque data?

Yes, although depending on application you might want to pass the PRF output through a key derivation function (KDF) first, rather than use the raw PRF outputs directly.

Sebastian-Elfors-IDnow commented 1 year ago

Hi Emil,

Thanks for your answers!

“Yes, although depending on application you might want to pass the PRF output through a key derivation function (KDF) first, rather than use the raw PRF outputs directly.”

Good point. For example, how about using PBKDF2 with the PRF output as salt in conjunction with the user’s password?

One more question: Is the proposed WebAuthn L3 PRF-extensionhttps://w3c.github.io/webauthn/#prf-extension function intended to be called from a native app at the device? In other words, will it be possible to generate the PRF output in a local environment, without the involvement of an external RP?

Kind regards, Sebastian

emlun commented 1 year ago

how about using PBKDF2 with the PRF output as salt in conjunction with the user’s password?

I can't give a generic recommendation (nor should the spec, I think) since it'll depend greatly on the application (and since I'm personally not an expert on concerns like this; using a KDF is a pattern I've observed, but I don't know all the nuances around it). But PBKDF2 seems probably fine to me.

Is the proposed WebAuthn L3 PRF-extensionhttps://w3c.github.io/webauthn/#prf-extension function intended to be called from a native app at the device?

Native app APIs are strictly speaking not governed by the WebAuthn spec, so I'll have to pass that question on to platform vendors such as @akshayku, @christiaanbrand, @alanwaketan.

But yes, in a browser that supports the PRF extension you certainly could invoke the extension without involving a remote server. Likewise a client application with access to CTAP2 could implement the same abstractions on top of HMAC-Secret to generate the same outputs as a web version of the app would get from the PRF extension, also without need for a remote server.

Firstyear commented 1 year ago

Yes, this is one of the intended use cases of the PRF extension.

do any browsers support it today?

emlun commented 1 year ago

Not that I know of. There might be early prototypes, but at least the Chromium platform status page still lists the feature as "on hold". @agl or @nsatragno might know more.

agl commented 1 year ago

do any browsers support it today?

The CTAP2 support exists in Chromium, but it's not wired up in Blink. It is not currently an active effort but we're interested in reports from sites that would like to use it as we continually evaluate what areas to work on.

FlxMgdnz commented 1 year ago

We are frequently contacted by folks looking at passkeys for their e2e encryption use cases (native and web apps), which currently require users to come up with and remember their passwords/passphrases. So from our point of view, this is a real problem that I'd love to see solved by passkeys.

Progdrasil commented 1 year ago

To give a concrete example to @FlxMgdnz’s point, while password managers can support passkeys as an authenticator/vault, we at 1Password cannot begin thinking about dropping the Account Password in favor of unlocking using passkeys without wider implementations of the hmac-secret/prf extensions. Those secrets are what could enable us to decrypt the data within the local clients.

Firstyear commented 1 year ago

Within Kanidm and our use cases we'd like to use hmac-secret/prf for user vault unlocking in enterprise contexts, so we'd be very interested in this. Additionally, I'm sure that users of the webauthn-rs library in the broader rust community would also be interested in this capability.

irew commented 1 year ago

Same here for Dashlane, wider support for this extension could be really helpful.

arianvp commented 1 year ago

The systemd project uses HMAC-Secret extension of CTAP for LUKS device unlocking and we have some interest in exploring adding support for Passkeys for unlocking disks using the hybrid transport.

maccman commented 1 year ago

We at Reflect (https://reflect.app) would be super interested in the prf extension for our end-to-end encryption.

agl commented 1 year ago

We at Reflect (https://reflect.app/) would be super interested in the prf extension for our end-to-end encryption.

Try Chrome Canary with chrome://flags/#enable-experimental-web-platform-features set. Note that Windows will require that you create a discoverable credential in order for the PRF extension to work.

arianvp commented 1 year ago

@agl I'm trying to try this out on Chrome Canary on Android with your instructions; but it seems that when you try to create a discoverable credential it will always now show the "Passkey" UI and give no option to select a security key anymore. It only gives you the option to select a security key when you set discoverable credential to "discouraged". Is this some regression? Given i want to create a credential with PRF extension on my Yubikey (as that one actually supports the extension unlike Google's Passkeys) it seems this currently isn't possible anymore in Chrome. And if I recall correctly prf is only allowed on discoverable credentials right?

agl commented 1 year ago

but it seems that when you try to create a discoverable credential it will always now show the "Passkey" UI and give no option to select a security key anymore.

prf isn't specific to discoverable credentials. Windows currently only supports it for discoverable credentials, however, so you'll need to use discoverable credentials to use prf with security keys on that platform.

You didn't say which OS you're working with, so I'll try to give generic hints, but you should be able to use security keys for WebAuthn operations. Are you sure that you aren't setting authenticatorAttachment=platform? Setting it to nothing should allow security keys and setting it to cross-platform should hint towards security keys.

agl commented 1 year ago

Oh, I'm sorry, you clearly said “Chrome Canary on Android”. I'm afraid that Android currently doesn't support CTAP2 so cannot create discoverable credentials on security keys. That's why it'll only offer the platform authenticator if you request them. CTAP2 support for Android is coming in the hopefully not too distant future, although wiring up prf support on Android will involve additional work on top of that.

arianvp commented 1 year ago

Ah that makes sense. Thank you so much. I'll give it a shot on MacOS instead and report back if I run into issues! (But I expect it to just work)

Progdrasil commented 1 year ago

Given the interest in the issue, I was surprised to see it get closed. Could we have an explanation as to the reasoning?

MasterKale commented 1 year ago

hmac-secret will become available in WebAuthn via the new prf extension as currently defined in the draft of L3:

https://w3c.github.io/webauthn/#prf-extension

And in fact, as @agl mentioned above, the prf extension works in Chrome Canary so we can now say too that "platforms are starting to implement support."

As such there wasn't much reason to keep this issue open. prf will continue to get iterated on but that can happen independent of this issue.

akshayku commented 1 year ago

Given the interest in the issue, I was surprised to see it get closed. Could we have an explanation as to the reasoning?

There are some refinements happening to "prf" in #1836, but to the overall question of support of hmac-secret extension in this issue, from the spec perspective, we already have that in the spec in the form of "prf".

ragnarbull commented 1 year ago

Digging this back up... can anyone comment - is the hmac-secret / prf extension currently only supported for YubiKeys?

@agl does Google have a timeline for adding the prf extension to Android? Anyone know about Apple and Microsoft with FaceID/Windows Hello?

Like many, I would love to see this so a user can decrypt their vault (ie. a mobile/web E2EE app) using any of their saved passkeys - not just a hardware security key or a password.

agl commented 1 year ago

is the hmac-secret / prf extension currently only supported for YubiKeys?

Many FIDO2-capable security keys support hmac-secret.

@agl does Google have a timeline for adding the prf extension to Android?

Passkeys stored in Google Password Manager (i.e. all passkeys on an Android device prior to Android 13) have supported PRF for some time.

ragnarbull commented 1 year ago

@agl thank you! I didn't realise this worked with Google like you said that's awesome. Anyone who comes across this, you can test the prf compatability here: https://sneakernetsend.com/ from @MasterKale (Oct '23: works for YubiKey and Android passkeys on Chrome and Edge with Windows OS. Windows Hello not yet working.