Encrypted Access Logging for Online Accounts: Device Attributions without Device Tracking
Client-Side Encrypted Access Logging (CSAL) is a proposed protocol that uses OS-level cryptography and FIDO2-style attestations to create trustworthy, privacy-preserving account activity logs, resolving the tension between preventing user tracking and accurately detecting account compromise.
Online accounts can be leveraged to cause interpersonal harm, with account compromise being a primary issue faced by survivors of intimate partner violence (IPV). A common tactic for abusers is to gain illicit access to a survivor’s accounts, often by knowing their password. Account Security Interfaces (ASIs), which display recent login activity, are intended to help users detect such compromise. However, these ASIs are fundamentally untrustworthy as they rely on the client-provided user-agent string, which can be easily spoofed using browser developer tools. An abuser can alter this string to mimic one of the survivor’s legitimate devices, making their malicious login indistinguishable from a legitimate one and undermining the ASI’s purpose.
This integrity problem stems from a core tension: accurately attributing access to a specific device requires a stable identifier, but providing such an identifier to a service provider creates significant privacy risks related to user tracking.
Introducing Client-Side Encrypted Access Logging (CSAL)
Client-Side Encrypted Access Logging (CSAL) is a protocol designed to navigate this tension between privacy and utility. It provides robust device attribution without revealing trackable identifiers to the service provider. The protocol is agnostic to the authentication mechanism and operates with the following threat model:
- Trusted OS: The operating system is considered a fully trusted party responsible for key management and cryptographic operations.
- Malicious Browser/App: The client-side browser or application is untrusted and may attempt to violate integrity or privacy.
- Semi-Honest Server: The service provider is “honest-but-curious,” meaning it follows the protocol but will try to learn device information from the data it stores.
- Malicious User: An attacker who can successfully authenticate as the legitimate user.
The core idea is to use the OS to generate and manage cryptographic keys for each device session.
-
Initial Login: When a device logs in for the first time, the OS generates a public/private key pair (
PK1,sk1) and a symmetric key (K1). It sends the login information, its public key (PK1), and a device identifier that has been encrypted with the symmetric key (K1) to the server. The server stores the public key and the ciphertext. -
Subsequent Logins: When a second device logs in, it first authenticates. The server then provides it with the set of all public keys associated with the account (e.g.,
PK1). The new device generates its own keys (PK2,sk2,K2), encrypts its device ID withK2, and then encryptsK2using the public key of the first device (PK1). The server stores the new public key (PK2), the encrypted device ID, and the encrypted symmetric key. -
Viewing the ASI: When a user requests their ASI, the server returns the entire log of ciphertexts. The user’s device can use its own private key(s) to decrypt the symmetric keys of other sessions, which in turn allows it to decrypt the device identifiers for those sessions. This provides the user with a ground-truth view of which devices accessed their account, as the encrypted identifiers are signed and managed by the trusted OS.
Security, Privacy, and the Reachability Challenge
The CSAL protocol provides two main security guarantees against a semi-honest server:
- Log Privacy: The server cannot read the device identifiers, as it only ever stores ciphertexts.
- Session Unlinkability: The server cannot determine if two separate sessions originated from the same device, as each session uses fresh, randomized cryptographic material.
However, a fundamental challenge arises: there is an inherent trade-off between full privacy and the ability to access the entire log history. If a device is used only once and then is lost or destroyed (the “falls into the lake” problem), the keys needed to decrypt its log entries are gone forever. No new device can recover that information.
To mitigate this, the protocol includes a re-encryption mechanism. When an older device comes back online, it can fetch the public keys of newer sessions and re-encrypt its symmetric key for them. This process builds a “reachability graph,” where nodes are sessions and edges represent the ability to decrypt. Over time, as devices reconnect, they can share decryption capabilities, allowing newer devices to eventually access a more complete history of the log.
A Practical Deployment Architecture via FIDO2
To defend against an active, man-in-the-middle attack from a malicious browser, the protocol requires a way to authenticate both the OS and the server. The proposed architecture models this on the FIDO2/WebAuthn framework.
The idea is to extend the FIDO2 “authenticator” (the secure hardware/software that manages passkeys) to also function as an “encryptor.” During registration, the device would use FIDO2-style attestations to send a certified public encryption key to the server, proving it was generated within a trusted environment. This leverages the existing, widely deployed infrastructure for hardware-backed key management and prevents the browser from tampering with key exchanges. Server authentication could be handled through a TLS-like certificate infrastructure.
A proof-of-concept Python implementation demonstrates that the protocol is practical, adding approximately 146ms to the login process for a single session. The primary obstacle to deployment is not performance but the ecosystem-level collaboration required between OS vendors and service providers.