La empresa de seguridad de software Binarly reveló en el pasado año 2023 que dispositivos de Acer, Dell, Gigabyte, así como de Intel y Supermicro tenían el sistema Secure Boot comprometido. La clave criptográfica que protegía esos modelos se filtró a finales del año 2022 en un repositorio público de GitHub. Cualquiera que la descargara podía saltarse la protección que brindaba Secure Boot.
Vale la pena destacar que, además de la filtración de 2022, Ars Technica también informó que más de 300 modelos más usaban 21 claves de plataforma marcadas como “NO ENVIAR” o “NO CONFIAR”. Estas 21 claves fueron suministradas por American Megatrends, Inc. (AMI) como claves de prueba para los fabricantes de placas base para personalizar su firmware UEFI. Eso quiere decir que, casi todos los fabricantes que trabajaron con AMI tenían una copia de estas claves, y son un secreto a voces de la industria que conocen cientos, si no miles, de personas. Parece que Secure Boot no es tan seguro y a continuación le comentamos todo al respecto.
Todo parece indicar que Secure Boot no es tan seguro
Es crucial señalar que, además de las 5 empresas afectadas por la clave filtrada en GitHub, los siguientes fabricantes también se vieron afectados por las claves de prueba: Aopen, Foremelife, así como también Fujitsu, HP e inclusive, Lenovo. Cabe aclarar que, el impacto generalizado de esta filtración de Secure Boot, podría ser tomado como un fracaso de toda la industria al momento de practicar una gestión apropiada de las claves criptográficas.
Hay diversos problemasrelacionados con la seguridad de la cadena de suministro:
- Primero que nada, la mala gestión de materiales criptográficos y así mismo, la aparición de las claves privadas directamente en los repositorios de código con la ruta codificada desde los scripts de compilación.
- De igual forma, uso de claves criptográficas que no sean de producción responsables de la seguridad de la plataforma de firmware y dispositivos de producción.
- No hay rotación de las claves criptográficas de seguridad de la plataforma por línea de productos. Por ejemplo, se corroboraron las mismas claves criptográficas en productos relacionados con el cliente y el servidor. Se detectó un comportamiento similar con la fuga de la clave del código de referencia de Intel Boot Guard. El mismo OEM usó las mismas claves criptográficas relacionadas con la seguridad de la plataforma para el firmware producido para diferentes fabricantes de dispositivos.
Lastimosamente, los usuarios individuales no tienen la capacidad de poder solucionar este problema si se ven afectados. A menos que el fabricante de la placa lance una actualización del BIOS, no es posible reparar un dispositivo con esta vulnerabilidad.
