El cómputo confidencial debía cerrar el último flanco de la historia del cifrado: datos en reposo, datos en tránsito y, por fin, datos en uso. Las empresas que construyen cargas de trabajo sensibles a la soberanía sobre TEEs han apostado sus arquitecturas por esa promesa. Luego llegó una serie de divulgaciones en AMD SEV-SNP e Intel TDX que plantearon una pregunta incómoda: ¿sigue siendo válido el modelo de confianza?
La respuesta corta es sí, con condiciones. La respuesta larga exige entender qué rompe cada clase de vulnerabilidad, qué restauran las mitigaciones y dónde queda el riesgo residual. Desestimar las divulgaciones como ruido de los fabricantes sería ingenuo; tratarlas como una invalidación total del cómputo confidencial sería igualmente erróneo.
Qué mostraron realmente las vulnerabilidades recientes
La divulgación más significativa de AMD, CVE-2024-56161 (AMD-SB-3019), expuso un fallo en la verificación de firma de microcódigo de la CPU. Un atacante con privilegio de administrador local en ring 0 podía cargar microcódigo malicioso, comprometiendo las garantías de confidencialidad e integridad de un guest ejecutándose bajo AMD SEV-SNP. El equipo de seguridad de Google demostró la capacidad de fabricar parches de microcódigo maliciosos arbitrarios en Zen 1 hasta Zen 4; la causa raíz fue una función hash insegura en la ruta de validación de firmas. AMD asignó una puntuación CVSS de 7,2. La corrección requirió una actualización de microcódigo, una actualización del firmware SEV en algunas plataformas y un reflash de BIOS; tras reiniciar, el propio informe de atestación de SEV-SNP puede confirmar que la mitigación está activa.
Un aviso separado de AMD, AMD-SB-3011, describió tres formas en que un hipervisor malicioso podía leer o corromper la memoria de una VM guest. El lote de agosto de 2025 (AMD-SB-3014) añadió más problemas de IOMMU y SEV-SNP hallados en auditorías internas y de terceros, con mitigaciones incluidas en los paquetes de firmware EPYC Platform Initialization. Investigadores de KU Leuven, la Universidad de Lübeck, el CISPA Helmholtz Center y la Universidad de Birmingham fueron reconocidos por varios de esos hallazgos.
En el lado de Intel, una revisión conjunta de cinco meses entre Google Cloud Security y el equipo INT31 de Intel sobre TDX Module 1.5 produjo cinco CVEs junto con 35 bugs y debilidades adicionales. El más grave, CVE-2025-30513, permitía a un operador no confiable comprometer completamente las garantías de seguridad de TDX. CVE-2025-27572 es un canal lateral de ejecución transitoria dentro de los componentes del hipervisor en Ring 0 que puede exponer datos sensibles a través de rutas de ejecución especulativa, aunque la explotación requiere alta complejidad y acceso local privilegiado. Intel parchó los cinco CVEs antes de la divulgación coordinada.
Qué tienen en común las vulnerabilidades
Al analizar ambas plataformas emerge un patrón. Cada ataque divulgado requiere acceso ring 0 en el host, un hipervisor comprometido o proximidad física a la plataforma. Ninguno es explotable de forma remota por un inquilino sin un punto de apoyo previo. Eso no los convierte en teóricos: un proveedor de nube con un administrador deshonesto, un compromiso en la cadena de suministro que alcance la capa de firmware, o un actor estatal con acceso físico son todos actores de amenaza plausibles. Pero el modelo de amenaza típico del cómputo confidencial, proteger la carga de trabajo de un inquilino frente a un operador de nube no confiable, es precisamente lo que estos ataques apuntan.
La superficie de ataque del cómputo confidencial no es el enclave en sí. Es el firmware, la ruta de actualización del microcódigo y la cadena de atestación que ancla la confianza en hardware que el inquilino no posee.
Ese reencuadre importa para las decisiones de arquitectura. Las empresas que adoptaron TEEs principalmente para cumplir requisitos regulatorios de aislamiento de datos en uso, sin modelar la ruta de actualización de firmware y microcódigo como parte del límite de confianza, tienen una brecha que cerrar. Quienes la modelaron correctamente y ejecutan plataformas parcheadas y atestadas están en una posición materialmente mejor que antes de las divulgaciones, porque los parches ahora son verificables mediante atestación.
Atestación remota: el mecanismo que hace verificables las mitigaciones
La atestación es la parte de la arquitectura de cómputo confidencial que transforma un parche de una afirmación en una prueba criptográfica. En SEV-SNP, el informe de atestación lo genera el hardware y lo firma una clave enraizada en la AMD Root Key; tras aplicar las correcciones de microcódigo y firmware para CVE-2024-56161, el informe de atestación puede confirmar que la mitigación está activa. Una carga de trabajo puede negarse a desbloquear secretos a menos que el informe de atestación refleje el estado parcheado. Esto no es un workaround; es el mecanismo funcionando como fue diseñado.
La implicación práctica es que la gestión de políticas de atestación se convierte en una preocupación operativa de primer nivel, no en una casilla de verificación en el despliegue. Los equipos deben definir versiones mínimas aceptables de firmware, fijar los valores de medición esperados e integrar la verificación en la ruta de lanzamiento de la carga de trabajo en lugar de confiar implícitamente en la plataforma. La revisión conjunta de Intel TDX reforzó esto: varios de los 35 hallazgos que no son CVE eran debilidades en cómo se delegaba la confianza entre componentes, más que bugs de corrupción de memoria directa.
Mitigación de vulnerabilidades en enclaves en la práctica
Un despliegue de cómputo confidencial defendible tras estas divulgaciones tiene este aspecto. Primero, tratar el ciclo de actualización de microcódigo y BIOS como una ruta crítica de seguridad, no como una tarea de mantenimiento; la ventana entre la fecha de corrección interna de AMD (diciembre de 2024) y la divulgación pública (febrero de 2025) para CVE-2024-56161 muestra que los plazos de divulgación responsable se miden en semanas, no en meses, y las plataformas deben absorber los parches con rapidez. Segundo, aplicar verificación de atestación al iniciar la carga de trabajo y construir una política que rechace enclaves ejecutándose en plataformas por debajo de una línea base de firmware conocida como buena. Tercero, delimitar el modelo de amenaza con honestidad: si el adversario es un administrador de nube deshonesto con acceso ring 0, los TEEs con atestación verificada siguen siendo el control disponible más sólido; si el adversario tiene acceso físico al servidor y tiempo ilimitado, ningún control puramente de software será suficiente.
Para cargas de trabajo donde el hipervisor no puede ser confiable en absoluto, la respuesta arquitectónica es avanzar hacia un diseño en el que la atestación del TEE sea verificada por el propietario de la carga de trabajo directamente contra el servicio de atestación del fabricante de hardware, sin pasar por el operador de nube. Tanto AMD como Intel publican las cadenas de certificados de atestación necesarias para hacerlo.
La capa de red y dónde termina realmente la confianza
La verificación de atestación es una operación de red: la carga de trabajo contacta el servicio de atestación del fabricante de hardware, o un proxy del mismo, y esa conexión debe ser confiable. Para empresas europeas con requisitos de residencia de datos, importa enrutar el tráfico de atestación a través de la red de un proveedor que tenga peering directo con los servicios relevantes. Operamos 44 puntos de presencia en Europa y Oriente Medio con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en todos los sitios, lo que significa que las llamadas al servicio de atestación y la recuperación de secretos sellados que las sigue viajan por rutas que controlamos, en lugar de atravesar segmentos impredecibles de internet público donde picos de latencia o anomalías BGP podrían crear canales laterales de temporización o timeouts de atestación que degraden la postura de seguridad.
El punto más amplio es que la seguridad del cómputo confidencial no es una propiedad del enclave por sí solo. Es una propiedad de toda la ruta, desde la raíz de confianza en el hardware, pasando por el firmware, por la llamada de verificación de atestación y hasta la decisión de liberación de claves. Las debilidades en cualquier punto de esa ruta importan. Las divulgaciones recientes localizaron debilidades en la capa de firmware; las mitigaciones las abordan; la atestación hace verificable la corrección. La arquitectura no está rota. Se entiende mejor que hace dieciocho meses, y eso es una base razonable para mantener la confianza.
