Encrypted Access Logging for Online Accounts: Device Attributions without Device Tracking

Encrypted Access Logging for Online Accounts: Device Attributions without Device Tracking

Speakers: Carolina Ortega Pérez, Cornell Tech

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=2pjdR5RUOPY

Overview

In an era where digital accounts permeate every aspect of life, ensuring their security and detecting compromise is paramount. This talk, presented by Carolina Ortega Pérez from Cornell Tech, introduces a novel approach to enhancing the integrity and privacy of Account Security Interfaces (ASIs), which are crucial tools for users to monitor their online activity. The research, a collaborative effort with Ala Defala and Tom Rristenport, addresses a critical vulnerability in current ASIs: their susceptibility to device spoofing. By proposing Clientside Encrypted Access Logging (CESL) protocols, the work aims to provide reliable device attribution without compromising user privacy through device tracking.

The motivation for this research is deeply rooted in real-world challenges, particularly those faced by survivors of intimate partner violence (IPV). As a volunteer at Sitta, a clinic dedicated to ending tech abuse, Pérez has observed firsthand how account compromise can be leveraged to cause harm. ASIs are intended to be a first line of defense, allowing users to identify illicit access. However, the ease with which device information can be manipulated renders these interfaces unreliable, making it difficult for survivors to discern legitimate from malicious activity. This paper offers a robust, privacy-preserving solution to restore trust in ASIs, providing users with the tools to effectively detect and mitigate account compromise, and even gather forensic evidence for legal processes.

Background

▶ Watch: Introduction: Account compromise as a tech abuse problem (0:00)

The proliferation of online accounts across various services has made digital security a cornerstone of personal safety. For many, particularly survivors of intimate partner violence (IPV), the integrity of these accounts can have profound real-world consequences. Abusive partners often gain illicit access to accounts either by knowing passwords or through access to unlocked devices. Even after discovery, immediate eviction of an abuser from an account might not be safe, making it critical for survivors to understand the history of access and identify unauthorized logins.

Account Security Interfaces (ASIs) are designed to address this need. These web interfaces allow users to review their account activity, including a log of devices from which their account has been accessed. In the context of tech abuse clinics like Sitta, ASIs are vital for helping survivors identify compromised accounts, remove malicious devices, and change passwords. However, as demonstrated by Follow et al. in 2023, the reliability of current ASIs is severely undermined by a fundamental flaw: they are remarkably easy to spoof.

The core vulnerability lies in how account platforms infer device information. During a login, the client (typically a web browser or application) sends HTTP requests that include login credentials and a user agent string. This user agent string contains details about the browser, operating system, and device. Platforms parse this string and display the derived device information in the ASI. The critical weakness is that the user agent string is client-controlled and can be effortlessly altered using standard developer tools, often requiring just a few clicks. An abuser, knowing the victim's device models, can easily change their user agent to mimic one of the legitimate devices. This results in duplicate or misleading entries in the ASI, making it impossible for the user to distinguish between genuine and malicious access, thereby hindering the ASI's primary goal of detecting compromise. This integrity problem necessitates a more robust solution, one that can provide verifiable device attribution independent of an untrusted client.

Key Findings

▶ Watch: Challenge: OS involvement reveals device IDs, privacy concern (5:10)

The central contribution of this research is the proposal of Clientside Encrypted Access Logging (CESL) protocols, designed to provide trustworthy device attribution in online account ASIs while preserving user privacy. The core insight is to involve the operating system (OS) as a trusted party, circumventing the untrusted browser or application layer.

The initial, naive approach of having the OS sign a static device identifier and send it to the server was quickly dismissed due to well-established privacy concerns. Sending static identifiers to service providers enables extensive device tracking, a practice that major vendors like Apple and Android have actively restricted for years. This led to a refined goal: achieving device attribution with privacy from the service provider.

The CESL protocols achieve this by leveraging OS-generated cryptographic keys. Instead of sending plain-text device identifiers, the OS generates a public/private key pair and a symmetric key for each device. Device identifiers are then encrypted using these symmetric keys, and the symmetric keys themselves are encrypted using the public keys of other devices associated with the same account. This multi-layered encryption ensures that the server stores only ciphertexts, preventing it from learning device identities. Only a legitimate device, possessing its corresponding private key, can decrypt the full log and verify the device attributions.

The paper formalizes three crucial security definitions: log privacy and session unlinkability against an honest-but-curious server, and the ability to access log entries. Log privacy ensures the server cannot read device IDs, while session unlinkability means the server cannot determine if two sessions originate from the same device. A significant finding is a theorem demonstrating that it's impossible to achieve full privacy while guaranteeing access to all historical log entries if the original decryption key (e.g., due to device loss) is unavailable. This trade-off is characterized by a "reachability graph" that defines which entries can be decrypted. The proposed scheme is proven to meet the privacy definitions, with log access constrained by this graph.

Finally, a proof of concept implementation in Python validates the practical feasibility of CESL. It demonstrates that the cryptographic operations and an extra network round trip during login introduce only a negligible performance overhead (a couple of milliseconds and kilobytes), making the solution practical for real-world deployment. The primary remaining challenge identified is the need for extensive collaboration with operating system vendors to integrate these capabilities at the OS level.

Technical Deep Dive

▶ Watch: New goal: Achieving privacy from the service provider (6:20)

The CESL protocol design is predicated on a carefully defined threat model and leverages the operating system as a secure anchor for cryptographic operations.

Threat Model:

1. Malicious Browser/Application: The client-side browser or application is explicitly considered untrusted. It cannot be relied upon to provide privacy or integrity for device information. This is the primary attack vector addressed by CESL.
2. Semi-Honest Server: The server is considered semi-honest. It desires to learn unspoofed device information but is not actively malicious in the sense of tampering with data or performing man-in-the-middle (MITM) attacks against the cryptographic protocol itself. The goal is to provide privacy from this server regarding device identifiers, meaning the server should not be able to link activity to specific physical devices. Preventing a fully malicious server from executing MITM attacks remains an area for future work.
3. Malicious User: An adversary who has successfully authenticated as the legitimate account owner (e.g., an abuser with the victim's password). This malicious user knows the victim's devices and attempts to impersonate them, primarily through user agent spoofing. This model acknowledges that account compromise prevention alone is insufficient; robust detection and forensic capabilities are also necessary.

Core Protocol Mechanics:

The CESL protocol fundamentally relies on the operating system to generate and manage cryptographic keys securely, ensuring that a malicious client-side application cannot extract or tamper with them.

1. Key Generation: For each device accessing an account, the OS generates:

• A public/private key pair (e.g., RSA or ECC) for asymmetric encryption.
• A symmetric key (e.g., AES key) for encrypting the device identifier.

1. Initial Login (Device 1):

• The user authenticates to the service.
• The client (browser/app) sends the user agent string.
• The OS on Device 1 encrypts its unique device identifier (ID1) using its symmetric key K1, producing Ciphertext_ID1.
• The OS also sends its public key (PK1).
• The server stores the user agent, Ciphertext_ID1, and PK1. At this stage, the server cannot learn ID1.

1. Subsequent Login (Device 2):

• The user authenticates.
• The server responds by sending all public keys associated with that account that it has stored so far (e.g., PK1).
• The client on Device 2 sends its user agent string.
• The OS on Device 2 encrypts its device identifier (ID2) using its symmetric key K2, yielding Ciphertext_ID2.
• The OS on Device 2 sends its public key (PK2).
• Crucially, Device 2 also encrypts its symmetric key K2 using each of the public keys received from the server (e.g., Encrypt(K2, PK1)). This creates Ciphertext_K2_for_PK1. The purpose of this step is to allow other devices (like Device 1) to eventually decrypt K2 and thus ID2.
• The server stores the user agent, Ciphertext_ID2, PK2, and Ciphertext_K2_for_PK1.

1. Accessing the ASI (e.g., from Device 1):

• When Device 1 requests the ASI, the server sends back all relevant log entries, including all stored user agents, public keys (PK1, PK2), encrypted device identifiers (Ciphertext_ID1, Ciphertext_ID2), and encrypted symmetric keys (Ciphertext_K2_for_PK1).
• Device 1, possessing its private key (SK1), can:
• Decrypt Ciphertext_ID1 using its K1 (which it stored locally or derived).
• Decrypt Ciphertext_K2_for_PK1 using its SK1 to recover K2.
• Use the recovered K2 to decrypt Ciphertext_ID2 and reveal ID2.
• This process allows Device 1 to reconstruct the full, verifiable log of device identifiers, while the server only ever handles encrypted data.

Deployment Architecture (FIDO2 Inspiration):

A major challenge is how the OS can securely interact with the server, especially given a malicious browser in the middle. The proposed architecture draws heavy inspiration from the FIDO2 framework and the WebAuthn API, which are widely deployed for passwordless authentication.

• OS/Authenticator Role: FIDO2 devices incorporate authenticators (e.g., hardware security modules, biometric sensors) that are certified by vendors. These authenticators securely generate and manage cryptographic keys for user authentication. The CESL proposal extends this concept by having the authenticator also act as an "encryptor."
• Key Management: Similar to how FIDO2 authenticators create signing key pairs for authentication, the CESL authenticator would create additional encryption key pairs. The public encryption key would be shared with the server, enabling the server to distribute it to other devices for the symmetric key encryption process described above.
• OS Attestation: FIDO2 uses attestation certificates to prove to the server that the authenticator is genuine and its keys were generated securely by a certified device. This mechanism can be adapted for CESL to provide authenticity for the OS-generated encryption keys, protecting against browser-based tampering.
• Server Authentication to OS: To prevent a malicious browser from performing a man-in-the-middle attack between the OS/authenticator and the legitimate server, the OS needs to authenticate the server. While not deeply elaborated in the paper, the authors envision using mechanisms similar to TLS (Transport Layer Security) and potentially a whitelist of trusted service providers to ensure the OS is communicating with the intended party.

This architectural approach effectively addresses the browser MITM problem. However, the current protocol still considers the server as semi-honest. A fully malicious server could theoretically perform a MITM attack against the user, which is acknowledged as a limitation and an area for future work.

Demo / Proof of Concept

▶ Watch: Solution: Encrypted Access Logging (CESL) protocol overview (8:00)

Carolina Ortega Pérez detailed the implementation of a proof of concept (PoC) for the CESL protocols, developed in Python. This PoC served to validate the practical feasibility of the proposed cryptographic operations and architectural interactions.

The key finding from the demonstration and performance analysis was that the overhead introduced by CESL is minimal and well within acceptable limits for a real-world system. Specifically, the cryptographic operations and the necessary extra round trip during the login process resulted in only "a couple of extra milliseconds and kilobytes in the payload."

It is important to note that these additional operations are not constant background processes. They occur only when a user logs in to an account or explicitly chooses to access their Account Security Interface (ASI). Given this infrequent execution, the slight increase in latency and data transfer is negligible in the overall user experience. The conclusion drawn is that, from a performance perspective, CESL is entirely practical.

The primary hurdle to deployment, as highlighted in the talk, is not technical performance but rather the significant collaboration required with operating system vendors. Integrating such a system necessitates fundamental changes at the OS level, particularly in how device identifiers are managed and how cryptographic keys are securely generated and utilized by applications. The authors are optimistic, however, noting that similar cross-industry collaboration has successfully occurred with the FIDO2 specifications, suggesting a precedent for such complex ecosystem shifts.

Defensive Implications

▶ Watch: CESL protocol prevents spoofing and ensures server privacy (9:10)

The CESL protocols offer significant defensive advantages for both end-users and online service providers, fundamentally improving the reliability of account security.

For Users:

• Enhanced Trust in ASIs: The most direct benefit is providing users with trustworthy device attribution in their Account Security Interfaces. No longer can a malicious actor easily spoof device information using simple user agent manipulation. This restores the ASI as a credible tool for detecting unauthorized access.
• Empowered Compromise Detection: Users can more reliably identify when their account has been accessed from an unfamiliar or unauthorized device, even if the attacker attempts to disguise their presence. This is particularly crucial for vulnerable populations, such as survivors of intimate partner violence, who depend on accurate information to assess and mitigate tech abuse.
• Potential Forensic Evidence: In cases of tech abuse, the integrity-protected log entries provided by CESL could serve as stronger forensic evidence for legal processes, offering a verifiable record of illicit access that is resistant to client-side tampering.

For Service Providers:

• Improved Security Posture: Implementing CESL allows service providers to offer a significantly more robust and secure experience for their users. It addresses a known and exploitable vulnerability in their existing ASIs, enhancing their overall security posture.
• Reduced Attack Surface: By leveraging OS-level security primitives, the system shifts trust away from the easily manipulated client application, effectively reducing the attack surface for device spoofing.
• Privacy-Preserving: The design ensures that service providers do not gain access to static, linkable device identifiers in plain text. This aligns with modern privacy principles and avoids inadvertently enabling device tracking, which is a critical concern for users and regulatory bodies.
• Ecosystem Collaboration: While challenging, embracing the CESL architecture implies engaging in industry-wide collaboration with OS vendors, similar to the FIDO2 initiative. This could lead to a more standardized and secure foundation for online account security across the digital ecosystem.

General Security Posture:

The work represents a shift from solely focusing on account compromise prevention to also providing robust mechanisms for detection and mitigation after a compromise has occurred. It underscores the growing importance of involving the operating system as a trusted computing base for critical security functions, rather than solely relying on application-layer defenses that are often vulnerable to client-side manipulation. The adoption of CESL would represent a significant step forward in securing online accounts against sophisticated client-side attacks while upholding user privacy.

Key Takeaways

• Current Account Security Interfaces (ASIs) are fundamentally flawed, allowing malicious actors to easily spoof device information via user agent manipulation, thereby hindering the detection of account compromise.
• Clientside Encrypted Access Logging (CESL) protocols address this by leveraging the operating system as a trusted entity to generate and manage cryptographic keys, ensuring the integrity of device attribution data.
• CESL prioritizes user privacy by encrypting device identifiers before they are sent to the service provider, preventing the server from learning static, linkable device information and enabling device tracking.
• The proposed architecture draws inspiration from the widely adopted FIDO2 framework and WebAuthn API, extending the role of hardware authenticators to also securely generate and manage encryption keys for CESL.
• A Python proof of concept demonstrates that CESL is practically feasible, introducing only minimal performance overhead (a couple of milliseconds and kilobytes) during login or ASI access.
• Successful real-world deployment of CESL requires significant, cross-industry collaboration between online service providers and operating system vendors to integrate the necessary OS-level cryptographic primitives.

About the Speaker(s)

Carolina Ortega Pérez is a researcher at Cornell Tech, where she is engaged in work that bridges the gap between theoretical computer science and real-world security challenges. Her research on encrypted access logging for online accounts reflects her commitment to enhancing digital safety and privacy. Pérez's work is deeply influenced by her practical experience as a volunteer at Sitta, a clinic in New York dedicated to combating tech abuse. Through Sitta, she works directly with survivors of intimate partner violence (IPV) to help them navigate and regain control of their digital environments after experiencing account compromise and other forms of tech-facilitated abuse. This firsthand understanding of user vulnerabilities and the critical need for reliable security tools forms the core motivation behind her research contributions.