El chip que guarda tus claves está roto: audité las cuatro máquinas de mi enjambre

El TPM existe para una sola cosa: guardar claves donde el sistema operativo no las pueda leer. Si cifras el disco y sellas la clave al TPM, la máquina arranca sola y el disco robado es un ladrillo. Toda esa promesa depende de que el chip cumpla su parte.

Esta semana aparecieron dos CVE que dicen que no la cumple. Los vi el mismo día en alemán, en heise, y en ruso, en OpenNet. En español no encontré nada, y ese vacío es la razón por la que este texto existe.

Así que en vez de traducir el anuncio, fui a revisar mis propias máquinas.

Qué se rompió

Los dos fallos están en el código de referencia TPM 2.0 del Trusted Computing Group, no en AMD ni en Intel. Los encontraron cuatro investigadores de Intel: Liran Perez, Zecharye Galitzky, Shai Sarfati y Yanai Moyal. Como casi todas las implementaciones de fTPM derivan de ese código, el problema se reparte solo.

CVE-2026-6726 (CVSS 8.5) es una confusión de tipos: el firmware no separa bien los objetos y una zona de memoria que ya se usó queda accesible cuando se reutiliza para otra cosa. Datos de una clave anterior sobreviven donde no deberían.

CVE-2026-6727 (CVSS 8.3) es un canal lateral por tiempo en el descifrado RSA OAEP. Un programa manda muchísimos comandos al coprocesador y mide cuánto tarda en responder; de esas diferencias deduce el secreto.

AMD publicó su boletín el 11 de agosto y marcó los dos como “non-AMD”, porque el origen es el código del TCG. La lista de afectados igual es enorme: de Ryzen 3000 a Ryzen 9000, Ryzen AI 300 y 400, Threadripper, los Z1 y Z2, varias familias Embedded. El fTPM de Intel también figura como afectado en el aviso del CERT.

Los dos exigen acceso local con privilegios. Eso baja bastante el pánico y sube la pregunta interesante: si alguien ya tiene root en tu máquina, ¿qué le quedaba protegido? Exactamente lo que el TPM guardaba.

La auditoría

Cuatro máquinas, cuatro respuestas distintas. El comando que separa el trigo de la paja es este:

sudo tpm2_getcap properties-fixed | grep -A3 TPM2_PT_MANUFACTURER

Si el fabricante es AMD o INTC, el TPM es firmware y corre dentro del procesador. Si sale IFX, STM o NTC, es un chip discreto y esta historia no te toca.

El Mac: inmune por no tener

MacBook Pro con un i7-9750H, un procesador que está de lleno en el rango afectado. Pero macOS no usa TPM: usa el chip T2 y su Secure Enclave, una implementación distinta que no deriva del código del TCG. No hay /dev/tpm0 que auditar.

La única máquina que se salva es la que nunca tuvo la pieza rota.

El VPS: la ventaja de no tener hardware

CPU: AMD EPYC 9355P 32-Core
hypervisor: kvm
sin /dev/tpm* (VM sin TPM expuesto)

Un EPYC 9355P, procesador afectado en la lista. Pero es una máquina virtual y el hipervisor no expone TPM al huésped. Si necesitara uno, sería un swtpm emulado, otra pila de código con otros problemas. Aquí tampoco hay nada que parchar.

fedora: afectada, con salida

Este sí duele, porque es el nodo con GPU donde corre la mitad de mi trabajo.

CPU:            AMD Ryzen 7 7800X3D
placa:          ASUS PRIME B650M-A II
fabricante TPM: AMD                  ← firmware TPM
versión fTPM:   6.31.0.6
BIOS:           2613 (12/04/2024)
AGESA:          FireRangePI 1.1.7.0

Un Ryzen 7000, en pleno rango. fTPM de AMD, no chip discreto. Y una BIOS de abril de 2024.

AMD entregó el firmware corregido a los fabricantes entre mayo y junio de 2026, y para AM5 el arreglo entra con AGESA ComboAM5 PI 1.2.0.3k o superior. ASUS ya publicó BIOS 3886 para esta placa el 2 de julio de 2026, con AGESA 1.3.0.1b, muy por encima del mínimo.

O sea: el parche existe desde hace seis semanas y mi máquina sigue en la BIOS 2613 mientras la corregida es la 3886.

vworker: afectada, sin salida

CPU:            Intel Core i5-9400F
placa:          ASUS PRIME H310M-E R2.0
fabricante TPM: INTC / "Intel"       ← Platform Trust Technology
versión fTPM:   302.12
BIOS:           1006 (13/08/2019)

Coffee Lake, novena generación, dentro del rango de Intel. Platform Trust Technology activo, que es el fTPM de Intel con otro nombre. BIOS de 2019.

Fui a buscar la actualización y encontré el final del camino: la última BIOS que ASUS publicó para esta placa es la 2209, de junio de 2022. Cuatro años sin una sola versión nueva. El chipset H310 salió en 2018 y está fuera de soporte.

El fix de un fTPM viaja únicamente dentro de una BIOS. Si el fabricante de la placa dejó de publicar BIOS, la vulnerabilidad se queda ahí para siempre. No hay comando, paquete ni truco que la saque.

Esa máquina no tiene arreglo. Punto.

El detalle que casi me engaña

Antes de ir al sitio de ASUS hice lo que haría cualquiera en Linux: preguntarle a fwupd, que es la herramienta estándar para actualizar firmware.

$ sudo fwupdmgr get-updates
Dispositivos sin actualizaciones del firmware disponible:
 • KINGSTON SNV2S1000G
 • System Firmware
 • UEFI dbx
Ningún dispositivo actualizable

fwupd ve el TPM. Lo lista con su versión, su fabricante y hasta sus GUID. Y aun así dice que no hay nada que actualizar, mientras el fabricante de la placa lleva un mes con la BIOS corregida publicada en su web.

La explicación no es un error: fwupd solo conoce lo que se publica en LVFS, y buena parte de los fabricantes de placas de escritorio no publica ahí. La herramienta no miente, pero su silencio se lee igual que un “estás al día”.

Si administras máquinas Linux y usas fwupd como señal de que el firmware está sano, esta es la lección más práctica del artículo. Que no reporte actualizaciones no significa que no existan.

Intenté medir el canal lateral, y no lo detecté

Aquí es donde este blog se separa de una nota traducida. No hay prueba de concepto pública, así que reproducir el ataque completo está fuera de alcance. Lo que sí se puede medir es su precondición: que el tiempo de respuesta del TPM dependa del dato que procesa.

Monté un banco simple. Creo una clave RSA-2048 dentro del TPM, cifro dos mensajes distintos (uno de puros ceros, otro aleatorio) y mido sesenta descifrados de cada uno.

AMD fTPM 6.31.0.6, en el Ryzen 7800X3D:

Intel PTT 302.12, en el i5-9400F:

La diferencia de mediana entre los dos mensajes fue de 0.090 ms en AMD y 0.048 ms en Intel. En ambos casos queda muy por debajo de la propia desviación de la medición.

No detecté el canal lateral. Y eso no desmiente el CVE: dice que mi instrumento es demasiado grueso. Estoy midiendo desde Python, lanzando un proceso por operación, con el planificador del sistema encima; el ruido de mi banco es de milisegundos y el ataque real vive en el orden de los ciclos de CPU, con mensajes elegidos a propósito para provocar la bifurcación, no aleatorios.

Publico el intento fallido porque el resultado negativo también informa: la precondición no se ve desde el espacio de usuario con herramientas normales. Nadie va a notar este ataque mirando latencias.

Lo que sí salió de la medición fue un dato lateral que me sorprendió. Un solo descifrado RSA-2048 tarda 326 ms en el fTPM de AMD y 374 ms en el PTT de Intel. Son menos de tres operaciones por segundo. Un TPM es un guardián lento por diseño, y esa lentitud explica sola por qué un ataque que necesita “incontables comandos” es tedioso, y por qué a nadie se le ocurre poner un TPM en el camino de algo con volumen.

También quedó claro que el PTT de Intel es bastante menos consistente: su desviación en getrandom es de 2.06 ms contra 0.15 ms del fTPM de AMD, casi catorce veces más dispersión.

Mi opinión

El titular asusta más de lo que corresponde. Los dos fallos piden acceso local con privilegios elevados, y a esa altura el atacante ya tiene tu máquina. Lo que estos CVE agregan es que las claves guardadas en el TPM, que eran justamente lo último que se suponía a salvo, dejan de estarlo.

Lo que sí me molesta de verdad es la cadena de distribución. El error vive en el código del TCG, AMD e Intel lo heredan, cada uno entrega firmware corregido a los fabricantes de placas, y cada fabricante decide si publica una BIOS. Cuando el modelo tiene ocho años, la respuesta es que no. La vulnerabilidad no se cierra: se abandona.

Y me irrita que la herramienta oficial de Linux para esto me haya dicho que todo estaba bien.

Qué haría con esto

• Averigua si tu TPM es firmware o chip. Un comando, treinta segundos. Si es discreto, deja de leer tranquilo.
• No confíes en fwupdmgr como única fuente. Ve al sitio del fabricante de tu placa y compara la versión de BIOS a mano.
• Si sellas claves de LUKS o BitLocker al TPM, actualiza la BIOS. Es el único escenario donde estos fallos cambian algo concreto para ti.
• Si tu placa ya no recibe BIOS, no selles nada al TPM. Una frase de paso que escribes al arrancar es hoy más confiable que un fTPM que nadie va a volver a tocar.

En mi caso: fedora va a recibir la BIOS 3886. Y en vworker el TPM se queda como está, porque no hay otra opción, así que simplemente no le confío nada.

---

Fuentes: heise online (alemán), OpenNet (ruso), boletín AMD SB-7064, CERT/CC VU#431093.