dmcrypt:当用户空间加密包装器不存在时会发生什么?

dmcrypt:当用户空间加密包装器不存在时会发生什么?

我正在尝试设置一个加密卷来安全地存储文件。这是在 NextThingCo 口袋芯片上完成的,但操作系统基于 Debian,所以我想我会先在这里尝试一下,因为我的问题与 dmcrypt 的关系比平台本身更密切(至少我是这么认为的)。

我目前建立的食谱如下(可能不正确或过于复杂):

  1. 创建文件
  2. 将其设置为循环设备。
  3. 执行 rypsetup 进行格式化并打开。“abc”是密码,通过 stdin 输入(这个假设正确吗?)。
  4. 创建文件系统

所以它看起来像这样:

 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

现在,这一切似乎都运行良好,直到我使用了 --debug 参数(我想尝试其他参数,例如 key-size)。然后我注意到以下消息:

# 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

我也尝试运行基准测试:

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

以下是有关平台和操作系统的一些附加信息:

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

我知道设置 CONFIG_CRYPTO_USER_API_SKCIPHER 后需要重新编译内核,这样用户空间加密 API 才可用。我认为没有办法解决这个问题,对吧?

我从LuksDump中获取了有关存储文件的信息:

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

不过,我对目前的情况有几个疑问:

  • 该分区是否真的加密?如果是,采用哪种方案?
    • 如何在命令行上检查这一点?尝试转储有关分区的信息告诉我“有一个 LUKS 标头”,但这并不能告诉我数据是否加密。
  • 如何解决“资源繁忙”的情况,让我使用 512 的密钥大小?

感谢您阅读到这里。任何指点都将不胜感激。

编辑(2017 年 8 月 12 日): - 最后几行 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

答案1

看起来你的内核不支持带有 aes-xts-plain64 的 512 位密钥,并且根本不执行 aes 模式 cbc:

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

但那只是停止了基准测试,无论如何 xts 比 cbc 更受欢迎。我认为您可以通过重建/获取新内核(或者可能是 modprobeing,我不是 100% 确定)来获得更多可用模式。

关于 512 位密钥的 AES 有一些矛盾的信息,crypto.SE 上的这个 Q 说为什么我们不能实现 AES 512 密钥大小?并得出结论,它只是没有定义/支持,但--cipher aes-xts-plain64 --key-size 512对于我的 cryptsetup (v1.7.3) 来说使用效果很好,并且我的 /proc/crypto 有一个支持密钥大小 32-64 字节的 xts(aes) 条目。

  • 无论如何,从 luksDump 来看,该./encrypted.volume文件使用 aes 加密,模式为 xts-plain64 (aes-xts-plain64)。至少写入其中的任何内容都会被加密,如果您没有使用 luksOpen 进行加密并写入,它将不会受到影响。
  • ./encrypted.volume不是一个单独的磁盘分区,它只是一个文件/容器。
  • 您将使用大量的熵dd来从 /dev/urandom 中取出 100M(512*200?),这是不必要的。使用零创建容器文件是可以的(或只是fallocate)。一旦它被 luksFormatted然后你用零填充它,它将被加密并写入磁盘。

  • 最后 10 行左右是什么cryptsetup --help?它会说明默认值是什么。
  • 里面有什么/proc/crypto?它会向您显示可用的加密方法。
  • 此外,最近的 cryptsetup 处理循环文件本身,因此您可以跳过 losetup 并让 cryptsetup 处理它。
  • 如果您的 shell 保存了历史记录,您的密码短语(“abc”)可能会以纯文本形式存储,这不太好。ps如果它列出了完整的命令行,它也可能可见。使用另一种方式将密码短语发送到 stdin 可能更安全,或者在安全介质(外部 USB/设备)或 ramfs 中使用密钥文件等。请参阅常见问题解答中的 2.14。

相关内容