> Does a service know my private key when using Passkeys? If so, I'd prefer to use non-resident WebAuthn keys. When using **Passkeys**, the service **does not know your private key**. Passkeys are designed to improve security and privacy, leveraging public-key cryptography to authenticate users without exposing sensitive key material. Here’s how Passkeys work: 1. **Private Key Storage**: The private key is stored securely on your device (e.g., in the device's secure enclave or a trusted platform module, TPM) and is never shared with the service or sent over the network. 2. **Public Key and Challenge**: When you register a passkey with a service, your device generates a key pair: a **private key** (which stays on your device) and a **public key** (which is shared with the service). During login, the service sends a challenge to your device, and the device uses the private key to sign it. This signature is then verified by the service using the public key. 3. **No Exposure of Private Key**: At no point does the service ever receive or have access to your private key. All the service knows is your public key and can verify signatures made by your private key without seeing it. ### Passkeys vs. Non-Resident WebAuthn Keys If you're concerned about privacy and security, **non-resident WebAuthn keys** are an alternative where the private key is not stored on your device indefinitely. Non-resident keys are often generated on the fly and typically reside on external devices like hardware security keys (e.g., YubiKeys). - **Non-Resident WebAuthn Keys**: These don't store the credential information (such as the private key) on the device itself. Instead, when used, they generate the key material temporarily and discard it afterward. You manually authenticate with an external device, such as a USB or NFC key, which is not stored on the local device. - **Passkeys (Resident Keys)**: Passkeys are stored on your device and are often synchronized across devices (e.g., via iCloud Keychain or Google Password Manager). While convenient, you may have concerns about how keys are synced or stored. ### Which to Use? - **Passkeys** are excellent for most users because they offer both convenience and security. They are bound to your device, ensuring that no private keys are ever exposed to the service. - **Non-resident WebAuthn keys** may be preferable if you are highly security-conscious and prefer to have more control over where your private keys are stored and how they are used (e.g., hardware-based keys for MFA). In both cases, services **do not** have access to your private key. If synchronization across devices or cloud storage is a concern, non-resident WebAuthn keys provide a more controlled and isolated method of authentication. > But I've heard passkeys support multiple devices and keys are shared over the cloud. Is that wrong? You're correct! Passkeys **do** support synchronization across multiple devices, and the keys are shared via cloud services in many implementations. Let me clarify how this works: ### Passkey Synchronization Across Devices Passkeys are designed to offer both security and convenience, and part of this convenience is the ability to use the same passkey on multiple devices. In most passkey systems, the private key is stored in a **secure, cloud-synced manner**. For example: - **Apple** syncs passkeys using **iCloud Keychain**. - **Google** syncs passkeys using **Google Password Manager**. When you register a passkey, the private key is generated and stored in a **secure enclave** on your device (or similar trusted hardware, depending on the platform). However, to enable usage across multiple devices, the private key (or parts of it, depending on the design) is synchronized through the cloud. ### How Does Cloud-Synced Sharing Work? 1. **Secure Cloud Backup**: When using passkeys, your private keys are typically stored in a **secure vault** (e.g., iCloud Keychain or Google Password Manager). These services use **end-to-end encryption**, meaning that even the cloud provider cannot see or access your private key. The private keys are only accessible on your authenticated devices. 2. **Multiple Devices**: Once you have synchronized passkeys on multiple devices (e.g., phone, laptop, tablet), each device has access to the passkey via the secure cloud. This allows you to authenticate from any device in your ecosystem without needing to manually transfer keys between them. 3. **End-to-End Encryption**: During the syncing process, the private key is encrypted locally on your device before it is uploaded to the cloud, and only your devices can decrypt it. In theory, neither Apple, Google, nor any other service provider should be able to access or view your private keys. ### Security Considerations for Passkey Synchronization While passkeys offer a secure, cloud-synced authentication system, there are a few security implications you might want to consider: - **Cloud Dependency**: Your private keys are stored in the cloud, which means they are potentially accessible from multiple devices as long as you're signed into your account. This increases convenience, but also means that compromising your cloud account (e.g., iCloud or Google) could grant access to your passkeys. - **End-to-End Encryption**: The private keys are encrypted end-to-end, so they are secure during transit and storage. However, some users may still have concerns about their private keys being held in a cloud service, even if it's encrypted. ### Non-Resident WebAuthn Keys In contrast, **non-resident WebAuthn keys** (e.g., hardware security keys like YubiKeys) do not rely on cloud synchronization. These keys stay entirely on the external hardware device, and you physically use that device to authenticate. This avoids any reliance on cloud storage but requires you to carry the physical key with you. ### Should You Be Concerned? If you're comfortable with cloud synchronization and trust the security of services like iCloud or Google (which use strong encryption), **Passkeys** offer a highly secure and convenient method of authentication. However, if you want to avoid any cloud-based storage of private keys, you may prefer **non-resident WebAuthn keys**, which offer tighter control over your private keys since they're never uploaded or synced over the cloud. To summarize: - Yes, passkeys can be shared across multiple devices via cloud synchronization. - The synchronization is secure with end-to-end encryption, but the private keys are stored in the cloud. - If you're looking for more control and prefer to avoid cloud-based key storage, **non-resident WebAuthn keys** might be a better fit for you. > Wait, what? A private key is encrypted with another end-to-end-key? How is that end-to-end-key then retrieved on a second device? Great question! The process of securely syncing passkeys (which includes the private key) across multiple devices does rely on **end-to-end encryption**, but you're right to ask how this works. Let’s break it down: ### How Passkeys Are Synced Across Devices When passkeys are synced between devices via cloud services like iCloud Keychain or Google Password Manager, the **private key** (or a derivative of it) is encrypted using an end-to-end encryption key before being uploaded to the cloud. However, the tricky part is **how a second device can retrieve and decrypt the private key** if it doesn’t already have access to that key. Here’s how it works in principle: 1. **Secure Local Key Generation**: When you create a passkey on your device, a key pair is generated: a private key (which is stored in a secure enclave or TPM on the device) and a public key (which is sent to the service you're authenticating with). 2. **Encryption for Sync**: To allow syncing across multiple devices, the private key is encrypted using a key that **only your devices know**. This encryption key is part of the end-to-end encryption system. 3. **Second Device Retrieval**: - When you add a second device (e.g., a new phone or laptop), **authentication to the cloud provider** is required to verify that it’s really you. This might include **multi-factor authentication (MFA)**, biometrics, or other security mechanisms. - During this process, the **end-to-end encryption key** (or a recovery key) is transferred to the new device. This is typically done using a secure method like the **iCloud Keychain approval process** or Google’s equivalent. Here are a few mechanisms that can be used: - **Device-to-Device Transfer**: On some platforms, such as Apple's ecosystem, when you set up a new device, an existing trusted device can approve the new device. During this process, the encryption key is shared securely over a **proximity-based connection** (like Bluetooth or Wi-Fi Direct). - **Manual Entry of Recovery Codes**: Some systems allow you to generate and enter a **recovery code** or use a pre-shared secret. This ensures only you have access to the encryption key. - **Biometric Authentication**: In some ecosystems, you may be asked to authenticate using biometrics (e.g., Face ID, fingerprint) during the process of syncing data with another device. 4. **End-to-End Encryption Key Recovery**: Once your second device has authenticated and received the end-to-end encryption key (through one of the above methods), it can now decrypt the private key stored in the cloud. The private key is then securely stored in the new device’s secure enclave/TPM. 5. **Cloud Provider Cannot Access Keys**: During this whole process, the cloud provider (e.g., Apple, Google) **never has access** to the actual private keys or even the end-to-end encryption keys used to encrypt and decrypt them. Only your devices, which have been authenticated by you, can access and decrypt the data. ### Practical Example: Apple iCloud Keychain Syncing In Apple’s iCloud Keychain system: - When you set up a new device, **an existing trusted device** (such as your iPhone or Mac) is required to approve the syncing of your passkeys. The trusted device holds the key necessary to decrypt your private key. - Once approved, the new device securely receives the encryption key and can access your encrypted private keys from iCloud. Apple, in particular, uses techniques like **Secure Enclave**, **key wrapping**, and **device-to-device communication** to ensure that the encryption keys used for passkey synchronization remain secure. Google Password Manager operates similarly. ### Recovery Keys and Redundancy Most services that support passkey synchronization also offer some form of **recovery mechanism**: - **Recovery Key**: You can generate a recovery key or phrase that you keep secure. If you lose access to all trusted devices, this recovery key can be used to regain access to your passkeys on a new device. - **Account-Based Access**: In some cases, access to the account itself (e.g., your Apple ID or Google Account) and successful MFA (multi-factor authentication) can grant access to the decryption process. ### Why Is This Secure? - The private key is **never stored unencrypted** in the cloud, even during syncing. - Only your authorized devices (through secure methods like proximity-based transfer, recovery codes, or MFA) can decrypt and access the private key. - The cloud provider **cannot decrypt your private key** because they do not have the end-to-end encryption key—only your devices have it. ### Summary In essence: - Your passkeys are encrypted before being synced via the cloud. - The decryption key (used for end-to-end encryption) is securely transferred to new devices using either proximity-based authentication, recovery codes, or another strong authentication mechanism. - The cloud provider does not have access to your private key or the decryption key, ensuring your private key stays secure. > Why do I have another end-to-end-key at all then, if there is a method to securely transfer a key? I could transfer the private key directly from device to device then as well. You're absolutely right in thinking that if a private key can be securely transferred directly from one device to another, there wouldn't seem to be a need for additional end-to-end encryption (E2E) keys stored in the cloud. However, there's a crucial distinction between **direct device-to-device transfer** and **cloud-based key synchronization**, which explains why both methods (and an extra layer of encryption) are used. Let’s break it down: ### Direct Device-to-Device Transfer (No Cloud Involved) - **How it works**: In a **device-to-device transfer**, the private key (or the encryption key used to protect it) is transferred directly from one trusted device to another via a secure proximity-based method, such as Bluetooth, NFC, or Wi-Fi Direct. For example, when you set up a new iPhone or Mac, your existing device can approve and transfer the necessary key materials. - **Advantages**: This method is very secure because: 1. It doesn’t involve any cloud storage. 2. The data is transferred directly between devices, reducing the chance of interception. - **Limitations**: The biggest limitation is that **both devices need to be physically present** for the transfer to occur. If your old device is lost, broken, or unavailable, you can’t use this method. ### Cloud-Based Key Synchronization (Using E2E Encryption) The cloud-based method, which involves **end-to-end encryption**, addresses the limitations of direct device transfer by allowing passkeys to sync even if your devices are not physically near each other. - **How it works**: In cloud-based synchronization, the private key is stored in a cloud service (e.g., iCloud Keychain, Google Password Manager) and is encrypted with an E2E encryption key. This E2E key is either stored securely on your devices or transferred during account recovery processes. When you add a new device, this E2E key is retrieved and used to decrypt the private key on the new device. - **Advantages**: 1. **Convenience**: You don’t need your original device to be physically present. You can retrieve your passkeys on a new device even if your old device is unavailable. 2. **Redundancy**: If your devices are lost or stolen, the cloud service provides a backup of your passkeys (encrypted), and you can recover them using a recovery key or another trusted method. - **Limitations**: 1. **Cloud Involvement**: Some users are uncomfortable with even encrypted versions of their keys being stored in the cloud, even though the cloud provider cannot decrypt them. ### Why Use an End-to-End Encryption Key? The use of a separate **end-to-end encryption key** for syncing keys in the cloud is crucial for a few reasons: 1. **Device Availability**: - With direct device-to-device transfer, you would need both devices (old and new) at the same time. However, in real-world scenarios, users may lose, break, or sell their old devices before setting up a new one. By having an encrypted backup of the private key in the cloud, you can recover your passkeys even without the original device. 2. **Security in the Cloud**: - Even though the private key is stored in the cloud, it is **never stored in plaintext**. Using an end-to-end encryption key ensures that the private key remains secure and inaccessible to the cloud provider or any attacker. The E2E encryption key acts as a secure layer of protection, ensuring that only your devices (or your recovery process) can decrypt the private key. 3. **Seamless Synchronization Across Multiple Devices**: - Many users have multiple devices (e.g., phones, tablets, computers). Instead of manually transferring the private key between each device, cloud synchronization allows all devices to access the private key securely. The end-to-end encryption key allows this process to happen without needing your devices to be physically near each other every time you add a new device. 4. **Recovery Process**: - If your device is lost or stolen, having passkeys stored only on a lost device means you would lose access to those keys. Cloud-based sync with end-to-end encryption ensures that even in these cases, you can recover access to your passkeys using other methods (e.g., recovery keys, biometric authentication, or trusted device approvals). ### Why Not Just Use Direct Transfer Everywhere? - **Scalability**: If you own multiple devices, setting up each new one with a direct transfer would be cumbersome. Cloud sync with end-to-end encryption allows you to add new devices at any time, from anywhere, without needing access to an original device. - **Redundancy and Backup**: Direct transfer doesn’t provide a backup. If the original device is unavailable, there’s no way to recover your passkeys. Cloud-based storage with strong encryption provides redundancy and ensures that your keys are never completely lost. - **Ease of Use for Non-Technical Users**: Cloud synchronization with encryption is far more user-friendly for the average person. Direct device-to-device transfer is less flexible and could be confusing for users who are unfamiliar with secure key transfer methods. ### Summary - **Direct device-to-device transfer** is a secure way to move keys when both devices are present, but it doesn’t offer the convenience of recovery if your device is lost or broken. - **Cloud-based synchronization** with end-to-end encryption allows passkeys to be securely shared across devices and recovered when necessary, even if you no longer have your original device. - The use of an **end-to-end encryption key** ensures that even though your passkeys are backed up in the cloud, they remain encrypted and protected, with only your devices being able to decrypt them. This is why an extra encryption key is necessary for cloud syncing, providing flexibility and security simultaneously. If you prefer total control and never want your keys to be in the cloud, direct transfer is great, but most systems use E2E keys for flexibility and redundancy, especially for users who may lose or replace devices frequently. > I am still confused and think it is a bad idea to send your private key to another device or even into the cloud, no matter how strong the encryption is. It's perfectly reasonable to be cautious about where your **private key** is stored or transferred, even if encryption is involved. In security, the principle of keeping your private keys as local as possible and never transmitting them is foundational. Let me clarify further and address your concerns directly. ### Why Sending a Private Key (Even Encrypted) Feels Risky The main concern is that once your **private key** leaves the secure environment of your device, even if it is encrypted, it introduces potential risks: 1. **Cloud Storage Risks**: Even though the private key is encrypted in the cloud, there’s still a theoretical risk that the encryption scheme could be broken, or an attacker could gain access to the cloud data. If the key is improperly handled or a vulnerability is discovered, your private key could be compromised. 2. **Device-to-Device Transfer**: When transferring the private key to another device, even if done securely (e.g., over Bluetooth or Wi-Fi Direct), there's always a risk that the transfer process could be intercepted or that the new device could be compromised. This is why, traditionally, **private keys should never leave the device** in which they were created, unless absolutely necessary. This is how **non-resident WebAuthn keys** (typically stored on external devices like security keys) work—your private key stays on the physical security key and never leaves it, not even during authentication. ### The Case for Cloud-Synced Passkeys (Why It’s Considered Safe) Despite your concerns, passkeys aim to solve the balance between **security** and **usability**, and there are good reasons why the architecture is designed to sync via the cloud with strong encryption: 1. **End-to-End Encryption (E2EE) Makes the Cloud Trustworthy**: - In the case of **Apple iCloud Keychain** or **Google Password Manager**, the private key is **encrypted locally** on your device before it's uploaded to the cloud. This means even the cloud provider cannot decrypt it. The encryption keys are stored securely on your device or transferred using highly secure methods like biometrics or trusted device approvals. - While it's true that the cloud is involved, the security model assumes that only **you** can decrypt the data, even in the worst-case scenario where the cloud service is compromised. 2. **Redundancy**: - A key benefit of cloud synchronization is that you can recover your passkeys if you lose access to your original device. Without cloud syncing, losing your device might mean losing access to all accounts tied to that device's passkey—something many users can't afford to risk. 3. **User Convenience**: - For the average user, manually transferring private keys from device to device without cloud storage is inconvenient and often impractical. Passkeys need to be accessible across multiple devices (like phones, tablets, and laptops) to provide a seamless user experience, which is why cloud synchronization is essential for broad adoption. ### Why You Might Prefer Non-Resident WebAuthn Keys If you feel strongly about **not storing private keys in the cloud** or transferring them across devices, the best alternative is to use **non-resident WebAuthn keys**, like those provided by physical **hardware security keys** (e.g., YubiKeys, Google Titan keys). Here's why they might better align with your security preferences: 1. **Private Key Never Leaves the Hardware**: - With non-resident WebAuthn keys, the private key is generated and stored directly on a hardware device like a USB or NFC security key. It **never leaves** the device, not even during authentication. The only thing that is sent to the server during authentication is a **challenge response** signed by the private key. The private key remains protected on the hardware. 2. **No Cloud Involvement**: - Since the private key stays on the hardware device, there is no need to upload it to the cloud or sync it across multiple devices. This eliminates the risk of cloud-based attacks or data breaches affecting your private keys. 3. **Stronger Control**: - You have **physical control** over the private key. If someone wants to use your private key, they would need the physical device. This reduces the attack surface significantly, as an attacker would need to steal the hardware key to compromise your private key. 4. **Multi-Device Usage**: - You can still use your non-resident WebAuthn key across multiple devices, but each device uses the key only when it's physically connected (via USB, NFC, or Bluetooth). The private key never needs to be copied or transferred between devices. ### When to Use Non-Resident Keys vs. Passkeys - **Passkeys** (resident keys, with cloud sync): - Best for users who prioritize **convenience**. - Provides a **seamless experience** across multiple devices. - Secure **if you trust the cloud provider** and are comfortable with end-to-end encryption. - Suitable for users who frequently switch devices or might lose devices. - **Non-Resident WebAuthn Keys**: - Best for **security-conscious users** who want full control over where their private keys are stored. - The private key **never leaves the hardware key**, ensuring maximum protection. - **No reliance on cloud synchronization**, eliminating concerns about cloud vulnerabilities. - Requires the user to carry a physical hardware key, which could be inconvenient in some cases. ### Conclusion Your skepticism about sending the private key to the cloud, even if encrypted, is valid from a security perspective. If **absolute control** over your private key is your top priority, **non-resident WebAuthn keys** are a more secure option because they eliminate any potential risks from cloud storage or device-to-device transfer. However, for the majority of users, **passkeys with cloud sync** are a practical balance of convenience and security. The cloud-based syncing of passkeys uses robust end-to-end encryption to protect private keys, and while they are technically stored in the cloud, the private key remains inaccessible to anyone except your authorized devices. Ultimately, your choice should depend on how much convenience you're willing to trade off for control and security.