LUKS:

cifrado de disco en Linux, el equivalente a BitLocker

Linux y sistemas  |  unfantasmaenelsistema.com

En el artículo sobre BitLocker vimos cómo Windows cifra un disco entero para que, si te roban el portátil o acaba en un contenedor de reciclaje sin borrar, sus datos no sirvan de nada. Linux tiene su propia respuesta a ese mismo problema, y es anterior: se llama LUKS (Linux Unified Key Setup) y lleva siendo el estándar de facto desde 2004. No es una aplicación que instalas, sino un formato en disco y un subsistema del propio kernel.

La idea de fondo es idéntica a la de BitLocker: el disco se cifra bloque a bloque con una clave maestra que nunca cambia, y esa clave maestra se guarda a su vez cifrada con tu frase de paso (o con una llave, o con el TPM). Cambiar la contraseña no obliga a recifrar 500 GB: solo se vuelve a envolver la clave maestra. Este artículo recorre cómo funciona LUKS por dentro, cómo se cifra desde un disco de datos hasta la raíz del sistema, y cómo se automatiza el arranque sin renunciar a la protección.

1. Las piezas: dm-crypt, cryptsetup y LUKS

Conviene separar tres nombres que se mezclan. dm-crypt es el módulo del kernel Linux que hace el trabajo real: crea un dispositivo de bloques virtual que cifra y descifra al vuelo cada sector que se escribe o se lee del disco físico. cryptsetup es la herramienta de línea de comandos con la que hablas tú. Y LUKS es el formato estándar que cryptsetup escribe en el disco para guardar, de forma ordenada, todo lo que dm-crypt necesita: el algoritmo, la sal, los parámetros y la clave maestra envuelta.

Podrías usar dm-crypt en «modo plain», sin LUKS, pasándole tú todos los parámetros a mano cada vez. Nadie lo hace salvo casos muy concretos: sin cabecera no hay forma de saber si una frase de paso es correcta (simplemente sale basura), no puedes tener varias frases, y un error en un parámetro hace los datos irrecuperables sin ningún aviso. LUKS existe precisamente para quitar esos pies.

1.1 LUKS1 y LUKS2

Para un sistema nuevo, LUKS2 sin pensarlo. LUKS1 solo se sigue usando cuando el gestor de arranque necesita leer la partición cifrada directamente (por ejemplo GRUB desbloqueando `/boot` en algunas configuraciones antiguas), porque su soporte de LUKS2 y de Argon2 llegó tarde y con limitaciones.

2. La cabecera LUKS y los key slots

Todo lo que hace a un volumen LUKS descifrable vive en su cabecera, al principio de la partición. La cabecera contiene la clave maestra cifrada (en realidad, cifrada tantas veces como slots activos haya) y los metadatos. El resto de la partición es el área de datos, cifrada con la clave maestra en claro, que solo existe en la RAM mientras el volumen está abierto.

Un key slot es una ranura que guarda una copia de la clave maestra envuelta con una frase de paso concreta. LUKS2 tiene hasta 32. Esto tiene consecuencias prácticas muy útiles:

• Puedes darle a un disco una frase de paso tuya y otra de recuperación guardada en una caja fuerte, y ambas abren el mismo volumen
• Cambiar de frase de paso es añadir un slot nuevo y borrar el viejo: los datos no se tocan
• Un fichero de clave (`keyfile`) es solo otro slot: un archivo de bytes aleatorios que hace de «contraseña» para desbloqueos automáticos
• Si borras todos los slots, o se corrompe la cabecera, la clave maestra se pierde y con ella todos los datos, aunque el cifrado siga intacto

# Ver el estado de la cabecera y que slots estan ocupados
sudo cryptsetup luksDump /dev/sda2
 
# Copia de seguridad de la cabecera (guardala en lugar seguro y cifrado)
sudo cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file sda2-luks-header.img
 
# Restaurar la cabecera desde el backup
sudo cryptsetup luksHeaderRestore /dev/sda2 --header-backup-file sda2-luks-header.img

3. Argon2id: por qué tu frase de paso aguanta

En el artículo sobre Hashcat y GPU cracking vimos que una tarjeta gráfica moderna prueba miles de millones de hashes rápidos por segundo. Si LUKS derivara la clave de tu frase con una función rápida, una frase corta caería en horas. Por eso LUKS usa una función de derivación de clave (KDF) deliberadamente cara.

LUKS1 usaba PBKDF2, que solo se puede encarecer subiendo el número de iteraciones — y las GPU hacen iteraciones muy bien. LUKS2 usa Argon2id, diseñado tras el Password Hashing Competition para ser memory-hard: cada intento exige, por defecto, cientos de MB de RAM y varios hilos durante un tiempo medido. Una GPU tiene muchos núcleos pero poca memoria por núcleo, así que ese requisito de memoria hunde el paralelismo que hace peligroso a Hashcat. El ASIC dedicado, que arrasa con MD5, tampoco ayuda cuando el cuello de botella es el ancho de banda de memoria.

# cryptsetup mide tu hardware y ajusta Argon2 para tardar ~2 segundos por intento
# Puedes verlo y forzar parametros en el formateo:
sudo cryptsetup luksFormat --type luks2 \
     --pbkdf argon2id \
     --pbkdf-memory 1048576 \      # 1 GiB de RAM por intento
     --pbkdf-parallel 4 \
     --iter-time 4000 \            # objetivo: 4 s por intento en esta maquina
     /dev/sda2
 
# Ver los parametros KDF reales de un volumen ya creado:
sudo cryptsetup luksDump /dev/sda2 | grep -A4 Argon2

4. Cifrar un disco de datos, paso a paso

El caso más simple: un disco secundario, entero para datos, sin sistema operativo. El flujo es formatear a LUKS, abrirlo (lo que crea un dispositivo en `/dev/mapper/`), poner encima un sistema de ficheros normal y montarlo.

# 1. Formatear la particion como LUKS2 (BORRA lo que hubiera; pide confirmar y frase de paso)
sudo cryptsetup luksFormat --type luks2 /dev/sdb1
 
# 2. Abrir el volumen -> aparece /dev/mapper/datos
sudo cryptsetup luksOpen /dev/sdb1 datos
 
# 3. Sistema de ficheros dentro del volumen ya descifrado
sudo mkfs.ext4 /dev/mapper/datos
sudo mount /dev/mapper/datos /mnt/datos
 
# ... uso normal ...
 
# 4. Al terminar: desmontar y cerrar (la clave maestra sale de la RAM)
sudo umount /mnt/datos
sudo cryptsetup luksClose datos
 
# Anadir una segunda frase de paso (por ejemplo, de recuperacion) a un slot libre
sudo cryptsetup luksAddKey /dev/sdb1
 
# Quitar una frase de paso concreta
sudo cryptsetup luksRemoveKey /dev/sdb1

4.1 Montaje automático con /etc/crypttab

Para que un disco de datos se abra solo al arrancar, se declara en `/etc/crypttab` (qué volumen, de dónde sale la clave) y el punto de montaje va en `/etc/fstab` apuntando a `/dev/mapper/`. La clave suele ser un keyfile con permisos `0400` de root guardado en la raíz ya cifrada, para no teclear dos frases al arranque.

# /etc/crypttab   ->   nombre        dispositivo (por UUID)                  clave           opciones
datos   UUID=1a2b3c4d-....   /root/keys/datos.key   luks,discard
 
# /etc/fstab
/dev/mapper/datos   /srv/datos   ext4   defaults   0 2

4.2 Cifrar un disco que YA tiene datos

Desde cryptsetup 2.x se puede cifrar «in situ» un sistema de ficheros existente sin copiarlo a otro sitio, con `cryptsetup reencrypt –encrypt` (necesita un poco de espacio libre para desplazar los datos y hacer hueco a la cabecera). Es una operación larga y que debe poder reanudarse: un corte de luz a medias sin haber podido continuar deja el volumen inconsistente. Haz copia de seguridad completa antes, sin excepción.

5. Cifrar la raíz del sistema

Cifrar `/home` protege tus documentos, pero deja al descubierto binarios, configuración, logs y posibles secretos en `/etc` y `/var`. Cifrar la raíz entera es lo que de verdad equivale a BitLocker. El detalle es que el sistema tiene que arrancar desde algo cifrado, y ahí entra el initramfs.

• `/boot` (kernel + initramfs) suele quedar sin cifrar, o en LUKS1 si lo desbloquea GRUB. Es la parte que el firmware necesita leer antes de que exista ningún sistema para descifrar
• El initramfs es un mini-sistema en RAM que el kernel carga primero. Lleva `cryptsetup` y, al arrancar, es quien pide la frase de paso, abre la raíz LUKS y luego cede el control al sistema real
• Ese es el prompt de arranque («Please enter passphrase for disk…»): lo dibuja el initramfs, no el sistema operativo
• Todos los instaladores modernos (Ubuntu, Fedora, Debian, openSUSE) ofrecen esto como una casilla «cifrar el disco» — por dentro montan exactamente este esquema

6. Desbloqueo automático: TPM2 y red

Teclear la frase en cada arranque es tedioso en un portátil y directamente inviable en un servidor sin teclado. Hay dos formas estándar de que el disco se abra solo sin dejar la clave en claro en ningún fichero.

6.1 Atado al TPM 2.0 (como hace BitLocker)

El TPM es un chip que libera un secreto solo si el equipo arrancó en un estado concreto, medido en sus PCR (registros que resumen firmware, gestor de arranque, kernel…). `systemd-cryptenroll` mete un slot LUKS2 sellado contra esos PCR: si nadie ha manipulado el arranque, el TPM entrega la clave y el disco se abre sin preguntar; si algo cambió, no la entrega y cae de vuelta a la frase de paso.

# Sellar un slot LUKS contra el TPM, atado a los PCR 7 (Secure Boot) y 0 (firmware)
sudo systemd-cryptenroll --tpm2-device=auto \
     --tpm2-pcrs=0+7 /dev/sda2
 
# Anadir ademas un PIN: el TPM exige un codigo corto por encima de la medida de arranque
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-with-pin=yes /dev/sda2
 
# En /etc/crypttab, la opcion tpm2-device delega el desbloqueo en el chip
root  UUID=...  none  luks,tpm2-device=auto

6.2 Atado a la red: Clevis y Tang

Para un parque de servidores en un CPD propio, Tang es un pequeño servicio en la red y Clevis el cliente en cada máquina. Mediante un intercambio criptográfico (nada de «guardar la contraseña en el servidor»), la máquina solo puede desbloquear su disco si está en la red donde vive el Tang. Si alguien se lleva el servidor físico fuera del CPD, no arranca. Es el esquema «network-bound disk encryption» (NBDE), y se puede combinar con TPM en una política «esto Y aquello».

7. LUKS sobre LVM o LVM sobre LUKS

Si además de cifrar quieres LVM (varios volúmenes lógicos, snapshots, redimensionar), el orden de las capas importa.

El instalador de la mayoría de distribuciones monta «LVM sobre LUKS» cuando marcas cifrar el disco. Para la swap, cífrala siempre (guarda memoria en claro, incluida la posible frase): dentro del LVM cifrado ya lo está; si va suelta, `crypttab` admite una clave aleatoria en cada arranque (`/dev/urandom`), a costa de perder la hibernación.

8. Qué NO protege LUKS, y ataques reales

El cifrado de disco protege datos en reposo: el equipo apagado, el disco fuera de la máquina, el portátil robado sin encender. En cuanto el volumen está abierto, los datos están tan expuestos como en cualquier sistema sin cifrar. Los ataques conocidos explotan justo esa frontera.

9. Checklist para un portátil Linux

Conclusión

LUKS hace en Linux exactamente lo que BitLocker en Windows, con la misma arquitectura de clave maestra envuelta y las mismas fronteras: protege el disco en reposo y nada más. La diferencia está en la transparencia — cabecera documentada, `cryptsetup luksDump` te enseña cada parámetro, y puedes copiar la cabecera, migrar el KDF o añadir slots sin herramientas propietarias.

Si te quedas con tres ideas: marca la casilla de cifrado al instalar y usa una frase de paso de verdad; haz copia de la cabecera y guarda una frase de recuperación aparte, porque la cabecera es el único punto de fallo total; y automatiza el arranque con TPM2 más PIN, que es cómodo sin regalar el disco a quien solo pulse el botón de encendido.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)