Almacenamiento Seguro: Creando un Sistema de Archivos Cifrado en Linux.

En Linux, el cifrado se realiza a través de dm-crypt usando LUKS igual que la configuración de la clave utilizando la API crypto del Kernel. Esta característica forma parte de Kernel Linux 4.14.18-106 o superior, adicionalmente necesitamos el driver Exynos5422 Slim SSS (Subsistema de seguridad) que admite encriptaciones AES, SHA-1, SHA-256, HMAC-SHA-1 y HMAC-SHA -256. El objetivo de device-mapper es proporcionar un cifrado transparente de los dispositivos de bloque utilizando API crypto del kernel.

• Cifrado AES con soporte aes-cbc/aes-ctr
• Cifrado por bloques (CBC)
• Contador (CTR) conocido como modo contador entero (ICM) y modo contador de enteros segmentados (SIC)
• ESSIV ("Encrypted salt-sector initialization vector") permite al sistema crear IVs basados en un hash que incluye el número del sector y la clave de cifrado
• SHA-256 es el algoritmo hash utilizado para la derivación de claves
• XTS es el modo de encadenamiento orientado al contador
• PLAIN64 es un mecanismo de generación IV que simplemente pasa directamente el índice del sector de 64 bits al algoritmo de encadenamiento como IV

Parameters: < cipher > < key > < iv_offset > < device path > < offset > [< #opt_params > < opt_params >]
< cipher >
Encryption cipher, encryption mode and Initial Vector (IV) generator.
The cipher specifications format is:
cipher[ :keycount ]-chainmode-ivmode[ :ivopts ]
Examples:
aes-cbc-essiv:sha256
aes-xts-plain64
Serpent-xts-plain64

Cipher format also supports direct specification with kernel crypt API
format (selected by capi: prefix). The IV specification is the same
as for the first format type.
This format is mainly used for specification of authenticated modes.
The crypto API cipher specifications format is:
Capi:cipher_api_spec-ivmode[ :ivopts ]
Examples:
capi:cbc(aes)-essiv:sha256
capi:xts(aes)-plain64
Examples of authenticated modes:
capi:gcm(aes)-random
capi:authenc(hmac(sha256),xts(aes))-random
capi:rfc7539(chacha20,poly1305)-random

Prueba de rendimiento Cryptsetup con DRAM

# root@odroid:~# cryptsetup benchmark

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 297552 iterations per second
PBKDF2-sha256 195338 iterations per second
PBKDF2-sha512 125068 iterations per second
PBKDF2-ripemd160 247305 iterations per second
PBKDF2-whirlpool 27935 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 73.8 MiB/s 97.7 MiB/s
serpent-cbc 128b 40.9 MiB/s 42.9 MiB/s
twofish-cbc 128b 58.0 MiB/s 62.0 MiB/s
aes-cbc 256b 59.8 MiB/s 74.0 MiB/s
serpent-cbc 256b 41.5 MiB/s 42.7 MiB/s
twofish-cbc 256b 59.1 MiB/s 62.0 MiB/s
aes-xts 256b 110.6 MiB/s 95.2 MiB/s
serpent-xts 256b 41.6 MiB/s 42.2 MiB/s
twofish-xts 256b 59.7 MiB/s 61.9 MiB/s
aes-xts 512b 86.1 MiB/s 72.5 MiB/s
serpent-xts 512b 42.1 MiB/s 42.4 MiB/s
twofish-xts 512b 60.7 MiB/s 61.6 MiB/s

Prueba de rendimiento Cryptsetup con HDD

La Figura 1 muestra los resultados de las pruebas de un ODROID-HC2 utilizando un HDD NAS WD 4TB a 5400RPM, que pueden variar según el tipo de disco duro utilizado:

$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

Encriptar el disco duro usando cryptsetup

Instala cryptsetup y como no necesitamos reiniciar, inicia los módulos dm-crypt.

$ sudo apt-get install cryptsetup
$ sudo modprobe dm-crypt sha256 aes

Prueba a verificar que cryptsetup y dm-crypt estén funcionando:

$ fallocate -l 128MiB /tmp/test.bin
$ dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1
$ sync
$ cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin

$ fallocate -l 128MiB /tmp/test.bin
$ dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1
$ sync
$ cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-ctr-plain -h sha256 -s 128 /tmp/test.bin

Una vez que compruebes que cryptsetup funciona bien, puede empezar a encriptar el disco. Ten en cuenta que se trata de un cifrado de todo el disco, de modo que el disco debe formatearse.

$ sudo wipefs -a /dev/sda1
/dev/sda1: 6 bytes were erased at offset 0x00000000 (crypto_LUKS): 4c 55 4b 53 ba be

Crea una clave para desbloquear el volumen

La encriptación Luks admite múltiples claves. Estas claves pueden ser contraseñas introducidas de forma interactiva, o archivos clave pasados como argumento para desbloquear la partición cifrada.

$ sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4
$ sudo chmod 400 /root/keyfile

Para crear la partición cifrada en /dev/sda1, se utiliza luks. El cifrado de la partición será gestionado usando el comando cryptsetup.

$ sudo cryptsetup --verify-passphrase luksFormat /dev/sda1 -c aes-cbc-essiv:sha256 -h sha256 -s 128

Esto te solicitará una contraseña que debería ser larga (más de 8 caracteres), lo cual debería tenerse en cuenta. Los siguientes pasos muestran cómo abrir la unidad encriptada y asignar la dp-crypt al sistema de archivos. A continuación, desbloquea la unidad usando la contraseña que acabamos de proporcionar, luego crea un sistema de archivos en el dispositivo.

$ sudo cryptsetup luksOpen /dev/sda1 securebackup

Formatea la partición:

$ sudo mkfs -t ext4 -m 1 /dev/mapper/securebackup

Agrega una clave luks que permite el montaje automático durante el arranque:

$ sudo cryptsetup -v luksClose securebackup
$ sudo cryptsetup luksAddKey /dev/sda1 /root/keyfile

Actualiza el archivo /etc/crypttab para hacer referencia al archivo de claves:

$ cat /etc/crypttab
# < target name > < source device > < key file > < options >
securebackup /dev/sda1 /root/keyfile luks

Necesitamos decirle al subsistema dm-crypt que este dispositivo debe montarse antes de la partición HDD encriptada. Para hacerlo, abre el archivo /etc/default/cryptdisks y busca la línea CRYPTDISKS_MOUNT = "":

$ cat /etc/default/cryptdisks
# Run cryptdisks initscripts at startup? Default is Yes.
CRYPTDISKS_ENABLE=Yes

# Mountpoints to mount, before cryptsetup is invoked at initscripts. Takes
# mountpoins which are configured in /etc/fstab as arguments. Separate
# mountpoints by space.
# This is useful for keyfiles on removable media. Default is unset.
CRYPTDISKS_MOUNT="/root/keyfile"

# Default check script. Takes effect, if the 'check' option is set in crypttab
# without a value.
CRYPTDISKS_CHECK=blkid

# Default precheck script. Takes effect, if the 'precheck' option is set in
# crypttab without a value.
# Default is 'un_blkid' for plain dm-crypt devices if unset here.
CRYPTDISKS_PRECHECK=

Comprueba que la unidad esté asignada al dispositivo de cifrado:

$ sudo cryptsetup luksOpen /dev/sda1 securebackup
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:0 0 29.8G 0 disk
|-mmcblk1p1 179:1 0 128M 0 part /media/boot
`-mmcblk1p2 179:2 0 29.7G 0 part /
sda 8:0 0 149G 0 disk
`-sda1 8:1 0 149G 0 part
`-securebackup 254:0 0 149G 0 crypt

Para montar automáticamente el disco en el siguiente reinicio, debes actualizar la entrada /etc/fstab:

$ mkdir -p /media/secure
$ sudo cat /etc/fstab
UUID=e139ce78-9841-40fe-8823-96a304a09859 / ext4 errors=remount-ro,noatime 0 1
LABEL=boot /media/boot vfat defaults 0 1
/dev/mapper/securebackup /media/secure ext4 defaults,rw 0 2

Podrás montar manualmente el disco si los pasos anteriores han dado resultado:

$ mount /dev/mapper/securebackup /media/secure

Rendimiento de CIFS/Samba en un HDD encriptado

Las Figuras 2 - 7 muestran el rendimiento utilizando la siguiente configuración de hardware:

• HC2 + ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img.xz with updated 4.14.18-106 kernel
• Tarjeta MicroSD de 8GB
• HDD Seagate 8TB  (ST8000AS0002)
• Encriptación: aes-xts-plain64 (256 bit key, SHA256 hash)

Samba usa la siguiente configuración:

[HDD INTERNAL]
comment = NAS
path = /media/internal
valid users = odroid
writable = yes
create mask = 0775
directory mask = 0775
# Tweaks
write cache size = 524288
getwd cache = yes
use sendfile = yes
min receivefile size = 16384
socket options = TCP_NODELAY IPTOS_LOWDELAY

Para el ver el artículo original, consulta la entrada de la Wiki en https://wiki.odroid.com/odroid-xu4/software/disk_encryption.