Confidential Computing: el protocolo que prometía seguridad en la nube ahora tiene un fallo crítico de confianza

Introducción

En mayo de 2026, The Register reveló que los management engines de Intel y AMD (como el Intel Management Engine o AMD PSP) operan por debajo del sistema operativo y quedan fuera del alcance de marcos de soberanía como SecNumCloud en Europa. Esto dejó una pregunta crítica sin respuesta: ¿qué pasa con el protocolo que supuestamente debía probar que ese hardware —y por extensión, la nube— podía ser confiable?

La respuesta llegó con tres años de investigación formal liderada por Muhammad Usama Sardar, de la TU Dresden: el protocolo Attested TLS, piedra angular de Confidential Computing, tiene un diseño arquitectural que no cumple lo que promete. Peor aún, los ataques descubiertos no son simples bugs de implementación, sino fallos de diseño que permiten redirigir conexiones legítimas a servidores comprometidos sin que el cliente lo detecte.

Qué ocurrió

La premisa rota de Confidential Computing

Confidential Computing se basa en remote attestation: un servidor demuestra criptográficamente a un cliente que está corriendo dentro de un Trusted Execution Environment (TEE) genuino y sin modificaciones, antes de que cualquier dato sensible sea transmitido. Empresas como Intel y Google Cloud lo promocionan como la base de nubes soberanas y gobernanza de datos.

Sin embargo, el análisis formal realizado por Sardar y su equipo —publicado en Identity Crisis in Confidential Computing (AsiaCCS 2026)— demostró que Attested TLS no puede probar quién está al otro lado de la conexión. En su lugar, solo verifica que el software en ejecución es el esperado, no su ubicación física o identidad de red.

Los ataques: relay y diversion

Los investigadores formalizaron tres niveles de binding criptográfico entre la evidencia de attestation y la conexión TLS real:

1. Nivel 1: La evidencia se vincula solo al intercambio inicial de claves (Diffie-Hellman). Cubre el inicio del handshake, pero no la identidad del servidor.
2. Nivel 2: La evidencia se vincula a la clave de tráfico del cliente. Esto cubre todo hasta la confirmación de identidad del servidor.
3. Nivel 3 (el relevante en producción): La evidencia debería vincularse a la clave de tráfico real usada para cifrar los datos. Este nivel es inalcanzable con el diseño actual de Attested TLS.

Los ataques demostrados por Sardar son de dos tipos:

• Diversion: Redir una conexión destinada a un servidor legítimo a otro máquina comprometida, en cualquier parte del mundo, sin que el cliente lo note.
• Relay: Un cliente verifica la evidencia de un servidor confiable (ej: un agente de IA), pero termina cifrando su tráfico a un servidor malicioso distinto.

Implementaciones afectadas en producción

El equipo analizó siete mecanismos de binding en Attested TLS. Solo tres alcanzan el nivel 1; el resto falla incluso ese mínimo. La propuesta de mitigación de Sardar —un binder criptográfico basado en el secreto del handshake y la clave pública del servidor— solo logra el nivel 2.

Los sistemas afectados incluyen:

• Meta (WhatsApp Private Processing): Revisado por Trail of Bits antes de su despliegue, pero sin análisis formal. El fallo pasó desapercibido.
• Edgeless Systems (Contrast): Plataforma de confidencialidad para cargas de trabajo en Kubernetes.
• Cocos AI (versiones 0.4.0 a 0.8.2): Plataforma open-source para procesamiento confidencial de datos.
• CCC Attestation SIG PoC: El proyecto de prueba de concepto del Confidential Computing Consortium también resultó vulnerable.

CVE-2026-33697: detalles y severidad

El fallo fue reportado responsablemente y asignado como CVE-2026-33697, con un CVSS score de 7.5 (Alto). Para contexto:

• BadRAM (2024, ataque contra AMD SEV-SNP): CVSS 5.3.
• Fabricked (cluster de fallos recientes en Confidential Computing): CVSS 5.9.
• BreakFAST (otro fallo en el mismo ecosistema): CVSS 5.9.

El IETF y el Attestation Special Interest Group del CCC ya reconocieron formalmente los ataques de relay. Sardar advirtió: «Attested TLS, tal como está implementado hoy, no es maduro. Estamos investigando más, y estamos seguros de que hay más problemas por descubrir».

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

Si tu organización depende de Confidential Computing para:

• Procesamiento confidencial de datos (ej: ML en la nube con modelos sensibles).
• Gobernanza de datos soberanos (ej: cumplimiento con SecNumCloud o GDPR).
• Aislamiento de cargas de trabajo críticas (ej: contratos inteligentes, registros médicos).

…entonces estas conexiones no son tan seguras como creen. Un atacante podría:

1. Interceptar tráfico legítimo redirigiéndolo a un servidor controlado por él, sin romper el cifrado TLS.
2. Filtrar datos sensibles durante minutos u horas, mientras el cliente cree estar comunicándose con el destino correcto.
3. Usar el fallo como vector de pivoting en entornos híbridos o multi-nube.

Ejemplo concreto: Un equipo de DevOps despliega un servicio de IA en AWS Nitro Enclaves usando Attested TLS. Una instancia comprometida en otra región (o incluso en otro availability zone) podría recibir tráfico sensible sin que el cliente detecte el cambio.

Para equipos de Seguridad

El fallo expone una falsa sensación de seguridad en Confidential Computing:

• La confianza se delega en el hardware, pero los protocolos superiores (como Attested TLS) no pueden garantizar la identidad continua del servidor.
• La verificación formal es crítica: Un audit manual (como el realizado por Trail of Bits en Meta) no puede detectar fallos de diseño que solo emergen bajo análisis exhaustivo.
• La estandarización está en riesgo: El CCC y el IETF reconocieron el problema, pero no hay consenso aún sobre cómo mitigarlo sin romper el estándar TLS 1.3.

Impacto cuantitativo:

• 4 de los 5 sistemas evaluados están en producción hoy (Meta, Edgeless, Cocos AI, CCC PoC).
• Todas las versiones de Cocos AI entre 0.4.0 y 0.8.2 son vulnerables.
• El fallo afecta a cualquier implementación que use intra-handshake attestation, independientemente del proveedor de cloud (AWS, GCP, Azure) o del TEE (Intel TDX, AMD SEV-SNP, ARM CCA).

Para equipos de Cloud

Las plataformas de cloud que promocionan Confidential Computing como diferenciador (ej: AWS Nitro Enclaves, Google Confidential VMs) ahora enfrentan un problema de confianza en su propia infraestructura:

• AWS Nitro Enclaves usa Attested TLS para aislar cargas de trabajo. ¿Cómo garantiza que un enclave no sea reemplazado por uno malicioso durante una sesión?
• Google Cloud Confidential Computing depende de mecanismos similares para «control auditables sobre el acceso a datos». Este fallo invalida esa promesa.

• Autenticación mutua (mTLS) con certificados firmados por una CA interna.
• Monitoreo continuo de integridad de los enclaves (ej: usando runtime attestation fuera del handshake).
• Segmentación de red para aislar tráfico confidencial.

Detalles técnicos

Cómo funciona Attested TLS (y por qué falla)

Attested TLS extiende el handshake estándar de TLS 1.3 para incluir:

1. Generación de evidencia: El servidor genera una prueba criptográfica (usando el TEE) de que está corriendo el software esperado.
2. Binding a la conexión: Esa evidencia debería vincularse a la clave de tráfico real usada para cifrar los datos.

El problema está en el binding. Sardar formalizó tres niveles:

Cliente (C) ───────────────────> Servidor Legítimo (S1) [Attested TLS]
       │
       ▼
Atacante (A) [Servidor Malicioso, mismo software]
       │
       ▼
C ◄─────────────────── A [Handshake exitoso, pero tráfico va a A]

El cliente verifica que S1 está corriendo el software correcto, pero nunca verifica que S1 sea realmente quien responde. El atacante puede estar en otro continente.

Análisis formal vs. auditorías manuales

El equipo de Sardar usó ProVerif, una herramienta de verificación formal de protocolos. Sus ventajas:

• Exhaustividad: Analiza todas las ramas del protocolo bajo un modelo de amenaza definido.
• Detección de fallos sutiles: Un binding mal implementado puede pasar desapercibido en auditorías manuales (como la de Trail of Bits en Meta).

• Solo analizó intra-handshake attestation. El post-handshake attestation (ej: verificaciones durante la sesión) quedó fuera del alcance.
• No cubrió implementaciones específicas de proveedores (ej: cómo AWS implementa Attested TLS en Nitro).

CVE-2026-33697: vectores y mitigación propuesta

• Vector: Ataques de relay y diversion en Attested TLS intra-handshake.
• Componentes afectados:

– Edgeless Contrast.

– Cocos AI (v0.4.0–v0.8.2).

– CCC Attestation SIG PoC.

• Mitigación propuesta por Sardar:

– El secreto del handshake (handshake_secret en TLS 1.3).

– La clave pública del servidor (server_public_key).

– Logra nivel 2, pero no nivel 3.

// Pseudocódigo del binder propuesto por Sardar
fn create_binder(
    handshake_secret: &[u8],
    server_public_key: &[u8],
    attestation_evidence: &[u8],
) -> Vec<u8> {
    let binder_key = hkdf_expand_label(
        handshake_secret,
        "tls13 attested binder",
        &[],
        32,
    );
    let binder_input = [server_public_key, attestation_evidence].concat();
    hmac_sha256(&binder_key, &binder_input)
}

• Modificar TLS 1.3 para incluir la clave de tráfico durante el handshake (rompiendo su diseño actual).
• Añadir overhead criptográfico que impactaría en rendimiento (ej: firmar cada paquete con la evidencia de attestation).

Qué deberían hacer los administradores y equipos técnicos

1. Identificar dependencias en Confidential Computing

Revisa tu stack:

# Ejemplo: Buscar servicios que usen Intel TDX o AMD SEV-SNP
kubectl get pods -A -o jsonpath='{.items[*].metadata.annotations.container\.security\.intel\.com\/tdx}'
az vm list --query "[?confidentialComputeType=='TDX']" -o table
gcloud compute instances list --filter="confidentialInstanceConfig.isEnabled:true"

Si usas:

• AWS Nitro Enclaves: Verifica si tu aplicación usa Attested TLS.
• Edgeless Contrast: Actualiza a la última versión (o aplica parches manuales).
• Cocos AI: Despliega versiones ≥0.8.3 (o migra a alternativas).

2. Implementar capas adicionales de seguridad

a) Autenticación mutua (mTLS) con certificados internos

# Ejemplo en Kubernetes (Istio)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
spec:
  mtls:
    mode: STRICT

b) Verificación de integridad continua

Usa herramientas como:

• AWS Nitro Enclaves Attestation: Verifica el report de attestation cada N minutos.
• Google Cloud Confidential VMs: Usa el API de shielded VMs para monitorear integridad.

# Comando para verificar integridad en AWS Nitro Enclaves
aws nitro-enclaves-cli describe-enclave --enclave-id <ID> | jq '.PCRs'

c) Segmentación de red

• Aísla tráfico confidencial en VPC dedicadas.
• Usa network policies en Kubernetes o firewalls en cloud.

# Ejemplo: Denegar tráfico no autorizado en AWS VPC
aws ec2 create-network-acl-entry \
  --network-acl-id <ACL_ID> \
  --rule-number 100 \
  --protocol tcp \
  --port-range FromPort=443,ToPort=443 \
  --cidr-block <IP_SERVIDOR_LEGITIMO>/32 \
  --egress \
  --action deny

3. Actualizar sistemas afectados

# Actualizar Cocos AI (ejemplo con Docker)
docker pull cocosai/cocos:0.8.3
docker run -d --name cocos-ai --restart unless-stopped cocosai/cocos:0.8.3

# Verificar versión en AWS Nitro Enclaves
aws nitro-enclaves-cli describe-enclave --enclave-id <ID> | jq '.ImageID'

4. Monitorear y auditar

• Logs de handshakes TLS: Usa herramientas como Zeek o Suricata para detectar anomalías.

  # Ejemplo de regla Zeek para detectar relay attacks
  event ssl_handshake(c: connection, is_resumed: bool, version: count) {
      if (c$id$resp_h in [10.0.0.0/8, 192.168.0.0/16]) {
          NOTICE([$note=SSL::PossibleRelayAttack, $msg="Posible ataque de relay en IP interna"]);
      }
  }
  

• Alertas en SIEM: Configura reglas para detectar cambios en attestation reports (ej: un servidor reportando el mismo PCR pero en una región distinta).

5. Evaluar alternativas

Si Confidential Computing es crítico para tu organización, considera:

• TLS 1.3 puro con mTLS: Sin depender de Attested TLS.
• Isolation con sandboxing (ej: Firecracker, gVisor).
• Multi-cloud con verificación cruzada: Usa enclaves en proveedores distintos y valida integridad de ambos.

Conclusión

El descubrimiento de Sardar expone una falla fundamental en la arquitectura de Confidential Computing: Attested TLS no puede garantizar que un cliente esté hablando con el servidor correcto durante toda la sesión, solo al inicio del handshake. Esto invalida promesas de soberanía, aislamiento y gobernanza que han impulsado inversiones en nubes europeas y globales.

La industria enfrenta un dilema:

1. Aceptar que Attested TLS es insalvable en su forma actual y migrar a alternativas (mTLS, sandboxing).
2. Modificar TLS 1.3 para soportar level 3 binding, con el riesgo de romper compatibilidad y rendimiento.
3. Depender del hardware (no del protocolo) y asumir que la confianza absoluta no existe.

Mientras tanto, los equipos técnicos deben:

• Dejar de confiar ciegamente en Attested TLS.
• Implementar capas adicionales de autenticación y monitoreo.
• Priorizar actualizaciones en sistemas afectados.

El fallo (CVE-2026-33697) es solo la punta del iceberg. Como advirtió Sardar: «Estamos seguros de que hay más problemas por descubrir». La verificación formal debe volverse estándar en el diseño de protocolos de seguridad críticos.

FIN