Un poco sobre Secure Boot, la característica de seguridad que acompaña a UEFI

Hoy voy a exponer un poco sobre Secure Boot, la característica de seguridad que acompaña a UEFI y que fue y sigue siendo duramente criticada desde los círculos ajenos a Microsoft, y es que, si bien sobre el papel se supone que es un estándar, la forma en que fue impulsado por el gigante de Redmond fue vista por muchos como una forma de intentar expulsar a los sistemas operativos alternativos del mercado, empezado Linux y FreeBSD, que son los principales rivales de Windows en el espectro de los compatibles.

En lo que respecta a Secure Boot, nos encontramos con dos mundos que conviven con la característica de forma muy diferente. Por un lado tenemos a los usuarios de Windows, los cuales nunca han tenido que preocuparse por la compatibilidad debido a que Microsoft tiene de facto a todos los fabricantes de hardware a su servicio.

Por otro lado están los sistemas operativos alternativos, empezando por Linux. Aquí la postura en torno a Secure Boot se ha diluido y diversificado, hasta el extremo que la característica tiene en la actualidad hasta defensores. Simplificando, se puede decir que en estos momentos hay tres bandos: los que rechazan Secure Boot de plano, los que no se oponen al concepto pero sí a la forma en que está gestionado y los que lo han abrazado del todo.

El uso de Secure Boot en Linux no ha estado libre de polémica y de duras broncas, ya que en Ubuntu se descubrió que su implementación no era segura debido a que se saltaba la característica para iniciar, mientras que, dentro del desarrollo del propio kernel Linux, la inclusión del módulo Lockdown estuvo en el aire durante siete años debido a que los responsables no se ponían de acuerdo sobre si atarlo o no Secure Boot. Por si alguien lo pregunta, Linus Torvalds estaba en contra, mientras que Matthew Garret, creador de Lockdown, estaba a favor.

En los últimos tiempos se ha podido ver como systemd, que es básicamente el marco que establece la forma de funcionar de la mayoría de las principales distribuciones Linux, está avanzando en la adopción de los mecanismos de seguridad implementados a nivel de placa base, entre ellos el TPM requerido por Windows 11. ¿Veremos en un futuro a Linux requiriendo TPM para funcionar? Por ahora a la comunidad le sobra fuerza para impedir que eso suceda.

Como vemos, la salsa en torno a Secure Boot está fuera de Windows, y es que no hay mucho que contar cuando el sistema de Microsoft actúa aquí como un buen árbitro de fútbol. Si hace bien su trabajo no da de qué hablar (o escribir).

Qué es Secure Boot

Secure Boot es un estándar de seguridad desarrollado por miembros ligados a la industria del PC con el propósito de garantizar que el software ejecutado en una computadora es confiable para el fabricante.

Cuando el equipo es encendido, el firmware de la placa base comprueba la firma de cada pieza de software que se ejecuta en el equipo, incluyendo los drivers de firmware de UEFI, las aplicaciones de EFI y el sistema operativo. En caso de que la comprobación de las firmas se haga correctamente, el equipo terminará el proceso de arranque y el firmware dará control al sistema operativo.

Es importante tener en cuenta que Secure Boot no cifra el almacenamiento de los datos y es independiente de TPM, aunque sí es capaz de trabajar junto al módulo requerido por Windows 11. Básicamente, lo único que hace Secure Boot es asegurarse de que el software tiene la firma requerida para que su ejecución sea autorizada en el equipo.

Windows 8 y el impulso de UEFI

Microsoft sembró la discordia con Windows 8, el fallido sistema operativo convergente. Su característica más recordada es Modern UI, conocida como Metro en sus fases de desarrollo, que es una interfaz de tipo baldosas para el menú de Inicio que no gustó a casi nadie. Aquel rechazo, que limitó la difusión del sistema, hizo que Steve Sinofsky acabara fuera de Microsoft.

Otro aspecto polémico de Windows 8 fue la tienda de aplicaciones, la cual fue acusada de ser un intento de monopolizar la distribución de software a través de un canal totalmente controlado por Microsoft. Aquello hizo que muchos alzaran la voz, incluidos Valve y Epic Games. Quién diría que, años después, las dos empresas de videojuegos se convertirían en rivales encarnizados después de que la segunda pusiera en marcha su propia tienda en 2018.

Pero lo que realmente importa en esta entrada fue que Microsoft estableció como requisito a los OEM el uso de UEFI y la activación de Secure Boot si querían obtener el certificado para Windows 8. Aquel movimiento de Microsoft pilló a contrapié a casi todos los responsables de las distribuciones Linux, que no solo no contaban con soporte para un Secure Boot que se puede desactivar en la inmensa mayoría de las ocasiones, sino que tampoco eran capaces de arrancar sobre UEFI debido que GRUB, el gestor de arranque más usado en dicho sistema, no soportaba esa interfaz de firmware.

El requerimiento de UEFI y Secure Boot por parte de Microsoft fue el gran impulso para ambas tecnologías y le costó al gigante de Redmond una demanda que no prosperó, ya que los equipos x86 en los que Secure Boot no se puede desactivar no son comunes.

El paso del tiempo y la puesta a disposición de una clave de terceros de Secure Boot para Linux ha cambiado mucho el panorama en torno al sistema operativo de código abierto. Desde hace años existen distribuciones como Ubuntu y Fedora que ofrecen un buen soporte para Secure Boot, pero la característica de seguridad todavía tiene que ser inhabilitada en caso de usar una gráfica de NVIDIA con su driver oficial.

Sin embargo, y pese a la mejora del soporte en Linux, no son pocos los usuarios de dicho sistema que en la actualidad siguen pensando que UEFI y Secure Boot son dos tecnologías que están secuestradas por Microsoft y que solo responden a sus intereses. En consecuencia, lo primero que hacen para usar el sistema operativo de su elección sin barreras es inhabilitar Secure Boot.

A pesar de que las formas en que ha llegado UEFI son cuestionables, no todo lo aportado por la interfaz de firmware ha sido malo, ya que, entre otras cosas, ha servido para estandarizar la tabla de particiones GPT frente a la vetusta MBR, ha permitido mejorar la integración entre el sistema operativo y las placas base (o su firmware) y en Linux ha abierto la puerta a fwupd, un daemon que permite actualizar el firmware empleado por el hardware, desde ordenadores hasta periféricos, pero a pesar de que el soporte que ofrece va mejorando, son pocos los fabricantes que ofrecen soporte a través de él.

Matices entre UEFI y Secure Boot

La campaña contra Secure Boot se volvió también contra UEFI. Eso ha hecho que muchas personas crean que ambas cosas son lo mismo, pero la realidad es que la primera actúa como una característica de la segunda y además puede ser inhabilitada, mientras que la segunda debe ser soportada por el sistema operativo de manera forzada si no hay a disposición algún tipo de soporte legado.

Resumiendo mucho, UEFI (Unified Extensible Firmware Interface) es un conjunto de especificaciones escritas por UEFI Forum que define la arquitectura del firmware de la plataforma utilizada el arranque y su interfaz para interactuar con el sistema operativo. Fue creado con el objetivo de reemplazar las viejas BIOS, aunque manteniendo la compatibilidad al menos de forma temporal. La especificación original de EFI (Extensible Firmware Interface), que básicamente es el nombre anterior, fue desarrollada por Intel.

Lo que es Secure Boot ya lo he definido en apartados anteriores, así que limitaré a decir que es un mecanismo que se encarga de verificar la autenticidad y la legitimidad del software que se va a ejecutar en la computadora, empleando para ello un mecanismo de comprobación mediante firmas digitales.

Cómo funciona Secure Boot

El funcionamiento de Secure Boot es más fácil de explicar con un diagrama que con palabras. Una de las partes más importantes de la característica de seguridad son las bases de datos Allow DB (DB) y Disallow DB (DBX), que pueden ser traducidas como base de datos para permitir y base de datos para no permitir.

DB almacena los valores hash y las claves para los cargadores que son de confianza y las aplicaciones EFI que el firmware de la máquina permite cargar. Por su parte, DBX almacena las claves y los hashes revocados, comprometidos y no confiables. En caso de querer cargar un código firmado con una de las claves presentes en DBX o que el hash coincida con una entrada de DBX, la plataforma se encargará de provocar la detención del proceso de arranque.

El siguiente diagrama muestra el proceso que pasa Red Hat Enterprise Linux para cumplir con los distintos pasos y requerimientos de Secure Boot. Este esquema debería ser similar en cualquier otra distribución, sobre todo en aquellas que usan systemd.

En primer lugar se comprueba si el certificado público está presente en Allow DB, cosa que en caso de ser respondida de forma afirmativa permite pasar a la comprobación del cargador de arranque: GRUB 2. Si la firma del cargador de arranque es válida, se pasará a hacer lo mismo con el kernel (Linux), que en caso de arrojar otro resultado afirmativo deriva en el cumplimiento de la secuencia de Secure Boot y en el arranque del sistema. La lógica con Windows es esencialmente la misma, pero este diagrama de Red Hat muestra un ejemplo empleando componentes concretos en lugar de ofrecer una vista general y genérica.

Obviamente, nada de este proceso de comprobaciones se realiza en caso de que el usuario haya inhabilitado Secure Boot desde la configuración de su placa base, y esa es la mejor opción si uno quiere probar distribuciones Linux u otros sistemas operativos sobre UEFI sin más limitaciones que la necesidad de soportar dicha interfaz de firmware.

Cómo ver la configuración de Secure Boot en tu placa base

La configuración de Secure Boot, por lo general, es posible encontrarla en el apartado Seguridad/Security o Arranque/Boot. Dependiendo de la placa base, el usuario se puede encontrar configuraciones más genéricas u otras más orientadas a Windows, que es a fin de cuentas el sistema operativo para el que está fabricado más del 90% de los ordenadores del mundo.

Los equipos de sobremesa permiten la inhabilitación de Secure Boot de manera relativamente fácil y sin poner más obstáculos a los usuarios, pero cuando se trata de portátiles, o al menos así me ha pasado a mí con mi actual portátil Acer, la desactivación de la característica de seguridad requiere del establecimiento de una contraseña para acceder a la BIOS.

Conclusión

Como vemos, Secure Boot es una característica que sobre el papel aporta cosas positivas para los usuarios, pero a la hora de la verdad ha mostrado tener algunos agujeros que justifican al menos parcialmente los argumentos de sus detractores.

Nos guste o no, Secure Boot ha venido para quedarse, y esto se está viendo en cosas como su expansión por el IoT, sector que está totalmente dominado por Linux en general y Ubuntu en particular. Sin embargo, que su uso sea voluntario y que pueda desactivarse sigue siendo algo muy importante debido a que no todas la distribuciones soportan la característica de manera correcta, cosa a la que hay que sumar sistemas de perfil más underground como los derivados de Illumos.

Imagen de portada: Pexels y Pixabay