dm-crypt (Español)/Specialties (Español)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Estado de la traducción: esta traducción de Dm-crypt/Specialties fue revisada el 2018-11-22. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Asegurar la partición de arranque no cifrada

La partición /boot y el Master Boot Record son las dos áreas del disco que no están cifradas, incluso en una configuración de raíz cifrada. Por lo general, no se pueden cifrar porque el gestor de arranque y la BIOS (respectivamente) no pueden desbloquear un contenedor dm-crypt para continuar el proceso de arranque. Una excepción es GRUB (Español), que tiene una función para desbloquear /boot cifrado —véase dm-crypt/Encrypting an entire system (Español)#Cifrar partición de arranque (GRUB)—.

Esta sección describe los pasos que se pueden tomar para hacer que el proceso de arranque sea más seguro.

Advertencia: tenga en cuenta que proteger la partición /boot y el MBR puede mitigar los numerosos ataques que se pueden producir durante el proceso de arranque, pero los sistemas configurados de esta manera pueden ser vulnerables a la manipulación de la BIOS/UEFI/firmware, a través de los registradores de teclas del hardware, los ataques de arranque en frío y muchas otras amenazas cuyo estudio queda fuera del alcance de este artículo. Para obtener una descripción general de los problemas relacionados con la fiabilidad del sistema y cómo se relacionan con el cifrado del disco completo, consulte [1].

Arrancar desde un dispositivo extraíble

Advertencia: en la versión 230 de systemd, cryptsetup generador emite RequiresMountsFor para el archivo de claves de cifrado. Por lo tanto, cuando el sistema de archivos que contiene este archivo no está montado, también detiene el servicio cryptsetup. Este comportamiento es incorrecto porque el sistema de archivos y la clave de cifrado solo se requieren una vez, cuando el contenedor criptográfico está inicialmente configurado. Consulte systemd issue 3816.

El uso de un dispositivo separado para iniciar un sistema es un procedimiento bastante sencillo y ofrece una mejora de seguridad significativa contra algunos tipos de ataques. En un sistema de archivos raíz cifrado hay dos partes que emplea el sistema que resultan vulnerables, estas son:

el Master Boot Record, y
la partición /boot.

Estos deben almacenarse sin cifrar para que el sistema pueda iniciarse. Para protegerlos de manipulación indebida, es recomendable almacenarlos en un medio extraíble, como una unidad USB, y arrancar desde esa unidad en lugar del disco duro. Siempre que tenga su disco USB a buen recaudo, puede estar seguro de que esos componentes no han sido manipulados, lo que hace que la autenticación sea mucho más segura al desbloquear el sistema.

Se supone que ya tiene su sistema configurado con una partición dedicada montada en /boot. Si no lo hace, siga los pasos indicados en dm-crypt/System configuration (Español)#Cargador de arranque, sustituyendo su disco duro por una unidad extraíble.

Nota: debe asegurarse de que su sistema admita el arranque desde el medio elegido, ya sea una unidad USB, un disco duro externo, una tarjeta SD o cualquier otro medio.

Prepare la unidad extraíble (/dev/sdx).

# gdisk /dev/sdx #formatear si es necesario. Alternativamente, utilice cgdisk, fdisk, cfdisk, gparted...
# mkfs.ext2 /dev/sdx1
# mount /dev/sdx1 /mnt

Copie los contenidos existentes de /boot en el nuevo.

# cp -ai /boot/* /mnt/

Monte la nueva partición. No olvide actualizar su archivo fstab (Español) en consecuencia.

# umount /boot
# umount /mnt
# mount /dev/sdx1 /boot
# genfstab -p -U / > /etc/fstab

Actualice GRUB (Español). El script grub-mkconfig debería detectar el nuevo UUID de la partición automáticamente, pero es posible que las entradas del menú personalizado deban actualizarse manualmente.

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx #intalar en el dispositivo extraíble, no en el disco duro.

Reinicie y pruebe la nueva configuración. Recuerde configurar en la BIOS o en Unified Extensible Firmware Interface (Español) el orden de inicio del dispositivo desde el que arrancar. Si el sistema no se inicia, aún debería poder iniciar desde el disco duro para corregir el problema.

chkboot

Advertencia: chkboot realiza una prueba de comprobación posencendido de una partición /boot, no una prueba de comprobación preencendido. Cuando se ejecuta el script chkboot, ya se ha ingresado la contraseña, por lo que su cargador de arranque, el kernel o initrd pueden quedar potencialmente comprometidos. Si el sistema da fallo tras la prueba de integridad de chkboot, no se podrá garantizar la seguridad de sus datos.

Remitiéndonos al artículo de ct-magazine (Número 3/12, página 146, 01.16.2012, [2]), el siguiente script comprueba los archivos presentes en /boot para cambios de hash SHA-1, inodo y bloques ocupados en el disco duro. También verifica el Master Boot Record. El script no puede evitar cierto tipo de ataques, pero otros muchos los hace más difíciles. Ninguna configuración del script en sí misma se almacena en /boot que no está cifrado. Con un sistema cifrado bloqueado/apagado, esto hace que sea más difícil para algunos atacantes porque no es evidente que se realice una comparación de suma de comprobación automática de la partición en el arranque. Sin embargo, un atacante que anticipe estas precauciones puede manipular el firmware para ejecutar su propio código en la parte superior del kernel e interceptar el acceso al sistema de archivos, por ejemplo, a boot, y este le presente los archivos no protegidos. En general, ninguna medida de seguridad por debajo del nivel del firmware puede garantizar la fiabilidad y la evidencia de falsificación.

El script con instrucciones de instalación está disponible (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2), También hay un paquete chkboot^AUR para instalar.

Después de la instalación, agregue un archivo de servicio (el paquete incluye uno basado en lo siguiente) y actívelo:

[Unit]
Description=Check that boot is what we want
Requires=basic.target
After=basic.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/chkboot.sh

[Install]
WantedBy=multi-user.target

Hay una pequeña advertencia para systemd. Al momento de escribir (este artículo), el script original chkboot.sh suministrado contiene un espacio vacío al comienzo de #!/bin/bash que debe ser eliminado para que el servicio se inicie con éxito.

Como /usr/local/bin/chkboot_user.sh debe ejecutarse justo después del inicio de sesión, debe agregarlo al inicio automático (por ejemplo, en KDE -> Configuración del sistema -> Inicio y apagado -> Autostart ; en GNOME 3: gnome-session-properties).

Con Arch Linux, los cambios en /boot son bastante frecuentes, por ejemplo, con la incorporación de nuevos kernels. Por lo tanto, puede ser útil usar los scripts con cada actualización completa del sistema. Una forma de hacerlo sería:

#!/bin/bash
#
# Nota: inserte su <usuario> y ejecútelo con sudo para que pacman y chkboot funcionen automáticamente
#
echo "Pacman update [1] Quickcheck before updating" & 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
/usr/local/bin/chkboot.sh
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
/usr/local/bin/chkboot.sh
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user>
echo "Pacman update [3] All done, let us roll on ..."

mkinitcpio-chkcryptoboot

Advertencia: este hook no cifra el código GRUB, el código (MBR) o el apéndice EFI, ni protege contra situaciones en las que un atacante puede modificar el comportamiento del cargador de arranque para comprometer el kernel y/o initramfs en tiempo de ejecución.

mkinitcpio-chkcryptoboot^AUR es un hook de mkinitcpio (Español) que realiza verificaciones de integridad durante el primer espacio de usuario y aconseja al usuario que no ingrese su contraseña para desbloquear la partición raíz si el sistema parece estar comprometido. La seguridad se logra a través de una partición de arranque cifrada, que se desbloquea utilizando el módulo cryptodisk.mod para GRUB, y una partición del sistema de archivos raíz, que se cifra con una contraseña diferente de la anterior. De esta manera, Initramfs (Español) y el kernel (Español) están protegidos contra la manipulación fuera de línea, y la partición raíz puede permanecer segura incluso si la contraseña de la partición /boot se ingresa en un equipo comprometido (siempre que el hook chkcryptoboot detecte que el equipo se ha visto comprometido, y el mismo no se ha visto comprometido en tiempo de ejecución).

Este hook requiere la versión >=2.00 del paquete grub para que funcione, y una partición dedicada, /boot cifrada con LUKS con su propia contraseña para que sea seguro.

Instalación

Instale mkinitcpio-chkcryptoboot^AUR y edite /etc/default/chkcryptoboot.conf. Si desea disponer de la capacidad de detectar si su partición de arranque se baipaseó (o puenteó), modifique las variables CMDLINE_NAME y CMDLINE_VALUE con valores que solo usted conozca. Puede seguir el consejo de usar dos funciones de hash como se sugiere, inmediatamente después de la instalación. Además, asegúrese de hacer los cambios apropiados en la línea de órdenes del kernel en /etc/default/grub. Edite la línea HOOKS= en /etc/mkinitcpio.conf, e inserte el hook chkcryptoboot antes de encrypt. Cuando haya terminado, regenere initramfs.

Descripción técnica

mkinitcpio-chkcryptoboot^AUR consiste en un hook de instalación y un hook en tiempo de ejecución para mkinitcpio. El hook de instalación se ejecuta cada vez que se reconstruye initramfs, y comprueba el hash del apéndice de EFI system partition (Español) de GRUB ($esp/EFI/grub_uefi/grubx64.efi) (en el caso de los sistemas Unified Extensible Firmware Interface (Español) ) o los primeros 446 bytes del disco en el que está instalado GRUB (en el caso de los sistemas BIOS), y almacena ese hash dentro de los initramfs ubicados dentro de la partición cifrada /boot. Cuando se inicia el sistema, GRUB solicita la contraseña para desbloquear /boot, luego el hook en tiempo de ejecución realiza la misma operación de comparación de hash antes de solicitar la contraseña de la partición raíz. Si no coinciden, el hook imprimirá un error como este:

CHKCRYPTOBOOT ALERT!
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!
Please type uppercase yes to continue:

Además del hash del cargador de arranque, el hook también verifica los parámetros del kernel en ejecución con los configurados en /etc/default/chkcryptoboot.conf. Esto se comprueba tanto en tiempo de ejecución como después de que se realiza el proceso de arranque. Esto permite que el hook detecte si la configuración de GRUB no se baipaseó tanto en el tiempo de ejecución como después, para detectar si la partición /boot completa ha sido manipulada.

Para los sistemas BIOS, el hook crea un hash del gestor de arranque de la primera etapa de GRUB (instalado en los primeros 446 bytes del dispositivo de arranque) para compararlo en los procesos de arranque posteriores. La segunda etapa principal del gestor de arranque GRUB, core.img, no será comprobado.

AIDE

Como alternativa a los scripts anteriores, se puede configurar una comprobación de hash con AIDE que se puede personalizar a través de un archivo de configuración muy flexible.

STARK

Si bien alguno de los métodos descritos arriba deberían dar respuesta a la demanda de la mayoría de los usuarios, los mismos no resuelven todos los problemas de seguridad que se pueden presentar asociados con /boot sin cifrar. Un enfoque que intenta proporcionar una cadena de arranque completamente autenticada fue publicado con POTTS como una tesis académica para implementar el marco de autenticación STARK

La prueba de concepto de POTTS utiliza Arch Linux como una distribución base e implementa una cadena de arranque del sistema con:

POTTS: un menú de inicio para un mensaje de autenticación de una sola vez.
TrustedGrub - una implementación de GRUB Legacy que autentica el kernel e initramfs contra los registros de chips TPM.
TRESOR: un parche del kernel que implementa AES pero mantiene la clave maestra no en la RAM sino en los registros de la CPU durante el tiempo de ejecución.

Como parte de la tesis installation, se han publicado instrucciones basadas en Arch Linux (ISO a partir de 2013-01). Si desea probarlo, tenga en cuenta que estas herramientas no se encuentran en los repositorios estándar y que la solución llevará mucho tiempo de mantenimiento.

Utilizar archivos de claves cifrados con GPG, LUKS o OpenSSL

Las siguientes publicaciones del foro brindan instrucciones para usar dos factores de autenticación, archivos de claves cifrados con gpg o openssl, en lugar de un archivo de clave de texto plano descrito anteriormente en este artículo wiki System Encryption using LUKS with GPG encrypted keys:

GnuPG: Post regarding GPG encrypted keys Esta publicación tiene las instrucciones genéricas.
OpenSSL: Post regarding OpenSSL encrypted keys Esta publicación solo tiene los hooks ssldec.
OpenSSL: Post regarding OpenSSL salted bf-cbc encrypted keys Esta publicación tiene los hooks bfkf de initcpio, install y el script generador del archivo de claves cifrado.
LUKS: Post regarding LUKS encrypted keys con un hook lukskey de initcpio. O #/boot cifrado y un encabezado LUKS separado en USB a continuación con un hook encrypt personalizado para initcpio.

Tenga en cuenta que:

Puede seguir las instrucciones anteriores con solo dos particiones primarias, una partición de arranque (requerida debido al cifrado) y una partición LVM primaria. Dentro de la partición LVM puede tener tantas particiones como necesite, pero lo más importante es que contenga volumenes lógicos para, al menos, las particiones raíz, de intercambio y «home». Esto tiene la ventaja adicional de tener solo un archivo de claves para todas sus particiones y tener la capacidad de hibernar su equipo (suspender en disco) donde la partición de intercambio está encriptada. Si decide hacerlo, los hooks en /etc/mkinitcpio.conf deberían tener este aspecto:
```
HOOKS=( ... usb usbinput (etwo o ssldec) encrypt (si se utiliza openssl) lvm2 resume ... )
```
y debe agregar
```
resume=/dev/<NombredelGrupodeVolúmenes>/<NombredelVolumenLógicodeIntecambio>
```
a sus parámetros del kernel.
Si necesita almacenar temporalmente el archivo de claves desencriptado en algún lugar, no lo almacene en un disco sin cifrado. Es mejor asegúrese de guardarlos en la memoria RAM como /dev/shm.
Si desea usar un archivo de claves encriptado con GPG, necesita usar una versión 1.4 de GnuPG compilada estáticamente o puede editar los hooks y usar este paquete AUR gnupg1^AUR
Es posible que una actualización de OpenSSL pueda romper el hook ssldec personalizado, mencionada en la segunda publicación del foro.

Desbloqueo remoto de la partición (u otro volumen) raíz

Si desea poder reiniciar un sistema totalmente cifrado con LUKS de forma remota, o iniciarlo con un servicio Wake-on-LAN (véase también), necesitará una forma de ingresar una frase de contraseña para la partición/volumen raíz en el inicio. Esto se puede lograr ejecutando un hook de mkinitcpio (Español) que configure una interfaz de red. Algunos de los paquetes que se enumeran a continuación contribuyen con varios hooks compilados de mkinitcpio para facilitar la configuración.

Nota:

Tenga en cuenta que debe usar los nombres de dispositivos del kernel para la interfaz de red (por ejemplo, eth0) y no uno de udev (Español) (por ejemplo, enp1s0), ya que no funcionarán.
Podría ser necesario agregar el módulo de su tarjeta de red a la matriz MODULES.

Desbloqueo remoto (hooks: systemd, systemd-tool)

El paquete de AUR mkinitcpio-systemd-tool proporciona un hook systemd pensado para mkinitcpio denominado systemd-tool con el siguiente conjunto de características para systemd en initramfs:

Características principales proporcionadas por el hook: configuración unificada systemd + mkinitcpio aprovisionamiento automático de recursos binarios y de configuración invocación bajo demanda de scripts mkinitcpio y funciones en línea	Características proporcionadas por las unidades de servicio incluidas: depuración de errores de initrd configuración de red temprana intérprete de órdenes de usuario interactiva acceso ssh remoto en initrd cryptsetup + agente de contraseña personalizada

El paquete mkinitcpio-systemd-tool requiere el hook systemd. Para obtener más información, lea README del proyecto, así como el valor predeterminado proporcionado por defecto por systemd service unit files para comenzar.

Los hooks recomendados son: base autodetect modconf block filesystems keyboard fsck systemd systemd-tool.

Desbloqueo remoto (hooks: netconf, dropbear, tinyssh, ppp)

Otra combinación de paquetes que proporciona inicios de sesión remotos para initcpio es mkinitcpio-netconf y/o mkinitcpio-ppp^AUR (para el desbloqueo remoto usando un Protocolo punto a punto (PPP) —en inglés Point-to-Point Protocol— de conexión a través de Internet) junto con un servidor OpenSSH (Español). Tiene la opción de usar mkinitcpio-dropbear o mkinitcpio-tinyssh. Esos hooks no instalan ningún intérprete de órdenes, por lo que también debe instalar el paquete mkinitcpio-utils. Las instrucciones a continuación se pueden utilizar con cualquier combinación de los paquetes anteriores. Cuando haya diferentes caminos, se advertirá.

Si aún no tiene un par de claves SSH, genere uno en el sistema cliente (el que se usará para desbloquear la máquina remota).
Nota: tinyssh solo admite los tipos de claves Ed25519 y ECDSA. Si elige usar mkinitcpio-tinyssh, necesitará crear/usar una de estas.
Inserte su clave pública SSH (es decir, la que normalmente coloca en los hosts para poder ingresar sin contraseña, o la que acaba de crear y que termina en .pub ) en el archivo /etc/dropbear/root_key o /etc/tinyssh/root_key del equipo remoto.
Sugerencia: este método se puede usar más adelante para agregar otras claves públicas SSH según sea necesario; en el caso de que simplemente esté copiando el contenido el archivo ~/.ssh/authorized_keys remoto, asegúrese de verificar que solo contenga las claves que desea utilizar para desbloquear la máquina remota. Si agrega claves adicionales, regenere initrd también usando mkinitcpio. Vea también Secure Shell (Español)#Protección.
Agregue los tres hooks,<netconf y/o ppp> <dropbear o tinyssh> encryptssh antes de filesystems dentro de la matriz «HOOKS» en /etc/mkinitcpio.conf (el hook encryptssh reemplaza al hook encrypt). Después regenere initramfs.
Nota: El hook net proporcionado por mkinitcpio-nfs-utils no es necesario.
Configure el parámetro cryptdevice= requerido y agregue el parámetro del kernel ip= a la configuración de su gestor de arranque con los argumentos apropiados. Por ejemplo, si el servidor DHCP no atribuye una IP estática a su sistema remoto, lo que dificultaría el acceso con SSH a través de reinicios, puede indicar explícitamente la IP que desea usar:
```
ip=192.168.1.1:::::eth0:none
```
Alternativamente, también puede especificar la máscara de subred y la puerta de enlace requeridas por la red:
```
ip=192.168.1.1::192.168.1.254:255.255.255.0::eth0:none
```
Nota: a partir de la versión 0.0.4 de mkinitcpio-netconf, puede anidar múltiples parámetros ip= con el fin de configurar múltiples interfaces. No puede mezclarlo con ip=dhcp (ip=:::::eth0:dhcp) solo. Se debe especificar una interfaz.
```
ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none
```
Para una descripción detallada eche un vistazo a la sección de mkinitcpio. Cuando termine, actualice la configuración de su gestor de arranque.
Finalmente, reinicie el sistema remoto e intente ejecutar ssh para él, indicando explícitamente el nombre de usuario «root» (incluso si la cuenta de root está desactivada en la máquina, ya que este usuario root se utiliza solo en initrd con el propósito de desbloquear el sistema remoto). Si está utilizando el paquete mkinitcpio-dropbear y también tiene el paquete openssh instalado, lo más probable es que no reciba ninguna advertencia antes de iniciar sesión, ya que convierte y usa el mismo juego de claves openssh del host (excepto las claves Ed25519, ya que dropbear no las admite). En caso de que esté utilizando mkinitcpio-tinyssh, tiene la opción de instalar tinyssh-convert^{[enlace roto: replaced by tinyssh]} o tinyssh-convert-git^AUR para que pueda usar las mismas claves que su instalación openssh (actualmente solo son claves Ed25519). En cualquier caso, debería haber ejecutado el demonio ssh al menos una vez, utilizando las unidades systemd suministradas, para que las claves se puedan generar primero. Después de reiniciar la máquina, se le solicitará que introduzca la contraseña para desbloquear el dispositivo raíz. El sistema completará su proceso de arranque y luego puede iniciar sesión en él como lo haría normalmente (con el usuario remoto que elija).

Sugerencia: si simplemente desea una buena solución para montar otras particiones cifradas (como /home) de forma remota, puede consultar este hilo del foro.

Desbloqueo remoto a través de wifi (hooks: construya el suyo propio)

El hook net se usa normalmente con una conexión cableada. En caso de que desee configurar un equipo que solo dispone de conexión inalámbrica y desbloquearla a través de wifi, puede crear un hook personalizado para conectarse a una red wifi antes de ejecutar el hook de red, net.

El siguiente ejemplo muestra una configuración utilizando un adaptador wifi USB, que se conecta a una red wifi protegida con WPA2-PSK. En caso de que utilice, por ejemplo, WEP u otro, es posible que necesite cambiar algunas cosas.

Modifique /etc/mkinitcpio.conf:
- Agregue el módulo del kernel necesario para su adaptador wifi específico.
- Incluya los archivos binarios wpa_passphrase y wpa_supplicant.
- Agregue un hook wifi (o el nombre que elija, este es el hook personalizado que se creará) antes del hook net.
```
MODULES=(módulo)
BINARIES=(wpa_passphrase wpa_supplicant)
HOOKS=(base udev autodetect ... wifi net ... dropbear encryptssh ...)
```

Cree el hook wifi en /etc/initcpio/hooks/wifi:

run_hook ()
{
	# demorar unos segundos, dejando que wlan0 sea configurado por kernel
	sleep 5

	# configurar wlan0 a up
	ip link configurar wlan0 up

	# asociar con la red wifi
	# 1. guardar el archivo config temporal
	wpa_passphrase « network ESSID » « passrase »> /tmp/wifi 

	# 2. crear asociación
	wpa_supplicant -B -D nl80211, wext -i wlan0 -c /tmp/wifi

	# demorar unos segundos para que wpa_supplicant termine de conectarse
	sleep 5

	# wlan0 ahora debería estar conectado y listo para que el hook net pueda asignar una ip
}

	run_cleanuphook ()
{
	# wpa_supplicant que se ejecuta en segundo plano
	killall wpa_supplicant

	# configurar wlan0 link a down 
	ip link set wlan0 down

	# wlan0 ahora debería estar completamente desconectado de la red wifi
}

Cree el archivo de instalación de hook en/etc/initcpio/install/wifi:

build ()
{
	add_runscript
}
help ()
{
cat<<HELPEOF
	Activar wifi en el arranque, para desbloquear dropbear ssh del disco..
HELPEOF
}

Agregue ip=:::::wlan0:dhcp a los parámetros del kernel. Elimine ip=:::::eth0:dhcp para que no entre en conflicto.
Opcionalmente, cree una entrada de arranque adicional con el parámetro del kernel ip=:::::eth0:dhcp.
Regenere initramfs.
Actualice la configuración de su cargador de arranque.

Recuerde configurar wifi, de modo que pueda iniciar sesión una vez que el sistema haya arrancado completamente. En caso de que no pueda conectarse a la red wifi, intente aumentar los tiempos de demora un poco.

Soporte Discard/TRIM para unidades de estado sólido (SSD)

Los usuarios de unidades de estado sólido deben tener en cuenta que, de forma predeterminada, las órdenes TRIM no están activadas por el mapeador de dispositivos, es decir, los dispositivos de bloque se montan sin la opción discard a menos que anule el valor predeterminado.

Los mantenedores de device-mapper han dejado claro que la compatibilidad con TRIM nunca se activará de forma predeterminada en los dispositivos dm-crypt debido a las posibles implicaciones de seguridad. [3][4] Es posible la fuga mínima de datos en forma de información liberada del bloque, tal vez suficiente para determinar el sistema de archivos en uso, en dispositivos con TRIM activado. Una ilustración y discusión de los problemas que surgen de la activación de TRIM está disponible en el blog de un desarrollador de «cryptsetup». Si le preocupan estos factores, también tenga en cuenta que las amenazas pueden aumentar: por ejemplo, si su dispositivo todavía está cifrado con el algoritmo de cifrado predeterminado anterior (cryptsetup <1.6.0) --cipher aes-cbc-essiv, es posible que se produzcan más fugas de información a partir de la observación del sector «trimmed», que con las actuales opciones de cifrado predeterminadas.

Se distinguen los siguientes casos:

El dispositivo está cifrado con la modalidad LUKS de dm-crypt predeterminado:
- De forma predeterminada, el encabezado LUKS se almacena al comienzo del dispositivo y usar TRIM es útil para proteger las modificaciones del encabezado. Si, por ejemplo, se revoca una contraseña LUKS comprometida, sin TRIM activado, el encabezado anterior en general todavía estará disponible para leer hasta que otra operación lo sobrescriba; mientras tanto, si se roba la unidad, los atacantes podrían, en teoría, encontrar una manera de localizar el encabezado anterior y usarlo para descifrar el contenido con la contraseña comprometida. Consulte cryptsetup, sección 5.19 ¿Qué hay de las unidades de estado sólido, flash y unidades híbridas? y Cifrado de disco completo en un ssd.
- TRIM puede dejarse desactivado si los problemas de seguridad indicados en la parte superior de esta sección se consideran una amenaza peor que los indicados en la viñeta anterior.

Véase también Securely wipe disk#Flash memory.

El dispositivo está cifrado con la modalidad plain de dm-crypt, o el encabezado LUKS se almacena por separado:
- Si se requiere una negación plausible, TRIM nunca debe ser usado debido a las consideraciones dadas en la parte superior de esta sección, o el uso del cifrado se dará a conocer.
- Si no se requiere una negación plausible, se puede usar TRIM por sus mejoras de rendimiento, siempre que los peligros de seguridad descritos en la parte superior de esta sección no sean motivo de preocupación.

Advertencia: antes de activar TRIM en una unidad, asegúrese de que el dispositivo sea totalmente compatible con las órdenes TRIM, o de lo contrario puede provocar pérdida de datos. Consulte Solid State Drives#TRIM.

En versiones 3.1 de linux y posteriores, el soporte para TRIM de dm-crypt se puede alternar al crear el dispositivo o montarlo con dmsetup. El soporte para esta opción también existe en la versión 1.4.0 de cryptsetup y superior. Para agregar soporte durante el arranque, deberá añadir :allow-discards a la opción cryptdevice. La opción TRIM puede verse así:

cryptdevice=/dev/sdaX:root:allow-discards

Para las opciones de configuración principales de cryptdevice antes de :allow-discards vea Dm-crypt/System configuration (Español).

Si está utilizando initrd basado en systemd, debe pasar la opción:

rd.luks.options=discard

Nota: la opción rd.luks.options=discard del kernel no tiene ningún efecto en los dispositivos incluidos en el archivo /etc/crypttab para la imagen de initramfs (/etc/crypttab.initramfs en la raíz real). Debe especificar la opción discard en /etc/crypttab.initramfs.

Además de la opción del kernel, también se requiere ejecutar periódicamente fstrim o montar el sistema de archivos (por ejemplo, /dev/mapper/root en este ejemplo) con la opción discard en /etc/fstab. Para obtener más información, consulte la página de TRIM.

Para los dispositivos LUKS desbloqueados a través de /etc/crypttab use la opción discard, por ejemplo:

/etc/crypttab

luks-123abcdef-etc UUID=123abcdef-etc none discard

Cuando desbloquee manualmente los dispositivos en la consola, use --allow-discards.

Con LUKS2 puede establecer allow-discards como un indicador predeterminado para un dispositivo abriéndolo una vez con la opción --persistent:

# cryptsetup --allow-discards --persistent open --type luks2 /dev/sdaX root

Puede confirmar que el indicador se ha establecido de forma permanente en el encabezado LUKS2 comprobando la salida de cryptsetup luksDump

# cryptsetup luksDump /dev/sdaX | grep Flags

Flags:          allow-discards

En cualquier caso, puede verificar si el dispositivo realmente se abrió con discards inspeccionando la salida de dmsetup table:

# dmsetup table

luks-123abcdef-etc: 0 1234567 crypt aes-xts-plain64 000etc000 0 8:2 4096 1 allow_discards

El hook encrypt y varios discos

Sugerencia: el hook sd-encrypt admite el desbloqueo de múltiples dispositivos. Se pueden especificar en la línea de órdenes del kernel o en el archivo /etc/crypttab.initramfs. Consulte dm-crypt/System configuration (Español)#Utilizar el hook sd-encrypt.

El hook encrypt solo permite una única entrada cryptdevice= (FS#23182). En las configuraciones del sistema con múltiples unidades, esto puede ser limitante, ya que dm-crypt no tiene una función que permita exceder al dispositivo físico. Por ejemplo, tomemos «LVM sobre LUKS»: todo el volumen LVM existe dentro de un mapeado LUKS. Esto está perfectamente bien para un sistema de una sola unidad, ya que solo hay un dispositivo para descifrar. Pero, ¿qué sucede cuando desea aumentar el tamaño de LVM? No puede, al menos no sin modificar el hook encrypt.

Las siguientes secciones muestran sucintamente las alternativas para superar dicha limitación. El primero trata sobre cómo expandir una configuración LUKS sobre LVM a un nuevo disco. El segundo consiste en la modificación del hook encrypt para poder desbloquear varios discos en las configuraciones LUKS sin LVM.

Expandir LVM en varios discos

La gestión de discos múltiples es una característica básica de LVM (Español) y una de las principales razones para su flexibilidad de particionado. También se puede utilizar con dm-crypt, pero solo si se emplea LVM como primer mapeador. En tal configuración LUKS sobre LVM los dispositivos encriptados se crean dentro de los volúmenes lógicos (con una clave/contraseña por volumen). Lo siguiente cubre los pasos para saber cómo expandir esa configuración a otro disco.

Advertencia: realice una copia de seguridad. Si bien el cambio de tamaño de los sistemas de archivos puede estar estandarizada, tenga en cuenta que las operaciones pueden ir mal y lo explicado a continuación podría no ajustarse a su configuración particular. En general, extender un sistema de archivos para liberar espacio en el disco es menos problemático que reducir uno. Esto se aplica, en particular, cuando se usan mapeadores apilados, como es el caso del siguiente ejemplo.

Añadir una nueva unidad

Primero, prepare un nuevo disco de acuerdo con dm-crypt/Drive preparation (Español). Segundo, partíciónelo como un LVM, por ejemplo, asigne todo el espacio a /dev/sdY1 con el tipo de partición 8E00 (Linux LVM). Y tercero, adjunte el nuevo disco/partición al grupo de volúmenes LVM existente, por ejemplo:

# pvcreate /dev/sdY1
# vgextend MyStorage /dev/sdY1

Extender el volumen lógico

El siguiente paso, consiste en la asignación final del nuevo espacio del disco al el volumen lógico que se va a extender, para lo cual dicho volumen lógico tiene que ser desmontado. Se puede realizar para la partición raíz cryptdevice, pero en este caso el procedimiento se debe realizar desde una imagen ISO de instalación de Arch.

En este ejemplo, se supone que el volumen lógico para /home (nombre del volúmen lógico homevol) se expandirá al espacio del disco nuevo:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Ahora, una vez extendido el volumen lógico, el contenedor LUKS viene a continuación:

# cryptsetup open /dev/MyStorage/homevol home
# umount /home      # Como seguridad, para el caso de que fuera automática remontar
# cryptsetup --verbose resize home

Finalmente, redimensionamos el sistema de archivos:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home

¡Hecho! Si este era su plan, /home se puede volver a montar y ahora incluirá el espacio del nuevo disco:

# mount /dev/mapper/home /home

Tenga en cuenta que la acción cryptsetup resize no afecta a las claves de cifrado y, por tanto, estas no habrán cambiado.

Modificar el hook encrypt para varias particiones

Sistema de archivos raíz que abarca múltiples particiones

Es posible modificar el hook encrypt para permitir descifrar múltiples unidades de disco duro raíz (/) en el arranque. En un solo paso:

# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
# cp /usr/lib/initcpio/hooks/encrypt  /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2

Agregue cryptdevice2= a sus opciones de arranque (y cryptkey2= si es necesario), y agregue el hook encrypt2 a mkinitcpio.conf antes de regenerarlo. Vea dm-crypt/System configuration (Español).

Múltiples particiones no root

Tal vez tenga la necesidad de usar el hook encrypt en una partición no root. Arch no admite esto de forma automática sino que necesita intervención manual, sin embargo, puede cambiar fácilmente los valores de cryptdev y cryptname en /lib/initcpio/hooks/encrypt (el primero en su partición /dev/sd*, el segundo para el nombre que desea atribuirle). Eso debería bastar.

La gran ventaja es que puede tener todo automatizado, mientras que configurar /etc/crypttab con un archivo de claves externa (es decir, el archivo de claves no está en ninguna partición interna del disco duro) puede ser una molestia. Asegúrese de que el dispositivo USB/FireWire/... se monte antes que la partición encriptada, lo que significa que debe cambiar el orden de /etc/fstab (al menos).

Por supuesto, si se actualiza el paquete cryptsetup, tendrá que cambiar este script nuevamente. A diferencia de /etc/crypttab, solo se admite una partición, pero con un poco más de picardía se pueden desbloquear varias particiones.

Si desea implementar esto en una partición RAID por software, hay una cosa más que debe hacer. No basta con configurar el dispositivo /dev/mdX en /lib/initcpio/hooks/encrypt; el hook encrypt fallará al no poder encontrar la clave por algún motivo y tampoco mostrará un prompt para pedirle una contraseña. Parece que los dispositivos RAID no se activan hasta que se ejecuta el hook encrypt. Puede resolver esto colocando la matriz RAID en /boot/grub/menu.lst, así:

kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5

Si configura su partición raíz como un RAID, advertirá avisos similares con esa configuración. GRUB (Español) puede manejar múltiples definiciones de matriz muy bien:

kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

Sistema cifrado usando un encabezado LUKS separado

Este ejemplo sigue la misma configuración que en dm-crypt/Encrypting an entire system (Español)#Modalidad plain de dm-crypt, que debería leer primero antes de seguir esta guía.

Al utilizar un encabezado separado, el dispositivo de bloque cifrado solo transporta datos cifrados, lo que proporciona cifrado denegable siempre que los atacantes no conozcan la existencia de un encabezado. Es similar a usar la modalidad plain de dm-crypt, pero con las ventajas de LUKS como la posibilidad de usar varias contraseñas para desbloquear la clave maestra y la función de derivación de la clave. Además, el uso de un encabezado separado ofrece una forma de autenticación de dos factores con una configuración más fácil que usar un achivo de claves cifrado con GPG u OpenSSL, ya que tendrá un prompt solicitando la contraseña que permite reintentos múltiples. Consulte Disk encryption (Español)#Metadatos criptográficos para obtener más información.

Consulte dm-crypt/Device encryption (Español)#Opciones de cifrado para la modalidad LUKS para ver las opciones de cifrado antes de realizar el primer paso para configurar la partición del sistema cifrado y crear un archivo de encabezado para usar con cryptsetup:

# dd if=/dev/zero of=header.img bs=4M count=1 conv=notrunc
# cryptsetup luksFormat --type luks2 /dev/sdX --align-payload 8192 --header header.img

Sugerencia: cuando use la opción --header, --align-payload permite especificar el inicio de datos cifrados en un dispositivo. Al reservar un espacio al comienzo del dispositivo, tiene la opción posteriormente de volver a colocar el encabezado LUKS. Consulte cryptsetup(8) para conocer los valores admitidos por--align-payload.

Abra el contenedor:

# cryptsetup open --header header.img /dev/sdX enc

Ahora siga los pasos de la configuración de LVM sobre LUKS según sus necesidades. Lo mismo se aplica a la preparación de la partición de arranque en el dispositivo extraíble (porque de lo contrario, no tiene sentido tener un archivo de encabezado separado para desbloquear el cifrado disco). Luego mueva el header.img sobre él:

# mv header.img /mnt/boot

Siga el procedimiento de instalación hasta el paso mkinitcpio (ahora debería realizar arch-chroot dentro del sistema cifrado).

Sugerencia: Se dará cuenta de que, como la partición del sistema solo tiene datos «aleatorios», no tiene una tabla de particiones y, por lo tanto, un UUID o un LABEL. Pero aún puede tener una mapeado consistente utilizando el Persistent block device naming (Español)#by-id y by-path. Por ejemplo usando la identificación del disco de /dev/disk/by-id/.

Hay dos opciones para que initramfs admita un encabezado LUKS separado.

Utilizar el hook systemd

Primero cree /etc/crypttab.initramfs y agregue el dispositivo cifrado a él. La sintaxis se define en crypttab(5)

/etc/crypttab.initramfs

enc	/dev/disk/by-id/your-disk_id	none	header=/boot/header.img

Modifique /etc/mkinitcpio.conf para usar systemd y agregue la imagen header a FILES.

/etc/mkinitcpio.conf

...
FILES=(/boot/header.img)
...
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)
...

Regenerar initramfs y listo.

Nota: no es necesario pasar ningún parámetro cryptsetup a la línea de órdenes del kernel, ya que /etc/crypttab.initramfs se agregará como /etc/crypttab en initramfs. Si desea especificarlos en la línea de órdenes del kernel, consulte dm-crypt/System configuration (Español)#Utilizar el hook sd-encrypt para ver las opciones admitidas.

Modificar el hook encrypt

Este método muestra cómo modificar el hook encrypt para usar un encabezado LUKS separado. Ahora el hook encrypt debe modificarse para que cryptsetup use el encabezado separado (FS#42851; fuente base e idea para estos cambios publicado en BBS). Haga una copia para que no se sobrescriba en una actualización de mkinitcpio (Español):

# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2

/etc/initcpio/hooks/encrypt2 (around line 52)

warn_deprecated() {
    echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
    echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
}

local headerFlag=false
for cryptopt in ${cryptoptions//,/ }; do
    case ${cryptopt} in
        allow-discards)
            cryptargs="${cryptargs} --allow-discards"
            ;;  
        header)
            cryptargs="${cryptargs} --header /boot/header.img"
            headerFlag=true
            ;;
        *)  
            echo "Encryption option '${cryptopt}' not known, ignoring." >&2 
            ;;  
    esac
done

if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
    if $headerFlag || cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
        [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
        dopassphrase=1

Ahora edite el archivo mkinitcpio.conf para agregar los hooks encrypt2 y lvm2 a HOOKS, el archivo header.img a FILES y el modulo loop a MODULES, aparte de otras configuraciones que requiera el sistema:

/etc/mkinitcpio.conf

...
MODULES=(loop)
...
FILES=(/boot/header.img)
...
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt2 lvm2 filesystems fsck)
...

Esto es necesario para que el encabezado LUKS esté disponible en el arranque y permita el descifrado del sistema, eximiéndonos de una configuración más complicada como montar otro dispositivo USB separado para acceder al encabezado. Después de esta configuración se creará initramfs.

A continuación, configure el cargador de arranque para especificar cryptdevice= pasando también la nueva opción header a dicha configuración:

cryptdevice=/dev/disk/by-id/your-disk_id:enc:header

Para finalizar, seguimos dm-crypt/Encrypting an entire system (Español)#Posinstalación que es particularmente útil con una partición /boot en un medio de almacenamiento USB.

/boot cifrado y un encabezado LUKS separado en USB

En lugar de incrustar la imagen header.img y el archivo de claves en initramfs, esta configuración hará que su sistema dependa completamente de la llave usb en lugar de tan solo la imagen de arranque, y del archivo de claves cifrado que contiene la partición de arranque cifrada. Como el encabezado y el archivo de claves no están embebidos en la imagen initramfs y el hook encrypt personalizado está específicamente para by-id, literalmente necesitará la llave usb para arrancar.

Para la unidad usb, ya que está cifrando la unidad y el archivo de claves en su interior, es preferible colocar en cascada los algoritmos de cifrado para no usar el mismo dos veces. Es discutible si un ataque de intermediario sería realmente factible. Puede ser twofish-serpent o serpent-twofish.

Preparar las particiones de los discos

Se asumirá que sdb es la unidad USB, y que sda es el disco duro principal.

Prepare los dispositivos de acuerdo con dm-crypt/Drive preparation (Español).

Preparar la llave USB

Utilice gdisk para particionar el disco según el diseño mostrado aquí, con la excepción de que solo debe incluir las dos primeras particiones. De este modo:

# gdisk /dev/sdb

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624         1460223   200.0 MiB   8300  Linux filesystem

Antes de ejecutar cryptsetup, consulte opciones de cifrado para la modalidad LUKS y algoritmos de cifrado y modalidades de operación .

Prepare la partición de arranque pero no ejecute mount sobre ninguna partición todavía y formatee la partición del sistema EFI.

# mount /dev/mapper/cryptboot /mnt
# dd if=/dev/urandom of=/mnt/key.img bs=tamaño_del_archivo count=1
# cryptsetup --align-payload=1 luksFormat /mnt/key.img
# cryptsetup open /mnt/key.img lukskey

El tamaño_del_archivo está en bytes pero puede ir seguido de un sufijo como M. Tener un archivo demasiado pequeño le dará un desagradable error Requested offset is beyond real size of device /dev/loop0. Como referencia aproximada, la creación de un archivo de 4M lo cifrará correctamente. Debe hacer que el archivo sea más grande que el espacio necesario, ya que el dispositivo loop cifrado será un poco más pequeño que el tamaño del archivo.

Con un archivo grande, puede usar --keyfile-offset=desplazamiento y --keyfile-size=tamaño para navegar a la posición correcta. [5]

Ahora debería tener lukskey abierto en un dispositivo loop (en /dev/loop1), mapeado como /dev/mapper/lukskey.

Preparar la unidad principal

# truncate -s 2M /mnt/header.img
# cryptsetup --key-file=/dev/mapper/lukskey --keyfile-offset=desplazamiento --keyfile-size=tamaño luksFormat /dev/sda --align-payload 4096 --header /mnt/header.img

Elija un desplazamiento y un tamaño en bytes (8192 bytes es el tamaño máximo de archivo de claves para cryptsetup).

# cryptsetup open --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=offset --keyfile-size=size /dev/sda enc 
# cryptsetup close lukskey
# umount /mnt

Siga con los pasos para la preparación de los volúmenes lógicos para configurar LVM sobre LUKS.

Consulte Partitioning (Español)#Particiones dedicadas para obtener recomendaciones sobre el tamaño de sus particiones.

Una vez que su partición raíz esté montada, realice mount sobre su partición de arranque cifrada como /mnt/boot y su partición del sistema EFI como /mnt/efi.

Procedimiento de instalación y personalización del hook encrypt

Siga la installation guide (Español) hasta el paso mkinitcpio pero no lo haga todavía, y omita los pasos de partición, formateo y montaje como ya se han hecho.

Para que la configuración cifrada funcione, necesita crear su propio hook, que afortunadamente es fácil de hacer y aquí está el código que necesita. Tendrá que seguir Persistent block device naming (Español)#by-id y by-path para averiguar sus propios valores by-id para el disco usb y para el disco principal (están vinculados -> a sda o sdb).

Debería usar by-id en lugar de sda o sdb porque sdX puede cambiar, y aquel garantiza que sea el dispositivo correcto .

Puede nombrar customencrypthook como quiera, y los hooks de compilación personalizados se pueden colocar en las carpetas hooks e install de /etc/initcpio. Mantenga una copia de seguridad de ambos archivos (cp a la partición /home o al directorio /home de su usuario después de crearlos). /usr/bin/ash no es un error tipográfico.

/etc/initcpio/hooks/customencrypthook

#!/usr/bin/ash

run_hook() {
    modprobe -a -q dm-crypt >/dev/null 2>&1
    modprobe loop
    [ "${quiet}" = "y" ] && CSQUIET=">/dev/null"

    while [ ! -L '/dev/disk/by-id/usbdrive-part2' ]; do
     echo 'Waiting for USB'
     sleep 1
    done

    cryptsetup open /dev/disk/by-id/usbdrive-part2 cryptboot
    mkdir -p /mnt
    mount /dev/mapper/cryptboot /mnt
    cryptsetup open /mnt/key.img lukskey
    cryptsetup --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' open /dev/disk/by-id/harddrive enc
    cryptsetup close lukskey
    umount /mnt
}

usbdrive es su unidad USB by-id, y harddrive su unidad de disco duro principal by-id.

Sugerencia: también puede cerrar cryptboot usando cryptsetup close, pero tenerlo abierto facilita el montaje de las actualizaciones del sistema usando Pacman (Español) y regenere initramfs con mkinitcpio (Español). La partición /boot debe estar montada para las actualizaciones que afectan al Kernel (Español) o Initramfs (Español), e initramfs se regenerará automáticamente después de estas actualizaciones.

# cp /usr/lib/initcpio/install/encrypt /etc/initpcio/install/customencrypthook

Ahora edite el archivo copiado y elimine la sección help() ya que no es necesaria.

/etc/mkinitcpio.conf (edite solo esta parte, no lo reemplace, estos son solo extractos de las partes necesarias)

MODULES=(loop)
...
HOOKS=(base udev autodetect modconf block customencrypthook lvm2 filesystems keyboard fsck)

Las matrices files=() y binaries=() están vacías, y no debería tener que reemplazar la matriz HOOKS=(...) completa, basta colocar customencrypthook lvm2 después de block y antes de filesystems, y asegúrese de systemd, sd-lvm2 y encrypt son quitados.

Cargador de arranque

Finalice la guía de instalación desde el paso mkinitcpio. Para arrancar, necesitaría GRUB (Español) o Unified Extensible Firmware Interface (Español)#efibootmgr. Tenga en cuenta que puede usar GRUB (Español) para admitir los discos encriptados mediante la configuración del cargador de arranque, pero modificar la línea GRUB_CMDLINE_LINUX no es necesario para esta configuración.

O use Direct UEFI Secure boot para generar claves con cryptboot^AUR, firmando luego initramfs y el kernel y creando un archivo de arranque .efi para la partición del sistema EFI con sbupdate-git^AUR. Antes de usar cryptboot o sbupdate, observe este extracto de Secure Boot#Using your own keys:

Sugerencia: tenga en cuenta que cryptboot^AUR requiere que la partición de arranque cifrada se especifique en /etc/crypttab antes de que se ejecute, y si lo está utilizando en combinación con sbupdate-git^AUR, sbupdate espera a que los archivos /boot/efikeys/db.* creados por cryptboot se capitalicen como DB.* a menos que se configure de otro modo en /etc/default/sbupdate. Los usuarios que no usen systemd para manejar el cifrado pueden no tener nada en su archivo /etc/crypttab y necesitarán crear una entrada.

# efibootmgr -c -d /dev/device -p partition_number -L "Arch Linux Signed" -l "EFI\Arch\linux-signed.efi"

Consulte efibootmgr(8) para obtener una explicación de las opciones.

Asegúrese de que el orden de inicio ponga Arch Linux Signed primero. Si no es así, cámbielo con efibootmgr -o XXXX,YYYY,ZZZZ.

Cambiar el archivo de claves LUKS

# cryptsetup --header /boot/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=offset --keyfile-size=size luksChangeKey /dev/mapper/enc /dev/mapper/lukskey2 --new-keyfile-size=newsize --new-keyfile-offset=newoffset

Después, ejecute cryptsetup close lukskey, haga shred o dd sobre el archivo de claves antiguo con datos aleatorios antes de borrarlo, y asegúrese de que el nuevo archivo de claves tenga el mismo nombre que el anterior: key.img u otro nombre.