「Dm-crypt/特記事項」の版間の差分

2024年9月5日 (木) 21:07時点における最新版

1 暗号化されていない boot パーティションのセキュア化
2 GPG や LUKS、OpenSSL の暗号化キーファイルを使う
3 root などのパーティションのリモート解除
4 一度きりのパスワード無しの再起動
5 ソリッドステートドライブ (SSD) の Discard/TRIM のサポート
6 encrypt フックと複数のディスク

暗号化されていない boot パーティションのセキュア化

たとえルートパーティションを暗号化したとしても、/boot パーティションと Master Boot Record は暗号化できません。通常、これらの2つを暗号化するのは不可能です。ブートローダーや BIOS は dm-crypt コンテナの暗号化を解除することができないため、ブートプロセスを続行できません。ただし、GRUB には LUKS で暗号化した /boot を復号する機能が存在します - dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB) を見てください。

このセクションでは、ブートプロセスをよりセキュアにするためにできることを説明しています。

警告: /boot パーティションと MBR をセキュア化することによりブートプロセス中に起こりうる数々の攻撃を緩和することはできますが、この方法で構成されたシステムは依然として BIOS/UEFI/ファームウェアの改ざん、ハードウェアキーロガー、コールドブート攻撃、そしてこの記事の範囲を超える他の多くの脅威に対しては脆弱である可能性があります。システムの信頼性の問題やディスク全体の暗号化に関連する問題の概要は、[1] を参照してください。

ノート: UEFI を使用している場合、暗号化しないでおく必要があるのは ESP のみです (ユニファイドカーネルイメージを使用している場合など)。この場合、セキュアブートを使用することにより、ブートプロセスが改ざんされていないことを保証することができます。これは、以下の方法と同じ効果を得ることのできる簡単な方法です。dm-crypt/システム全体の暗号化#Simple encrypted root with TPM2 and Secure Boot^{[リンク切れ: セクションが存在しません]} を参照してください。

リムーバブルデバイスから起動

別のデバイスを使ってシステムを起動するのはとても簡単で、特定の種類の攻撃に対してセキュリティを高めることができます。ルートファイルシステムを暗号化したシステムで脆弱ポイントとなりえるのは以下の2つです:

Master Boot Record
/boot パーティション

システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。これらを改竄から保護する方法として、USB ドライブなどのリムーバブルメディアに保存して、ハードディスクの代わりとしてドライブから起動すると良いでしょう。ドライブを肌身離さず持ち歩いていれば、これらのコンポーネントに改竄を加えられる恐れがなくなり、システムを解錠する認証機構をさらにセキュアにすることができます。

ここでは、既にシステム設定を終えていて専用のパーティションを /boot にマウントしていると仮定します。まだ設定していない場合は、dm-crypt/システム設定#カーネルパラメータの手順に従ってください (この時、ハードディスクはリムーバブルメディアに置き換えて手順を進めてください)。

ノート: 選んだメディア (USB ドライブ、外部ハードドライブ、SD カードなど) からのブートが、あなたのシステムでサポートされていることを確認してください。

リムーバブルドライブ (/dev/sdx) を準備します:

# gdisk /dev/sdx # 必要に応じてフォーマットしてください。または、cgdisk、fdisk、cfdisk、gparted などを使ってください。
# mkfs.ext2 /dev/sdx1 # BIOS システムの場合
# mkfs.fat -F 32 /dev/sdx1 # UEFI システムの場合
# mount /dev/sdx1 /mnt

既存の /boot の中身をリムーバブル上の新しい boot パーティションにコピーしてください:

# cp -ai /boot/* /mnt/

新しいパーティションをマウントしてください。fstab を適宜更新するのを忘れないでください:

# umount /boot
# umount /mnt
# mount /dev/sdx1 /boot
# genfstab -p -U / > /etc/fstab

その後 GRUB を更新してください。grub-mkconfig は自動的に新しいパーティションの UUID を認識するはずですが、カスタムメニューエントリは手動で更新する必要があるかもしれません。

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx # ハードディスクではなく、リムーバブルデバイスにインストール。BIOS システムの場合。
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub # UEFI システムの場合。

再起動して新しい設定をテストしてください。忘れずに BIOS や UEFI でデバイスのブート順序を設定してください。システムが起動しない場合、ハードドライブから起動することで問題を修正することができます。

chkboot

警告: chkboot は /boot パーティションの改ざんを検出可能にしますが、改ざんを防止するわけではありません。chkboot スクリプトを実行する時までに、すでにあなたはパスワードを、危殆化している可能性のあるブートローダ、カーネル、そして初期 RAM ディスクに入力しています。システムが chkboot の整合性テストに合格しない場合、あなたのデータの安全性に対していかなる保証もできません。

ct-magazine (3/12 号、146 ページ、2012年1月16日、[2]) の記事によると、以下のスクリプトは /boot のファイルに対して SHA-1 ハッシュや inode、ハードドライブの占有ブロックが変化していないかチェックします。また Master Boot Record もチェックします。特定の種類の攻撃を防ぐことはできませんが、防御力を高めることができます。スクリプト自体の設定は暗号化されていない /boot に保存されません。暗号化されたシステムのロックがかかっている/電源が落ちている状態であれば、見かけ上は起動時にパーティションの自動チェックサム比較が行われることはわからないため、攻撃するのが難しくなります。ただし、攻撃者にあらかじめ予期されていた場合、ファームウェアを操作してカーネルの上でコードを動かして、ファイルシステム (例: boot) のアクセスを横取りされてしまう可能性はあります。一般的に、ファームウェアよりも下の階層では改竄されていないという保証は得られません。

インストールスクリプトが存在します (作者: Juergen Schmidt, ju at heisec.de; ライセンス: GPLv2)。また、chkboot^AUR パッケージでインストールすることもできます。

インストールしたら、chkboot.service を有効化してください。

/usr/local/bin/chkboot_user.sh はログイン後すぐに実行する必要があるので、このスクリプトを自動起動させる必要があります (例えば、KDE では System Settings -> Startup and Shutdown -> Autostart、GNOME では gnome-session-properties)。

Arch Linux では、新しいカーネルなどによって /boot に頻繁に変更が加えられます。なので、アップグレードするたびにスクリプトを実行させると良いでしょう。これを行う方法としては以下があります:

#!/bin/sh
#
# 注: <user> にユーザ名を入力してください。このスクリプトを sudo で実行すると、pacman と chboot が自動的に動作します。
#
echo "Pacman update [1] Quickcheck before updating" &
sudo -u <user> /usr/local/bin/chkboot_user.sh
/usr/local/bin/chkboot.sh
sudo -u <user> /usr/local/bin/chkboot_user.sh
echo "Pacman update [2] Syncing repos for pacman"
pacman -Syu
/usr/local/bin/chkboot.sh
sudo -u <user> /usr/local/bin/chkboot_user.sh
echo "Pacman update [3] All done, let us roll on ..."

mkinitcpio-chkcryptoboot

警告: このフックは GRUB のコア (MBR) コードや EFI スタブは暗号化しません。攻撃者がブートローダーの設定を変更してカーネルや initramfs を実行時に改竄できる状態からは保護されません。

mkinitcpio-chkcryptoboot^AUR は、初期ユーザー空間で整合性チェックを行ってシステムのセキュリティが破られている場合に root パーティションのパスワードを入力しないようにユーザーに忠告する mkinitcpio フックです。ブートパーティションを暗号化することでセキュリティを確保し、GRUB の cryptodisk.mod モジュールでロックを解除します。root ファイルシステムのパーティションは別のパスワードを使って暗号化します。これなら、オフラインの改竄からも initramfs やカーネルを守ることができ、たとえマシンに侵入されて /boot パーティションのパスワードが入力されても root パーティションは安全です (chkcryptoboot フックが改竄を検出して、フック自体が改竄されていない場合)。

このフックが機能するには grub バージョン >= 2.00 が必要で、さらに、セキュアに保つために LUKS で暗号化された専用の /boot パーティションに独自のパスワードが設定されている必要があります。

インストール

mkinitcpio-chkcryptoboot^AUR をインストールし、/etc/default/chkcryptoboot.conf を編集してください。ブートパーティションがバイパスされたかどうかを検出したい場合は、CMDLINE_NAME 変数と CMDLINE_VALUE 変数を編集して、それぞれにあなただけが知っている値を入れてください。パッケージのインストール後に表示されるアドバイスの通りに、2つのハッシュ値を使うことができます。また、/etc/default/grub でカーネルコマンドラインを適切に変更することも忘れないでください。/etc/mkinitcpio.conf 内の HOOKS= 行を編集して chkcryptoboot フックを encrypt より前に加えてください。終わったら、initramfs を再生成してください。

技術的な概要

mkinitcpio-chkcryptoboot^AUR には mkinitcpio のインストールフックとランタイムフックが含まれています。インストールフックは、initramfs が再ビルドされるたびに実行され、UEFI システムでは GRUB の EFI スタブ ($esp/EFI/grub_uefi/grubx64.efi) のハッシュ値を計算し、BIOS システムでは GRUB が格納されているディスクの先頭 446 バイトのハッシュ値を計算します。そして、暗号化されている /boot パーティション内にある initramfs 内部にそのハッシュ値を保存します。システムがブートされると、GRUB は /boot パスワードを要求します。この時、ランタイムフックは、ルートパーティションのパスワードプロンプトが表示される前に同じハッシュ計算を行い、その結果を比較します。これらのハッシュ値が一致しない場合、ランタイムフックは以下のようなエラーを表示します:

CHKCRYPTOBOOT ALERT!
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!
Please type uppercase yes to continue:

ブートローダのハッシュ計算に加えて、ランタイムフックは実行中のカーネルのパラメータを /etc/default/chkcryptoboot.conf 内で設定されているものと比較します。これは、実行中とブートプロセスの終了後の両方でチェックされます。これにより、フックは、GRUB の設定が実行中にバイパスされていないかどうか確認し、その後、/boot パーティション全体がバイパスされていないことを確認できます。

BIOS システムにおいては、フックは GRUB の第1ステージのブートローダ (ブートデバイスの先頭 446 バイトにインストールされています) のハッシュ値を計算し、後のブートプロセスで値を比較します。メインの第2ステージの GRUB ブートローダである core.img はチェックされません。

AIDE

上記のスクリプトの代替として、AIDE によりハッシュチェックをセットアップできます。AIDE は非常に柔軟な設定ファイルによってカスタマイズできます。

STARK

これらの方法はほとんどのユーザの目的を達成できるはずですが、暗号化されていない /boot に関連する全てのセキュリティ問題に対処できるわけではありません。完全に認証されたブート連鎖を提供しようと試みるアプローチが、STARK 認証フレームワークを実装する学術論文として POTTS で公開されました。

概念実証の POTTS は Arch Linux をベースのディストリビューションとして使用しており、以下によってシステムのブート連鎖を実装しています:

POTTS - ワンタイム認証のメッセージプロンプトのためのブートメニュー。
TrustedGrub - TPM チップの PCR レジスタを使ってカーネルと initramfs を認証する GRUB Legacy 実装。
TRESOR - AES を実装しているが、実行中にマスターキーを RAM 内ではなく CPU レジスタ内に保存するカーネルパッチ。

論文の一部として、Arch Linux (2013年01月の時点の ISO) をベースにしたインストール手順が公開されました。これを試したい場合、使われているツールが標準リポジトリ内に存在せず、この方法は維持に時間がかかることに注意してください。

GPG や LUKS、OpenSSL の暗号化キーファイルを使う

以下のフォーラム投稿では、この wiki ページの前の部分で説明したように平文のキーファイルを使うのではなく、二要素認証や gpg、openssl の暗号化キーファイルを使うための手順が示されています (System Encryption using LUKS with GPG encrypted keys):

GnuPG: GPG 暗号化キーに関する投稿。この投稿では一般的な手順が書かれてあります。
OpenSSL: OpenSSL 暗号化キーに関する投稿。この投稿では ssldec フックが書かれてあるのみです。
OpenSSL: OpenSSL のソルトが付与された bf-cbc 暗号化キーに関する投稿。この投稿では bfkf initcpio フック、インストールスクリプト、暗号化されたキーファイルの生成スクリプトが書かれてあります。
LUKS: lukskey initcpio フックと LUKS 暗号化キーに関する投稿。あるいは、initcpio のカスタムの encrypt フックが書かれた以下の #/boot を暗号化し、デタッチされた LUKS ヘッダを USB 上に保存するを見てください。

注意点:

上記の手順に従う際に必要なのは 2 つの主要なパーティションだけです。1つはブートパーティション (暗号化のために必要) で、もう一つはプライマリ LVM パーティションです。この LVM パーティション内には好きなだけパーティションを作成できますが、最も重要なのは、少なくともルート、スワップ、ホームの論理ボリュームパーティションはこのパーティション内に作成する必要があるということです。これには、すべてのパーティションを1つのキーファイルだけで復号でき、さらに、暗号化されたスワップパーティションへハイバネートできるという利点があります。これを行う場合、/etc/mkinitcpio.conf でのフック配列は次のようになります:
```
HOOKS=( ... usb usbinput (etwo または ssldec) encrypt (<- openssl を使用する場合) lvm2 resume ... )
```
そして、次をカーネルパラメータに追加する必要があります:
```
resume=/dev/<VolumeGroupName>/<LVNameOfSwap>
```
暗号化されていないキーファイルを一時的にどこかに保存する必要がある場合、暗号化されていないディスク上には保存しないでください。/dev/shm などの RAM 上に保存するとなお良いです。
GPG で暗号化されたキーファイルを使用したい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使用する必要があります。これを使用しない場合、フックの配列を編集して gnupg1^AUR を使用する必要があります。
OpenSSL のアップデートにより、上記の2番目のフォーラムの投稿で言及されているカスタムの ssldec が壊れる可能性があります。

root などのパーティションのリモート解除

LUKS によって完全に暗号化されたシステムをリモートで再起動したい場合、もしくは Wake-on-LAN サービスを使ってシステムを起動したい場合、起動時にルートパーティション/ボリュームのパスフレーズを入力する手段が必要になります。ネットワークインターフェイスを設定する mkinitcpio のフックを実行することでこれを実現可能です。以下のパッケージには様々な mkinitcpio ビルドフックが含まれており設定を楽にしてくれます。

ノート:

ネットワークインターフェイスはカーネルによるデバイス名を使用してください (例: eth0)。udev によるデバイス名 (例: enp1s0) を使用してはいけません。
使用しているネットワークカードのモジュールを MODULES 行に追加する必要が場合があります。

リモートのロック解除 (フック: systemd, systemd-tool)

AUR パッケージの mkinitcpio-systemd-tool には systemd-tool という名前の systemd 中心の mkinitcpio フックが含まれており、initramfs の systemd で以下の機能を使うことができるようになります:

フックによって実現されるコア機能: systemd + mkinitcpio の統合設定バイナリと設定リソースの自動プロビジョニングオンデマンドの mkinitcpio スクリプトとインライン関数の実行	同梱されているサービスユニットによって実現される機能: initrd のデバッグ初期ユーザー空間でのネットワークの設定インタラクティブなユーザーシェル initrd におけるリモート ssh アクセス cryptsetup + カスタムパスワードエージェント

mkinitcpio-systemd-tool パッケージは systemd フックを必要とします。詳しい情報はプロジェクトの README やデフォルトの systemd サービスユニットファイルを見てください。

推奨されるフックは次の通りです: base autodetect modconf block filesystems keyboard fsck systemd systemd-tool。

リモートのロック解除 (フック: netconf, dropbear, tinyssh, ppp)

initcpio のリモートログインを実現するパッケージの別の組み合わせとして mkinitcpio-netconf あるいは mkinitcpio-ppp^AUR (インターネット経由で PPP 接続を使ってリモートでロックを解除) と SSH サーバーを使用する方法があります。SSH サーバーは mkinitcpio-dropbear または mkinitcpio-tinyssh のどちらを使用するか選択できます。これらのフックはシェルをインストールしないため、mkinitcpio-utils パッケージもインストールする必要があります。以下の手順は上記のパッケージと組み合わせて使うことができます。パスが異なる場合、注意してください。

SSH のキーペアが存在しない場合、クライアント環境でペアを生成してください (リモート環境のロックを解除するのに使用します)。mkinitcpio-tinyssh を使用する場合、Ed25519 鍵を使用することができます。
SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が .pub のファイル) をリモートマシンの /etc/dropbear/root_key または /etc/tinyssh/root_key ファイルにコピーしてください。
ヒント: 必要であれば他の SSH 公開鍵を後で追加することもできます。リモートの ~/.ssh/authorized_keys の中身をコピーする場合、リモートマシンのロックを解除するのに使用する鍵だけが含まれていることを確認してください。鍵を追加したら、mkinitcpio で initrd も再生成する必要があります。Secure Shell#SSH の保護も参照してください。
/etc/mkinitcpio.conf の "HOOKS" 行の filesystems の前に <netconf and/or ppp> <dropbear or tinyssh> encryptssh フックを追加してください (encryptssh で encrypt フックを置き換えます)。それから initramfs イメージを再生成してください。
ノート: mkinitcpio-nfs-utils に含まれている net フックは必要ありません。
ブートローダーの設定に cryptdevice= パラメータを設定して適切な引数を付けた ip= カーネルコマンドパラメータを追加してください。例えば、DHCP サーバーからリモート環境に固定 IP が割り当てられない場合、再起動してから SSH でアクセスするのが難しいため、以下のように使用したい IP を明示的に指定できます:
```
ip=192.168.1.1:::::eth0:none
```
ノート: mkinitcpio-netconf のバージョン 0.0.4 現在、複数の ip= パラメータをネストすることで複数のインターフェイスを設定できます。ip=dhcp (ip=:::::eth0:dhcp) と混ぜることはできません。インターフェイスを指定する必要があります。
```
ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none
```
詳しい説明は mkinitcpio のセクションを読んでください。設定が完了したら、ブートローダーの設定を更新してください。
Finally, restart the remote system and try to ssh to it, explicitly stating the "root" username (even if the root account is disabled on the machine, this root user is used only in the initrd for the purpose of unlocking the remote system). If you are using the mkinitcpio-dropbear package and you also have the openssh package installed, then you most probably will not get any warnings before logging in, because it convert and use the same host keys openssh uses. (Except Ed25519 keys, dropbear does not support them). In case you are using mkinitcpio-tinyssh, you have the option of installing tinyssh-convert or tinyssh-convert-git^AUR so you can use the same keys as your openssh installation (currently only Ed25519 keys). In either case, you should have run the ssh daemon at least once, using the provided systemd units, so the keys can be generated first. After rebooting the machine, you should be prompted for the passphrase to unlock the root device. Afterwards, the system will complete its boot process and you can ssh to it as you normally would (with the remote user of your choice).

ヒント: If you would simply like a nice solution to mount other encrypted partitions (such as /home) remotely, you may want to look at this forum thread.

wifi でリモートのロック解除 (フック: 自分で作成)

The net hook is normally used with an ethernet connection. In case you want to setup a computer with wireless only, and unlock it via wifi, you can create a custom hook to connect to a wifi network before the net hook is run.

Below example shows a setup using a usb wifi adapter, connecting to a wifi network protected with WPA2-PSK. In case you use for example WEP or another boot loader, you might need to change some things.

Modify /etc/mkinitcpio.conf:
- Add the needed kernel module for your specific wifi adatper.
- Include the wpa_passphrase and wpa_supplicant binaries.
- Add a hook wifi (or a name of your choice, this is the custom hook that will be created) before the net hook.
```
MODULES="module"
BINARIES="wpa_passphrase wpa_supplicant"
HOOKS="base udev autodetect ... wifi net ... dropbear encryptssh ..."
```

Create the wifi hook in /etc/initcpio/hooks/wifi:

run_hook ()
{
	# sleep a couple of seconds so wlan0 is setup by kernel
	sleep 5

	# set wlan0 to up
	ip link set wlan0 up

	# assocciate with wifi network
	# 1. save temp config file
	wpa_passphrase "network ESSID" "pass phrase" > /tmp/wifi

	# 2. assocciate
	wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi

	# sleep a couple of seconds so that wpa_supplicant finishes connecting
	sleep 5

	# wlan0 should now be connected and ready to be assigned an ip by the net hook
}

run_cleanuphook ()
{
	# kill wpa_supplicant running in the background
	killall wpa_supplicant

	# set wlan0 link down
	ip link set wlan0 down

	# wlan0 should now be fully disconnected from the wifi network
}

Create the hook installation file in /etc/initcpio/install/wifi:

build ()
{
	add_runscript
}
help ()
{
cat<<HELPEOF
	Enables wifi on boot, for dropbear ssh unlocking of disk.
HELPEOF
}

ip=:::::wlan0:dhcp をカーネルパラメータに追加。衝突しないように ip=:::::eth0:dhcp は削除してください。
Optionally create an additional boot entry with kernel parameter ip=:::::eth0:dhcp.
initramfs イメージを再生成。
ブートローダーの設定を更新。例えば GRUB の場合:
```
# grub-mkconfig -o /boot/grub/grub.cfg
```

Remember to setup WiFi, so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.

一度きりのパスワード無しの再起動

ターミナルに暗号化済みルートドライブのパスワードを入力する必要なしにリモートのヘッドレスあるいはアクセス不能なシステムを再起動するためのもう一つの方法は、一時的なキーファイルを使用することです。キーファイルはブート時にカーネルからアクセス可能な場所に配置する必要があり、cryptkey のブートパラメータを追加する必要があり、そして、そのキーファイルを "cryptsetup luksAddKey" コマンドを使って有効なキーとして登録する必要があります。

この作業は passless-boot^AUR を使えば簡単に行うことができます。このツールの readme ファイルで説明されているこのツールのセットアップ手順は、自身でセットアップする際のテンプレートとしても使えるかもしれません。Security considerations の章での議論を参照してください。

ソリッドステートドライブ (SSD) の Discard/TRIM のサポート

ソリッドステートドライブを使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは discard オプションが無効な状態でマウントされます。

セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [3][4]。TRIM を有効にすると解放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は cryptsetup の開発者によるブログ記事で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である --cipher aes-cbc-essiv で暗号化されている場合、最新のデフォルト設定を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。

以下のケースに分かれます:

デバイスをデフォルトの dm-crypt LUKS モードで暗号化している場合:
- By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives? and Full disk encryption on an ssd.
- TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.

ディスクの完全消去#フラッシュメモリも参照してください。

デバイスを dm-crypt の plain モードで暗号化している、または LUKS ヘッダーを別個に保存している場合:
- 妥当な否認権が必要な場合、TRIM を使用してはいけません。上記のとおり暗号化していることが分かってしまうからです。
- 妥当な否認権が必要ない場合、上記で説明しているセキュリティ上の懸案を気にしないのであれば TRIM を使用してパフォーマンスを向上できます。

警告: ドライブの TRIM を有効にする前に、デバイスが TRIM コマンドを完全にサポートしていることを確認してください。TRIM がサポートされていない場合、データが消失する危険があります。ソリッドステートドライブ#TRIM を見てください。

In linux 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add :allow-discards to the cryptdevice option. The TRIM option may look like this:

cryptdevice=/dev/sdaX:root:allow-discards

メインの cryptdevice 設定オプションは :allow-discards よりも先に来ます。Dm-crypt/システム設定を見てください。

If you are using a systemd based initrd, you must pass:

rd.luks.options=discard

Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab. For details, please refer to the TRIM page.

For LUKS devices unlocked manually on the console or via /etc/crypttab either discard or allow-discards may be used.

encrypt フックと複数のディスク

The encrypt hook only allows for a single cryptdevice= entry (FS#23182). In system setups with multiple drives this may be limiting, because dm-crypt has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the encrypt hook.

The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a LUKS on LVM setup to a new disk. The second with modifying the encrypt hook to unlock multiple disks in LUKS setups without LVM. The third section then again uses LVM, but modifies the encrypt hook to unlock the encrypted LVM with a remote LUKS header.

LVM を複数のディスクに拡張

The management of multiple disks is a basic LVM feature and a major reason for its partitioning flexibility. It can also be used with dm-crypt, but only if LVM is employed as the first mapper. In such a LUKS on LVM setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk.

警告: Backup! While resizing filesystems may be standard, keep in mind that operations may go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.

新しいドライブの追加

まず、Dm-crypt/ドライブの準備に従って新しいディスクを準備すると良いでしょう。そして LVM としてパーティショニングします (例: 全ての領域を /dev/sdY1 に割り当ててパーティションタイプを "8E00" (Linux LVM) に設定)。その後、新しいディスク・パーティションを既存の LVM ボリュームグループに追加します:

# pvcreate /dev/sdY1
# vgextend MyStorage /dev/sdY1

論理ボリュームの拡張

For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the cryptdevice root partition, but in this case the procedure has to be performed from an Arch Install ISO.

In this example, it is assumed that the logical volume for /home (lv-name homevol) is going to be expanded with the fresh disk space:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Now the logical volume is extended and the LUKS container comes next:

# cryptsetup open --type luks /dev/mapper/MyStorage-homevol home
# umount /home      # as a safety, in case it was automatically remounted
# cryptsetup --verbose resize home

最後に、ファイルシステムのサイズを変更:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home

Done! If it went to plan, /home can be remounted

# mount /dev/mapper/home /home

and now includes the span to the new disk. Note that the cryptsetup resize action does not affect encryption keys, they have not changed.

複数のパーティションの encrypt フックを修正

複数のパーティションにまたがる root ファイルシステム

起動時に複数のハードドライブからルートファイルシステム (/) を復号化するように encrypt フックを修正することが可能です:

# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
# cp /usr/lib/initcpio/hooks/encrypt  /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2

ブートオプションに cryptdevice2= を (必要であれば cryptkey2= も) 追加して、mkinitcpio.conf に encrypt2 フックを追加してからリビルドしてください。Dm-crypt/システム設定も参照。

複数の root 以外のパーティション

Maybe you have a requirement for using the encrypt hook on a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.

The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of /etc/fstab (at least).

Of course, if the cryptsetup package gets upgraded, you will have to change this script again. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.

If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like

kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5

If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). GRUB can handle multiple array definitions just fine:

kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

リモート LUKS ヘッダーを使ってシステムを暗号化

以下の例では Dm-crypt/システム全体の暗号化#Plain dm-crypt と同じセットアップを使います。先に進む前に読んでおいてください。

リモートのヘッダーを使うことにより、暗号化されたブロックデバイスには暗号化データだけが保持され、攻撃者にヘッダーの存在が露見しないかぎり否認可能性を得ることができます。plain dm-crypt を使用する場合と似ていますが、LUKS の利点としてマスター鍵と鍵導出関数によって複数のパスフレーズが使えるなどのメリットがあります。さらに、リモートヘッダーは GPG や OpenSSL で暗号化したキーファイルを使う方法よりも簡単に二要素認証を実現できます。内蔵のパスワードプロンプトで複数回の入力が可能です。詳しくはディスク暗号化#暗号メタデータを見てください。

dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプションを見て暗号化オプションを確認してから、暗号化したシステムパーティションを設定し cryptsetup で使用するヘッダーファイルを作成してください:

# truncate -s 2M header.img
# cryptsetup luksFormat /dev/sdX --header header.img

コンテナを開くには:

# cryptsetup open --header header.img --type luks /dev/sdX enc

後は LVM on LUKS セットアップに従ってください。同じようにリムーバブルデバイスに boot パーティションを準備します (同じでなければ、暗号化ディスクを解錠するためのヘッダーファイルを別にする意味がありません)。そして header.img を移動します:

# mv header.img /mnt/boot

Follow the installation procedure up to the mkinitcpio step (you should now be arch-chrooted inside the encrypted system).

There are two options for initramfs to support a detached LUKS header.

systemd フックを使う

まず /etc/crypttab.initramfs を作成して暗号化デバイスを追加してください。構文は crypttab(5) に定義されています:

/etc/crypttab.initramfs

MyStorage    PARTUUID=00000000-0000-0000-0000-000000000000    none    header=/boot/header.img

systemd を使用するように /etc/mkinitcpio.conf を編集して FILES にヘッダーを追加してください:

/etc/mkinitcpio.conf

FILES="/boot/header.img"

HOOKS="... systemd ... block sd-encrypt sd-lvm2 filesystems ..."

initramfs を再作成したら設定は完了です。

ノート: No cryptsetup parameters need to be passed to the kernel command line, since/etc/crypttab.initramfs will be added as /etc/crypttab in the initramfs. If you wish to specify them in the kernel command line see systemd-cryptsetup-generator(8) for the supported options.

encrypt フックを修正する

This method shows how to modify the encrypt hook in order to use a remote LUKS header. Now the encrypt hook has to be modified to let cryptsetup use the separate header (FS#42851; base source and idea for these changes published on the BBS). Make a copy so it is not overwritten on a mkinitcpio update:

# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2

/etc/initcpio/hooks/encrypt2 (around line 52)

warn_deprecated() {
    echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
    echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
}

local headerFlag=false
for cryptopt in ${cryptoptions//,/ }; do
    case ${cryptopt} in
        allow-discards)
            cryptargs="${cryptargs} --allow-discards"
            ;;  
        header)
            cryptargs="${cryptargs} --header /boot/header.img"
            headerFlag=true
            ;;
        *)  
            echo "Encryption option '${cryptopt}' not known, ignoring." >&2 
            ;;  
    esac
done

if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
    if $headerFlag || cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
        [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
        dopassphrase=1

Now edit the mkinitcpio.conf to add the encrypt2 and lvm2 hooks, the header.img to FILES and the loop to MODULES, apart from other configuration the system requires:

/etc/mkinitcpio.conf

MODULES="loop"

FILES="/boot/header.img"

HOOKS="... encrypt2 lvm2 ... filesystems ..."

This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up the initramfs is created.

次にブートローダーを設定して cryptdevice= で新しい header オプションも設定します:

cryptdevice=/dev/sdX:enc:header

To finish, following Dm-crypt/システム全体の暗号化#インストール後 is particularly useful with a /boot partition on an USB storage medium.

ヒント: You will notice that since the system partition only has "random" data, it does not have a partition table and by that an UUID or a name. But you can still have a consistent mapping using the disk id under /dev/disk/by-id/