Passkeys

"This requires iCloud Keychain, yet someone may not want to put all of their passwords in iCloud. Is it practical to use a local keychain for some stuff alongside iCloud Keychain?" Although the video presenter mentions iCloud Keychain, that is part of Apple's push to always use it. The feature does not require iCloud Keychain. Passkeys can be used on single devices. iCloud Keychain technically cannot be enabled if you have a single device associated with iCloud—the end-point key exchange requires multiple devices. So the second device you add to iCloud Keychain actually enables the feature, if that makes sense. (This is documented at Apple and a little hard to parse.)

"If these “passkeys” are stored in a safe way protected with biometrics… how do I log in using them on my 2019 iMac with no secure enclave?" Passkeys are *not* stored in Secure Enclave. They are stored like passwords. Unlike passwords, the private key portion is never transmitted or sent off device to websites. The entire passkey is only synced via iCloud Keychain (if enabled) or shared via AirDrop to other people.

You can deduce that Secure Enclave is not involved because you can share and sync the passkey. Items in Secure Enclave are per-device locked and destroyed after enrollment in the enclave. So you can't sync device keys or other secrets over iCloud Keychain, but you can sync passwords, which are stored in user space and protected by biometrics or the device passcode. As a result, a passkey can be seen to be akin to a password in terms of the level of protection.

That also makes me think that it may be available on a Mac via Keychain Access, since it will be stored at a similar level of user access as passwords synced via iCloud Keychain?

As far as I can tell from the available documentation, it works as follows. I'm going to be a bit hand-wavey since I don't know exactly what Apple, Microsoft, and Google are doing here, but client-side, it looks like FIDO authentication with some backups.

There are no passwords involved here, aside from your iCloud password. Instead, authentication is performed using public-key encryption. When you register with a site, your computer or device generates a public-private key pair and stores the private key in the secure enclave. It thus should be impossible to extract the private key unless some attack is developed against the secure enclave.

When generating the keys, they're presumably signed by a certificate on Apple's servers. The service you're registering for therefore recieves a public key corresponding to the private key stored in the secure enclave, and signed by Apple's certificate. When you want to log in to this servce, the service generates a challenge and sends it directly to your computer or device. This challenge is passed to the secure enclave, which encrypts the challenge using the private key. Your computer or device then sends the encrypted challenge back to the service, which uses the public key to verify it. Apple's servers aren't involved in this process.

So the private keys aren't stored on iCloud Keychain, but metadata about them is. iCloud Keychain knows which services you've registered with, your usernames, etc. So if you move to another computer or device, iCloud keychain can instruct your computer or device to generate new public-private keypairs for each service. The service recieves the new public keys, and since they're signed by Apple's certificate, just like your old public key, that tells the service that Apple is vouching that you're the same person who generated the old key.

How difficult it is for Apple's service to do that vouching, and what technical limitations there are on that, I don't know. It seems the weakest link in all of this, but on the whole, I buy the argument that it's safer than passwords, and Apple is less likely to vouch for an attacker than a phishing expidition is to get passwords directly from a user.

It’s interesting that Glenn and Michael have very different ideas about how this works. Most of what I’ve read sounds more like what Glenn is saying. However, Michael’s description seems like a better match for the benefits that Apple claims. If there really are new key pairs generated for each device, that raises some questions. You then have to rely on Apple delivering the new public key to the service before you can log in from your new device? And there must be a way for Apple to only vouch if an existing device consents—otherwise Apple could just generate new logins on your behalf whenever they want. And, finally, if it’s all per-device and locked by the Secure Enclave, that implies that you can’t make you own backups. Which means that there isn’t really a backup at all, because everything that syncs together is collectively one system. If you or a bug screws that up, you can’t revert.

According to Apple's support document, you can recover without an existing device conscenting, by going through the iCloud Keychain recovery process. They claim it's E2E encrypted, and you must have 2FA enabled on iCloud Keychain, so I suspect they're encrypted with a user password. If you lose your ability to pass 2FA along with your devices, I bet Apple support can disable it temporarily.

Thinking about this some more, and reading what Glen wrote, it's possible that the FIDO keys themselves aren't stored on the secure enclave. Rather, each device gets encrypted copies of the keys from iCloud, decrypts them using iCloud's E2E encryption, and they're then re-encrypted using a device-specific key stored in the secure enclave before hitting the disk. This would eliminate the need for Apple to sign and attest new keys.

So iCloud would still be the weak point here, but Apple can't just attest new keys.

@Michael That makes more sense, and the Secure Enclave might not have enough space to store all the passkeys directly, anyway. I still don’t understand the claimed benefit for device theft.

IIRC the secure enclave has 4 MB of storage, and the keys are only 32 bytes each. It can store 125,000 keys, which ought to be enough for most use cases.

As for device theft. I believe the benefit is that since the passkeys are encrypted by the secure enclave, and the secure enclave won't decrypt anything without passing a Face/Touch ID or passcode check, anyone who steals your device is left with only encrypted keys that they can't use.

It's also worth mentioning that if you find Apple's implementation lacking, third-party password managers will be offering WebAuthn support in the future. For example, 1Password recently joined the FIDO Alliance and shared a clip of their passwordless login flow.

@Michael Right, but is that really a benefit over a password manager, as Apple claims? Most people probably have a 4-digit device password and a much longer 1Password password.

@remmah Yeah, it will be interesting to see how these different implementations interoperate.

I think the simplest explanation here is probably the correct one: "passkeys" are simply domain-scoped public/private keypairs, and just like your passwords, they're stored in iCloud Keychain and recoverable using the iCloud Keychain escrow process.

I'm more worried about lock-in--just what sort of buggery will Apple pull to stop you from mass-exporting your "passkeys"? Third-party alternatives ought to be considered.

@Sebby Yes, that’s the interpretation I’m leaning towards as well. However, if that’s true, it makes me doubt some of Apple’s statements, as I mentioned above. The lock-in and lack of flexibility are really concerning. I don’t see how this is ever going to work with third-party alternatives unless you use a third-party browser, too.

Excellent questions regarding Passkey. I had mostly the same ones when I heard about the announcement. I think Passkey will be mostly based on existing FIDO standards. Therefore, sharing of the private keys through iCloud seems the most likely solution for credential syncing.

If used as a secondary authentication method I think there could be some utility here for me. But sadly I don't think this will be supported in other browsers than Safari. Also, the requirement to use iCloud Keychain is not very appealing for me. Although a majority of Apple's users probably will be totally fine with it.

My understanding is that the use of passkeys will require iCloud Keychain to be enabled so as to avoid a scenario in which a user loses access to all their accounts because they lost the one and only device on which the keys were stored. I believe Ricky Mondello indicated this on Twitter a few times, but I cannot pinpoint the exact tweet I have in mind.

Passkeys seem like one of these technologies that will make life 99% better for 99% of users and sheer hell for everyone else. If you are one of these users who reuses passwords, never backs up anything, and trusts entirely in luck, then passkeys will be transformative — secure, transparent, etc. The moment you want to back things up or retain the ability to change ecosystems, passkeys will make your life impossible.

People pushing passkeys current work at Apple, Google, or Microsoft. They are amongst the few who can realistically never lose access to their accounts, by virtue of having access to internal channels to recover from whatever disasters might strike them. As for everyone else, good luck contacting Apple or Google and getting an account reinstated in any unusual situation. (The existing recovery processes pretty much boil down to a magical password in a magical safe deposit box or a magical friend who is infinitely available and infinitely trustworthy.)

I find it telling that all the platforms working on passkeys have pushed “mass export” further down the roadmap. The goal appears to be platform lock-in hidden under a thick layer of standardisation for legal compliance. Because passkeys are standard and because they can be exported one-by-one over AirDrop or used across devices using QR Codes and Bluetooth, all the compliance boxes are ticked and the EU cannot say a thing. In practice, however, it seems that no company is in a hurry to make them easy to export en masse, knowing full well this will lock users into their respective silos.

iCloud Keychain is both transformative and toxic in the extreme.

@Tarsier Yes, I believe there were several such tweets from Mondello, including this one.

@Michael Tsai, I guess how effective the lock-in will be will depend on how much of the entire stack can be reimplemented by third parties. The Bluetooth bit in particular is probably quite a challenge. We'll have to see how the password managers do it, I suppose; maybe all the UI can be added to a browser extension, or called from one, without needing consent from the OS, at least on the desktop OSs. I'm not terribly optimistic, but perhaps this will all happily turn out to be a completely unfounded worry. I hope so.