2 votos

dmcrypt: ¿Qué sucede cuando el contenedor de crypto del espacio de usuario no está presente?

Estoy tratando de configurar un volumen cifrado para almacenar archivos de forma segura. Esto se hace en un NextThingCo pocketchip, pero el sistema operativo basado en debian así que he pensado que yo podría darle una oportunidad aquí en primer lugar, que mi pregunta está más relacionado con la dmcrypt de la plataforma en sí (o eso creo).

La receta que he construido hasta ahora es el siguiente (puede ser incorrecta o demasiado complicado):

  1. Crear un archivo de
  2. Configurado como un dispositivo de bucle.
  3. Hacer el crypsetup para formatear y abierto. "abc" es la contraseña, se alimenta a través de la entrada estándar (es esta suposición correcta?).
  4. Hacer un sistema de ficheros
  5. Monte

Por lo que se ve como esto:

 sudo dd if=/dev/urandom of=./encrypted.volume bs=512K count=200
 sudo losetup /dev/loop0 ./encrypted.volume  
 echo "abc" | sudo cryptsetup luksFormat /dev/loop0
 echo "abc" | sudo cryptsetup open /dev/loop0 vault
 sudo mkfs /dev/mapper/vault
 sudo mount /dev/mapper/vault /mnt/vault

Ahora bien, todo esto parece funcionar bien y dandy, que es hasta que se utiliza la opción --debug parámetro (quería probar otros parámetros así por ejemplo, tamaño de clave). Y me di cuenta de los siguientes mensajes:

# cryptsetup 1.7.0 processing "cryptsetup -v --debug --cipher aes-xts-plain64 --key-size 
512 --hash sha512 --iter-time 5000 --timeout 10 --use-random luksFormat /dev/loop0"
# Running command luksFormat.
...
# Userspace crypto wrapper cannot use aes-xts-plain64 (-95).
...
device-mapper: remove ioctl on temporary-cryptsetup-6661 failed: Device or resource busy    <------ appears when I change the  --key-size to 512 i.s.o. default 256
...
device-mapper: remove ioctl on temporary-cryptsetup-6698 failed: Device or resource busy

He intentado correr el benchmark:

chip@chip:~/data/run$ sudo cryptsetup --debug benchmark
[sudo] password for chip:
# cryptsetup 1.7.0 processing "cryptsetup --debug benchmark"
# Running command benchmark.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Tests are approximate using memory only (no storage IO).
# Crypto backend (gcrypt 1.6.4) initialized in cryptsetup library version 1.7.0.
# Detected kernel Linux 4.4.13-ntc-mlc armv7l.
# KDF pbkdf2, hash sha1: 59041 iterations per second (256-bits key).
PBKDF2-sha1        59041 iterations per second for 256-bit key
# KDF pbkdf2, hash sha256: 79437 iterations per second (256-bits key).
PBKDF2-sha256      79437 iterations per second for 256-bit key
# KDF pbkdf2, hash sha512: 40705 iterations per second (256-bits key).
PBKDF2-sha512      40705 iterations per second for 256-bit key
# KDF pbkdf2, hash ripemd160: 50412 iterations per second (256-bits key).
PBKDF2-ripemd160   50412 iterations per second for 256-bit key
# KDF pbkdf2, hash whirlpool: 7481 iterations per second (256-bits key).
PBKDF2-whirlpool    7481 iterations per second for 256-bit key
# Cannot initialise cipher aes, mode cbc.
Required kernel crypto interface not available.
Command failed with code 95: Operation not supported

Aquí hay algo de información adicional acerca de la plataforma y sistema operativo:

chip@chip:~/data/run$ uname -r
4.4.13-ntc-mlc
chip@chip:~/data/run$ cat /boot/config-4.4.13-ntc-mlc | grep CRYPTO_USER_API_SKCIPHER
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set

Entiendo que sería necesario volver a compilar el kernel después me puse CONFIG_CRYPTO_USER_API_SKCIPHER por lo que el espacio de usuario API de cifrado disponible. No creo que hay una forma de evitar eso, ¿no?

Yo LuksDump la información sobre el almacenamiento de archivos:

chip@chip:~/data/run$ sudo cryptsetup luksDump ./encrypted.volume

LUKS header information for ./encrypted.volume

Version:        1
Cipher name:    aes          <------- ???
Cipher mode:    xts-plain64  <------- ???
Hash spec:      sha256       
Payload offset: 4096
MK bits:        256
MK digest:      ee f8 8d ad 9b 67 d9 7d cb 20 fe a9 25 a3 8b a5 c2 65 56 dd
MK salt:        38 74 e8 9d 77 6a 93 b5 03 41 cb 3e ce 79 b4 00
                55 f3 98 8f c5 a7 14 05 25 9c 4e 91 68 1a 53 37
MK iterations:  18500
UUID:           36912ea4-9adb-4d1f-b9f2-f6a09a258833

Key Slot 0: ENABLED
        Iterations:             150587
        Salt:                   e8 4f f3 c1 07 1a 2b 2d d2 d9 f4 55 0f b3 13 28
                                2a 69 06 aa a0 94 4a 05 5d 5f e9 28 9b 91 39 94
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Sin embargo, tengo un par de preguntas acerca de la situación actual:

  • Es la partición cifra realmente? Si es así, con qué programa?
    • Cómo comprobar esto en la línea de comandos? Tratando de volcar la información de la partición me dice que "no es un LUKS encabezado", pero que no me dicen si los datos están cifrados o no.
  • ¿Cómo resolver los recursos de "ocupado" de la situación, que me permitiera utilizar un tamaño de clave de 512?

Gracias por leer hasta aquí. Alguna sugerencia será muy apreciada.

EDITAR (08/12/17): - Últimas líneas de crypsetup --help:

<name> is the device to create under /dev/mapper
<device> is the encrypted device
<key slot> is the LUKS key slot number to modify
<key file> optional key file for the new key for luksAddKey action

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 2000 (ms)

Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

0voto

Xen2050 Puntos 2860

Parece que su kernel no soporta 512 bits de las claves de encriptación aes-xts-plain64, y no hace aes en modo cbc:

# Cannot initialise cipher aes, mode cbc.
Required kernel crypto interface not available.
Command failed with code 95: Operation not supported

pero que sólo se detiene en el punto de referencia, xts es preferido sobre el cbc de todos modos. Creo que se podría conseguir más modos disponibles por la reconstrucción y obtener un nuevo kernel (o tal vez modprobeing, yo no estoy 100% seguro).

Hay un poco de conflicto info acerca de aes con 512 bits llaves, Q esta en crypto.SE dice que por Qué no podemos aplicar AES 512 tamaño de la clave? y concluye que no sólo define y apoyado, pero el uso de --cipher aes-xts-plain64 --key-size 512 funciona bien para mi cryptsetup (v1.7.3) y mi /proc/crypto tiene una xts(aes) de entrada de apoyo keysizes 32-64 bytes.

  • De todos modos, a partir de luksDump la ./encrypted.volume archivo de mira cifrados con aes en modo xts-plain64 (aes-xts-plain64). Al menos nada de lo escrito a que se cifra, que va a ser virgen si no luksOpen-ed y escrito.
  • ./encrypted.volume no es una partición de disco, es sólo un archivo/el recipiente.
  • Vamos a usar hasta un montón de su entropía mediante dd tomar 100M (512*200?) de /dev/urandom, y es innecesario. Crear el archivo contenedor mediante los ceros está bien (o fallocate). Una vez que se luksFormatted , a continuación, se rellena con ceros por la que se encriptados y escrito en el disco.

  • ¿Cuál es el último 10 líneas o así de cryptsetup --help? Que voy a decir lo que los valores predeterminados.
  • Lo que está en /proc/crypto? Lo voy a mostrar los métodos de encriptación disponibles.
  • También los últimos cryptsetup manija del lazo de los archivos, por lo que puede pasar losetup y dejar cryptsetup manejar.
  • Si su cáscara guarda el historial, su contraseña ("abc") puede ser almacenada en texto plano, que no es gran. Podría ser visible desde ps demasiado, si figura en la lista completa de líneas de comando. El uso de otra forma de obtener la contraseña a stdin puede ser más seguro, o utilizar un archivo de claves en un medio seguro (externo USB/dispositivo) o en ramfs, etc. Ver 2.14 en la sección de preguntas frecuentes.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: