web-dev-qa-db-ja.com

dmcrypt：ユーザースペースの暗号ラッパーが存在しない場合はどうなりますか？

ファイルを安全に保存するために暗号化されたボリュームを設定しようとしています。これはNextThingCoポケットチップで行われますが、OSはdebianに基づいているので、私の質問はプラットフォーム自体よりもdmcryptに関連しているので、最初にここで試してみると思います（またはそう思います）。

私がこれまでに作成したレシピは次のとおりです（正しくないか、過度に複雑である可能性があります）。

  1. ファイルを作成する
  2. ループデバイスとして設定します。
  3. フォーマットして開くためにcrypsetupを実行します。 「abc」は、stdinを介して入力されるパスワードです（この仮定は正しいですか？）。
  4. ファイルシステムを作成する
  5. Mount

したがって、次のようになります。

 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

プラットフォームとOSに関する追加情報は次のとおりです。

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のキーサイズを使用できる「リソースビジー」状況を解決するにはどうすればよいですか？

ここまで読んでいただきありがとうございます。どんなポインタでも大歓迎です。

編集（08/12/17）：-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
linuxencryptionarmdm-crypt
2
Paco

カーネルは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ファイルはモードxts-plain64（aes-xts-plain64）のaesで暗号化されているように見えます。少なくともそれに書き込まれるものはすべて暗号化されます。luksOpen-edして書き込まれていない場合は、変更されません。
  • ./encrypted.volumeは個別のディスクパーティションではなく、単なるファイル/コンテナです。

  • ddを使用してエントロピーの多くを使い果たして/ dev/urandomから1億（512 * 200？）を取り出しますが、これは不要です。ゼロを使​​用してコンテナファイルを作成することは問題ありません（または単にfallocate）。 luksFormatted、次にをゼロで埋めると、暗号化されてディスクに書き込まれます。

  • cryptsetup --helpの最後の10行ほどは何ですか？それはデフォルトが何であるかを言うでしょう。
  • /proc/cryptoには何が含まれていますか？利用可能な暗号化方法が表示されます。
  • また、最近のcryptsetupはループファイル自体を処理するため、losetupをスキップしてcryptsetupに処理させることができます。
  • シェルが履歴を保存する場合、パスフレーズ（ "abc"）はプレーンテキストで保存される可能性がありますが、これはすばらしいことではありません。完全なコマンドラインがリストされている場合は、psからも表示される可能性があります。パスフレーズをstdinに取得する別の方法を使用する方が安全な場合があります。または、安全なメディア（外部USB /デバイス）またはramfsなどでキーファイルを使用します。FAQの2.14を参照してください。
0
Xen2050