Cifrado LUKS2 + TPM 2.0 en Linux 2026

Q: ¿Cómo configuro desbloqueo automático LUKS con TPM 2.0?

Usa systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+7 /dev/sdX para sellar la clave a los PCR del firmware y Secure Boot, luego añade tpm2-device=auto en /etc/crypttab . Mantén siempre una passphrase de respaldo en otro slot.

Actualizado: 26 de mayo de 2026

El cifrado de disco con LUKS2 en Linux se configura con cryptsetup luksFormat --type luks2, usa Argon2id como KDF por defecto y permite desbloqueo automático mediante TPM 2.0 con systemd-cryptenroll, o policy-based unlock con Clevis/Tang. En 2026, LUKS2 sigue siendo el estándar de facto para cifrado en reposo en distribuciones modernas (RHEL 9, Ubuntu 24.04 LTS, Debian 12), e integra mejoras críticas en resistencia a ataques de hardware, recuperación y rotación de claves. Honestamente, este es uno de esos temas donde un error de configuración cuesta horas de pánico. Por eso, en mi último despliegue de flotilla de servidores hice un checklist como el que voy a compartir contigo aquí, paso a paso, desde el formateo inicial hasta el desbloqueo desatendido.

LUKS2 reemplaza a LUKS1 con un encabezado JSON redundante, soporte para múltiples segmentos y Argon2id por defecto, mucho más resistente a GPU/ASIC que PBKDF2.
cryptsetup-2.7.x (2026) admite re-cifrado online, slots de tokens TPM/FIDO2 y verificación de integridad por sector con --integrity.
systemd-cryptenroll sella claves en el TPM 2.0 vinculadas a PCRs (típicamente 0, 2, 7) para desbloqueo automático con detección de manipulación de firmware.
Clevis + Tang ofrecen desbloqueo basado en red (NBDE) para flotas de servidores sin TPM o entornos virtualizados.
Mantenga siempre una clave de recuperación en un slot separado y exporte el encabezado LUKS con cryptsetup luksHeaderBackup. Sin él, los datos cifrados son irrecuperables.
LUKS2 con AES-XTS-256 no es post-cuántico seguro a largo plazo, pero el riesgo práctico hasta 2030+ es bajo según la guía NIST IR 8547.

Diferencias entre LUKS1 y LUKS2

LUKS2 introduce un encabezado en formato JSON con dos copias redundantes (binario + JSON area), y eso elimina la principal causa de pérdidas catastróficas en LUKS1: la corrupción del header en los primeros 4096 bytes. Cada keyslot LUKS2 puede usar un KDF distinto, y la especificación admite hasta 32 slots (frente a 8 en LUKS1). Además, LUKS2 soporta tokens JSON que vinculan slots a hardware externo: TPM 2.0, llaves FIDO2 (YubiKey 5, Nitrokey 3, SoloKey) y servidores Tang.

El KDF por defecto cambia de PBKDF2 (LUKS1) a Argon2id, ganador del Password Hashing Competition y resistente a ataques con GPU/ASIC. En benchmarks de 2026, romper una passphrase de 12 caracteres protegida con Argon2id requiere ~10⁴ veces más recursos que la misma con PBKDF2-SHA256. La siguiente tabla resume los puntos de comparación que más afectan a decisiones operativas:

Característica	LUKS1	LUKS2
Formato del header	Binario fijo	JSON + binario redundante
KDF por defecto	PBKDF2-SHA256	Argon2id
Máx. keyslots	8	32
Tokens TPM/FIDO2	No	Sí (slot 0–31)
Re-cifrado online	No	Sí (cryptsetup ≥ 2.2)
Integridad por sector (dm-integrity)	Limitado	Nativo con `--integrity hmac-sha256`
Recuperación de header	Frágil	Robusta (2 copias)

Para nuevas instalaciones en 2026, no existe ningún motivo técnico para usar LUKS1. Los instaladores de Fedora 41, RHEL 9, Ubuntu 24.04 LTS y openSUSE Tumbleweed usan LUKS2 sin opción explícita. Si tienes volúmenes LUKS1 heredados, puedes migrarlos con cryptsetup convert --type luks2 /dev/sdX tras un luksHeaderBackup.

Cómo cifrar un disco Linux con LUKS2

El flujo recomendado en 2026 cubre cuatro pasos: borrado seguro (opcional pero recomendado en SSD nuevos), luksFormat, apertura del dispositivo mapeado y creación del filesystem. Supongamos que el disco objetivo es /dev/nvme0n1p3 y se trata de una partición de datos (no la raíz). Los comandos son los siguientes:

# 1. Verificar versión de cryptsetup (debe ser >= 2.6 para soporte completo de TPM 2.0)
cryptsetup --version

# 2. (Opcional) Sobrescribir con datos aleatorios para indistinguibilidad
dd if=/dev/urandom of=/dev/nvme0n1p3 bs=1M status=progress

# 3. Formatear con LUKS2, AES-XTS-256, Argon2id y dm-integrity opcional
cryptsetup luksFormat \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha512 \
  --pbkdf argon2id \
  --pbkdf-memory 1048576 \
  --pbkdf-parallel 4 \
  --iter-time 5000 \
  --use-random \
  --verify-passphrase \
  /dev/nvme0n1p3

# 4. Abrir el dispositivo (aparecerá como /dev/mapper/datacrypt)
cryptsetup open /dev/nvme0n1p3 datacrypt

# 5. Crear filesystem y montar
mkfs.ext4 -L data /dev/mapper/datacrypt
mkdir -p /mnt/data
mount /dev/mapper/datacrypt /mnt/data

Para que el volumen se abra al arrancar, añade una entrada en /etc/crypttab y otra en /etc/fstab:

# /etc/crypttab (name, source, key-file, options)
datacrypt  UUID=$(blkid -s UUID -o value /dev/nvme0n1p3)  none  luks,discard,timeout=30

# /etc/fstab
/dev/mapper/datacrypt  /mnt/data  ext4  defaults,noatime  0  2

Usa siempre el UUID del dispositivo cifrado, no el nombre del nodo (que puede cambiar al reorganizar discos). El parámetro discard habilita TRIM y mejora el rendimiento en SSD, aunque expone el patrón de bloques no usados, así que evítalo si tu modelo de amenaza incluye análisis forense de SSD.

Argon2id como KDF: parámetros recomendados

Argon2id es el modo híbrido del algoritmo Argon2 (estandarizado en RFC 9106), que combina resistencia a side-channel (Argon2i) con resistencia a tradeoff (Argon2d). Sus tres parámetros (memoria, paralelismo e iteraciones) determinan tanto la seguridad como el tiempo de desbloqueo en cada arranque.

El valor de --iter-time de cryptsetup ajusta el número de iteraciones para que la derivación tarde N milisegundos en la CPU actual. Para servidores con CPU moderna (Ryzen 7000, Intel 13ª gen+), estos son los valores que vengo usando en producción:

Memoria (--pbkdf-memory): 1 048 576 KiB (1 GiB) en estaciones, 524 288 KiB (512 MiB) en VPS con poca RAM.
Paralelismo (--pbkdf-parallel): número de hilos físicos / 2, típicamente 2–4.
Tiempo de iteración (--iter-time): 5000 ms para datos sensibles; 2000 ms para volúmenes de arranque donde la latencia importa.

Verifica los parámetros aplicados con cryptsetup luksDump /dev/nvme0n1p3. Si planeas desplegar la misma imagen en hardware más débil (Raspberry Pi, edge devices), bench-mark previamente con cryptsetup benchmark y reduce la memoria. Argon2id con 1 GiB falla en sistemas con menos de 2 GiB libres durante el arranque temprano (lo aprendí por las malas en una Pi 4).

Desbloqueo automático con TPM 2.0 y systemd-cryptenroll

El desbloqueo desatendido con TPM 2.0 sella la clave del volumen contra valores de PCR (Platform Configuration Registers) que reflejan el estado del firmware y los componentes de arranque. Si un atacante modifica UEFI, el bootloader o el kernel, los PCRs cambian y el TPM se niega a liberar la clave. Esta es la base del modelo "measured boot" en Linux desde 2023.

La herramienta moderna es systemd-cryptenroll, parte de systemd ≥ 248. La documentación oficial de systemd-cryptenroll detalla todos los modos. Para enrollar un TPM 2.0 a un volumen LUKS2, el flujo mínimo es:

# Verificar que el TPM 2.0 está disponible y accesible
systemd-cryptenroll --tpm2-device=list

# Enrollar el TPM vinculando a PCRs 0 (firmware), 2 (extensions), 7 (Secure Boot state)
systemd-cryptenroll \
  --tpm2-device=auto \
  --tpm2-pcrs=0+2+7 \
  --tpm2-with-pin=yes \
  /dev/nvme0n1p3

# Confirmar que se añadió el slot de token
cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 "tpm2"

Activa el desbloqueo automático modificando /etc/crypttab para usar el módulo systemd-cryptsetup con la opción tpm2-device=auto:

# /etc/crypttab con TPM 2.0
datacrypt  UUID=...  none  luks,discard,tpm2-device=auto,tpm2-pcrs=0+2+7

La opción --tpm2-with-pin=yes añade una segunda capa: el TPM sólo libera la clave si el usuario introduce un PIN corto (4–8 dígitos) durante el arranque. Esto bloquea el ataque "evil maid", donde el atacante clona el TPM o lo mueve a otra placa. Para servidores headless donde no hay teclado, omite el PIN, pero entonces conviene monitorear journalctl -u systemd-cryptsetup@datacrypt en busca de fallos repetidos de PCR. Yo dejé pasar este punto en un rack remoto y, tras una actualización de firmware silenciosa, perdí el arranque automático sin saberlo durante una semana.

Clevis y Tang: cifrado vinculado a la red (NBDE)

Network-Bound Disk Encryption (NBDE) resuelve el problema de los servidores sin TPM, o las VMs donde el TPM virtual no es confiable. Tang es un servidor HTTP minimalista (puerto 80 por defecto) que custodia material criptográfico; Clevis es el cliente que combina ese material con una clave generada localmente para envolver la clave LUKS. El servidor jamás ve la clave del disco.

Esquema típico de despliegue en 2026: dos o más servidores Tang en distintas zonas de red, y los clientes los enrollan con política de umbral (threshold) usando Shamir Secret Sharing. Si pierdes 1 de 2 servidores, el disco sigue desbloqueándose. Si los pierdes todos, los datos quedan inaccesibles hasta restaurar uno.

# En el servidor Tang (Fedora/RHEL)
dnf install tang
systemctl enable --now tangd.socket
firewall-cmd --add-service=http --permanent && firewall-cmd --reload

# Publicar el thumbprint para los clientes
tang-show-keys

# En el cliente: enrollar Clevis a LUKS con política SSS de 1-de-2 Tang
dnf install clevis clevis-luks clevis-dracut
clevis luks bind -d /dev/nvme0n1p3 sss \
  '{"t":1,"pins":{"tang":[
    {"url":"http://tang1.internal:80"},
    {"url":"http://tang2.internal:80"}
  ]}}'

# Regenerar initramfs para que Clevis se ejecute en arranque temprano
dracut -fv

Para profundizar en el modelo de amenaza de Tang frente a TPM, consulta el proyecto Clevis en GitHub, que mantiene una matriz comparativa actualizada. La regla práctica que aplico: TPM 2.0 para laptops y servidores físicos, Clevis+Tang para flotas en datacenter con red interna confiable, y ambos combinados (sss con tpm2 + tang) para máxima resiliencia.

Rotación de claves, headers y backups

Una política de gestión de secretos seria exige rotación periódica de keyslots, especialmente tras la salida de un administrador o sospecha de exposición. LUKS2 soporta hasta 32 slots; mi recomendación es mantener al menos tres roles diferenciados: slot 0 (passphrase operativa), slot 1 (clave de recuperación impresa y custodiada offline) y slot 2+ (TPM/FIDO2/Tang). Las prácticas de gestión de secretos en CI/CD que describimos en nuestra guía de pipeline DevSecOps con GitHub Actions son igualmente aplicables a las claves LUKS.

# Añadir una clave de recuperación de 96 caracteres en slot 1
RECOVERY=$(openssl rand -base64 72)
echo "GUARDE ESTO OFFLINE: $RECOVERY"
echo -n "$RECOVERY" | cryptsetup luksAddKey /dev/nvme0n1p3 --new-key-slot 1

# Rotar la passphrase del slot 0
cryptsetup luksChangeKey /dev/nvme0n1p3 --key-slot 0

# Eliminar un slot comprometido (p.ej. tras salida de un admin)
cryptsetup luksKillSlot /dev/nvme0n1p3 3

# Backup del header (IMPRESCINDIBLE antes de cualquier cambio mayor)
cryptsetup luksHeaderBackup /dev/nvme0n1p3 \
  --header-backup-file /root/luks-header-$(date +%F).img
gpg --symmetric --cipher-algo AES256 /root/luks-header-*.img

Guarda el header cifrado fuera de la máquina (almacenamiento offline, gestor de secretos, caja fuerte). Sin él, una corrupción del primer sector del disco vuelve los datos cifrados irrecuperables incluso conociendo la passphrase. Combina esta práctica con escaneos regulares de configuración como los descritos en nuestra guía de escaneo de vulnerabilidades con Lynis, OpenSCAP y Trivy, que ya incluye comprobaciones de cifrado en reposo.

¿Es LUKS2 seguro frente a computación cuántica?

LUKS2 utiliza por defecto AES-XTS-256, un cifrado simétrico. El algoritmo de Grover reduciría su seguridad efectiva a 128 bits frente a un computador cuántico criptográficamente relevante (CRQC), nivel aún considerado seguro a largo plazo según NIST. Sin embargo, los KDFs como Argon2id son memory-hard y no se ven afectados sustancialmente por Grover. Por tanto, no es necesario migrar LUKS2 a algoritmos post-cuánticos en 2026.

El riesgo real no está en el cifrado simétrico del bloque, sino en cómo se protege la passphrase si se transmite por canales asimétricos (p. ej. desbloqueo remoto vía SSH con claves RSA). En ese caso, complementa el cifrado con configuraciones SSH resistentes a quantum como las que cubrimos en la guía de hardening SSH 2026 con criptografía post-cuántica. Para datos con horizonte de confidencialidad mayor a 30 años (registros médicos, secretos de estado), considera una capa adicional de cifrado a nivel de aplicación con algoritmos KEM aprobados por NIST (ML-KEM, antes Kyber).

Cómo abrir y montar una partición LUKS

Para abrir manualmente una partición LUKS desde un live USB o tras una recuperación, el flujo es:

# Identificar la partición LUKS
lsblk -f
blkid | grep crypto_LUKS

# Abrir e introducir la passphrase
cryptsetup open /dev/nvme0n1p3 rescue

# Si es LVM sobre LUKS, activar volume groups
vgscan && vgchange -ay

# Montar
mount /dev/mapper/rescue /mnt/rescue
# o, si hay LVM:
mount /dev/vg0/root /mnt/rescue

# Al terminar: desmontar y cerrar
umount /mnt/rescue
cryptsetup close rescue

Si recibes el error No key available with this passphrase tras un cambio de hardware (cambio de placa o actualización de firmware UEFI), suele ser un slot TPM que ya no valida los PCRs. Usa la passphrase de respaldo del slot 0 y reenrolla el TPM con los nuevos valores. Para hardening adicional del sistema operativo tras montar el volumen, te recomiendo nuestra guía sobre SELinux y AppArmor: MAC práctico para servidores Linux.

Preguntas frecuentes

¿Cuál es la diferencia principal entre LUKS1 y LUKS2 en 2026?

LUKS2 reemplaza el encabezado binario fijo de LUKS1 por un header JSON con redundancia, cambia el KDF por defecto a Argon2id (resistente a GPU), soporta hasta 32 keyslots y permite tokens TPM 2.0, FIDO2 y Tang. Todas las distribuciones modernas crean volúmenes LUKS2 por defecto.

¿Cómo configuro desbloqueo automático LUKS con TPM 2.0?

Usa systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+7 /dev/sdX para sellar la clave a los PCR del firmware y Secure Boot, luego añade tpm2-device=auto en /etc/crypttab. Mantén siempre una passphrase de respaldo en otro slot.

¿Cómo agrego una clave de recuperación a un volumen LUKS?

Genera una cadena aleatoria de al menos 60 caracteres y añádela con cryptsetup luksAddKey /dev/sdX --new-key-slot 1. Imprime el resultado, custódialo offline y verifica con cryptsetup luksDump que el slot 1 está habilitado.

¿Es seguro LUKS2 frente a computadoras cuánticas?

Sí, en un horizonte temporal razonable. AES-XTS-256 mantiene 128 bits de seguridad efectiva contra el algoritmo de Grover, nivel aceptable según NIST hasta 2030 y más allá. Argon2id no se ve afectado significativamente por algoritmos cuánticos conocidos.

¿Qué hago si pierdo la passphrase y el TPM falla?

Sin la passphrase, sin la clave de recuperación y sin acceso al TPM original, los datos son irrecuperables: ese es el diseño. Por eso es imprescindible mantener una clave de recuperación impresa offline y un backup del header LUKS cifrado (cryptsetup luksHeaderBackup) en almacenamiento separado.

¿Puedo usar LUKS2 sin TPM en un servidor headless?

Sí. Despliega Clevis con dos o más servidores Tang en tu red interna y enrolla el volumen con política Shamir Secret Sharing (sss) de umbral. El servidor desbloqueará automáticamente en arranque mientras la red esté disponible, sin requerir TPM ni intervención manual.