2025-11-18T12:28:13.304767

Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Rezabek, Mahhouk, Miller et al.
Confidential Virtual Machines (CVMs) protect data in use by running workloads inside hardware-isolated environments. In doing so, they also inherit the limitations of the underlying hardware. Trusted Execution Environments (TEEs), which enforce this isolation, explicitly exclude adversaries with physical access from their threat model. Commercial TEEs, e.g., Intel TDX, thus assume infrastructure providers do not physically exploit hardware and serve as safeguards instead. This creates a tension: tenants must trust provider integrity at the hardware layer, yet existing remote attestation offers no way to verify that CVMs actually run on physically trusted platforms, leaving today's CVM deployments unable to demonstrate that their guarantees align with the TEE vendor's threat model. We bridge this confidence gap with Data Center Execution Assurance (DCEA), a design generating "Proofs of Cloud". DCEA binds a CVM to its underlying platform using vTPM-anchored measurements, ensuring CVM launch evidence and TPM quotes refer to the same physical chassis. This takes advantage of the fact that data centers are often identifiable via TPMs. Our approach applies to CVMs accessing vTPMs and running on top of software stacks fully controlled by the cloud provider, as well as single-tenant bare-metal deployments with discrete TPMs. We trust providers for integrity (certificate issuance), but not for the confidentiality of CVM-visible state. DCEA enables remote verification of a CVM's platform origin and integrity, mitigating attacks like replay and attestation proxying. We include a candidate implementation on Google Cloud and Intel TDX that leverages Intel TXT for trusted launch. Our design refines CVMs' threat model and provides a practical path for deploying high-assurance, confidential workloads in minimally trusted environments.
academic

Prueba de Nube: Garantía de Ejecución en Centro de Datos para Máquinas Virtuales Confidenciales

Información Básica

  • ID del Artículo: 2510.12469
  • Título: Proof of Cloud: Data Center Execution Assurance for Confidential VMs
  • Autores: Filip Rezabek, Moe Mahhouk, Andrew Miller, Stefan Genchev, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach
  • Clasificación: cs.CR (Criptografía y Seguridad), cs.DC (Computación Distribuida, Paralela y en Clúster)
  • Fecha de Publicación: 14 de octubre de 2024 (preimpresión en arXiv)
  • Enlace del Artículo: https://arxiv.org/abs/2510.12469

Resumen

Las máquinas virtuales confidenciales (CVMs) protegen los datos en uso ejecutando cargas de trabajo en entornos de aislamiento de hardware. Sin embargo, también heredan las limitaciones del hardware subyacente. Los entornos de ejecución confiables (TEEs) refuerzan este aislamiento, pero su modelo de amenaza excluye explícitamente a los atacantes con acceso físico. Los TEEs comerciales (como Intel TDX) asumen que los proveedores de infraestructura no explotarán el hardware a nivel físico. Esto genera una contradicción: los inquilinos deben confiar en la integridad del proveedor a nivel de hardware, pero la atestación remota existente no puede verificar si una CVM se ejecuta realmente en una plataforma físicamente confiable. Este artículo propone el diseño de Garantía de Ejecución en Centro de Datos (DCEA), que genera "pruebas de nube" vinculando la CVM a su plataforma subyacente mediante mediciones ancladas en vTPM, asegurando que la evidencia de arranque de la CVM y la referencia del TPM apunten al mismo chasis físico.

Contexto de Investigación y Motivación

Definición del Problema

Las máquinas virtuales confidenciales (CVMs) actuales enfrentan un defecto de seguridad crítico: aunque los TEEs pueden probar "qué código se ejecuta", no pueden probar "dónde se ejecuta el código". Este punto ciego "agnóstico de ubicación" permite que operadores maliciosos ejecuten cargas de trabajo aparentemente confiables en hardware bajo su control, mientras generan pruebas válidas.

Importancia del Problema

  1. Defectos del Modelo de Amenaza: El modelo de amenaza de los TEEs comerciales (Intel TDX, AMD SEV-SNP) asume que los atacantes no pueden acceder físicamente a los servidores, pero no hay forma de verificar esta suposición
  2. Casos de Ataque Reales: Ataques recientes han explotado el acceso físico para extraer claves de atestación de Intel SGX
  3. Aplicaciones de Alto Riesgo: Campos sensibles como las finanzas descentralizadas (DeFi) dependen cada vez más de la protección de TEE para activos valiosos, pero los participantes no confían mutuamente

Limitaciones de Métodos Existentes

  • La atestación estándar de TEE solo verifica el modelo de CPU, microcódigo y estado de arranque, sin incluir evidencia de la ubicación de instalación del procesador
  • No puede detectar la migración de cargas de trabajo a entornos no controlados por operadores maliciosos
  • Carece de mecanismos criptográficos para verificar la ubicación del TEE

Contribuciones Principales

  1. Definición del Modelo de Amenaza DCEA: Aplicable a escenarios de CVM y máquinas desnudas, cubriendo diversas capacidades de atacantes
  2. Diseño de Arquitectura DCEA Práctica: Vinculación de pruebas de TD a mediciones a nivel de plataforma mediante vTPM
  3. Evaluación de Viabilidad y Seguridad del Método: Incluyendo implementación detallada del protocolo y medidas de mitigación de ataques
  4. Provisión de Implementación de Referencia: Implementación candidata en Google Cloud e Intel TDX, utilizando Intel TXT para arranque confiable

Explicación Detallada del Método

Definición de Tareas

DCEA tiene como objetivo proporcionar evidencia criptográfica a verificadores remotos, probando que las cargas de trabajo confidenciales no solo se ejecutan en estados de software y hardware verificados, sino también en entornos de infraestructura conocidos.

Diseño de Arquitectura Principal

Raíces de Confianza Duales

DCEA establece dos raíces de confianza paralelas:

  1. Raíz de Confianza de TEE: Proveniente de fabricantes de TEE como Intel
  2. Raíz de Confianza de Infraestructura: Proveniente del proveedor de nube, implementada mediante TPM/vTPM

Dos Escenarios de Implementación

Escenario Uno (S1): CVM Administrada

  • La CVM se ejecuta en un hipervisor administrado por el proveedor, equipado con vTPM
  • El proveedor de nube administra el SO del host y la infraestructura de vTPM
  • La vinculación se logra mediante verificación de consistencia entre referencias de vTPM y referencias de TD

Escenario Dos (S2): Implementación en Máquina Desnuda

  • Servidor de máquina desnuda de un solo inquilino con acceso directo a TPM discreto
  • La pila de software del host no es confiable, dependiendo solo de garantías de hardware
  • Utiliza Intel TXT para establecer una cadena de confianza desde TPM a CVM

Detalles de Implementación Técnica

Protocolo DCEA de Cuatro Pasos

  1. Establecimiento de Arranque Confiable y Raíz de Plataforma: Uso de Intel TXT para arranque seguro, midiendo elementos de arranque temprano en PCR 17-18
  2. Configuración y Sellado de Claves de Atestación: El TPM genera AK y sella el material de clave privada bajo la política de PCR 17-18
  3. Vinculación de Evidencia Dentro del Cliente: TD incrusta el hash de la clave pública de AK del vTPM en su informe de atestación
  4. Flujo de Trabajo de Evidencia Compuesta del Verificador: El verificador inicia un desafío basado en nonce, obteniendo informe de TD y referencia de TPM

Innovaciones Técnicas Clave

  • Verificación Cruzada PCR-RTMR: Detección de inconsistencias comparando valores de PCR del TPM y valores de RTMR del TD
  • Mecanismo de Sellado de Claves: Sellado de AK del vTPM a valores de PCR específicos, previniendo uso en entornos no coincidentes
  • Vinculación Transitiva: Creación de vinculación transitiva desde evidencia de TD a pila de host medida mediante hash de AK

Análisis de Seguridad

Modelo de Amenaza

  • Capacidades del Atacante: Control del SO del host, hipervisor y pila de virtualización; puede interceptar, retrasar, reproducir e inyectar mensajes
  • Limitaciones del Atacante: No puede realizar manipulación física; fabricantes de CPU y TPM son confiables; infraestructura del proveedor de nube es confiable

Vectores de Ataque y Mitigación

Tipo de AtaqueDescripción del AtaqueMecanismo de Mitigación
A1: Falsificación de Referencia/MediciónFalsificación de referencia de vTPM o inyección de valores falsos de PCR/RTMRTD firmado por QE + referencia de AK sellada
A2: Ataque de Retransmisión/ProxyRetransmisión de solicitudes de referencia a máquina honesta remotaNonce + hash de AK incrustado en TD + AK sellada
A3: Inconsistencia de MediciónValores de PCR no coinciden con TD-RTMRVerificador comprueba TD RTMR contra PCR 17-18
A4: Intercepción/Manipulación de CanalAtaque de intermediario en ruta de TD a vTPMVinculación de punto final mediante AK + verificación de firma
A5: Sustitución de Identidad y ClaveFalsificación de certificado EK de TPM o sustitución de AK esperadaOrigen de AK anclado en EK + AKpub esperada incrustada en TD
A6: Compromiso de Componente de Nivel PrivilegiadoEjecución de binario de vTPM malicioso modificadoMedición de vTPM/host a PCR 18

Configuración Experimental y Resultados

Plataforma de Implementación

  • Plataforma Objetivo: Intel TDX en Google Cloud Platform
  • Pila Técnica: Intel TXT, TPM 2.0, hipervisor QEMU
  • Entorno de Prueba: GCP en región de Canadá y hosts de OVH

Evaluación de Rendimiento

Pruebas de rendimiento de 500 operaciones consecutivas en TPM y vTPM:

Tipo de OperaciónTPM de HardwarevTPM
Generación de Referencia~0.55 segundos~0.30 segundos
Operación de Firma~0.40 segundos~0.15 segundos

Hallazgos Clave:

  • El TPM de hardware es aproximadamente un orden de magnitud más lento que el vTPM de software
  • El rendimiento de vTPM es más estable, con mayor variabilidad en TPM de hardware
  • Para operaciones de atestación única, la sobrecarga de rendimiento es aceptable

Soporte de Plataforma en Nube

PlataformaSoporte de CVMSoporte de vTPMSoporte de Máquina DesnudaTPM de Hardware
GCP✓✓✓✓
Azure✓✓××
AWS×✓××

Trabajo Relacionado

Atestación de Vinculación de Ubicación

Las soluciones existentes típicamente dependen de verificación basada en latencia o señales de geolocalización externa como GPS, pero sufren ruido de ruta de red o falta de precisión.

Protección Contra Ataques de Proxy

El "ataque de proxy Frankenstein" propuesto en este artículo extiende conceptos de ataque de conexión existentes, donde el atacante posee múltiples dispositivos de hardware en lugar de una plataforma única.

Mecanismos de Protección de Privacidad

El trabajo relacionado enfatiza preocupaciones sobre la fuga de información sensible en registros de transparencia de certificados, y este artículo propone usar pruebas de conocimiento cero para mitigar riesgos de rastreabilidad.

Conclusiones y Discusión

Conclusiones Principales

  1. DCEA cierra exitosamente la brecha entre el modelo de amenaza de TEE y las necesidades de implementación real
  2. A través de raíces de confianza duales y verificación cruzada PCR-RTMR, defiende efectivamente contra seis ataques de software principales
  3. La implementación en plataformas de hardware existentes demuestra la viabilidad del esquema

Limitaciones

  1. Dependencia del Proceso de Medición de PCR: Las mediciones de PCR pueden variar entre plataformas o pilas de virtualización diferentes
  2. Desafíos en Entornos Multiinquilino: La reutilización de componentes de vTPM puede debilitar las garantías de unicidad de la atestación
  3. Consideraciones de Privacidad: La cadena de certificados de vTPM puede revelar detalles de implementación

Direcciones Futuras

  1. Extensión a Plataformas AMD: Requiere que AMD SEV-SNP proporcione funcionalidad similar a RTMR
  2. Registro de Claves Global: Establecimiento de verificación de unicidad de AK basada en blockchain o transparencia de certificados
  3. Integración de Pruebas de Conocimiento Cero: Implementación de verificación de plataforma que proteja la privacidad

Evaluación Profunda

Fortalezas

  1. Importancia del Problema: Aborda un punto ciego de seguridad crítico en la implementación de CVM
  2. Innovación del Método: Primera propuesta de esquema sistemático de atestación de vinculación de ubicación
  3. Practicidad Fuerte: Implementable en plataformas comerciales existentes
  4. Análisis de Seguridad Completo: Identifica y mitiga múltiples vectores de ataque
  5. Implementación Integral: Proporciona implementación detallada del protocolo y evaluación de rendimiento

Deficiencias

  1. Dependencia de Plataforma: Actualmente limitado principalmente a Intel TDX, con soporte limitado para AMD
  2. Suposiciones de Confianza: Aún requiere confiar en la seguridad física del proveedor de nube y emisión de certificados
  3. Sobrecarga de Rendimiento: Las operaciones de TPM de hardware son relativamente lentas
  4. Complejidad: La implementación del protocolo es compleja, aumentando la dificultad de implementación

Impacto

  1. Contribución Académica: Proporciona una nueva dimensión de garantía de seguridad para el campo de la computación confidencial
  2. Valor Práctico: Significativo para aplicaciones de alto riesgo como DeFi
  3. Potencial de Estandarización: Puede influir en el desarrollo de estándares futuros de TEE

Escenarios Aplicables

  • Aplicaciones de finanzas descentralizadas (DeFi)
  • Escenarios de computación multiparte
  • Cargas de trabajo de computación en nube de requisitos de seguridad elevados
  • Aplicaciones de computación confidencial que requieren verificación de ubicación

Referencias

El artículo cita 55 referencias relacionadas, cubriendo múltiples campos incluyendo tecnología de TEE, especificaciones de TPM, seguridad en computación en nube y protocolos criptográficos, proporcionando una base teórica sólida para la investigación.