Secure Boot + TPM: qué protegen (y qué no)

Comienza por el modelo de amenazas, no por la casilla

Secure Boot y el TPM a menudo se venden como “seguridad de arranque”. Eso es como vender “cinturones de seguridad”. Los cinturones de seguridad son geniales—contra problemas específicos. No hacen nada contra otros. Tu trabajo es elegir las características de seguridad correctas para el choque que realmente es probable que tengas.

Para qué sirve Secure Boot (en una frase)

Secure Boot trata sobre la aplicación: solo se permiten ejecutar componentes de arranque confiables (firmware → cargador de arranque → kernel), basándose en la verificación de firmas.

Para qué sirve el TPM (en una frase)

El TPM trata sobre secretos y evidencia: puede proteger claves y registrar mediciones del proceso de arranque (PCRs) para que puedas enlazar el acceso a estados “conocidos y buenos” o demostrar lo que ocurrió.

Amenazas realistas de arranque que puedes mitigar

• Ataques de “evil maid”: alguien obtiene acceso físico a un portátil o servidor apagado y manipula la cadena de arranque o se hace con las claves del disco.
• Persistencia por bootkit: malware que se instala por debajo del SO (bootloader, kernel temprano, initramfs) de modo que reimaginar “desde dentro del SO” no lo limpiará.
• Deriva de la imagen de suministro / golden image: un nodo arranca algo distinto de lo que construiste y quieres una forma criptográfica de detectarlo.
• Robo de credenciales por acceso offline al disco: un atacante roba un disco o una máquina completa e intenta leerlo en otro lugar.

Amenazas que estas características no solucionan por sí solas

• RCE remota en tu aplicación una vez que el SO está arriba.
• Exploits del kernel post-arranque que no requieren reemplazar la cadena de arranque.
• Insiders malintencionados con acceso de administrador que pueden firmar su propio malware si les permites controlar las claves de firma.
• Firmware vulnerable que miente felizmente sobre lo que verificó.

Una cita que vale la pena tener en la pared, porque previene proyectos sin sentido:

Idea parafraseada (Gene Kim): “Mejorar la fiabilidad trata sobre mejorar el sistema de trabajo, no sobre heroísmos durante las interrupciones.”

Secure Boot y TPM son mejoras del sistema de trabajo cuando las operacionalizas: gestión de claves, flujos de actualización, comprobaciones de atestación y procedimientos de acceso de emergencia. Si tu plan es “actívalo y espera”, eso no es un plan. Es un informe de incidente futuro.

Secure Boot: qué aplica

UEFI Secure Boot es una aplicación de firmas a nivel de firmware. El firmware solo ejecutará binarios EFI que estén firmados por una clave en la que confía. Eso es el núcleo. Todo lo demás—shim, MOK, herramientas de las distribuciones—es la plomería para que esto funcione en la vida real.

La cadena de confianza, concretamente

Una cadena típica de Linux en hardware comercial se ve así:

• Firmware UEFI contiene claves de confianza y la lógica de verificación.
• shim es un pequeño cargador de arranque firmado habitualmente por una clave ampliamente confiable y puede cargar claves adicionales.
• GRUB/systemd-boot es cargado por shim y puede verificar el kernel y el initramfs.
• Kernel carga módulos; la aplicación de firmas de módulos es un control separado.
• initramfs levanta el almacenamiento y monta la raíz; si esto no es confiable, puedes perder todo antes de que arranque tu “OS real”.

El valor de Secure Boot es simple: evita que un componente EFI sin firmar (o mal firmado) se ejecute. Eso bloquea una clase de bootkits e intentos de manipulación. También te impedirá dormir a las 2 a.m. si tu flujo de firma es descuidado.

Claves con las que te encontrarás (y que debes respetar)

• PK (Platform Key): clave de nivel superior que controla la configuración de Secure Boot.
• KEK (Key Exchange Key): autoriza actualizaciones a las bases de datos de firmas.
• db: firmas/hashes permitidos.
• dbx: firmas/hashes revocados (la “lista de no”).
• MOK (Machine Owner Key): lista de claves gestionada por shim usada comúnmente para permitir kernels/módulos personalizados sin reemplazar las claves de plataforma.

Si solo recuerdas una regla operativa: trata las claves de firma como credenciales de base de datos de producción. Si se filtra tu clave de firma, “Secure Boot habilitado” se convierte en “Secure Boot habilita persistencia para los atacantes”.

Broma #1: Secure Boot es como un portero con una libreta—muy eficaz hasta que repartes pulseras fotocopiadas en el estacionamiento.

TPM: qué mide, almacena y se niega a olvidar

El TPM (Trusted Platform Module) es un componente resistente a manipulaciones (chip o con respaldo por firmware) diseñado para hacer muy bien unas pocas cosas: proteger claves, producir pruebas criptográficas y registrar mediciones del arranque temprano en PCRs (Platform Configuration Registers).

Fundamentos de TPM 2.0 que importan en operaciones

• PCRs: registros especiales que registran una cadena de hashes de mediciones. No “pones” PCRs; los extiendes, lo que significa PCR = HASH(PCR || nueva_medición). Esto hace que el historial sea pegajoso.
• Sellado (Sealing): cifrar (envolver) un secreto para que el TPM solo lo libere si la máquina está en un estado específico (definido por valores PCR).
• Atestación: producir una declaración firmada sobre los valores PCR (y a veces registros de eventos), para que una parte remota pueda verificar el estado de arranque.
• Claves de respaldo e identidad: claves que permiten al TPM demostrar que es un TPM genuino y luego hablar como una máquina en particular.

La trampa del “auto-desbloqueo TPM”

Usar el TPM para auto-desbloquear LUKS/BitLocker es común. También es donde la gente se quema, porque confunden comodidad con seguridad.

Si sellas una clave de disco a PCRs que miden el cargador de arranque y el kernel, fuerzas al atacante a mantener esos componentes intactos para obtener la clave. Si la sellas a un conjunto débil de PCRs—o peor, no usas vinculación a PCR en absoluto—puede que solo estés guardando la clave en una caja elegante que se abre cuando le apetece.

El TPM no es un “entorno seguro para todo” mágico

El TPM es bueno para secretos pequeños y pruebas. No es un acelerador criptográfico de alto rendimiento para tu base de datos. Tampoco sustituye parchear firmware, controlar el acceso administrativo o tener procesos a prueba de manipulación en la cadena de suministro.

Broma #2: Un TPM es una bóveda, no una niñera; no te impedirá dejar la puerta de la sala de servidores abierta.

Secure Boot vs Measured Boot: aplicación frente a evidencia

Estos dos se confunden porque ambos tratan sobre la integridad del arranque. Son herramientas diferentes con modos de falla distintos.

Secure Boot (aplicación)

• Pregunta que responde: “¿Debe permitirse ejecutar este binario?”
• Mecanismo: verificación de firmas contra claves permitidas (db) y revocaciones (dbx).
• Modo de falla: no arrancas.
• Dolor operativo: flujo de firmas, rotación de claves, revocaciones, controladores de terceros.

Measured Boot (evidencia)

• Pregunta que responde: “¿Qué se ejecutó?”
• Mecanismo: mediciones extendidas en PCRs + registro de eventos; luego atestadas.
• Modo de falla: puede que aún arranques, pero tu atestación falla o tus secretos sellados no se liberan.
• Dolor operativo: deriva de PCR debido a actualizaciones, cambios de firmware o cambios de configuración.

En la práctica, las plataformas robustas hacen ambas cosas: Secure Boot previene manipulaciones obvias; el arranque medido te da auditabilidad y confianza condicional para la liberación de claves.

Qué no protegen Secure Boot + TPM

Esta es la sección que evita gastar presupuesto mal. Si vas a invertir capital político en seguridad de arranque, asegúrate de no afirmar que arregla cosas que no arregla.

No detienen compromisos en tiempo de ejecución

Si un atacante obtiene ejecución de código en tu SO en ejecución y escala a root, Secure Boot no lo expulsará. El TPM no llamará a la policía. Aún necesitas endurecimiento del kernel, parches, principio de menor privilegio y monitoreo real.

No garantizan que el firmware sea honesto

Secure Boot y el arranque medido dependen de que el firmware se comporte correctamente. Si el firmware está comprometido, puede mentir sobre lo que verificó o midió. Por eso la higiene en actualizaciones de firmware no es opcional y por qué algunos entornos requieren raíces de confianza hardware más rutas de actualizaciones de firmware verificadas.

No protegen contra malware “autorizado”

Si tu organización firma un cargador de arranque malicioso con una clave confiable, Secure Boot lo arrancará sin problemas. Si un atacante roba tu clave de firma, tu capa de aplicación se convierte en su canal de distribución. Pon las claves de firma en procesos respaldados por HSM, controla su uso y registra cada evento de firma como si fuera un despliegue de producción.

No resuelven problemas de sesiones robadas

Secure Boot y TPM pueden ayudar a proteger claves de disco en reposo. No protegen una máquina ya desbloqueada de un atacante con sesión iniciada, agente SSH robado o sesión SSO comprometida. Amenaza distinta. Controles distintos.

No facilitan la recuperación

A menudo hacen la recuperación más difícil. Ese es el punto: estás aplicando integridad. Planea procedimientos de acceso de emergencia usando claves de recuperación, acceso por consola fuera de banda y procedimientos documentados para el enrolamiento de claves.

Hechos interesantes y contexto histórico (las partes que la gente olvida)

1. Secure Boot llegó a PCs UEFI convencionales a principios de los 2010, y de inmediato chocó con la realidad de que la gente instala sistemas operativos que no son los predeterminados de fábrica.
2. TPM 1.2 precede a TPM 2.0 por años; TPM 2.0 amplió algoritmos y flexibilidad, lo cual es genial hasta que intentas estandarizarlo en una flota heterogénea.
3. El arranque medido es anterior a muchas carreras cloud-native: el concepto de cadena de mediciones viene de investigaciones tempranas de computación confiable, no del marketing moderno DevSecOps.
4. La lista de revocación UEFI (dbx) es una palanca operativa real: puede dejar inservibles bootloaders antiguos tras una actualización si dependes de componentes revocados.
5. shim existe porque la realidad existe: es un compromiso práctico para permitir que las distros participen en los ecosistemas de Secure Boot sin que cada usuario gestione claves de plataforma desde el día uno.
6. La firma de módulos no es lo mismo que Secure Boot: incluso con Secure Boot activado, los módulos de kernel sin firmar pueden ser una vía de compromiso del kernel a menos que la aplicación de firmas de módulos esté configurada.
7. Los valores PCR cambian por razones aburridas, como una actualización de firmware, un cambio en el orden de arranque o alternar ciertas opciones UEFI. Eso no es “TPM inestable”, es la medición cumpliendo su función.
8. Existen TPMs virtuales (vTPM) y se usan ampliamente en pilas de virtualización; son útiles, pero tu confianza pasa al hipervisor y a su gestión de claves.

Tareas prácticas: comandos, significado de la salida y la decisión que tomas

Estos son los chequeos que ejecuto cuando alguien dice “Secure Boot está activado” o “el TPM está configurado”. No me interesan las vibras. Me interesa la evidencia.

Task 1: Verify Secure Boot state from Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: UEFI Secure Boot está habilitado y el kernel lo ve así.

Decisión: Si está deshabilitado en máquinas que deberían aplicar la integridad de arranque, corrige la política del firmware; si está habilitado en un equipo de desarrollo que necesita kernels no firmados, planifica MOK o perfiles separados.

Task 2: Confirm UEFI boot mode (UEFI vs legacy BIOS)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Qué significa: Secure Boot requiere modo UEFI; el modo legacy hace que toda esta conversación sea mayormente académica.

Decisión: Si ves “Legacy” en hardware que debería estar asegurado, tienes un problema de baseline de construcción/firmware.

Task 3: Inspect enrolled MOK keys (common in Linux fleets)

cr0x@server:~$ mokutil --list-enrolled | head
MokListRT:
  SHA1 Fingerprint: 12:34:56:78:90:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88
  Subject: CN=Corp Kernel Signing CA

Qué significa: shim confiará en binarios firmados por estas claves (según la configuración).

Decisión: Si no reconoces el sujeto, trátalo como una posible brecha de política. Si lo reconoces, asegúrate de que la clave privada esté controlada como un secreto de producción.

Task 4: Check whether the bootloader and kernel are signed (Debian/Ubuntu style)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Windows UEFI Driver Publisher
image signature certificates:
 - subject: /CN=Canonical Ltd. Secure Boot Signing

Qué significa: El binario EFI contiene una cadena de firma. La aplicación de Secure Boot solo es tan buena como lo que realmente ejecutas.

Decisión: Si el emisor de la firma es inesperado para tu entorno, puedes estar confiando en claves más amplias de lo que pretendías. Para entornos estrictos, usa tu propia estrategia PK/KEK/db.

Task 5: Verify kernel module signature enforcement status

cr0x@server:~$ cat /sys/module/module/parameters/sig_enforce
Y

Qué significa: El kernel requiere módulos firmados (según la configuración).

Decisión: Si “N” en sistemas expuestos a código no confiable, considera habilitarlo; si “Y” rompe drivers de proveedor, necesitas un flujo de firma de módulos limpio, no una excepción nocturna.

Task 6: Confirm TPM device presence

cr0x@server:~$ ls -l /dev/tpm* 2>/dev/null
crw------- 1 root root  10, 224 Feb  5 10:12 /dev/tpm0
crw------- 1 root root 253,   0 Feb  5 10:12 /dev/tpmrm0

Qué significa: El TPM está expuesto al SO. /dev/tpmrm0 es la interfaz del gestor de recursos (preferida por muchas herramientas).

Decisión: Si falta, revisa ajustes del BIOS/UEFI (TPM deshabilitado), controladores faltantes o configuración de VM (vTPM no adjunto).

Task 7: Read TPM capabilities to confirm TPM 2.0

cr0x@server:~$ tpm2_getcap properties-fixed | grep -E 'TPM2_PT_FAMILY_INDICATOR|TPM2_PT_MANUFACTURER'
  TPM2_PT_FAMILY_INDICATOR: "2.0"
  TPM2_PT_MANUFACTURER: "INTC"

Qué significa: Confirma familia del TPM y fabricante. Esto ayuda cuando depuras comportamientos inconsistentes entre revisiones de hardware.

Decisión: Si esperabas 2.0 pero ves otra cosa (o errores de herramientas), detente y estandariza hardware/firmware o ajusta las herramientas según corresponda.

Task 8: Dump current PCR values (snapshot)

cr0x@server:~$ tpm2_pcrread sha256:0,2,4,7
sha256:
  0 : 2F4A...9C11
  2 : A1B2...C3D4
  4 : 88EE...1020
  7 : 0D0C...BEEF

Qué significa: Las PCRs son hashes que representan el estado medido del arranque (según firmware y configuración). La PCR 7 suele asociarse con el estado de la política de Secure Boot en muchas plataformas.

Decisión: Usa estos valores para detectar deriva o enlazar secretos. Si la PCR 7 cambia inesperadamente tras actualizaciones, espera que los secretos sellados dejen de desbloquearse hasta que vuelvas a sellar o ajustes la política.

Task 9: Check IMA/EVM measurement logs (if enabled)

cr0x@server:~$ test -r /sys/kernel/security/ima/ascii_runtime_measurements && head -n 3 /sys/kernel/security/ima/ascii_runtime_measurements
10 8b6c2f0c8d9e1e... ima-ng sha256:... boot_aggregate
10 1a2b3c4d5e6f... ima-ng sha256:... /usr/lib/systemd/systemd
10 9f8e7d6c5b4a... ima-ng sha256:... /usr/bin/sudo

Qué significa: IMA extiende la medición más allá del arranque temprano hacia mediciones de archivos en tiempo de ejecución (si está configurado). Control distinto, pero a menudo emparejado con atestación TPM.

Decisión: Si estás construyendo atestación, decide si necesitas solo integridad de arranque o evidencia continua de integridad de archivos. No habilites IMA en producción sin un plan de despliegue; puede generar mucho ruido.

Task 10: Confirm LUKS is using TPM-based unlocking (systemd-cryptenroll example)

cr0x@server:~$ sudo systemd-cryptenroll --dump /dev/nvme0n1p3 | sed -n '1,25p'
CRYPTTAB ENROLLMENT:
  Entry Token 0:
        Token Type: systemd-tpm2
        PCRs: 7
        SRK Handle: 0x81000001

Qué significa: El volumen tiene un token TPM2 inscrito, vinculado a la PCR 7 en este ejemplo.

Decisión: El enlace solo a PCR 7 es común y a veces aceptable, pero a menudo no es suficiente para alta garantía. Considera enlazar PCRs adicionales (p. ej., relacionados con cargador de arranque/kernel) según tu plataforma y tolerancia a rupturas por actualizaciones.

Task 11: Test unsealing behavior by simulating a policy mismatch (safe read-only check)

cr0x@server:~$ sudo systemd-cryptenroll --tpm2-pcrs=0+7 --dry-run /dev/nvme0n1p3
Failed to enroll TPM2 token: PCR 0+7 policy would change (existing token uses PCRs: 7)

Qué significa: Cambiar la política de PCR cambia cuándo el TPM liberará la clave. Por eso “simplemente enlazar a más PCRs” no es gratis.

Decisión: Decide según el modelo de amenazas: más PCRs suelen aumentar la integridad pero aumentan el acoplamiento operativo con actualizaciones y cambios de configuración.

Task 12: Inspect boot entries and confirm you’re booting what you think you’re booting

cr0x@server:~$ sudo efibootmgr -v | head -n 15
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,2c9d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Qué significa: Muestra la ruta al binario EFI realmente utilizado. Atacantes y accidentes aman las entradas de arranque alternativas.

Decisión: Si BootCurrent no es la ruta esperada, corrige el orden de arranque y elimina entradas obsoletas. En servidores, protege el acceso al firmware y registra cambios.

Task 13: Check for Secure Boot-related boot failures in the journal

cr0x@server:~$ sudo journalctl -b -0 | grep -iE 'secure boot|shim|mok|verification|lockdown' | head
kernel: secureboot: Secure boot enabled
kernel: Lockdown: integrity: Kernel is locked down from EFI Secure Boot mode
shim: MokManager: Processing MOK enrollment request

Qué significa: Confirma modo lockdown y muestra eventos de enrolamiento de claves.

Decisión: Si ves errores de verificación tras actualizaciones, probablemente tienes un desajuste de firmas o un evento de revocación. Deja de adivinar y valida firmas y el estado de dbx.

Task 14: Determine kernel lockdown mode (common with Secure Boot on)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity [confidentiality]

Qué significa: El kernel está en modo lockdown, restringiendo ciertas acciones que podrían eludir garantías de integridad.

Decisión: Si tus herramientas dependen de interfaces restringidas (como algunos depuradores), planifica flujos alternativos. No desactives Secure Boot solo para que tu depurador funcione; usa kernels firmados adecuados o compilaciones de depuración controladas.

Task 15: Inspect dbx updates (revocations) that can break boot

cr0x@server:~$ sudo mokutil --dbx | head
dbx:
  0: sha256 3f2a...d91c
  1: sha256 7a9b...0011

Qué significa: Lista hashes/certs revocados en dbx tal como se ve vía mokutil.

Decisión: Si un bootloader del que dependes aparece en dbx (directamente o via cadena de certificados), necesitas actualizar componentes de arranque en toda la flota antes de que la enforcement de revocación deje máquinas varadas.

Task 16: Confirm TPM is not in a weird “needs attention” state

cr0x@server:~$ dmesg | grep -iE 'tpm|crb|tis' | head -n 10
tpm_tis 00:05: 2.0 TPM (device-id 0x1B, rev-id 16)
tpm tpm0: TPM2.0 device found (CRB interface)

Qué significa: El kernel reconoce el TPM y la interfaz. Errores aquí suelen correlacionarse con malas configuraciones de firmware o revisiones de BIOS con bugs.

Decisión: Si ves timeouts o errores de localidad, prioriza actualizaciones de firmware o correcciones de plataforma antes de construir sistemas dependientes del TPM encima.

Guía de diagnóstico rápido: encuentra el cuello de botella rápido

Cuando la seguridad de arranque falla, la gente tiende a revolverse. No lo hagas. Usa una guía corta y normalmente encontrarás el culpable en minutos.

Primero: ¿falla la aplicación o falla la liberación de la clave?

• La máquina no arranca en absoluto, cae al firmware o al prompt del cargador: probablemente aplicación de Secure Boot o componente de arranque revocado.
• La máquina arranca pero el disco no se desbloquea automáticamente / pide la clave de recuperación: probablemente fallo de desellado TPM por deriva de PCR o cambio de estado del TPM.
• La máquina arranca y el disco se desbloquea, pero la atestación dice “no confiable”: probablemente desajuste de arranque medido, parsing del registro de eventos o deriva de baseline.

Segundo: revisa las tres “fuentes de verdad”

1. Ajustes de firmware: ¿Secure Boot habilitado? ¿CSM/legacy deshabilitado? ¿TPM habilitado/activado? ¿Alguna actualización de firmware reciente?
2. Componentes de arranque: qué binario EFI se ejecutó (efibootmgr), ¿las firmas son válidas (sbverify), cambió dbx (mokutil –dbx)?
3. Mediciones/claves: valores PCR (tpm2_pcrread), política de enrolamiento (systemd-cryptenroll –dump) y registros (journalctl, dmesg).

Tercero: decide qué tipo de arreglo puedes permitir

• Restauración de emergencia del servicio: usa claves de recuperación, arranca con medios firmados conocidos, revierte la actualización conflictiva.
• Corrección de integridad: actualiza/re-firma cargador/kernel, ajusta la política PCR con un procedimiento controlado de re-sellado, despliega cambios de db/dbx en el orden correcto.
• Arreglo a largo plazo: estandariza versiones de firmware, gestión de claves y cadencia de actualizaciones; implementa gating por atestación para cargas sensibles.

El cuello de botella usualmente no es “el TPM está roto”. Es “cambiamos algo que no medimos y ahora nuestra política hace exactamente lo que pedimos”.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: Tras una actualización del kernel, los servidores arrancan pero falla el auto-desbloqueo LUKS

Causa raíz: La clave sellada en el TPM estaba ligada a PCRs afectadas por la actualización (o al estado de Secure Boot que cambió por actualizaciones db/dbx).

Solución: Usa la vía de recuperación para arrancar y luego reseal/enroll el token TPM contra el nuevo estado medido. Considera enlazar a PCRs que coincidan con tu estrategia de actualizaciones y prueba actualizaciones en un anillo canario.

2) Síntoma: “SecureBoot enabled” pero todavía cargan módulos del kernel sin firmar

Causa raíz: No está habilitada la aplicación de firmas de módulos (o los módulos están firmados por una clave que el kernel confía vía MOK/certificado embebido).

Solución: Habilita la aplicación de firmas de módulos donde sea requerido; audita las claves confiadas; implementa una cadena de firma de módulos. No confíes solo en Secure Boot para la integridad de módulos.

3) Síntoma: De repente no puedes arrancar con medios de rescate antiguos

Causa raíz: Una actualización de dbx revocó el bootloader/shim antiguo usado por ese medio.

Solución: Mantén medios de rescate actualizados firmados con claves actualmente confiables; prueba medios de arranque después de actualizaciones de dbx; conserva una ruta documentada de acceso de emergencia que no dependa de componentes revocados.

4) Síntoma: La atestación falla en un subconjunto de servidores del mismo modelo

Causa raíz: Versiones de firmware diferentes, o ajustes del BIOS distintos (CSM, modo Secure Boot, orden de arranque), causando deriva de PCR.

Solución: Estandariza firmware, aplica perfiles de configuración y recoge baselines de PCR por modelo/firmware. “Idéntico” en la flota suele ser aspiracional, no real.

5) Síntoma: Herramientas TPM devuelven “No TPM device found” en una VM

Causa raíz: vTPM no adjunto o no expuesto; o la guest carece de drivers.

Solución: Adjunta un dispositivo vTPM en la configuración del hipervisor; verifica la existencia de /dev/tpmrm0; asegura que los módulos del kernel estén presentes. Si no puedes confiar en el hipervisor, no finjas que el vTPM te da garantías a nivel hardware.

6) Síntoma: Secure Boot habilitado, pero la manipulación de la cadena de arranque aún es posible con acceso físico

Causa raíz: La configuración del firmware no está protegida (sin contraseña de administrador), el atacante puede deshabilitar Secure Boot o inscribir sus propias claves.

Solución: Bloquea la configuración del firmware, restringe el acceso físico, usa detección de intrusión del chasis si está disponible e inventaría/monitorea deriva de configuración del firmware.

7) Síntoma: No puedes depurar producción porque el lockdown bloquea acceso a interfaces del kernel

Causa raíz: Secure Boot dispara la política de lockdown del kernel que restringe ciertas operaciones de depuración.

Solución: Proporciona kernels de depuración firmados para entornos controlados, o usa herramientas de observabilidad soportadas que no requieren romper garantías de integridad. Si tu plan de depuración requiere desactivar controles, no es un plan.

Tres mini-historias corporativas (anonimizadas, plausibles y dolorosas)

Mini-historia 1: El incidente causado por una suposición errónea (“Secure Boot significa que nuestros drivers están seguros”)

Una compañía SaaS mediana desplegó Secure Boot en sus nodos worker de Kubernetes. Fue un empujón por cumplimiento. El equipo de seguridad obtuvo su casilla marcada, el de infraestructura sufrió muchos reinicios de firmware y todos declararon victoria.

Semanas después, un pool de nodos empezó a comportarse raro: pérdidas intermitentes de paquetes, picos de CPU en softirq y luego panics ocasionales del kernel. Vibras clásicas de “hardware o driver”. Drenaron nodos, reemplazaron algunos y el problema siguió la imagen, no el chasis.

La causa raíz no fue exótica: se instaló un módulo de kernel de terceros como parte de un “paquete de rendimiento”. Estaba firmado—porque la organización había inscrito una clave MOK amplia para facilitar instalaciones de proveedores. Un artefacto de build comprometido se coló en la cadena de suministro, aún firmado por la clave que todos confiaban. Secure Boot aplicó la política: “Si está firmado por esta clave, ejecútalo”.

La solución no fue desactivar Secure Boot. Fue dejar de tratar el enrolamiento MOK como una característica de conveniencia. Rotaron la clave MOK, restringieron quién podía firmar módulos y requirieron evidencia reproducible de build para los blobs de proveedores. Aprendieron a la fuerza que confiar en una clave es la política real; las firmas son solo el formato.

Mini-historia 2: La optimización que salió mal (“Ligemos la clave de disco a más PCRs para mayor seguridad”)

Un equipo de servicios financieros decidió endurecer el cifrado de disco en laptops Linux. Usaron desbloqueo basado en TPM y pensaron, razonablemente, que ligar la clave a más PCRs haría la manipulación más difícil. Así que la ligaron a un conjunto amplio: firmware, cargador de arranque, kernel y algunas mediciones relacionadas con configuración.

En el laboratorio se veía genial. Luego llegó el mundo real. Llegaron actualizaciones de firmware en oleadas, a veces por herramientas del OEM, a veces por IT. Un subconjunto de máquinas recibió una actualización de BIOS que cambió componentes medidos y valores PCR. Los portátiles arrancaron, pero el TPM se negó a desellarlos. Los usuarios cayeron en flujos de recuperación y las líneas de soporte colapsaron.

El equipo de seguridad inicialmente lo llamó “inestabilidad TPM”. No lo era. Era la política haciendo su trabajo: esas máquinas ya no estaban en el antiguo estado medido.

Recuperaron apoyándose en claves de recuperación y un proceso controlado de re-enrolamiento tras actualizaciones. También aprendieron a ligar PCRs que coincidan con su cadencia operativa y a escalonar actualizaciones de firmware con la misma disciplina que las actualizaciones del SO. Más PCRs puede ser más fuerte. También puede convertirse en un Denial-of-Service que te autoprogramas.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (“Probamos cambios de dbx como un deploy de producción”)

Una gran empresa gestionaba una flota Linux mixta: servidores bare metal, algunos portátiles y un lote de appliances que eran básicamente PCs en una caja. Tenían una práctica que parecía dolorosamente conservadora: cualquier actualización de firmware y cualquier cambio db/dbx pasaba por anillos canario, con pruebas de arranque que incluían medios de rescate.

Un trimestre, se desplegó una actualización dbx que revocó un componente de arranque vulnerable. Fue la decisión de seguridad correcta. También fue el tipo de movimiento que deja máquinas varadas si aún arrancas con shims antiguos o dependes de imágenes de recuperación obsoletas.

Porque tenían canarios, lo detectaron temprano: su ISO de rescate heredada ya no arrancaba. La solución fue directa: actualizar medios de rescate con un shim firmado actual y actualizar la imagen del proveedor del appliance antes de que la revocación afectara a la flota amplia.

Sin drama. Sin llamadas de incidente. Sin ejecutivos aprendiendo qué significa “dbx”. Solo un ticket pequeño cerrado con discreción. Este es el tipo de higiene operacional poco glamorosa que te mantiene empleado.

Listas de verificación / plan paso a paso (qué hacer en una organización real)

Checklist A: Desplegar Secure Boot sin causar outages autoinfligidos

1. Inventario del modo de firmware: confirma modo UEFI en todas partes; elimina instalaciones legacy BIOS.
2. Decide la estrategia de claves: valores por defecto del proveedor vs PK/KEK/db personalizados. Si necesitas control organizacional fuerte, planifica claves personalizadas y custodia.
3. Establece pipeline de firma: quién firma kernels/módulos, dónde se almacena la clave, qué aprobaciones existen y dónde están los logs de auditoría.
4. Planifica cambios de dbx: sigue revocaciones; prueba que tus componentes de arranque y medios de rescate no estén revocados.
5. Canary todo: firmware, shim, cargador, kernel y actualizaciones de dbx. Las pruebas de arranque no son opcionales.
6. Define acceso de emergencia: consola fuera de banda, medios de rescate, claves de recuperación y el proceso humano para usarlos.

Checklist B: Usar TPM para desbloqueo de disco sin engañarte

1. Define contra qué te defiendes: laptop robada, servidor robado o manipulación?
2. Elige la política PCR intencionalmente: solo PCR 7 es conveniente; políticas más amplias son más fuertes pero frágiles. Elige según la realidad de tus actualizaciones.
3. Almacena claves de recuperación de forma segura: en custodia con control de acceso y auditoría. Prueba recuperación trimestralmente.
4. Planifica actualizaciones de firmware: cambiarán PCRs. Construye un flujo de re-enrolamiento.
5. Monitorea la deriva: recopila baselines de PCR; alerta sobre cambios inesperados para roles sensibles.

Checklist C: Atestación que no se convierta en teatro

1. Decide qué harás con los resultados de atestación: bloquear colocación de cargas, restringir secretos o solo registrar evidencia.
2. Baseline por clase de plataforma: modelo de hardware + versión de firmware + perfil de configuración.
3. Maneja actualizaciones: trata nuevos baselines como un release; promuévelos por anillos.
4. Mantén los logs: la atestación sin retención es un hobby, no un control.

Preguntas frecuentes

1) ¿Secure Boot cifra algo?

No. Secure Boot verifica firmas para decidir qué puede ejecutarse. El cifrado en reposo es un control separado (LUKS, BitLocker, etc.).

2) Si Secure Boot está habilitado, ¿estoy a salvo de bootkits?

Estás más protegido contra bootkits sin firmar o no confiables. Si los atacantes pueden conseguir que un componente malicioso sea firmado por una clave confiable (o comprometen tu clave), Secure Boot lo arrancará felizmente.

3) ¿Qué almacena realmente el TPM?

Pueden almacenar claves (o material de claves), contadores y pequeños blobs. También almacena valores PCR (mediciones) y puede firmar declaraciones de atestación. No es almacenamiento de propósito general.

4) ¿Cuál es la diferencia entre enlace a PCR y “TPM presente” para desbloqueo de disco?

Enlace a PCR significa que el TPM liberará la clave solo si el estado medido coincide con la política. “TPM presente” sin política PCR significativa es mayormente conveniencia; puede no resistir la manipulación.

5) ¿Por qué una actualización de firmware rompe el auto-desbloqueo basado en TPM?

Porque los componentes medidos cambiaron, los valores PCR cambiaron y el TPM se niega a desellar una clave ligada a las mediciones antiguas. Ese es un comportamiento esperado.

6) ¿Puedo usar un TPM en una VM y aún reclamar confianza hardware?

Puedes usar un vTPM y obtener funciones como sellado y atestación dentro del límite de confianza de la virtualización. Pero tu confianza pasa al hipervisor, su almacenamiento de secretos vTPM y su historia de atestación.

7) ¿Debo usar claves Secure Boot personalizadas (PK/KEK/db propio) en todas partes?

Sólo si estás listo para operarlo: generación de claves, almacenamiento seguro, rotación, recuperación y gestión del ciclo de vida. Para muchas organizaciones, shim + MOK es un punto medio pragmático. Para alta garantía, las claves personalizadas valen la pena.

8) ¿Secure Boot es lo mismo que kernel lockdown?

No, pero están conectados en muchas distribuciones. Cuando Secure Boot está habilitado, el kernel puede entrar en modo lockdown para evitar ciertas acciones que podrían eludir garantías de integridad.

9) ¿Puede Secure Boot impedir que alguien arranque desde un USB?

Puede impedir arrancar cargadores USB sin firmar/no confiables. Pero si las opciones de arranque del firmware no están bloqueadas, un atacante aún podría cambiar ajustes. La seguridad física y el control de acceso al firmware importan.

10) ¿Qué debería registrar y monitorear?

Como mínimo: estado de Secure Boot, claves inscritas (MOK/db), cambios de dbx, versiones de firmware, disponibilidad del TPM y resultados de atestación para máquinas que ejecutan cargas sensibles.

Próximos pasos que realmente importan

Si quieres que Secure Boot + TPM sean más que un sticker de cumplimiento, haz tres cosas:

1. Escribe tu modelo de amenazas en lenguaje llano. “Evil maid en portátiles” y “persistencia por bootkit en hipervisores” son mundos distintos.
2. Operacionaliza claves y actualizaciones: trata la firma como despliegues de producción, prueba cambios de dbx como pruebas de kernel y estandariza firmware.
3. Practica la recuperación: custodia claves de recuperación, conserva medios de rescate actualizados y realiza trimestralmente un simulacro “¿podemos recuperar un disco sellado tras una actualización de firmware?”.

Secure Boot aplica lo que confías. El TPM te ayuda a enlazar secretos y demostrar lo que pasó. Ninguno reemplaza parcheo, control de acceso o procesos aburridos. Y el “proceso aburrido”, incómodamente, es donde vive la mayor parte de la seguridad.