Glossary
Core terminology used in this documentation.Infrastructure
| Term | Definition |
|---|---|
| TEE (Trusted Execution Environment) | A hardware-isolated compute environment that protects code and data from the rest of the system. Memory is encrypted, and the hardware proves the environment’s integrity via attestation. |
| CVM (Confidential Virtual Machine) | A virtual machine running in a TEE. In dstack-cloud, a CVM runs dstack-os with your Docker containers inside. |
| Intel TDX (Trust Domain Extensions) | Intel’s TEE technology that provides memory encryption and isolation at the VM level. Supported on GCP Confidential VMs and certain bare-metal servers. |
| SGX (Software Guard Extensions) | Intel’s earlier TEE technology. Provides memory encryption at the enclave (process) level. |
| AWS Nitro Enclaves | AWS’s TEE technology. Provides process-level isolation within an EC2 instance. Memory is encrypted and inaccessible to the host. |
| NSM (Nitro Secure Module) | The hardware component in AWS Nitro that generates attestation documents and manages Enclave lifecycle. |
| VSOCK | A socket interface for communication between a Nitro Enclave and its host EC2 instance. The Enclave cannot directly access the network — all traffic goes through VSOCK. |
| EIF (Enclave Image File) | The image format used by AWS Nitro Enclaves. Built from a Docker image, it contains the OS and application code that runs inside the Enclave. |
| TPM (Trusted Platform Module) | A hardware security module that provides secure key storage and measurement. Used on GCP Confidential VMs as the root of trust. |
| PCCS (Provisioning Certificate Caching Service) | Intel’s service for caching attestation certificate chains, used in DCAP (Data Center Attestation Primitives) workflows. |
Security Mechanisms
| Term | Definition |
|---|---|
| Remote Attestation | The process by which a TEE proves its identity and integrity to an external party. The TEE generates a cryptographic proof (signed by hardware) containing measurements of the running code. |
| RA-TLS (Remote Attestation TLS) | An extension of TLS where both parties verify each other’s TEE attestation during the handshake. Used for secure communication between workloads and KMS. |
| ZT-TLS (Zero Trust TLS) | A TLS variant that requires TEE attestation for every connection, regardless of network location. |
| Measurement | A cryptographic hash of the code and configuration running inside a TEE. Any change to the code produces a different measurement. |
| PCR (Platform Configuration Register) | Measurement registers used by AWS Nitro Enclaves (PCR0-3). |
| RTMR (Runtime Measurement Register) | Measurement registers used by Intel TDX (RTMR0-3). |
| OS_IMAGE_HASH | A composite hash derived from all PCR values, used as the unique identifier for a Nitro Enclave image on-chain. |
| compose-hash | The SHA256 hash of the docker-compose.yaml file, stored in RTMR3 on GCP TDX deployments. |
| Quote (TDX Quote) | A hardware-signed attestation proof generated by Intel TDX. Contains measurement values (RTMR0-3) and an Intel hardware signature. |
| Attestation Document | The attestation proof generated by AWS NSM. Contains PCR values and an NSM signature. |
dstack Components
| Term | Definition |
|---|---|
| dstack | The open-source confidential computing framework. Provides a CLI, KMS, attestation, and SDK libraries (Python, TypeScript, Rust, Go) for building confidential applications. GitHub |
| dstack-sdk | Client libraries (Python, TypeScript, Rust, Go) that applications use to interact with dstack features such as attestation, key retrieval, and storage encryption. Part of the dstack framework. |
| dstack-cloud | An extension of dstack that enables deployment on GCP Confidential VMs and AWS Nitro Enclaves. Provides the dstack-cloud CLI. GitHub |
| dstack-os | The minimal operating system that runs inside each dstack CVM. Built from a reproducible Docker image. |
| Guest Agent | A process that runs inside each dstack CVM alongside your application containers. Handles attestation, key retrieval from KMS, and storage encryption. Exposes a local API at /var/run/dstack.sock. |
| KMS (Key Management Service) | A standalone service that runs in its own TEE. Verifies workload attestation and dispatches keys to authorized workloads. Also known as DeRoT (Decentralized Root-of-Trust). |
| Gateway | An edge component that handles TLS termination, automatic ACME certificate provisioning, and RA-TLS support for incoming connections. |
| VMM (Virtual Machine Monitor) | The component that parses Docker Compose files and boots CVMs from reproducible OS images. |
On-chain Governance
| Term | Definition |
|---|---|
| DstackKms | The On-chain KMS policy contract. Stores authorized workload measurements and admin roles. |
| DstackApp | The on-chain application entry contract. Holds a reference to DstackKms. |
| Multisig (Safe) | A multi-signature wallet that controls governance actions. Requires multiple parties to approve any transaction. |
| Timelock | A delay mechanism that enforces a mandatory waiting period between approval and execution of governance transactions. |
| GovernanceSafe | The specific Safe wallet instance used for dstack governance. |
Cryptography
| Term | Definition |
|---|---|
| MPC (Multi-Party Computation) | A cryptographic technique where multiple parties jointly compute a result without any single party learning the inputs. Planned for future KMS root key generation. |
| KDF (Key Derivation Function) | A function that derives application-specific keys from a root key. Each workload gets a unique key derived this way. |
| SealingKey | A key used to encrypt data at rest (disk storage) inside the CVM. Derived from the KMS-delivered key. |
| RootKey | The top-level key in the KMS hierarchy. All application keys are derived from the RootKey. |