Epoch-based Attestation Caching

• The paper introduces epoch-based attestation caching that amortizes expensive remote attestation by verifying policy state once per epoch.
• It leverages TEEs to cache attested policy hashes and transitions, reducing per-action cryptographic overhead with constant-time equality checks.
• Implications include improved governance and performance by tightly coupling CRDT-based policy updates with bounded staleness and efficient runtime enforcement.

Searching arXiv for the specified papers to ground the article and citations. Epoch-based Attestation Caching is a mechanism for amortizing the cost of remote attestation and policy integrity verification across a bounded interval, or “policy epoch,” rather than repeating those operations for every inference or action. In the Ethical Hyper-Velocity (EHV) architecture, the Trusted Execution Environment (TEE) performs remote attestation and policy integrity verification only once per epoch $E_k$, binds the resulting state to a policy hash $H_p = \text{SHA-256}(S_G)$, and caches that attested state inside the TEE. During the epoch, enforcement reduces to a constant-time equality check between the current local policy hash and the cached epoch hash, followed by application of compiled constraints inside a JIT Policy Enforcement Point (PEP) (Sharma, 18 May 2026). The same general design pattern also appears, under different terminology, in control-flow attestation systems such as GuaranTEE, where bounded batches of attestation evidence are securely cached and verified asynchronously (Morbitzer et al., 2022), and in network attestation systems such as TRAIN, where each attestation instance carries forward cached integrity state across rounds (Frolikov et al., 10 Feb 2025).

1. Definition and Architectural Role

Within EHV, Epoch-based Attestation Caching is defined by three coupled operations: remote attestation, policy-state hashing, and epoch binding. The mechanism performs remote attestation and policy integrity verification only once per policy epoch $E_k$, computes a policy hash

$H_p = \text{SHA-256}(S_G),$

where $S_G$ is the globally merged policy CRDT state, and caches that hash inside the TEE as the trusted policy state for the duration of the epoch (Sharma, 18 May 2026). Per-action verification is then expressed as

$$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$

EHV positions this mechanism as Pillar 2 of a three-part architecture. Pillar 1 is a CRDT-based Policy Compiler that merges policies into a Global Ethical State,

$S_G = \bigsqcup_{i=1}^{n} S_i.$

Pillar 2 is Epoch-based Attestation Caching, in which the TEE validates the hash of $S_G$ once per epoch. Pillar 3 is a PEP located inside the Governance-Aware JIT Compiler, where the cached epoch state is used for per-action decisions $$G(a, C) \in \{\text{PERMIT}, \text{DENY}, \text{ESCALATE}\}$$ (Sharma, 18 May 2026).

This placement is central to the architectural objective of moving governance into the inference pipeline. Rather than treating attestation as an external or sporadic audit artifact, the cache becomes the operational bridge between CRDT-synchronized policy state, TEE-rooted trust, and constant-time runtime enforcement. A plausible implication is that the cache is not merely a performance optimization; it is also the state abstraction that makes policy enforcement composable with JIT-time inference control.

2. Motivation: Attestation Cost, Governance Latency, and the Epoch Trade-off

The mechanism addresses a specific mismatch between attestation cost and runtime decision frequency. In agentic systems with high-frequency policy updates, hardware-based isolation, and governance embedded inside the inference pipeline, a naive design would either perform a full TEE remote attestation and/or policy integrity check for every inference or action, incurring 200ms+ per remote attestation round-trip, or run continuous or very frequent attestation, saturating the system with cryptographic and network overhead (Sharma, 18 May 2026).

That cost conflicts directly with EHV’s stated objectives of Sub-millisecond Formal Determinism (SMFD) and $O(1)$ runtime policy enforcement. The paper states that remote attestation is orders of magnitude slower than per-token or per-action inference steps, and that frequent attestation would dominate latency and throughput, making the system unusable in high-throughput clinical or industrial settings (Sharma, 18 May 2026). Epoch-based Attestation Caching therefore amortizes the attestation cost: attest once per epoch, cache the attested policy and code state, and perform only constant-time equality checks during the epoch.

The use of epochs rather than per-request or continuous attestation is motivated explicitly as a trade-off between freshness and performance. EHV states three reasons: attestation cost is high (200ms+), policy changes are not continuous at microsecond timescales, and bounded staleness is acceptable if it is explicitly modeled as an Epoch Staleness Window, remains small compared to legacy governance latency, and can be shortened by emergency mechanisms (Sharma, 18 May 2026). The architecture therefore defines Policy Epochs with configurable duration $H_p = \text{SHA-256}(S_G)$0, such as 60 seconds in the healthcare example.

Related systems illustrate the same amortization principle in different domains. GuaranTEE does not use the term epoch-based attestation caching, but it accumulates control-flow evidence over bounded intervals, securely caches the evidence in the prover TEE, and verifies batches in a way that amortizes cryptographic and communication costs (Morbitzer et al., 2022). TRAIN likewise defines discrete attestation instances with a unique challenge and scheduled attestation time, while carrying forward cached per-device integrity state across rounds (Frolikov et al., 10 Feb 2025). These systems support the broader view that bounded validity intervals are a recurring systems pattern for reconciling attestation security with high-rate execution.

3. Operational Mechanics

Epochs in EHV are primarily time-based. Each epoch has a fixed duration $H_p = \text{SHA-256}(S_G)$1, attestation is performed at epoch boundaries, and emergency resets can force a new epoch before timer expiry. The mechanism allows an EMERGENCY_EPOCH_RESET signal for critical policy changes such as drug withdrawal, triggering immediate re-attestation and effectively starting a new epoch (Sharma, 18 May 2026).

Within an epoch, the TEE caches four categories of state: the TEE attestation result or measurement, the attested policy hash

$H_p = \text{SHA-256}(S_G)$2

the compiled constraints $H_p = \text{SHA-256}(S_G)$3 derived from that policy state, and epoch metadata consisting of the epoch identifier $H_p = \text{SHA-256}(S_G)$4 and the last attestation time $H_p = \text{SHA-256}(S_G)$5 (Sharma, 18 May 2026). Because the design assumes one active epoch per node, indexing is trivial: the cache key is the current epoch identifier, and the cache values are $H_p = \text{SHA-256}(S_G)$6.

The lifecycle begins with attestation. The JIT PEP inside the TEE submits a TDX, SGX, or SEV-SNP quote to a Key Broker or Service. The Key Broker verifies the enclave digest and returns keys together with the confirmed epoch hash $H_p = \text{SHA-256}(S_G)$7. The JIT PEP then caches constraints from the policy store (Sharma, 18 May 2026). For each subsequent action request, the PEP retrieves the local policy hash $H_p = \text{SHA-256}(S_G)$8, loads active constraints $H_p = \text{SHA-256}(S_G)$9 in $E_k$0, and returns PERMIT if still within epoch and hashes match, or DENY/ESCALATE otherwise. A timer inside the TEE tracks epoch expiry; once elapsed time exceeds $E_k$1, the JIT PEP blocks and refuses to permit further actions until re-attestation.

The algorithmic sketch in EHV formalizes these operations. At epoch creation, the TEE computes

$E_k$2

produces an attestation quote including its measurement and $E_k$3, sends the quote to the Key Broker, and if verification succeeds sets

$E_k$4

then compiles policy into constraints $E_k$5 and stores the result in the epoch cache (Sharma, 18 May 2026). During per-action verification, the system checks expiration, recomputes $E_k$6, compares it against $E_k$7, and either triggers re-attestation or applies $E_k$8.

GuaranTEE exhibits an analogous bounded-cache protocol at the level of control-flow evidence. ProveTEE caches IDs in an ID batch buffer, updates a running hash chain, encrypts a batch when full, and writes the encrypted message into shared memory; VerifyTEE decrypts, validates the hash chain, and verifies the control-flow path against a CFG (Morbitzer et al., 2022). TRAIN exhibits the same structure at the network level: each attestation request defines a round with a new hash-chain value, a scheduled attestation time, and carry-over verifier state such as per-device Latest Modification Time (LMT) (Frolikov et al., 10 Feb 2025). These systems differ in object of attestation—policy state, control flow, or device code state—but all use a bounded interval to reuse trusted state without recomputing the full attestation basis on every event.

4. Security Model, Staleness, and Correctness Conditions

The principal security question raised by epoch-based caching is whether a cached attested state can become stale in a way that permits unsafe behavior. EHV addresses this by making staleness explicit. The paper defines the Epoch Staleness Window (ESW) as

$E_k$9

the maximum time during which a policy update arriving mid-epoch might not yet be enforced because the system continues to trust the attested epoch state until the next epoch boundary (Sharma, 18 May 2026).

The number of actions executed under stale policy during this window is bounded by

$H_p = \text{SHA-256}(S_G),$0

where $H_p = \text{SHA-256}(S_G),$1 is action throughput. EHV gives the example $H_p = \text{SHA-256}(S_G),$2 actions/hour and $H_p = \text{SHA-256}(S_G),$3, yielding

$H_p = \text{SHA-256}(S_G),$4

The paper contrasts this with legacy systems at $H_p = \text{SHA-256}(S_G),$5 days, where

$H_p = \text{SHA-256}(S_G),$6

This framing does not eliminate TOCTTOU risk; it bounds it quantitatively and ties it to an explicit configuration variable, the epoch length (Sharma, 18 May 2026).

The system’s fail-closed rule is equally central. EHV states

$H_p = \text{SHA-256}(S_G),$7

If the node is partitioned from the attestation authority and cannot re-attest, all actions are denied after epoch expiry (Sharma, 18 May 2026). This is intended to prevent indefinite execution under an old policy. For ultra-critical updates, EMERGENCY_EPOCH_RESET can reduce the window to network propagation time $H_p = \text{SHA-256}(S_G),$8.

Formal correctness in EHV is expressed at the governance level rather than by explicit epoch state variables. The TLA+ specification uses PolicySet, AgentAction, EnforcementStatus, and NetworkState, with safety invariant

$H_p = \text{SHA-256}(S_G),$9

Epochs and attestation are not modeled directly, but their effect is captured by the requirement that invalid actions with respect to the current policy set are never permitted (Sharma, 18 May 2026). This suggests that epoch-based caching is treated as an implementation strategy whose correctness must preserve a stronger policy-level invariant.

Comparable concerns appear in the other cited systems. GuaranTEE secures cached control-flow batches using AES-GCM, evolving keys $S_G$0, counters BatchNo, and a cumulative hash chain, thereby providing integrity, anti-replay, ordering, and completeness across batches (Morbitzer et al., 2022). TRAIN distinguishes intra-device TOCTOU and inter-device TOCTOU, reducing the latter by tightly bounding the start of attestation across devices and carrying epoch-specific freshness through hash-chain-authenticated requests (Frolikov et al., 10 Feb 2025). Together, these designs show that epoch-based caching does not remove freshness hazards; rather, it externalizes them into explicit validity intervals, synchrony assumptions, and re-attestation triggers.

5. Performance Model and Complexity

EHV’s performance claim rests on separating the expensive operation—remote attestation—from the frequent operation—per-action enforcement. Within an epoch, the verification function is

$S_G$1

where comparison of two fixed-size hashes is $S_G$2, and lookup and application of compiled constraints are designed to be $S_G$3 via constant-time checks or table lookups (Sharma, 18 May 2026). On that basis, the paper states that per-action governance overhead is constant.

Governance Latency is defined as

$S_G$4

Legacy frameworks are described as having $S_G$5 of 14–30 days due to manual audits, whereas EHV claims

$S_G$6

for runtime enforcement after the next epoch attestation (Sharma, 18 May 2026). The critical performance move is attestation amortization. Without epochs, attestation overhead per action is approximately 200ms, which dominates inference and makes SMFD impossible. With epochs, if $S_G$7 and attestation cost per epoch is $S_G$8, then average attestation cost per action becomes

$S_G$9

which becomes negligible at high action rates (Sharma, 18 May 2026).

GuaranTEE provides an empirical analogue of the same amortization logic. With batch size 1 and feedback frequency 1, queue transfer time is approximately 2,098 ns per ID; with batch size 10,000 and feedback frequency 10, it is approximately 37.76 ns per ID, a more than 50× improvement in per-event communication cost (Morbitzer et al., 2022). End-to-end, an uninstrumented SGX signing service runs at about 54.79 μs per request, while GuaranTEE with batch size 10,000 and feedback frequency 10 runs at about 57.28 μs per request, approximately 1.05× total, or about 5% overhead (Morbitzer et al., 2022). TRAIN likewise achieves constant-time per-device attestation by attesting only a fixed-size state such as LMT or challenge rather than full program memory, with request verification about 13.0 ms and report generation about 30 ms on MSP430 at 8MHz (Frolikov et al., 10 Feb 2025).

The shared principle is that the expensive cryptographic or measurement work is performed once per epoch-like unit, while event-level checking is reduced to constant-sized state operations. A plausible implication is that epoch-based caching should be understood as a complexity transformation: it replaces per-event attestation cost with epoch transition cost plus bounded staleness.

6. Interaction with CRDT Policy State and Related Attestation Paradigms

EHV’s mechanism depends on the fact that policy state is represented as a CRDT and therefore admits a stable, convergent hash. Policies are maintained as an LWW-Element-Set with merge rule

$$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$0

and the global state is

$$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$1

As nodes converge under partitions, the policy hash $$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$2 also converges (Sharma, 18 May 2026). EHV does not define each CRDT update as a separate epoch; epochs remain time-based, but if the policy set changes and the local hash diverges from $$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$3, the system triggers re-attestation and an epoch transition. For critical updates, EMERGENCY_EPOCH_RESET can be issued immediately (Sharma, 18 May 2026).

This architecture differs from conventional TEE attestation schemes that are static or coarse-grained. Standard TEE attestation proves the enclave measurement at launch time; it does not normally bind an evolving governance state into the attestation result for constant-time per-action enforcement. GuaranTEE extends TEE attestation from launch-time integrity to runtime control-flow integrity through control-flow attestation, but does so by batching control-flow evidence rather than by hashing a replicated policy state (Morbitzer et al., 2022). TRAIN, by contrast, addresses network attestation in IoT, where each attestation round is authenticated by a hash-chain link and leverages cached LMT values per device to avoid re-hashing full memory on every round (Frolikov et al., 10 Feb 2025).

A useful distinction is therefore between three families of epoch-like attestation caching. In EHV, the cached object is a policy snapshot summarized by $$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$4. In GuaranTEE, it is a batch of control-flow evidence summarized by a running hash and protected by per-batch encryption. In TRAIN, it is a per-round authentication token combined with a cached integrity summary such as LMT. The common pattern is reuse of trusted state across a bounded interval; the differentiating factor is what semantic object the cache attests.

7. Limitations, Edge Cases, and Common Misconceptions

A common misconception is that epoch-based caching eliminates TOCTTOU. The source material does not support that interpretation. EHV instead makes staleness explicit through the Epoch Staleness Window, quantifies the number of potentially stale actions, and relies on fail-closed expiration plus emergency reset to bound risk (Sharma, 18 May 2026). TRAIN similarly distinguishes different TOCTOU notions and reduces, rather than universally removes, inter-device skew in the clockless variant (Frolikov et al., 10 Feb 2025). The mechanism is therefore a bounded-staleness design, not a zero-staleness one.

Another misconception is that the cache replaces attestation. In EHV, the cache is valid only because a TEE quote, enclave measurement, and policy hash have been verified by a Key Broker or Service; when the local policy hash diverges, the timer expires, an emergency reset occurs, or remote attestation fails, the current epoch cache is invalidated and a new attestation is required (Sharma, 18 May 2026). GuaranTEE makes the same point cryptographically: a batch is valid only as part of a forward-only state machine over Key_i, BatchNo, and cumulative hash; if any of these become inconsistent, the cached data is treated as tampered with or lost (Morbitzer et al., 2022).

The limitations stated for EHV are threefold. First, epoch granularity is a trade-off: short epochs lower staleness but raise attestation overhead, while long epochs lower overhead but increase staleness, so domain-specific tuning is required (Sharma, 18 May 2026). Second, without TEEs the system falls back to out-of-band auditing and loses SMFD and hardware-rooted guarantees. Third, the semantic gap labeled ASEL remains outside formal verification: the PEP relies on correct parsing of model outputs into structured actions, and that layer is not formally verified (Sharma, 18 May 2026).

The threat model also leaves residual risks. EHV identifies TEE side-channel attacks such as Spectre and Foreshadow, with mitigation by epoch rotation and attestation refresh; stale-epoch exploitation, mitigated by configurable $$\text{Verify}(a) = \begin{cases} O(1) & \text{if } H_p^{\text{local}} = H_p^{\text{epoch}} \ \text{Re-attest} & \text{otherwise.} \end{cases}$$5 and forced re-attestation on critical updates; and network partition beyond epoch duration, mitigated by CRDT convergence and fail-closed behavior (Sharma, 18 May 2026). Out-of-scope risks include global compromise of the TEE hardware root of trust, side-channel classes TEEs cannot mitigate, and incorrect or adversarial ASEL parsing. GuaranTEE similarly notes limitations around context-insensitivity of CFG validation and the difficulty of complete CFG learning for large services (Morbitzer et al., 2022). TRAIN notes fragility in hash-chain renewal timing and dependence of the clockless variant on accurate delay estimation (Frolikov et al., 10 Feb 2025).

Taken together, these limitations indicate that epoch-based attestation caching is best understood as a systems discipline for controlling the economics of trust updates under strong adversarial assumptions. It does not dissolve the need for trusted hardware, synchronization logic, or formal reasoning; rather, it reorganizes those requirements around explicitly bounded validity intervals.