Confidential computing: el protocolo de confianza TLS atestiguado tiene fallos críticos

¿Qué ha ocurrido?

El investigador Muhammad Usama Sardar, de la Universidad Técnica de Dresde (TU Dresden), ha publicado dos estudios que demuestran que el protocolo attested TLS (TLS atestiguado), diseñado para vincular criptográficamente la identidad de un servidor con su ejecución dentro de un Entorno de Ejecución Confiable (TEE), no cumple su promesa de seguridad. En el primer trabajo, presentado en la conferencia AsiaCCS 2026 bajo el título Identity Crisis in Confidential Computing, se identificaron ataques de desvío (diversion attacks) contra dos protocolos state-of-the-art de TLS atestiguado. En el segundo, titulado Intra-handshake.fail y aceptado para ESORICS 2026, se analizaron siete mecanismos de vinculación durante el handshake TLS (intra-handshake attestation) y ninguno logró prevenir ataques de retransmisión (relay attacks).

La investigación se realizó utilizando la herramienta ProVerif, un verificador formal ampliamente aceptado para el análisis simbólico de protocolos de seguridad. Los resultados han sido verificados de forma independiente, lo que otorga solidez a las conclusiones. Sardar y sus coautores (Mariam Moustafa y Tuomas Aura en el primer estudio; Viacheslav Dubeyko y Jean-Marie Jacquet en el segundo) han demostrado que el TLS atestiguado, tal como está implementado actualmente, no logra proporcionar el nivel de seguridad que la industria promete.

¿Por qué es importante?

La computación confidencial (confidential computing) se promociona como la base técnica de la nube soberana europea. Empresas como Intel, con su tecnología TDX (Trust Domain Extensions), y Google Cloud afirman que sus TEE protegen los datos incluso del propio proveedor cloud. Intel en sus páginas de producto promete que TDX “añadirá salvaguardas a la soberanía y gobernanza de datos”. Google Cloud describe su infraestructura de computación confidencial como aquella que ofrece “control completo y auditable sobre el acceso a los datos del cliente”.

Sin embargo, el TLS atestiguado es el mecanismo que permite al cliente verificar que está hablando con un TEE genuino antes de intercambiar datos sensibles. Si este protocolo es vulnerable, un atacante puede redirigir la conexión hacia un servidor malicioso que ejecute el mismo software, sin que el cliente lo detecte. Como señala Sardar: “En computación confidencial hay que confiar en el fabricante del hardware. No hay manera de evitarlo. Pero se suponía que la capa de protocolo proporcionaría todo lo demás. Nuestra investigación muestra que proporciona mucho menos de lo asumido.”

Además, en mayo de 2025, The Register informó que los motores de gestión (management engines) que operan por debajo del sistema operativo en chips de Intel y AMD quedan fuera de lo que los marcos de soberanía europeos como SecNumCloud realmente evalúan. Esto dejaba una pregunta abierta sobre la capa superior: el protocolo destinado a demostrar que el propio chip puede ser confiable. La nueva investigación responde a esa pregunta, y la respuesta no es tranquilizadora.

Consecuencias para empresas y usuarios

El fallo afecta directamente a cualquier organización que confíe en confidential computing para proteger datos sensibles en la nube: sectores regulados como finanzas, salud o administración pública. La promesa de soberanía de datos se debilita, y los clientes deben asumir que, incluso con TEE, un atacante externo podría interceptar comunicaciones. Los proveedores cloud deberán revisar sus implementaciones y posiblemente rediseñar los protocolos de atestación.

En el primer estudio, Sardar y sus colegas demostraron ataques de desvío contra dos protocolos de TLS atestiguado de última generación. Una conexión destinada a un servidor específico puede ser redirigida silenciosamente a otra máquina comprometida que ejecute el mismo software, en cualquier lugar del mundo, sin que el cliente lo sepa. El servidor original no ha hecho nada malo; el atacante simplemente explota el hecho de que el protocolo verifica la integridad del software, no su ubicación geográfica.

El segundo estudio, Intra-handshake.fail, va más allá. Examina lo que la industria llama “atestación intra-handshake”, donde la evidencia se genera durante el propio handshake TLS, y prueba siete formas diferentes de vincular criptográficamente esa evidencia a la conexión subyacente. Ninguna de ellas logró prevenir ataques de retransmisión. Incluso los mecanismos de vinculación más fuertes (nivel 3, que ata la evidencia a la clave de tráfico de aplicación) resultaron vulnerables.

Para los usuarios, esto implica que cualquier dato procesado bajo la promesa de confidential computing podría estar expuesto a intermediarios maliciosos. Las empresas que migran cargas de trabajo sensibles a la nube confiando en estas garantías deben reconsiderar sus estrategias de seguridad. Los proveedores cloud, por su parte, enfrentan un desafío arquitectónico: no existe un parche sencillo. Sardar sugiere que la solución podría requerir cambios fundamentales en cómo se define la atestación.

¿Qué deben saber los lectores?

• El TLS atestiguado no verifica la ubicación geográfica del servidor, solo la integridad del software. Esto permite ataques de redirección a cualquier máquina con el mismo software en cualquier parte del mundo.
• Los ataques de retransmisión (relay attacks) son posibles incluso con los mecanismos de vinculación más fuertes (nivel 3, que ata la evidencia a la clave de tráfico de aplicación).
• La investigación se realizó con la herramienta ProVerif, ampliamente aceptada para análisis formal de protocolos, y los resultados han sido verificados de forma independiente.
• No existe un parche sencillo; el problema es arquitectónico. Sardar sugiere que la solución podría requerir cambios fundamentales en cómo se define la atestación.
• Este hallazgo se suma a preocupaciones anteriores sobre los motores de gestión en chips Intel y AMD, que quedan fuera de los marcos de soberanía europeos. La combinación de ambos problemas pone en entredicho la viabilidad de la nube soberana basada en confidential computing.