https://developer.apple.com/videos/play/wwdc2022/10092/

Most (not all, but most) of the criticisms I’ve seen of passkeys are a result of people making incorrect assumptions about the problems they were meant to solve.

For example, to solve password reuse, weak credentials, phishing, and credential theft from server breaches, you need easy to use, convenient WebAuthn credentials. The convenient part is that they are available on all your devices via secure (E2E encrypted) syncing.

The linked talk covers all of this in a lot more detail.

In theory, because most consumer-grade providers do offer some sync option which breaks the "100% hardware" guarantee and could allow malicious software to use this functionality to steal the raw key material for later offline use.

Passkeys are a slight upgrade in terms of security but a huge upgrade in terms of vendor lock-in and discouraging people from escaping whatever Big Tech walled garden they're currently in. That's why they're being pushed so hard.

Passkeys alone are a slight upgrade in terms of security compared to password only. They are a major downgrade in terms of security compared to password + second factor.

No, they're not. It is indeed worth looking into the details.

It would be impossible to sync passkeys, for example via iCloud keychain, if they were kept in the secure enclave.

You misunderstand.

Keys that are stored in the secure enclave never get out. They can't get out. That's literally why it's secure. This is why Apple silicon Mac internal hard drives can no longer be swapped. If the drive is separated from the secure enclave, or the secure enclave is damaged and the encryption key is lost, the data on the hard drive can't be recovered. You don't have the key; you can't get the key.

Synced Passkeys are, in the Apple world, still stored in a Secure Element; they just are exportable. https://www.slashid.dev/blog/passkeys-deepdive/ describes this fairly clearly.

Syncing does certainly open up attacks that are not possible against non-synced credentials, but you're incorrect to say that synced Passkeys are not stored in the Secure Element.

At least, that's my understanding. Tell me if I'm wrong!

1) The key used to encrypt the keychain is stored in the secure enclave.

2) The keychain data itself is not stored in the secure enclave.

The secure enclave only stores keys, whereas the keychain holds arbitrary data of arbitrary length. If keychain data were actually stored in the secure enclave, there would be a danger of it running out of space!

https://developer.apple.com/documentation/security/certifica...

"When you protect a private key with the Secure Enclave, you never handle the plain-text key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create and encode the key, and later to decode and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome."

Here's the kicker:

"Can’t encode preexisting keys. You must use the Secure Enclave to create the keys. Not having a mechanism to transfer plain-text key data into or out of the Secure Enclave is fundamental to its security."

In other words, nothing ever goes in, and nothing ever comes out. This makes syncing of secure enclave keys impossible. What can be synced are keys that are encrypted and decrypted by the secure enclave. These keys are the aforementioned "output".

It doesn't really matter if the storage of the actual wrapped keys is in the secure element or on disk, of course--what matters is if the SE exports unencrypted credentials, or if it fails to validate the identity of the key to which it encrypts credentials before exporting.

It doesn't seem from that description like it does either, but it's a bit unclear to me from the docs. Do you know?

"Exportable, but in SEP" is a meaningless distinction (if it even exists, I am not convinced that the article isn't confused about things, but I do not have the time or energy to try to refute it).

The security benefits on SEP are that the keys _physically_ cannot leave it; if they're "exportable" and available to AP, then their security is necessarily only as good as of Keychain, and whether they're stored in SEP or on disk doesn't really matter if the AP can access them at all.

What I understand the iCloud scheme to guarantee is roughly:

1. The TEE will not export keys except encrypted to the previously-established sync keypair. (IOW, it will only export keys after first encrypting them with the public key of the iCloud-sync keypair.)

2. The iCloud sync keypair will not be divulged by the iCloud server-side HSM except upon presentation of the correct auth credentials (your iCloud password or recovery key).

I think this provides meaningful security beyond keys sitting in plaintext on (FDE-encrypted) disk, namely, that malware running on the device cannot itself simply export the keys from the TEE. It must instead join a new keychain to the iCloud trust circle, as described at https://support.apple.com/en-hk/guide/security/sec0a319b35f/..., and to do this, it must be able to authenticate to iCloud as the user.

That's certainly possible--malware running on the device could phish the user's iCloud password, for example. But it's no longer a zero-user-interaction access to the synced key.

Again, clearly weaker than non-exportable keys, but still stronger than keys sitting in plaintext on disk.

You're right that the items from iCloud Keychain don't just sit in a plaintext on a disk, and that the ceremony to join a keyring is a complex and (until proven otherwise) secure one, but none of that is related in anyway to SEP.

The very existence of iCloud Passwords extension for Chrome on Windows should be a proof of that.

> In other words, the private key used to encrypt kSecAttrSynchronizable keys in the Secure Enclave is backed in iCloud. As such, when a new device needs to restore the keychain it can reconstruct the private key and thus decrypt the keypair needed to access all the private keys marked as kSecAttrSynchronizable, which include passkeys.

So presumably the iCloud sync pubkey is in fact available to the TEE to do the necessary encryption before exporting the synced credentials. Where that pubkey is stored only matters if you can trick the TEE into encrypting to some other pubkey, which presumably you can't--the implication of the docs seems to be that it pre-establishes which keys it will trust at iCloud enrollment time.

Is that not the case? I think if the TEE happily encrypts to any pubkey, there's a super obvious bypass here, so I doubt that's how the system works.

The OP mentions Yubikey: you can store a passkey on a Yubikey, and then it's device-bound and can't be exported. But Apple's implementation of passkeys is synced; they're just stored in an encrypted keychain.

e.g. many secure enclaves support exporting a key to another attested secure enclave

Shrug. Sure is convenient though.

Also my computer doesn't have a secure enclave because I'm keeping it disabled to prevent my machine from upgrading to Windows 11 :-). I wonder what it would try to do in that case.

That said, are people putting their cryptowallets in the secure enclave too these days? That would be new information for me.

Passkeys are meant to replace passwords for the average user. And they definitely succeed at that.

Because the technology is newish I would do some research before using it for anything really important.

So like Intel's SGX was so secure until it was not?

So you don't use a password manager, and instead use the same password everywhere (or at most a few of them), along with the same email address (or perhaps a couple of them)? If so, you should be made aware of credential stuffing: https://en.wikipedia.org/wiki/Credential_stuffing

>What part of "Good security is security where you don't get to run code on the device providing the security, ever." did they miss?

You have misapprehended how Passkeys is implemented; the site you are accessing does not run code on your machine for Passkeys.

As an aside, the site requesting the Passkey is part of the signed response; in other words, malicious sites impersonating a site cannot cause your browser to generate a Passkey for the site they are impersonating.

If you are so worried about sites running code on your box, disable JavaScript entirely in your browser.

The good thing about passwords is that it just depend on your mind. You can travel through any country with hostile customs with empty pockets. No one can get your "authentication device" and there is not even a proof that you have an account on any website. Or that you don't have multiple of them.

Seriously, all the people of my parents generation have a physical book with account names and passwords in it. You keep it in a safe place, and nobody can hack it remotely.

Plus, should your heirs or caretakers need to access it, it's all there in plain text for them.

Other than a few web forums, I don't use my phone for anything that requires a password. Certainly not for email, banking, or anything that involves personal data, money, or business. A lot of stuff, I don't do on my desktop either.

Anything connected to the internet is insecure. No, it's not as convenient to do things by phone or paper mail, but I value security more than convenience.

It's true that unsynced/hardware-bound credentials can help mitigate such attacks, but they cannot prevent it. The primary threat model of Passkeys is password theft via phishing, reuse, server-side compromise, etc.

If you want to use a USB security key, you still can--Passkeys do not take away from that. But most people are unwilling to go buy a USB key or carry one around, which is where Passkeys--arguably a bit less secure, but far better than the passwords they replace--are still a great step forward.

I can't. Most of services I use do not support using Passkeys + a USB security key as second factor.

I'm very happy to use Passkeys (synced with my password manager, just like how I sync my password database now) + a USB security key. Unfortunately, most services force me to use Apple (or Google, Microsoft)-implemented Passkeys which are secured by their hardware devices so that they can also function as a second factor.

E.g. https://www.yubico.com/products/yubikey-bio-series/