A TEE-Based Architecture for Confidential and Dependable Process Attestation in Authorship Verification

This paper presents a novel TEE-based architecture for continuous process attestation that ensures tamper-resistant evidence collection and high availability through a resilient chain protocol and formal dependability modeling, achieving low overhead and rapid recovery in Intel SGX evaluations.

The Gist

Imagine you are a famous author, and someone claims they wrote a masterpiece. But you suspect they didn't write it at all; maybe they hired a ghostwriter, or worse, they used a computer program to generate the whole thing instantly.

How do you prove, beyond a shadow of a doubt, that a real human sat down and typed those words over several hours?

This paper proposes a high-tech solution to that problem, but with a twist: it assumes the person trying to cheat is the one holding the computer.

Here is the story of how this system works, explained simply.

The Problem: The "Honesty Box" Paradox

Usually, when we verify something, we trust the computer to tell the truth. But in this scenario, the "Attester" (the person claiming they wrote the book) controls the computer. They can turn it off, fake the data, or edit the logs. It's like asking a suspect to write their own alibi.

If the software is running on their machine, they can just lie. The paper calls this "Trust Inversion." The person you are trying to verify is the one in charge of the evidence.

The Solution: The "Glass-Box" Safe (TEE)

To solve this, the authors use a technology called a Trusted Execution Environment (TEE).

Think of a TEE as a magic, unbreakable glass safe inside the computer.

• The bad guy (the author) controls the whole house (the computer).
• But inside the house, there is this one glass safe that only the "Verifier" (the person checking the work) can see into.
• The bad guy can't break the glass, can't peek inside, and can't change what happens inside. They can only turn the power off or unplug the safe.

The system runs the "evidence collection" entirely inside this safe. It records every keystroke, the time between them, and the rhythm of typing. Because the safe is hardware-protected, the bad guy can't fake the data inside it.

The Challenge: What if the Safe Breaks?

Here is the tricky part: Even magic safes can crash. The computer might lose power, the software inside the safe might glitch, or the internet might go down.

If the safe crashes, the "chain of evidence" breaks. If you lose the chain, you lose the proof that the writing happened continuously.

The authors designed a system that is resilient, meaning it can survive these crashes without losing the story.

1. The "Sealed Diary" (Crash Recovery)

Imagine the safe writes a diary entry every 30 seconds.

• Normal: It writes the entry, seals it in an envelope, and sends it to the verifier.
• Crash: If the safe crashes, the computer reboots. The new safe opens the last sealed envelope it found on the floor. It checks the seal (which is unbreakable), sees where it left off, and starts writing the next entry immediately.
• The Result: Even if the safe crashes 10 times, the diary is still continuous. The only thing lost is the few seconds between the crash and the restart.

2. The "Offline Mode" (Network Blackouts)

What if the internet goes down? The safe doesn't stop working. It keeps writing entries and sealing them in envelopes, stacking them up inside the safe.

• Once the internet comes back, the safe dumps the whole stack of envelopes in order.
• The verifier checks the timestamps and the math to ensure no one skipped a day or faked the time.

The "Math Magic" (Proof of Work)

How does the system know the author didn't just type one word and then wait 30 seconds?
The system uses a Sequential Work Function. Think of this as a mathematical puzzle that takes exactly 30 seconds to solve.

• You can't solve it faster, no matter how powerful your computer is.
• You can't solve it in parallel (you can't use 100 computers to solve it in 1 second).
• This proves that real time passed. If the puzzle is solved, 30 seconds must have ticked by.

The "Three Levels of Trust"

The paper admits that the input (the typing) is the weakest link because the bad guy controls the keyboard driver. So, they offer three levels of protection:

1. Level 1 (Software): The computer promises it didn't lie about the keystrokes. (Good, but the bad guy can lie).
2. Level 2 (OS): The operating system helps verify. (Harder to fake).
3. Level 3 (Hardware): The keyboard talks directly to the safe, bypassing the bad guy's software entirely. (The most secure).

The Results: Does it Work?

The authors tested this on real hardware (Intel SGX).

• Speed: It's incredibly fast. The "safe" only slows down the typing process by about 0.3%. You wouldn't even notice it.
• Reliability: In simulations, the system was available and collecting evidence 99.5% of the time, even with frequent crashes.
• Recovery: If it crashes, it gets back up and starts writing again in less than 0.2 seconds.

The Big Picture

This paper presents a new way to prove human authorship.
Instead of trusting the software (which can be hacked), we trust the hardware (the unbreakable glass safe). Even if the person trying to cheat controls the entire computer, they cannot break the safe, cannot fake the time, and cannot erase the evidence once it's sealed.

It changes the question from "Do you believe the software?" to "Can you break the hardware?" And since the hardware is designed to be unbreakable, the answer is usually "No."

Technical Summary

1. Problem Statement

The paper addresses the challenge of verifying human authorship in a digital environment where the platform itself is controlled by the potential adversary (a scenario termed "Trust Inversion").

• The Core Issue: Traditional process attestation verifies system state, but verifying a continuous physical process (like typing a document) requires evidence that the human actually performed the actions over time.
• The Threat Model: In standard remote attestation, the verifier trusts the attester's hardware. In authorship verification, the "Attester" (the writer) controls the OS, hypervisor, and hardware. They are motivated to fabricate evidence (e.g., auto-generating text or simulating keystrokes) to pass verification.
• The Gap: Existing Trusted Execution Environment (TEE) frameworks verify enclave identity but do not address the dependability (availability and resilience) of continuous evidence collection. If a TEE crashes or the network partitions, gaps in the evidence chain can invalidate hours of prior work. No existing solution handles continuous process attestation inside TEEs with guaranteed recovery and formal dependability bounds.

2. Methodology and Architecture

The authors propose a novel architecture that moves the evidence collection pipeline entirely inside a TEE (specifically evaluated on Intel SGX, but applicable to ARM TrustZone and AMD SEV-SNP).

A. System Architecture

• Roles: The system involves an Author (Attester), a Writing Application (adversary-controlled), a TEE Enclave (trusted), a Verifier, and a Relying Party.
• The Enclave (TCB): A small, isolated component (~180 KiB) running the evidence pipeline. It is the only trusted component; the OS and application are untrusted.
• Evidence Pipeline Stages:
  1. Input Reception: Secure channel from the application with monotonic sequence numbers to prevent replay.
  2. Feature Extraction: Analyzes inter-keystroke intervals (IKI), Shannon entropy, and cognitive load statistics.
  3. Temporal Proof (SWF): Computes a Sequential Work Function (Argon2id) chain every 30 seconds to prove elapsed time without relying on trusted clocks.
  4. Cross-Domain Binding (CDCE): Binds content, behavioral, and temporal evidence using an HMAC keyed by the SWF output.
  5. Sealing & Signing: Evidence is cryptographically signed and "sealed" (encrypted and integrity-protected) to local storage for crash recovery.

B. Graduated Input Assurance

To mitigate the risk of the adversary-controlled application injecting fake events, the system offers three tiers of input integrity:

• Tier 1 (Software): HMAC-protected shared memory (prevents modification in transit, but allows injection).
• Tier 2 (OS-mediated): Kernel-level hooks (raises the bar to kernel compromise).
• Tier 3 (Hardware-bound): Secure input paths (e.g., TrustZone trusted controllers) verifying physical device origin.

C. Resilient Evidence Chain Protocol

• Crash Recovery: If the enclave crashes, it unseals the last valid checkpoint, verifies integrity, and resumes the chain. A "Recovery Marker" is inserted to record the gap duration, allowing the Verifier to downgrade fidelity rather than rejecting the entire session.
• Offline Attestation: During network partitions, the enclave continues generating and sealing checkpoints locally. Upon reconnection, the chain is transmitted in order. The SWF chain ensures freshness even without a live network connection.

3. Key Contributions

1. First TEE Architecture for Continuous Process Attestation: Introduces a system for collecting continuous evidence (keystrokes, timing) inside an enclave with graduated input assurance (Tier 1–3).
2. Dependability Modeling: Develops a Continuous-Time Markov Chain (CTMC) model to quantify:
   • Evidence Chain Availability (ECA): The fraction of time evidence is being collected.
   • Mean Time Between Evidence Gaps (MTBEG).
   • Recovery Time Objectives (RTO).
3. Resilient Protocol: A protocol supporting sealed-state recovery and offline operation, with formal proofs of chain integrity even after crashes.
4. Combined Security Analysis: Derives formal security bounds under a composite threat model including Trust Inversion, Side-Channel Leaks (bounded by $\epsilon_{sc}$), DoS, and clock attacks.
5. Empirical Evaluation: Comprehensive testing on Intel SGX demonstrating low overhead and high availability.

4. Results and Evaluation

The system was implemented in Rust using the Teaclave SGX SDK and tested on an Intel Xeon E-2388G.

• Performance Overhead:
  • Per-checkpoint overhead: <25% (63 ms inside enclave vs. 51 ms outside).
  • CPU Impact: <0.3% of the 30-second checkpoint interval (negligible impact on user experience).
• Dependability (Availability):
  • Evidence Chain Availability (ECA): >99.5% in Monte Carlo simulations under Poisson failure models.
  • Resilience: Even with adversarial seal corruption attempts, ECA remained >99.7%.
• Recovery Time:
  • Sealed Recovery: <200 ms (mean 148 ms).
  • Cold Restart: ~1.87 seconds.
• Security:
  • The system resists trust inversion by ensuring the adversary cannot forge the enclave's signing key or the SWF chain.
  • Side-channel leakage is modeled as a bounded parameter ($\epsilon_{sc} \le 2^{-64}$), though the authors note this requires further empirical validation.

5. Significance

• Paradigm Shift: The paper shifts the trust model from "believe the software" to "verify the hardware." By isolating the evidence pipeline in a TEE, it makes it computationally infeasible for an adversary controlling the host OS to fabricate a continuous authorship history.
• Solving the "Gap" Problem: Previous systems failed because a single crash or network drop could invalidate a session. This architecture ensures that gaps are recoverable and quantifiable, maintaining the integrity of the evidence chain.
• Privacy-Preserving: The architecture supports offline authoring and local processing, preserving user privacy while still providing cryptographic proof of human activity.
• Future-Proofing: While evaluated on SGX, the design is adaptable to ARM TrustZone and AMD SEV-SNP, addressing the deprecation of consumer SGX by offering a path forward for secure authorship verification on mobile and server platforms.

In conclusion, this work provides the first comprehensive framework for dependable, continuous process attestation in adversarial environments, combining hardware isolation with rigorous mathematical modeling of system resilience.