Glossary

The process by which a TEE proves its identity and integrity to a remote party. In TDX, attestation produces a cryptographic quote containing measurements of the running code and hardware configuration. The remote party verifies the quote against expected values.

A JSON document specifying which TDX measurement values (MRTD, RTMR0–3) and TCB statuses the KMS considers acceptable. Fetched from GitHub releases and optionally pinned by SHA-256 hash. See Config Reference.

A public web application (React + serverless API) that allows anyone to verify a KMS instance is running inside a genuine TDX enclave. Chains the KMS self-attestation through Intel Trust Authority. See Attestation Flow.

A time-limited, single-use nonce issued by the KMS during the key release protocol. The node must produce a TDX quote binding this nonce to prove freshness. Stored in the ChallengeStore (InMemory or Redis).

A UUID v4 identifier returned by POST /challenge. Used to look up and consume the associated nonce during POST /get-key. Single-use: consumed on first retrieval.

Trait-based storage abstraction for challenge nonces. Two implementations: InMemoryStore (DashMap, single-instance) and RedisStore (multi-instance). Maps challengeId → (nonce, peerId, expiry).

Cryptographic isolation between image profiles via distinct RTMR3 runtime events. A debug node’s RTMR3 differs from production, preventing cross-profile key access. Enforced by TDX hardware.

A release artifact that maps compatible combinations of mero-kms-phala and merod image versions. Used by the release pipeline to determine which KMS builds can serve keys to which node builds. Published alongside published-mrtds.json in GitHub releases.

A SHA-256 digest of the Docker Compose file used to deploy a CVM workload. Recorded during image build and included in attestation artifacts, allowing verifiers to confirm the exact orchestration configuration that was launched.

A virtual machine with hardware-enforced memory encryption and isolation. In mero-tee, merod nodes and the KMS run as GCP TDX Confidential VMs. The hypervisor cannot read or tamper with CVM memory.

The most permissive image profile. Enables SSH access and a read-write filesystem, intended for development and troubleshooting only. Writes a unique RTMR3 runtime event so that debug nodes are cryptographically separated from production cohorts and cannot obtain production keys.

An intermediate image profile that permits SSH access for inspection but enforces a read-only root filesystem. Provides observability without allowing runtime modification of binaries or configuration. Writes a distinct RTMR3 event for cohort separation.

Phala Network’s TEE runtime that provides deterministic key derivation and TDX quote generation. The KMS communicates with dstack via a Unix domain socket. dstack seals a root key to the hardware, enabling repeatable key derivation.

The release lane that produces merod node images for GCP TDX Confidential VMs. Builds are measured at image creation time, and the resulting MRTD values are published in published-mrtds.json so the KMS can verify nodes at key-release time.

HMAC-based Key Derivation Function (RFC 5869). Used by dstack to derive deterministic encryption keys from a root secret and application-specific inputs (namespace + peerId). The same inputs always produce the same output.

Intel’s cloud service for remote attestation verification. Accepts TDX quotes and returns signed JWTs containing verified measurements and TCB status. Used by the Attestation Verifier for independent verification.

The process of generating a storage encryption key from dstack’s sealed root secret. Uses KEY_NAMESPACE_PREFIX + peerId as input. Deterministic: the same node always receives the same key.

The Key Management Service — a Rust HTTP service running inside a TDX enclave. Validates node attestations and releases storage encryption keys via Phala dstack. See System Overview.

Per-profile attestation policy files published in GitHub releases (e.g. kms-phala-attestation-policy.locked-read-only.json). Each file lists the MRTD and RTMR0–3 values and acceptable TCB statuses for that profile. The KMS fetches and applies the policy matching the requesting node’s profile.

The most restrictive (production) image profile. Disables SSH entirely and enforces a read-only root filesystem, minimising the attack surface. This is the only profile intended for production workloads. Its unique RTMR3 event ensures it receives a distinct key cohort.

The Calimero node daemon from the core repository. In the TEE context, merod runs inside a TDX Confidential VM and contacts the KMS on boot to obtain its storage encryption key.

Measurement of the Trust Domain — a SHA-384 hash of the initial VM image at launch time. Computed by the CPU before the guest starts. Any change to the image (even a single byte) produces a different MRTD. Used to pin the exact binary.

The bidirectional trust model where both the node and the KMS verify each other’s TDX attestation before any sensitive operation. Plane 1: node verifies KMS. Plane 2: KMS verifies node. See Trust Model.

A cryptographically random value used to ensure freshness of attestation quotes and challenge-response exchanges. Each nonce is single-use and time-limited (TTL). Prevents replay attacks.

A libp2p peer identifier derived from the node’s Ed25519 public key. Used as the node’s identity in the challenge-response protocol and as input to key derivation. Format: 12D3KooW....

The release lane that builds and deploys mero-kms-phala on Phala Cloud CVMs. Produces a compose_hash that is recorded in attestation artifacts, allowing nodes and the attestation-verifier to confirm the exact KMS deployment.

The governance process for moving an attestation policy from staging to production. A new policy is first deployed behind a staging probe for validation; once the probe confirms successful key release, the policy is promoted to the production KMS configuration.

One of three image build configurations: debug (full access), debug-read-only (SSH + RO filesystem), or locked-read-only (no SSH, RO, minimal surface). Each writes a unique RTMR3 runtime event for cohort separation.

A JSON artifact published in each GitHub release containing the MRTD values of all images built in that release. The KMS references this file (by URL and optional SHA-256 pin) to know which node image measurements are legitimate. See Config Reference.

A cryptographic data structure produced by the TDX hardware that contains the Trust Domain’s measurements (MRTD, RTMR0–3), user-supplied report_data, and a hardware signature. Verifiers use the quote to confirm the software identity of a running enclave.

A 64-byte user-defined field in a TDX quote. The KMS uses this to bind a nonce (and optional context) to the attestation, ensuring the quote was produced for a specific request and cannot be replayed.

Four extend-only registers (RTMR0–3) in TDX that record measurements during the VM lifecycle. Each register captures a different phase: RTMR0 (firmware), RTMR1 (OS kernel), RTMR2 (application), RTMR3 (runtime events). Values can only be extended, never reset.

Firmware measurement. Extended by the TDVF (TDX Virtual Firmware) during early boot. Captures the firmware version and configuration. Changes if the firmware is updated.

OS kernel measurement. Extended during kernel boot. Captures the kernel binary, initrd, and boot parameters. Changes if the kernel or boot configuration is modified.

Application measurement. Extended when the application layer loads. In mero-tee, this captures the merod or KMS binary and its initial configuration.

Runtime event register. Extended during runtime to record dynamic events. In mero-tee, each image profile writes a distinct RTMR3 event at boot, creating cryptographic cohort separation between debug and production nodes.

The centralized error enum in the KMS codebase. Variants: InvalidInput (400), InvalidChallenge (400/401), InvalidSignature (401), PolicyViolation (403), RateLimited (429), PolicyNotReady (503), InternalError (500). See Error Handling.

An automated validation step in the release pipeline that deploys a candidate attestation policy to a staging KMS instance and attempts a full key-release cycle against it. If the probe succeeds, the policy is eligible for policy promotion to production.

The set of hardware, firmware, and software components that are critical to the security of a TEE. TCB status indicates whether the platform’s security patches are current. Possible values: UpToDate, SWHardeningNeeded, ConfigurationAndSWHardeningNeeded, OutOfDate.

Intel’s hardware technology for creating isolated virtual machines (Trust Domains) with CPU-enforced memory encryption. The hypervisor and other VMs cannot access a TD’s memory. TDX provides attestation via cryptographic quotes signed by hardware.

The firmware that runs inside a TDX Trust Domain during early boot. Extends RTMR0 with firmware measurements. Based on UEFI and provides the initial trusted boot environment.

A hardware-isolated processing environment that protects code and data from external access, including the OS and hypervisor. Intel TDX and Intel SGX are examples. mero-tee uses TDX for VM-level isolation.

A TDX-protected virtual machine. Each TD has its own encrypted memory space, measurement registers, and attestation capabilities. In mero-tee, each merod node and the KMS run as separate Trust Domains.