Gestión de claves Secure Boot en Windows y Linux

Si usas Secure Boot en equipos con Windows y Linux, la gestión de claves ya no es opcional: afecta a si el sistema arranca, si puedes actualizar el firmware con fwupd o las herramientas del fabricante y, en los próximos años, incluso a si tus máquinas seguirán aceptando los cargadores de arranque firmados con certificados antiguos de Microsoft.

El objetivo de este artículo es explicarte, con calma pero en profundidad, cómo funciona todo el ecosistema de claves y certificados de Secure Boot en plataformas UEFI modernas, qué papeles juegan PK, KEK, db y dbx, cómo se encaja esto con Windows, con las distribuciones Linux que tiran de shim y con el hardware OEM, y qué soluciones reales existen para generar, custodiar y renovar esas claves sin montar un caos en fábrica o en entornos profesionales.

Qué es Secure Boot y cómo encaja en UEFI, Windows y Linux

Secure Boot es una función de seguridad definida dentro del estándar UEFI, no un invento exclusivo de Microsoft. Nació como evolución del viejo BIOS para disponer de un mecanismo estándar que permita al firmware comprobar firmas criptográficas de los componentes que se cargan en el arranque: ROMs de opción, controladores UEFI, aplicaciones UEFI y, sobre todo, cargadores de sistemas operativos.

El truco está en que el firmware sólo ejecuta binarios cuya firma pueda verificar con claves de confianza almacenadas internamente. Eso reduce la superficie de ataque frente a malware de arranque (bootkits, rootkits) que se inyecta antes de que el sistema operativo y el antivirus tomen el control. Windows 8 introdujo este modelo como parte de su arquitectura de arranque seguro y desde entonces es requisito en equipos cliente de Windows modernos y Windows Server.

En el mundo Linux, Secure Boot tuvo una acogida más polémica porque muchas distribuciones no estaban preparadas para firmar correctamente GRUB y el kernel, y porque la mayor parte del ecosistema se apoya en la infraestructura de claves de Microsoft para arrancar en hardware de consumo. De ahí surge shim: un pequeño cargador firmado por Microsoft que, a su vez, verifica GRUB y el kernel con claves de la propia distro, y se gestiona con herramientas como MOK Manager.

Aunque Microsoft actúa como una de las autoridades de certificación relevantes para Secure Boot, el estándar da el control último al propietario de la máquina: en casi todas las placas x86 puedes gestionar la base de datos de claves, añadir las tuyas, borrar las de Microsoft o incluso arrancar con una PK completamente propia. La polémica viene más por la configuración por defecto y por los requisitos de certificación de Windows que por la tecnología en sí.

Criptografía de clave pública y PKI aplicadas al arranque seguro

Secure Boot se apoya completamente en la infraestructura de clave pública (PKI). Eso implica trabajar con pares de claves asimétricas (pública y privada), certificados X.509 y cadenas de certificación que establecen una raíz de confianza desde la entidad de certificación (CA) hasta los binarios que se ejecutan en el arranque.

En este modelo, la clave privada sirve para firmar y la pública para verificar. Si alguien compromete la clave privada, todo lo firmado con ella deja de ser confiable, y es obligatorio revocar el certificado asociado (añadiéndolo a dbx) para impedir que dispositivos sigan cargando binarios potencialmente maliciosos.

Los algoritmos recomendados para Secure Boot son RSA de al menos 2048 bits y firmas con SHA-256. El estándar UEFI define tipos de firma como EFI_CERT_X509_GUID (certificados X.509 completos) o EFI_CERT_RSA2048_GUID (clave pública en bruto o hash de la clave, para ahorrar espacio en firmware), y Windows alinea sus requisitos con este nivel de seguridad.

Un certificado digital típico contiene un nombre distintivo, la clave pública y la firma de la CA emisora. En los certificados raíz, esa firma es autofirmada (la CA se firma a sí misma), mientras que en certificados intermedios o de entidad final la firma procede de otra CA superior. Secure Boot aprovecha estas cadenas de certificación para permitir que una CA raíz confiable legitime muchas claves intermedias sin abarrotar el firmware de certificados.

En la práctica, en el arranque seguro convergen varias CA relevantes: por un lado el OEM (o sus delegados como el IBV o el ODM), y por otro Microsoft, con diferentes certificados para KEK, para la UEFI CA que firma el Boot Manager de Windows y para la UEFI CA que usa para firmar controladores UEFI de terceros y cargadores de otros sistemas operativos como Fedora o Ubuntu.

Raíz de confianza en UEFI: PK, KEK, db y dbx

La raíz de confianza de Secure Boot en UEFI se materializa en cuatro elementos clave: la Platform Key (PK), la Key Exchange Key (KEK), la base de datos de firmas permitidas (db) y la base de datos de firmas prohibidas o revocadas (dbx). Todas ellas se almacenan como variables UEFI autenticadas.

La Platform Key (PK) establece quién es el “dueño” de la plataforma a efectos de arranque seguro. Es un certificado, normalmente X.509 RSA-2048 con firma SHA-256, cuya parte pública (PKpub) se inscribe en el firmware durante la fabricación, sacando el sistema del modo de configuración y pasándolo al modo de usuario.

La parte privada de la PK (PKpriv) debe permanecer siempre fuera del dispositivo, bajo custodia extrema: se utiliza para firmar cualquier operación que cambie KEK, db o dbx en modo de usuario, y también para reemplazar la propia PK. Microsoft ofrece a los OEM la posibilidad de usar una PK gestionada por ellos, custodiada en HSM, lo que simplifica la gestión para fabricantes que no quieren montar una PKI completa.

La Key Exchange Key (KEK) actúa como vínculo de confianza entre el firmware y los sistemas operativos o aplicaciones que gestionan db y dbx. Cada sistema (Windows, Linux, OEM, tercero) puede inscribir su clave pública KEKpub en la variable KEK, de forma que cualquier actualización de db o dbx firmada con esa clave se acepte como legítima.

En equipos con Windows 11 actuales es obligatorio incluir al menos la CA “Microsoft Corporation KEK 2K 2023” en la variable KEK. Ese certificado permite a Microsoft distribuir actualizaciones de dbx (revocaciones de binarios vulnerables o certificados comprometidos) y, si es necesario, ajustar el contenido de db para admitir nuevos firmantes.

La base de datos db (_IMAGE_SECURITY_DATABASE) recoge las firmas que se consideran válidas para arrancar. Aquí se insertan certificados raíz como la “Windows UEFI CA 2023”, la “Microsoft UEFI CA 2023”, la “Microsoft Corporation UEFI CA 2011” o la “Microsoft UEFI Option ROM CA 2023”, así como posibles CA de OEM o hashes de binarios concretos.

dbx (EFI_IMAGE_SIGNATURE_DATABASE1) hace justo lo contrario: almacena certificados, claves o hashes explícitamente revocados. Cualquier coincidencia en dbx bloquea la ejecución del binario aunque su firma encaje con algo de db. Windows exige que exista siempre una dbx y distribuye regularmente paquetes de actualización con nuevas revocaciones, sobre todo al descubrir vulnerabilidades en bootloaders o drivers UEFI.

Requisitos de configuración Secure Boot en equipos Windows 11 y sistemas con Linux

Para dispositivos Windows 11 modernos, especialmente la versión 25H2, Microsoft marca una configuración mínima de Secure Boot UEFI. Los OEM deben preinstalar una PK (propia o de Microsoft), el KEK “Microsoft Corporation KEK 2K 2023”, la “Windows UEFI CA 2023” en db y el paquete de dbx más reciente en dbx.

En equipos pensados también para ejecutar Linux u otras aplicaciones UEFI de terceros, el contenido de db se amplía. Además de la Windows UEFI CA 2023, se recomienda incluir la Microsoft UEFI CA 2023, la Microsoft Corporation UEFI CA 2011 y la Microsoft UEFI Option ROM CA 2023 para que ROMs de opción, controladores UEFI externos y cargadores de otras plataformas arranquen sin obligar al usuario a trastear en el firmware.

Los OEM pueden incluir, si lo necesitan, una CA UEFI propia en db, por ejemplo para firmar drivers UEFI internos o cargadores especializados. Asimismo, las variables dbDefault, dbxDefault y KEKDefault permiten definir conjuntos predeterminados de claves y firmas que el firmware puede restaurar a valores de fábrica.

En el mundo Linux entra en juego otro factor: la caducidad de certificados de Microsoft. Las claves antiguas acabarán expirando por completo (el horizonte de septiembre de 2025 es especialmente relevante), y eso implica que cargadores firmados con esos certificados podrían dejar de arrancar, o que actualizaciones de firmware vía fwupd fallen si no se han instalado las nuevas KEK y CA de Microsoft.

Distribuciones como Ubuntu, Fedora y openSUSE, junto con sus variantes comerciales (RHEL, SLE), suelen llevar la delantera en compatibilidad con Secure Boot. Integran bien fwupd, GNOME Software o Discover para aplicar actualizaciones de claves con un par de clics y un reinicio, mientras que otras distros aún recomiendan directamente desactivar Secure Boot porque no firman correctamente GRUB o el kernel.

Escenarios típicos de uso y problemas frecuentes con Secure Boot

En un PC doméstico o de gaming, Secure Boot te protege de bootloaders maliciosos pero puede chocar con hardware antiguo o software sin firma válida. Es relativamente habitual tener que desactivarlo para arrancar un live USB de herramientas, alguna distro exótica o tarjetas gráficas viejas que no exponen ROMs UEFI firmadas.

En entornos profesionales o corporativos, tener Secure Boot activo y bien configurado es casi obligado. Muchos despliegues dependen de esta capa para reducir el riesgo de compromisos a bajo nivel y combinan su uso con TPM 2.0 y cifrado de disco completo (BitLocker en Windows, LUKS en Linux), sellando las claves de descifrado a la integridad del arranque.

Windows 11 ha endurecido más el panorama al exigir simultáneamente TPM 2.0 y Secure Boot como requisitos oficiales. Aunque existen instaladores modificados que rodean estas comprobaciones, quien quiera ir “por la vía soportada” tiene que asegurarse de que el firmware está en modo UEFI puro, con Secure Boot disponible y, de ser posible, activo.

Los videojuegos también se han subido al carro de Secure Boot como requisito indirecto en combinación con anticheat a nivel kernel. Títulos como Valorant, League of Legends, Battlefield 6 o Call of Duty: Black Ops 7 han llegado a exigir Windows con arranque seguro para que funcione su sistema anti trampas, dejando fuera a equipos antiguos sin UEFI o sin TPM.

En el ámbito Linux, Secure Boot es crítico en escenarios de arranque dual cifrado. Si tienes Windows y Linux compartiendo máquina y tu partición Linux está cifrada, siempre quedan algunos archivos sin cifrar (initramfs, cargador, shim/GRUB) que son atractivos para un atacante que comprometa Windows. Secure Boot, correctamente configurado, impide que ese atacante sustituya tu initramfs por uno que robe la passphrase, porque el firmware rechazaría un binario no firmado con una clave de confianza.

Cómo activar o desactivar Secure Boot de forma segura

Habilitar o deshabilitar Secure Boot siempre se hace desde el firmware UEFI del equipo, no desde el sistema operativo como tal, aunque Windows ofrece accesos directos para reiniciar directamente al menú de firmware.

Desde Windows 10 u 11, el camino más cómodo pasa por el menú de recuperación avanzado: entras en Configuración > Actualización y seguridad > Recuperación > Inicio avanzado, pulsas “Reiniciar ahora” y, tras el reinicio, eliges Solucionar problemas > Opciones avanzadas > Configuración de firmware UEFI. Desde ahí, el equipo se reinicia de nuevo pero entra directamente a la interfaz de la BIOS/UEFI.

Dentro de la UEFI, cada fabricante coloca la opción de Secure Boot en un sitio ligeramente distinto, por lo general en la pestaña “Boot” o en “Security”. Primero puede ser necesario establecer una contraseña de administrador para poder modificar ese parámetro, y después ya se puede cambiar entre Enabled/Disabled o borrar claves para retornar al modo de configuración.

Conviene recordar que desactivar Secure Boot tiene impacto real en la superficie de ataque. Abrirás la puerta a que se puedan ejecutar bootloaders, kernels o herramientas de diagnóstico sin firma verificada, lo que, si el equipo está expuesto a malware sofisticado, incrementa el riesgo de bootkits muy difíciles de detectar y limpiar.

En equipos comprados con Windows preinstalado, algunos fabricantes configuran Secure Boot de forma bastante restrictiva. En ciertos sobremesa y portátiles “cerrados”, el usuario tiene que deshabilitarlo sí o sí si quiere arrancar muchas distribuciones Linux que aún no soportan bien el modelo de firmas de Microsoft o que no ofrecen shim firmado.

Gestión de claves de Secure Boot en fabricación y entornos OEM

Cuando hablamos de OEM, ODM o integradores que fabrican equipos a gran escala, la gestión de claves pasa de ser un detalle técnico a convertirse en un proyecto de PKI completo. No basta con “generar un certificado” y ya está: hay que definir cuántas PK distintas habrá, dónde se guarda cada clave privada y durante cuántos años se van a poder emitir actualizaciones de firmware o cambiar KEK/db/dbx.

Las opciones típicas para la Platform Key (PK) van desde una por equipo hasta una única por OEM. Usar una PK por dispositivo maximiza el aislamiento (si una se compromete, sólo afecta a una máquina), pero es un infierno logístico y de almacenamiento. Una PK por modelo o por línea de producto suele ser el punto de equilibrio razonable, sobre todo en sobremesa y portátiles de consumo.

Además de la PK, los OEM necesitan claves específicas para firmar actualizaciones de firmware de forma segura. La llamada “clave de actualización de firmware seguro” suele estar grabada como clave pública o como hash en una zona protegida del dispositivo (flash protegida o fusibles en SoC), y todas las cápsulas de actualización se deben firmar con la clave privada correspondiente o con una que encadene a ella.

Toda esta operativa se ve reflejada en el flujo de Windows para actualizar firmware vía UEFI Capsule. Windows recopila las actualizaciones en su driver store, llama a la función UpdateCapsule() antes de ExitBootServices(), y el firmware valida la firma, comprueba la clave contra el hash almacenado y, si todo cuadra, flashea el nuevo firmware.

La clave de actualización de firmware nunca debería ser la misma que la PK. Si PKpriv se viese comprometida y se estuviera utilizando para firmar firmware, el atacante podría tanto deshabilitar Secure Boot como sustituir el firmware legítimo por uno modificado, bloqueando incluso la capacidad de recuperar la plataforma con una nueva PK.

Soluciones de administración de claves: HSM, TPM, software y otros

Para gestionar las claves de Secure Boot de forma seria, lo habitual es recurrir a módulos de seguridad de hardware (HSM). Son dispositivos certificados (FIPS 140-2 nivel 2 o 3 en muchos casos) diseñados para generar, almacenar y usar claves privadas sin exponerlas nunca en claro fuera del hardware.

Los HSM de red son la opción más robusta para fábricas o centros de datos: permiten alta disponibilidad, copias de seguridad seguras y acceso controlado desde varios servidores, además de ofrecer aceleración criptográfica para generar y firmar grandes volúmenes de certificados sin estrangular la línea de producción.

Los HSM independientes (USB, PCIe, PCMCIA) funcionan bien para escenarios más pequeños o para laboratorios. Pueden integrarse con las APIs criptográficas de Microsoft (CAPI, CNG) u otras, y algunos modelos ofrecen también mecanismos de backup y replicación, aunque no siempre al nivel de un HSM de red.

En todos estos casos, la autenticación fuerte es la piedra angular. Muchos HSM permiten esquemas de “k de m” tokens: por ejemplo, se generan 5 tarjetas criptográficas y se exige la presencia simultánea de 3 para poder desbloquear el acceso a determinadas claves. Así se reparte la responsabilidad entre varios roles (seguridad, operaciones, dirección) y se reduce el riesgo de abuso individual.

Existen alternativas menos potentes orientadas al hardware del propio PC, como el TPM o las tarjetas inteligentes. Un TPM puede generar y proteger claves para cifrado de disco y otras funciones, pero no suele tener la capacidad de procesamiento, ni el almacenamiento, ni las certificaciones necesarias para gestionar miles de PK o claves de firmware en fábrica.

Las tarjetas inteligentes y tokens USB con certificados EV comparten algunas propiedades con los HSM (claves no exportables, resistencia básica a manipulaciones), pero son incómodos para flujos automatizados en cadena de producción y carecen de la escalabilidad y las capacidades de alta disponibilidad que se requieren cuando hay que firmar imágenes de firmware continuamente.

Por último, están los enfoques puramente de software para la generación y almacenamiento de claves, que no son recomendables para entornos OEM. Herramientas como makecert o las APIs criptográficas estándar permiten crear certificados y guardarlos en discos cifrados o máquinas aisladas, pero el vector de ataque es muchísimo mayor y, salvo que se combinen con controles físicos extremos, el riesgo de fuga de claves crece de forma inasumible.

Generación, almacenamiento y recuperación de claves privadas

El espacio que ocupa una clave RSA-2048 es pequeño en términos absolutos (2048 bits), pero la clave está en el valor simbólico y en la gestión a largo plazo. Una PK o una clave de actualización de firmware podrían necesitar estar accesibles de forma segura durante una década o más, para atender incidentes o generar nuevas versiones de firmware.

La recomendación general es almacenar las claves privadas siempre en hardware dedicado, sea un HSM en datacenter o, en escenarios mucho más modestos, un token criptográfico custodio, y que las copias de seguridad se mantengan en ubicaciones físicas separadas, incluso en regiones geográficas distintas, para minimizar el impacto de desastres.

Los procesos de recuperación de clave deben estar tan bien definidos como los de generación. Puedes verte obligado a regenerar una PK porque un cliente de alta seguridad quiere inscribir la suya propia, porque se detecta una posible filtración o simplemente porque la política interna marca rotaciones periódicas (por ejemplo, cada X años siguiendo las directrices de la Federal Bridge CA).

En el caso de KEK y de las claves de actualización de firmware, la recuperación es aún más crítica. KEKpriv se usa para firmar nuevas versiones de db y dbx, y la clave “priv” de firmware firma las actualizaciones que se entregan a millones de dispositivos. Perder una de estas claves sin tener backup puede dejarte incapaz de revocar certificados comprometidos o de distribuir correcciones de seguridad.

La autenticación de alto nivel (FIPS 140-2 nivel 3) añade una capa adicional de protección en todo este proceso. Obliga a identificar de forma individual a cada operador que accede al módulo, a registrar sus acciones y a aplicar controles físicos (sellos, sensores de manipulación, borrado seguro ante intentos de intrusión) que reducen drásticamente el riesgo de robo silencioso de claves.

Secure Boot, firma de terceros y compatibilidad con Linux

Secure Boot, por sí solo, no es un mecanismo de DRM ni una jaula para impedir que instales Linux. Lo que hace es restringir qué binarios pueden ejecutarse en el arranque, y eso se puede utilizar de forma legítima para seguridad o de forma torpe si se configura de manera demasiado cerrada.

Las críticas típicas que lo pintan como herramienta de Microsoft para bloquear sistemas alternativos no se sostienen cuando se revisa la especificación UEFI. El usuario o administrador puede inscribir sus propias claves, borrar las de Microsoft, cambiar la PK o elegir que sólo se confíe en binarios firmados por su organización, algo que Debian y otras distribuciones documentan claramente en su propia documentación.

Lo que sí es cierto es que, a nivel práctico, muchas distros Linux han optado por apoyarse en la infraestructura de claves de Microsoft para facilitar la vida a los usuarios menos técnicos. Al usar shim firmado por la Microsoft UEFI CA 2011 o 2023, el firmware reconoce de inmediato el cargador de la distro sin necesidad de que el usuario toque PK, KEK o db a mano.

Microsoft ofrece además una CA específica para firmar controladores y aplicaciones UEFI de terceros. Cualquier fabricante de hardware o desarrollador que necesite que su ROM de opción o su driver UEFI arranque en hardware con Secure Boot puede someter sus binarios a ese proceso de firma y distribuirlos sabiendo que funcionarán en equipos que tengan la CA de Microsoft en db.

La parte menos agradable de este esquema es que las claves caducan y se revocan. Cuando un certificado raíz antiguo se aproxima a su fecha de caducidad, hay que reemplazarlo por uno nuevo y asegurarse de que todos los equipos han recibido las actualizaciones correspondientes vía KEK/db/dbx, o se corre el riesgo de que cosas como fwupd, ciertos cargadores o ROMs UEFI dejen de ser aceptados por el firmware.

Si usas arranque dual con Windows y Linux, o tienes despliegues de Linux con Secure Boot activo, te interesa revisar periódicamente las actualizaciones de claves publicadas por Microsoft y tu distribución. En muchas distros basta con aceptar los paquetes de actualización de firmas desde la tienda de software o el gestor de paquetes, reiniciar y dejar que el firmware aplique los cambios; en otras tendrás que tirar de línea de comandos y utilidades específicas.

Arranque dual Windows-Linux, particiones EFI y orden de arranque

Configurar un arranque dual limpio entre Windows y Linux exige entender un poco cómo interactúan UEFI, la partición EFI y el gestor de arranque GRUB, con Secure Boot en juego, es aún más importante no improvisar, y conviene revisar el proceso de arranque en sistemas UEFI.

Si ya tienes Windows instalado en modo UEFI con particionado GPT, lo primero es reducir la partición de Windows y reservar espacio sin asignar para Linux, desactivando antes cosas como el inicio rápido y BitLocker para evitar sorpresas al redimensionar. Es fundamental comprobar que existe una partición EFI (FAT32, unos cientos de MB) que ambos sistemas compartirán.

Al instalar Linux, lo recomendable es utilizar el particionado manual y respetar la partición EFI existente, montándola como /boot/efi en lugar de crear otra. A partir de ahí, se crean las particiones para /, /home y swap según necesidades, y se instala GRUB como gestor de arranque UEFI apuntando también a la partición EFI.

Si la distribución soporta Secure Boot, se instalará un shim y un GRUB firmados que el firmware aceptará sin más. Si no, puede que haya que desactivar temporalmente Secure Boot para completar la instalación, o bien inscribir manualmente certificados adicionales en db para que el firmware confíe en el cargador de Linux, y en caso de problemas de compatibilidad es habitual añadir parámetros de arranque al GRUB.

Después de la instalación, puede suceder que el sistema arranque directamente a Windows porque la entrada de arranque de GRUB no está priorizada. En ese caso, toca entrar en la UEFI y cambiar el orden de arranque o, desde Linux, usar efibootmgr para reordenar las entradas. Desde Windows también es posible jugar con bcdedit, bootrec y reagentc, pero es más limpio dejar que UEFI gestione las prioridades.

Con todo configurado y las claves bien gestionadas, se puede mantener un arranque dual robusto, con discos cifrados y Secure Boot activo, sin necesidad de estar habilitando y deshabilitando opciones cada vez que cambies de sistema ni renunciar a las ventajas de seguridad que aporta la arquitectura moderna UEFI-Secure Boot-TPM.

En definitiva, entender la gestión de claves de Secure Boot en Windows y Linux —desde PK y KEK hasta db/dbx, HSM, TPM y la convivencia con arranque dual— es lo que marca la diferencia entre un sistema caprichoso que deja de arrancar cuando caduca un certificado y una plataforma sólida, preparada para actualizaciones de firmware, nuevas distribuciones y requisitos de seguridad cada vez más exigentes sin perder el control sobre tus propios equipos.