TriHaRd: Higher Resilience for TEE Trusted Time

arXiv:2512.10732 · cs.CR, cs.DC · Submitted 2025-12-11 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "TriHaRd: Higher Resilience for TEE Trusted Time".

Jane: The paper was written by the authors from INSA Lyon and CNRS and Université Claude Bernard Lyon 1 and LIRIS, UMR5205 and University of Neuchâtel and ICTEAM, UCLouvain and iExec Blockchain Tech.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Paper discussion segment 1: Tom: We're looking at a new paper called "TriHaRd: Higher Resilience for TEE Trusted Time" which just popped up on arXiv. Jane, when I see a title like that, I immediately think of someone trying to fix a massive hole in how secure hardware handles time.

Jane: You're spot on, Tom. Basically, we use these "Trusted Execution Environments," or TEEs, to keep data safe even if the operating system is compromised. But there's a huge problem because the clock itself isn't inside that safe zone, so a malicious owner of the machine can just lie about what time it is.

Tom: Right, and looking at these authors from INSA Lyon and several other institutions, they aren't just playing around with small tweaks. They are going head-to-head with previous protocols like Triad to make sure time stays reliable even when things get messy.

Jane: It's a big deal because if you can't trust the clock, you can't trust anything involving expiration dates or timestamps in secure computing. If I think a digital certificate is valid but the machine is lying and saying it's still yesterday, my whole security model falls apart.

Lu: This is where it gets really wild for me from a research standpoint. We are talking about building a decentralized consensus of time across multiple nodes to create a "truth" that no single bad actor can touch. Imagine the complexity of orchestrating these enclaves so they all agree on the passage of seconds while fighting off an adversary who controls the very hardware they sit on!

Meng: I'm looking at this from a deployment perspective, and it sounds like a nightmare to maintain if we don't get it right. If these nodes are scattered across different cloud providers, how do you even begin to coordinate them without adding massive latency?

Lalam: That coordination is actually what will allow us to build more resilient digital cultures. When we can guarantee that time is an immutable truth in a distributed system, we enable global trust in automated services that don't rely on a single central authority.

Tom: We've touched on the "why" and the "who," but let's get into what this paper actually does to fix that clock problem.

Paper discussion segment 2: Jane: So, moving into the actual mechanics of TriHaRd: Higher Resilience for TEE Trusted Time, the authors describe a system that doesn't just rely on one source. They use a cluster of these secure enclaves that talk to each other and a remote Time Authority to keep everyone in sync.

Tom: And they're specifically targeting the flaws in Triad, which was this earlier attempt at distributed time. In Triad, if one node got its clock speed messed with by a malicious OS, it could actually trick the other honest nodes into jumping forward into the future.

Jane: Exactly, it’s like a virus for time. One node says "hey, it's actually the year two thousand thirty" and because of how they communicated, the other nodes might believe it. TriHaRd changes that by making sure peer-to-peer communication doesn't automatically update your clock; it only checks if you're consistent with everyone else.

Lu: That distinction is brilliant because it breaks the chain of infection! By separating "checking for consistency" from "updating the clock," they’ve created a massive barrier for an attacker trying to propagate a lie through the network.

Meng: But wait, if they aren't updating based on peer messages, doesn't that mean you might spend more time talking to that remote Time Authority? I worry about the overhead of constantly checking in with an external server just to make sure your clock hasn't drifted.

Lalam: That’s actually why their approach is so clever for large-scale AI and distributed systems. They use "optimistic synchronization," which means they only hit the remote authority when things look suspicious or after a certain period, keeping the system fast but safe. This allows us to scale these trusted services across entire continents without waiting for a single clock in Virginia to tell us what time it is.

Tom: It sounds like they've found a way to balance that speed and security, but I want to see exactly how they stop an attacker from just slowing down the clock speed locally.

Paper discussion segment 3: Tom: Okay, let's talk about the "how" because this is where the engineering gets intense. The paper explains that TriHaRd uses these "AEX-Notify" mechanisms to detect when an operating system interrupts a secure enclave.

Jane: Think of it like this: if you're in a private room and someone suddenly slams the door or pauses your video, you know something happened. The enclave notices those interruptions and immediately marks its clock as "tainted," meaning it doesn't trust itself until it can prove it's consistent with its peers again.

Tom: And they also have this "panic threshold." If the clock suddenly jumps by a huge amount during one of those interruptions, the system just panics and stops serving timestamps entirely to prevent lying to clients.

Lu: The math they used in their experiments is what really caught my eye! They showed that while Triad could be manipulated into massive drifts, TriHaRd keeps everything within very tight bounds, like fifteen microseconds per second. That level of precision is incredible for a system designed to survive active attacks.

Meng: I noticed they did some heavy testing on both single machines and multi-machine Azure setups. Seeing them prove that the attack power is reduced by "more than three orders of magnitude" compared to Triad—that's a massive jump in reliability for any engineer building a secure cloud service.

Lalam: And that reliability is what ultimately shapes how we interact with technology. When the underlying time is unshakeable, we can build decentralized marketplaces and automated legal contracts that are truly tamper-proof, which changes the very fabric of digital trust.

Tom: It's a massive leap forward in making secure hardware actually usable for real-world applications.

Conclusion: Jane: We've covered a lot today, from the fundamental problem of untrusted clocks to how TriHaRd uses Byzantine-resilient checks and local monitoring to fix it. It’s a sophisticated solution for a very sneaky type of attack.

Tom: This paper, "TriHaRd: Higher Resilience for TEE Trusted Time," really sets a new standard for what we should expect from secure distributed systems. It's not just about being secure; it's about being resilient when the environment is actively trying to break you.

Lu: I'm already thinking about how this could be applied to decentralized AI training where timing is everything for model convergence!

Meng: From my side, if this can be implemented without too much performance hit, it’s going to be a staple in secure cloud architectures very soon.

Lalam: Ultimately, it's about creating a world where the digital foundations are as solid as the physical ones.

Jane: Thanks for joining us for this deep dive; we'll see you next time when we tackle another fascinating paper!

Tom: Goodbye everyone!

INSA Lyon · CNRS · Université Claude Bernard Lyon 1 · LIRIS, UMR5205 · University of Neuchâtel · ICTEAM, UCLouvain · iExec Blockchain Tech

cs.CR, cs.DC

Submitted: 2025-12-11

Updated: 2025-12-11

Comments: 2026 45th IEEE International Conference on Computer Communications (INFOCOM)

Journal ref: 2026 45th IEEE International Conference on Computer Communications (INFOCOM), 18 May 2026, Tokyo, Japan, 10 pages

DOI: 10.1109/INFOCOM59046.2026.11571700

Code: https://github.com/RedChainLab/TriHaRd-HigherResilience-TEE-Trusted-Time

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 89/100

The gist: "TriHaRd: Higher Resilience for TEE Trusted Time" proposes a "TEE-based trusted time protocol with high resilience against attacks manipulating enclave-perceived clock speeds and offsets." The paper

Key concepts

Trusted Execution Environments (TEEs): TEEs are secure areas within hardware designed to keep data safe even if the main operating system is compromised. A major problem is that the clock inside these environments is not protected, allowing a malicious owner to falsely report what time it is.
TriHaRd: This paper proposes a system that uses a cluster of secure enclaves and a remote Time Authority to maintain accurate time across multiple nodes. It specifically fixes flaws in previous distributed time protocols by ensuring peer-to-peer communication does not automatically update the clock, breaking chains of lies.
AEX-Notify mechanisms: These are mechanisms used by TriHaRd to detect when an operating system interrupts a secure enclave. When an interruption occurs, the enclave marks its clock as 'tainted,' meaning it stops trusting itself until it can prove consistency with its peers again.
Optimistic Synchronization: This technique allows the system to remain fast by only contacting a remote time authority when things look suspicious or after a certain period. This balances speed and security, enabling scalable services without waiting for every local clock to verify itself constantly.

Terminology

Consistency — 27× in this paper · explained in 3 episodes
Core — 17× in this paper · explained in 2 episodes
Time Authority — 7× in this paper
Calibration — 5× in this paper · explained in 7 episodes
Accuracy — 3× in this paper · explained in 1 episode
Network Time Protocol — 3× in this paper
Benchmark — 2× in this paper · explained in 2 episodes
Verification — 2× in this paper · explained in 2 episodes
Accountability — 1× in this paper · explained in 2 episodes
Actor — 1× in this paper · explained in 3 episodes
Explainability — 1× in this paper · explained in 3 episodes
Trusted Platform Module — 1× in this paper

Summary

TriHaRd: Higher Resilience for TEE Trusted Time proposes a TEE-based trusted time protocol with high resilience against attacks manipulating enclave-perceived clock speeds and offsets. The paper identifies that in Trusted Execution Environments (TEEs) such as Intel SGX, the time source is outside the Trusted Computing Base: a malicious host can manipulate the TEE’s notion of time, jumping in time or affecting perceived time speed. While previous work like Triad is vulnerable to a single compromised node that can manipulate its own notion of time by delaying some protocol messages with the TA [Time Authority], which can cause honest nodes to skip to timestamps arbitrarily far in the future, TriHaRd aims to mitigate these risks.

The proposed solution, TriHaRd, comprises four sub-protocols:

Clock synchronization: Each TriHaRd enclave performs synchronization with the TA, in this work, using a simplified NTP protocol.
Local clock monitoring: An enclave thread monitors the TSC [TimeStamp Counter] over time and stores the current value. The stored TSC value is invalidated after interruptions occur. To prevent arbitrary forward jumps, our AEX handler checks that the last stored and the current TSC values differ by less than a panic threshold of increments. Additionally, if no AEX happens within a given increase in TSC, the enclave 'self-taints', i.e., switches to a TAINTED TSC state autonomously.
"Cluster clock-consistency verification: To verify the TSC value while easing the request load on the TA, enclaves in the cluster cooperate to check whether their clocks (i.e., TSC values and reference timestamps) are consistent. Crucially, communications between peers in TriHaRd only check for consistency with peer clocks and do not trigger clock adjustments, which denies an attack vector present in Triad where peers in the TEE cluster update their clocks based on each other, using the highest-valued clock."
Timestamp service: A client enclave application can get the current timestamp from the TriHaRd enclave, after some checks on the stored TSC value’s state. Timestamps are only returned when the node is in the OK state, i.e., to summarize: its clock is consistent with the TA and f peers, and no AEX nor self-tainting event occurred since the last round of protocol C’s peer consistency check.

Empirical results demonstrate that TriHaRd mitigates attacks on Triad and maintains high accuracy. In fault-free setups, TriHaRd nodes drift within 50µs from the reference, with a maximum instantaneous rate around ±0.3ppm, whereas Triad nodes drift significantly, in the order of hundreds of microseconds per second or more. Under attack scenarios involving strategic TSC forward jumps and clock slowing, TriHaRd shows superior resilience: the maximum undetected clock speed offset [is reduced] by more than 3 orders of magnitude compared to Triad. While an attack on Triad could cause a node to drift at -93ms/s, the timestamp drift at Node 3 [in TriHaRd] remains within 130µs. Furthermore, while the attack reduces availability in TriHaRd (e.g., to 60% for an attacked node), it prevents the propagation of malicious timestamps to honest nodes. The authors conclude that TriHaRd upholds an absolute drift offset within 1ms, with honest clock speeds calibrated within 0.3ppm.of the reference.

Improvements for AI systems

Based on the technical mechanisms described in the TriHaRd protocol, here are specific improvements for high-stakes AI systems (such as autonomous vehicle fleets, high-frequency trading bots, or decentralized AI inference networks):

Build a Temporal Integrity Layer for Decentralized AI Training/Inference

To prevent attackers from manipulating the timestamps of training data or inference requests in a distributed environment, integrate the TriHaRd protocol into the Trusted Execution Environments (TEEs) where model weights and data are processed.

What it can do: Ensures that time-series training data cannot be re-ordered or time-shifted by a malicious cloud provider to induce model drift or poisoning. It guarantees that every gradient update or inference request is cryptographically bound to a globally consistent, Byzantine-resilient timestamp.

Implement Clock-Speed Guardrails for Latency-Sensitive AI Agents

For AI agents operating in competitive environments (e.g., automated market makers or real-time robotic control), use TriHaRd’s local and peer consistency checks to monitor the perceived clock speed of the host OS.

What it can do: Detects slow-motion attacks where an adversary slows down the CPU's perceived time to gain an advantage in auction-based resource allocation or to delay a safety-critical reaction (e.g., an autonomous drone's collision avoidance signal). The system will autonomously transition to a TAINTED state and cease operations if clock speed manipulation is detected, preventing the AI from making decisions based on stale or manipulated temporal contexts.

Secure Temporal Synchronization for Federated Learning

In Federated Learning (FL) setups, use TriHaRd's peer-to-peer consistency checks (Protocol C) to verify that all participating edge nodes are operating within a strict synchronization bound (e.g., <1ms).

What it can do: Prevents Stale Update Attacks where a malicious node uses an offset or manipulated clock to submit model updates that appear current but were actually calculated using outdated data. This maintains the mathematical integrity of the global model aggregation process by ensuring all participants are temporally aligned.

Hardened Audit Logging for AI Compliance and Forensics

Integrate TriHaRd’s monotonic TSC monitoring and AEX-Notify detection into the logging subsystem of AI decision-making engines.

What it can do: Provides an unforgeable, high-precision temporal audit trail for AI decisions. Because the system detects even micro-interruptions (AEXs) that might be used to hide time jumps, it ensures that forensic reconstructions of AI behavior (e.g., why a medical AI made a specific diagnosis at a specific millisecond) are immune to OS-level timestamp tampering.

Sources

Mixed Fault Tolerance Protocols with Trusted Execution Environment