¿Qué es Secure Boot y por qué importa?
Secure Boot es un estándar de seguridad definido en la especificación UEFI (Unified Extensible Firmware Interface), desarrollado por el consorcio UEFI Forum con contribuciones de Intel, AMD, Microsoft y fabricantes OEM. No se trata de una restricción de software ni de una política comercial: es una raíz de confianza criptográfica (Root of Trust) anclada en el firmware de la placa base que garantiza que únicamente software firmado digitalmente y autorizado puede ejecutarse durante el proceso de arranque.
Secure Boot implementa un mecanismo de verificación de firma digital (PKI basado en RSA-2048/SHA-256 o superior) que actúa antes de que el sistema operativo tenga control del hardware. Su objetivo es prevenir los ataques de tipo bootkit, rootkit de pre-OS y firmware implant.
El problema que Secure Boot resuelve
Antes de su adopción masiva, existía una ventana de vulnerabilidad crítica: el intervalo entre que el firmware inicializaba el hardware y que el sistema operativo cargaba sus defensas. En este periodo, malware como TDL4, MBR Locker o Mebromi podía comprometer el sistema de forma invisible, cargándose antes que cualquier antivirus y persistiendo incluso tras reinstalaciones del SO.
⚠️ Sin Secure Boot
- El firmware ejecuta cualquier código encontrado en el MBR/EFI
- Un bootkit puede instalarse antes del OS y ser invisible
- Persistencia incluso después de formatear el disco
- No hay verificación de integridad del gestor de arranque
✅ Con Secure Boot
- Cada componente de arranque es verificado criptográficamente
- Las firmas son comprobadas contra una base de datos en firmware
- Un bootloader no firmado es rechazado antes de ejecutarse
- La cadena de confianza se extiende hasta el kernel del OS
Origen e historia
La especificación UEFI 2.3.1 Errata C (2012) formalizó Secure Boot, aunque las primeras implementaciones llegaron con Windows 8 (2012) y los sistemas basados en la arquitectura ARM de 64 bits. Desde entonces, se ha convertido en requisito obligatorio para la certificación Windows Hardware Compatibility y, con la llegada de Windows 11 en 2021, en un prerrequisito no negociable del sistema operativo.
La Cadena de Confianza: De Hardware a Kernel
Secure Boot implementa lo que se denomina una Cadena de Confianza (Chain of Trust): cada eslabón verifica la integridad del siguiente antes de cederle el control. Si cualquier verificación falla, el proceso se detiene y el sistema entra en modo de recuperación.
Si cualquier eslabón de la cadena no puede verificar criptográficamente al siguiente, el arranque se detiene. No hay excepciones ni formas de "saltar" un eslabón sin deshabilitar explícitamente Secure Boot desde la UEFI.
Jerarquía de Claves Criptográficas: PK, KEK, db y dbx
El corazón de Secure Boot es una infraestructura de clave pública (PKI) jerárquica almacenada en variables NVRAM del firmware UEFI, protegidas contra escritura una vez en modo "deployed". Cada variable tiene un propósito preciso y un nivel de acceso diferente.
Platform Key (PK)
La raíz absoluta de la jerarquía. Es la clave del propietario de la plataforma (normalmente el fabricante OEM). Existe una única PK por sistema. Su clave pública se almacena en firmware; la privada la custodia el fabricante bajo HSMs de nivel FIPS 140-2.
Función: Autoriza la modificación de las KEK. Sin PK válida, nadie puede alterar las claves de arranque desde el SO. Solo se puede cambiar desde la interfaz UEFI físicamente.
Key Exchange Key (KEK)
Intermediaria entre la PK y las bases de datos operacionales. Generalmente existen dos KEK por defecto: una de Microsoft Corporation y otra del fabricante OEM. La KEK autoriza a sus titulares a modificar las bases de datos db y dbx.
Ejemplo real: Microsoft usa su KEK para actualizar la dbx cuando revoca bootloaders comprometidos, sin necesidad de que el OEM intervenga.
Allowed Signatures (db)
La lista blanca de Secure Boot. Contiene certificados X.509 o hashes SHA-256 de binarios EFI que están autorizados a ejecutarse. Si el bootloader presenta una firma válida contra cualquier certificado de la db, el firmware lo ejecuta.
Contenido típico: Certificado de Microsoft UEFI CA 2011 (para Windows y Shim), certificado del OEM, posiblemente certificados de distribuciones Linux específicas.
Forbidden Signatures (dbx)
La lista negra de revocaciones. Contiene hashes de binarios conocidos como comprometidos o vulnerables. La verificación contra dbx tiene prioridad sobre la db: aunque un binario esté firmado con un certificado válido, si su hash aparece en dbx, es rechazado.
Caso real: La vulnerabilidad BootHole (CVE-2020-10713) afectó a GRUB2. Microsoft distribuyó actualizaciones de la dbx para bloquear las versiones vulnerables.
Variables UEFI adicionales
| Variable | Nombre completo | Contenido | Quién puede modificarla |
|---|---|---|---|
| PK | Platform Key | Un único certificado X.509 RSA-2048+ | Solo desde la UI UEFI (físicamente) |
| KEK | Key Exchange Key | Uno o más certificados X.509 | Firmado con clave privada de PK |
| db | Allowed Signatures DB | Certs X.509 y/o hashes EFI | Firmado con clave privada de KEK |
| dbx | Forbidden Signatures DB | Hashes de binarios revocados | Firmado con clave privada de KEK |
| dbt | Authorized Timestamps DB | Timestamps de autorización | Firmado con clave privada de KEK |
| dbr | Recovery Signatures DB | Binarios de recuperación | Firmado con clave privada de KEK |
# Ver todas las variables Secure Boot disponibles efi-readvar # Exportar la PK actual en formato PEM efi-readvar -v PK -o PK.esl # Ver el estado de Secure Boot con mokutil mokutil --sb-state # Listar hashes en la lista negra (dbx) efi-readvar -v dbx # Alternativa: leer directamente desde sysfs od -An -tx1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
Proceso de Boot Paso a Paso: Del Botón de Encendido al Kernel
El proceso de arranque con Secure Boot activo sigue una secuencia criptográficamente verificada. Veamos exactamente qué ocurre en cada microsegundo:
POST y carga del firmware UEFI
Al pulsar el botón de encendido, la CPU ejecuta el código almacenado en la ROM de firmware desde una dirección fija (0xFFFFFFF0 en x86). El UEFI realiza el Power-On Self-Test (POST): verifica RAM, inicializa controladores PCIe, almacenamiento NVMe/SATA y puertos USB. En esta fase, Secure Boot no ha intervenido aún — el código de firmware está en ROM inmutable.
Inicialización de Secure Boot y carga de variables
El firmware UEFI carga las variables criptográficas (PK, KEK, db, dbx) desde la NVRAM. Determina si Secure Boot está en modo Setup, User o si está desactivado. En modo User (el normal), las comprobaciones criptográficas son obligatorias.
Localización del EFI System Partition (ESP)
El firmware lee la tabla de particiones GPT del dispositivo de arranque (disco NVMe, SSD SATA, USB). Localiza la partición ESP (tipo GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B), formateada en FAT32. Dentro del ESP busca el archivo EFI loader, típicamente en \EFI\BOOT\BOOTX64.EFI o en una ruta almacenada en las variables de boot UEFI (BootXXXX).
Verificación criptográfica del bootloader (¡El núcleo de Secure Boot!)
Antes de ejecutar el archivo EFI, el firmware extrae su firma digital (almacenada en la tabla de Authenticode del PE/COFF). Calcula el hash SHA-256 del binario y comprueba primero si ese hash aparece en la dbx (revocado → RECHAZADO). Si no está revocado, verifica si la firma es válida contra algún certificado de la db. Si pasa ambas pruebas → ejecuta el bootloader.
Ejecución del bootloader y verificación del kernel
El bootloader (Windows Boot Manager, GRUB con Shim, systemd-boot...) se ejecuta. Con Secure Boot activo, el bootloader también está obligado a verificar criptográficamente cada componente adicional que carga: en Windows, verifica winload.efi, el kernel ntoskrnl.exe y todos los drivers de arranque. En Linux con Shim, GRUB verifica el kernel antes de ejecutarlo.
Transferencia de control al sistema operativo
Una vez verificada toda la cadena, el kernel toma el control exclusivo del hardware. En Windows, esto activa las protecciones adicionales como Early Launch Anti-Malware (ELAM), Virtualization-Based Security (VBS) y Hypervisor-Protected Code Integrity (HVCI), que dependen de la garantía que ofrece Secure Boot para funcionar correctamente.
El proceso de verificación criptográfica añade típicamente entre 50ms y 200ms al tiempo de arranque, una penalización mínima e imperceptible comparada con el beneficio de seguridad que proporciona.
# Verificar estado de Secure Boot en Windows Confirm-SecureBootUEFI # Ver detalle del estado de arranque seguro Get-SecureBootUEFI -Name "SecureBoot" # Ver la base de datos de firmas autorizadas (db) Get-SecureBootUEFI -Name "db" # Ver la política de Secure Boot actual Get-SecureBootPolicy # Estado de TPM (relacionado con arranque seguro) Get-Tpm
Guía Práctica: Gestión de Secure Boot en la UEFI
Acceder y gestionar Secure Boot requiere entrar a la interfaz UEFI del sistema. Los pasos varían ligeramente según el fabricante, pero la lógica es universal.
Cómo acceder a la UEFI
| Fabricante | Tecla de acceso | Ubicación de Secure Boot |
|---|---|---|
| ASUS | F2 o DEL | Boot → Secure Boot |
| MSI | DEL | Settings → Security → Secure Boot |
| Gigabyte | DEL | BIOS Features → Secure Boot |
| ASRock | F2 | Security → Secure Boot |
| HP | F10 o ESC | System Configuration → Boot Options |
| Dell | F2 | Secure Boot → Secure Boot Enable |
| Lenovo | F1 o F2 | Security → Secure Boot |
| Acer | F2 | Boot → Secure Boot |
| Surface | Volumen ↓ + Power | Security |
En Windows 11: Configuración → Sistema → Recuperación → Inicio avanzado → Reiniciar ahora → Solucionar problemas → Opciones avanzadas → Configuración de firmware UEFI → Reiniciar. Esto reinicia directamente en la UEFI sin necesidad de saber la tecla exacta.
Modos de Secure Boot
Setup Mode / Disabled
Sin verificaciones criptográficas. Cualquier bootloader puede ejecutarse. Necesario para instalar algunos sistemas operativos legacy o usar discos de rescate antiguos.
User Mode (Standard)
Configuración por defecto. Usa las claves precargadas por el OEM y Microsoft. Ideal para Windows y distribuciones Linux mainstream (Ubuntu, Fedora, openSUSE).
Custom / Advanced Mode
Permite al usuario gestionar sus propias claves PK, KEK, db y dbx. Necesario para firmar bootloaders personalizados, usar Arch Linux sin Shim, o implementar claves corporativas propias.
Pasar a Custom Mode y gestionar claves propias
Modificar o eliminar las claves de Secure Boot sin una copia de seguridad puede dejar el sistema sin arranque. Exporta siempre las claves actuales antes de proceder. Necesitarás un sistema de recuperación.
# Instalar herramientas necesarias (Debian/Ubuntu) sudo apt install efitools openssl sbsigntool # 1. Generar una PK propia (Platform Key) openssl req -newkey rsa:4096 -nodes -keyout PK.key \ -new -x509 -sha256 -days 3650 -out PK.crt \ -subj "/CN=My Platform Key/" # 2. Generar KEK propia openssl req -newkey rsa:4096 -nodes -keyout KEK.key \ -new -x509 -sha256 -days 3650 -out KEK.crt \ -subj "/CN=My Key Exchange Key/" # 3. Generar clave de firma de base de datos openssl req -newkey rsa:4096 -nodes -keyout db.key \ -new -x509 -sha256 -days 3650 -out db.crt \ -subj "/CN=My Signature Database Key/" # 4. Convertir a formato EFI Signature List cert-to-efi-sig-list -g "$(uuidgen)" PK.crt PK.esl cert-to-efi-sig-list -g "$(uuidgen)" KEK.crt KEK.esl cert-to-efi-sig-list -g "$(uuidgen)" db.crt db.esl # 5. Firmar las listas de firmas sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth sign-efi-sig-list -k PK.key -c PK.crt KEK KEK.esl KEK.auth sign-efi-sig-list -k KEK.key -c KEK.crt db db.esl db.auth # 6. Firmar un bootloader personalizado sbsign --key db.key --cert db.crt \ --output bootloader-signed.efi bootloader.efi
Soporte Multiplataforma: Windows y Linux
Secure Boot funciona de forma diferente según el sistema operativo. Entender estas diferencias es fundamental para administradores de sistemas y usuarios avanzados.
Windows 11 y los requisitos de arranque seguro
Windows 11 convirtió Secure Boot en un requisito de instalación obligatorio, junto con TPM 2.0. Esta decisión de Microsoft en 2021 generó controversia pero está justificada por la arquitectura de seguridad holística del sistema.
🔒 TPM 2.0 + Secure Boot
El TPM (Trusted Platform Module) y Secure Boot trabajan en sinergia. El TPM almacena mediciones de integridad del arranque (PCR — Platform Configuration Registers) que Secure Boot ayuda a garantizar. Juntos habilitan BitLocker sin PIN, Windows Hello y Credential Guard.
🛡️ VBS y HVCI
Virtualization-Based Security y Hypervisor-Protected Code Integrity requieren que Secure Boot esté activo para garantizar que el hipervisor Hyper-V se cargó en un entorno limpio. Sin esta garantía, VBS no puede confiar en su propio entorno de ejecución.
# Verificar todos los requisitos de Windows 11 $sb = Confirm-SecureBootUEFI $tpm = Get-Tpm $cpu = Get-WmiObject Win32_Processor Write-Host "Secure Boot: $sb" Write-Host "TPM Presente: $($tpm.TpmPresent)" Write-Host "TPM Activado: $($tpm.TpmActivated)" Write-Host "TPM Versión: $($tpm.ManufacturerVersionFull)" Write-Host "CPU: $($cpu.Name)" # Verificar si BitLocker usa TPM con Secure Boot manage-bde -status C: # Ver mediciones TPM del proceso de arranque Get-TpmEndorsementKeyInfo
Linux y el Shim Bootloader
El ecosistema Linux resolvió el problema de Secure Boot de forma elegante con el concepto del Shim bootloader: un pequeño cargador EFI firmado directamente por Microsoft que actúa de puente entre el firmware UEFI (que confía en Microsoft) y GRUB (que confía en la distribución Linux).
Firmware UEFI verifica Shim (firmado por Microsoft) → Shim verifica GRUB (firmado por la distribución) → GRUB verifica el Kernel (firmado por la distribución). Tres capas de verificación, todas transparentes al usuario.
¿Por qué Microsoft firma el Shim?
Microsoft gestiona el programa Windows Hardware Quality Lab (WHQL), que incluye el proceso de firma de Shim para distribuciones Linux. Canonical (Ubuntu), Red Hat (Fedora/RHEL), SUSE (openSUSE) y Debian tienen sus Shims firmados por Microsoft. Esto permite que estas distribuciones funcionen con Secure Boot sin que el usuario tenga que importar claves manualmente.
# Ver el estado de Secure Boot en Linux mokutil --sb-state # Verificar que el Shim está firmado por Microsoft sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi # Verificar firma del GRUB sbverify --list /boot/efi/EFI/ubuntu/grubx64.efi # Verificar firma del kernel sbverify --list /boot/vmlinuz-$(uname -r) # Ver los certificados MokList (Machine Owner Key) mokutil --list-enrolled # Ver el certificado de firma de Ubuntu openssl x509 -inform DER -in /boot/efi/EFI/ubuntu/shimx64.efi \ -noout -text 2>/dev/null | head -30
MOK Manager: Machine Owner Key
El MOK (Machine Owner Key) es el mecanismo que permite a usuarios de Linux importar claves de firma adicionales al proceso de verificación de Shim, sin necesidad de modificar las variables UEFI directamente. Es fundamental para kernels con módulos de terceros (como drivers de NVIDIA o VirtualBox).
Generar un par de claves MOK
Crea un certificado X.509 con OpenSSL que usarás para firmar módulos del kernel o drivers personalizados.
Importar la clave con mokutil
Usa mokutil --import tu-clave.der para encolar la importación. Requiere establecer una contraseña temporal de un solo uso.
Confirmar en MokManager
En el siguiente reinicio, Shim lanza MokManager (una UI de firmware) donde debes confirmar la importación introduciendo la contraseña. Esta confirmación física previene ataques remotos.
Firmar módulos con la clave MOK
Usa kmodsign sha512 tu-clave.key tu-clave.der modulo.ko para firmar módulos del kernel. El kernel los cargará sin errores de firma.
# 1. Generar par de claves MOK openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv \ -outform DER -out MOK.der -days 36500 -subj "/CN=My MOK/" \ -nodes # 2. Encolar importación de la clave pública sudo mokutil --import MOK.der # 3. Reiniciar — MokManager aparecerá automáticamente sudo reboot # 4. (Tras reiniciar) Verificar que la clave se importó mokutil --list-enrolled | grep -A 5 "My MOK" # 5. Firmar un módulo del kernel manualmente sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file \ sha512 MOK.priv MOK.der /lib/modules/$(uname -r)/updates/dkms/nvidia.ko # 6. Verificar la firma del módulo modinfo nvidia | grep -E "signer|sig_key"
Mitos sobre Secure Boot: Desmontando Falsas Creencias
Secure Boot es uno de los temas con más desinformación en el ámbito tecnológico. Aquí desmontamos los mitos más extendidos con argumentos técnicos sólidos.
Secure Boot impide instalar Linux — "Si activo Secure Boot, no puedo usar Linux ni instalar otros sistemas operativos."
Las principales distribuciones Linux (Ubuntu, Fedora, Debian, openSUSE, RHEL) tienen sus Shim firmados por Microsoft y funcionan perfectamente con Secure Boot activo. El mito proviene de distros de nicho sin Shim firmado.
Secure Boot ralentiza el PC — "Las verificaciones criptográficas añaden segundos al tiempo de arranque."
La penalización real medida es de 50-200ms, absolutamente imperceptible. Las operaciones RSA modernas sobre firmware dedicado son extremadamente rápidas. El tiempo de arranque está dominado por la inicialización de hardware, no por Secure Boot.
Es un sistema de control de Microsoft — "Secure Boot es un malware de Microsoft para que solo puedas usar Windows."
Secure Boot es un estándar abierto del UEFI Forum con contribuciones de AMD, Intel, ARM y docenas de fabricantes. Microsoft es uno de los firmantes de confianza, pero cualquier usuario puede gestionar sus propias claves en Custom Mode.
Secure Boot protege contra todos los malware — "Con Secure Boot activo mi sistema es invulnerable."
Secure Boot protege solo el proceso de arranque. No protege contra malware que se ejecuta dentro del OS (una vez que el kernel tiene el control), no es un antivirus ni reemplaza otras capas de seguridad.
Desactivar Secure Boot es necesario para overclocking o modding — "Para tweaks de BIOS avanzados hay que desactivarlo."
El overclocking, XMP/EXPO para RAM, ajuste de voltajes y curvas de ventiladores son completamente independientes de Secure Boot. No existe ninguna relación técnica entre estos conceptos.
Preguntas Frecuentes Avanzadas sobre Secure Boot
Respuestas detalladas a las preguntas más complejas y frecuentes sobre Secure Boot.
Cuando Secure Boot detecta un binario EFI que no supera la verificación criptográfica, el firmware UEFI detiene el proceso de arranque de inmediato y generalmente muestra un mensaje de error como "Security Violation" o "Secure Boot Violation". El sistema no continúa bajo ninguna circunstancia. El usuario verá normalmente las opciones de: (1) acceder a la UEFI para desactivar Secure Boot, (2) entrar en un modo de recuperación, o (3) arrancar desde un dispositivo alternativo verificado. En sistemas con protección adicional (como ASUS SecureROM o las implementaciones con TPM lockout), múltiples fallos pueden activar un contador de errores que bloquea temporalmente la configuración UEFI.
La recuperación depende del escenario: (1) Bootloader corrompido: Arranca desde un USB de instalación del OS (que tiene su propio Shim/bootloader firmado), ejecuta herramientas de reparación de arranque como bootrec /rebuildbcd en Windows o grub-install en Linux. (2) PK/KEK corrompidas: Accede a la UEFI físicamente y usa la opción "Restore to Factory Defaults" o "Reset Secure Boot Keys", que restaura las claves OEM originales desde una memoria protegida. (3) dbx demasiado restrictiva: Entra a la UEFI, deshabilita temporalmente Secure Boot, arranca el OS y elimina la entrada problemática de dbx con efi-updatevar. Nunca extraigas la batería de la placa base como solución, ya que las claves UEFI en sistemas modernos persisten en NVRAM independiente.
Secure Boot es preventivo: verifica y bloquea activamente la ejecución de código no autorizado. Measured Boot es descriptivo: registra criptográficamente (mediante hashes SHA-256 almacenados en los PCR del TPM) cada componente que se carga durante el arranque, sin bloquear nada. Measured Boot crea un log de integridad que puede ser enviado a un servidor remoto (Remote Attestation) para que un tercero verifique si el sistema arrancó en un estado confiable. Windows 11 usa ambos simultáneamente: Secure Boot previene la carga de código malicioso, y Measured Boot registra todo lo que ocurrió para auditoría posterior. La combinación es lo que permite funcionalidades como la atestación de dispositivos en Microsoft Entra ID.
BlackLotus (CVE-2022-21894, aka "baton drop") fue un bootkit UEFI que explotaba una vulnerabilidad de diseño en el manejo de políticas de Secure Boot en Windows: permitía a un atacante con privilegios de administrador instalar un bootloader antiguo y vulnerable que todavía no había sido añadido a la dbx. El atacante aprovechaba el hecho de que la revocación de bootloaders comprometidos no es instantánea: hay un periodo entre el descubrimiento de la vulnerabilidad y el momento en que Microsoft distribuye actualizaciones de la dbx. Microsoft parcheó esto con actualizaciones de la dbx en 2023, pero el caso demostró que la seguridad del ecosistema Secure Boot depende críticamente de mantener la dbx actualizada. La lección: Secure Boot es tan fuerte como la actualización de su lista de revocaciones.
Sí, y es la configuración recomendada. Un setup dual boot Windows 11 + Ubuntu/Fedora con Secure Boot activo funciona perfectamente. El gestor de arranque GRUB de Ubuntu/Fedora está cargado via Shim (firmado por Microsoft), por lo que el firmware UEFI lo verifica correctamente. El flujo es: Firmware verifica GRUB Shim de Ubuntu → GRUB muestra el menú con Windows y Linux → Al elegir Windows, GRUB cede el control a bootmgfw.efi (también verificado). La configuración más robusta es dejar que el instalador de la distribución Linux gestione GRUB automáticamente y no modificar manualmente la ESP.
Los bypass de Secure Boot son técnicas que permiten eludir las verificaciones criptográficas. Los principales vectores son: (1) Drivers o bootloaders firmados pero vulnerables (como el caso BootHole o BlackLotus): se mitigan manteniendo la dbx actualizada. (2) Vulnerabilidades en el propio firmware UEFI (memory corruption en el código de verificación): se mitigan con actualizaciones de firmware del fabricante. (3) Acceso físico a la UEFI: se mitiga con contraseña de administrador de UEFI y, en entornos corporativos, con BIOS Management. (4) Ataques de "rollback" que instalan versiones antiguas de componentes: se mitigan con Secure Boot combinado con TPM y políticas de anti-rollback. La capa de protección más efectiva contra todos estos es el conjunto Secure Boot + TPM 2.0 + UEFI password + Windows Defender Credential Guard.
Las máquinas virtuales modernas pueden emular un entorno UEFI con Secure Boot. VMware Workstation, VirtualBox, Hyper-V y QEMU/KVM soportan Secure Boot virtual: la VM tiene su propio firmware UEFI (generalmente OVMF en Linux) con sus propias claves. Desde la perspectiva del sistema operativo invitado, experimenta Secure Boot de forma idéntica a hardware real. Importante: el Secure Boot de la VM es independiente del Secure Boot del host — la VM puede tener Secure Boot desactivado aunque el host lo tenga activo, y viceversa. Para Windows 11 en VM, Hyper-V incluye un "Security Template" que activa automáticamente Secure Boot + TPM virtual, cumpliendo todos los requisitos del instalador.