Glossary
The vocabulary used across the Mero TEE docs. Only terms this system actually
uses are listed; the protocol-level concepts (namespaces, the ReadOnlyTee and
RelayTee roles, fleet admission) are defined in
Calimero Core → TEE Attestation & Fleet Admission.
Attestation — the process by which a TEE proves its software identity and integrity to a remote party. In TDX it produces a signed quote containing the running code’s measurements; the verifier checks that quote against expected values.
Attestation policy — the allowlist the KMS enforces before releasing a key:
allowed MRTD, RTMR0–3, and TCB-status values (AttestationPolicy in
mero-kms/src/policy.rs). Baked into the KMS image (ALLOWED_* in
/etc/mero-kms/kms.env) from the node release it ships with. The release also
publishes it, together with the KMS’s own measurements (kms_allowed_*), as the
signed kms-attestation-policy[.<profile>].json that merod uses to pin the KMS.
Attestation verifier — the public React + Vercel-serverless tool
(attestation-verifier/) that verifies a KMS or node quote independently, via
Intel Trust Authority.
Bootstrap replica — the one KMS replica of a new cluster started with
kms-bootstrap=true instance metadata (MERO_KMS_BOOTSTRAP). It generates the
cluster root in RAM; every other replica joins. kms-bootstrap is cleared once
the cluster has formed, since a second bootstrap would mean a second root.
Challenge — a single-use, TTL-bound 32-byte nonce the KMS issues from
POST /challenge. The node must embed it in its quote’s report_data. It is
stateless: MAC’d with a key derived from the cluster root and carrying its expiry
and peer ID, so any replica can redeem it; each replica keeps a replay set until
expiry.
ChallengeId — the stateless challenge token returned by /challenge and echoed
back to /get-key: 16 random bytes and the expiry, hex-encoded to 48 characters. Its
nonce is an HMAC-SHA256 over the ID and the peer ID under a key derived from the
cluster root (mero-kms/src/stateless_challenge.rs). (It is not a UUID.)
Cluster — the five KMS replicas (three zones, at least two regions) that serve one release, behind one VPC-internal URL. One cluster per release; an upgrade brings a new one.
Cluster root — the random 32-byte secret every node key of a release derives
from (HKDF(root, "{namespace}/{profile}/{peerId}")), along with the transport
key for sealed release and the challenge key. It exists only in the memory of the
cluster’s replicas: never written to disk, never backed up. Losing every replica
loses it, which costs node replacements, not data.
Cohort separation — cryptographic isolation between image profiles: each profile extends RTMR3 with a distinct runtime event, so a debug node’s quote can never satisfy a production policy. Reinforced by the profile being baked into the key-derivation path.
compatibility-catalog.json — the repo-root catalog mapping each release
version to its kms_tag, node_image_tag, and policy URLs. Refreshed after a
release by the update-compatibility-catalog workflow.
CVM (Confidential VM) — a VM with hardware-enforced memory encryption and
isolation. Both merod nodes and the KMS run as TDX CVMs on GCP; the hypervisor
cannot read or tamper with their memory.
Debug TD — a TD launched with the TDATTRIBUTES debug bit. It reports the
same measurements as a normal TD of the same image, but its host can read its
memory, so the KMS refuses to start in one and never gives the root to one.
dm-verity — the kernel’s block-level integrity check. Both images’ root filesystems are read-only EROFS sealed behind dm-verity, with the root hash on the measured kernel command line, so an offline edit of the boot disk is a read error rather than different code.
Fleet HA sidecar — the systemd service baked into node images
(mero-tee/ansible/roles/merotee/templates/fleet-sidecar.sh.j2). On a one-second
loop it polls the fleet control plane (MDMA) for namespace assignments and drives
merod via meroctl tee fleet-join / meroctl namespace leave. It is only the
trigger — the actual admission, eviction, and key purge happen in Calimero Core.
ITA (Intel Trust Authority) — Intel’s hosted attestation service. It appraises a TDX quote and returns a signed JWT with the verified measurements and TCB status. The attestation verifier uses it as an independent oracle.
Join — how a KMS replica other than the bootstrap one obtains the cluster
root: POST /cluster/nonce, then POST /cluster/join with its quote and a
one-time X25519 key. The giver releases the root, sealed to that key, only if the
quote carries exactly its own MRTD and RTMR0–3 (“same as me”), is not a debug
TD, and has an allowed TCB status; the joiner checks the giver’s quote the same
way before accepting. Peer addresses come from kms-peers metadata and are
untrusted.
Key derivation — the KMS derives a storage key by HKDF from the cluster root
on the path {KEY_NAMESPACE_PREFIX}/{profile}/{peerId} (default prefix
merod/storage). It is deterministic: the same inputs always yield the same key
from any replica of the cluster, and different profiles yield different keys for
the same peer.
Key release — the /challenge → /get-key flow by which an attested node
obtains its storage encryption key. See key release.
KMS (mero-kms) — the Rust/Axum Key Management Service (mero-kms/) that
validates node attestations and releases storage encryption keys derived from its
cluster root. It runs as the frozen GCP TDX image merotee-kms-<profile>-<version>.
kms-url — the node instance-metadata key naming the KMS cluster’s
VPC-internal URL. MDMA sets it; calimero-init passes it to merod init --kms-url, which stores it as tee.kms.url.
MDMA — the fleet control plane. It deploys each release’s KMS cluster and
nodes, and decides which namespaces a fleet node should join: the fleet HA
sidecar polls it (/api/fleet/should-join) with the node’s peer_id and MRTD,
and confirms admissions back to it.
Measurement — a hardware-computed hash written into MRTD or an RTMR. In this
system each is a 48-byte (96-hex-char) SHA-384 value (HexMeasurement).
merod — the Calimero node daemon from calimero-network/core. In the TEE context it runs inside a TDX CVM and fetches its storage key from the KMS at boot.
MRTD (Measurement of the Trust Domain) — the SHA-384 measurement of the
initial VM image, computed by the CPU before the guest runs. Any change to the
image changes it, pinning the exact binary. A node can also read its own MRTD
from /sys/class/misc/tdx_guest/measurements/mrtd:sha384.
Mutual attestation — the two-sided trust model for key release: the node
verifies the KMS (via /attest) and the KMS verifies the node (via
/challenge + /get-key). See trust model.
Nonce — a fresh random value that binds an attestation or challenge to a
specific request, preventing replay. Carried in the first 32 bytes of a quote’s
report_data.
PeerId — the node’s libp2p peer identifier, derived from its public key and encoded in base58btc. Used as the node’s identity in the challenge–response flow and as an input to key derivation.
Profile — one of three image build configurations: debug (full access),
debug-read-only (read-only root, SSH retained), or locked-read-only
(production: no SSH, locked down). Each writes a distinct RTMR3 event for cohort
separation, and the KMS also pins its own profile via /etc/mero-kms/image-profile.
published-mrtds.json — the node-release artifact listing the MRTD (and related measurements) of the images built in that release, per profile. The verifier and operators use it to know which node measurements are legitimate.
Quote (TDX quote) — the signed data structure the TDX hardware produces,
containing the Trust Domain’s measurements (MRTD, RTMR0–3), the caller-supplied
report_data, and a hardware signature. Verifiers use it to confirm a running
enclave’s software identity.
report_data — 64 caller-supplied bytes baked into a quote. Mero TEE splits it
as nonce ‖ binding: for /get-key the binding is SHA-256(peerId); for
/attest it defaults to SHA-256("mero-kms-attest-v1").
RTMR (Runtime Measurement Register) — one of four extend-only registers
(RTMR0–3) that record measurements across the VM lifecycle. RTMR0 ≈ firmware,
RTMR1 ≈ kernel/boot, RTMR2 ≈ application/kernel-cmdline, RTMR3 ≈ post-boot runtime
events. In Mero TEE, RTMR2 carries the injected calimero.root_hash and RTMR3
carries the profile/role separation.
ServiceError — the KMS’s centralized error enum (mero-kms/src/handlers/errors.rs).
Its HTTP mapping: invalid_request / invalid_peer_id (400), invalid_challenge
/ invalid_signature / attestation_verification_failed (401),
tcb_status_rejected / measurement_policy_rejected (403), rate_limited (429),
policy_not_ready (503), key_derivation_failed (500). See
error handling.
Sigstore — the keyless (GitHub OIDC) signing used for release assets such as
published-mrtds.json; no signing key is stored in the repo.
Storage encryption key — the key that decrypts a node’s on-disk state, derived
from the cluster root and released by the KMS, sealed, after a successful
attestation. It is unrelated
to the per-group keys a TEE member (ReadOnlyTee or RelayTee) receives in
Core.
TCB (Trusted Computing Base) — the hardware/firmware/software critical to a
TEE’s security. A quote reports a TCB status (e.g. UpToDate,
SWHardeningNeeded, OutOfDate); the policy allowlists which are acceptable
(default: uptodate; mero-tee releases currently also declare outofdate,
see the release pipeline). The allowlist is a declared release input, not a
reading taken from the release probe host — see
release pipeline.
TDVF (TDX Virtual Firmware) — the UEFI-based firmware that runs inside a Trust Domain during early boot and extends RTMR0.
TDX (Trust Domain Extensions) — Intel’s hardware technology for isolated, memory-encrypted VMs (Trust Domains) with CPU-signed attestation. It is the TEE this system uses.
TEE (Trusted Execution Environment) — a hardware-isolated environment that protects code and data from the host OS and hypervisor. Intel TDX (VM-level) and Intel SGX (process-level) are examples; Mero TEE uses TDX.
Trust Domain (TD) — a single TDX-protected VM, with its own encrypted memory,
measurement registers, and attestation. Each merod node and the KMS is one.