Google Authenticator: The Hidden Mechanisms of Passwordless Authentication
This architectural analysis details the hidden mechanisms behind Google's synced passkeys, revealing a hybrid model that leverages a cloud-based authenticator (enclave.ua5v[.]com) for sensitive cryptographic operations while anchoring trust to local hardware keys. Understanding this infrastructure is critical for defenders to anticipate emerging attack vectors in passwordless authentication environments.
Authors: Unit 42
Source:
Palo Alto Networks
- domaincaBLE[.]ua5v[.]comDomain associated with CTAP Hybrid transports (tunnel service) for passkey authentication.
- domainenclave[.]ua5v[.]comUndocumented cloud-based authenticator domain used by Google Chrome for synced passkey operations.
- filename%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDBChrome sync database storing WebauthnCredentialSpecifics for synchronized passkeys.
- filename%LocalAppData%\Google\Chrome\User Data\<Profile>\passkey_enclave_stateLocal file storing wrapped device keys, identity public keys, and encrypted security domain secrets.
- urlwss://enclave[.]ua5v[.]com/enclaveWebSocket endpoint used by Chrome to establish a secure Noise protocol tunnel with the cloud authenticator.
Key Takeaways
- Google's synced passkeys rely on an undocumented, cloud-based authenticator operating at enclave.ua5v[.]com.
- The architecture uses a hybrid model where sensitive cryptographic operations occur in an isolated cloud environment but remain anchored to hardware-backed keys (TPM) on the local device.
- Communication between Chrome and the cloud authenticator is secured using OAuth2 tokens, WebSockets, and the Noise Protocol Framework (Noise_NK_P256_AESGCM_SHA256).
- Local state, including wrapped keys and secrets, is stored in a specific file named passkey_enclave_state within the Chrome User Data profile.
Affected Systems
- Google Chrome on desktop platforms (Windows, macOS, Linux, ChromeOS)
- Systems utilizing Trusted Platform Module (TPM) for hardware-backed keys
Attack Chain
This report details system architecture rather than an active attack chain. The authentication flow begins with device onboarding, where Chrome generates TPM-backed Identity and User Verification (UV) keys and registers them with the cloud authenticator. When creating or using a passkey, Chrome establishes a secure WebSocket connection using OAuth2 and the Noise Protocol Framework, allowing the cloud authenticator to perform cryptographic operations using a synchronized Security Domain Secret without exposing plaintext keys to the local device.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No specific detection rules are provided in this architectural overview.
Detection Engineering Assessment
EDR Visibility: Medium — EDR can monitor file access to the passkey_enclave_state and LevelDB directories, as well as network connections to enclave.ua5v.com made by Chrome. Network Visibility: Medium — Network telemetry can observe DNS resolutions and WebSocket connections to enclave.ua5v.com, though the payload is encrypted via the Noise protocol. Detection Difficulty: Hard — The communication is heavily encrypted (Noise Protocol over WebSockets) and blends in with legitimate Chrome sync traffic. Distinguishing malicious impersonation from legitimate usage requires deep inspection of local key access.
Required Log Sources
- EDR File Activity
- Network Proxy/Flow Logs
- Windows API monitoring (CNG API)
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| An attacker attempting to extract passkey state will access the passkey_enclave_state file from a non-browser process. | File access logs targeting %LocalAppData%\Google\Chrome\User Data*\passkey_enclave_state. | Credential Access | Low (Only Chrome and backup tools should typically access this specific file). |
Control Gaps
- Lack of visibility into the encrypted Noise protocol tunnel
- Difficulty distinguishing legitimate Chrome OAuth2 token requests from malicious ones
Key Behavioral Indicators
- Access to passkey_enclave_state by unusual processes
- Connections to enclave.ua5v.com from non-browser processes
Recommendations
Immediate Mitigation
- Monitor access to Chrome's User Data directory, specifically the passkey_enclave_state file, for unauthorized access by non-browser processes.
Infrastructure Hardening
- Implement Identity Threat Detection and Response (ITDR) solutions to monitor anomalous authentication patterns.
- Ensure robust endpoint protection is deployed to prevent malware from accessing local Chrome state files.
User Protection
- Ensure devices utilizing synced passkeys have strong local authentication (Windows Hello/biometrics) enabled and enforced.
Security Awareness
- Educate security teams on the hybrid cloud/local architecture of modern passkeys to better understand the evolving attack surface.
MITRE ATT&CK Mapping
- T1556 - Modify Authentication Process
- T1528 - Steal Application Access Token
- T1552.001 - Credentials In Files
Additional IOCs
- Ips:
142[.]250[.]75[.]170- IP address observed resolving to www.googleapis.com during OAuth2 token request.142[.]250[.]75[.]174- IP address observed resolving to enclave.ua5v.com during WebSocket upgrade.52[.]41[.]96[.]105- IP address observed resolving to webauthn.io during passkey authentication testing.
- Urls:
hxxps://www[.]googleapis[.]com/auth/secureidentity.action- OAuth2 scope requested by Chrome to authorize cloud authenticator operations.