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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(戻るリンクの削除)
(二要素認証に用語を統一)
 
(5人の利用者による、間の17版が非表示)
1行目: 1行目:
 
{{Lowercase title}}
 
{{Lowercase title}}
[[Category:セキュリティ]]
+
[[Category:保存データ暗号化]]
  +
[[en:dm-crypt/Specialties]]
[[Category:ファイルシステム]]
 
[[en:Dm-crypt/Specialties]]
+
[[es:Dm-crypt (Español)/Specialties]]
  +
[[pl:Dm-crypt (Polski)/Specialties]]
   
==暗号化されていない boot パーティションのセキュア化==
+
== 暗号化されていない boot パーティションのセキュア化 ==
   
たとえ [[Dm-crypt/システム全体の暗号化|root を暗号化]]したとしても、{{ic|/boot}} パーティションと [[Master Boot Record]] は暗号化できません。この2つを暗号化するのは基本的に不可能です。[[ブートローダー]]や BIOS dm-crypt コンテナの暗号化を解除することではできないため、ブートプロセス続行できません。ただし [[GRUB]] には LUKS で暗号化した {{ic|/boot}} を復号する機能が存在します[[GRUB]] を見てください。
+
たとえ[[Dm-crypt/システム全体の暗号化|ルートパーティションを暗号化]]したとしても、{{ic|/boot}} パーティションと [[Master Boot Record]] は暗号化できません。通常、れらの2つを暗号化するのは不可能です。[[ブートローダー]]や BIOS dm-crypt コンテナの暗号化を解除することできないため、ブートプロセス続行できません。ただし[[GRUB]] には LUKS で暗号化した {{ic|/boot}} を復号する機能が存在します - [[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)]] を見てください。
   
  +
このセクションでは、ブートプロセスをよりセキュアにするためにできることを説明しています。
{{Warning|Note that securing the {{ic|/boot}} partition and MBR can mitigate numerous attacks that occur during the boot process, but systems configured this way may still be vulnerable to BIOS/UEFI/firmware tampering, hardware keyloggers, cold boot attacks, and many other threats that are beyond the scope of this article. For an overview of system-trust issues and how these relate to full-disk encryption, refer to [http://www.youtube.com/watch?v=pKeiKYA03eE].}}
 
   
  +
{{Warning|1={{ic|/boot}} パーティションと MBR をセキュア化することによりブートプロセス中に起こりうる数々の攻撃を緩和することはできますが、この方法で構成されたシステムは依然として BIOS/UEFI/ファームウェアの改ざん、ハードウェアキーロガー、コールドブート攻撃、そしてこの記事の範囲を超える他の多くの脅威に対しては脆弱である可能性があります。システムの信頼性の問題やディスク全体の暗号化に関連する問題の概要は、[https://www.youtube.com/watch?v=pKeiKYA03eE] を参照してください。}}
===リムーバルデバイスから起動===
 
   
  +
{{Note|[[UEFI]] を使用している場合、暗号化しないでおく必要があるのは [[ESP]] のみです ([[ユニファイドカーネルイメージ]]を使用している場合など)。この場合、[[セキュアブート]]を使用することにより、ブートプロセスが改ざんされていないことを保証することができます。これは、以下の方法と同じ効果を得ることのできる簡単な方法です。[[dm-crypt/システム全体の暗号化#Simple encrypted root with TPM2 and Secure Boot]]{{Broken section link}} を参照してください。}}
{{warning|systemd バージョン 230 から cryptsetup のジェネレータは crypto キーファイルの RequiresMountsFor を省きます。そのため、ファイルが含まれているファイルシステムをアンマウントすると、cryptsetup サービスも停止します。ファイルシステムと cryptokey が必要になるのは crypto コンテナを初期設定するときだけなので、この挙動は間違っています。詳しくは [https://github.com/systemd/systemd/issues/3816] を参照。}}
 
  +
  +
=== リムーバブルデバイスから起動 ===
  +
  +
別のデバイスを使ってシステムを起動するのはとても簡単で、特定の種類の攻撃に対してセキュリティを高めることができます。[[Dm-crypt/システム全体の暗号化|ルートファイルシステムを暗号化]]したシステムで脆弱ポイントとなりえるのは以下の2つです:
   
別のデバイスを使ってシステムを起動するのはとても簡単で、特定の攻撃に対してセキュリティを高めることができます。[[Dm-crypt/システム全体の暗号化|ルートファイルシステムを暗号化]]したシステムで脆弱ポイントとなりえるのは以下の2つです:
 
 
* [[Master Boot Record]]
 
* [[Master Boot Record]]
 
* {{ic|/boot}} パーティション
 
* {{ic|/boot}} パーティション
システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。改竄から保護する方法として、USB ドライブなどのリムーバルメディアに保存して、ハードディスクの代わりとしてドライブから起動することができます。ドライブを肌身離さず持ち歩いていれば、改竄を加えられる恐れがなくなり、システムを解錠する認証機構をさらにセキュアにすることができます。
 
   
  +
システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。これらを改竄から保護する方法として、USB ドライブなどのリムーバブルメディアに保存して、ハードディスクの代わりとしてドライブから起動すると良いでしょう。ドライブを肌身離さず持ち歩いていれば、これらのコンポーネントに改竄を加えられる恐れがなくなり、システムを解錠する認証機構をさらにセキュアにすることができます。
既にシステム設定を終えていて専用のパーティションを {{ic|/boot}} にマウントしていることが前提です。まだ設定していない場合、ハードディスクをリムーバルメディアに置き換えて [[dm-crypt/システム設定#ブートローダー]]の手順に従ってください。
 
  +
{{Note|You must make sure your system supports booting from the chosen medium, be it a USB drive, an external hard drive, an SD card, or anything else.}}
 
  +
ここでは、既にシステム設定を終えていて専用のパーティションを {{ic|/boot}} にマウントしていると仮定します。まだ設定していない場合は、[[dm-crypt/システム設定#カーネルパラメータ]] の手順に従ってください (この時、ハードディスクはリムーバブルメディアに置き換えて手順を進めてください)。
リムーバルドライブ ({{ic|/dev/sdx}}) を準備:
 
  +
# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...
 
  +
{{Note|選んだメディア (USB ドライブ、外部ハードドライブ、SD カードなど) からのブートが、あなたのシステムでサポートされていることを確認してください。}}
# mkfs.ext2 /dev/sdx1
 
  +
  +
リムーバブルドライブ ({{ic|/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
 
# mount /dev/sdx1 /mnt
  +
既存の {{ic|/boot}} の中身をコピー:
 
  +
既存の {{ic|/boot}} の中身をリムーバブル上の新しい boot パーティションにコピーしてください:
# cp -R -i -d /boot/* /mnt
 
  +
新しいパーティションをマウントして [[fstab]] ファイルを更新:
 
  +
# cp -ai /boot/* /mnt/
  +
  +
新しいパーティションをマウントしてください。[[fstab]] を適宜更新するのを忘れないでください:
  +
 
# umount /boot
 
# umount /boot
 
# umount /mnt
 
# umount /mnt
 
# mount /dev/sdx1 /boot
 
# mount /dev/sdx1 /boot
 
# genfstab -p -U / > /etc/fstab
 
# genfstab -p -U / > /etc/fstab
  +
 
その後 [[GRUB]] を更新してください。{{ic|grub-mkconfig}} は自動的に新しいパーティションの UUID を認識するはずですが、カスタムメニューエントリは手動で更新する必要があるかもしれません。
 
その後 [[GRUB]] を更新してください。{{ic|grub-mkconfig}} は自動的に新しいパーティションの UUID を認識するはずですが、カスタムメニューエントリは手動で更新する必要があるかもしれません。
  +
 
# grub-mkconfig -o /boot/grub/grub.cfg
 
# grub-mkconfig -o /boot/grub/grub.cfg
  +
# grub-install /dev/sdx # ハードディスクではなく、リムーバブルデバイスにインストール。BIOS システムの場合。
# grub-install /dev/sdx #install to the removable device, not the hard disk.
 
  +
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub # UEFI システムの場合。
  +
 
再起動して新しい設定をテストしてください。忘れずに [[BIOS]] や [[UEFI]] でデバイスのブート順序を設定してください。システムが起動しない場合、ハードドライブから起動することで問題を修正することができます。
 
再起動して新しい設定をテストしてください。忘れずに [[BIOS]] や [[UEFI]] でデバイスのブート順序を設定してください。システムが起動しない場合、ハードドライブから起動することで問題を修正することができます。
   
===chkboot===
+
=== chkboot ===
{{warning|chkboot makes a {{ic|/boot}} partition '''tamper-evident''', not '''tamper-proof'''. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.}}
 
ct-magazine (Issue 3/12, page 146, 01.16.2012, [http://www.heise.de/ct/inhalt/2012/03/6/]) の記事に記載されていた chkboot スクリプトは {{ic|/boot}} のファイルに対して SHA-1 ハッシュや inode、ハードドライブの占有ブロックが変化していないかチェックします。[[Master Boot Record]] もチェックされます。ある種の攻撃を防ぐことはできませんが、防御力を高めることができます。スクリプトの設定は暗号化されていない {{ic|/boot}} に保存されません。暗号化システムのロックがかかっている(休眠)状態であれば、見かけ上は起動時にパーティションの自動チェックサム比較が行われることはわからないため、攻撃するのが難しくなります。ただし、攻撃者にあらかじめ予期されていた場合、ファームウェアを操作してカーネルの上でコードを動かして、ファイルシステム (例: {{ic|boot}}) のアクセスを横取りされてしまう可能性はあります。一般的に、ファームウェアよりも下の階層では改竄されていないという保証は得られません。
 
   
  +
{{Warning|chkboot は {{ic|/boot}} パーティションの'''改ざんを検出可能'''にしますが、'''改ざんを防止'''するわけではありません。chkboot スクリプトを実行する時までに、すでにあなたはパスワードを、危殆化している可能性のあるブートローダ、カーネル、そして初期 RAM ディスクに入力しています。システムが chkboot の整合性テストに合格しない場合、あなたのデータの安全性に対していかなる保証もできません。}}
インストールスクリプトが [ftp://ftp.heise.de/pub/ct/listings/1203-146.zip 存在します] (作者: Juergen Schmidt, ju at heisec.de; ライセンス: GPLv2)。また、{{AUR|chkboot}} パッケージで[[インストール]]することもできます。
 
   
  +
ct-magazine (3/12 号、146 ページ、2012年1月16日、[https://www.heise.de/ct/inhalt/2012/03/6/]) の記事によると、以下のスクリプトは {{ic|/boot}} のファイルに対して SHA-1 ハッシュや inode、ハードドライブの占有ブロックが変化していないかチェックします。また [[Master Boot Record]] もチェックします。特定の種類の攻撃を防ぐことはできませんが、防御力を高めることができます。スクリプト自体の設定は暗号化されていない {{ic|/boot}} に保存されません。暗号化されたシステムのロックがかかっている/電源が落ちている状態であれば、見かけ上は起動時にパーティションの自動チェックサム比較が行われることはわからないため、攻撃するのが難しくなります。ただし、攻撃者にあらかじめ予期されていた場合、ファームウェアを操作してカーネルの上でコードを動かして、ファイルシステム (例: {{ic|boot}}) のアクセスを横取りされてしまう可能性はあります。一般的に、ファームウェアよりも下の階層では改竄されていないという保証は得られません。
インストールしたらサービスファイル (パッケージに含まれています) を追加して[[有効化]]してください:
 
  +
[Unit]
 
  +
インストールスクリプトが[https://ftp.heise.de/pub/ct/listings/1203-146.zip 存在します] (作者: Juergen Schmidt, ju at heisec.de; ライセンス: GPLv2)。また、{{AUR|chkboot}} パッケージで[[インストール]]することもできます。
Description=Check that boot is what we want
 
Requires=basic.target
 
After=basic.target
 
 
[Service]
 
Type=oneshot
 
ExecStart=/usr/local/bin/chkboot.sh
 
 
[Install]
 
WantedBy=multi-user.target
 
   
  +
インストールしたら、{{ic|chkboot.service}} を[[有効化]]してください。
systemd の場合は注意が必要です。執筆時点ではオリジナルの {{ic|chkboot.sh}} スクリプトには {{ic|<u> </u>#!/bin/bash}} の最初に空白が含まれておりサービスを起動するには空白を削除する必要があります。
 
   
{{ic|/usr/local/bin/chkboot_user.sh}} はログイン後すぐに実行する必要があるため、[[自動起動]]するように設定してくだ (例: KDE の場合 -> ''System Settings -> Startup and Shutdown -> Autostart''; GNOME 3: ''gnome-session-properties'')。
+
{{ic|/usr/local/bin/chkboot_user.sh}} はログイン後すぐに実行する必要があるのでこのスクリプトを[[自動起動]]させる必要があります (例えば、KDE では ''System Settings -> Startup and Shutdown -> Autostart''GNOME では ''gnome-session-properties'')。
   
Arch Linux では新しいカーネルのアップデートなどによって {{ic|/boot}} に頻繁に変更が加えられます。システムアップグレードするたびにスクリプトを使用すると良いでしょう:
+
Arch Linux では新しいカーネルなどによって {{ic|/boot}} に頻繁に変更が加えられます。なので、アップグレードするたびにスクリプトを実行させると良いでしょう。これを行う方法としては以下があります:
   
#!/bin/bash
+
#!/bin/sh
 
#
 
#
  +
# 注: ''<user>'' にユーザ名を入力してください。このスクリプトを sudo で実行すると、pacman と chboot が自動的に動作します。
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically
 
 
#
 
#
echo "Pacman update [1] Quickcheck before updating" &
+
echo "Pacman update [1] Quickcheck before updating" &
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
+
sudo -u ''<user>'' /usr/local/bin/chkboot_user.sh
 
/usr/local/bin/chkboot.sh
 
/usr/local/bin/chkboot.sh
  +
sudo -u ''<user>'' /usr/local/bin/chkboot_user.sh
sync # sync disks with any results
 
  +
echo "Pacman update [2] Syncing repos for pacman"
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
 
echo "Pacman update [2] Syncing repos for pacman"
 
 
pacman -Syu
 
pacman -Syu
 
/usr/local/bin/chkboot.sh
 
/usr/local/bin/chkboot.sh
  +
sudo -u ''<user>'' /usr/local/bin/chkboot_user.sh
sync
 
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user>
 
 
echo "Pacman update [3] All done, let us roll on ..."
 
echo "Pacman update [3] All done, let us roll on ..."
   
=== mkinitcpio-chkcryptoboot ===
+
=== mkinitcpio-chkcryptoboot ===
{{Warning|このフックは [[GRUB]] のコアコード (MBR) や EFI スタブは暗号化しません。攻撃者がブートローダーの設定を変更してカーネルや initramfs を実行時に改竄できる状態からは保護されません。}}
 
{{aur|mkinitcpio-chkcryptoboot}} は初期ユーザー空間で整合性チェックを行ってシステムのセキュリティが破られている場合に root パーティションのパスワードを入力しないようにユーザーに忠告する [[mkinitcpio]] フックです。[[Dm-crypt/システム全体の暗号化|ブートパーティションを暗号化]]することでセキュリティを確保し、[[GRUB]] の {{ic|cryptodisk.mod}} モジュールでロックを解除します。root ファイルシステムのパーティションは別のパスワードを使って暗号化します。これなら、オフラインの改竄からも [[initramfs]] や[[カーネル]]を守ることができ、たとえマシンに侵入されて {{ic|/boot}} パーティションのパスワードが入力されても root パーティションは安全です (chkcryptoboot フックが改竄を検出して、フック自体が改竄されていない場合)。
 
   
  +
{{Warning|このフックは [[GRUB]] のコア (MBR) コードや EFI スタブは暗号化'''しません'''。攻撃者がブートローダーの設定を変更してカーネルや initramfs を実行時に改竄できる状態からは保護されません。}}
This hook requires {{Pkg|grub}} release >=2.00 to function, and a dedicated, LUKS encrypted {{ic|/boot}} partition with its own password in order to be secure.
 
  +
  +
{{aur|mkinitcpio-chkcryptoboot}} は、初期ユーザー空間で整合性チェックを行ってシステムのセキュリティが破られている場合に root パーティションのパスワードを入力しないようにユーザーに忠告する [[mkinitcpio]] フックです。[[Dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|ブートパーティションを暗号化]]することでセキュリティを確保し、[[GRUB# 暗号化された /boot|GRUB]] の {{ic|cryptodisk.mod}} モジュールでロックを解除します。root ファイルシステムのパーティションは別のパスワードを使って暗号化します。これなら、オフラインの改竄からも [[initramfs]] や[[カーネル]]を守ることができ、たとえマシンに侵入されて {{ic|/boot}} パーティションのパスワードが入力されても root パーティションは安全です (chkcryptoboot フックが改竄を検出して、フック自体が改竄されていない場合)。
  +
  +
このフックが機能するには {{Pkg|grub}} バージョン >= 2.00 が必要で、さらに、セキュアに保つために LUKS で暗号化された専用の {{ic|/boot}} パーティションに独自のパスワードが設定されている必要があります。
   
 
==== インストール ====
 
==== インストール ====
  +
{{aur|mkinitcpio-chkcryptoboot}} を[[インストール]]して {{ic|/etc/default/chkcryptoboot.conf}} を編集します。If you want the ability of detecting if your boot partition was bypassed, edit the {{ic|CMDLINE_NAME}} and {{ic|CMDLINE_VALUE}} variables, with values known only to you. You can follow the advice of using two hashes as is suggested right after the installation. Also, be sure to make the appropriate changes to the [[カーネルパラメータ|kernel command line]] in {{ic|/etc/default/grub}}. Edit the {{ic|1=HOOKS=}} line in {{ic|/etc/mkinitcpio.conf}}, and insert the {{ic|chkcryptoboot}} hook '''before''' {{ic|encrypt}}. When finished, [[Mkinitcpio#イメージ作成とアクティベーション|rebuild]] the initramfs.
 
  +
{{aur|mkinitcpio-chkcryptoboot}} を[[インストール]]し、{{ic|/etc/default/chkcryptoboot.conf}} を編集してください。ブートパーティションがバイパスされたかどうかを検出したい場合は、{{ic|CMDLINE_NAME}} 変数と {{ic|CMDLINE_VALUE}} 変数を編集して、それぞれにあなただけが知っている値を入れてください。パッケージのインストール後に表示されるアドバイスの通りに、2つのハッシュ値を使うことができます。また、{{ic|/etc/default/grub}} で[[カーネルコマンドライン]]を適切に変更することも忘れないでください。{{ic|/etc/mkinitcpio.conf}} 内の {{ic|1=HOOKS=}} 行を編集して {{ic|chkcryptoboot}} フックを {{ic|encrypt}} '''より前に'''加えてください。終わったら、[[initramfs を再生成する|initramfs を再生成]]してください。
   
 
==== 技術的な概要 ====
 
==== 技術的な概要 ====
{{aur|mkinitcpio-chkcryptoboot}} consists of an install hook and a run-time hook for mkinitcpio. The install hook runs every time the initramfs is rebuilt, and hashes the GRUB [[UEFI|EFI]] stub ({{ic|$esp/EFI/grub_uefi/grubx64.efi}}) (in the case of [[UEFI]] systems) or the first 446 bytes of the disk on which GRUB is installed (in the case of BIOS systems), and stores that hash inside the initramfs located inside the encrypted {{ic|/boot}} partition. When the system is booted, GRUB prompts for the {{ic|/boot}} password, then the run-time hook performs the same hashing operation and compares the resulting hashes before prompting for the root partition password. If they do not match, the hook will print an error like this:
 
{{bc|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:
 
}}
 
   
  +
{{aur|mkinitcpio-chkcryptoboot}} には mkinitcpio のインストールフックとランタイムフックが含まれています。インストールフックは、initramfs が再ビルドされるたびに実行され、[[UEFI]] システムでは GRUB の [[EFI]] スタブ ({{ic|$esp/EFI/grub_uefi/grubx64.efi}}) のハッシュ値を計算し、BIOS システムでは GRUB が格納されているディスクの先頭 446 バイトのハッシュ値を計算します。そして、暗号化されている {{ic|/boot}} パーティション内にある initramfs 内部にそのハッシュ値を保存します。システムがブートされると、GRUB は {{ic|/boot}} パスワードを要求します。この時、ランタイムフックは、ルートパーティションのパスワードプロンプトが表示される前に同じハッシュ計算を行い、その結果を比較します。これらのハッシュ値が一致しない場合、ランタイムフックは以下のようなエラーを表示します:
In addition to hashing the boot loader, the hook also checks the parameters of the running kernel against those configured in {{ic|/etc/default/chkcryptoboot.conf}}. This is checked both at run-time and after the boot process is done. This allows the hook to detect if GRUB's configuration was not bypassed at run-time and afterwards to detect if the entire {{ic|/boot}} partition was not bypassed.
 
   
  +
CHKCRYPTOBOOT ALERT!
For BIOS systems the hook creates a hash of GRUB's first stage bootloader (installed to the first 446 bytes of the bootdevice) to compare at the later boot processes. The main second-stage GRUB bootloader {{ic|core.img}} is not checked.
 
  +
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:
   
  +
ブートローダのハッシュ計算に加えて、ランタイムフックは実行中のカーネルのパラメータを {{ic|/etc/default/chkcryptoboot.conf}} 内で設定されているものと比較します。これは、実行中とブートプロセスの終了後の両方でチェックされます。これにより、フックは、GRUB の設定が実行中にバイパスされていないかどうか確認し、その後、{{ic|/boot}} パーティション全体がバイパスされていないことを確認できます。
=== 他の方法 ===
 
   
  +
BIOS システムにおいては、フックは GRUB の第1ステージのブートローダ (ブートデバイスの先頭 446 バイトにインストールされています) のハッシュ値を計算し、後のブートプロセスで値を比較します。メインの第2ステージの GRUB ブートローダである {{ic|core.img}} はチェックされません。
上記のスクリプトの代わりに、[[AIDE]] によるハッシュチェックを設定することもできます。柔軟な設定ファイルでカスタマイズが可能です。
 
   
  +
=== AIDE ===
While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted {{ic|/boot}}. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the [http://www1.informatik.uni-erlangen.de/stark STARK] authentication framework.
 
   
  +
上記のスクリプトの代替として、[[AIDE]] によりハッシュチェックをセットアップできます。AIDE は非常に柔軟な設定ファイルによってカスタマイズできます。
The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with
 
* POTTS - a boot menu for a one-time authentication message prompt
 
* TrustedGrub - a [[GRUB Legacy]] implementation which authenticates the kernel and initramfs against TPM chip registers
 
* TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime.
 
As part of the thesis [http://13.tc/p/potts/manual.html installation] instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.
 
   
  +
=== STARK ===
==GPG や OpenSSL で暗号化されたキーファイルを使う==
 
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:
 
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.
 
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.
 
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 Post regarding OpenSSL salted bf-cbc encrypted keys] This post has the {{ic|bfkf}} initcpio hooks, install, and encrypted keyfile generator scripts.
 
* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 Post regarding LUKS encrypted keys] with a {{ic|lukskey}} initcpio hook.
 
   
  +
これらの方法はほとんどのユーザの目的を達成できるはずですが、暗号化されていない {{ic|/boot}} に関連する全てのセキュリティ問題に対処できるわけではありません。完全に認証されたブート連鎖を提供しようと試みるアプローチが、[https://www1.informatik.uni-erlangen.de/stark STARK] 認証フレームワークを実装する学術論文として POTTS で公開されました。
Note that:
 
  +
* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} should look like this:{{bc|1=HOOKS=" ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... "}} そして[[カーネルパラメータ]]に以下を追加してください: {{bc|1=resume=/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>}}
 
  +
概念実証の POTTS は Arch Linux をベースのディストリビューションとして使用しており、以下によってシステムのブート連鎖を実装しています:
* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.
 
  +
* GPG で暗号化されたキーファイルを使いたい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使う必要があります。もしくはフックを編集して AUR の {{AUR|gnupg1}} パッケージを使ってください。
 
  +
* POTTS - ワンタイム認証のメッセージプロンプトのためのブートメニュー。
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.
 
  +
* TrustedGrub - [[Trusted Platform Module|TPM チップ]]の PCR レジスタを使ってカーネルと initramfs を認証する [[GRUB Legacy]] 実装。
  +
* TRESOR - AES を実装しているが、実行中にマスターキーを RAM 内ではなく CPU レジスタ内に保存するカーネルパッチ。
  +
  +
論文の一部として、Arch Linux (2013年01月の時点の ISO) をベースにした[https://13.tc/p/potts/manual.html インストール]手順が公開されました。これを試したい場合、使われているツールが標準リポジトリ内に存在せず、この方法は維持に時間がかかることに注意してください。
  +
  +
== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==
  +
  +
以下のフォーラム投稿では、この wiki ページの前の部分で説明したように平文のキーファイルを使うのではなく、二要素認証 や gpg、openssl の暗号化キーファイルを使うための手順が示されています ([https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]):
  +
  +
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 GPG 暗号化キーに関する投稿]。この投稿では一般的な手順が書かれてあります。
  +
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 OpenSSL 暗号化キーに関する投稿]。この投稿では {{ic|ssldec}} フックが書かれてあるのみです。
  +
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 OpenSSL のソルトが付与された bf-cbc 暗号化キーに関する投稿]。この投稿では {{ic|bfkf}} initcpio フック、インストールスクリプト、暗号化されたキーファイルの生成スクリプトが書かれてあります。
  +
* LUKS: {{ic|lukskey}} initcpio フックと [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 LUKS 暗号化キーに関する投稿]。あるいは、initcpio のカスタムの encrypt フックが書かれた以下の [[#/boot を暗号化し、デタッチされた LUKS ヘッダを USB 上に保存する]] を見てください。
  +
  +
注意点:
  +
  +
* 上記の手順に従う際に必要なのは 2 つの主要なパーティションだけです。1つはブートパーティション (暗号化のために必要) で、もう一つはプライマリ LVM パーティションです。この LVM パーティション内には好きなだけパーティションを作成できますが、最も重要なのは、少なくともルート、スワップ、ホームの論理ボリュームパーティションはこのパーティション内に作成する必要があるということです。これには、すべてのパーティションを1つのキーファイルだけで復号でき、さらに、暗号化されたスワップパーティションへハイバネートできるという利点があります。これを行う場合、{{ic|/etc/mkinitcpio.conf}} でのフック配列は次のようになります: {{bc|1=HOOKS=( ... usb usbinput (etwo または ssldec) encrypt (<- openssl を使用する場合) lvm2 resume ... )}} そして、次を[[カーネルパラメータ]]に追加する必要があります: {{bc|1=resume=/dev/<VolumeGroupName>/<LVNameOfSwap>}}
  +
* 暗号化されていないキーファイルを一時的にどこかに保存する必要がある場合、暗号化されていないディスク上には保存しないでください。{{ic|/dev/shm}} などの RAM 上に保存するとなお良いです。
  +
* GPG で暗号化されたキーファイルを使用したい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使用する必要があります。これを使用しない場合、フックの配列を編集して {{AUR|gnupg1}} を使用する必要があります。
  +
* OpenSSL のアップデートにより、上記の2番目のフォーラムの投稿で言及されているカスタムの {{ic|ssldec}} が壊れる可能性があります。
   
 
==root などのパーティションのリモート解除==
 
==root などのパーティションのリモート解除==
133行目: 148行目:
 
===リモートのロック解除 (フック: systemd, systemd-tool)===
 
===リモートのロック解除 (フック: systemd, systemd-tool)===
   
AUR パッケージの {{AUR|mkinitcpio-systemd-tool}} には ''systemd-tool'' という名前の {{Pkg|systemd}} 中心の mkinitcpio フックが含まれており、initramfs の systemd で以下の機能を使うことができるようになります:
+
AUR パッケージの {{Pkg|mkinitcpio-systemd-tool}} には ''systemd-tool'' という名前の {{Pkg|systemd}} 中心の mkinitcpio フックが含まれており、initramfs の systemd で以下の機能を使うことができるようになります:
   
 
{| class="wikitable"
 
{| class="wikitable"
150行目: 165行目:
 
* cryptsetup + カスタムパスワードエージェント
 
* cryptsetup + カスタムパスワードエージェント
 
|}
 
|}
{{AUR|mkinitcpio-systemd-tool}} パッケージは [[Mkinitcpio#通常のフック|systemd フック]]を必要とします。詳しい情報はプロジェクトの [https://github.com/random-archer/mkinitcpio-systemd-tool/blob/master/README.md README] やデフォルトの [https://github.com/random-archer/mkinitcpio-systemd-tool systemd サービスユニットファイル] を見てください。
+
{{Pkg|mkinitcpio-systemd-tool}} パッケージは [[Mkinitcpio#通常のフック|systemd フック]]を必要とします。詳しい情報はプロジェクトの [https://github.com/random-archer/mkinitcpio-systemd-tool/blob/master/README.md README] やデフォルトの [https://github.com/random-archer/mkinitcpio-systemd-tool systemd サービスユニットファイル] を見てください。
   
 
推奨されるフックは次の通りです: {{ic|base autodetect modconf block filesystems keyboard fsck systemd systemd-tool}}。
 
推奨されるフックは次の通りです: {{ic|base autodetect modconf block filesystems keyboard fsck systemd systemd-tool}}。
156行目: 171行目:
 
===リモートのロック解除 (フック: netconf, dropbear, tinyssh, ppp)===
 
===リモートのロック解除 (フック: netconf, dropbear, tinyssh, ppp)===
   
initcpio のリモートログインを実現するパッケージの別の組み合わせとして {{AUR|mkinitcpio-netconf}} あるいは {{AUR|mkinitcpio-ppp}} (インターネット経由で [[Wikipedia:Point-to-Point Protocol|PPP]] 接続を使ってリモートでロックを解除) と [[SSH]] サーバーを使用する方法があります。SSH サーバーは {{AUR|mkinitcpio-dropbear}} または {{AUR|mkinitcpio-tinyssh}} のどちらを使用するか選択できます。これらのフックはシェルをインストールしないため、{{AUR|mkinitcpio-utils}} パッケージも[[インストール]]する必要があります。以下の手順は上記のパッケージと組み合わせて使うことができます。パスが異なる場合、注意してください。
+
initcpio のリモートログインを実現するパッケージの別の組み合わせとして {{Pkg|mkinitcpio-netconf}} あるいは {{AUR|mkinitcpio-ppp}} (インターネット経由で [[Wikipedia:Point-to-Point Protocol|PPP]] 接続を使ってリモートでロックを解除) と [[SSH]] サーバーを使用する方法があります。SSH サーバーは {{Pkg|mkinitcpio-dropbear}} または {{Pkg|mkinitcpio-tinyssh}} のどちらを使用するか選択できます。これらのフックはシェルをインストールしないため、{{Pkg|mkinitcpio-utils}} パッケージも[[インストール]]する必要があります。以下の手順は上記のパッケージと組み合わせて使うことができます。パスが異なる場合、注意してください。
   
# SSH のキーペアが存在しない場合、クライアント環境で[[SSH 鍵#SSH 鍵のペアを生成|ペアを生成]]してください (リモート環境のロックを解除するのに使用します)。{{AUR|mkinitcpio-tinyssh}} を使用する場合、[[SSH_鍵#暗号化のタイプを選択|Ed25519 鍵]]を使用することができます。
+
# SSH のキーペアが存在しない場合、クライアント環境で[[SSH 鍵#SSH 鍵のペアを生成|ペアを生成]]してください (リモート環境のロックを解除するのに使用します)。{{Pkg|mkinitcpio-tinyssh}} を使用する場合、[[SSH_鍵#暗号化のタイプを選択|Ed25519 鍵]]を使用することができます。
 
# SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が ''.pub'' のファイル) をリモートマシンの {{ic|/etc/dropbear/root_key}} または {{ic|/etc/tinyssh/root_key}} ファイルにコピーしてください。 {{Tip|必要であれば他の SSH 公開鍵を後で追加することもできます。リモートの {{ic|~/.ssh/authorized_keys}} の中身をコピーする場合、リモートマシンのロックを解除するのに使用する鍵だけが含まれていることを確認してください。鍵を追加したら、{{ic|mkinitcpio}} で initrd も再生成する必要があります。[[Secure Shell#SSH の保護]]も参照してください。}}
 
# SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が ''.pub'' のファイル) をリモートマシンの {{ic|/etc/dropbear/root_key}} または {{ic|/etc/tinyssh/root_key}} ファイルにコピーしてください。 {{Tip|必要であれば他の SSH 公開鍵を後で追加することもできます。リモートの {{ic|~/.ssh/authorized_keys}} の中身をコピーする場合、リモートマシンのロックを解除するのに使用する鍵だけが含まれていることを確認してください。鍵を追加したら、{{ic|mkinitcpio}} で initrd も再生成する必要があります。[[Secure Shell#SSH の保護]]も参照してください。}}
 
# {{ic|/etc/mkinitcpio.conf}} の "HOOKS" 行の {{ic|filesystems}} の前に {{ic|<netconf and/or ppp> <dropbear or tinyssh> encryptssh}} [[Mkinitcpio#HOOKS|フック]]を追加してください ({{ic|encryptssh}} で {{ic|encrypt}} フックを置き換えます)。それから [[Mkinitcpio#イメージ作成とアクティベーション|initramfs イメージを再生成]]してください。 {{Note|{{Pkg|mkinitcpio-nfs-utils}} に含まれている {{ic|net}} フックは必要ありません。}}
 
# {{ic|/etc/mkinitcpio.conf}} の "HOOKS" 行の {{ic|filesystems}} の前に {{ic|<netconf and/or ppp> <dropbear or tinyssh> encryptssh}} [[Mkinitcpio#HOOKS|フック]]を追加してください ({{ic|encryptssh}} で {{ic|encrypt}} フックを置き換えます)。それから [[Mkinitcpio#イメージ作成とアクティベーション|initramfs イメージを再生成]]してください。 {{Note|{{Pkg|mkinitcpio-nfs-utils}} に含まれている {{ic|net}} フックは必要ありません。}}
# ブートローダーの設定に {{ic|1=cryptdevice=}} [[dm-crypt/システム設定#ブートローダー|パラメータ]]を設定して適切な引数を付けた {{ic|1=ip=}} [[カーネルパラメータ|カーネルコマンドパラメータ]]を追加してください。例えば、DHCP サーバーからリモート環境に固定 IP が割り当てられない場合、再起動してから SSH でアクセスするのが難しいため、以下のように使用したい IP を明示的に指定できます:{{bc|<nowiki>ip=192.168.1.1:::::eth0:none</nowiki>}}{{Note|{{AUR|mkinitcpio-netconf}} のバージョン 0.0.4 現在、複数の {{ic|ip<nowiki>=</nowiki>}} パラメータをネストすることで複数のインターフェイスを設定できます。{{ic|ip<nowiki>=</nowiki>dhcp}} ({{ic|ip<nowiki>=</nowiki>:::::eth0:dhcp}}) と混ぜることはできません。インターフェイスを指定する必要があります。}}{{bc|<nowiki>ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none</nowiki>}}詳しい説明は [[Mkinitcpio#net を使う|mkinitcpio のセクション]]を読んでください。設定が完了したら、[[ブートローダー]]の設定を更新してください。
+
# ブートローダーの設定に {{ic|1=cryptdevice=}} [[dm-crypt/システム設定#ブートローダー|パラメータ]]を設定して適切な引数を付けた {{ic|1=ip=}} [[カーネルパラメータ|カーネルコマンドパラメータ]]を追加してください。例えば、DHCP サーバーからリモート環境に固定 IP が割り当てられない場合、再起動してから SSH でアクセスするのが難しいため、以下のように使用したい IP を明示的に指定できます:{{bc|<nowiki>ip=192.168.1.1:::::eth0:none</nowiki>}}{{Note|{{Pkg|mkinitcpio-netconf}} のバージョン 0.0.4 現在、複数の {{ic|ip<nowiki>=</nowiki>}} パラメータをネストすることで複数のインターフェイスを設定できます。{{ic|ip<nowiki>=</nowiki>dhcp}} ({{ic|ip<nowiki>=</nowiki>:::::eth0:dhcp}}) と混ぜることはできません。インターフェイスを指定する必要があります。}}{{bc|<nowiki>ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none</nowiki>}}詳しい説明は [[Mkinitcpio#net を使う|mkinitcpio のセクション]]を読んでください。設定が完了したら、[[ブートローダー]]の設定を更新してください。
# Finally, restart the remote system and try to [[Secure_Shell#サーバーに接続する|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 {{AUR|mkinitcpio-dropbear}} package and you also have the {{Pkg|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 {{AUR|mkinitcpio-tinyssh}}, you have the option of installing {{AUR|tinyssh-convert}} or {{AUR|tinyssh-convert-git}} so you can use the same keys as your {{Pkg|openssh}} installation (currently only Ed25519 keys). In either case, you should have run [[Secure_Shell#sshd デーモンの管理|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 [[Secure_Shell#サーバーに接続する|as you normally would]] (with the remote user of your choice).
+
# Finally, restart the remote system and try to [[Secure_Shell#サーバーに接続する|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 {{Pkg|mkinitcpio-dropbear}} package and you also have the {{Pkg|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 {{Pkg|mkinitcpio-tinyssh}}, you have the option of installing {{Pkg|tinyssh-convert}} or {{AUR|tinyssh-convert-git}} so you can use the same keys as your {{Pkg|openssh}} installation (currently only Ed25519 keys). In either case, you should have run [[Secure_Shell#sshd デーモンの管理|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 [[Secure_Shell#サーバーに接続する|as you normally would]] (with the remote user of your choice).
   
 
{{Tip|1=If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}}) remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].}}
 
{{Tip|1=If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}}) remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].}}
181行目: 196行目:
 
# [[Mkinitcpio#イメージ作成とアクティベーション|initramfs イメージを再生成]]。
 
# [[Mkinitcpio#イメージ作成とアクティベーション|initramfs イメージを再生成]]。
 
# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成|GRUB]] の場合:{{bc|# grub-mkconfig -o /boot/grub/grub.cfg}}
 
# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成|GRUB]] の場合:{{bc|# 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.
+
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.
  +
  +
== 一度きりのパスワード無しの再起動 ==
  +
  +
ターミナルに暗号化済みルートドライブのパスワードを入力する必要なしにリモートのヘッドレスあるいはアクセス不能なシステムを再起動するためのもう一つの方法は、一時的な[[dm-crypt/システム設定#キーファイルでロックを解除する|キーファイル]]を使用することです。キーファイルはブート時にカーネルからアクセス可能な場所に配置する必要があり、[[dm-crypt/システム設定#cryptkey|cryptkey]] のブートパラメータを追加する必要があり、そして、そのキーファイルを "cryptsetup luksAddKey" コマンドを使って有効なキーとして登録する必要があります。
  +
  +
この作業は {{AUR|passless-boot}} を使えば簡単に行うことができます。[https://gitlab.com/Marcool04/passless-boot このツールの readme ファイル]で説明されているこのツールのセットアップ手順は、自身でセットアップする際のテンプレートとしても使えるかもしれません。[https://gitlab.com/Marcool04/passless-boot#security-considerations-and-threat-model Security considerations] の章での議論を参照してください。
   
 
==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==
 
==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==
 
[[ソリッドステートドライブ]]を使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは {{ic|discard}} オプションが無効な状態でマウントされます。
 
[[ソリッドステートドライブ]]を使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは {{ic|discard}} オプションが無効な状態でマウントされます。
   
セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html]。TRIM を有効にすると放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は ''cryptsetup'' の開発者による [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html ブログ記事] で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である {{ic|--cipher aes-cbc-essiv}} で暗号化されている場合、最新の[[Dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプション|デフォルト設定]]を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。
+
セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html]。TRIM を有効にすると放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は ''cryptsetup'' の開発者による [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html ブログ記事] で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である {{ic|--cipher aes-cbc-essiv}} で暗号化されている場合、最新の[[Dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプション|デフォルト設定]]を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。
   
 
以下のケースに分かれます:
 
以下のケースに分かれます:
288行目: 309行目:
 
# cryptsetup open --header header.img --type luks /dev/sdX enc
 
# cryptsetup open --header header.img --type luks /dev/sdX enc
   
後は [[Dm-crypt/システム全体の暗号化#boot 以外のパーティションの準備|LVM on LUKS セットアップ]]に従ってください。同じようにリムーバルデバイスに [[Dm-crypt/システム全体の暗号化#boot パーティションの準備 4|boot パーティションを準備]]します (同じでなければ、暗号化ディスクを解錠するためのヘッダーファイルを別にする意味がありません)。そして {{ic|header.img}} を移動します:
+
後は [[Dm-crypt/システム全体の暗号化#boot 以外のパーティションの準備|LVM on LUKS セットアップ]]に従ってください。同じようにリムーバルデバイスに [[Dm-crypt/システム全体の暗号化#boot パーティションの準備 4|boot パーティションを準備]]します (同じでなければ、暗号化ディスクを解錠するためのヘッダーファイルを別にする意味がありません)。そして {{ic|header.img}} を移動します:
 
# mv header.img /mnt/boot
 
# mv header.img /mnt/boot
   

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

暗号化されていない 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つです:

システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。これらを改竄から保護する方法として、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 システムの場合。

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

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)。また、chkbootAUR パッケージでインストールすることもできます。

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

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

インストール

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

技術的な概要

mkinitcpio-chkcryptobootAUR には 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):

注意点:

  • 上記の手順に従う際に必要なのは 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 を使用する必要があります。これを使用しない場合、フックの配列を編集して gnupg1AUR を使用する必要があります。
  • OpenSSL のアップデートにより、上記の2番目のフォーラムの投稿で言及されているカスタムの ssldec が壊れる可能性があります。

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

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

ノート:

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

  1. SSH のキーペアが存在しない場合、クライアント環境でペアを生成してください (リモート環境のロックを解除するのに使用します)。mkinitcpio-tinyssh を使用する場合、Ed25519 鍵を使用することができます。
  2. SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が .pub のファイル) をリモートマシンの /etc/dropbear/root_key または /etc/tinyssh/root_key ファイルにコピーしてください。
    ヒント: 必要であれば他の SSH 公開鍵を後で追加することもできます。リモートの ~/.ssh/authorized_keys の中身をコピーする場合、リモートマシンのロックを解除するのに使用する鍵だけが含まれていることを確認してください。鍵を追加したら、mkinitcpio で initrd も再生成する必要があります。Secure Shell#SSH の保護も参照してください。
  3. /etc/mkinitcpio.conf の "HOOKS" 行の filesystems の前に <netconf and/or ppp> <dropbear or tinyssh> encryptssh フックを追加してください (encryptsshencrypt フックを置き換えます)。それから initramfs イメージを再生成してください。
    ノート: mkinitcpio-nfs-utils に含まれている net フックは必要ありません。
  4. ブートローダーの設定に 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 のセクションを読んでください。設定が完了したら、ブートローダーの設定を更新してください。
  5. 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-gitAUR 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.

  1. 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 ..."
  2. 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
    }
  3. 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
    }
  4. ip=:::::wlan0:dhcpカーネルパラメータに追加。衝突しないように ip=:::::eth0:dhcp は削除してください。
  5. Optionally create an additional boot entry with kernel parameter ip=:::::eth0:dhcp.
  6. initramfs イメージを再生成
  7. ブートローダーの設定を更新。例えば 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-bootAUR を使えば簡単に行うことができます。このツールの 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.confencrypt2 フックを追加してからリビルドしてください。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/