Privacy Infrastructure

Detailing Lambda's privacy-preserving technology stack.

Privacy Philosophy

Lambda's privacy infrastructure is built on three core principles:

Zero-Knowledge Operation: We can't see your data, even if we tried
Hardware-Backed Security: Trust the silicon, not the software
Cryptographically Verifiable: Don't trust, verify

Secure Enclave Technology

Intel SGX (Software Guard Extensions)

What Is SGX?

Intel SGX provides hardware-isolated memory regions called enclaves where code and data are protected from:

Operating system
Hypervisor
BIOS/firmware
Other applications
Even our infrastructure operators

How It Works:

┌────────────────────────────────────────────────┐
│                 Untrusted World                │
│          (OS, Drivers, Other Applications)     │
│                                                │
│  ┌──────────────────────────────────────────┐  │
│  │      Trusted Execution Environment       │  │
│  │                                          │  │
│  │  ┌────────────────────────────────────┐  │  │
│  │  │     SGX Enclave                    │  │  │
│  │  │                                    │  │  │
│  │  │  • Encrypted Memory                │  │  │
│  │  │  • Sealed Storage                  │  │  │
│  │  │  • Your Application Code           │  │  │
│  │  │  • Your Data                       │  │  │
│  │  │                                    │  │  │
│  │  │  Protected by CPU                  │  │  │
│  │  └────────────────────────────────────┘  │  │
│  │                                          │  │
│  └──────────────────────────────────────────┘  │
│                                                │
└────────────────────────────────────────────────┘

SGX Features at Lambda:

Enclave Size: Up to 128GB of protected memory
Remote Attestation: Cryptographically prove your code is running in SGX
Sealing: Persist encrypted data tied to enclave identity
Measured Boot: Verify enclave code hasn't been tampered with

Attestation Example:

# Request attestation from your instance
lambda attest inst_abc123 --output attestation.json

# Verify locally
lambda verify attestation.json

Attestation Output:

{
  "enclave_id": "3f4a8b...",
  "measurement": "sha256:9f86d0...",
  "signature": "304502210...",
  "timestamp": "2026-01-24T10:30:00Z",
  "platform": "Intel SGX",
  "verified": true
}

AMD SEV (Secure Encrypted Virtualization)

What Is SEV?

AMD SEV encrypts the entire virtual machine memory, protecting it from the hypervisor and host OS.

SEV Architecture:

graph TB
    subgraph "Host (Untrusted)"
        H[Hypervisor]
        M[Management Tools]
    end

    subgraph "Guest VM (Encrypted)"
        K[Guest Kernel]
        A[Applications]
        D[Data]
    end

    subgraph "AMD SEV Hardware"
        AES[AES Engine]
        KM[Key Manager]
        MEM[Memory Controller]
    end

    %% Logic Connections
    A --> K
    D --> K
    K -.->|Encrypted| AES
    AES --> KM
    KM --> MEM
    MEM -.->|Ciphertext Only| H
    H --X|Cannot Decrypt| A
    H --X|Cannot Decrypt| D

    %% Styling (Ensure there is a blank line above this)
    style AES fill:#f99,stroke:#333,stroke-width:3px
    style KM fill:#f99,stroke:#333,stroke-width:3px

'

SEV Features:

Full Memory Encryption: Every byte in RAM is encrypted
Transparent to Guest: No modifications to guest OS needed
Key Isolation: Each VM has unique encryption key
DMA Protection: Direct memory access is encrypted

SEV-ES (Encrypted State):

Extends SEV to encrypt CPU register state:

Protects against register inspection attacks
Encrypts context during VM exits
Prevents hypervisor from stealing passwords in registers

SEV-SNP (Secure Nested Paging):

Latest generation with memory integrity:

Prevents replay attacks
Detects memory remapping attacks
Cryptographic integrity checks

ARM TrustZone

What Is TrustZone?

ARM TrustZone partitions the system into:

Secure World: Trusted execution environment
Normal World: Regular applications and OS

TrustZone Architecture:

┌─────────────────────────────────────┐
│         Normal World                │
│  (Linux, Applications, Services)    │
│                                     │
│  Cannot access Secure World         │
└─────────────────────────────────────┘
           ↕ Secure Monitor
┌─────────────────────────────────────┐
│         Secure World                │
│  (Trusted OS, Crypto, Keys)         │
│                                     │
│  Full access to Normal World        │
│  Normal World has NO access here    │
└─────────────────────────────────────┘

Encryption Stack

Lambda implements multi-layer encryption to ensure data privacy at all stages.

Layer 1: Data at Rest

Storage Encryption:

┌─────────────────────────────────────────────┐
│  Your Application                           │
└───────────────────┬─────────────────────────┘
                    │      read/write
                    ▼
┌─────────────────────────────────────────────┐
│  Filesystem (ext4, xfs, etc.)               │
└───────────────────┬─────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────┐
│  dm-crypt / LUKS                            │
│  (Your Key: AES-256-XTS)                    │
└───────────────────┬─────────────────────────┘
                    │  encrypted blocks
                    ▼
┌─────────────────────────────────────────────┐
│  NVMe SSD                                   │
│  (Hardware Encryption: AES-256-GCM)         │
└─────────────────────────────────────────────┘

Encryption Algorithms:

Block Level: AES-256-XTS (disk encryption)
File Level: AES-256-GCM (file encryption)
Hardware Level: AES-256-GCM (SSD controller)

Key Management:

Customer-managed keys (BYOK)
Keys never stored on Lambda infrastructure
Automatic key rotation (optional)
Key derivation using HKDF-SHA256

Layer 2: Data in Transit

Network Encryption:

Your Application
      ↓ TLS 1.3
Load Balancer
      ↓ WireGuard/IPsec
Firewall
      ↓ Encrypted Tunnel
Your Instance

Protocols:

External Traffic: TLS 1.3 with perfect forward secrecy
Internal Traffic: WireGuard or IPsec
Instance-to-Instance: Private encrypted tunnels

Cipher Suites:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
No support for weak ciphers (CBC, RC4, etc.)

Layer 3: Data in Use (Memory)

Memory Encryption:

Using SEV or SGX, memory is encrypted while being actively used:

CPU ──────┬──────► Memory (Encrypted)
          │             ↓
          │        Memory Controller
          │             ↓
          │        Encryption Engine
          │             ↓
          └────────► DRAM (Ciphertext)

Benefits:

Protects against cold-boot attacks
Prevents memory scraping
Isolates VM memory from hypervisor
Protects during live migration

Layer 4: Runtime Protection

Process Isolation:

# Each instance runs in isolated namespace
unshare --net --mount --uts --ipc --pid

# SELinux/AppArmor policies
# No cross-instance access
# Encrypted /tmp and swap

Key Management Architecture

Customer-Controlled Keys

Lambda uses a Bring Your Own Key (BYOK) model:

graph TB
    A[Customer] -->|Generates| B[Master Key]
    B -->|Stored Locally| C[Customer Key Store]
    B -->|Derives| D[Data Encryption Keys]
    D -->|Encrypts| E[Volume/Data]

    F[Lambda Platform] -.->|Never Accesses| B
    F -.->|Never Stores| B
    F -.->|Cannot Decrypt| E

    style B fill:#9f9,stroke:#333,stroke-width:3px
    style C fill:#9f9,stroke:#333,stroke-width:3px
    style F fill:#f99,stroke:#333,stroke-dash:5

Key Hierarchy

Customer Master Key (CMK)
  ↓ HKDF-SHA256
Region Key Encryption Key (KEK)
  ↓ HKDF-SHA256
Instance Key Encryption Key (KEK)
  ↓ Wrap
Data Encryption Key (DEK) for Each Volume

Key Operations

Key Generation:

# Generate master key
lambda key generate --name my-master-key --output key.pem

# Store securely (NOT on Lambda)
mv key.pem ~/secure-location/

# Use key for instance creation
lambda create instance \
  --encryption-key ~/secure-location/key.pem

Key Rotation:

# Generate new key
lambda key generate --name my-master-key-v2

# Migrate instance to new key
lambda key rotate inst_abc123 \
  --old-key ~/keys/v1.pem \
  --new-key ~/keys/v2.pem

How Lambda manages your infrastructure without seeing inside.

Metadata vs. Data

What Lambda Sees (Metadata):

Instance ID: inst_abc123
Instance type: compute-4x
Region: us-west-1
Status: running
Resource usage: CPU %, Memory %, Network bytes

What Lambda DOESN'T See (Data):

Application logs
Environment variables
File contents
Process list
Command arguments
Network packet payloads

Orchestration Flow

Metrics We Collect:

{
  "instance_id": "inst_abc123",
  "timestamp": "2026-01-24T10:30:00Z",
  "metrics": {
    "cpu_percent": 45.2,
    "memory_bytes": 2147483648,
    "network_in_bytes": 1024000,
    "network_out_bytes": 512000,
    "disk_read_bytes": 204800,
    "disk_write_bytes": 102400
  }
}

What's NOT in Metrics:

Process names
Open files
Network connections (IPs, ports)
Log entries
User activity

Network Privacy

Packet-Level Privacy

Traffic Flow:

Your App → Encrypted Packet → Lambda Network → Encrypted Packet → Destination
                ↑                                      ↑
           Lambda cannot inspect              Lambda cannot inspect

Network Isolation:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Instance A  │     │  Instance B  │     │  Instance C  │
│  Customer 1  │     │  Customer 2  │     │  Customer 1  │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                    │                    │
       └────────────────────┼────────────────────┘
                            │
                     No cross-talk
          (unless explicitly configured)

VPN Support

Private Networking:

# Create private VPN
lambda vpn create \
  --name corporate-vpn \
  --cidr 10.0.0.0/16

# Connect instance to VPN
lambda vpn connect inst_abc123 --vpn vpn_xyz789

# All traffic encrypted end-to-end

Audit & Compliance

What Gets Audited

Control Plane Audit Log:

{
  "event_id": "evt_123",
  "timestamp": "2026-01-24T10:30:00Z",
  "event_type": "instance.created",
  "actor": "user_xyz",
  "resource": "inst_abc123",
  "action": "create",
  "metadata": {
    "instance_type": "compute-4x",
    "region": "us-west-1"
  }
}

What's NOT Audited:

Application-level events
User data access
File operations
Process execution

Compliance Certifications

Lambda maintains compliance with:

✓ SOC 2 Type II: Annual audits
✓ ISO 27001: Information security management
✓ HIPAA: Healthcare data
✓ GDPR: EU data protection
✓ PCI DSS: Payment card data
✓ FedRAMP: U.S. government (in progress)

See Compliance Documentation →

Threat Model

What Lambda Protects Against

Threat	Protection
Insider Threat	✓ Zero-knowledge architecture
Provider Breach	✓ Encrypted data, no keys on platform
Memory Scraping	✓ Hardware memory encryption
Cold Boot Attack	✓ SEV/SGX protections
Hypervisor Compromise	✓ Hardware-backed isolation
Network Sniffing	✓ End-to-end encryption
Storage Theft	✓ Encrypted volumes with customer keys
Legal Subpoena	✓ No plaintext data to surrender

What Users Must Protect

Responsibility	User Action
Encryption Keys	Store securely, use key management
SSH Keys	Protect private keys, rotate regularly
Application Security	Patch vulnerabilities, secure code
Access Control	Strong passwords, MFA
Backup Keys	Secure backup of encryption keys

Verification & Attestation

Verify Your Instance

Remote Attestation Process:

Request Attestation:

lambda attest inst_abc123

Receive Proof:

{
  "quote": "base64_encoded_quote",
  "signature": "base64_signature",
  "certificate_chain": ["cert1", "cert2"],
  "platform_info": {
    "cpu": "Intel Xeon Gold",
    "sgx_version": "2.0",
    "microcode": "0x123"
  }
}

Verify Locally:

lambda verify attestation.json --verify-with intel-pcs

Confirm Security:

✓ Signature valid
✓ CPU is genuine Intel with SGX
✓ Microcode is up-to-date
✓ Enclave measurement matches expected
✓ No debug mode enabled

Continuous Verification

# Set up monitoring attestation
lambda attest inst_abc123 --monitor --alert-on-failure

Next Step

Learn how to manage your compute instances.

Compute Instances Guide →

Think Lambda, Think Privacy