- El auto‑unlock de LUKS con TPM se basa en añadir una clave extra sellada a PCR y liberada solo si el arranque coincide con el estado esperado.
- Herramientas modernas como systemd‑cryptenroll y Clevis permiten integrar TPM2 con LUKS y el initramfs sin recurrir a scripts artesanales.
- La elección de PCR y el soporte correcto en initramfs determinan el equilibrio entre seguridad, tolerancia a actualizaciones y comodidad.
- Este modelo protege sobre todo frente a robo de discos y arranques no autorizados, aunque implica ceder algo de seguridad frente a ataques físicos muy avanzados.
Configurar desbloqueo automático de LUKS usando TPM se ha convertido en algo muy apetecible para quien quiere cifrado completo de disco sin teclear la contraseña en cada arranque. El problema es que hay mil guías distintas, algunas mezclan conceptos, otras dependen de la distro… y al final es fácil acabar bastante perdido.
En este artículo vas a encontrar una explicación paso a paso y en profundidad de las distintas formas de integrar LUKS con TPM (TPM2 e incluso TPM 1.2), usando herramientas modernas como systemd-cryptenroll y Clevis, pero también métodos más artesanales con scripts en initramfs. Verás ventajas, pegas reales que se encuentra la gente, cómo elegir PCR y qué implicaciones de seguridad tiene todo esto.
Qué es realmente el auto‑unlock de LUKS con TPM
Cuando hablamos de auto‑unlock por TPM nos referimos a que el equipo sea capaz de descifrar el volumen LUKS durante el arranque sin que tú metas la contraseña, siempre que el estado de la máquina coincida con el esperado. En lugar de usar tu passphrase, se usa una clave adicional guardada y sellada dentro del TPM.
En LUKS, los datos no se protegen directamente con tu contraseña, sino con una clave maestra interna. Tu passphrase (o una clave aleatoria) solo sirve para cifrar esa clave maestra mediante un algoritmo de derivación. Esto permite tener múltiples ranuras de clave en el mismo volumen: una o varias contraseñas humanas, y otra clave aleatoria asociada al TPM para el auto‑desbloqueo.
El TPM, por su parte, es un chip criptográfico que puede guardar secretos y liberarlos solo si se cumplen ciertas condiciones, entre ellas que determinados registros de configuración de plataforma, los PCR (Platform Configuration Registers), tengan unos valores concretos. Esos PCR almacenan hashes de diferentes partes del proceso de arranque (firmware, bootloader, kernel, estado de Secure Boot, etc.), de forma que, si algo se modifica, el TPM se niega a entregar la clave.
Requisitos generales antes de empezar
Antes de lanzarte a probar cualquier método de auto‑unlock con TPM, conviene asegurarse de que el sistema cumple una serie de requisitos básicos para evitar perder el tiempo o, peor, dejar la máquina sin arrancar.
- Necesitas un chip TPM2 (o TPM 1.2 en algunos escenarios) habilitado en la BIOS/UEFI. En hardware moderno suele venir de serie, pero puede estar desactivado. En sistemas con systemd puedes consultar si el sistema ve un TPM2 con un comando tipo systemd-analyze has-tpm2.
- El volumen debe estar cifrado con LUKS, idealmente en formato LUKS2 si quieres usar systemd-cryptenroll o la integración moderna de systemd. Puedes comprobarlo con cryptsetup luksDump /dev/tu_dispositivo. Si ves LUKS1 y quieres convertir a LUKS2, es una operación delicada en la que es imprescindible tener copia de seguridad.
- Hay que tener instalados los paquetes adecuados según el método: para systemd‑cryptenroll suelen ser systemd-cryptenroll y tpm2-tss; para Clevis serán clevis, clevis-luks, clevis-tpm2 y, dependiendo de la distro, módulos como clevis-systemd, clevis-dracut o clevis-initramfs.
- El initramfs ha de incluir todo lo necesario para el desbloqueo temprano: soporte de LUKS, drivers del TPM y los binarios o hooks que hagan la petición al chip. En Debian/Ubuntu eso se gestiona con mkinitramfs o update-initramfs, en Fedora con dracut y en Arch con mkinitcpio.
Además, conviene tener Secure Boot funcionando si quieres un modelo parecido al de BitLocker, ya que Secure Boot y TPM se complementan: el primero valida que el código que arranca está firmado y no ha sido alterado, y el segundo sella la clave contra la medición de ese arranque.
Elegir bien los PCR: equilibrio entre seguridad y comodidad
Uno de los puntos más confusos cuando se configura LUKS con TPM2 es decidir qué PCR usar para sellar la clave. No es trivial, porque cuantos más PCR incluya el sellado, más cosas romperán el auto‑unlock tras una actualización o cambio de hardware, pero también será más difícil que un atacante manipule el arranque sin romper las medidas.
Los PCR se numeran y cada uno refleja una parte distinta del sistema. Herramientas como systemd-cryptenroll documentan muy bien el significado de cada uno. Resumiendo los más relevantes para estos casos, tenemos PCR de firmware, de código de arranque, de configuración de particiones, del estado de Secure Boot, del kernel, initrd y línea de comandos, del shim y certificados MOK, incluso PCR que pueden medir volúmenes LUKS activados y machine-id.
Mucha gente busca un compromiso entre seguridad y no volverse loco con cada actualización. Por ejemplo, hay guías que recomiendan usar solo PCR relacionados con configuración básica y estado de Secure Boot, como 1 y 7, lo que permite actualizar firmware y bootloader firmados sin romper el desbloqueo. Otras configuraciones más estrictas combinan PCR como 1+3+5+7+11+12+14+15, añadiendo integridad de tabla de particiones, kernel, shim, parámetros de kernel, volúmenes LUKS, etc., a costa de que cualquier cambio significativo requiera volver a inscribir la clave en el TPM.
Hay también combinaciones centradas en lo que systemd considera razonable, como atar la clave a PCR 0, 4, 7 y 11 para cubrir firmware, bootloader, estado de Secure Boot y kernel empaquetado en una imagen unificada. Otras personas deciden evitar PCR que cambian con relativa frecuencia, como los relacionados con firmware o con kernels que se actualizan casi a diario, para no tener que re‑enrollar la clave cada dos por tres.
Método 1: auto‑unlock con systemd‑cryptenroll y TPM2
En sistemas modernos con LUKS2 y systemd, la forma más limpia de integrar el TPM es mediante systemd-cryptenroll. Esta herramienta se encarga de añadir a LUKS una ranura de clave aleatoria sellada con TPM2, y de coordinar el desbloqueo durante el arranque usando sd-encrypt en initramfs.
Alta de la clave en el TPM2
El primer paso consiste en identificar el volumen cifrado, normalmente la partición que contiene la raíz o el conjunto de volúmenes que quieres desbloquear sin intervención. Una vez localizado el dispositivo, se ejecuta como root un comando del estilo systemd-cryptenroll –tpm2-device=auto –tpm2-pcrs=LISTA_PCR /dev/tu_dispositivo.
Este comando genera una clave aleatoria nueva y la coloca en una ranura extra de LUKS, sellándola a los PCR indicados. Durante el proceso, la herramienta te pedirá una contraseña ya válida de ese volumen para autorizar la operación. El TPM queda así asociado a ese volumen: si los PCR coinciden, en el arranque la clave se liberará y se usará de forma transparente.
systemd‑cryptenroll también puede opcionalmente combinar el sellado en TPM con un PIN adicional, usando una opción que fuerza a que el usuario introduzca un código corto además de cumplir las mediciones. Eso mitiga ataques de tipo “criatura de hotel” en los que alguien con acceso físico manipula el entorno, aunque en la práctica complica el uso y no todo el mundo lo necesita.
Integración con crypttab y la línea de comandos del kernel
Una vez creada la ranura TPM en LUKS, hay que decirle al sistema de arranque que intente usarla. En sistemas systemd el modo más habitual es editar /etc/crypttab y añadir la opción tpm2-device=auto en el campo de opciones de la entrada correspondiente. El formato de la línea suele ser algo tipo nombre UUID=… none luks,tpm2-device=auto.
Cuando el volumen cifrado contiene el sistema de archivos raíz, muchas distros también requieren pasar una opción en la línea de comandos del kernel, algo como rd.luks.options=tpm2-device=auto o una variante con el UUID del volumen, dependiendo de la forma en que el generador de initramfs interprete dichas opciones. Esto se hace editando /etc/default/grub y añadiendo el parámetro a la variable adecuada (GRUB_CMDLINE_LINUX o GRUB_CMDLINE_LINUX_DEFAULT).
Tras modificar la configuración de GRUB, hay que regenerar el fichero de configuración principal con herramientas como update-grub en Debian/Ubuntu o grub2-mkconfig -o /boot/grub/grub.cfg en Fedora y otras derivadas. Este paso es clave para que en el siguiente reinicio el kernel reciba los parámetros correctos de desbloqueo.
Regenerar initramfs con soporte TPM y sd‑encrypt
Para que todo esto funcione en la fase temprana de arranque, el initramfs debe contener sd-encrypt y las bibliotecas TPM2. En Fedora esto va de la mano con dracut, en Debian/Ubuntu se usa normalmente update-initramfs, y en Arch entra en juego mkinitcpio con los hooks adecuados. Muchas guías insisten en que hay que usar tpm2-tss y asegurarse de que los módulos sd‑encrypt y sd‑vconsole están presentes.
En distros como CachyOS o Arch, se recomienda cambiar la lista de hooks de mkinitcpio, sustituyendo el enfoque clásico basado en encrypt por la variante con systemd, sd-encrypt y sd-vconsole. Esto implica modificar la línea HOOKS para que aparezcan en orden correcto base, systemd, plymouth (si se usa), autodetect, microcode, modconf, kms, keyboard, sd‑vconsole, sd‑encrypt, block, filesystems y, opcionalmente, fsck.
Una vez ajustados los hooks, se regenera el initramfs con un mkinitcpio -P o equivalente, y en el siguiente arranque, si todo va bien, el volumen raíz se desbloquea usando el TPM sin pedir contraseña. En guías reales de usuarios, se comenta que cualquier fallo de configuración de crypttab o de los hooks puede dejar el sistema sin arrancar, por lo que es recomendable copias de seguridad de /etc/mkinitcpio.conf y crypttab antes de tocar nada.
Método 2: auto‑unlock usando Clevis y TPM2
Otra línea muy popular, especialmente en entornos RHEL, Fedora, Debian y derivados, es aprovechar Clevis, un marco de desencriptado basado en políticas que se integra con LUKS, TPM2 y distintos sistemas de arranque. Clevis añade una capa de flexibilidad, permitiendo incluso combinar TPM con otros factores o montar configuraciones más avanzadas.
Instalación de Clevis y preparación del TPM
Para trabajar con Clevis, en Debian/Ubuntu es habitual instalar clevis, clevis-tpm2, clevis-luks, clevis-udisks2, clevis-systemd y clevis-initramfs, y luego refrescar permisos con algo como udevadm trigger. En sistemas que usen dracut, puede entrar también clevis-dracut, que se encarga de inyectar módulos Clevis en el initramfs generado por dracut.
Es recomendable verificar qué bancos de PCR soporta el TPM con tpm2_pcrread. El comando listará distintas funciones hash (por ejemplo SHA1, SHA256) y mostrará qué PCR están activos. La mayoría de guías recomiendan usar SHA256 como banco de medición, por ser el estándar robusto actual y estar soportado por casi todo.
Vincular LUKS con TPM mediante Clevis
Una vez listo el entorno, se localiza el dispositivo LUKS (por ejemplo con cryptsetup luksDump /dev/sdaX) y se ejecuta un comando del tipo clevis luks bind -d /dev/sda3 tpm2 ‘{«pcr_bank»:»sha256″,»pcr_ids»:»0,1,7″}’. Este comando añade a LUKS una clave asociada a TPM y la sella a los PCR elegidos. La elección de PCR aquí, igual que con systemd‑cryptenroll, es un compromiso entre seguridad y que el auto‑desbloqueo no se rompa con cada cambio menor.
Hay ejemplos prácticos donde se recomienda incluir al menos el PCR 7 (estado de Secure Boot) y otro PCR relacionado con la plataforma, como el 1, para mitigar algunos ataques y seguir teniendo cierta flexibilidad a la hora de actualizar el firmware o el bootloader mientras estén firmados correctamente. Otra gente opta por combinaciones más conservadoras, lo que reduce algo la seguridad pero evita dolores de cabeza en servidores que se actualizan a menudo.
Integración de Clevis con initramfs y systemd
Tras hacer el bind de Clevis con LUKS, hay que asegurarse de que el initramfs contiene los módulos de Clevis y las librerías TPM. En Debian/Ubuntu esto suele implicar ejecutar update-initramfs -u -k all para regenerar la imagen, mientras que en Fedora se usa dracut -f y se verifica que el módulo de Clevis está incluido.
Clevis se integra con el marco de agentes de contraseña de systemd. En el arranque, systemd lanza distintos agentes que responden a las peticiones de passphrase: los tradicionales que muestran prompts en tty o en plymouth, y Clevis como agente adicional que intenta desbloquear automáticamente. Esto significa que puedes seguir viendo un prompt aunque Clevis esté funcionando; en algunos sistemas, aunque el volumen se haya desbloqueado de forma automática, el prompt visual ya lanzado no se borra, generando confusión.
Para que esto funcione con root, además de Clevis y los binarios TPM, se necesitan paquetes como clevis-systemd y, para la parte temprana del arranque, clevis-dracut o clevis-initramfs según la distro. Diversos casos prácticos muestran que cuando falta alguno de estos componentes, el sistema simplemente cae a un prompt de contraseña o incluso al shell de dracut, indicando que no se ha podido completar el cryptsetup.
Método 3: integración manual con TPM2 y scripts en initramfs
Antes de que existieran soluciones tan integradas como systemd-cryptenroll o Clevis, mucha gente recurría —y algunos siguen recurriendo— a scripts personalizados dentro del initramfs que usan las herramientas de TPM de bajo nivel (como tpm2_unseal) para obtener una clave y dársela a cryptsetup.
En este enfoque, se comienza instalando tpm2-tools y, a menudo, limpiando o reseteando el TPM a través del sistema o de la BIOS según el fabricante. A continuación se genera una clave aleatoria larga (por ejemplo 512 bits), se añade como clave válida en LUKS usando cryptsetup y se realiza el sellado en el TPM con las utilidades de tpm2-tools, creando una jerarquía de claves (clave raíz, clave de sellado) que guardan el secreto asociado a ciertos PCR.
Para que la clave pueda usarse en el arranque, es necesario que el initramfs incluya el binario tpm2_unseal, sus dependencias de biblioteca y los scripts que llaman a ese comando. En sistemas basados en initramfs-tools se usan scripts hook en /etc/initramfs-tools/hooks para meter los binarios dentro de la imagen, y scripts adicionales en /usr/local/bin o similares que se ejecutan temprano para obtener la clave y pasarla a cryptsetup.
Finalmente, se ajusta /etc/crypttab para indicar que la clave se obtiene mediante un keyscript personalizado que ejecuta tpm2_unseal. Dado que las opciones keyscript no siempre se integran bien con systemd en fases tempranas, algunas guías añaden opciones como initramfs para forzar que el desbloqueo se intente en initramfs y no más tarde. Después se reconstruye el initramfs y se prueba el arranque.
Este método es mucho más manual y propenso a errores, pero ilustra bien qué está ocurriendo por debajo: lo único esencial es que, durante el arranque, haya algo que sea capaz de pedirle al TPM la clave sellada y pasársela a cryptsetup sin intervención del usuario.
TPM 1.2 y métodos específicos con dracut
Aunque hoy casi todo el mundo habla de TPM2, todavía existen entornos donde solo hay TPM 1.2. En esos casos, el patrón general no cambia: se guarda una clave de LUKS en el TPM y se prepara el initramfs para leerla automáticamente. Hay soluciones basadas en tpm-tools/trousers y módulos de dracut específicos que leen un índice NV del TPM en el arranque.
Un ejemplo típico consiste en instalar trousers y tpm-tools, inicializar el TPM, guardar en un índice concreto la clave que previamente hemos añadido a LUKS, y luego usar un módulo de dracut personalizado que ejecuta tpm_nvread en initramfs para recuperar dicha clave y pasársela a cryptsetup. Si dracut no incluye cryptsetup por defecto en esa fase, hay que modificar los scripts de módulo para que lo haga, y a veces no resulta trivial porque dracut no siempre mete todo lo que esperamos.
En entornos como RHEL8 se han documentado estos métodos, pero suelen considerarse algo frágiles comparados con las integraciones modernas basadas en TPM2 y herramientas estándar. Aun así, demuestran que incluso con TPM 1.2 es posible lograr un comportamiento parecido al auto‑unlock, con las debidas precauciones.
Diferencias prácticas entre BitLocker y LUKS+TPM
En Windows, BitLocker ofrece desde hace años una experiencia prácticamente transparente: se cifra el disco del sistema, se sella una clave en el TPM, y el equipo arranca sin pedir nada mientras la plataforma no cambie de forma sospechosa. Es tan simple de usar que muchas organizaciones lo activan de forma masiva sin apenas intervención del usuario.
LUKS, conceptualmente, funciona de forma muy similar a BitLocker: una clave maestra interna protege los datos, y varias claves de desbloqueo (contraseñas, ficheros de clave, TPM) permiten acceder a esa clave maestra. La gran diferencia ha sido históricamente la falta de una integración homogénea entre las distintas distros Linux y los distintos sistemas de arranque, lo que dejaba al administrador construyendo soluciones a medida en initramfs.
Con la llegada de herramientas como systemd-cryptenroll y Clevis, y de initramfs generados por dracut o mkinitcpio con soporte nativo de TPM2, la situación se ha acercado mucho a la experiencia de BitLocker. Hoy es relativamente sencillo montar un servidor Linux con cifrado completo de disco que se auto‑desbloquea con TPM sin intervención humana, manteniendo un nivel de seguridad muy similar al de Windows siempre que se elijan bien los PCR y se mantenga Secure Boot.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.