dmcrypt: O que acontece quando o wrapper crypto do userspace não está presente?

Question

Estou tentando configurar um volume criptografado para armazenar arquivos com segurança. Isso é feito em um pocketchip NextThingCo, mas o sistema operacional é baseado no debian, então eu imaginei que eu iria tentar primeiro aqui, já que a minha pergunta está mais relacionada ao dmcrypt do que a própria plataforma (ou assim eu acho).

A receita que eu construí até agora é a seguinte (pode ser incorreta ou excessivamente complicada):

1. Crie um arquivo
2. Configure como um dispositivo de loop.
3. Faça o crypsetup para formatação e abertura. "abc" é a senha, alimentada por stdin (esta suposição é correta?).
4. Crie um sistema de arquivos
5. Montagem

Então parece com isso:

 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

Agora, tudo isso parece funcionar bem, até que eu usei o parâmetro --debug (eu queria testar outros parâmetros, por exemplo, tamanho de chave). E percebi as seguintes mensagens:

# 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

Eu tentei executar o benchmark também:

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

Veja algumas informações adicionais sobre a plataforma e o sistema operacional:

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

Eu entendo que precisaria recompilar o kernel depois de definir CONFIG_CRYPTO_USER_API_SKCIPHER para que a API de criptografia do espaço de usuário se torne disponível. Eu não acho que há uma maneira de contornar isso, existe?

Eu LuksDump as informações sobre o arquivo de armazenamento:

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

No entanto, tenho algumas perguntas sobre a situação atual:

• A partição está realmente criptografada? Se sim, com qual esquema?
  • Como verificar isso na linha de comando? Tentar despejar informações sobre a partição me diz que "há um cabeçalho LUKS", mas isso não me diz se os dados estão criptografados ou não.
• Como resolver a situação '' ocupado '', o que me permitiria usar um tamanho de chave de 512?

Obrigado por ler todo o caminho até aqui. Quaisquer ponteiros serão muito apreciados.

EDIT (08/12/17): - últimas linhas 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

• saída de / proc / crypto: link

Answer 1

Parece que seu kernel não suporta chaves de 512 bits com o aes-xts-plain64, e não faz o modo ae do cbc:

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

mas isso apenas pára o benchmark, o xts é preferido em relação ao cbc de qualquer maneira. Eu acho que você poderia obter mais modos disponíveis reconstruindo / obtendo um novo kernel (ou talvez modificando, não tenho 100% de certeza).

Há poucas informações conflitantes sobre o aes com chaves de 512 bits, o Q no crypto.SE diz Por que não podemos implementar o tamanho da chave AES 512? e conclui que ele não está definido / suportado, mas usar --cipher aes-xts-plain64 --key-size 512 funciona bem para meu cryptsetup (v1.7.3) e meu / proc / crypto tem uma entrada xts (aes) que suporta chaves de 32-64 bytes.

• De qualquer forma, a partir do luksDump, o arquivo ./encrypted.volume parece criptografado com aes no modo xts-plain64 (aes-xts-plain64). Pelo menos qualquer coisa escrita para ele seria criptografada, ela não será tocada se você não tiver luks aberto e escrito nela.
• ./encrypted.volume não é uma partição de disco separada, é apenas um arquivo / contêiner.

• Você usará muita entropia usando dd para tirar 100M (512 * 200?) de / dev / urandom, e isso é desnecessário. Criar o arquivo contêiner usando zeros é bom (ou apenas fallocate ). Uma vez que é luksFormatted então você preenche com zeros que serão criptografados & escrito em disco.

  • Consulte a seção de configuração do link
• Quais são as últimas 10 linhas de cryptsetup --help ? Ele dirá quais são os padrões.
• O que há em /proc/crypto ? Ele mostrará os métodos de criptografia disponíveis.
• Os arquivos de loop de alça do cryptsetup também são recentes, então você pode pular o losetup e deixar o cryptsetup lidar com isso.
• Se o seu shell salva o histórico, sua frase secreta ("abc") pode ser armazenada em texto simples, isso não é ótimo. Pode ser visível a partir de ps também, se ele listar linhas de comando completas. Usar outra maneira de obter a senha para stdin pode ser mais seguro ou usar um arquivo de chave em um meio seguro (USB / dispositivo externo) ou em ramfs, etc. Consulte 2.14 no FAQ.