Wednesday, June 29, 2022 [Tweets] [Favorites]

Passkeys

Meet passkeys (Hacker News):

Learn how to add support for passkeys to create a quick and easy sign in experience for people, all while offering a radical increase to account security. Passkeys are simple and strong credentials built to eliminate phishing attacks. We’ll share how passkeys are designed with security in mind, show you how people will use them, go over how to integrate passkeys in your log in flow, and explore the platform and web APIs you need to adopt this feature.

The developer documentation is here. I don’t understand the slide at the end where it says that Passkey protects against device theft but a password manager (maybe) doesn’t.

Other questions:

Kuba Suder:

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?

Dan Moren:

The addition of passkeys should also remove the need for multifactor authentication—no more entering codes from an app or via SMS. That was always an additional feature provided because of passwords’ inherent insecurity, but the way in which passkeys work makes it unnecessary.

[…]

One additional question that has now been answered for passkeys is what happens when you’re logging in on another device, either from Apple or another manufacturer. The FIDO Alliance that backs the passkey standard (of which companies like Apple, Microsoft, Google, and Amazon are all members) has an approved solution: a QR code that you scan with your phone, providing a secure way to log in.

The methodology behind this process is fascinating: among other things, the authenticating device (likely your iPhone) creates a Bluetooth-based relay server which, by the very nature of Bluetooth’s limited range, helps ensure that you are in fact in proximity to the device into which you’re logging in. That makes it much more difficult for phishers to trick you into giving up your passkey: sending you a QR code in an email or text message won’t work because it won’t be able to get access to the Bluetooth connection.

Dan Moren (also Bruce Schneier):

Andrew pointed me to a blog post by Terence Eden, which contains a bit of a thought experiment on what happens if you have a catastrophic accident (say, a house fire) and lose access to all your devices[…]

[…]

Well, there are recovery methods in place, as you might suspect. Apple talks broadly about them in a support article[…]

Apple:

To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.

It sounds like anyone who can get into your Apple ID account and either see your phone notifications or redirect an SMS message can delete all your passkeys.

Glenn Fleishman:

A passkey replaces two-factor authentication, and it’s worth breaking down why, as it seems counter-intuitive: how can a single code held on a device provide distinct aspects of confirmation? The rubric for multiple security factors is usually stated as at least two of “something you know, something you have, or something you are.” A passkey incorporates at least two of those:

  • Something you know: While commonly thought of as a password, the “know” part is really any fixed piece of information you possess. Think of a 20-character randomly generated password stored in your password manager. Do you “know” that? Yes, in the sense that it’s retrievable exactly as entered.
  • Something you have: Because passkeys are locked to devices, you prove your possession of a device by unlocking the passkey: no device, no passkey.
  • Something you are: Although passkeys don’t require biometric authentication using Face ID or Touch ID, it’s an option. Apple always lets you use a device passcode to backstop Face ID or Touch ID, so it’s a blurred line with “something you know” compared to a dedicated biometric device with no fallback option.

In what sense are passkeys locked to a device if they are syncing via iCloud Keychain? Is the idea that they must be on one of your devices because there is no way to export them?

Update (2022-06-30): Meek Geek:

What if something was broken with your Apple Card and Apple says you owe them money, or if you’re a developer who ran afoul of Apple’s App Store rules?

Would a suspension of your iCloud account mean that you lose access to all your passkeys?

Previously:

14 Comments

Glenn Fleishman

"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.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment