Skip to main content

​
Complete Network Privacy Through Hardware

Phala Cloud runs your applications in hardware-encrypted memory where even the cloud provider can’t see your data. Every network connection uses multiple layers of encryption, and you can verify it all cryptographically.

​
Security Architecture

​
Defense in Depth

Phala Cloud implements multiple independent security layers. Each layer assumes others might fail, creating resilient protection: Hardware encryption. Intel TDX encrypts memory with unique per-VM keys. The hypervisor and host OS cannot access these keys—the hardware prevents it. Network isolation. Every packet travels through encrypted tunnels. TLS 1.3 protects client connections, then WireGuard isolates CVM traffic from the host network. Certificate security. TEEs generate ACME accounts inside encrypted memory. Private keys exist nowhere else—they’re mathematically bound to the TEE instance.

​
Application Responsibility

Your code, your security. We protect the infrastructure layer. Application vulnerabilities like SQL injection or authentication bugs remain your responsibility. Think of us as an armored truck: we secure the transport, not what you put inside.

​
Network Architecture

​
Hardware Isolation

Your application runs in a Confidential VM (CVM) protected by Intel TDX. Here’s the architecture: 
Physical Server
├── Intel TDX (hardware root of trust)
├── Your CVM (encrypted with unique key)
│   ├── WireGuard tunnel (your keypair only)
│   ├── Docker network (172.x.x.x)
│   └── Your containers
└── Someone else's CVM (different encryption key)
    └── Can't see your traffic or memory
The key point: each CVM gets its own encryption key from the hardware. The host OS literally cannot decrypt your memory—it doesn’t have the key.

​
Traffic Flow

Standard HTTPS traffic follows this path: 
Browser → TLS 1.3 → Gateway → WireGuard → Your CVM → HTTP → Container
The gateway (also in a TEE) strips TLS and immediately re-encrypts with WireGuard. Your data is never in plaintext on the host. TLS passthrough mode preserves end-to-end encryption: 
Client → TLS → Gateway → WireGuard[TLS] → Your CVM → TLS → Container
Add an s suffix to your domain (like app-443s.phala.network) and the gateway routes without decryption. Your application handles TLS termination directly.

​
WireGuard with Mutual Attestation

WireGuard tunnels between the gateway and your CVM are only established after mutual attestation:
  1. Attestation First: Both the gateway TEE and your CVM generate TDX attestation quotes
  2. Mutual Verification: Each side verifies the other’s attestation before proceeding
  3. Key Exchange: Only after successful attestation do they exchange WireGuard public keys
  4. Tunnel Creation: WireGuard establishes the encrypted tunnel using ChaCha20-Poly1305
  5. Continuous Encryption: All traffic flows through this attested tunnel, invisible to the host
This attestation requirement ensures you’re always connecting to genuine TEE instances, not imposters. Even after TLS termination at the gateway, your data remains encrypted until it reaches your container.

​
Zero-Trust HTTPS (zt-https)

​
How TEEs Control Certificates

Both Phala Cloud domains (via gateway) and custom domains (via dstack-ingress) implement Zero-Trust HTTPS. TEEs generate and control their own ACME accounts:
  1. TEE generates ECDSA keypair: The private key is created inside TDX-encrypted memory
  2. Registers with Let’s Encrypt: The TEE establishes its own ACME account
  3. Seals credentials to hardware: Keys are stored on encrypted disk, bound to TEE measurements
  4. Requests certificates: Only this specific TEE instance can use these credentials
The private keys are stored on an encrypted disk that only the TEE can decrypt. Even with full host access, attackers can’t extract these credentials—the hardware prevents it.

​
Zero-Trust Certificate Architecture

We implement Zero-Trust HTTPS through three essential mechanisms: CAA DNS Records: Lock your domain to a specific ACME account 
your-domain.com CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/YOUR_TEE"
This prevents anyone else—even with domain control—from getting valid certificates. Certificate Transparency Monitoring: Every certificate issuance gets logged publicly. Monitor these logs to detect any unauthorized certificates immediately. Cryptographic Evidence: Custom domains publish proof at /evidences/ containing:
  • TDX attestation quote proving hardware backing
  • SHA256 hash linking the certificate to the ACME account
  • The actual certificate and account details
This creates an auditable chain: the hardware signs the evidence, the evidence contains the certificate, and the certificate serves your traffic. Any tampering breaks the cryptographic chain.

​
Preventing Timeline Attacks

CAA records only protect future certificate issuance. Existing certificates remain valid until expiration. To ensure complete security:
  1. Check historical certificates: Review all certificates ever issued for your domain
  2. Verify expiration: Ensure pre-deployment certificates have expired
  3. Revoke if necessary: Contact the CA to revoke any unexpired legacy certificates
This prevents attackers from using certificates obtained before your TEE deployment.

​
Compliance and Standards

Phala Cloud’s architecture aligns with major regulatory requirements through hardware-enforced security. The platform provides GDPR Article 32 compliance with state-of-the-art encryption (TLS 1.3, WireGuard, TDX), pseudonymization through CVM isolation, and continuous confidentiality. For HIPAA, we deliver hardware-enforced access controls, attestation-based audit trails, and mandatory end-to-end encryption. PCI DSS requirements are met through hardware network segmentation, FIPS-approved cryptography, and hardware-sealed key management. Remember: infrastructure security doesn’t replace application security. You remain responsible for secure coding practices, authentication, and application-layer compliance requirements.

​
Advanced Deployment Patterns

​
Cross-Region Architecture

Running globally distributed CVMs? Traffic flows like this: 
CVM_US → WireGuard → Gateway_US → Internet → Gateway_EU → WireGuard → CVM_EU
Expect ~100ms latency per ocean crossing. Data transfer costs apply. Consider regulatory requirements for data movement.

​
Maximum Privacy with Tor

Need network-layer anonymity? Deploy Tor inside your CVM: 
services:
  tor:
    image: torproject/tor
    volumes:
      - ./torrc:/etc/tor/torrc
  app:
    network_mode: "service:tor"
Users connect via .onion addresses. Traffic correlation becomes nearly impossible. TEE attestation still works.

​
TLS Passthrough Applications

For services requiring unmodified TLS: 
{
  host: 'app-443s.phala.network',  // Note the 's' suffix
  port: 443
}
The s suffix enables passthrough mode. Common uses include gRPC services, custom protocols, and applications with client certificate authentication.

​
Security Boundaries

​
What TEE Hardware Guarantees

Memory encryption. Each CVM’s memory is encrypted with a unique key from the CPU. The host OS doesn’t have this key. Attestation. You can cryptographically verify what code is running. The hardware signs the measurements. Isolation. CVMs can’t access each other’s memory or networks. Hardware enforces these boundaries.

​
Scope Boundaries

Application layer. Your code’s security remains your responsibility. We secure the platform, not the application logic. Availability. We focus on confidentiality and integrity. Plan redundancy for high availability requirements.

​
Technical References