Trusted Execution Environments (TEE)

A Trusted Execution Environment is a hardware-isolated region of a CPU that keeps the code and data running inside it confidential and tamper-proof — even from the operating system, the hypervisor, and the operator of the machine itself. The hardware encrypts the environment's memory and blocks any outside software from reading or modifying it, so a workload can run on infrastructure it does not control without exposing its secrets. Just as importantly, a TEE can produce a signed attestation — a cryptographic measurement of exactly what code is running — that a remote party can verify before deciding to trust it.

Aspens uses this to protect signing keys. The signer service runs inside an Intel TDX (Trust Domain Extensions) Trust Domain — a hardware-isolated confidential VM. Private key material lives only inside that environment; no other process, and no operator, can extract it. Before any relying party trusts the signer with key material, it asks the Trust Domain for an attestation report and checks that the report describes a genuine, unmodified signer enclave. The rest of this page explains how to read that report.

Reading an Aspens TEE Attestation Report

Calling AttestationService.GetAttestation (see protos/attestation.proto) returns an AttestationReport: the body of an Intel TDX quote, with every field rendered as a hex string. These fields are the cryptographic measurements that let a remote verifier decide whether it is talking to a genuine, unmodified signer enclave before trusting it with key material.

The quote also carries an Intel-rooted signature chain (PCK certificates) that proves the body was produced by real TDX hardware. The signature is what makes the report trustworthy; the fields below are what it attests to.

A sample report:

TEE Attestation Report:
  TEE TCB SVN:      0d010800000000000000000000000000
  MR SEAM:          489e585f1c54bc5a02066c8c6ec21619ff0334ec6f21e07e2a35202c59183789c8057e7d97dd591bb08314b185819e72
  MR Signer SEAM:   000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  SEAM Attributes:  0000000000000000
  TD Attributes:    0000001000000000
  XFAM:             e700060000000000
  MR TD:            feb7486608382c1ff0e15b4648ddc0acea6ca974eb53e3529f4c4bd5ffbaa20bf335cb75965cea65fe473aed9647c162
  MR Config ID:     000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  MR Owner:         000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  MR Owner Config:  000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  RTMR[0]:          258d702dd00646d83a5c4158d3821485c8691bdb843342c640ef5830fb7d267591ac795b835653b789c6f93267d0fd49
  RTMR[1]:          812db05a95580a554a9eae4d8f0e9c4f9ea46de3d5890d57dfa09daf875dd7d5aec528ed639b9a53d13268b419da6169
  RTMR[2]:          1a9d1da9b543d2d447b76e12df5d935cedac81225a6b688a0ddb27ed17b3445604afa92adcc428f5a38f095d66d8c21e
  RTMR[3]:          000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  Report Data:      00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Field reference

Decoding the sample

• TD Attributes 0000001000000000 — read as 8 bytes, only bit 28 (SEPT_VE_DISABLE) is set. Critically, bit 0 (DEBUG) is 0: this is a production, non-debuggable TD. A debug TD would have bit 0 set and must never be trusted with real keys.
• XFAM e700060000000000 — enables x87, SSE, AVX, AVX-512 (opmask + ZMM state) and AMX (tile config + tile data). A standard mask for a modern Xeon; nothing unusual.
• MR Signer SEAM, SEAM Attributes — all zero — expected: the production Intel-signed TDX module reports a zero signer and zero attributes.
• MR Config ID / MR Owner / MR Owner Config — all zero — Aspens does not use the owner / config namespacing fields; identity comes entirely from MR TD plus the RTMRs.
• RTMR[3] — all zero — the signer does not extend the application-reserved runtime register. RTMR[0]–RTMR[2] are populated by the measured-boot chain.
• Report Data — all zero — nothing was bound to this particular report. A report used to actually establish trust should carry a non-zero value (a nonce, or the signer's public-key hash); an all-zero Report Data indicates a bare / diagnostic report and should not be accepted as proof that any specific key lives in the TD.

Static identity vs. runtime vs. caller-bound

The fields fall into three groups, which matters when deciding what to pin:

• Platform / TCB — TEE TCB SVN, MR SEAM, MR Signer SEAM, SEAM Attributes. Identify the Intel TDX module and its patch level. Verified against Intel's TCB data, not pinned by Aspens.
• TD build identity — MR TD, TD Attributes, XFAM, MR Config ID, MR Owner, MR Owner Config. Fixed when the signer CVM is built. MR TD is the value to pin to a known-good signer image.
• Runtime + caller — RTMR[0..3] accumulate measured-boot / runtime state; Report Data is whatever the caller asked to bind. These vary per boot and per request.

The RTMR-to-content mapping — firmware in RTMR[0], kernel / bootloader in RTMR[1], OS / initrd / kernel cmdline in RTMR[2], application in RTMR[3] — is a software convention of the measured-boot stack, not fixed by the hardware.

What a verifier should check

Before trusting a signer attestation, a relying party should:

1. Verify the quote signature chain terminates at an Intel root (proves real TDX hardware).
2. Check TEE TCB SVN / MR SEAM against Intel's current TCB info — reject out-of-date platforms.
3. Confirm TD Attributes bit 0 (DEBUG) is clear — reject debug TDs.
4. Pin MR TD (and the expected RTMR values) to a known-good signer build.
5. Confirm Report Data echoes the exact nonce / public-key hash the verifier expected — this is what ties the attestation to this session and this key.

A report that passes 1–4 but has unexpected Report Data proves a genuine signer exists somewhere — but not that it is the party you are talking to.