|
| 1 | +# dstack Security Model |
| 2 | + |
| 3 | +dstack protects your code and data from infrastructure operators. Using TEE hardware isolation, your workloads run in encrypted memory that the host cannot read or modify. You can cryptographically verify that your exact code runs in genuine TEE hardware. |
| 4 | + |
| 5 | +This document helps you evaluate whether dstack's security model fits your needs. |
| 6 | + |
| 7 | +## Trust Boundaries |
| 8 | + |
| 9 | +dstack removes the need to trust infrastructure operators. The cloud provider cannot read your memory, modify your code, or access your secrets. Network attackers cannot intercept your traffic because TLS terminates inside the TEE with keys fully controlled by the TEE (Zero Trust HTTPS). Docker registries cannot serve malicious images because the TEE verifies SHA256 digests before pulling. |
| 10 | + |
| 11 | +The only thing you must trust is **TEE hardware** (currently Intel TDX, with AMD SEV support planned). You trust that the TEE provides genuine memory encryption and that quotes are signed by real hardware. For GPU workloads, you also trust **NVIDIA GPU hardware** and NVIDIA's Remote Attestation Service (NRAS). These are hardware-level trust assumptions. |
| 12 | + |
| 13 | +Everything else is verifiable. |
| 14 | + |
| 15 | +**The dstack OS** is measured during boot and recorded in the attestation quote. You verify it by rebuilding from [meta-dstack](https://github.com/Dstack-TEE/meta-dstack) source and comparing measurements, or by checking that the OS hash is whitelisted in a governance contract you trust. |
| 16 | + |
| 17 | +**The KMS** runs in its own TEE with its own attestation quote. You verify it the same way you verify any dstack workload. |
| 18 | + |
| 19 | +### What dstack Cannot Protect |
| 20 | + |
| 21 | +TEE technology has inherent limitations. Side-channel attacks against TEE hardware are researched actively, and microarchitectural vulnerabilities are discovered periodically. Hardware vendors release TCB updates to address these, so keep your TCB version current. |
| 22 | + |
| 23 | +dstack protects the execution environment, not your application code. Bugs in your application remain exploitable. Secrets that you log or transmit insecurely can still leak. Your code must follow secure development practices. |
| 24 | + |
| 25 | +Infrastructure operators can still deny service. They can shut down your workload, throttle resources, or block network access. If availability matters, plan for redundancy across providers. |
| 26 | + |
| 27 | +## Security Guarantees |
| 28 | + |
| 29 | +### Confidentiality |
| 30 | + |
| 31 | +| Layer | Protection | Mechanism | |
| 32 | +|-------|------------|-----------| |
| 33 | +| Memory | Encrypted at runtime | TEE hardware encryption | |
| 34 | +| Disk | Encrypted at rest | Per-app keys from KMS (AES-256-GCM) | |
| 35 | +| Environment | Encrypted in transit | X25519 ECDH + AES-256-GCM | |
| 36 | +| Network | Encrypted end-to-end | Zero Trust HTTPS (TLS terminates in TEE) | |
| 37 | + |
| 38 | +### Integrity |
| 39 | + |
| 40 | +| Component | Verification | Measurement | |
| 41 | +|-----------|--------------|-------------| |
| 42 | +| Hardware | TEE signature | Attestation quote | |
| 43 | +| Firmware | Boot measurement | MRTD | |
| 44 | +| OS | Boot measurement | RTMR0-2 | |
| 45 | +| Application | Runtime measurement | RTMR3 (compose-hash) | |
| 46 | + |
| 47 | +### Isolation |
| 48 | + |
| 49 | +Each application derives unique keys from the KMS based on its identity. Instance-level secrets use the instance ID to create unique disk encryption keys. No keys are shared between different applications. |
| 50 | + |
| 51 | +## GPU Security for AI Workloads |
| 52 | + |
| 53 | +dstack supports NVIDIA H100, H200, and B200 GPUs in confidential compute mode for AI inference and training workloads. |
| 54 | + |
| 55 | +### How It Works |
| 56 | + |
| 57 | +GPUs are passed through via VFIO directly to the TEE-protected CVM. The GPU operates in confidential compute mode, encrypting data during computation. Both the CPU TEE and NVIDIA GPU provide hardware isolation together. If either component fails verification, the security model breaks. |
| 58 | + |
| 59 | +### Dual Attestation |
| 60 | + |
| 61 | +GPU workloads require verification of both hardware components. The CPU TEE provides the quote that verifies CPU and memory isolation. NVIDIA's Remote Attestation Service (NRAS) independently verifies the GPU is genuine and running in confidential mode. Both attestations must pass for complete verification. |
| 62 | + |
| 63 | +### AI Workload Protection |
| 64 | + |
| 65 | +Models and training data stay within the hardware-protected environment. The infrastructure operator cannot access model weights, training data, or inference inputs/outputs. Response integrity is provable through cryptographic signatures generated inside the TEE. Performance overhead is minimal, achieving approximately 99% efficiency compared to native execution. |
| 66 | + |
| 67 | +## Chain of Trust |
| 68 | + |
| 69 | +dstack implements layered verification from hardware to application. Each layer is measured and included in the attestation quote, which TEE hardware cryptographically signs. |
| 70 | + |
| 71 | +``` |
| 72 | +┌─────────────────────────────────────────────────────────────────┐ |
| 73 | +│ Attestation Quote (signed by TEE hardware) │ |
| 74 | +│ ├── Hardware: TEE signature proves genuine hardware │ |
| 75 | +│ ├── MRTD: Virtual firmware measurement │ |
| 76 | +│ ├── RTMR0-2: OS kernel and boot parameters │ |
| 77 | +│ ├── RTMR3: Application (compose-hash) + KMS binding │ |
| 78 | +│ └── reportData: Your challenge (replay protection) │ |
| 79 | +├─────────────────────────────────────────────────────────────────┤ |
| 80 | +│ Event Log (RTMR3 breakdown) │ |
| 81 | +│ ├── compose-hash: SHA256 of your docker-compose │ |
| 82 | +│ ├── key-provider: KMS root CA public key hash │ |
| 83 | +│ └── instance-id: Unique per deployment │ |
| 84 | +└─────────────────────────────────────────────────────────────────┘ |
| 85 | +``` |
| 86 | + |
| 87 | +**Hardware layer.** The TEE provides the root of trust. The attestation quote is cryptographically signed by TEE hardware, and verification confirms the signature chain. The TCB status shows whether firmware is patched against known vulnerabilities. |
| 88 | + |
| 89 | +**OS layer.** The dstack OS is measured during boot into MRTD and RTMR0-2. MRTD captures the virtual firmware. RTMR0 captures firmware configuration. RTMR1 captures the Linux kernel. RTMR2 captures kernel command-line parameters. You verify integrity by computing expected measurements from meta-dstack source and comparing them to the quote. |
| 90 | + |
| 91 | +**Application layer.** Your application is measured into RTMR3 as the compose-hash, which is the SHA256 hash of your normalized docker-compose configuration. Each image must use SHA256 digest pinning. This proves exactly which container images are running and that no code substitution happened after measurement. |
| 92 | + |
| 93 | +**Key management layer.** The KMS root CA public key hash is recorded in RTMR3 as the key-provider event. This binds your workload to a specific KMS instance. The KMS itself runs in a TEE with its own attestation quote, so you can verify the KMS the same way you verify any workload. |
| 94 | + |
| 95 | +## Verification Checklist |
| 96 | + |
| 97 | +Use this checklist to verify a workload running in a dstack CVM. |
| 98 | + |
| 99 | +**Platform verification:** |
| 100 | +- [ ] Attestation quote signature is valid |
| 101 | +- [ ] TCB status is up-to-date (no unpatched vulnerabilities) |
| 102 | +- [ ] OS measurements match expected values (MRTD, RTMR0-2) |
| 103 | +- [ ] OS image hash is whitelisted (if using governance) |
| 104 | + |
| 105 | +**Application verification:** |
| 106 | +- [ ] compose-hash matches your docker-compose |
| 107 | +- [ ] All images use SHA256 digests (no mutable tags) |
| 108 | +- [ ] RTMR3 event log replays correctly |
| 109 | +- [ ] reportData contains your challenge (replay protection) |
| 110 | + |
| 111 | +**Key management verification:** |
| 112 | +- [ ] key-provider matches expected KMS identity |
| 113 | +- [ ] KMS attestation is valid |
| 114 | + |
| 115 | +## Limitations |
| 116 | + |
| 117 | +### Attestation proves identity, not correctness |
| 118 | + |
| 119 | +Attestation proves which code is running, not that the code is bug-free. It proves the environment is isolated, not that your application handles secrets correctly. You still need to audit your application code and follow secure development practices. |
| 120 | + |
| 121 | +### Environment variables need application-layer authentication |
| 122 | + |
| 123 | +Encrypted environment variables prevent the host from reading your secrets. However, the host can replace encrypted values with different ones. Your application should verify authenticity using patterns like LAUNCH_TOKEN. See [security-best-practices.md](security-best-practices.md) for details. |
| 124 | + |
| 125 | +### KMS root key security |
| 126 | + |
| 127 | +All keys derive from the KMS root key, which is protected by TEE isolation. Like all TEE-based systems, a TEE compromise could expose the root key. We are developing MPC-based KMS where the root key is distributed across multiple parties, eliminating this single point of failure. |
| 128 | + |
| 129 | +## Further Reading |
| 130 | + |
| 131 | +For production deployment guidance, see [security-best-practices.md](security-best-practices.md). For smart contract authorization details, see [onchain-governance.md](onchain-governance.md). For technical details about CVM boundaries and APIs, see [cvm-boundaries.md](cvm-boundaries.md). |
0 commit comments