Attestation

Attestation is the process of cryptographically proving that your workload is running in a genuine Trusted Execution Environment (TEE) and hasn’t been tampered with.

What is Attestation?

Attestation provides verifiable evidence that:

  • Your VM is running on genuine AMD SEV-SNP hardware
  • The VM firmware and software match expected measurements
  • The VM configuration is correct
  • No unauthorized modifications have been made

How Attestation Works

1. Launch Measurement

When a TEE VM launches, the AMD Secure Processor calculates a cryptographic hash of:

  • VM firmware (OVMF/UEFI)
  • Kernel and initial ramdisk
  • VM policy settings
  • Initial memory contents

This hash is called the launch measurement.

2. Attestation Report

The AMD Secure Processor generates a signed attestation report containing:

  • MEASUREMENT - Launch measurement hash
  • GUEST_SVN - Guest security version number
  • POLICY - VM policy flags
  • FAMILY_ID - VM family identifier
  • IMAGE_ID - VM image identifier
  • VMPL - VM privilege level
  • SIGNATURE - AMD’s cryptographic signature

3. Verification

Anyone can verify the attestation report by:

  1. Obtaining the report from the VM
  2. Verifying AMD’s signature using AMD’s public key
  3. Checking the measurement matches expected values
  4. Validating firmware versions and policy settings

Getting an Attestation Report

Retrieve an attestation report using the CLI:

teenode vm attest vm_xyz789

Or via the API:

curl https://api.teenode.com/v1/vms/vm_xyz789/attestation \
  -H "Authorization: Bearer YOUR_API_KEY"

Example response:

{
  "report": "AQAAAAEAAwAA...",
  "measurement": "a1b2c3d4e5f6789012345678901234567890",
  "verified": true,
  "platform": {
    "vendor": "AMD",
    "model": "EPYC 7003",
    "firmware_version": "1.51.03"
  },
  "policy": {
    "abi_major": 1,
    "abi_minor": 51,
    "smt_allowed": false,
    "migration_agent_allowed": false,
    "debug_allowed": false
  },
  "timestamp": "2024-01-15T14:30:00Z"
}

Verifying Attestation

Manual verification steps:

# 1. Get the attestation report
teenode vm attest vm_xyz789 --output report.bin

# 2. Get AMD’s certificate chain
curl -o vcek.pem https://kdsintf.amd.com/vcek/v1/Milan/...

# 3. Verify the signature
teenode attest verify \
  --report report.bin \
  --cert vcek.pem \
  --expected-measurement a1b2c3d4...

What to Verify

Critical Checks

  • Signature - Report is signed by genuine AMD hardware
  • Measurement - Matches your expected VM configuration
  • Policy - Debug disabled, SMT disabled for maximum security
  • Firmware Version - Recent and without known vulnerabilities

Policy Flags

Important policy settings to check:

{
  "debug_allowed": false,        // Should be false in production
  "migration_agent_allowed": false,  // Disable unless needed
  "smt_allowed": false,          // Disable for maximum security
  "abi_major": 1,               // SEV-SNP protocol version
  "abi_minor": 51               // Firmware version
}
If debug_allowed is true, the VM memory can be accessed by the hypervisor. This should only be enabled during development.

Remote Attestation

Remote attestation allows external parties to verify your VM. Use cases include:

  • Proving to users their data is processed securely
  • Multi-party computation verification
  • Regulatory compliance auditing
  • Blockchain validator verification

Remote attestation workflow:

# 1. Requestor sends a nonce (random challenge)
curl -X POST https://your-vm.teenode.app/attest \
  -d '{"nonce": "abc123..."}'

# 2. VM generates attestation report with nonce
# 3. VM returns signed report
# 4. Requestor verifies report and nonce

Continuous Attestation

For high-security applications, implement continuous attestation:

# Set up automated attestation checks
teenode vm attest vm_xyz789 \
  --continuous \
  --interval 5m \
  --webhook https://your-app.com/attest-check
Continuous attestation helps detect runtime attacks or VM compromise.

Attestation Failure Scenarios

Attestation may fail if:

  • VM firmware was modified
  • Debug mode was enabled
  • Memory was tampered with
  • Firmware has known vulnerabilities
  • Hardware doesn’t support SEV-SNP

Best Practices

  • Verify attestation before sending sensitive data to a VM
  • Store expected measurements in a secure location
  • Automate attestation verification in CI/CD pipelines
  • Monitor firmware versions for security updates
  • Use nonces to prevent replay attacks
  • Implement continuous attestation for critical workloads

Learn More

    Attestation - Teenode Documentation