Durante las últimas semanas muchos usuarios con placas base AM5 de GIGABYTE se encontraron con un problema, un bug totalmente desconcertante en las BIOS: cada vez que encendían el PC, Windows pedía la clave de recuperación de BitLocker. No era un fallo del SSD, ni de Microsoft, como se apuntó en un principio, ni tampoco de un ataque online. El origen del problema estaba en las BIOS recientes de GIGABYTE, ya que o bien la empresa, o bien AMD introdujeron un bug en UEFI en cómo interactuaban con el TPM y el registro PCR0.

Como bien sabemos, sobre todo después de la cantidad de problemas que tuvo Microsoft, BitLocker funciona apoyándose en el TPM (Trusted Platform Module), un chip de seguridad que verifica que el entorno de arranque no ha sido alterado en nuestro PC. Bien es cierto que las CPU actuales tienen fTPM, por lo que no hace falta dicho chip y la validación llega desde el procesador, y ahí está parte del problema con GIGABYTE y AMD.

GIGABYTE admite el bug en sus BIOS provocado, posiblemente, por AGESA 1.2.8.0 con BitLocker y TPM

Para que TPM o fTPM funcionen correctamente utilizan varios registros llamados PCR (Platform Configuration Registers). El más crítico en este caso es el PCR0, que almacena un hash con mediciones del firmware UEFI y de elementos clave del arranque, que uniéndolos a la validación de la CPU por AGESA, complicó todo en las placas base GIGABYTE para AM5.

Por lo tanto, si ese hash cambia, aunque sea mínimamente, BitLocker asume que algo en el entorno ha sido modificado y bloquea el acceso automático al disco cifrado.

El problema detectado, y confirmado por GIGABYTE más tarde, es que en varias BIOS con AGESA 1.2.8.0 el valor del PCR0 no permanecía constante entre arranques. No porque hubiese una manipulación real, sino porque la secuencia de inicialización del hardware variaba ligeramente, en especial cuando se utilizaba una dGPU y estaban activadas funciones LED o RGB.

Curioso cuanto menos. Evidentemente, y como vimos, muchos fabricantes de placas retiraron versiones de BIOS en sus modelos sin decir nada, para más tarde lanzarlas bajo la llamada AGESA 1.2.8.0 V2, porque la V1 fue un desastre para muchos, ahora vemos algunas consecuencias de aquello.

GIGABYTE soluciona el problema con nuevas BIOS/UEFI, en teoría, con AGESA 1.3.0.0

Poniéndonos un poco técnicos, la BIOS estaba midiendo estados dinámicos durante el POST, ya que si el orden de inicialización de la GPU dedicada, sea AMD, Intel o NVIDIA, o de los drivers de iluminación de la placa cambiaban mínimamente, el hash final del PCR0 también lo hacía. El TPM registraba una medición distinta en el registro y BitLocker interpretaba que el sistema había cambiado, pidiendo la nueva key y creando el pánico entre algunos usuarios.

El resultado era un bucle constante de petición de clave, incluso sin modificar nada en el PC, lo que volvió locos a los más conspiranoicos pensando que habían sido hackeados. GIGABYTE ya ha empezado a distribuir nuevas versiones de BIOS que corrigen este comportamiento. De hecho, en sus notas de actualización de los firmwares en las webs de cada modelo de placa base para AM5 mencionan explícitamente mejoras de compatibilidad con BitLocker cuando se usa una dGPU y funciones LED.

Eso implica que han estabilizado el proceso de medición, o han eliminado del cálculo elementos no deterministas, aunque tampoco lo han especificado como tal. Además, se espera que AGESA 1.3.0.0 termine de normalizar este flujo a nivel más profundo dentro del firmware AMD.

La solución actual pasa simplemente por actualizar a la BIOS/UEFI más reciente disponible para cada modelo, aunque como medida preventiva, siempre es recomendable suspender temporalmente BitLocker antes de actualizar firmware. Sea como fuere, por suerte GIGABYTE ha corregido este bug en sus nuevas BIOS y BitLocker ya no será un problema para los afectados con Windows.