Security Whitepaper

Architecture

The system consists of four components with distinct trust boundaries:

Key generation

User keys are generated entirely on the client device during account creation. The private key never leaves the device.

Key hierarchy

User Device
├── WebAuthn Credential (ECDSA P-256)
│   └── PRF Extension → Master Secret
│       └── HKDF-SHA256 → KEK (Key Encryption Key)
│           └── Encrypts → RSA-4096 Private Key
│
└── RSA-4096 Key Pair
    ├── Public Key → Sent to Offload (for encrypting data to user)
    └── Private Key → Stored in macOS Keychain (encrypted by KEK)

Key storage

The user's RSA private key is protected by multiple layers:

1. User authenticates via Touch ID (biometric)
2. WebAuthn PRF extension derives a secret from the credential
3. HKDF-SHA256 derives a Key Encryption Key (KEK) from the PRF output
4. KEK decrypts the RSA private key stored in macOS Keychain

The PRF secret is bound to the device's Secure Enclave. It cannot be extracted or used without biometric authentication on the specific device.

Encryption flow

Data encryption uses a two-layer scheme: symmetric encryption for performance, asymmetric encryption for key exchange.

Outbound (User → CVM)

1. User device generates random DEK (Data Encryption Key)
   DEK = crypto.getRandomValues(32 bytes)

2. Encrypt payload with DEK
   ciphertext = AES-256-GCM(plaintext, DEK, random_iv)

3. Wrap DEK with CVM's public key
   wrapped_dek = RSA-OAEP-SHA256(DEK, cvm_public_key)

4. Send to Offload backend:
   { ciphertext, wrapped_dek, iv, auth_tag }

5. Offload forwards to CVM (cannot decrypt - no private key)

6. CVM unwraps DEK and decrypts:
   DEK = RSA-OAEP-SHA256-Decrypt(wrapped_dek, cvm_private_key)
   plaintext = AES-256-GCM-Decrypt(ciphertext, DEK, iv)

Inbound (CVM → User)

1. CVM generates random DEK for response

2. Encrypt response with DEK
   ciphertext = AES-256-GCM(response, DEK, random_iv)

3. Wrap DEK with User's public key
   wrapped_dek = RSA-OAEP-SHA256(DEK, user_public_key)

4. Return via Offload backend (cannot decrypt)

5. User device unwraps and decrypts:
   DEK = RSA-OAEP-SHA256-Decrypt(wrapped_dek, user_private_key)
   response = AES-256-GCM-Decrypt(ciphertext, DEK, iv)

The Offload backend only ever handles wrapped keys and encrypted blobs. It possesses neither the CVM's private key nor the user's private key.

Confidential computing

Processing occurs inside Azure Confidential VMs powered by AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging).

Hardware guarantees

• • Memory encryption: All VM memory is encrypted with AES-256. The key exists only in the CPU silicon and cannot be extracted.
• • Isolation: The hypervisor, host OS, and other VMs cannot read CVM memory.
• • Integrity: SEV-SNP prevents memory replay attacks and validates memory mappings.
• • Attestation: The CVM can cryptographically prove its configuration to remote parties.

What this prevents

• • Cloud provider employees accessing customer data
• • Physical access attacks (cold boot, bus probing)
• • Hypervisor-level attacks
• • Memory scraping by co-tenant VMs

Hardware attestation

Attestation proves that a CVM is genuine AMD hardware running expected code. This prevents Offload from substituting a fake "CVM" that could exfiltrate data.

Attestation chain

AMD Factory
│
├── Burns unique VCEK (Versioned Chip Endorsement Key) into silicon
│   - Cannot be extracted or modified
│   - Unique per chip
│
├── Signs intermediate certificate (ASK) with AMD Root Key (ARK)
│
└── Publishes ARK and ASK at developer.amd.com/sev/

CVM Boot
│
├── AMD chip measures boot sequence and loaded code
│   - Creates hash of exact software state
│
├── Chip signs attestation report with VCEK
│   - Report includes: code hash, VM configuration, platform info
│
└── Report can be verified against AMD's published certificates

Verification
│
├── Download AMD root certificates (public)
├── Verify attestation signature chains to AMD root
├── Verify code hash matches expected value
└── If valid → CVM is genuine and running expected code

Key release policy

The CVM's RSA private key is stored in Azure Key Vault with a Secure Key Release (SKR) policy. The key is only released to CVMs that pass attestation verification:

• • Valid AMD SEV-SNP attestation report
• • Code measurement matches expected hash
• • Platform meets security requirements

If Offload modifies the CVM code, the hash changes, attestation fails, and Key Vault refuses to release the private key. The modified CVM cannot decrypt any user data.

Data source security

Different data sources have different security properties based on their integration method:

Threat model

Threats mitigated

Trust assumptions

• • AMD hardware: We trust AMD's SEV-SNP implementation is correct and AMD has not retained chip keys
• • Cryptographic primitives: AES-256, RSA-4096, SHA-256 are secure against known attacks
• • User device: The user's device is not compromised at the time of key generation
• • WebAuthn: The device's Secure Enclave correctly implements WebAuthn PRF

Out of scope

• • Compromised user devices (malware with root access)
• • Side-channel attacks on AMD SEV-SNP
• • Denial of service attacks
• • Social engineering attacks on users

Algorithms & specifications

Cryptographic algorithms

Hardware specifications

• • CVM technology: AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging)
• • Cloud platform: Microsoft Azure DCasv5/ECasv5 series
• • Attestation service: Microsoft Azure Attestation (MAA)
• • Key management: Azure Key Vault with Secure Key Release

References

• • AMD SEV-SNP Documentation
• • Azure Confidential Computing
• • WebAuthn Level 3 Specification
• • NIST SP 800-38D (AES-GCM)