web-dev-qa-db-ja.com

新しく作成されたDM-CRYPT / LUKSパーティションで「このパスフレーズで使用可能なキーはありません」

検索を行うと、暗号設定のために他の人がより複雑な問題を抱えているように見えますが、私の問題は何かを簡単に行うときです。

Lubuntu 18.10 32ビット（カーネルが更新されています）のほとんど新しいインストールを使用して、暗号化されたパーティションを作成できます。

cryptsetup  --verbose  --verify-passphrase  luksFormat  /dev/mmcblk0    

WARNING: Device /dev/mmcblk0 already contains a 'crypto_LUKS' superblock signature.

WARNING!
========
This will overwrite data on /dev/mmcblk0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mmcblk0: 
Verify passphrase: 
Existing 'crypto_LUKS' superblock signature on device /dev/mmcblk0 will be wiped.
Key slot 0 created.
Command successful.

与えられたパスワードがaの場合、ロックを解除することができません。

cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Enter passphrase for /dev/mmcblk0:
No key available with this passphrase.
Enter passphrase for /dev/mmcblk0:

（私もzulucryptを試して同じ結果が得られました）

インストーラーの暗号化機能を使用してLubuntuをインストールしたので、システムがネイティブで使用しているものと、mmcドライブで作成したcryptsetupを比較できます。

cryptsetup luksDump /dev/sda1

関連する部分は次のようです：

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512

2つのダンプの唯一の違いは、ローカルドライブの場合、最下位の「MKビット」は512ですが、mmcの場合は256です。

それが適切かどうかはわかりませんが、ローカルドライブには2つのキースロットがあり、mmcには1つしかないこともわかります。 （私のローカルドライブに2つのキースロットがあるという事実は、最初のキーが破損している場合に備えて、インストーラーが重複キーを入れたかどうかを私に希望させます。）

コメント投稿者から、次のようにパスフレーズを提供するように依頼されました。

echo -n 'a' | cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Can't do passphrase verification on non-tty inputs.
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).

パスワードを提供する別の方法：

echo 'a' > interactive_pass         
cat interactive_pass | cryptsetup luksAddKey /dev/mmcblk0

No key available with this passphrase.

キーファイルを使用する。

これは理解できません。しばらくいじりましたが、使い方を間違えた場合と問題がある場合の違いがわからないのでやめました。

zulucryptにはキーファイルを作成する方法がありますが、Failed To Generate Key。それは簡単なので、私はそれを正しく使用していると確信しています（rootとして実行し、作成したいファイルへの書き込み権限を持っています）

encryptionlukscryptsetup
1
spiralofhope

TL; DR-メディアが信頼できるかどうかを確認します。 luksFormatおよびluksOpenはサポートしていません。

この問題は、少なくともいくつかの方法で考えられます。

  • 間違ったパスフレーズが提供されています
  • パスフレーズが間違った方法で与えられている
  • Cryptsetup自体など、重要なソフトウェアに問題があります。

好奇心から、私はmmcドライブの完全なフォーマットを（「ゼロから始める」ために）行うことにしましたが、次のことを確認しました。

Sudo mkfs.ext4 /dev/mmcblk0 -cc   

mke2fs 1.44.4 (18-Aug-2018)
/dev/mmcblk0 contains a ext4 file system
        last mounted on Tue Mar  5 11:30:02 2019
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 15591936 4k blocks and 3899392 inodes
Filesystem UUID: 0ab72f40-d2a2-408d-b4ca-d5e8fcc27ec7
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424

Testing with pattern 0xaa: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x55: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0xff: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0x00: done                                                 rs)
Reading and comparing: done                                                 rs)
Block 0 in primary superblock/group descriptor area bad.
Blocks 0 through 9 must be good in order to build a filesystem.
Aborting....

これがどこに向かっているのかはすでにわかりました。

これまでにフォーマットしたことがないので、2つ目のストレージデバイス（USBスティック）をチェックしてフォーマットしましたが、そのフォーマットは正常に完了しました。同じcryptsetupプロセスを実行して、USBスティックをフォーマットして開きます動作しました。これにより、発生していた別の問題が明らかになります。

  • パスフレーズは間違った方法でreceivedされています

luksFormatがそのデータを確認するための健全性チェックを行っていないのではないかと思います実際に読み取ることができます。

補足として、私はすでにWindowsで非クイックフォーマットを実行しており、問題なく動作しました。また、完全な書き込みと読み取りの比較テストも行いましたが、これも成功しました。私は好奇心から他に実行するテストがありますが、これは（どういうわけか）Linux固有の問題である可能性があります。そのうさぎの穴のトラブルシューティングは行いませんが、問題が発生している特定のプラットフォームですべてのフォーマットとテストを行うことが重要であると結論付けます。

1
spiralofhope