Details on Google's implementation of passkeys

[Adam Langley]

We were excited to see Apple's passkey announcements at WWDC last
week. They have prompted several questions about the technical details
around what Google [demoed at
I/O](https://www.youtube.com/watch?v=xghjqgj4peA#t=9m00s) earlier this
year, and whether there are differences with Apple’s implementation.
This note is intended to help answer some of those questions:

Neither Android nor Chrome OS currently support discoverable
credentials. When we launch passkey support for Android, discoverable
credentials will be supported and discoverable credentials will be
passkeys: synced to the user's account. But non-discoverable
credentials will remain untouched. When a non-discoverable credential
is created it will continue to be hardware bound, and a SafetyNet
attestation will continue to be returned.

Unless credentials are currently being created on Android that set
residentKey=preferred then the introduction of passkey support is not
expected to have any immediate impact for existing applications(*).

Passkey support on Chrome OS will come after Android but our current
thinking is that it will use the same pattern for deployment:
non-discoverable credentials are bound to the ChromeOS device,
discoverable credentials are synced to the user's account.

Android & Chrome OS will sync passkeys with the user’s account and
creating a passkey will require syncing to be enabled. We do not
currently have plans to sync passkeys to other platforms.

Passkeys on Android will not initially have any attestation. If we add
an attestation in the future it will be in a new format that is common
across different Google products. The attestation for non-discoverable
credentials will likely transition to this new format in the future.

When we launch passkey support on Android we will concurrently launch
support for the [device public-key
extension](https://github.com/w3c/webauthn/pull/1663). This extension
associates a second private key with a credential and that private key
never leaves the device. This provides a device bound signal for risk
analysis. We believe that most sites should not use this extension,
but we understand that in some contexts the additional signal is
valuable.

We do not currently plan to support any form of passkey sharing in the
initial Android launch. Sharing needs to be carefully considered but
we recognise the need for users to move between ecosystems. As noted
above, we will support the device public-key extension to provide a
risk signal.

Auto-fill integration with passkeys is currently behind a flag in
Chrome on some platforms, and we demoed it at the RSA Conference last
week. The Web API for that integration differs from what Apple has
shipped in macOS and iOS betas but that will be resolved when Chrome
updates to reflect the [current
specification](https://github.com/w3c/webauthn/pull/1576). The
specification is still a draft and may change between now and public
availability.


(*) Android apps (not websites) that aren’t following the spec and
which are setting residentKey=required without also setting
requireResidentKey=true will also be affected. This combination of
options should be rejected but, due to a bug, is not.

---
Adam Langley
Principal Software Engineer
Google LLC

[Philipp Junghannß]

will with all of this also CTAP2 maybe be supported on android (and if not already, chrome OS)?

because frankly, I am not sure how secure that syncing and all goes especially when it's stored in a centralized account at some provider, how that is going to be secured, are we falling back to a password (which kinda upends the entire passwordless idea) or is an existing device needed for syncing (which obviously creates its own set of issues).

I personally would not like to trust such a thing especially when originally the idea of on-device credentials is, that they are supposed to NOT be able to be exported and for that guarded by the secure enclave, TPM, or something similar on any given device. And with that being eroded, I honestly would like to just use my FIDO2 devices, as I trust them generally more than both my phone and some company like google apple or microsoft, getting access to HUGE swaths of accounts is just a big no for me, and likely many others too.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAL9PXLyy%2BAWyF76S9puw3TsQB8bTbj87PjG%3DAti3vyULzv7wvQ%40mail.gmail.com.

[Adam Langley]

On Mon, Jun 13, 2022 at 1:49 PM Philipp Junghannß <teamhyd...@gmail.com> wrote:

will with all of this also CTAP2 maybe be supported on android (and if not already, chrome OS)?

We want security keys to serve for users with specific security or compliance needs, or for those who just want to use them.

CTAP2 security keys are fully supported on Chrome OS. Support on Android is desired, but I'm afraid that I don't have a specific timeline that I can share.

Cheers

AGL

[Michael Peng]

I had some questions regarding the attestation specifically -- it seems that passkeys both on Apple and Google will lack an attestation. In that case, I'm somewhat confused on how registration would work.

Without an attestation, how would a relying party validate the registration of an authenticator? It sounds like this also applies to client-side discoverable credentials, also about which I have admittedly limited knowledge, so it seems like I might be missing something when it comes to how passkeys and client-side discoverable credentials work.

My understanding was that passkeys and client-side discoverable credentials would both pass on an attestation during registration, then during verification on any passkey-associated device, the passkey would be retrievable using the same credentialId observed during enrollment. Is this not the case?

[Tim Cappalli]

Attestation is optional. Not all authenticators provide them.

 

From the WebAuthn perspective, there is no difference between a discoverable credential in a pre-passkey world and a "passkey" (aka multi-device passkey, aka multi-device credential). "passkey" is just an end user friendly term for a WebAuthn or FIDO credential, e.g. the thing that replaces a "password".

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/f60dd3e7-2337-4f10-b49f-315e4bb665d6n%40fidoalliance.org.

[Michael Peng]

Gotcha, essentially a passkey is a client-side discoverable credential that happens to be (possibly) made available also on other devices through some vendor framework.

I understand that attestations are optional, so there's no guarantee that RPs would be able to receive one. That being said, currently RPs are able to request attestations in order to validate credentials and glean information such as AAGUIDs to understand the make/model (example use case: enterprise customer wants to understand what authenticator a user is being used because of a security policy).

Actually, as I type this out, I'm realizing I might have a fundamental misunderstanding here. I left the above intact in case I've made a mistake anywhere, but basically:

• When we talk about optional attestation, we're talking about optional attStmts
• The authenticator necessarily must still pass an attestationObject, containing authData
• Therefore RPs, even without an attestation statement, would still be able to enroll credentials and have access e.g. to AAGUIDs; RPs would just not be able to validate the authData etc.

Is that accurate?

[Tim Cappalli]

Correct (just be aware that you may receive an AAGUID of all zeroes).

 

tim

[Michael Peng]

Ah yeah, that makes sense, e.g. even Apple's anonymous attestation format (where attestation statement still exists) can return an AAGUID of all 0s.

If this is the case, though, isn't it a significant problem that RPs can't validate passkey credentials? Wouldn't we want to ensure that RPs would be able to validate the data from an inbound passkey enrollment attempt? Is the idea that users wouldn't want to shoot themselves in the foot by providing some insecure/misconfigured passkey, and that we have enough protection from bad actors thanks to TLS (i.e. protect from MITM)? However, if that's the case then, why bother with attestation statements in the first place?

Thanks so much for your help, and apologies if these are rather silly questions.

[Tim Cappalli]

Yes, attestations are a good thing. What the attestation represents is changing a bit in the new multi-credential world.

 

An attestation for a multi-device credential ultimately represents the virtual authenticator, which in the case of platforms that sync, is the sync fabric. The DPK's attestation represents the local authenticator.

 

Some platforms may not provide attestation at launch of multi-device credentials. Even without an attestation, a passkey / multi-device credential is still better than a password.

[Michael Peng]

For sure yeah, it makes sense that an attestation statement for a multi-device credential would represent the virtual synced authenticator and its authenticator data would contain that synced public key, which would be usable across devices as if it were available "on" the device during verification, etc. And yeah, a "classic" DPK's attestation represents the actual local authenticator.

So even though, as you mention, some platforms (we've seen this with both Google and Apple so far) would not provide an attestation out of the box in the interest of getting a usable framework out, I'm glad to hear that the concept of an attestation statement is still relevant and possibly would be offered moving forward. Moreover, I think the key miscue I had was just around the distinction between the attestation statement and overall attestation object (the latter of which would remain, and would contain the authData etc, and just have fmt None for attestation statement type presumably).

Thanks so much!

[Emil Lundberg]

Let me just note that "What the attestation represents is changing a bit in the new multi-credential world" is only half true, and strictly speaking nothing is changing. There never was anything that "an attestation" in general represents, it always has been and always will be dependent on the contents of the attestation. It's happened that until now, most or all attestations expressed that the key is hardware-bound, but there's no reason you couldn't for example have a software authenticator with exportable keys. It has never been the case that just the presence of an attestation statement means the key is hardware-bound, for example.

What could change is if authenticator vendors were continue to use the same attestation certificates etc. for copyable credentials as they've been using for hardware-bound credentials - then the meaning of _those attestation statements_ would change. But that seems unlikely - Google stated in the first message of the thread that hardware-bound keys will be unaffected by this, and Apple as noted plans to not provide attestation for copyable keys (for now, at least).

Emil Lundberg

Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/774371dc-1b42-440c-83ae-3e2dc94d1364n%40fidoalliance.org.

[Philipp Junghannß]

but there's no reason you couldn't for example have a software authenticator with exportable keys

while not exactly a software authenticator, the Ledger is already a U2F capable authenticator which has its master secret "exportable" in the way that it is derived from the initial seed you write down during setup.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CANMnvkwPvQrrrK4kn%3DzRh-Bb%2BFzE2vJWHMHMoBuTqmqnDTCcmg%40mail.gmail.com.

[Michael Peng]

That makes sense. Another question that might be a bit related -- are passkeys considered to be hardware-protected authenticators? (Specifically, this is regarding the keyProtection value) Since these keys are essentially copyable, the keys are no longer bound to the device, and therefore would be considered to be a virtual software authenticator with exportable keys, right?

Also, not sure if Adam would have this detail, but presumably these new copyable/multi-device credentials would have their own, new identifying AAGUIDs, right?

However, since these new credentials would be self-attested as established (i.e. would not have an attestation statement), my understanding is that they wouldn't be listed on the FIDO MDS. Is that accurate (today, e.g. MacBook TouchID via Chrome and Windows VBS Software Authenticator aren't listed there, and are self-attested; all listed authenticator models that do appear on the FIDO MDS have associated attestationRootCertificate[s])?

[Tim Cappalli]

Just for clarity, a passkey is a name for a credential, not an authenticator.

Some authenticators will support both multi-device and single-device passkeys. How this is conveyed in MDS is still being worked out across multiple working groups.

Tim

Tim Cappalli | m: +1 (617) 701-7149 • @timcappalli

did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Michael Peng <sky....@gmail.com>

Sent: Wednesday, June 29, 2022 1:21:18 PM

To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>

Cc: Emil Lundberg <em...@yubico.com>; FIDO Dev (fido-dev) <fido...@fidoalliance.org>; Tim Cappalli <Tim.Ca...@microsoft.com>; Michael Peng <sky....@gmail.com>

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d141ba96-4113-4937-b7a5-861e0e1eeddcn%40fidoalliance.org.

[Michael Peng]

Ah interesting, so an authenticator model is identified by a given AAGUID, and can contain a multitude of instances of passkeys/credentials (both multi- and single-device).

Then, the way we'd indicate key protection in authenticator data for both authenticators that support both single- and multi-device credentials  is not yet established, and related to that, neither is how RPs might distinguish between multi-device and single-device credentials, right?

[Emil Lundberg]

Key protection would be signaled via the attestation statement, typically by looking up the attestation in the FIDO Metadata Service (MDS) and seeing what the MDS reports about that authenticator model. In theory it could also be signaled by some extension directly in the attestation certificate, but there's no standardized format for it.

In the case of authenticators capable of both single-device/hardware-bound credentials and multi-device/copyable credentials, it is not yet decided how that might be reflected in the MDS. Maybe both will live under the same AAGUID and share the same metadata statement, or maybe it'll be modeled as two separate "logical authenticators" each with its own AAGUID and key protection modes.

WebAuthn Level 3 will introduce two new authenticator data flags which distinguish multi-device credentials (BE) and their sync state (BS), but these bits will say nothing about key protection.

Emil Lundberg

Software Engineer | Yubico

[Michael Peng]

Ah that's right, got my wires crossed and forgot that only the MDS would have that information. There's the UVM extension but no guarantee that it would be used I suppose. It also makes sense that single- & multi-device credentials vs key protection are somewhat distinct concepts.

That's interesting, then from an RP's perspective, until WebAuthn Level 3 there wouldn't necessarily be a way to identify when it's working with a multi-device credential?

Since Apple/Google/MSFT are already beginning to ship multi-device passkeys, I guess that creates a challenge from an enterprise perspective when dealing with enrolled multi-device credentials that weren't recognized as such initially. For example, if a credential has been enrolled pre-Level-3, the RP might want to know whether the customer could conceivably use it to verify on a new device (multi-device passkey) or not (single-device passkey).

There are also some enterprise use cases where customers care about e.g. whether a private key is device-bound, etc, though I suppose that's more dependent on how the authenticator listing in the MDS. With Apple stating that they're not ever planning on supporting attestation statements with multi-device passkeys moving forward, there's no "guarantee" that a credential is what it claims to be since it could spoof an AAGUID, right? Regardless, I guess that's up to the enterprise RP here to handle and make clear to its customer.

[nuno sung]

IMO even if Apple will adopt the BE/BS of webauthn L3 in the future, if your RP never adopt attestation type None, there is no difference to your RP from the perspective of risk assessment. "as passkeys will not provide an attestation statement", that's Apple's preference and right to use None for multi-device credentials even not to put anything in MDS or go for any certification and we can't say anything for them including Google/MSFT if they will use None or else. Although I see it's a hard decision to exclude Apple's passkey here just as None, but even as before there are cases to handles unexpected None response as browsers' policy settings or just the user deny to let the RP to get the Direct back. I haven't seen a effective way to differentiate Apple passkey's None from others. Btw, my test on iOS16 beta2 that you need to turn on iCloud keychain sync or you can't create any platform credential successfully on safari.

Besides, the aaguid should not be reused in single->multi-device credentials case due to it depends on the security review of your design document during the certification process. Could you explain the way to "spoof an AAGUID" here if the RP won't support None at beginning?

Michael Peng 在 2022年6月30日 星期四清晨7:59:42 [UTC+8] 的信中寫道：

[Michael Peng]

It's a rather peculiar edge case here, but essentially without an attestation statement to validate, we have no guarantee that a given WebAuthn credential is being honest about the AAGUID passed in the authenticator data.

[Johan Lundberg]

Thank you for this update Adam.

Two things:

1.

"Auto-fill integration with passkeys is currently behind a flag in Chrome on some platforms, and we demoed it at the RSA Conference last week."

Does this mean that any third party "authenticator app", like Authy, BitWarden or 1Password, can be selected for supplying and managing Multi-device FIDO credentials on Android? Also, is there a link you could share were this demo can be viewed?

2.  In your reply to My1 below you answer: "CTAP2 security keys are fully supported on Chrome OS. Support on Android is desired, but I'm afraid that I don't have a specific timeline that I can share."

I cannot stress enough how highly desirable support for discoverable credentials (resident keys) as specified in CTAP2 on Android would be. Being able to perform fast, as in FIDO, usernameless authentication is such a great user experience compared to having to tap in a long username for every authentication event. Especially in environments where Android devices are shared and Identity cannot be bound to the device. An update regarding this support would be great information.

Best,

Johan

[Adam Langley]

On Sat, Jul 30, 2022 at 2:46 AM Johan Lundberg <j...@ldbg.se> wrote:

Two things:

1.

"Auto-fill integration with passkeys is currently behind a flag in Chrome on some platforms, and we demoed it at the RSA Conference last week."
Does this mean that any third party "authenticator app", like Authy, BitWarden or 1Password, can be selected for supplying and managing Multi-device FIDO credentials on Android?

We would like to support pluggable passkey providers in Android but do not currently have anything to announce on this topic. (The new APIs for Android 13 have already been announced, however, so you could correctly conclude that it would be Android 14 at the earliest.)

 

Also, is there a link you could share were this demo can be viewed?

I think there is a video bouncing around but I'm afraid that I don't have a link.

 

2.  In your reply to My1 below you answer: "CTAP2 security keys are fully supported on Chrome OS. Support on Android is desired, but I'm afraid that I don't have a specific timeline that I can share."

I cannot stress enough how highly desirable support for discoverable credentials (resident keys) as specified in CTAP2 on Android would be. Being able to perform fast, as in FIDO, usernameless authentication is such a great user experience compared to having to tap in a long username for every authentication event. Especially in environments where Android devices are shared and Identity cannot be bound to the device. An update regarding this support would be great information.

We understand.

Cheers

AGL 

[HAMISU SHEHU]

SLM how are you and how your body

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+unsubscribe@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAL9PXLyy%2BAWyF76S9puw3TsQB8bTbj87PjG%3DAti3vyULzv7wvQ%40mail.gmail.com.

[Tim Cappalli]

Video is here: https://youtu.be/SWocv4BhCNg

Tim Cappalli | m: +1 (617) 701-7149 • @timcappalli

did:ion:EiBgPHSLu66o1hQWT7ejtsV73PfrzeKphDXpgbLchRi32w

---

From: 'Adam Langley' via FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Sent: Monday, August 1, 2022 3:49:10 PM
To: Johan Lundberg <j...@ldbg.se>
Cc: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Re: Details on Google's implementation of passkeys

 

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAL9PXLxha%2BU5HzXCcLaYiTsnmZfYF5LXJn1m3Wq_MG%2BRK7xRww%40mail.gmail.com.

[Johan Lundberg]

Thanks for the info guys. Let's hope for full FIDO2 support on all client platforms and interoperability with major IDPs. We are all depending on a few big vendors here to get this relying party started. The future for usernameless authentication looks bright.

[Arun T]

Will the implementation support Backup Eligibility flags?

Apple seems to support it https://developer.apple.com/forums/thread/713195?answerId=727512022#727512022

[Adam Langley]

On Mon, Sep 19, 2022 at 3:08 PM Arun T <arunte...@gmail.com> wrote:

Will the implementation support Backup Eligibility flags?

Yes. Both BE and BS flags will be true when creating a synced credential and false otherwise.

Cheers

AGL

[Andrew Doyon]

Hi,

I'm still confused about how the introduction of passkey support on Android will affect our current credential creation process. If we leave our code as is, once passkey support is released, will it begin creating passkeys or will it continue to create device-bound, non-discoverable credentials like it is currently doing?

We're currently using version 18.1.0 of the play-services-fido library. We do not set the requireResidentKey parameter to either true or false during current credential creation. 

My understanding is that if requireResidentKey is not set to true or even set at all, then the created credential will be non-discoverable. And if requireResidentyKey is set to true, then the credential will be a discoverable passkey. Is this correct?

Thanks,

Andy

[Adam Langley]

On Sun, Sep 25, 2022 at 7:54 PM Andrew Doyon <adoy...@gmail.com> wrote:

My understanding is that if requireResidentKey is not set to true or even set at all, then the created credential will be non-discoverable. And if requireResidentyKey is set to true, then the credential will be a discoverable passkey. Is this correct?

Yes.

Cheers

AGL 

[Dhruv Kuchhal]

I'm not sure if I caught the answer to Michael Peng's question about risk assessment, given that the attestation data is going to be lacking in passkeys.

Without proper attestation, the FIDO security reference itself highlights a good number of security risks -- for one, a malicious authenticator on the user's device that might get bound to the account during registration. How is an RP supposed to differentiate that from a real authenticator based passkey?

With passkeys, are we accepting these risks to improve usability to a point where it's easy to move away from passwords?

[Christiaan Brand]

Malicious software (ie. authenticators) on a user's device is typically out of scope of our threat model today.

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/3387677a-aa77-46df-a556-101ea4f517f9n%40fidoalliance.org.

[Dhruv Kuchhal]

Got it, thanks!

[MO ELKHALAFY]

Hello 

I think the answer to the risks in this context, if two-factor authentication is enabled, it is impossible to access the account, even if the password is known, also the authentication algorithms are difficult and the account cannot be accessed easily and this is from my point of view!!

Thank you 

Regards,

ELKHALAFY

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/92de27c1-397e-41d4-ad47-2b6e97c4e150n%40fidoalliance.org.