Passkeys in Apple's iCloud Keychain

Passkeys are the new hot topic in crypto and are being broadly discussed amongst account developers. In some of these discussions, there has been confusion and inaccuracies on the implementation of passkey storage and security within the Apple ecosystem. The goal of this guide is to outline in detail how Apple's iCloud Keychain manages passkeys and the all-important private key.

The information in this guide is directly from Apple's documentation. Citations are provided along the way so that you don't have to trust me and can verify for yourself. Apple's documents are unfortunately quite scattered, so this guide attempts to bring all of that information into one accessible place.

This guide will discuss the lifecycle of passkeys in the Apple ecosystem and also dive into aspects of iCloud's Keychain, which is necessary to understand to have a clear picture of how passkeys are stored, secured, and synced across devices.

Quick Jump

• First Things First
• The Passkey Lifecycle
• Generation
• Local Storage
• Remote Storage
• Challenge & Transaction Signing (Usage)
• Recovery
• iCloud Keychain: Secure Sync & Storage
• Trusted Circle
• Secure Sync
• Data Security & Encryption
• iCloud Keychain Recovery Mechanisms
• Creating the iCloud Keychain Escrow
• Recovering the Keychain from Escrow
• Recovery using a Recovery Contact
• Recovery using Escrow for iCloud Keychain
• Potential Pitfalls
• Conclusion
• Sources

First Things First

• iCloud Keychain, and therefore a passkey's private key, is always end-to-end encrypted, no opt-in required.
• With secure enclave, iCloud Keychain passkeys provide hardware level security, ensuring that the private key is never exposed outside of the secure enclave.
• Data which is end-to-end encrypted can NEVER be accessed by Apple. Even in extreme cases such as iCloud or Apple itself being hacked; the data is secure.
• Even if a user's iCloud account is hacked, data is secure unless the hacker can authenticate into a trusted device in the user's iCloud account (this requires the user themselves be compromised as the Keychain's local data is protected by biometrics such as FaceID or TouchID)
• In extreme scenarios, such as a user losing all Apple devices, the iCloud Keychain can still be securely recovered.
• To use passkeys, iOS16, iPadOS16, macOS13, or tvOS 16 (or later) is required and iCloud Keychain and two-factor authentication must be on. ¹

• WebAuthentication Standard (aka WebAuthn): The standard published by the World Wide Web Consortium as part of FIDO2, with guidance from the FIDO Alliance. This standard defines the technology underpinning passkeys.
• Passkeys: Apple's implementation of the WebAuthn standard. Apple was the first to introduce an implementation of WebAuthn which could be synced across devices. The term “Passkey” has quickly become the common place phrase for implementations of the WebAuthn standard.
• Secure Enclave: Refers to the dedicated secure subsystem in modern Apple devices. "The Secure Enclave is isolated from the main processor to provide an extra layer of security and is designed to keep sensitive data secure even when the Application Processor kernel becomes compromised."²

Finally, note that when I'm talking about the security of a passkey, I am referring to the passkey's private key, which is the sensitive piece of data used to authenticate.

A Passkey's Lifecycle

This section provides an overview of the security and storage of passkeys in all stages of its lifecycle.

Passkey Generation

Apple passkeys are generated using public key cryptography. "During account registration, the operating system creates a unique cryptographic key pair to associate with an account for the app or website. These keys are generated by the device securely and uniquely for every account". ³

Further, "the server never learns what the private key is".³ If the device has a secure enclave, the private key is generated within the secure enclave using its AES engine for efficient and secure cryptographic operations.²

If a device doesn’t have a secure enclave, it cannot generate a passkey. Only devices which have Touch ID or Face ID can generate and authorize use of a passkey.²

Local Storage of Passkeys

Passkeys and its private key are stored within the iCloud Keychain. Some iCloud Keychain data is stored in a SQLite database, encrypted by the metadata key which is stored in the Secure Enclave.⁴ Some iCloud Keychain data tagged with the kSecAttrTokenIDSecureEnclave variable, such as passkeys, is stored in the Secure Enclave.⁵

Devices without a secure enclave do still store iCloud Keychain data locally in a secure encrypted file; however, since devices without a secure enclave cannot use passkeys, the passkey should never be exposed in an insecure environment. But if there is any concern, Apple uses several security practices to protect data in runtime such as sandboxing and address space layout randomization.⁶

Remote Storage & Security of Passkeys (Cloud Storage)

Given that iCloud Keychain data, including passkeys, is synced across devices, we know that the data must be stored and secured remotely.

Before passkeys are sent to the cloud from the local device, they are encrypted using iCloud's encryption mechanisms (described in detail in the iCloud section of this document).

In no scenario is Apple able to gain access to a user's Keychain data. Only devices within a user's iCloud trusted circle can decrypt Keychain data. Again, you can find more details in the section on passkeys.

Challenge & Transaction Signing (Usage)

This section is a quick overview on how passkeys can be used. Passkeys are used to sign challenges which allow a user to authenticate and log in to a website or app. They now are also increasingly being used in web3 to authenticate onchain transactions. Here's what happens when passkeys are used:

• In traditional authentication scenarios such as logging in to a website or app:
• The app or website's server provides the user with a random bytestring “challenge” which is signed with the private key.
• The server can then verify the signature of the challenge using the public key of the passkey for the account that the user is authenticating.
• For authenticating the execution of onchain transactions for a smart account:
• The user is provided with a transaction object to sign with the private key of their passkey, which is an authorized user of their smart account.
• The signed transaction object is sent to the smart account which uses an onchain verifier to prove that the owner of the account approved the transaction by signing it with their passkey.
• In this second scenario, the transaction object being signed for is passed for the “challenge” instead of a random byte string as a challenge.
• In both above scenarios the private key for the passkey is used in the same way. The only difference is the object being signed.

When signing the challenge or transaction object, the device will request from the user that they use their passkey to sign. The user then authenticates using biometrics such as Face ID or Touch ID. The user needs to be logged into iCloud to access passkeys. It is important to note that this is required as a security measure and is not because the passkey is being pulled from the cloud. Recall from our previous section that the passkey is stored locally within the secure enclave.¹

Once the user has authenticated with biometrics, the device will use the secure enclave to sign the object and then pass the signed object back to the service requesting authentication.

If you are on a device which doesn't have access to your iCloud Keychain or that doesn't have the appropriate software to use Passkeys, the site can provide a QR code which creates a Bluetooth connection with your iPhone. The challenge to sign will be sent to your iPhone and will be signed within the secure enclave after authenticating with biometrics. The signed challenge will then be passed back to the originating device to complete authentication.¹

Throughout the challenge signing process, the private key never leaves the secure enclave of the device.

Passkey Recovery

Passkeys have the same recovery mechanisms as any sensitive data stored in the iCloud Keychain.

You can find the details of iCloud Keychain Recovery below. The important aspects are as follows:

• Even if all Apple devices are lost, the Keychain can be recovered if the user set up Advanced Data Protection or added a Recovery Contact.
• If at least one Apple device is still available, a new device can be added to the trusted circle and the keychain will be synced to that device making the passkey available.

iCloud Keychain: Secure Sync & Storage

Because Passkeys are managed by iCloud Keychain, it is important to understand how iCloud Keychain secures, syncs, stores, and recovers your sensitive data. For accounts set up with 2FA, iCloud leverages CloudKit, an integrated API for Apple OS that functions as a backend as a service and powers iCloud.

iCloud Trusted Circle

One of the core components of iCloud is the trusted circle of devices. When iCloud is first enabled, the originating device creates a circle of trust and a syncing identity for itself.⁷

• The syncing identity is a public private keypair stored in the device's Keychain
• The public key of the syncing identity is added to the circle and the trusted circle is signed twice
• First by the private key of the syncing identity
• Second by a p256 elliptical key derived from the user's iCloud account password
• The parameters used to create the second key are also stored in the keychain for future use in recovery scenarios

For 2FA accounts, meaning any account using passkeys, an additional similar syncing circle is created and stored in CloudKit.⁷ Each device maintains its own list of identities it trusts and signs the list of trusted devices using one of its identity keys. The trusted circle is also stored in the iCloud key-value storage area.

Technically, the trusted circle can only be modified with both the iCloud password and the private key of one of the devices in the circle. Apple provides 2 flows for adding a device to the trusted circle:

• By pairing with and being “sponsored” by an existing iCloud Keychain device
• In this flow, the applicant device creates its syncing identity for both the syncing circle and the syncing lists in CloudKit and presents them to the sponsor.
• The sponsor adds the public key of the new member to the syncing circle and signs it with both its own syncing identity and the key derived from the user's iCloud password.
• The new syncing circle is placed in iCloud, where it is similarly signed by the new member of the circle.
• In 2FA accounts, the sponsor device also provides the joining device with a “voucher” signed by its identity keys, showing the applicant device should be trusted.
• The sponsor device adds the applicate device to its individual list of syncing identities to include the applicant.
• Using iCloud Keychain Recovery (described below)

Secure Sync

Once a device is in the trusted circle, it has the public key of the syncing identity of all the other trusted devices. They exchange items through the iCloud key-value storage or through CloudKit, depending on if the account has 2FA enabled or not.⁷

Each item is encrypted so that it can only be decrypted by a device within the Keychain's trusted circle. This is possible because data is encrypted with the CloudKit Service Key, which is only ever created in the secure enclave of a trusted device and never provided to Apple.⁸

Data Security & Encryption

The security of your data is two part. It is protected by the authentication process required to gain access to data in iCloud Keychain, as well as by the encryption of the data at rest within iCloud. Apple uses 2 Factor authentication to improve the security and recoverability of iCloud data.

In Apple's ecosystem, 2 factor authentication (2FA) uses existing Apple devices within a user's trusted circle.⁹ Whenever 2FA is required, a 2FA code is sent to a device in the trusted circle which is NOT the current device being used. The other device asks the user if the device requesting authentication should be allowed to authenticate, and if confirmed, then displays a 6 digit code which is used on the requesting device. At this point, 2FA is considered completed.

We have discussed how iCloud encrypts data to secure it in previous sections, but we will articulate it again here in more depth. All data within iCloud Keychain is end-to-end encrypted, no opt-in is required.

Apple offers two options to encrypt and protect data stored in iCloud:

• Standard (default): iCloud data is encrypted, encryption keys for data which is not end-to-end encrypted are secured in Apple data centers so they can help with data recovery.
• For most users, this option is likely best. It balances security and usability. There is added external security risk that encryption keys are available to Apple for the trade-off benefit that they can help you with data recovery.
• Advanced Data Protection: Optional setting offering the highest level of iCloud data security.
• For more advanced users: this option reduces external security risk since only the user has access to encryption keys with the tradeoff downside that in extreme scenarios, only the user can recover data and Apple cannot assist.

For details on exactly which iCloud data can be accessed by Apple, you can visit iCloud data security overview.¹⁰ This document has a table which outlines the details for all data stored in iCloud.

Keychain Recovery

Recovery of iCloud Keychain is of extreme importance, especially now that passkeys are being used to secure funds. If a passkey securing funds is lost, it puts those funds at risk if the onchain smart account doesn’t have additional recovery mechanisms.

Throughout this article, we have rearticulated that even in extreme scenarios, Apple does not have access to data secured in Keychain. This section outlines the magic of how a user can recover their Keychain even if they lose all trusted devices, without Apple having access to the secure data.

Creating the iCloud Keychain Escrow

Given that the use of passkeys requires that 2FA is enabled, I will only outline the escrow process for when 2FA is setup. You can review the non-2FA escrow flow in Apple’s Secure iCloud Keychain Recovery document.¹¹

Keychain recovery uses secondary authentication and a secure escrow service created by Apple. The user’s Keychain is encrypted using a strong passcode and the escrow service provides a copy of the keychain to the user when a strict set of conditions are met.¹¹

For 2FA enabled accounts, the device passcode is used to recover an escrowed keychain. When the passcode is established, the keychain is escrowed with Apple.

Within the escrow, the necessary keys are provided to allow the recovering device to rejoin iCloud Keychain, proving to any existing devices that the user successfully went through the escrow recovery process and is therefore considered authorized by the account’s owner.

Note that the user must also register a phone number. This provides an extra level of security and also makes it possible to use the recovery process even when all trusted devices have been lost.

Recovering the Keychain from Escrow

Life happens, and we might lose one or many devices. The most common scenario is losing a single device while still controlling at least one other device in the trusted circle. In this scenario, the user could choose to pair their new device with an existing device to add the new device to the trusted circle,which we outlined above here. The other option is to use iCloud’s keychain recovery mechanism outlined below.

In extreme scenarios, a user might lose access to all of the trusted devices in their Keychain, but even in this scenario all is not lost; however!, the user must have opted in to at least one of two Apple features. If the user did not opt into one of these features, their iCloud Keychain will be lost:

• Account Recovery Contact has been turned on and at least one recovery contact has been set
• This can be turned on even if Advanced Data Protection is off. If you are an Apple user, I highly recommend you turn this feature on.
• On your iPhone, this feature can be found within your iCloud settings on your device under Advanced Data Protection. Scroll down to Account Recovery and select “Add Recovery Contact”.
• Advanced Data Protection has been turned on
• Advanced data protection can be set up in a user’s iCloud on devices which have at least iOS 16.2, iPadOS 16.2, macOS 13.1, tvOS 16.2, watchOS 9.2, or the latest version of iCloud for Windows. ¹²
• When setting up Advanced Data Protection, the user must set up at least one alternative recovery method in either one or more recovery contacts or a recovery key which is used to recover iCloud data if they lose access to their account.

When recovering an account, a user can either use the Escrow recovery flow or the Recovery Contact flow.

Recovery using a Recovery Contact

Recovering a keychain using a Recovery Contact is a slightly more user friendly route. It is important to note that neither Apple nor the recovery contact have the necessary information individually to recover the user’s end-to-end encrypted iCloud data. Further, Apple doesn’t know who the recovery contact is until late in the course of a recovery attempt to protect user’s privacy. Here’s how Recovery Contact secures the recovery information:

• When a recovery contact is added, the key to access iCloud Keychain data is encrypted with a strong random key.
• This random key is split between into 2 key shares, one given to the recovery contact and the other stored on Apple’ servers. This processes is secured by an end-to-end encrypted CloudKit container shared with the recovery contact to share the portion of the key the recovery contact needs.
• Apple and the recovery contact also receive the same authorization secret from the user (in the background) which is needed later for recovery.
• For more details on how the recovery key is managed securely, review Apple’s Recovery contact security process¹⁴.

When an account needs to be recovered, the user requests help from their Recovery contact. At that time, a recovery code is generated by the recovery contact’s device, which the recovery contact then provides to the user. The user then enterers the recovery code on their device to establish a secure connection between devices using the SPAKE2+ protocol, the contents of which isn’t accessible by Apple.¹⁴

Through this secure connection, the recovery contact’s device sends their portion of the keying information and the authorization secret to the user requesting recovery. The user provides the authorization secret to Apple, which then provides the other half of the key.

The user’s device then recombines the keying information and uses it to decrypt and recover their iCloud data. Note that there are safeguards in place to prevent a recovery contact from initiating recovery without the user’s consent.¹⁴

Recovery using Advanced Data Protection

The iCloud Keychain Escrow stores all Keychains in the hardware security modules (HSMs) that guard escrow records. Each HSM has a key to encrypt and decrypt the escrow records under their watch. These records were already encrypted so this adds an additional layer of encryption.¹³

To recover the keychain a user must:

• Authenticate with iCloud using their account & password on the new device.
• Respond to an SMS sent to the registered phone number on the account.
• Enter the iCloud security code. If the user has 2FA enabled, they can use their device passcode¹¹ or they can use the recovery key from Advanced Data Protection if that was setup.

Once this information is provided, the HSM cluster verifies that the user knows the security code using the Secure Remote Password (SRP) protocol.¹³ This protocol allows Apple to verify the user knows the code without seeing the code. This ensures Apple never accesses the information required to decrypt the Keychain.

The HSM cluster unwraps the escrow record and sends it to the user’s device, where the iCloud security code is used to unwrap the random keys used to encrypt the user’s keychain. At this point the Keychain has been recovered and restored on the user’s device.

The recovery procedure policies are encoded in the HSM firmware and the administrative access cards that permit the firmware to be changed have been destroyed. This prevents an account from being compromised due to employee coercion or bribing.

Lastly, the user only has 10 attempts to authenticate and retrieve an escrow record. This prevents brute-force attempts to retrieve a record. After several attempts, the record is locked, and the user must call Apple Support to be granted more attempts. After the 10th failed attempt, the HSM cluster destroys the escrow record an the keychain is lost forever.¹³

Potential Pitfalls

Note: The remainder of this article is my own opinion.

The above should make it clear that Apple’s iCloud Keychain infrastructure is state of the art for securing passwords and passkeys. But there are always tradeoffs when securing your data, and iCloud Keychain isn’t without some shortcomings to be aware of.

Vendor Lock-in

A common concern with a device native password and now passkey manager like iCloud is vendor lock-in. It is true that if you are using iCloud, you must be using Apple devices. This means that if in the future you want to stop using Apple devices and transition to another device ecosystem, you won’t be able to bring your iCloud Keychain with you. To change device ecosystems, the user would need to update all accounts with new passkeys that are accessible on the new device. If you think that you may leave the Apple ecosystem, this is a limitation to be aware of.

3rd party password managers, such as 1Password, mitigate vendor lock-in as data managed by 3rd party providers can be made accessible anywhere; however, it’s important to note that the security of 3rd party mangers is different than what was outlined above. Because iCloud Keychain is only available on Apple devices, Apple can engineer a system which is incredibly secure. Secure in ways which 3rd party password managers using many different hardware systems likely are not (I plan on doing a similar in-depth review of 1Password so that the tradeoffs between these systems are clear & accessible).

The use of SMS

A careful reader will have noticed that Apple requires a trusted phone number be provided to support the account recovery process when using escrow recovery. This should raise alarm bells as this introduces SIM swap risks. If you are reading this article you are likely familiar, but just in case: a SIM swap attack is when a hacker contacts your phone carrier (e.g. Verizon) and pretends to be you. They provide enough information or bribe the carrier representative to have the SIM card for your phone swapped to their device. Now that they have your phone number, they receive any SMS based authentication requests. This type of attack is very common and used to compromise users who use SMS based 2FA or SMS password reset flows.

Lets outline the risk of a SIM Swap attack on an iCloud Keychain. Assume a hacker has successfully executed a SIM Swap and now have your phone number. Their steps to compromising your account would be as follows:

• They would need to authenticate into your iCloud on their device by using your iCloud password.
• Then they would receive and successfully respond to the SMS message from Apple.
• Then they would have to provide the HSM cluster with the iCloud Security Code set by the user. Recall they have less than 10 attempts to do so before the recovery process is locked.

The risk does exist and should be acknowledged. It would require that the hacker knows both the user’s iCloud password and the Security Code, in addition to SIM Swapping their phone.

Conclusion

Apple’s iCloud Keychain is one of, if not the most, secure passkey manager available. Not only does it provide hardware level security with the use of the Secure Enclave for all passkeys and passwords, but it also has a robust end-to-end encryption system which makes it impossible for Apple to gain access to your passkey’s private key in even the most extreme scenarios such as a user’s iCloud being hacked or iCloud itself being hacked.

The crypto space is beginning to use passkeys to authenticate smart accounts, meaning passkeys will be protecting large sums of money on immutable blockchains where transfers are irreversible. Understanding the details of how these passkeys are managed is critical and it is important for the crypto community to have an accurate understanding of how passkey management works in various ecosystems.

Take a moment to consider the iCloud Keychain private key management outlined in this document and compare it to existing private key management systems in crypto.

• It is clearly more secure than a hot wallet like MetaMask but has strong availability as it is available system wide and doesn’t require a browser extension.
• It has hardware level security with secure enclave, on par with the hardware level security provided by hardware wallets. Considering a recent security exploit of Ledger’s connect-kit, my unavoidable opinion is to wonder if the end-to-end security of that system is as secure as the one provided by iCloud. (Don’t yell at me for this opinion, prove me wrong)
• Further, iCloud Keychain has robust recovery mechanisms that are more secure and more accessible than seed phrases. Recovery Contact is Apple’s version of Social Recovery which we’ve seen gain some steam in the crypto smart account space.

I would make the argument that through passkeys, Apple has built the most secure and usable private key management tool available. It’s not without some shortcomings, such as vendor lock in, which would make transitions to another device ecosystem painful but not impossible. All security systems make tradeoffs, and the security provided by iCloud Keychain when balanced with its few downsides, is best in class and ready for mainstream adoption.

Sources