Trusted Execution Environments (TEEs) are revolutionizing how we build secure, privacy-preserving applications—especially in Web3 and AI. But how can users truly trust that a cryptographic key or sensitive computation is genuinely protected inside a TEE, and not just claimed to be? In this post, we’ll walk through how Dstack delivers end-to-end verifiability for TEE applications, addressing the real-world challenges of Zero Trust security.
Why Verifiability Matters for TEE Applications
Traditional Zero Trust systems, like smart contracts, are easy to verify: their code and inputs are public, and anyone can check what’s happening. But real-world applications are more complex. They often need to keep code or data private, use third-party dependencies, and run on infrastructure managed by others. This makes it much harder to prove that what’s running is what’s claimed.
Dstack tackles these challenges with a verification framework that minimizes code changes and fits into existing development workflows. Let’s see how this works in practice.
Threat Model
Before diving into the solution, it’s important to understand the risks. Dstack’s framework assumes its core components (Dstack-OS, Dstack-KMS, Dstack-Gateway, and governance contracts) are implemented correctly, but considers developers and administrators as potential adversaries. Here are some of the main attack vectors:
-
Application-Level Attacks
- Deploying unauthorized or malicious code (e.g., falsified Docker images)
- Introducing malicious dependencies via supply chain attacks
- Updating applications without proper governance
-
Infrastructure-Level Attacks
- Tampering with Dstack-OS
- Deploying compromised key management services
- Running on unpatched or vulnerable TEE firmware
- Faking TEE attestation on non-TEE hardware
-
Network-Level Attacks
- DNS hijacking to redirect users
- Man-in-the-middle attacks on communication channels
Direct hardware attacks (e.g., exploiting TEE hardware vulnerabilities) are out of scope for this discussion.
The Reproducibility Challenge
A core challenge in TEE attestation is bridging the gap between source code and the actual artifact (binary or container image) running inside the enclave. TEE attestation can prove that a specific artifact is running securely, but not that the artifact matches the reviewed source code.
This opens up several risks:
- Source Code Manipulation: Deploying artifacts that differ from the public code
- Build Process Compromise: Injecting malicious code during artifact creation
- Toolchain Vulnerabilities: Compromised compilers or build tools (think Ken Thompson’s classic hack)
TEE quotes only attest to cryptographic hashes of running artifacts. Without a way to link these hashes back to trusted source code, users can’t fully trust the application—even inside a TEE.
Establishing a complete verification chain requires:
- Source Code Verification: Open-source code or trusted third-party review
- Build Process Integrity: Reproducible builds for independent artifact verification
- Runtime Attestation: TEE quotes proving that verified artifacts are actually running
Traditional reproducible builds are ideal, but often impractical for complex applications. Dstack introduces an alternative: In-ConfidentialContainer (In-CC) Build.
Dstack Core Component Verifiability
Each Dstack component implements specific verifiability mechanisms, anchored in transparent, immutable records:
| Component | Source | Build Method | Registry | Verification |
|---|---|---|---|---|
| Dstack-OS | Open | Reproducible | KmsAuth | OS Digest |
| Dstack-KMS | Open | In-CC | KmsAuth | Image Hash, Root PubKey |
| Dstack-Gateway | Open | In-CC | AppAuth | Image Hash |
- Dstack-OS is fully open-source, reproducibly built, and audited.
- Dstack-KMS and Dstack-Gateway use In-CC Build, where the build process happens inside a verified Dstack-OS environment. This ensures that code fetching, compilation, and artifact creation are all attested and measured.
Governance smart contracts (KmsAuth and AppAuth) serve as authoritative registries, anchoring each component’s trust base.
What is In-ConfidentialContainer Build?
While reproducible builds are the gold standard, they’re often too complex for real-world use. In-CC Build executes the entire build process inside a verified Dstack-OS TEE, using precise source references (e.g., a specific git commit). The resulting artifact’s measurements are included in TEE quotes, providing strong guarantees with less operational overhead.
End-to-End Verification: A Step-by-Step Example
Let’s walk through how a user can verify that a cryptographic key was genuinely generated inside a TEE, using Dstack’s chain of trust.
1. Root of Trust: KmsAuth Contract
- The address of the Dstack-KMS governance contract (KmsAuth) is public.
- KmsAuth records measurements (hashes) of KMS node programs and the TDX Quote of the first KMS node (the primary key generator).
- New KMS nodes must be registered and verified before participating in key generation.
- Users can verify KMS node integrity and code correctness using these records and the open-source codebase.
2. Verifying Dstack-Gateway
- Dstack-Gateway is registered and verified by KMS nodes.
- Users can request the Gateway’s TEE Quote and check its artifact digest against the governance contract and codebase.
- Once verified, the Gateway generates its root key and certificate chain.
3. Deploying and Verifying the TEE Application
- The application is registered in KmsAuth, with its artifact digest stored in a dedicated AppAuth contract.
- KMS nodes verify the application’s TEE Quote and ensure it matches the registered digest.
- Only after successful verification is the key generated and the certificate chain issued.
- The application must also register with the Gateway, which checks the certificate chain and root certificate.
4. User Interaction and Proof
- Users access the application via the Gateway, delegating verification.
- The application can generate a TEE Quote on demand, including the generated public key as custom data.
Security Analysis: Mitigating Threats
Dstack’s approach covers multiple attack surfaces:
- Application Level: Only authorized code can be deployed, thanks to measurement verification and registry checks. In-CC Build ensures dependencies are verified, and updates require new registry entries and re-verification.
- Infrastructure Level: TDX Quotes verify Dstack-OS integrity. KMS updates require multi-signature governance. Firmware versions are validated to ensure up-to-date TEE hardware.
- Network Level: Certificate chain validation prevents DNS hijacking and man-in-the-middle attacks, ensuring authentic application identity and end-to-end encryption.
Note: Code audits and reviews remain essential for correctness. In-CC Build guarantees build integrity, not code quality.
Future Works
We’re committed to making Dstack’s verification tools even more accessible and robust. Here’s what’s coming next:
- Enhanced User Interface: We plan to deliver a more intuitive UI that clearly displays vital information—such as the KmsAuth contract address, TEE Quote breakdowns, and source code references—making verification easier for all users.
- Supply Chain Verification Integration: By incorporating tools like Sigstore, we aim to provide independent verification of the build process. When combined with In-CC Build, this will offer even stronger guarantees of artifact integrity and provenance.
- GitHub Actions Integration: We’re working on seamless integration with GitHub Actions to help teams adopt best practices for verifiable application builds, streamlining the path from source code to trusted deployment.
Stay tuned for updates as we continue to advance the usability and security of Dstack’s verification ecosystem.
Conclusion
Dstack provides a practical, comprehensive framework for verifying TEE applications in the real world. By combining open-source transparency, attested build processes, and authoritative registries, it enables users to trust that cryptographic keys and sensitive computations are genuinely protected—without sacrificing developer productivity or privacy.
Want to learn more? Check out the Dstack documentation or dive into the source code to see these mechanisms in action!