Syncing Platform Keys, Recoverability and Security levels

[akshayku]

There are various user combinations and RP security needs which makes it tricky to have a unified solution as well as solve recoverability. Sometimes, goals become contradictory. Like RP has a legitimate need for hardware bound keys but that conflicts with user's need to be able to login to the RP when that device is lost. It becomes easier when there is one other device that user has, but to support full device loss scenario, it becomes really difficult.

• RP Scenarios which reflects their various levels of security needs:
  • Scenario 1: Enterprises, due to various regulatory, compliance needs, wants hardware bound keys for their users.
  • Scenario 2: Consumer RP, also wants hardware bound keys for their highly sensitive users.
  • Scenario 3: Consumer RP is fed up with phishability and just want to get rid of passwords. They are OK with anything better than password.
• User Scenarios which reflects their usage patterns.
  • Scenario 1: User, who has multiple devices, lost one of the devices and wants to use a new device immediately after setting up that device.
  • Scenario 2: User, who has one device only (let's say phone), lost the device and wants to get back the state immediately after setting up a new device.
  • Scenario 3: User has a backup security key along with platform devices and uses backup security keys whenever platform devices are lost. User keeps the security key in well kept place and only uses that occasionally to setup platform authenticators. User does not want credential syncing and is handling the recovery themselves.
  • Scenario 4: User uses only security keys all the time.

All the RP scenarios can be solved by hardware bound keys from both platform or security keys.

User scenario 1 and 2, requires syncing which don't really match RP's needs for it's scenario 1 and 2. That is where the problem is. To address this conflict, a two key solution is proposed in #1546. Main idea behind that proposal is to have second key which is device bound and does not sync. So that when a user comes to a new device, a new device bound key is generated and RP will know that this assertion comes from a new device and then it can run it's risk analysis. This device key is per RP specific and is not shared among RPs. This is a compromise and may not work for every RP. Especially for highly sensitive RPs like banks, governments etc.

There are few important points to two key solution:

• RP needs a guarantee that it needs a true new device signal.
  • Currently with hardware bound platform authenticators, like Windows Hello, RP's gets a true device signal. Which it uses to build up a trusted device list. For example, if an RP gets two different Windows Hello credentials (assuming that credentials are not overwritten and RP is passing the exclude list properly during registration), then RP can get a guarantee that user is using two devices.
  • If that device bound key gets regenerated every time browser clears, then that second device bound key has no meaning. Then RP may incur hundreds of device public keys over time and such a data does not reflect the situation where user may only have 1 or 2 devices. Which may result in false fraud logic detections on RP's side. And RP will not adopt webauthn or use second key at all. It hurts webauthn adoption.
    • If that device bound key is per-app instead of device wide, then above same logic applies where RP is again not sure of how many trusted devices user has.

There is another problem with full device loss scenario. Platform specific recovery logic to recover an account in total device loss scenario scenario is mostly opaque for some good reasons. But in some cases it will fallback to the SMS and/or local device passwords/PINs. Which may be against the unphishability goal of webauthn and RP's requirements. But RP has no say in this in current proposals.

W.r.t security, I think there are various levels below in decreasing order.

1. Hardware bound Security Keys/Platform authenticators
2. Syncable credential with true device bound keys with recovery only allowed if user has one of other devices with them. Full device lost scenario is not supported in this situation.
3. Syncable credential with true device bound keys with full device lost scenario supported.
4. Syncable credential without device bound keys

• Syncable credential with per-app/per-context device bound key is same as syncable credential without device bound keys. As Rp cannot reliably infer anything from that per-context device bound key.

In this whole flow, one question arises. Why not give RP the choice to select what security they want at registration time. The problem with that proposal is that worry that every RP will think that they need highest security and user will suffer when they lost their own device in recovery scenario. Hence there is a current desire to pick up a reasonable middle ground without RP's choice. But things can change if enough people swing one way or another.

For us(Microsoft) as an RP, we always wanted only hardware bound keys earlier. Now we are debating whether Option 2 and 3 can work or not. That alone with require a lot of explaining and persuasion in enterprise use case and things are not settled yet. Option 4 will not probably work for us.

I am interested in other RPs stance on this. Where do they stand and what are their real needs.

[rlin1]

Regarding the security characteristic, for me there are 4 important aspects:

1. Which keys can be cloud-synchronized? None, individual keys, all - and how could the RP tell by looking at the registration response/attestation.

2. How are exported keys protected?
   2.1 Exported in-the-clear
   2.2 Can only be restored to authenticators implementing same or higher key sync protection scheme (e.g. no restore to authenticators that would export in the clear)
   2.3 Can only be restored to authenticators with same or higher security level (e.g. no restore to authenticators without TEE)
   2.4 Can only be restored to authenticators of the same model (i.e. AAGUID won’t change)

3. Are multiple instances of the keys allowed (e.g. phone + PC)?

4. What prevents the "sync" provider from disclosing the keys

[arshadnoor]

I would add two more questions to the list, @rlin1:

• How do RP's protect against a scalable attack/vulnerability on the "synched" implementation?
• Who bears responsibility for violations to privacy regulations when a "synch" provider's implementation is compromised?

[akshayku]

@rlin1 / @arshadnoor I have some answers but not all to above questions. And probably it's best that individual platform/Authenticator answers them individually. Also, I am not sure whether above comments are from RP's perspective or from FIDO alliance certification perspective or both.

I am still looking for RPs who say that it absolutely address their recovery scenarios vs it can work if done with following changes vs it will not work at all.

[cyberphone]

@akshayku This is a huge and looming issue for mobile devices. I didn't quite got what a "synced" credential is. Do you mean that it would require private key export? I hope not. A possible solution is syncing FIDO metadata like user has a key for mybank.com which can be enrolled at https://enroll.mybank.com. If a new device is to be used, the key will not be found and the user could be asked to use the original device to initiate a secure cloning request. A "manual" cloning concept is currently used by 5 million Swedes for "bootstrapping" their mobile BankID which are used by bank as well as government services.

In the case the user has lost all keys/devices I have no idea what to do except start over although synced FIDO metadata could (maybe) make the enrollment and KYC somewhat simpler.

[dwaite]

@cyberphone There is a technology preview by Apple which uses a secret/private key synchronization mechanism to synchronize PublicKeyCredentials (including private key) across devices. A single registered credential could be used on any Apple device.

AFAIK this has never been forbidden by WebAuthn, Apple is just the first large-scale authenticator to indicate intent to implement this sort of behavior. It does surface questions around what should happen when the RP security posture does not accept such behavior.

[rmondello]

@cyberphone There is a technology preview by Apple which uses a secret/private key synchronization mechanism to synchronize PublicKeyCredentials (including private key) across devices.

A method described in Apple’s Platform Security guide, to great extent.

https://support.apple.com/guide/security/secure-keychain-syncing-sec0a319b35f/1/web/1
https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/1/web/1
https://support.apple.com/guide/security/escrow-security-for-icloud-keychain-sec3e341e75d/1/web/1
https://support.apple.com/guide/security/secure-icloud-keychain-recovery-secdeb202947/1/web/1

[dwaite]

@rmondello my understanding is that there is a caveat however: the supported API for keychain (e.g kSecAttrSynchronizable) and the Apple Platform Security guide have not yet been updated to reflect the addition of these synchronized asymmetric keys.

[Kieun]

For native application, especially for Apple ecosystem, there is an option for RPs to indicate whether allowing key backup (syncing) or not. As a RP side, it would be helpful to leverage platform level key syncing since it just works without introducing complex KYC scenario. We prefer to have an option for this.

[cyberphone]

@Kieun This is fine but it will undoubtedly lead to a fractured FIDO ecosystem. Fixing it seems close to impossible. TPMs needed almost 20 years to get any (visible) use for consumers.

Although politically and technically difficult, I would early on have considered some kind of portable "master secret". However, the window of opportunity have already passed.

[emlun]

A WebAuthn parameter for RPs to signal whether syncing keys is permissible was previously discussed in #969. That was closed with the note:

we believe this has been superseded by issues such as #1546

Also noted there is that if syncing keys is not acceptable to an RP, then that RP must by necessity enforce attestation by allow-list anyway. So a parameter could at most optimize the user experience, but doesn't really introduce any new capability.

[ghost]

Worth noting also that solutions like Apple's keychain syncing (mentioned above by @dwaite and @rmondello) are ultimately password based. So although such solutions can help prevent RPs from requiring users to create new passwords, it doesn't eliminate passwords altogether.

When a user enables iCloud Keychain for the first time, the device establishes a circle of trust and creates a syncing identity for itself. The syncing identity consists of a private key and a public key. The public key of the syncing identity is put in the circle, and the circle is signed twice: first by the private key of the syncing identity, then again with an asymmetric elliptical key (using P-256) derived from the user’s iCloud account password.

(emphasis my own)

And further, in some sense it makes the root password (in this case an iCloud password) all the more vulnerable, since the attacker's prize for compromising it is all that much bigger.

[dwaite]

@certainlyNotHeisenberg I believe it is meant to be two-factor (possession and knowledge based) for circle membership, hence the unhighlighted part of the two signatures in this particular step. I'll let others more versed elaborate that point if they desire, such as if there is a device attestation to restrict circle membership.

[MeydanOzeri]

I have some idea that I'm playing with in my head to try and create a secure recovery flow in case of total loss of all authenticators, basically it relies upon asymmetric encryption signatures.

Upon registration the clients browser creates a public private key pair, it shows the user the private key in the form of a seed phrase (same as crypto wallets) and tells the user to store it safely, after the user is confirming that he stored it, the public key is saved by the RP for a future recovery scenario, and the private key is deleted.

When the user triggers the recovery flow, the RP will send a randomly generated message to the client, the client will be prompted to provide his seed phrase (private key) and the clients browser will use it to sign the message provided by the RP, then it will send the signed message to the RP where it will be verified by the public key associated with the account, if the signature is valid we can be certain that the correct and only private key was used.

After that the user will get the ability to perform a new attestation and create a new credential, when he is done all the old credentials will be deleted, and he will be shown a new recovery seed phrase for future recovery scenarios. (making it a one time use recovery phrase)

I find that this approach is a safe option since it is resistant to RP database breaches as acquiring the public key will not help the attacker, the private key is generated on the client side and doesn't leave it, so it is resistant to man in the middle attacks.
Brute forcing/guessing attacks are irrelevant since there are to many different possibilities for a private key when using a secure asymmetric algorithm such as ECDSA/RSA.

The only security issues I can come up with this approach is that it is not resistant to phishing attacks/social engineering attacks + the user will need to store it safely otherwise it is open to theft attacks.

I'm still trying to find a way to invalidate phishing/social engineering attacks with this approach. so far I didn't find a way.

Looking forward for your feedbacks on this idea.

[sbweeden]

When the user triggers the recovery flow, the RP will send a randomly generated message to the client, the client will be prompted to provide his seed phrase (private key) and the clients browser will use it to sign the message provided by the RP, then it will send the signed message to the RP where it will be verified by the public key associated with the account, if the signature is valid we can be certain that the correct and only private key was used.

You never indicated if in this model the seed phrase is bound to the client or not (i.e. can it be used from any machine/browser or only the one from which the original keypair was generated).

If it is bound to the device, then what advantage does this offer over the current platform authenticator approach, and how does account recovery work on loss of device?

If it is not bound to the client, then you have the same phishing and remote attack vector issues as with any shared secret approach.

If you would like to understand why WebAuthn is considered phishing resistant today, I've written an article about it here.

Either way I'm not convinced yet that this approach brings something new to the problem space, but happy to be proven wrong!

[emlun]

I think that @MeydanOzeri's proposal could be made phishing resistant if combined with ideas from our recovery extension. What's currently missing is that the user's private key be tied to a particular origin, so that the browser can verify that the RP is authorized to exercise that private key. This of course leads to a new problem: the user doesn't want to perform the setup and store one private key for each individual RP, right? But this could also be solved using asynchronous remote key generation (ARKG). I think this could even work without any changes to RP code or the WebAuthn API, something like this:

1. Initial setup:
   1. The browser generates a "seed" key pair, instructs the user to safely store the private key and stores the public key in the user's browser profile.
   2. The browser also generates a MAC key deterministically from the public key (for example by hashing the public key) and stores it.
   3. The public seed key and MAC key can be safely exported and imported to another machine in order to "connect" it to the same set of recovery credentials.
2. Whenever the user registers a new credential (navigator.credentials.create()), the browser checks if excludeCredentials contains any credential ID with a valid MAC suffix. If none does, the browser offers to register the recovery credential instead of a normal platform or roaming credential.
3. If the user chooses to register a recovery credential:
   1. The browser uses ARKG to generate a new public key and credential ID from the RP ID combined with the stored public seed key.
   2. The browser computes a MAC of the credential ID using the stored MAC key, and appends the MAC to the credential ID.
   3. The browser returns this public key and credential ID (with the MAC appended) as the credential to be registered.
4. Whenever the user is to authenticate (navigator.credentials.get()), the browser checks if allowCredentials contains any credential ID with a valid MAC suffix. If one does, the browser offers the user to use this recovery credential.
5. If the user chooses to use the recovery credential:
   1. The browser prompts the user to enter the private seed key.
   2. The browser removes the MAC suffix from the credential ID.
   3. The browser uses ARKG to derive a private key from the credential ID combined with the RP ID and private seed key.
   4. The browser uses the derived private key to sign the authentication challenge and returns the result as a normal WebAuthn assertion.
6. The user is now successfully logged in and can perform any credential management as usual.

I'll need to think a bit more on it, but the idea seems quite interesting:

• No secret key is stored long term in the browser
• Origin-bound and phishing resistant just like normal WebAuthn credentials
• Multiple browsers can be set up with the same public seed key and MAC key, and each needs the private key only at recovery time
• Entirely a browser feature, automatically compatible with all existing RPs (except ones with an attestation policy that excludes it)

I can't easily think of a way to preserve the "single-use" aspect of it, but that seems to me like a very minor problem compared with the advantages. Maybe a bigger problem is that so far, ARKG is intrinsically tied to elliptic curve cryptography and thus not quantum resistant.

[Firstyear]

The issue here is that this process is wayyyyy too complex for most people to be able to manage. I couldn't imagine trying to communicate this to my brother who is a carpenter and have him successfully able to create this recovery material, let alone using it to retrieve a key.

For example, "just export the recovery credentials" really glosses over a lot of complexity. Where will a user export it to? How will they preserve that? On a USB stick, which is a lossy medium?

While this whole process is technically very cool, and interesting, I think that it's really overlooking the experience of an everyday user to achieve this reliably.

Please when you come up with a process like this, step back and talk it through with non-technical folk and see if they can follow it. because that's your audience here. If I can't communicate this process to my brother, or my neighbours, then it won't work at scale.

Thanks,

[emlun]

Well, yeah, we're discussing possible technical solutions. Packaging for end users is important, yes, but premature at this point. But know that we do keep in mind that it needs to be possible in the end.

For example:

Where will a user export it to?

For the smoothest user experience, the browser could just sync it along with the user's other preferences, if the browser has cloud sync features. Or it could be exported as a textual "key phrase" to print or write down on paper just like the private key in @MeydanOzeri's proposal. Or any number of other possibilities, as the keys in question don't need to be kept secret.

[Firstyear]

If you leave user experience to the end, you'll potentially design a system that technically is excellent but you can't make usable.

Why not design a usable system first and think about that, and then fix in how it will work technically? Or at least, consider both at the same time? User experience isn't an after thought, it needs to be at least equally considered here.

[mfisk]

I can speak from and perspective of 3 RPs, both commercial (including banking) and government. This is an important issue for workforce (not consumer) authentication — the places where hardware tokens have had market penetration.

1. In this world, the RP has other roots of trust with the user and often wants to own the device enrollment/recovery flow.

2. The RP also often wants to limit access to corporate/compliant devices and does not want transparent moving on private keys from a corporate device to an unknown/personal device.

3. From a compliance and accreditation perspective, a device-bound key includes the device OS as part of the in-scope solution/system, but with ecosystem portability like Apple has, the compliance scope now includes the iCloud account recovery and new device enrollment process which is significant new complexity and with no change mangement to determine if new iCloud logic is understood by the RP or is considered acceptable to the RP. This is an untenable situation to some regulators.

Being able to require a single-device key that cannot be extracted from the device is a basic requirement. It is highly disappointing that FIDO2 platform implementations have been regressing from hardware-protected keys to cloud. On laptops this will drive continued use of separate hardware keys but on mobile this practice really undermines the ability to use FIDO2 for high-security applications.

Worse yet, on iOS 16, if the user disables cloud backup of their keychain, iOS actually refuses to enroll a new passkey at all. That’s just crazy to me.

[akshayku]

From TPAC 2024: This issue was for awareness purpose and no longer required given the reality of passkeys today. Closing this.