TriHaRd: Higher Resilience for TEE Trusted Time

TL;DR

Trusted time in TEEs is threatened by hosts that can manipulate clock speed and offset. TriHaRd proposes a Byzantine‑resilient, four‑protocol approach (A–D) that synchronizes clocks with a TA, monitors local TSC behavior, verifies cross‑node clock consistency, and serves timestamps only from healthy nodes. Empirical results show TriHaRd achieves sub‑millisecond drift, near‑NTPT tolerance, and high availability while mitigating attacks that cripple Triad, both in single‑ and multi‑machine deployments. This work advances practical, CPU‑level trusted time with strong resilience guarantees and an openly available artifact for reproducibility.

Abstract

Accurately measuring time passing is critical for many applications. However, 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. Previous work (Triad) proposes protocols for TEEs to maintain a trustworthy time source by building a cluster of TEEs that collaborate with each other and with a remote Time Authority to maintain a continuous notion of passing time. However, such approaches still allow an attacker to control the operating system and arbitrarily manipulate their own TEE's perceived clock speed. An attacker can even propagate faster passage of time to honest machines participating in Triad's trusted time protocol, causing them to skip to timestamps arbitrarily far in the future. We propose TriHaRd, a TEE trusted time protocol achieving high resilience against clock speed and offset manipulations, notably through Byzantine-resilient clock updates and consistency checks. We empirically show that TriHaRd mitigates known attacks against Triad.

Figures (6)

• Figure 1: TriHaRd distributed time service overview.
• Figure 2: Example evolution of TriHaRd node states over time (not to scale), as well as events and conditions triggering state changes. Protocols that update given states are indicated on the left. States in red prevent getting timestamps in protocol D, while states in blue are necessary. $\tau$ is the maximum absolute TEE--TA drift; $|C^{s}_{\text{peers}}|$ is the size of the set of consistent peers for protocol C's message sequence number $s$. $x$ is the maximum time the enclave may remain in the OK state. States notably satisfy the constraints: $\texttt{OK}\implies\texttt{TA\_CONSISTENT}\implies\texttt{SYNC}$, as well as $\texttt{FREQ}\implies\texttt{TA\_INCONSISTENT}\implies\texttt{TAINTED}$.
• Figure 3: Cumulative distribution of delays between successive Asynchronous Enclave Exits (AEXs) on the TimeStamp Counter (TSC) monitoring enclave thread at each time service. \ref{['fig:aexdelaytriad']} is simulated on top of \ref{['fig:aexdelaylowinterrupt']}'s environment, by triggering AEXs at the TSC monitoring thread's core, using rdmsr instructions on that core's TSC MSR (Model Specific Register, 0x10 for TSC). \ref{['fig:aexdelaytrihard-staint', 'fig:aexdelaylowinterrupt-staint']} show TriHaRd-perceived delays in TSC tainting events when using self-tainting set to 1.5s.
• Figure 4: Single-machine long-term fault-free behavior of Triad (top) and TriHaRd (bottom) nodes. The inter-interruption/self-tainting delay distribution for \ref{['fig:ff']}.i is illustrated by \ref{['fig:aexdelay']}.i. OS-measured TSC clock frequency is $F_{\text{TSC}}=2899.999\text{MHz}$.
• Figure 5: Multi-machine long-term fault-free behavior of Triad (top) and TriHaRd (bottom) nodes under Triad-like interruptions (left) and in a low AEX environment (right). OS-measured TSC clock frequency is $F_{\text{TSC}}=2793.439\text{MHz}$ for all machines. Note that in \ref{['fig:driftff-multi-trihard', 'fig:driftfflowinterr-multi-trihard']}, Node 1's OS clock, used as reference for its own enclave time service drift, may have exhibited a slight offset (around -0.5ms) compared to Nodes 2 and 3's OS clocks, hence the negative drift correction, while the drift also looks negative. Successful peer consistency checks (with a tolerance of 500µs) between enclave clocks support this argument.