Proteus: A Practical Framework for Privacy-Preserving Device Logs

Proteus is a practical, low-overhead framework for Android device logs that ensures privacy-preserving forensic analysis by combining keyed-hash pseudonymization with time-rotating encryption to prevent PII exposure and multi-snapshot correlation while maintaining data fidelity.

The Gist

Imagine you own a smartphone that is constantly writing a diary. This diary, called a device log, records everything you do: who you texted, where you went, what apps you used, and even your health data.

Companies and security teams need to read these diaries to catch hackers, stop fraud, or solve crimes. But here's the problem: these diaries are too honest. They contain your name, your home address, your medical history, and your private messages. If a company steals this diary or a hacker breaks into their server, your entire private life is exposed.

Current solutions are like trying to fix a leaky boat by bailing water with a spoon. They either:

1. Redact (Black out) the text: This hides your name, but it also hides the fact that "Alice" logged in three times. You lose the ability to connect the dots.
2. Encrypt the whole thing: This keeps it safe, but then no one can read it at all, even when they need to solve a crime.

Enter Proteus. Think of Proteus as a magical, privacy-preserving translator for your phone's diary.

The Core Idea: "Linking without Knowing"

The big breakthrough in this paper is a simple insight: To solve a crime, you don't need to know who someone is; you just need to know that two events happened to the same person.

Proteus achieves this using a two-step "magic trick" for every piece of sensitive information (like an email address or phone number) before it ever leaves your phone.

Step 1: The "Secret Code" (Pseudonymization)

Imagine you write "Alice" in your diary. Proteus takes that name and runs it through a special, secret machine (a keyed hash) that turns it into a unique code, like X7-99-Alpha.

• The Magic: If you write "Alice" again later, the machine produces the exact same code (X7-99-Alpha).
• The Result: The security team can see that X7-99-Alpha appeared at 9:00 AM and again at 5:00 PM. They know it's the same person. But they cannot turn the code back into "Alice." The code is a one-way street.

Step 2: The "Daily Lock" (Time-Rotating Encryption)

Here is where it gets really clever. What if a hacker steals the diary today, and then steals it again tomorrow? If the code X7-99-Alpha stays the same, the hacker can link all your activities over time.

Proteus solves this by putting the code inside a daily changing lockbox.

• Every 24 hours, the phone generates a brand new key to lock the diary.
• The code X7-99-Alpha from Monday is locked with Monday's key.
• The same code on Tuesday is locked with Tuesday's key.
• The Result: Even if a hacker steals the diary every day, they can't connect Monday's entries to Tuesday's entries because the locks are different. This is called Forward Secrecy.

How the "Controlled Sharing" Works

So, how does a detective actually solve a crime if they can't read the names?

Proteus introduces a Time-Bounded Key Handoff.

1. The Request: A forensic team says, "We need to investigate a specific incident that happened on October 15th."
2. The Grant: Your phone (with your permission) generates a special, temporary key only for October 15th. It sends this key to the detective.
3. The Reveal: The detective uses this key to unlock the diary only for that day. They can see the codes (X7-99-Alpha) and link the events.
4. The Safety Net: The moment the key is sent, your phone immediately changes its master lock (rotates the root key). The detective can never unlock future entries, and because they don't have the "Secret Code" machine's master key, they still can't turn X7-99-Alpha back into "Alice."

Why This is a Big Deal

The paper tested this on real phones (from 2017 to 2022) and found it to be incredibly fast and efficient.

• Speed: It adds a delay of only 0.2 milliseconds per message. That's faster than you can blink. Your phone won't feel slow.
• Size: It only makes the log files about 2.4% larger. It's like adding a tiny bit of padding to a letter; it doesn't fill up your mailbox.
• Security: It uses a "Double Ratchet" system (similar to the one used in WhatsApp and Signal) to ensure that even if a hacker gets inside your phone today, they can't read your logs from yesterday or predict your logs for tomorrow.

The Analogy Summary

Imagine your phone is a spy sending reports to headquarters.

• Old Way: The spy sends a report saying, "Agent Smith went to the bank." Headquarters sees the name, but if the report is stolen, the enemy knows it's Agent Smith.
• Redaction Way: The spy sends, "Agent [REDACTED] went to the bank." Headquarters sees the bank, but can't tell if it's the same agent who went to the gym later.
• Proteus Way: The spy sends, "Agent Code-99 went to the bank."
  • Headquarters sees Code-99 went to the bank, then the gym, then the park. They know it's the same agent.
  • If the enemy steals the report, they only see Code-99. They have no idea who that is.
  • If Headquarters needs to know who it is, they ask the spy for a one-time passcode for that specific day. The spy gives it, they decode the name for that day, and then the spy immediately changes their identity code for the next day.

Proteus allows us to have the best of both worlds: the deep, detailed analysis needed to catch criminals, without ever sacrificing the privacy of the innocent people whose data is being collected.

Technical Summary

Here is a detailed technical summary of the paper "Proteus: A Practical Framework for Privacy-Preserving Device Logs."

1. Problem Statement

The collection of device logs for forensic investigations, enterprise monitoring, and fraud detection has shifted from corporate-controlled workstations to user-owned mobile devices (BYOD, IoT, consumer electronics). This shift creates a fundamental privacy dilemma:

• PII Leakage: Granular logs essential for security analysis inevitably contain Personally Identifiable Information (PII) such as emails, location history, and device IDs. When these logs are exported to third-party servers (often "honest-but-curious" cloud platforms), PII is exposed.
• Limitations of Existing Solutions:
  • Post-hoc Redaction: Sanitizing logs after collection exposes PII during transmission and storage and destroys the ability to correlate events.
  • Client-side Taint Tracking: High runtime overhead and poor coverage of proprietary binaries.
  • Differential Privacy: Sacrifices per-event fidelity, making it useless for forensic timeline reconstruction.
  • Encrypted Logs: Often require wholesale decryption for analysis, exposing PII, or lack mechanisms for controlled, time-bounded access.
• The Core Challenge: How to enable forensic correlation (linking related events across time and devices) without ever exposing the plaintext PII values, even to adversaries who capture multiple log snapshots over time.

2. Methodology: The Proteus Framework

Proteus is an in-situ logging framework designed to protect PII at the point of generation on the device. It operates as a transparent extension to Android's logcat and relies on a two-layer cryptographic scheme anchored in hardware attestation.

A. Core Architecture

• Hardware Root of Trust: Proteus utilizes DICE (Device Identifier Composition Engine), a TCG-standardized hardware-rooted attestation mechanism. It derives a unique, hardware-bound CDI (Device Configuration Identifier) from device measurements.
• Key Hierarchy:
  • Root Key ($R_0$): Derived from the CDI and a server public key. It anchors the system to the specific device state.
  • Hash Key ($K_{hash}$): A long-term key derived from the CDI, used only on-device for pseudonymization. It is never shared with the server.
  • Ratchet Keys: A hierarchical ratcheting mechanism generates daily encryption keys.

B. The Two-Layer Protection Scheme

When a log message containing PII is emitted, Proteus applies two layers of protection:

1. Layer 1: Keyed-Hash Pseudonymization:
   • The plaintext PII (e.g., an email address) is hashed using a keyed HMAC with the device-specific $K_{hash}$.
   • This produces a stable pseudonymized token.
   • Benefit: Identical PII values always produce the same token, enabling correlation and timeline reconstruction without revealing the actual value.
2. Layer 2: Time-Rotating Encryption:
   • The pseudonymized token is encrypted using an authenticated encryption scheme (AEAD) with a daily-rotated ephemeral key ($K_t$).
   • The daily key is derived from a chain key ($ck_t$) using a one-way Key Derivation Function (KDF).
   • Benefit: Prevents multi-snapshot adversaries (who capture logs over time) from correlating tokens across different days. Even if a daily key is compromised, past logs remain secure (Forward Secrecy).

C. Controlled Sharing Protocol

To allow forensic analysis, a controlled sharing protocol grants time-bounded access:

• Grant Generation: The client exports the ratchet state (chain key) for a specific time window ($t^*$ to current) to the server.
• Decryption: The server uses this state to derive the daily decryption keys for that window.
• Token Recovery: The server decrypts the ciphertext to recover the pseudonymized tokens.
• Crucial Security Property: The server never receives $K_{hash}$. Therefore, it can link events (e.g., "User X logged in at 9 AM and 10 AM") but cannot reverse the hash to discover "User X is [e-mail]."
• Post-Compromise Security: Immediately after a grant is issued, the client rotates the root key ($R_0$) using fresh entropy from a Diffie-Hellman exchange. This severs the cryptographic chain, ensuring the server cannot decrypt logs generated after the grant window.

3. Key Contributions

1. First In-Situ Privacy Framework: Proteus is the first system to protect sensitive data at the point of emission, ensuring plaintext PII never leaves the device while maintaining full forensic utility.
2. Formal Threat Model: Defines a rigorous threat model for mobile endpoints involving multi-snapshot on-device observers and honest-but-curious cloud servers.
3. Hierarchical Ratcheting: Introduces a novel double-ratchet construction (inspired by Signal's Double Ratchet but adapted for logging) that provides forward secrecy and post-compromise security against time-based correlation attacks.
4. Provable Security: Provides a game-theoretic proof demonstrating that Proteus achieves confidentiality and forward secrecy properties analogous to Signal's protocol.
5. Practical Implementation: A working Android library integrated with logcat across three generations of hardware.

4. Evaluation Results

The authors evaluated Proteus on three generations of Android devices (Pixel 2, Tab S6, Pixel 6a) using a dataset of 30.3 million log entries.

• Performance Overhead:
  • Latency: Median latency of 0.2 ms per message.
  • Storage: Average size overhead of 97.1 bytes per PII field, resulting in a total storage increase of only 2.41% for the dataset.
  • Throughput: Capable of handling high message rates comparable to native Android logging.
• Bottlenecks: The primary performance cost comes from PII detection (regex matching) and format processing (string replacement), not the cryptographic operations.
• Scalability: The system scales linearly with the number of PII occurrences, not total log volume, making it suitable for production environments.

5. Significance

Proteus resolves the long-standing trade-off between observability and privacy in mobile security.

• Regulatory Compliance: It enables organizations to collect necessary forensic data without violating GDPR, CCPA, or other privacy regulations regarding PII handling.
• Forensic Utility: Unlike differential privacy or redaction, Proteus preserves the ability to reconstruct attack timelines and link events across sessions, which is critical for incident response.
• Adoption Path: By integrating transparently with existing logging APIs and requiring only standard hardware support (DICE), it offers a viable path for deployment in enterprise BYOD and consumer IoT ecosystems.

In summary, Proteus demonstrates that it is possible to build a logging system where the server can perform deep forensic analysis on device behavior without ever seeing the raw identities of the users, effectively neutralizing the risk of PII leakage in cloud-based analytics.