[Paper] TriHaRd: Higher Resilience for TEE Trusted Time

Source: arXiv - 2512.10732v1

Overview

The paper introduces TriHaRd, a new protocol that lets Trusted Execution Environments (TEEs) such as Intel SGX keep a reliable notion of time even when the host operating system is fully compromised. By hardening the earlier Triad design against clock‑speed and offset attacks, TriHaRd makes “trusted time” practical for security‑critical services that need accurate timestamps (e.g., secure logging, lease expiration, or blockchain anchoring).

Key Contributions

• Byzantine‑resilient clock updates – a novel update rule that tolerates malicious TEEs trying to speed‑up or slow‑down the shared clock.
• Cross‑TEE consistency checks – lightweight mechanisms that detect when a subset of participants diverge from the agreed‑upon time progression.
• Formal security analysis – proof‑style arguments showing that an adversary controlling the OS and any number of TEEs cannot force honest TEEs to accept an arbitrary future timestamp.
• Prototype implementation – a working TriHaRd library built on Intel SGX, integrated with a remote Time Authority (TA) and evaluated on a realistic cluster of SGX enclaves.
• Empirical evaluation – experiments demonstrating that TriHaRd blocks the clock‑speed attacks that break Triad, with only modest overhead (≈ 5 % extra latency per time‑update round).

Methodology

1. System Model – The authors assume a set of TEEs (the cluster) that can communicate over an authenticated channel, a remote Time Authority (TA) that periodically signs the current wall‑clock time, and a potentially malicious host OS that can tamper with any local timer.
2. Threat Model – The attacker may control the OS, any subset of TEEs, and can replay, drop, or forge messages except for the TA’s signatures (which are assumed trustworthy).
3. Protocol Design
   • Clock Proposal Phase: Each enclave proposes a local clock value (derived from its own hardware timer).
   • Byzantine‑Resilient Aggregation: Using a median‑based aggregation (similar to BFT consensus), the cluster computes a global time update that tolerates up to f faulty enclaves out of 2f + 1 participants.
   • Speed‑Bound Enforcement: Enclaves enforce a maximum allowed drift per update (e.g., no more than Δ ms per second). If a proposal exceeds this bound, it is discarded.
   • Consistency Check: After each round, enclaves exchange hash‑linked summaries of the accepted timestamps. Any mismatch triggers a re‑synchronization with the TA.
4. Implementation – The authors built the protocol as an SGX SDK library, using Intel’s RDTSC counter for local time, TLS for authenticated peer communication, and ED25519 signatures from the TA.
5. Evaluation – They deployed 7 SGX enclaves on separate VMs, simulated an adversary that speeds up its local timer by up to 10×, and measured the impact on honest enclaves’ clocks and on overall latency.

Results & Findings

The experiments confirm that TriHaRd completely neutralizes the “fast‑forward” attack that let a compromised enclave push the whole cluster’s clock arbitrarily far into the future. The modest performance penalty makes the protocol viable for production workloads that require periodic trusted timestamps.

Practical Implications

• Secure Logging & Auditing – Services that rely on tamper‑proof logs (e.g., financial transaction recorders, compliance auditors) can now obtain trustworthy timestamps without needing dedicated hardware clocks.
• Lease & Token Expiration – Distributed systems that enforce time‑based access (e.g., DRM, subscription services) can safely run inside SGX enclaves even when the host is untrusted.
• Blockchain Anchoring – TEEs can provide provably correct timestamps for off‑chain data that is later committed to a blockchain, reducing the attack surface of “oracle” services.
• Edge & IoT Deployments – Devices that cannot host a secure RTC can join a TriHaRd cluster and inherit a resilient time source, simplifying secure firmware updates and time‑based policies.
• Developer Simplicity – The provided SGX library abstracts away the consensus logic; developers only need to call get_trusted_time() and handle occasional re‑sync callbacks.

Limitations & Future Work

• Dependence on a Remote Time Authority – If the TA becomes unavailable, the cluster can only progress at a bounded rate, potentially stalling time‑sensitive applications.
• Network Latency Sensitivity – The median‑based aggregation assumes relatively synchronous communication; high‑latency or partitioned networks could increase re‑sync frequency.
• Scalability – The current prototype scales comfortably to a handful of enclaves; larger clusters may need hierarchical aggregation or gossip‑based variants.
• Hardware Diversity – The design is tied to Intel SGX’s monotonic counters; extending to other TEEs (e.g., ARM TrustZone, AMD SEV) will require adapting the local timer source.

Future research directions include exploring leaderless BFT clock protocols that further reduce reliance on a single TA, integrating hardware‑rooted time sources (e.g., TPM‑based counters), and evaluating TriHaRd in real‑world cloud orchestration platforms where enclave churn is frequent.

Authors

• Matthieu Bettinger
• Sonia Ben Mokhtar
• Pascal Felber
• Etienne Rivière
• Valerio Schiavoni
• Anthony Simonet-Boulogne

Paper Information

• arXiv ID: 2512.10732v1
• Categories: cs.CR, cs.DC
• Published: December 11, 2025
• PDF: Download PDF