Detecting Compromise of Passkey Storage on the Cloud

The Problem: The Security Paradox of Synced Passkeys

Passkeys, based on the FIDO2 standard’s asymmetric signature scheme, represent a significant security upgrade from traditional passwords. During registration, a user’s device generates a private key (SK), which remains on the device, and a public verification key (VK), which is sent to the relying party (the website or service). This architecture makes passkeys resistant to phishing and guessing attacks because the private key is never supposed to leave the user’s device.

However, this device-bound nature created a major usability issue: if a user loses their device, they lose access to their accounts. To solve this account lockout problem, the industry introduced synced passkeys. Services like Apple’s iCloud Keychain and Google’s Password Manager act as passkey providers, backing up the user’s private keys to their cloud storage.

This solution, while convenient, introduces a new and severe security threat. If the passkey provider’s cloud storage is breached, an attacker can gain unauthorized access to users’ passkeys. With these stolen credentials, an attacker can seamlessly log into the user’s accounts. The threat is magnified because many relying parties, trusting the inherent security of passkeys, may not trigger secondary-factor authentication for passkey-based logins.

Introducing CASPER: A Deception-Based Detection Framework

The central research question addressed is: How can a relying party detect unauthorized logins that result from a passkey provider’s compromise? The proposed solution is CASPER, a framework compatible with existing passkey implementations that enables relying parties to detect the use of leaked passkeys.

CASPER operates on a decoy-based deception mechanism. This differs from traditional decoy password systems where the credential leakage occurs at the relying party. In this scenario, the leakage happens at a third party (the passkey provider), and a different entity (the relying party) must detect it.

A simple solution like encrypting the passkey with a high-entropy master password before uploading it is ineffective because it reintroduces the original account recovery problem—users forget complex passwords or lose the devices holding the keys.

How CASPER’s Deception Mechanism Works

CASPER’s core innovation is using a low-entropy secret for detection rather than for primary security. While a low-entropy secret is easily guessable by an attacker, CASPER leverages this by creating a deception game.

The framework operates in three main steps:

1. Provider Account Setup: When a user creates an account with a passkey provider, CASPER generates a set of K+1 detection secrets. One is the real secret, and K are decoys. These are stored with the provider. A separate low-entropy secret (eta), known only to the user, is used to deterministically identify the real detection secret from the set.

2. Relying Party Registration:

   • The real detection secret is used to derive an encryption key, which encrypts the user’s actual passkey (SK) into an encrypted blob (SK~). This encrypted version is what gets backed up to the provider’s cloud storage; the plaintext passkey never leaves the device.
   • The system then uses all K+1 detection secrets (the real one and K decoys) to “decrypt” SK~. This process generates one real passkey and K well-formed decoy passkeys.
   • Finally, the corresponding K+1 verification keys (one real, K decoys) are generated and sent to the relying party.

3. Authentication and Compromise Detection:

   • Legitimate User: A legitimate user, possessing the low-entropy secret eta, can derive the real detection secret, obtain the real passkey SK from SK~, and correctly sign the authentication challenge. The relying party verifies the signature against the real VK and grants access.
   • Attacker: An attacker who breaches the provider’s storage gets SK~ and the K+1 detection secrets but does not know eta. They must guess which secret is the real one. With high probability, they will choose a decoy secret, generate a signature with a decoy passkey, and send it to the relying party.
   • Detection: When the relying party receives a signature corresponding to a decoy verification key, it raises an alert, successfully detecting that an attacker is attempting to use a leaked passkey.

Effectiveness, Usability, and Deployment

The effectiveness of CASPER was validated using model checking, modeling the attacker with a Markov Decision Process. The results are compelling:

• With 32 decoys and a user secret containing only 5 bits of entropy, CASPER achieves a detection accuracy of over 95% against an optimal attacker.
• Instantiating such a secret is practical. A single random, case-insensitive alphanumeric character contains over 5 bits of entropy, and a two-digit PIN contains over 6 bits. The secret can also be a biometric.

CASPER is designed to be practical and user-friendly:

• Deployability: It is compatible with existing passkey implementations and adds negligible performance or storage overhead.
• User Experience: The user only interacts with the low-entropy secret when setting up a new device or the provider account. Their daily login behavior remains unchanged.
• Preventing Collusion: To prevent a compromised relying party from trying to deduce the user’s secret, CASPER can be configured to mark only a subset of the decoy keys as “active verifiers,” further obfuscating the system.

• Tags:
• Cybersecurity
• Passkeys
• Authentication
• FIDO2
• Deception Technology
• CASPER