Configurar Secure Boot con llaves propias PK, KEK y db

Configurar Secure Boot con llaves propias (PK, KEK y db) es una de esas tareas que suenan a cosa de laboratorio de seguridad, pero que cada vez afecta más al usuario avanzado, a administradores de sistemas y a OEM que montan y venden equipos. Secure Boot ya no es una rareza: viene activado por defecto en la mayoría de placas modernas y es requisito para sistemas como Windows 11, distribuciones Linux firmadas y muchas soluciones industriales.

Si quieres controlar tú las claves de arranque seguro (en vez de conformarte con las que pone el fabricante), arrancar Linux, macOS con OpenCore o firmware propio sin perder compatibilidad con Windows, necesitas entender bien cómo funcionan la PK, la KEK, las bases de datos db/dbx y qué papel juegan herramientas como HSM, TPM o MOK. Vamos a verlo con calma, bajando a detalle técnico, pero con un lenguaje directo y práctico.

Qué es UEFI Secure Boot y por qué te interesa

UEFI Secure Boot es una extensión del estándar UEFI que define un mecanismo de verificación criptográfica de todos los binarios que participan en la cadena de arranque: firmware, ROM de opción, drivers UEFI en disco, aplicaciones UEFI y cargadores de sistema operativo. La idea es sencilla: antes de ejecutar nada, el firmware comprueba que esté firmado con una clave de confianza.

Para ello, Secure Boot se apoya en una infraestructura de clave pública (PKI): hay claves privadas que firman binarios y claves/certificados públicos almacenados en el firmware que verifican esas firmas. Si algo no cuadra, no se ejecuta. Esto reduce muchísimo el riesgo de rootkits y malware de prearranque, que tradicionalmente se metían justo antes del sistema operativo para esquivar antivirus.

En el ecosistema Windows moderno, especialmente desde Windows 8 y reforzado en Windows 10 y Windows 11, Microsoft usa esta arquitectura de Secure Boot como base de su cadena de arranque de confianza: firmware → Boot Manager → WinLoad → kernel → controladores críticos → antimalware. Cada eslabón verifica al siguiente usando firmas.

En el arranque típico con Secure Boot activado, el flujo es: el firmware UEFI valida el cargador del sistema operativo (por ejemplo, el Windows Boot Manager firmado por Microsoft); después, los componentes de arranque de Windows validan los controladores críticos de arranque y software antimalware marcado como tal; a partir de ahí continúa la inicialización normal del sistema operativo hasta la pantalla de inicio de sesión.

Para el usuario final esto se traduce en que el equipo no arrancará desde un USB o partición que no esté firmada correctamente, y para OEM/administradores supone tener que gestionar certificados, revocaciones (dbx) y compatibilidad con varios sistemas operativos sin perder seguridad.

PKI, criptografía de clave pública y tipos de certificados usados en Secure Boot

La base de todo esto es una PKI (Public Key Infrastructure), es decir, un conjunto de procesos, entidades y herramientas que permiten emitir certificados, comprobar identidades y revocar claves comprometidas. En el contexto de Secure Boot, la PKI sirve para:

• Verificar durante el arranque si una imagen UEFI (driver, aplicación, bootloader) es de confianza antes de ejecutarla.
• Autenticar cambios en las variables seguras (PK, KEK, db, dbx) y las actualizaciones de firmware, de forma que solo actores autorizados puedan modificarlas.

En una PKI típica para arranque seguro intervienen varios componentes: una autoridad de certificación (CA) que emite y firma certificados, una entidad de registro que verifica la identidad de quien pide el certificado, un directorio donde se almacenan claves y certificados y sistemas de administración que gestionan su ciclo de vida.

La criptografía que se usa en Secure Boot se basa normalmente en RSA‑2048 con SHA‑256. Se generan pares de claves asimétricas: una clave privada para firmar y una clave pública que se inserta en certificados X.509 o en estructuras específicas UEFI. Con una clave no puedes calcular la otra de forma práctica, así que mientras la privada esté protegida, el esquema es seguro.

Para Secure Boot se manejan varios conceptos clave:

• Certificado autofirmado: certificado cuya firma se realiza con su propia clave privada. Es lo habitual para las CA raíz (la raíz de confianza).
• Certificados emitidos por CA: la CA firma certificados de entidades (OEM, Microsoft, etc.), enlazando su identidad con una clave pública. Ahí se construyen las cadenas de certificados, donde puedes tener una raíz, uno o varios intermedios y el certificado final de firma.
• Certificados X.509: formato estándar que incluye DN, clave pública, algoritmo de firma, número de serie, emisor, sujeto y firma de la CA. En Secure Boot se usan con tipos como EFI_CERT_X509_GUID.

En UEFI Secure Boot se recomiendan claves públicas de al menos 2048 bits y certificados X.509 firmados con sha256RSA. Los certificados de Microsoft (por ejemplo, las CA UEFI 2011 y 2023, los KEK y los certificados de drivers UEFI) siguen este patrón y se distribuyen para que los OEM los inserten en las bases de datos de firma.

Claves y bases de datos de Secure Boot: PK, KEK, db y dbx

UEFI define una serie de variables seguras en NVRAM que componen la raíz de confianza del sistema: la Platform Key (PK), la Key Exchange Key (KEK) y las bases de datos de firma autorizada (db) y revocada (dbx). A nivel práctico, estas variables determinan qué se puede ejecutar, quién puede actualizar qué y cómo se pasa del modo de configuración al modo de usuario.

La clave de plataforma (PK) es el punto más alto de la jerarquía. La parte pública (PKpub) se inscribe en la variable PK del firmware; la parte privada (PKpriv) se mantiene fuera del equipo, idealmente en un HSM o al menos en un entorno extremadamente controlado. La PK establece la relación de confianza entre el propietario de la plataforma y el firmware: si controlas la PK, controlas quién puede cambiar la KEK, db y dbx.

Las claves de intercambio de claves (KEK) establecen la relación de confianza entre el sistema operativo (y otros actores) y el firmware. Cada sistema o proveedor puede inscribir una KEK pública (KEKpub) en la variable KEK. Con esa KEK se firman las actualizaciones de db y dbx. Microsoft, por ejemplo, distribuye su CA de Microsoft Corporation KEK 2K 2023, que los OEM deben incluir para permitir actualizaciones de revocación (dbx) y, si hace falta, cambios en la db.

La base de datos de firmas autorizadas db (EFI_IMAGE_SECURITY_DATABASE) contiene certificados, claves públicas y hashes de imágenes que el firmware puede cargar. Ahí entran, entre otras, la CA de UEFI de Windows 2023 (imprescindible para arrancar Windows) y, opcionalmente, las CA UEFI 2011, 2023 y de ROM de opción de Microsoft, así como CA de OEM o terceros que necesites (por ejemplo, para drivers UEFI propios o cargadores de Linux firmados por Microsoft UEFI CA 2023).

La base de datos de firmas prohibidas dbx (EFI_IMAGE_SIGNATURE_DATABASE1) mantiene una lista negra de hashes de binarios, claves y certificados revocados o vulnerables. Antes de comprobar db, el firmware mira dbx, y si encuentra una coincidencia, impide la ejecución de esa imagen. Windows requiere que exista una dbx, aunque inicialmente pueda contener un valor “dummy” (por ejemplo, el hash SHA‑256 de 0) hasta que lleguen las actualizaciones oficiales de Microsoft.

Además de estas variables principales, UEFI define DbDefault, DbxDefault y KEKDefault, donde el proveedor de la plataforma puede almacenar conjuntos de claves predeterminadas que se usan para restaurar la configuración de fábrica de Secure Boot desde la propia interfaz de firmware.

PK (Platform Key): generación, inscripción y estrategias de uso

Según la especificación UEFI (sección 27.5.1 en la versión 2.3.1 Errata C), la Platform Key es la que establece formalmente quién es el dueño de la máquina en términos de arranque seguro. Cuando inscribes una PKpub en la variable PK, el sistema sale de SetupMode (modo de configuración) y entra en modo usuario: a partir de ese momento, todas las modificaciones a las variables seguras exigen firmas válidas.

La PK debe ser, idealmente, un certificado X.509 de tipo EFI_CERT_X509_GUID con algoritmo de clave pública RSA‑2048 y firma sha256RSA. También se puede usar el formato EFI_CERT_RSA2048_GUID si andas justo de espacio en NVRAM, pero pierdes la flexibilidad adicional de X.509. Lo importante es que la clave privada de la PK esté extremadamente bien protegida, preferiblemente en HSM, y jamás se use de forma rutinaria para operaciones de firma de firmware o mantenimiento.

En cuanto a la estrategia de generación, hay varias opciones y cada una tiene implicaciones de seguridad y operativas:

1. Una PK por equipo: máxima granularidad y seguridad (pensada para gobiernos, banca, entornos de alta seguridad). Si una clave se compromete, solo afecta a una máquina, pero necesitas capacidad masiva de generación, almacenamiento y trazabilidad de claves.
2. Una PK por modelo: buen equilibrio para sobremesas y portátiles de consumo; si la clave se ve comprometida, afecta a todas las unidades de ese modelo.
3. Una PK por línea de producto: simplifica la gestión pero amplía el impacto de una posible brecha.
4. Una única PK por OEM: lo más sencillo de operar, pero un compromiso en la PK supone comprometer todo el parque de equipos, algo delicado a nivel reputacional y de soporte.

Microsoft ofrece una PK gestionada por ellos mismos para OEM que no quieran asumir la carga de proteger una PKproductiva. Esa PK se guarda en HSM de Microsoft siguiendo buenas prácticas de PKI y se considera la opción recomendada para gran parte del ecosistema Windows, siempre que no haya requisitos especiales de soberanía o segregación de claves.

La inscripción y actualización de PK se hace a través del servicio UEFI SetVariable(), usando la variable EFI_GLOBAL_VARIABLE correspondiente. Si el sistema está en SetupMode, puedes inscribir una nueva PKpub sin firma previa (aunque se construye internamente una estructura autenticada); si está en modo usuario, la nueva PKpub debe estar firmada con la PKpriv actual. Para borrar la PK, se escribe la variable PK con tamaño 0; en SetupMode no hace falta firma, en modo usuario debe ir firmada con la PKpriv vigente.

Desde el punto de vista operativo, es muy peligroso usar la PK de producción para firmar paquetes que borren la PK o restauren el sistema a SetupMode, porque eso permitiría a malware con acceso al sistema desactivar Secure Boot por software. Este tipo de operaciones se suelen limitar a entornos de prueba o a procedimientos muy controlados.

Si una PK se ve comprometida o un cliente quiere reasignar la propiedad de la plataforma (por ejemplo, una administración que quiere usar sus propias claves), puedes regenerar PK para un equipo, un modelo o toda una línea, según la estrategia elegida. La actualización se hace mediante variables autenticadas o paquetes de actualización de firmware firmados con la clave de actualización de firmware segura, cuidando de no perder KEK, db y dbx ya inscritos.

KEK, db y dbx: cómo se gestionan y cómo se combinan con claves de Microsoft y de terceros

La variable KEK contiene una lista de claves (generalmente certificados X.509) autorizadas para actualizar db y dbx. Cuando la plataforma está en modo usuario, cualquier cambio en esas bases de datos debe ir envuelto en una estructura de autenticación firmada por una de las KEK presentes. Esto permite, por ejemplo, que Microsoft publique actualizaciones de revocación (dbx) a través de Windows Update sin que el OEM tenga que intervenir en cada caso.

Para inscribir nuevas KEK puedes usar SetVariable() con el atributo EFI_VARIABLE_APPEND_WRITE, o leer la base de datos actual con GetVariable(), añadir la nueva entrada y volver a escribirla sin ese atributo. En SetupMode no hace falta firma, en modo usuario la estructura debe estar firmada con la PKpriv actual.

Borrar KEK también es posible, pero hay que tener cuidado: si no hay PK instalada, las peticiones de borrado no necesitan firma; si hay PK, borrar KEK exige un paquete firmado por PK, y modificar db/dbx requiere un paquete firmado por una de las KEK restantes. Desde el punto de vista de compatibilidad con Windows, se exige incluir en KEK al menos la CA de Microsoft Corporation KEK 2K 2023, que Microsoft publica para los OEM.

La db es la base de datos de firmas permitidas. Contiene las CA que firman cargadores de sistema operativo (como la Windows UEFI CA 2023), certificados de drivers UEFI (Microsoft UEFI CA 2011/2023, Option ROM UEFI CA 2023) y, opcionalmente, certificados de OEM y terceros. En sistemas que deben arrancar solo Windows, se puede enviar una db más estricta; en equipos que deban soportar Linux, ROM de opción de terceros o aplicaciones UEFI adicionales, se recomienda incluir todas las CA de Microsoft relevantes y, si procede, una CA UEFI del OEM.

La dbx lista hashes de binarios, certificados y claves que ya no son de confianza (por vulnerabilidades, robo de claves, etc.). El firmware siempre da prioridad a dbx: si una imagen coincide con algo en dbx, queda bloqueada aunque también aparezca como permitida en db. Microsoft distribuye periódicamente paquetes de dbx con revocaciones nuevas, y los requisitos de certificación de hardware de Windows exigen que haya una dbx presente desde fábrica (aunque sea con un valor placeholder hasta la primera actualización).

En los requisitos para dispositivos con Windows 11 25H2 precargado se marca como obligatorio que los OEM aprovisionen:

• PK: PK de OEM o PK gestionada por Microsoft.
• KEK: CA de Microsoft Corporation KEK 2K 2023.
• db: al menos la CA de UEFI de Windows 2023; para dispositivos que también soportan Linux u otros, se añaden Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 y Microsoft Option ROM UEFI CA 2023.
• dbx: el paquete de dbx más reciente proporcionado por Microsoft.

Claves de actualización de firmware seguro y flujo de actualización UEFI

Además de PK, KEK, db y dbx, las plataformas que siguen las recomendaciones de seguridad modernas tienen una clave de actualización de firmware seguro distinta, usada únicamente para firmar cápsulas de actualización de firmware. Su parte pública (o un hash) se almacena en una zona protegida: flash protegida en PCs clásicos o fusibles OTP en SoC.

La idea es que todas las actualizaciones de firmware que modifiquen el contenido de la flash UEFI deben ir firmadas con esta clave o con una que encadene a ella. El firmware, al recibir la cápsula a través de UpdateCapsule(), verifica la firma usando su clave pública interna; si la verificación falla, la actualización se descarta. Esto está alineado con las directrices de NIST 800‑147 sobre actualización segura de firmware.

En la práctica, se suele usar una clave de actualización por modelo o por línea de producto. Tener una clave por equipo, aunque teóricamente más seguro, complica muchísimo la logística: necesitarías generar y gestionar millones de paquetes de actualización únicos. Separar la clave de actualización de la PK es crítico: si usas la misma y se ve comprometida, no solo pierdes el control de las variables seguras sino también la capacidad fiable de actualizar la PK en equipos en producción.

En Windows, las actualizaciones de firmware UEFI se distribuyen normalmente como controladores de firmware que el sistema añade a su almacén y aplica mediante UpdateCapsule() durante el arranque. El firmware debe exponer la tabla ACPI ESRT para que Windows sepa qué dispositivos son actualizables y cómo. Las cápsulas pueden residir en memoria (escenario habitual) o en disco.

El flujo típico de una actualización de firmware con soporte UEFI moderno sería: descargar e instalar el paquete de firmware en Windows, reiniciar, el bootloader detecta la cápsula y la pasa a UpdateCapsule(), el firmware verifica la firma y aplica la actualización, se reinicia de nuevo y el sistema operativo termina de arrancar ya con la nueva versión.

Soluciones para generar y custodiar llaves: HSM, TPM, tarjetas inteligentes y alternativas

Para gestionar las claves de Secure Boot de forma profesional (PK, KEK de OEM, claves de firmware, etc.) no basta con guardarlas en un USB en un cajón. Lo recomendable es usar un HSM (Hardware Security Module), un dispositivo diseñado para generar, almacenar y usar claves de forma segura, muchas veces con certificaciones FIPS 140‑2 nivel 3.

Los HSM pueden estar en red o conectados localmente (PCIe, USB, PCMCIA). Un HSM de red es la opción más completa: múltiples servidores pueden acceder a él, se puede configurar alta disponibilidad, permite copias de seguridad encriptadas de claves y normalmente integra autenticación fuerte de múltiples operadores (esquemas “k de m”, por ejemplo, 3 de 5 tokens deben estar presentes para acceder a ciertas operaciones).

Los HSM independientes (tarjeta PCIe, dongle USB) funcionan bien en entornos más pequeños o aislados, a menudo integrándose con APIs como CAPI o CNG de Microsoft. Pueden ofrecer copia de seguridad y alta disponibilidad limitadas, pero siguen siendo muy superiores a soluciones puramente software.

Como alternativas de menor nivel tienes el TPM (Trusted Platform Module), que puede generar y almacenar claves y es muy útil para cifrado de disco completo (BitLocker), integridad de arranque medido, etc. Sin embargo, para un entorno de fabricación masivo, los TPM suelen carecer de la velocidad de procesamiento criptográfico y capacidad de almacenamiento de claves que ofrecen los HSM, además de no estar pensados para custodiar miles de claves de OEM.

También puedes usar tarjetas inteligentes o certificados de validación extendida (EV) almacenados en tokens hardware: proporcionan protección física y autenticación, pero su limitada capacidad de almacenamiento y rendimiento, junto con la necesidad de intervención manual, las hace poco adecuadas para plantas de fabricación o automatización de gran escala.

Finalmente, existen enfoques centrados en software (como el uso de APIs criptográficas de sistema operativo y contenedores de claves en discos cifrados o en máquinas virtuales aisladas), e incluso herramientas como makecert en entornos Windows antiguos. Aunque viables para pruebas o laboratorios, desde el punto de vista de seguridad no se recomiendan para gestionar PK y claves de firmware en producción porque amplían enormemente la superficie de ataque.

Estados de Secure Boot, SetupMode y ejemplo práctico de problemas con llaves propias

Un detalle fundamental cuando empiezas a configurar Secure Boot con llaves propias es entender la diferencia entre SetupMode y modo usuario. Mientras el sistema está en SetupMode (típicamente “Secure Boot: Disabled, SetupMode: 1”), todas las variables seguras se pueden modificar sin firma. En el momento en que inscribes una PK, SetupMode se pone a 0, SecureBoot a 1 y el firmware entra en modo usuario: a partir de ahí solo se aceptan modificaciones autenticadas.

Esto se aprecia con herramientas como bootctl o consultando directamente las variables en /sys/firmware/efi/efivars. Por ejemplo, un usuario con una placa ASRock B450M Pro4 y un Ryzen 5 2400G puede ver algo así en bootctl: firmware UEFI 2.70, Secure Boot habilitado, SetupMode en usuario y sin TPM2. Si intenta usar sbkeysync para insertar certificados de Microsoft en la db desde Linux, podría encontrarse con un error “Operación no permitida” al escribir en /sys/firmware/efi/efivars/db-..., precisamente porque ya no está en SetupMode y las claves que está intentando usar no coinciden con las que el firmware espera (PK/KEK actuales).

Muchos firmwares ofrecen desde su interfaz una serie de opciones de política de arranque seguro: usar claves de fábrica, cambiar a política personalizada, borrar todas las claves, borrar solo la PK o restaurar todas las claves a valores predeterminados, y opciones para modificar el logo de arranque UEFI. Borrar la PK suele devolver la máquina a SetupMode, pero algunos firmwares añaden protecciones adicionales (“La actualización de la variable segura está bloqueada”) y requieren secuencias concretas de reinicio o presencia física del usuario.

En esas mismas interfaces puedes ver el estado actual de Secure Boot (habilitado/deshabilitado), el modo (usuario/configuración) y acceder a menús de “Ver claves de arranque seguro” y “Política personalizada de arranque seguro” donde inspeccionar o manipular PK, KEK, db y dbx. Cada cambio significativo suele requerir reinicio para surtir efecto.

Este comportamiento es clave cuando, por ejemplo, ya has metido tus propias PK/KEK/db para arrancar una distro Linux firmada con tus claves y después quieres añadir los .auth de Microsoft para recuperar compatibilidad con el Windows Boot Manager: si ya no estás en SetupMode y tus paquetes .auth no están firmados con la PKpriv que conoce la placa, el firmware simplemente rechazará el cambio.

Secure Boot en Linux: shim, GRUB2, MOK y claves propias

En el mundo Linux, muchas distribuciones han tenido que adaptarse a Secure Boot para poder arrancar en hardware moderno sin pedir al usuario que desactive esta función en la BIOS. En openSUSE (y de forma similar en otras distros), el arranque UEFI con Secure Boot combina varias piezas: shim, GRUB2, el kernel firmado y las MOK (Machine Owner Keys).

El firmware UEFI, que solo confía de serie en certificados de Microsoft (y en algunos casos del OEM), carga primero shim.efi, un pequeño bootloader firmado por Microsoft UEFI CA. Shim incluye incorporada la CA de la distribución (por ejemplo, openSUSE) y, opcionalmente, una base de datos MOK que el usuario puede gestionar. Shim valida GRUB2 (firmado con la CA de la distro), y GRUB2, a su vez, solo carga kernels firmados con esa misma CA o con claves MOK que se hayan añadido manualmente.

Para permitir kernels personalizados o drivers propios sin romper Secure Boot, Linux ofrece el mecanismo MokManager. Cuando shim intenta cargar un binario EFI cuya firma no reconoce, puede invocar MokManager para permitir al usuario importar un nuevo certificado en MOK. Es un proceso interactivo durante el arranque: seleccionas “Enroll key from disk”, apuntas a tu certificado DER, confirmas y, tras reiniciar, esa clave pasa a formar parte de MOK y shim dejará pasar binarios firmados con ella.

Si quieres rizar el rizo y arrancar Linux con Secure Boot sin depender de las claves de Microsoft, algunas guías recomiendan resetear las claves del firmware y cargar tus propias PK, KEK y db, incluyendo únicamente tu propia CA y, si lo necesitas, la CA de la distro (por ejemplo, shim-opensuse.der en la db). En hardware antiguo que no soporta múltiples firmas en un mismo binario EFI, a veces hay que quitar la firma adicional de openSUSE en shim y dejar solo la de Microsoft, o viceversa, usando herramientas como pesign.

Desde Linux también es posible consultar y manipular variables EFI directamente a través de /sys/firmware/efi/vars o consultando el estado de Secure Boot con comandos como od sobre la variable SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data. Cada firmware es un mundo, pero este acceso de bajo nivel es muy útil para depurar situaciones donde el menú de BIOS no es claro o tiene bugs.

Uso de WSL en Windows para generar claves y firmar OpenCore y otros binarios

Una situación cada vez más frecuente es la de usuarios que quieren arrancar macOS con OpenCore en una máquina PC manteniendo Secure Boot activado. Dado que el firmware suele confiar solo en Microsoft y, a veces, en el OEM, hay que crear claves propias, insertarlas en el firmware y firmar con ellas todos los binarios EFI de OpenCore (incluyendo drivers y herramientas), a la vez que se conservan las CA de Microsoft necesarias para que Windows siga arrancando.

En lugar de montar un Linux completo en un disco aparte o en una máquina virtual, una opción muy cómoda es usar WSL (Windows Subsystem for Linux) en Windows 10/11. Instalando Ubuntu desde Microsoft Store (o mediante wsl --install en PowerShell), obtienes un entorno Linux real bajo el capó, con soporte para herramientas como openssl, sbsigntool y efitools, con acceso directo al sistema de ficheros de Windows bajo /mnt/c, /mnt/d, etc.

Desde ese Ubuntu en WSL puedes crear una carpeta de trabajo, generar tres pares de claves (PK, KEK e ISK o similar) con openssl req -new -x509 -newkey rsa:2048 -sha256 -days ..., configurando nombres CN reconocibles y restringiendo permisos a las claves privadas con chmod 0600. Luego puedes descargar los certificados de Microsoft necesarios (Windows Production PCA 2011, UEFI driver signing CA, o las versiones más recientes) y convertirlos de DER a PEM.

Con cert-to-efi-sig-list generas las listas de firmas en formato ESL (una por cada certificado/clave), y después combinas las que quieras incluir en db en un único db.esl (por ejemplo, tu ISK.esl más las ESL de las CA de Microsoft). Usando sign-efi-sig-list creas los archivos .auth que luego el firmware aceptará para poblar PK, KEK y db: PK firmada consigo misma, KEK firmada por PK y db firmada por KEK.

El siguiente paso es firmar los binarios EFI de OpenCore con tu ISK: herramientas como sbsign permiten firmar cada .efi con --key ISK.key --cert ISK.pem, generando versiones firmadas que luego colocas en la estructura EFI/OC (OpenCore.efi, BOOTx64.efi, drivers, tools…). Hay scripts que automatizan este proceso, descargando automáticamente la versión actual de OpenCore, añadiendo drivers como HfsPlus.efi y firmando recursivamente todos los archivos .efi, dejando todo listo en una carpeta “Signed”.

Finalmente, copias tus PK.auth, KEK.auth y db.auth fuera de WSL (por ejemplo, a una partición FAT accesible desde el firmware), entras en la BIOS/UEFI de tu placa y, desde el menú de “clave personalizada de arranque seguro”, los inscribes en el orden correcto. Una vez hecho esto, el firmware confiará tanto en tus claves como en las CA de Microsoft incluidas en db, y podrás arrancar Windows, OpenCore y otros binarios EFI firmados con tus propias llaves sin desactivar Secure Boot.

Todo este proceso, que suena farragoso la primera vez, acaba resultando relativamente manejable cuando comprendes la jerarquía PK → KEK → db/dbx y dispones de las herramientas adecuadas en un entorno cómodo como WSL.

Requisitos de Windows para Secure Boot, pruebas HCK y comprobaciones desde el sistema

Desde el punto de vista de certificación, Microsoft define una serie de requisitos de hardware y firmware para que un dispositivo se considere compatible con Windows con Secure Boot. Entre ellos destacan: exponer una implementación de UEFI al menos 2.3.1 (sección 27 para Secure Boot), soportar variables autenticadas, contar con una PK y KEK válidas, tener una db con las CA de Windows necesarias y mantener una dbx actualizada contra reversión de firmware y binarios revocados.

Los OEM deben asegurarse de que el almacenamiento de variables seguras está aislado del sistema operativo y no puede modificarse silenciosamente desde software sin las firmas correspondientes. También se requiere que todos los componentes de firmware estén firmados (RSA‑2048 con SHA‑256) y que el sistema implemente mecanismos de protección contra downgrade (rollback) de firmware a versiones vulnerables.

Para validar una plataforma, Microsoft proporciona herramientas y pruebas en el Hardware Certification Kit (HCK). Hay pruebas automáticas y manuales para Secure Boot que verifican aspectos como que el arranque seguro esté realmente habilitado, que la PK no sea una clave de prueba conocida, que la KEK contenga la KEK de producción de Microsoft, que la db tenga la CA de producción de Windows, que dbx exista y que las variables de tamaño máximo (por ejemplo, de 32 KB) se pueden crear y borrar correctamente.

Además, existen cmdlets de PowerShell para inspeccionar y modificar variables de UEFI de forma autenticada: Confirm-SecureBootUEFI (indica si Secure Boot está ON), Get-SecureBootUEFI (lee variables), Set-SecureBootUEFI (escribe/anexa) y Format-SecureBootUEFI (crea estructuras EFI_SIGNATURE_LIST y EFI_VARIABLE_AUTHENTICATION_2). Desde el punto de vista de usuario avanzado, estas herramientas son muy útiles para comprobar si tu configuración de PK/KEK/db coincide con lo que esperas.

Si trabajas con Linux en dual boot, también puedes echar mano de msinfo32 en Windows para ver el “Estado de arranque seguro” y, como ya se ha comentado, consultar directamente variables como SecureBoot y SetupMode desde /sys/firmware/efi/vars o utilizar efibootmgr para manipular entradas del gestor de arranque EFI (crear, borrar o reordenar opciones de arranque como EFI\Microsoft\Boot\bootmgfw.efi o EFI\opensuse\grubx64.efi).

Vista en conjunto, la configuración de Secure Boot con llaves propias implica entender bien la jerarquía PKI de la plataforma, elegir la estrategia adecuada de generación y almacenamiento de claves (idealmente con HSM), combinar claves de Microsoft, OEM y terceros en db y KEK sin romper compatibilidad, y manejar con soltura las herramientas tanto de firmware como de sistema operativo (WSL, OpenSSL, efitools, sbkeysync, cmdlets de PowerShell). Una vez interiorizada esta lógica, resulta relativamente cómodo mantener equipos que arrancan Windows, Linux y hasta OpenCore con Secure Boot activado, minimizando el riesgo de malware de arranque y manteniendo el control real sobre quién puede tocar la cadena de confianza.