Skip to main content

Public Cloud Attestation

Introduction​

Ensuring system integrity and security is critical in modern computing environments, especially with the rise of confidential computing. Remote attestation is a key component of this security model, allowing one party to verify the integrity of another system before sharing sensitive information. This document provides a comprehensive technical overview of attestation in public cloud environments, specifically focusing on Microsoft Azure and Google Cloud Platform.

Cocos provides attestation capabilities for Confidential Virtual Machines (CVMs) running on Microsoft Azure and Google Cloud Platform. The attestation framework establishes cryptographic proof of system integrity through hardware-backed Trusted Execution Environments (TEE) and Virtual Trusted Platform Modules (vTPM).

Attestation is a process in which one system (the attester) gathers information about itself and sends it to a relying party (or client) for verification. Successful verification ensures that the Confidential Virtual Machine (CVM) is running the expected code on trusted hardware with the correct configuration. If deemed trustworthy, the relying party can securely send confidential code or data to the attester.

Cocos implements the Background-Check model of remote attestation. In this model, the attester sends evidence to the relying party, who forwards it to the verifier for appraisal. The verifier then sends the attestation results to the relying party, who makes the final decision about trusting the attester based on the comparison of its own appraisal policy against the attestation result. For more detailed information about this model and remote attestation architectures, see RFC 9334 - Remote ATtestation procedureS (RATS) Architecture.

Trusted Computing Base (TCB)​

TCB

Definition and Scope​

The Trusted Computing Base (TCB) represents the complete set of hardware, firmware, and software components that are critical to the security of a computing system. The TCB establishes the root of trust from which all security properties of the system are derived. In the context of confidential computing and cloud attestation, the TCB includes multiple layers that must be verified to ensure system integrity.

TCB Components Hierarchy​

The TCB forms a hierarchical chain of trust, where each layer depends on the integrity of the layers below it:

1. Hardware Root of Trust (Layer 0)​

The foundational layer of the TCB, consisting of:

AMD SEV-SNP Processor:

  • Secure Encrypted Virtualization with Secure Nested Paging
  • Hardware-enforced memory encryption and isolation
  • Platform Security Processor (PSP) for secure operations
  • Cryptographic identity keys burned into silicon

Hardware Security Module (HSM):

  • Dedicated cryptographic processing unit
  • Tamper-resistant hardware for key storage
  • Hardware-based random number generation
  • Secure key derivation and attestation signing

CPU Microcode and Firmware:

  • Low-level processor instructions and behavior
  • Security patches and vulnerability mitigations
  • Platform-specific security features
  • Hardware feature enablement and configuration

2. Firmware Layer - Static Root of Trust for Measurement (SRTM)​

The firmware layer serves as the SRTM, responsible for:

UEFI/OVMF Firmware:

  • Unified Extensible Firmware Interface implementation
  • Open Virtual Machine Firmware for virtualized environments
  • Platform initialization and hardware discovery
  • Secure boot chain establishment

Secure Boot Chain:

  • Cryptographic verification of boot components
  • Certificate chain validation
  • Signature verification of boot loaders and OS kernels
  • Prevention of unauthorized code execution

PCR 0-7 Measurements:

  • Core Root of Trust for Measurement (CRTM)
  • UEFI firmware measurements
  • Boot configuration and variables
  • Platform configuration and setup

3. Virtualization Layer​

Virtual TPM (vTPM):

  • Software-based TPM functionality
  • PCR extend operations for boot measurements
  • Attestation Key (AK) generation and management
  • Secure storage of cryptographic artifacts

SEV-SNP Attestation:

  • Guest memory measurement and validation
  • Platform configuration measurements
  • Security version number tracking
  • Launch measurement verification

4. Operating System Layer​

Linux Integrity Measurement Architecture (IMA):

  • File system integrity measurements (PCR 10)
  • Runtime file access monitoring
  • Executable and library verification
  • Configuration file integrity

Kernel and Initramfs Integrity:

  • Kernel image measurement and verification
  • Initial RAM filesystem validation
  • Kernel module loading verification
  • System call table integrity

Event Log Maintenance

  • TPM event log handover from UEFI firmware
  • Continuous event log extension during runtime
  • Event log integrity and tamper detection
  • Integration with measurement subsystems

TCB Verification Models​

Direct Verification Model (GCP)​

Google Cloud Platform implements a direct verification approach where:

  • Golden Measurements: Reference values stored in GCP's TCB Integrity Bucket
  • Independent Verification: Clients can verify measurements without relying on centralized services
  • Launch Endorsements: Cryptographically signed endorsements for valid configurations
  • Policy Enforcement: Client-side policy validation against known good states

Verification Process:

  1. Retrieve golden measurements from gce_tcb_integrity bucket
  2. Compare attestation evidence against reference values
  3. Validate launch endorsements and signatures
  4. Enforce custom policies based on measurement comparison

Centralized Verification Model (Azure)​

Microsoft Azure uses a centralized attestation service approach:

  • Microsoft Azure Attestation (MAA): Centralized verification service
  • Signed JWT Tokens: Attestation results in standardized token format
  • Trust Service Provider: Azure acts as the trusted third party
  • Simplified Client Logic: Reduced complexity for attestation consumers

Verification Process:

  1. Submit attestation evidence to MAA service
  2. MAA validates against Azure's known configurations
  3. Receive signed JWT token with security claims
  4. Validate token signature using MAA public keys

TCB Security Properties​

  • Immutability

    • PCR values cannot be directly overwritten, only extended
    • Firmware measurements are cryptographically bound to hardware
    • Boot sequence modifications are detectable through PCR changes

  • Authenticity

    • Hardware-rooted cryptographic signatures
    • Certificate chains anchored in hardware identity
    • Tamper-evident measurement logs

  • Freshness

    • Nonce-based replay attack prevention
    • Timestamp validation in attestation reports
    • Event sequence verification

  • Completeness

    • Comprehensive measurement of all TCB components
    • Coverage of both static and dynamic system elements
    • Verification of configuration and runtime state

Attestation Architecture Overview​

Attestation Components​

The Cocos attestation system consists of two primary attestation sources:

TEE Attestation (SEV-SNP)​

Hardware-generated attestation reports from AMD SEV-SNP processors containing:

  • Platform measurements: Cryptographic hashes of platform state
  • Security version numbers: TCB component version tracking
  • Policy validation: Hardware-enforced security policies
  • Guest isolation proof: Cryptographic evidence of memory protection

The SEV-SNP attestation report is a binary structure containing fields such as:

  • Version, Guest SVN, Policy
  • Family ID, Image ID, Measurement (hash of initial guest memory)
  • Host data, ID block data, Author key digest
  • Signature and certificate chain

vTPM Attestation​

Virtual Trusted Platform Module quotes containing:

  • Boot measurements: PCR values from the boot sequence
  • Software component integrity: Hash measurements of loaded components
  • Configuration state: System configuration and policy settings
  • Event logs: Detailed record of all measured events

A TPM is a dedicated security chip designed to perform tamper-resistant cryptographic functions. It securely manages sensitive artifacts such as encryption keys, certificates, and integrity measurements. In scenarios where TPM functionality is implemented via software instead of hardware, it is referred to as a virtual TPM (vTPM).

Verification Flow​

CVM Instance → Generate Attestation → Platform Service → Verify Claims → Policy Enforcement

Both platforms follow this flow but implement different verification mechanisms and trust models.

Platform-Specific Implementations​

Microsoft Azure Implementation​

Azure Attestation Service Integration​

Azure uses the Microsoft Azure Attestation (MAA) service as a centralized attestation verifier. The MAA service validates attestation reports and issues signed JWT tokens containing security claims.

Azure Attestation Process​

  1. Evidence Generation:

    • The CVM generates a combined SEV-SNP attestation report and a vTPM quote
    • The SEV-SNP report is obtained by interacting with the underlying hardware and kept inside vTPM Non-Nolatile (NV) memory
    • The vTPM quote is fetched from the virtual TPM

  2. Service Submission:

    • Combined report parameters are generated for the MAA service
    • The report is submitted to a MAA service endpoint (e.g., sharedeus2.eus2.attest.azure.net)
    • MAA validates the report against Azure's known configurations

  3. Token Verification:

    • MAA returns a signed JWT token containing security claims
    • Token validation involves retrieving the MAA public key set
    • Signature verification ensures token authenticity and integrity

Azure Token Claims Structure​

The MAA token contains security-relevant claims within the x-ms-isolation-tee namespace:

Hardware Identity Claims:

  • x-ms-sevsnpvm-familyId: Processor family cryptographic identifier
  • x-ms-sevsnpvm-imageId: VM image configuration identifier
  • x-ms-sevsnpvm-launchmeasurement: Initial guest state cryptographic hash

Security Version Claims:

  • x-ms-sevsnpvm-bootloader-svn: Boot loader security version
  • x-ms-sevsnpvm-tee-svn: TEE security version
  • x-ms-sevsnpvm-snpfw-svn: SNP firmware security version
  • x-ms-sevsnpvm-microcode-svn: Microcode security version

Runtime Security Claims:

  • x-ms-sevsnpvm-guestsvn: Guest OS security version number
  • x-ms-sevsnpvm-idkeydigest: Identity key cryptographic hash
  • x-ms-sevsnpvm-reportid: Attestation report unique identifier

Google Cloud Platform Implementation​

GCP Direct Verification Model​

GCP provides direct access to golden measurements and launch endorsements, enabling independent verification without relying on a centralized attestation service.

GCP Attestation Process​

  1. Evidence Generation:

    • The CVM generates a SEV-SNP attestation report and a vTPM quote
    • Both teeNonce and vTpmNonce are provided to ensure freshness
    • vTPM quote is fetched by opening a connection to the TPM device (/dev/tpmrm0 or /dev/tpm0)
    • TPM attestation key is used to retrieve the quote, including PCR values and event log
    • The SEV-SNP report is fetched directly from the guest environment

  2. Event Log Processing:

    • Event log is read from /sys/kernel/security/tpm0/binary_bios_measurements
    • Combined attestation is marshaled for transmission

  3. Verification Process:

    • vTPM quote's signature is verified using the Attestation Key (AK) public key
    • PCR values within the quote are checked against expected golden values
    • Event log is replayed to ensure consistency with PCR values
    • SEV-SNP attestation report is verified against policy parameters

GCP Storage Integration​

GCP utilizes a TCB Integrity Bucket (gce_tcb_integrity) for storing:

Launch Endorsements:

  • Path: ovmf_x64_csm/sevsnp/{measurement}.binarypb
  • Contains golden measurements for different vCPU configurations
  • Includes SEV-SNP policy values and UEFI measurement data
  • Serialized as protocol buffer format for structured access

OVMF Files:

  • Path: ovmf_x64_csm/{digest}.fd
  • Firmware binary images for verification
  • Cryptographic hashes for integrity validation

TPM and PCR Deep Dive​

Trusted Platform Module (TPM) Architecture​

A TPM is a dedicated security chip that performs tamper-resistant cryptographic functions. Key components include:

Cryptographic Engine​

  • RSA and ECC key generation and operations
  • SHA-1, SHA-256, SHA-384, SHA-512 hash algorithms
  • HMAC and symmetric encryption capabilities
  • Hardware-based random number generation

Secure Storage​

  • Non-volatile memory for keys and certificates
  • Monotonic counters for replay protection
  • Authorization policies and access controls
  • Sealed storage with PCR binding

Platform Configuration Registers (PCRs)​

A Platform Configuration Register (PCR) is a secure memory region within the TPM that records system integrity measurements. Instead of being overwritten, PCR values are extended through a cryptographic hash function:

PCR[N] = HASH_alg(PCR[N] || NewMeasurement)

This ensures that all recorded values remain linked and verifiable, making PCRs essential for attestation and system security.

PCR Usage and Allocation​

A typical TPM has 24 PCRs (0-23). The specific content verified in each PCR depends on the platform and implementation:

Static PCRs (0-7) - SRTM Measurements​

  • PCR 0: Core Root of Trust for Measurement (CRTM) and UEFI firmware
  • PCR 1: Platform and motherboard configuration
  • PCR 2: UEFI driver and ROM code
  • PCR 3: UEFI driver and ROM code configuration
  • PCR 4: UEFI Boot Manager code
  • PCR 5: UEFI Boot Manager configuration and GPT table
  • PCR 6: Host platform manufacturer control
  • PCR 7: Secure Boot state and certificates

Dynamic PCRs (8-15) - OS and Application Measurements​

  • PCR 8: Boot loader (GRUB, systemd-boot)
  • PCR 9: Kernel and initramfs
  • PCR 10: Linux IMA measurements
  • PCR 11: BitLocker access control
  • PCR 12: Boot events and configuration
  • PCR 13: Module signature verification
  • PCR 14: MokList (Machine Owner Keys)
  • PCR 15: System firmware updates

Debug and Locality PCRs (16-23)​

  • PCR 16: Debug and development use
  • PCR 17-22: Dynamic Root of Trust for Measurement (DRTM)
  • PCR 23: Application-specific measurements

Trusted Boot and Integrity Measurement​

System integrity is ensured by measuring and recording each boot component into the TPM:

Static Root of Trust for Measurement (SRTM)​

The firmware acts as the SRTM, responsible for:

  • Measuring critical boot components
  • Storing component hashes in TPM PCRs
  • Establishing the initial trust anchor
  • Enabling secure boot chain verification

Measurement Chain​

  1. Power-on Reset: TPM PCRs are reset to known initial values
  2. Firmware Measurement: CRTM measures UEFI firmware into PCR 0
  3. Boot Component Measurement: Each component measures the next before execution
  4. OS Loader Measurement: Boot loader measures kernel and initramfs
  5. Runtime Measurement: IMA measures files and executables during runtime

Linux IMA (Integrity Measurement Architecture)​

Linux Integrity Measurement Architecture (IMA) is a Linux kernel feature that provides a mechanism to record and verify the integrity of files and other system objects at load or access time.

IMA Components​

Measurement: IMA computes cryptographic hashes of files and maintains a log of these measurements in the kernel's measurement list.

Appraisal: IMA can optionally enforce appraisal policies, requiring files to have valid signatures or hashes before access is granted.

Audit: IMA can generate audit records for file access and integrity violations.

Integration with Cocos​

CocosAI uses IMA to ensure comprehensive file system integrity:

  1. Measurement Collection: Every file on the filesystem is measured during access
  2. Local Verification: An in-VM agent fetches the current IMA measurement log
  3. PCR Integration: CLI tool combines IMA data with TPM PCR 10 values
  4. User-Space Verification: Verification performed outside the kernel for flexibility
  5. Tamper Detection: IMA's tamper-evident logs provide post-boot integrity checking

This design avoids boot failures on images without built-in measurements while still leveraging IMA's comprehensive integrity monitoring capabilities.

Security Considerations​

Threat Model​

The attestation system is designed to protect against:

Malicious Hypervisor​

  • Memory access and modification attempts
  • VM state manipulation
  • Firmware replacement or modification
  • Boot sequence tampering

Compromised Guest OS​

  • Kernel modification and rootkits
  • System call interception
  • File system tampering
  • Configuration manipulation

Supply Chain Attacks​

  • Firmware backdoors
  • Compromised boot components
  • Malicious kernel modules
  • Signed but malicious software

Replay Attacks​

  • Stale attestation evidence
  • Cached measurement reuse
  • Time-of-check vs time-of-use vulnerabilities

Security Properties​

Confidentiality​

  • Memory encryption prevents unauthorized access
  • Key derivation tied to platform state
  • Sealed storage protects sensitive data

Integrity​

  • Cryptographic measurement of all components
  • Tamper-evident logging
  • Hardware-rooted trust anchor

Authenticity​

  • Hardware-based signatures
  • Certificate chain validation
  • Platform identity verification

Freshness​

  • Nonce-based replay protection
  • Timestamp validation
  • Monotonic counter usage

Best Practices​

Policy Design​

  • Define minimum acceptable TCB versions
  • Specify required measurement values
  • Implement graduated trust levels
  • Regular policy updates and reviews

Key Management​

  • Secure key generation and storage
  • Regular key rotation procedures
  • Hardware-backed key protection
  • Proper key lifecycle management

Monitoring and Alerting​

  • Continuous attestation monitoring
  • Anomaly detection and response
  • Security event logging
  • Incident response procedures

Error Handling and Debugging​

Common Verification Failures​

  • PCR Mismatch: Boot configuration changes or updates
  • Signature Verification: Certificate chain issues or key rotation
  • Version Downgrade: Older firmware or microcode versions
  • Policy Violation: Configuration outside acceptable parameters

Debugging Strategies​

  • Verbose Logging: Enable detailed measurement and verification logs CLI docs (-v flag)
  • Incremental Verification: Test individual components separately
  • Reference Comparison: Compare against known working configurations
  • Timeline Analysis: Examine boot sequence and timing

Performance Considerations​

Attestation Overhead​

  • Report Generation: depends on the platform
  • Network Transmission: Varies by report size and network conditions
  • Verification Processing: Varies depending on amount of verified values

This comprehensive guide provides the foundation for implementing robust attestation systems in public cloud environments, ensuring the security and integrity of confidential computing workloads.