open.sh

open.sh

私のリムーバブルデバイスには、暗号化されたデータを含むパーティションが含まれており、任意のデータと区別できる他の項目がない設定があります。物理的に分離されたデバイスには、GPG暗号化キーを使用してデバイスをオンまたはオフにするスクリプトペアがあります。


open.sh

#!/bin/bash

# The crypt UUID is hard-coded. That way it will not try to decrypt the wrong
# device.
cryptuuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

# The UUID of the decrypted device is hard-coded. This is currently how the
# script knows what to mount after decrypting.
deviceuuid='yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'

# The encrypted key bits are fed to cryptsetup with specific parameters to
# decrypt the crypt.
gpg2 --decrypt <<-  END | sudo cryptsetup --offset 0 --cipher aes-xts-plain64 --key-size 256 --hash sha256 --key-file - open --type plain "/dev/disk/by-partuuid/$cryptuuid" Secrets
    -----BEGIN PGP MESSAGE-----

    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
    zzzzz
    -----END PGP MESSAGE-----
END

# A small delay is necessary to give time for the decrypted device to show up.
sleep 1

# Mount the decrypted device as if the user did it using the GUI.
gvfs-mount -d $(readlink -f $(blkid -U "$deviceuuid"))

閉じる.sh

#!/bin/bash

# The UUID of the decrypted device is hard-coded. This is currently how the
# script knows what unmount.
deviceuuid='yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'

# Find all processes using the decrypted device and issue a “friendly” kill
# signal.
sudo lsof -t $(findmnt -rn -S UUID="$deviceuuid" -o TARGET) | while read process; do kill -HUP $process; done

# Try to unmount the decrypted device and then close it with cryptsetup. findmnt
# identifies the path which the device is mounted. lsblk finds the decrypted
# device (minus “/dev/” from the UUID). dmsetup finds the decrypted device name
# given the block device name from before.
gvfs-mount -u $(findmnt -rn -S UUID="$deviceuuid" -o TARGET) && sudo cryptsetup close $(sudo dmsetup info --columns --noheadings --options Name --select BlkDevName=$(lsblk --raw --noheadings --output KNAME,UUID | awk '{if ($2=="'"$deviceuuid"'") { print $1}}'))

これらのスクリプトは機能しますが、理想的には暗号化されたパーティションの組み込みGUIサポートを最大限に活用して端末の使用を減らしたいと思います。

この目標に近づくために、Logical Volume Manager(LVM)のJBOD機能を調べました。アイデアは、ファイルマネージャに表示されるLUKSパーティションを持ちながら、暗号化されたデータが任意のデータと区別されないように、暗号化されたデータからLUKSヘッダーを維持することです。

これを達成するために、私は2冊の本を使用しました。

  1. 1つの文書タイトル.img(正確に2,139,648バイト)
  2. 物理デバイス/dev/sdx

設定手順

タイトル.imgLUKSヘッダー全体を収容するのに十分な大きさのLVM PVをホストするGPTパーティションが含まれています。/dev/sdx暗号化されたデータを含むLVM PVをホストするGPTパーティションが含まれています。

次の手順を使用して作成されます。

  1. fallocate -l 2139648 header.img最初のPVを保存する画像を作成します。
  2. 画像をマウントし、その中のPV用に4,112セクタのGPTパーティション(GUID:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)を作成しました。
  3. sudo pvcreate --labelsector 0 --metadatatype 2 --pvmetadatacopies 1 --metadatasize 32768b --dataalignment 512b /dev/disk/by-partuuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxヘッダーの物理ボリュームを作成します。
  4. 次のデバイスの場合/dev/sdx)暗号化されたデータを保存する場所に必要なパーティションの配置を決定し、LVMヘッダの先頭にセクタを追加します。 SSDドライブがセクタ65536で始まるパーティションとして事前フォーマットされている場合は、そのパーティションを削除し、セクタ65535で始まるパーティションを作成します。これにより、ファイルシステムはまだ最適に整列したままになります。
  5. sudo pvcreate --labelsector 0 --pvmetadatacopies 0 --metadatasize 0b --dataalignment 512b '/dev/disk/by-partuuid/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'LVMヘッダーのみを含み、メタデータは含まない物理ボリュームを作成します。
  6. vgcreate --metadatacopies unmanaged --physicalextentsize 512b Secrets '/dev/disk/by-partuuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' '/dev/disk/by-partuuid/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'この 2 つの物理ボリューム上にボリュームグループを作成します。
  7. lvcreate --contiguous n --extents 100%FREE Secrets --name Cryptボリュームグループで使用可能なすべてのスペースを占有する論理ボリュームを作成します。
  8. 今私が経験している特別な問題は、論理ボリュームにデータを書き込むと、常に最大の物理ボリュームに最初に書き込まれることです。 LUKSヘッダーが2つの物理ボリュームのうち小さい方に書き込まれることを望むので、これはお勧めできません。ボリュームグループのデータを物理ボリュームの順序を変更できるテキストファイルにエクスポートして問題を解決しましたvgcfgbackup -f metadata.txt Secrets
  9. 生成されたテキストファイルを編集するのは非常に簡単です。そのセクションの下には、次のlogical_volumes名前の2つのセグメントが必要です。各項目の下の合計値を編集する必要があります。とが必要であり、より大きな物理ボリュームと同じでなければなりません。このボリュームはリソースセクションにあります。あなたsegment1segment2start_extentextent_countsegment1start_extent = 0extent_count = 4040segment2start_extent = 4040extent_countpe_countphysical_volumes可能交換pv0pv1取り囲みが必要ですが、ボリューム定義を再確認して合理的であることを確認してください。
  10. vgcfgrestore -f metadata.txt Secrets変更はボリュームグループに適用されます。
  11. cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --align-payload 1 luksFormat /dev/Secrets/CryptLUKS 暗号化ボリュームを作成します。
  12. 新しいボリュームを開き、必要な操作を実行します。
  13. 取り出し:暗号化されたボリューム上のすべてのファイルシステムをアンマウントして閉じてから実行しますvgchange -an Secrets。その後、物理ボリュームを取り外して取り出すことができます。

いつ/dev/sdx挿入してタイトル.imgディスクユーティリティを使用してインストールするときにクリックすると、ボリュームのロックを解除するためのパスワードを求めるアイコンがランチャーに表示されます。論理ボリュームが登録されていない場合を除き、すべてのステップで端末は必要ありません。その後実行vgscan --mknodesそしてudevadm triggerしゃっくり問題を解決しているようです。

問題は、ボリュームをマウント解除するときにループデバイスを削除して暗号化されたストレージを取り出す前に、ターミナルを使用してLVMボリュームグループ(VG)を無効にする必要があることです。記憶媒体を物理的に取り外しても、ボリュームグループが消えてしまうようには見えず、ループデバイスはマウント解除されません。

デバイスの削除の問題を解決するのは問題ありませんが、このように設定を作成して維持するだけでは作業が複雑すぎるようです。

現在使いやすいマルチレベルフルディスク暗号化をサポートするLinuxディストリビューションはありますか?

関連情報