Intel SGX y AMD SEV: 8 ataques que rompen los TEE

¿Qué es un TEE y por qué tu startup ya depende de uno?

Un TEE (trusted execution environment, o "enclave") es una zona aislada dentro del propio procesador donde el código y los datos se procesan cifrados incluso mientras están en uso. El Confidential Computing Consortium (CCC), un proyecto de la Linux Foundation en el que participan Alibaba, Arm, Google, Huawei, Intel, Microsoft y Red Hat, lo define como un entorno que garantiza integridad de datos, confidencialidad e integridad del código: una vez configurado, ni el sistema operativo, ni el administrador del servidor, ni el proveedor de nube pueden leer ni modificar lo que ocurre dentro, según la descripción que recoge TechTarget.

Para un founder esto no es teoría de laboratorio. Si vendes a banca, salud o seguros, o si operas una red descentralizada, el TEE suele ser el ancla de confianza de tu propuesta: "ni yo puedo ver tus datos". El mercado lo confirma. Un informe de ResearchAndMarkets difundido en octubre de 2026 calcula que el gasto global en confidential computing pasó de US$12.280 millones en 2025 a US$16.690 millones en 2026, un 36% anual, y proyecta US$54.920 millones para 2030. La misma firma atribuye parte del impulso a la presión regulatoria y a la escalada de intrusiones: Check Point reportó que los ataques semanales contra redes corporativas crecieron 30% en el segundo trimestre de 2024 frente al mismo período de 2023.

El problema es que la garantía que sostiene todo ese mercado se rompió varias veces, y el repaso técnico que motiva esta nota lo documenta año por año.

Los ataques que rompieron la atestación remota

La atestación remota es la pieza de la que depende todo lo demás: el hardware firma un informe que certifica qué código corre dentro del enclave, y tu servidor lo verifica antes de entregar secretos. Si esa firma se puede falsificar, el modelo entero se cae.

El repaso publicado en alinush.github.io enumera una secuencia de ataques que fueron tumbando esa garantía, uno tras otro:

• 2018, Foreshadow: un sistema operativo malicioso logra robar la clave de atestación de Intel SGX. Fue la primera vez que se consiguió.
• 2020, SGAxe: repite el robo de la clave de atestación, esta vez con acceso ring-0.
• 2022, ÆPIC Leak: un bug microarquitectónico permite al administrador root del host robar la clave de atestación de SGX.
• 2024, BadRAM: sobre sistemas AMD SEV-SNP, un atacante con un único acceso físico manipula el chip SPD del módulo de memoria —unos US$10 de hardware— y consigue que el chip genuino de AMD firme un informe que certifica una máquina virtual benigna mientras en realidad corre una backdoor. No se extrae ninguna clave: la atestación simplemente miente.
• 2025, WireTap.fail: ataque de interposición física sobre sistemas DDR4. Sus autores afirman haber extraído claves de atestación y demuestran rupturas concretas sobre software real que usa SGX, entre ellos Secret Network, Phala, Crust e IntegriTEE.
• 2025, TEE.fail: la misma técnica de interposición, ahora sobre DDR5.
• 2025, Battering RAM: interposición física en DDR4.
• 2026, DDRop: interposición en DDR5 descartando escrituras, que habilita la falsificación de la atestación remota de Intel TDX.

No todo pasa por el hardware. El mismo repaso recuerda que el enclave de descubrimiento de contactos de Signal tuvo fallos de seguridad de memoria que permitían al host confundirlo y hacer que filtrara el contenido de su propia memoria. La lección es incómoda: incluso con una plataforma intacta, el código que corre dentro puede arruinarlo todo.

¿Por qué un ataque físico debería importar si tu modelo de amenaza lo excluye?

Es la objeción más repetida y el análisis la desarma sin rodeos: tu verificador de atestación acepta un informe firmado por cualquier CPU Intel en buen estado, y la CPU del atacante es una de ellas. La ruptura de una es la ruptura de todas.

La única salida que plantea el texto es fijar el verificador para que acepte únicamente tus propios certificados PCK, lo que excluye de forma implícita la CPU del atacante. Funciona para el llamado SGX escalable, el único que queda, pero exige gestionar una PKI propia con mucho cuidado. El autor lo describe como empuñar un arma cargada apuntando al pie.

Traducido a decisiones de producto: si tu arquitectura asume que la atestación siempre dice la verdad, estás delegando tu seguridad en un supuesto que la literatura académica ya rompió al menos ocho veces.

Cuando el enclave no está comprometido, solo apagado

La denegación de servicio está explícitamente fuera del modelo de amenaza de SGX, TDX, SEV-SNP y Nitro, porque el host siempre puede negarse a ejecutar el enclave. Pero hay fallos de disponibilidad que vienen de la propia plataforma:

• 2018: la revocación de credenciales de SGX tras Spectre y Meltdown dejó a los enclaves paralizados.
• 2022: SGX.fail documenta lo lento que se despliegan las recuperaciones de TCB y cómo las plataformas pueden quedar desactualizadas durante largos períodos.
• 2022: fallo de atestación TPM en plataformas AMD con ASP fTPM. El impacto de ejemplo que cita el repaso es llamativo: jugadores que no pueden competir en torneos online con premio en efectivo.

Para un SaaS que promete disponibilidad, esto importa tanto como un robo de claves. Un enclave que no arranca es una caída de servicio, y el proveedor de nube no te debe nada al respecto.

¿Qué están haciendo las nubes y los fabricantes?

El ecosistema lleva años construyendo sobre estas piezas. Microsoft fue el primer proveedor de nube en ofrecer confidential computing, en 2017, y sus máquinas virtuales con SGX sacan a Microsoft del perímetro de confianza, aunque obligan a reescribir el código de la aplicación. Google Cloud tomó el camino opuesto: sus Confidential VMs corren sobre hardware de AMD y permiten volver confidencial una máquina existente con un clic y sin tocar el código, con la contrapartida de que SEV ofrece mejor portabilidad y rendimiento pero no protege la integridad de memoria ni aísla el código del dueño de la plataforma, según el análisis de Steve Riley, analista de Gartner, recogido por TechTarget.

IBM anunció sus capacidades en 2018 y va por la cuarta generación, con servicios gestionados y la única oferta de nube pública con certificación FIPS 140-2 Nivel 4, según el mismo repaso. AWS no forma parte del CCC y su apuesta son los Nitro Enclaves, que aíslan la carga del resto de la instancia EC2 sin apoyarse en SGX ni en SEV. La visión de largo plazo la resumió Mark Russinovich, CTO de Microsoft Azure: conforme maduren y sean más flexibles, estas tecnologías se adoptarán más fácil, y la expectativa de la compañía es que el confidential computing termine siendo una capacidad ubicua.

¿Qué significa esto para tu startup?

Si tu producto toca datos sensibles o si vendes confianza como característica, estas son las decisiones que conviene tomar antes de que un cliente regulado te las pida:

• Haz un inventario de secretos antes de meterlos en un enclave. Separa claves de firma de larga vida, semillas y datos crudos de salud o financieros de las cargas de trabajo que solo necesitan aislarse del operador. La recomendación del repaso es directa: no pongas secretos valiosos en un TEE, porque es probable que terminen siendo públicos.
• Fija tu verificador a tus propios certificados PCK y gestiona esa PKI. Aceptar informes firmados por cualquier CPU en buen estado equivale a confiar en el hardware de tu atacante. Es trabajo extra y es exactamente el punto donde la mayoría de los equipos se salta el rigor.
• Diseña para la rotación y asume el peor caso. Claves efímeras, rotación programada y un plan escrito para el día en que la atestación deje de ser confiable. Si tu recuperación depende de que el enclave siga ahí, no tienes plan.
• Exige evidencia, no marketing. Pide a tu proveedor el modelo de amenaza por escrito: qué ataques cubre y cuáles quedan fuera. La denegación de servicio, por ejemplo, está fuera del modelo de SGX, TDX, SEV-SNP y Nitro por diseño.
• Si vendes confidential computing, anticipa el escrutinio. La due diligence técnica de un cliente de banca o salud va a incluir estas preguntas, y llegar con respuestas preparadas es una ventaja comercial concreta.
• Considera los diseños alternativos con los ojos abiertos. Propuestas académicas como Sanctum, del grupo del autor en el MIT, reducen la superficie de ataque del hardware de confianza, pero tienden a pagar ese beneficio con menor rendimiento o menos funcionalidad.

Conclusión

Los TEE siguen siendo una herramienta útil para aislar cargas de trabajo del operador de la infraestructura, y el mercado que los rodea crece a un ritmo que ningún founder puede ignorar. Pero la evidencia acumulada entre 2018 y 2026 muestra que la atestación remota —el mecanismo del que depende toda la confianza— se puede falsificar, y que el atacante no necesita ser un actor estatal con acceso a la fábrica: en el caso de BadRAM bastó un acceso físico puntual y unos dólares en hardware.

La conclusión práctica es de gestión de riesgo, no de rechazo tecnológico: trata al TEE como una capa más de defensa en profundidad, nunca como la bóveda donde guardas lo que no puede filtrarse. Si tu modelo de negocio se cae cuando la atestación falla, el problema no es el ataque: es el diseño.

Fuentes

• It's time to talk about TEEs (fuente original)
• How public cloud vendors tackle confidential computing
• Global Confidential Computing Market Report 2026