Hardware Attestation of Time (HAT): TPM-Based Temporal Binding for Remote Attestation

1.1. The TPM Temporal Attestation Gap

Remote attestation protocols verify temporal claims: that a computation took at least a certain duration, that events occurred in order, or that a process was active during a claimed interval. Software timestamps are trivially forgeable. [RFC3161] Timestamp Authorities provide trusted timestamps but require network connectivity and attest only to signing time, not computation duration.¶

TPM 2.0 devices contain a monotonic hardware clock that cannot be rolled back without triggering detectable state changes. The TPM2_GetTime command [TPM2-Commands] returns the current clock value in a signed attestation structure. No existing specification standardizes paired TPM2_GetTime readings for computation duration proof.¶

1.2. HAT Solution

HAT defines a "temporal sandwich": the Attester calls TPM2_GetTime before a computation, executes it, then calls TPM2_GetTime after. Both attestations are signed by the same AIK. The Verifier validates signatures, clock continuity, and elapsed time.¶

HAT proofs can optionally bind the computation's input to T_before, preventing pre-computation attacks.¶

HAT is designed for sequential computation verification systems and other scenarios where the platform operator is adversarial.¶

1.3. Related Work

TUDA [I-D.birkholz-rats-tuda] specified TPM-based temporal attestation using Time Stamp Authorities (TSA) and a Sync Base Protocol. HAT differs in requiring no external TSA, focusing on computation duration rather than audit logging, and using resetCount/clock-safe validation rather than TSA synchronization.¶

3.1. RATS Entity Roles

HAT maps to RATS entity roles [RFC9334] as follows:¶

Attester / Attesting Environment:

The platform performing the attested computation. Generates HAT proofs by calling TPM2_GetTime before and after each computation.¶

Endorser:

TPM manufacturers issuing EK certificates and platform attestation credentials. The certificate chain establishes AIK binding to genuine TPM hardware.¶

Verifier:

Receives HAT proofs, validates AIK signatures against the Endorser's certificate chain, and checks temporal consistency.¶

Relying Party:

Consumes Attestation Results per [RFC9334].¶

Reference Value Provider:

Supplies the expected computation duration and clock tolerance parameters that the Verifier uses to evaluate HAT time deltas. The Reference Value Provider conveys these values via one of: (a) the consuming protocol's Evidence structure (e.g., declared parameters from which duration is derived), (b) an out-of-band policy configuration on the Verifier, or (c) a CoRIM reference values manifest per draft-ietf-rats-corim. The specific conveyance mechanism is defined by the consuming protocol.¶

3.2. HAT in the Attestation Flow

HAT operates within the RATS passport model ([RFC9334], Section 8.1):¶

+----------+                      +-----------+
| Attester |                      |  Verifier |
|          |                      |           |
| 1. TPM2_GetTime (T_before)      |           |
| 2. Execute computation          |           |
| 3. TPM2_GetTime (T_after)       |           |
| 4. Package HAT proof            |           |
|          |                      |           |
|          |--- Evidence -------->|           |
|          |   (includes HAT)     |           |
|          |                      | 5. Verify |
|          |                      |    sigs   |
|          |                      | 6. Check  |
|          |                      |    clock  |
|          |                      | 7. Verify |
|          |                      |    delta  |
|          |                      |           |
+----------+                      +-----+-----+
                                        |
                                        v
                                  Attestation
                                   Result

3.3. Trust Model

HAT implements a trust inversion: the Attester operator is the primary adversary, analogous to anti-cheat attestation. The trust anchors are:¶

• The TPM hardware, providing a monotonic clock resistant to rollback.¶

• The AIK, a restricted signing key bound to the TPM.¶

• The Endorser's certificate chain, binding the AIK to genuine hardware.¶

The Attester operator controls the software stack and can choose when to call TPM2_GetTime, but cannot forge clock readings or AIK signatures.¶

4.1. TPM2_GetTime() Bracketing

The Attester MUST obtain TPM-attested time readings before and after each computation:¶

T_before = TPM2_GetTime(aikHandle, qualifyingData_before)

... execute computation ...

T_after  = TPM2_GetTime(aikHandle, qualifyingData_after)

The aikHandle MUST refer to the same AIK for both calls.¶

Each TPM2_GetTime call returns a TPMS_ATTEST structure [TPM2-Structures] containing:¶

• clockInfo.clock: Monotonic millisecond counter. Does not reset on reboot; only on owner-clear (which increments resetCount).¶

• clockInfo.resetCount: Increments on TPM2_Startup(CLEAR).¶

• clockInfo.restartCount: Increments on TPM2_Startup(STATE) (hibernation/resume).¶

• clockInfo.safe: Indicates clock reliability. Set to NO on clock discontinuity.¶

• firmwareVersion: TPM firmware version.¶

Applications SHOULD include qualifying data binding the HAT proof to the computation. Use cases where replay is not a threat (e.g., public timestamping) may omit qualifying data.¶

• T_before qualifyingData: computation input seed or hash thereof.¶

• T_after qualifyingData: computation output or commitment (e.g., Merkle root).¶

If the TPM is unavailable, the Attester MUST NOT generate a HAT proof.¶

The Attester SHOULD minimize delay between T_before and computation start, and between computation end and T_after.¶

4.2. AIK Signature Requirements

Key Attributes:

The AIK MUST be a restricted signing key with TPMA_OBJECT.restricted and TPMA_OBJECT.sign set per [TPM2-Structures].¶

Key Hierarchy:

The AIK SHOULD reside in the Endorsement hierarchy. AIKs in the Platform or Storage hierarchies MAY be used but offer weaker provenance.¶

Certificate Chain:

The AIK certificate chain MUST root to a known TPM manufacturer's EK certificate. The Verifier MUST validate the full chain before accepting HAT proofs.¶

Signature Scheme:

The AIK MUST use one of:¶

• RSASSA-PKCS1-v1_5 with SHA-256¶

• RSAPSS with SHA-256¶

• ECDSA with P-256¶

The Verifier MUST support at least RSASSA-PKCS1-v1_5 with SHA-256 and ECDSA with P-256.¶

Key Conveyance:

The AIK public key and certificate chain MUST be conveyed to the Verifier, either out-of-band or inline per the consuming protocol.¶

Discrete TPM:

For high-assurance scenarios, Verifiers SHOULD require attestation that the TPM is a discrete hardware module, not a vTPM.¶

4.3. Clock-Safe and Reset Semantics

The clockInfo.safe field indicates clock reliability. The TPM sets safe to NO on clock discontinuity:¶

• Platform power loss with disturbed or absent battery-backed RTC.¶

• Hardware anomaly affecting clock integrity.¶

• Explicit TPM2_ClockSet (typically restricted to platform hierarchy).¶

A resetCount mismatch between T_before and T_after indicates a platform reboot during computation. A reboot resets volatile TPM state and allows the operator to manipulate the computation environment. A restartCount mismatch indicates hibernation/resume, which preserves the clock but allows state inspection.¶

For multi-invocation chains, a resetCount change between T_after of invocation n-1 and T_before of invocation n breaks temporal chain continuity.¶

5.1. hat-proof CDDL

The HAT proof is encoded in CBOR [RFC8949] per [RFC8610]:¶

hat-proof = {
    1 => bstr,     ; time-before (TPMS_TIME_ATTEST_INFO)
    2 => bstr,     ; time-after (TPMS_TIME_ATTEST_INFO)
    3 => bstr,     ; sig-before (AIK signature)
    4 => bstr,     ; sig-after (AIK signature)
}

{
  1: h'ff20...0140',    / time-before: TPMS_ATTEST /
  2: h'ff20...0280',    / time-after:  TPMS_ATTEST /
  3: h'3045...9a7b',    / sig-before: ECDSA-P256   /
  4: h'3045...c4e2'     / sig-after:  ECDSA-P256   /
}

HAT proofs MUST use deterministic CBOR encoding per Section 4.2.1 of [RFC8949].¶

5.2. Field Semantics

5.3. Embedding in Consuming Protocols

The consuming protocol defines:¶

• The position within its Evidence structure for the HAT proof.¶

• AIK conveyance mechanism.¶

• Computation binding (e.g., incorporating T_before into seed derivation).¶

For standalone use, a HAT proof MAY be wrapped in a COSE_Sign1 envelope [RFC9052] with the AIK certificate chain in the unprotected header.¶

6.1. Verification Procedure

The Verifier MUST perform the following checks:¶

1. Signature verification: Verify sig-before and sig-after against the AIK public key. Validate the AIK certificate chain to a known TPM manufacturer root. Reject on failure.¶

2. Attestation type check: Verify both TPMS_ATTEST structures have type = TPM_ST_ATTEST_TIME and magic = TPM_GENERATED_VALUE.¶

3. resetCount consistency: Verify resetCount is identical in T_before and T_after. Reject on mismatch.¶

4. Clock-safe validation: Verify T_before.clockInfo.safe is true; MUST reject if false. If T_after.clockInfo.safe is false, SHOULD reject.¶

5. Time delta check: delta = T_after.clock - T_before.clock MUST be >= the expected computation duration obtained from the Reference Value Provider (Section 3.1). SHOULD flag deltas exceeding a configurable upper threshold (default: 10x expected duration).¶

6. Temporal chain continuity (multi-invocation): T_before.clock of invocation n MUST be strictly greater than T_after.clock of invocation n-1.¶

7. Computation binding (application-specific): If the consuming protocol binds the computation seed to T_before, verify this binding.¶

NOTE: HAT proves a lower bound on computation duration (the TPM clock interval). It does not prove a tight bound; the Attester may introduce delays between T_before/T_after and the actual computation.¶

6.2. Error Handling

Warnings SHOULD be included in the Attestation Result.¶

7.1. TPM Clock Manipulation

• Voltage glitching: Targeted voltage manipulation may cause clock skips. Requires physical access and specialized equipment.¶

• TPM reset attacks: Power-cycling resets volatile state, detectable via resetCount.¶

• VM-based attacks: vTPMs do not provide discrete TPM hardware guarantees. See Section 4.2 for discrete TPM requirements.¶

7.2. AIK Compromise

AIK extraction (via side-channel or fault injection) enables forging HAT proofs with arbitrary timestamps. Verifiers SHOULD support AIK revocation.¶

7.3. Replay Attacks

Without qualifying data binding, HAT proofs can be replayed for different computations. Applications SHOULD include computation-specific qualifying data. For multi-invocation chains, temporal chain continuity prevents insertion of old proofs.¶

7.4. Clock Drift and Resolution

TPM clocks lack mandated accuracy; typical drift is seconds per day. Verifiers SHOULD use a tolerance factor (5-10%) when comparing deltas to expected durations.¶

The TPM 2.0 specification defines clockInfo.clock as a millisecond counter, but actual update granularity is implementation-dependent. Some TPMs update the clock at intervals of 10ms or coarser. For computations shorter than approximately 100ms, clock resolution may dominate the measurement error. HAT is best suited for computations lasting at least one second.¶

7.5. Scope Limitations

This specification covers TPM 2.0 only. Other hardware platforms (ARM TrustZone, Intel SGX, Apple Secure Enclave) are out of scope.¶

8.1. Device Identification

AIKs are device-specific and potentially identifying. To mitigate correlation:¶

• Privacy CA: Issues AIK certificates without revealing the EK.¶

• Direct Anonymous Attestation (DAA): Proves TPM authenticity without persistent identifiers.¶

8.2. Uptime Leakage

TPM clock readings reveal platform uptime, a fingerprinting vector. When uptime exposure is unacceptable, the consuming protocol MAY strip absolute clock values, retaining only the time delta.¶

8.3. Data Minimization

The TPMS_ATTEST structure contains fields beyond what HAT verification requires (firmwareVersion, qualifiedSigner). The consuming protocol MAY define a reduced format including only clock values, resetCount, safe flag, and the AIK signature.¶

10.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[TPM2-Commands]

Trusted Computing Group, "Trusted Platform Module Library, Part 3: Commands", TCG Revision 01.59, 2019, <https://trustedcomputinggroup.org/resource/tpm-library-specification/>.

[TPM2-Structures]

Trusted Computing Group, "Trusted Platform Module Library, Part 2: Structures", TCG Revision 01.59, 2019, <https://trustedcomputinggroup.org/resource/tpm-library-specification/>.

10.2. Informative References

[I-D.birkholz-rats-tuda]

Birkholz, H., "Time-Based Uni-Directional Attestation", Work in Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 2023, <https://datatracker.ietf.org/doc/html/draft-birkholz-rats-tuda-07>.

[RFC3161]

Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.