Although synced passkeys have been awarded AAL2 by the NIST 800-63-3/4 standard, they lack the following properties:
– FIDO Alliance Certification Level: Not Available
– Attestation: Not Available
Because of these missing protections, protection for synced passkeys is implemented through a layered design that combines hardware isolation, user verification, end-to-end encryption, and zero-knowledge cloud storage. As a result, Exostar recommends only using the following platforms for synced passkeys:
– Apple iCloud
– Microsoft Authenticator
– Google Password Manager
Below is a breakdown of how this protection actually works in the real ecosystems (Apple, Google, Microsoft) and what the core security model is, independent of vendor.
Architectural Overview
A synced passkey is a FIDO2/WebAuthn credential where:
-
The private key is created and stored on a trusted local device (TPM, Secure Enclave, Android Keystore, etc.).
-
A cloud copy of that key is stored only after it has been encrypted end-to-end under a key known solely to the user’s devices (and sometimes their account credentials).
-
Other devices logged into the same account can decrypt and import that credential, preserving continuity without giving the cloud provider visibility into the key material.
The protection model guarantees:
-
The provider never sees plaintext private keys.
-
A compromise of the provider’s cloud does not compromise user credentials.
-
Only verified devices belonging to the same user (or managed account) can decrypt and use the keys.
Key Generation and Hardware Protection
The following table describes key generation process and corresponding hardware protection and how each platform uses hardware attestation to tie the credential to a genuine hardware security element:
| Step | Mechanism | Security Property |
|---|---|---|
| Key creation | Generated locally via FIDO2 API using secure hardware module (TPM / Secure Enclave / Titan M / Keystore) | Ensures entropy and prevents key extraction |
| Private key storage | Non-exportable key in hardware or OS keychain | Prevents raw key access, even by OS or malware |
| User verification | Biometric or PIN via platform authenticator | Guarantees live user presence; mitigates malware triggering signing silently |
Local Encryption and Cloud Sync
Before synchronization, the private key and metadata (i.e., RP ID, credential ID, algorithm) is wrapped in an encryption layer derived from user secrets using following strategies:
-
Encryption scheme:
-
Uses AES-256-GCM or ChaCha20-Poly1305 for confidentiality + integrity.
-
The encryption key is derived via PBKDF2 / Argon2 / HKDF from a user-specific master secret.
-
That master secret is usually derived from a key stored in the secure element or a key obtained through device-to-device bootstrap.
-
-
End-to-End model:
-
The provider’s cloud sees only ciphertext.
-
Sync servers manage versioning and delivery but cannot decrypt contents.
-
Only devices enrolled under the same identity and possessing the sync decryption key can read it.
-
Cross-Device Trust Establishment
When a new device is added the following process is followed:
- The user verifies identity (biometric + account credentials).
- A secure device-to-device channel is created (QR, Bluetooth, or out-of-band ECDH).
- The existing device transmits the decryption key or recovery secret over that channel.
- The new device can now decrypt synced passkeys and join the trust circle.
This ensures the user must prove control of an already-trusted device before expanding the circle.
Recovery and Backup
Different vendors implement recovery differently but all aim for zero-knowledge:
-
Apple: iCloud Keychain Escrow with multi-party threshold HSMs. The escrow key is encrypted with the user’s device secret and a recovery key. Apple’s HSM cannot decrypt unilaterally.
-
Google: Encrypted with a key split between device and account; recovery requires both factors.
-
Microsoft: Uses account-linked encryption, Authenticator app trust, and optionally hardware-bound credentials.
The recovery systems never hold the plaintext or a single decryption factor alone.