Cryptography

Complete reference for cryptographic primitives, libraries, and security mechanisms in dStack

Cryptographic Security Model

Overview: The dStack framework leverages Intel TDX’s hardware protections alongside a suite of vetted cryptographic libraries to secure data in use, in transit, and at rest. Running applications inside a TDX Trusted Domain (TD) means even a privileged host or hypervisor cannot directly access the app’s memory or secrets. Intel TDX enforces hardware memory encryption: each TD’s memory is encrypted with a unique key generated by the CPU and stored internally (lost on reset), so plaintext memory is never exposed to the host. On top of this foundation, dStack employs strong cryptographic primitives to manage keys, encrypt sensitive data, and authenticate communication. All chosen algorithms and libraries are high-assurance and industry-proven, ensuring the TEE’s security model remains robust against modern threats. Below, we detail each cryptographic component, the guarantees it provides, and how it integrates into dStack’s TDX-based architecture (covering Remote Attestation TLS, key management, and sealed data handling).

ring – Core Cryptographic Primitives

The ring library is the cornerstone for many cryptographic operations in dStack. It provides a safe, fast implementation of essential algorithms (symmetric ciphers, hash functions, signature schemes, etc.), largely drawing from BoringSSL’s battle-tested primitives. In practice, ring delivers constant-time, memory-safe implementations of algorithms like AES, SHA-2, HMAC, RSA, and ECDH/ECDSA, optimized in assembly for performance and security. By using ring, dStack benefits from ring’s rigorous testing and optimization process – ensuring cryptographic operations are correct and side-channel resistant.

Integration: In dStack, ring serves as the cryptographic backbone. It underpins the TLS stack (via rustls) by handling low-level cryptography such as the AES-GCM cipher, X25519 elliptic-curve Diffie–Hellman, and HMAC-based key derivation during handshakes. It is also likely used for random number generation (leveraging a secure OS entropy source) and any signature verification needed (for example, verifying Intel’s attestation signatures or certificates). By relying on ring, dStack avoids unsafe or outdated cryptography – only modern, vetted algorithms are enabled. This library’s focus on a “safe, fast, small crypto” core aligns with dStack’s security-first approach, minimizing both the attack surface and the chance of misimplementation. Overall, ring reinforces the correctness and reliability of every cryptographic operation inside the TEE.

rustls – Secure TLS with Remote Attestation

dStack uses rustls as its TLS library to secure communications to and from the TEE. Rustls is a modern TLS 1.2/1.3 implementation in Rust that emphasizes strong defaults and avoids legacy vulnerabilities. By design, rustls only offers high-grade ciphers and requires no insecure configuration, providing state-of-the-art cryptographic security out of the box. This means dStack’s TLS channels benefit from protocols like TLS 1.3, forward secrecy (ephemeral ECDH key exchanges), and robust cipher suites (e.g. AES-GCM and ChaCha20-Poly1305) with no support for obsolete algorithms. The entire stack is memory-safe, eliminating many classes of TLS vulnerabilities stemming from memory errors.

Integration (RA-TLS in dStack): Critically, dStack integrates rustls with Remote Attestation TLS (RA-TLS) to authenticate the TEE itself to clients. In a traditional TLS handshake, the server presents an X.509 certificate signed by a CA. dStack instead uses an attestation-backed certificate: when a TEE instance starts, it generates a fresh (ephemeral) keypair inside the enclave and includes the new public key in its TDX attestation quote. The attestation quote (signed by Intel’s attestation service) is then embedded into an X.509 certificate which is presented during the TLS handshake. This design eliminates any need to provision long-term private keys to the enclave. A remote client (or dStack gateway) connecting over TLS can extract the quote from the certificate, verify it against Intel’s attestation certs, and thereby trust that the TLS public key truly belongs to a genuine TDX enclave with an approved measurement. Once the quote is validated, the client knows it is talking to an attested dStack TD and can proceed to establish the TLS channel. All standard TLS guarantees (encryption, integrity, perfect forward secrecy) then apply to the connection, with the added assurance that one endpoint is a trusted enclave.

Using rustls to implement RA-TLS means this complex process is handled with high-level Rust safety and ring’s cryptography. For example, rustls (with ring) will perform the TLS 1.3 handshake using the enclave’s ephemeral key, negotiate an AES-GCM session key, and then encrypt all traffic to the enclave. The result is a secure channel where both confidentiality and endpoint authenticity (via attestation) are guaranteed. By adopting RA-TLS, dStack ensures that secret data can be sent into a TDX enclave only after verifying the enclave’s identity, embodying a strong zero-trust posture toward the host and network. The use of rustls further reinforces reliability: it has no unsafe code and is widely audited, giving researchers confidence that the TLS/attestation integration in dStack is sound and free from common pitfalls.

sodiumbox – Sealed Box Encryption for Secrets

dStack handles sensitive user data (like environment variables, API keys, etc.) via an Encrypted Environment Variables mechanism to ensure the host never sees them in plaintext. The sodiumbox library underpins this feature. SodiumBox is a pure-Rust implementation of libsodium’s Sealed Boxes, which provide anonymous public-key encryption of messages. Under the hood, sodiumbox uses well-regarded NaCl primitives: Curve25519 (X25519) for elliptic-curve key exchange, XSalsa20-Poly1305 for symmetric authenticated encryption, the HSalsa20 function and BLAKE2 hash for deriving sub-keys. These algorithms collectively allow one to encrypt a message such that only the holder of a designated private key can decrypt it, while providing authenticity (the ciphertext cannot be altered undetected) even if the sender remains anonymous. The use of XSalsa20-Poly1305 (a 256-bit Salsa20 stream cipher with a Poly1305 MAC) ensures high performance and strong security, as pioneered by DJB’s NaCl library.

Integration: In dStack, each TEE (CVM) generates an X25519 keypair internally, and the public key is made available for secret injection. When a user deploys an application, any secret environment variables are encrypted client-side using the enclave’s public key (via sodiumbox’s seal function). The ciphertext is then passed to the platform (or included in the deployment manifest) without ever revealing the secret to the host or dStack control plane. Upon startup, the enclave uses its X25519 private key to open (decrypt) these sealed boxes and retrieve the original secret values, which are then provided to the application. This workflow is explicitly documented: “The environment variables will be encrypted on the client side and decrypted in the CVM before being passed to the containers.”. Even if an attacker intercepts or dumps the host’s storage, the sealed secrets remain unintelligible without the enclave’s private key.

This mechanism effectively implements sealed data handling at the application level – secrets are sealed to the enclave’s identity key. Key management is straightforward and secure: the X25519 private key never leaves the TEE and need not be persisted (a new keypair can be generated for each deployment or enclave reboot). Because sodiumbox is a pure-Rust library (with no C dependencies) created as a drop-in replacement for sodiumoxide’s sealed box API, it inherits libsodium’s strong security model while fitting dStack’s all-Rust, no-unsafe ethos. The result is a highly reliable system for secret management: even without a hardware “seal key”, dStack ensures sensitive data is always encrypted with state-of-the-art public-key cryptography before crossing the TEE boundary.

k256 – High-Assurance secp256k1 Elliptic Curve

dStack includes the k256 library to handle cryptography on the secp256k1 elliptic curve, which is widely used in blockchain and cryptographic applications (for ECDSA signatures and key agreements). The k256 crate is a pure Rust implementation of secp256k1 from the RustCrypto project, designed for security and correctness. It was developed by cryptography engineers as a high-quality alternative to C libraries, featuring constant-time arithmetic and extensive test vectors. The library reuses and adapts well-vetted code (e.g., leveraging techniques from Bitcoin’s secp256k1 library, like endomorphism-based acceleration) to achieve excellent performance without sacrificing safety. By being memory safe and avoiding FFI, k256 eliminates entire classes of vulnerabilities (such as buffer overflows or misused pointers) while performing complex elliptic-curve math.

Integration: While the core dStack framework is agnostic to specific applications, having k256 available means the TEE can securely handle operations involving secp256k1 keys – for example, managing an Ethereum account’s private key, signing transactions, or participating in blockchain consensus from within the enclave. The presence of k256 signals that dStack’s security model extends to cryptocurrency use-cases: any secp256k1 private keys can be kept inside the TDX enclave, and all ECDSA signatures or ECDH exchanges on that curve are done with no exposure to the host. This is particularly relevant given dStack’s origins with Phala Network and other blockchain contributors – secp256k1 is the curve behind Bitcoin, Ethereum, and many other systems. Using k256 gives dStack high confidence in these operations: the implementation is the product of many expert contributors aiming to “produce a high-quality secp256k1 library”. It has been audited through community usage and is constantly updated to reflect best practices in elliptic-curve cryptography. In summary, any component of dStack or enclave application that uses secp256k1 benefits from k256’s strong guarantees of correctness and security, ensuring that cryptographic keys remain safe and cryptographic proofs (signatures) are computed correctly under the hood.

AES-GCM – Authenticated Data Encryption

For symmetric encryption needs, dStack leans on the AES-GCM algorithm – a NIST-approved mode of AES encryption that provides authenticated encryption with associated data. AES-GCM combines the AES 128/256-bit block cipher (for confidentiality) with the Galois/Counter Mode of operation and a built-in Galois Message Authentication Code (for integrity). This means that when dStack encrypts any payload with AES-GCM, the output ciphertext is not only scrambled (unreadable without the key) but also tagged with an authentication code; any modification to the ciphertext or associated metadata will be detected upon decryption. The strength of AES-GCM is well-regarded: it’s a standard cipher for TLS (HTTP/2, HTTP/3 use it), VPNs, and storage encryption, known for its performance and security robustness. NIST’s recommendation highlights GCM as a robust mode for block ciphers, suitable for high-throughput authenticated encryption needs.

Integration: In the dStack security architecture, AES-GCM is used wherever bulk data needs to be symmetrically encrypted. One primary use is within rustls TLS sessions – e.g., dStack’s TLS termination and RA-TLS channels typically use AES-128-GCM or AES-256-GCM cipher suites to encrypt tunnelled data. Additionally, if dStack ever needs to encrypt data at rest (for example, encrypting a file or container image before storing it on untrusted disk), it would employ AES-GCM to protect that data. In doing so, a random 96-bit IV and a symmetric key (derived or generated inside the enclave) are used to encrypt the plaintext and produce a ciphertext + 128-bit authentication tag. Even if an attacker retrieved the encrypted blob, without the key they cannot decrypt it; and any tampering with the ciphertext would render the tag invalid, preventing undetected modifications.

Key Management: Symmetric keys for AES-GCM are managed within the TEE context. They may be derived from a higher-level secret or agreement – for instance, the TLS handshake (via ring and rustls) derives session keys using HKDF and hands them to AES-GCM for packet encryption. In other scenarios, dStack could generate a random key (using ring’s CSPRNG) for file encryption; that key could itself be protected by the enclave (possibly exported only under encryption via sodiumbox or wrapped with an attestation process if it needs to leave). Typically, these keys are ephemeral or enclave-bound: for example, TLS session keys last only for the session and are never written to disk, and any long-term symmetric key would be stored encrypted under an enclave-held key. By using AES-GCM, dStack aligns with industry best practices — this cipher is not only highly efficient on modern CPUs (with AES-NI and PCLMULQDQ instruction support) but also vetted by the cryptographic community. The result is that dStack’s data encryption layer is both secure and performant, ensuring high throughput encryption without sacrificing security guarantees.

Robustness and Best-Practice Assurance

Collectively, these cryptographic components form a layered security model that is resilient against a wide range of threats. Intel TDX provides a hardware root of trust (enforcing memory encryption and secure boot measurements), while Remote Attestation and RA-TLS link that trust to network connections, and high-level encryption schemes protect data flowing in and out of the enclave. Every cryptographic primitive in use – from the X25519 and XSalsa20 of sodiumbox to the secp256k1 and AES-GCM implementations – reflects community-vetted, modern best practices. Notably, dStack avoids weak algorithms and eschews any “roll-your-own” crypto; it relies on proven libraries like ring and RustCrypto crates, which have undergone scrutiny. By focusing on pure-Rust or carefully vetted code, dStack reduces the risk of memory safety bugs and integrates smoothly with the TEE threat model (minimizing reliance on the untrusted host).

Key management is handled with a principle of least privilege and ephemerality: ephemeral keys (for TLS and attestation) mean there are no long-lived private keys to protect on disk, and secrets intended for the enclave are always encrypted in transit (using the enclave’s public key or TLS channel). If persistent storage of secrets is required, dStack would seal them by encryption tied to the enclave’s identity or a user-provided passphrase, ensuring that even if data is saved outside the enclave, it remains protected by strong cryptography. The framework’s reliance on primitives like AES-GCM for any such storage guarantees both confidentiality and integrity of sealed data.

In summary, the dStack cryptographic security model is built on robust, high-assurance tools that complement the guarantees of Intel TDX. By using these well-known libraries and algorithms, dStack instills confidence that data and communications are protected to the highest standards. Security researchers will recognize that each component – ring, rustls (with RA-TLS), sodiumbox, k256, AES-GCM – has been chosen precisely because it upholds correctness and soundness under scrutiny. This deliberate design ensures that dStack’s confidentiality and integrity promises in a TDX environment stand on a firm, industry-best foundation, without introducing undue risk or weak links in the cryptographic chain.

Online Source References:

1. Dstack Encrypted Env Vars – DStack Documentation (GitHub source)

2. Rustls Security Overview – Rustls Docs

3. Intel TDX RA-TLS Design – Intel® TDX Documentation (Download PDF)

4. SodiumBox Crate Info – Lib.rs (Kevin Wang)

5. k256 crate announcement – Tony Arcieri, Iqlusion Blog

6. NIST GCM Recommendation – NIST SP 800-38D (2007)

7. ring Cryptography Library – docs.rs: safe, fast, small crypto using BoringSSL primitives

Source Code References

This article is based on the following key modules and scripts from the DStack codebase:

• ra-tls/src/cert.rs:
  Implements X.509 certificate generation, custom extension embedding (TDX quotes, event logs, app IDs), and certificate signing logic for RA-TLS.

• ra-tls/src/kdf.rs:
  Provides the HKDF-based key derivation framework, including context separation and domain-specific key generation.

• ra-tls/src/attestation.rs:
  Handles TDX quote processing, attestation report generation, and integration with Intel DCAP QVL for quote verification.

• sodiumbox/src/lib.rs:
  Pure Rust implementation of libsodium-compatible sealed box encryption, using X25519 and XSalsa20-Poly1305.

• kms/src/crypto.rs:
  Core cryptographic operations for the Key Management System, including key derivation, ECDSA/secp256k1 signing, and hash utilities.

• gateway/src/main.rs:
  Main entry point for the dstack gateway, orchestrating authentication, certificate validation, and secure communication.

• Cargo.toml:
  Project manifest listing cryptographic dependencies (e.g., ring, rustls, sodiumoxide), feature flags, and build configuration.

For operational security best practices, refer to the deployment documentation.
For a detailed overview of system architecture, see the infrastructure documentation.

For further exploration, consult the DStack GitHub repository and review the latest code for updates and implementation details.