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

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 .

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, ), 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 que debe ser eliminado para que el servicio se inicie con éxito.

Como 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

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 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 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 . Si desea disponer de la capacidad de detectar si su partición de arranque se baipaseó (o puenteó), modifique las variables CMDLINE_NAME y 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 . Edite la línea en , e inserte el hook antes de . Cuando haya terminado, regenere initramfs^{[enlace roto: sección no válida]}.

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 () (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 . 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, , 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 .
• OpenSSL: Post regarding OpenSSL salted bf-cbc encrypted keys Esta publicación tiene los hooks 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 deberían tener este aspecto: y debe agregar 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 .
• 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
• Es posible que una actualización de OpenSSL pueda romper el hook 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.

Desbloqueo remoto (hooks: systemd, systemd-tool)

El paquete de AUR mkinitcpio-systemd-tool proporciona un hook 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: .

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

Otra combinación de paquetes que proporciona inicios de sesión remotos para initcpio es y/o (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 o . Esos hooks no instalan ningún intérprete de órdenes, por lo que también debe instalar el paquete . Las instrucciones a continuación se pueden utilizar con cualquier combinación de los paquetes anteriores. Cuando haya diferentes caminos, se advertirá.

1. Si aún no tiene un par de claves SSH, genere uno^{[enlace roto: sección no válida]} 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.
2. 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 o del equipo remoto.
3. Agregue los tres hooks,<netconf y/o ppp> <dropbear o tinyssh> encryptssh antes de dentro de la matriz «HOOKS» en (el hook reemplaza al hook ). Después regenere initramfs^{[enlace roto: sección no válida]}.
4. Configure el parámetro requerido y agregue el parámetro del kernel 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: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

   Para una descripción detallada eche un vistazo a la sección de mkinitcpio^{[enlace roto: sección no válida]}. Cuando termine, actualice la configuración de su gestor de arranque.
5. 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 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 , tiene la opción de instalar o 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).

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.

1. Modifique :
   • Agregue el módulo del kernel necesario para su adaptador wifi específico.
   • Incluya los archivos binarios y .
   • Agregue un hook wifi (o el nombre que elija, este es el hook personalizado que se creará) antes del hook .
2. Cree el hook wifi en /etc/initcpio/hooks/wifi:
3. Cree el archivo de instalación de hook en:
4. Agregue a los parámetros del kernel. Elimine para que no entre en conflicto.
5. Opcionalmente, cree una entrada de arranque adicional con el parámetro del kernel .
6. Regenere initramfs^{[enlace roto: sección no válida]}.
7. 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 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. 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.

En versiones 3.1 de 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 y superior. Para agregar soporte durante el arranque, deberá añadir a la opción . La opción TRIM puede verse así:

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

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

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

rd.luks.options=discard

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

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

/etc/crypttab

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

Cuando desbloquee manualmente los dispositivos en la consola, use .

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

# 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

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

El hook encrypt y varios discos

El hook solo permite una única entrada (). 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 .

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 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.

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 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 , 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 (nombre del volúmen lógico ) 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, 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 no afecta a las claves de cifrado y, por tanto, estas no habrán cambiado.

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 si es necesario), y agregue el hook 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 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 (el primero en su partición , el segundo para el nombre que desea atribuirle). Eso debería bastar.

La gran ventaja es que puede tener todo automatizado, mientras que configurar 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 (al menos).

Por supuesto, si se actualiza el paquete , tendrá que cambiar este script nuevamente. A diferencia de , 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 ; el hook 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 . Puede resolver esto colocando la matriz RAID en , 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 :

# 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

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 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).

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

Utilizar el hook systemd

Primero cree y agregue el dispositivo cifrado a él. La sintaxis se define en

Modifique para usar systemd^{[enlace roto: sección no válida]} y agregue la imagen header a .

/etc/mkinitcpio.conf

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

Regenerar initramfs^{[enlace roto: sección no válida]} y listo.

Modificar el hook encrypt

Este método muestra cómo modificar el hook para usar un encabezado LUKS separado. Ahora el hook debe modificarse para que use el encabezado separado (; 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

Ahora edite el archivo mkinitcpio.conf para agregar los hooks y a HOOKS, el archivo a y el modulo a , aparte de otras configuraciones que requiera el sistema:

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^{[enlace roto: sección no válida]}.

A continuación, configure el cargador de arranque para especificar pasando también la nueva opción 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 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 es la unidad USB, y que 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 , 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 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 . Tener un archivo demasiado pequeño le dará un desagradable error . 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 y --keyfile-size=tamaño para navegar a la posición correcta.

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

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 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^{[enlace roto: sección no válida]} para obtener recomendaciones sobre el tamaño de sus particiones.

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

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

Siga la installation guide (Español) hasta el paso 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 para el disco usb y para el disco principal (están vinculados -> a o ).

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

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

es su unidad USB , y harddrive su unidad de disco duro principal .

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

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

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

Cargador de arranque

Finalice la guía de instalación desde el paso . 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 no es necesario para esta configuración.

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

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

Consulte 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 .

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 , 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: u otro nombre.