はじめに (対象読者・この記事でわかること)

この記事は、Arch Linuxおよびその派生ディストリビューション（Manjaro、EndeavourOSなど）を使用していて、LUKSでディスク暗号化を設定したにもかかわらず、なぜか起動時に自動的に暗号化が解除されてしまうという問題に直面している方を対象としています。

この記事を読むことで、なぜ暗号化されたはずのシステムが自動的に解除されてしまうのか、その背後にあるmkinitcpioとsystemdの複雑な関係性を理解し、実際に問題を解決する方法が身につきます。また、initramfsの生成プロセスと、キーファイルが意図せず組み込まれてしまうメカニズムについても詳しく解説します。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 - Linuxの基本的なコマンド操作とファイルシステムの知識 - LUKS（Linux Unified Key Setup）の基本的な概念 - Arch Linuxのmkinitcpioコマンドの基礎知識

自動解除の謎：なぜ暗号化が意味をなさなくなったのか

Arch系OSでLUKS暗号化を設定したつもりが、起動時にパスフレーズの入力を求められず、システムが勝手に起動してしまう現象は、多くのユーザーが直面する深刻なセキュリティ上の問題です。これは単なる設定ミスではなく、深い仕様理解が必要な複雑な事象です。

この問題の核心には、mkinitcpioがinitramfsを生成する際の振る舞いと、systemdの自動マウト機能の相互作用があります。特に、キーファイルが/etc/以下に存在し、それがmkinitcpioのHOOKS設定に組み込まれてしまうことで、起動時に自動的に暗号化を解除するキーとして認識されてしまうのです。

さらに、最近のArch系ディストリビューションでは、systemdベースのHOOKSがデフォルトになりつつあるため、この問題がより顕在化しています。systemd HOOKを使用している場合、systemd-cryptsetupが自動的にキーファイルを探索し、見つかった場合はユーザーの介入なしに暗号化を解除してしまうのです。

問題の根本原因と段階的な解決方法

問題の診断：なぜ自動解除が起きているのか

まず、現在のinitramfsにキーファイルが含まれているかどうかを確認する必要があります。

Bash

# initramfsの内容を確認
mkdir /tmp/initramfs
cd /tmp/initramfs
# 現在のカーネルのinitramfsを展開
lsinitcpio -x /boot/initramfs-linux.img

# キーファイルの有無を確認
find . -name "*key*" -o -name "*luks*" -o -name "*crypto*"

もし、予期しない場所（特に/etc/以下）にキーファイルが存在する場合、これが自動解除の原因となっています。

次に、mkinitcpioの設定ファイルを確認します：

Bash

# /etc/mkinitcpio.confの内容を確認
cat /etc/mkinitcpio.conf | grep -E "^(HOOKS|FILES)"

FILES行にキーファイルが指定されていないか、またHOOKSにsystemdが含まれている場合、自動解除のリスクが高まります。

解決策の実装：安全な暗号化システムの構築

ステップ1: 既存のキーファイルの特定と削除

まず、システム内のキーファイルを特定し、安全に削除または移動します。

Bash

# システム全体のキーファイルを検索
sudo find / -name "*key*" -type f 2>/dev/null | grep -v proc | grep -v sys

# LUKS用のキーファイルを特定
sudo cryptsetup luksDump /dev/sda2 | grep -A5 "Keyslot"

もし不要なキーファイルが見つかった場合、/etc/crypttabや/etc/fstabからも関連する行を削除します：

Bash

# /etc/crypttabを編集
sudo nano /etc/crypttab
# 以下のような行があれば削除またはコメントアウト
# luks-partition UUID=xxxx-xxxx none

ステップ2: mkinitcpio設定の修正

次に、/etc/mkinitcpio.confを適切に設定します。

Bash

# バックアップを作成
sudo cp /etc/mkinitcpio.conf /etc/mkinitcpio.conf.backup

# エディタで開く
sudo nano /etc/mkinitcpio.conf

# HOOKS行を修正（systemdを使用する場合）
HOOKS=(base systemd autodetect modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

# または、systemdを使用しない場合（より制御しやすい）
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

重要なポイントは、encrypt HOOKを使用し、systemd HOOKの使用を避けることで、より直接的な制御が可能になります。

ステップ3: 新しいinitramfsの生成とテスト

設定を保存したら、新しいinitramfsを生成します：

Bash

# 新しいinitramfsを生成
sudo mkinitcpio -P

# GRUB設定の更新（GRUBを使用している場合）
sudo grub-mkconfig -o /boot/grub/grub.cfg

ステップ4: カーネルパラメータの確認

/etc/default/grubファイルで、カーネルパラメータが正しく設定されていることを確認します：

Bash

# GRUB設定ファイルを編集
sudo nano /etc/default/grub

# GRUB_CMDLINE_LINUX_DEFAULTに以下を追加
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=あなたのUUID:cryptroot root=/dev/mapper/cryptroot"

UUIDは以下のコマンドで確認できます：

Bash

# LUKSパーティションのUUIDを確認
sudo blkid | grep crypto_LUKS

ハマった点とトラブルシューティング

問題1: 起動時に「No key available with this passphrase」エラー

このエラーは、キーボードレイアウトの問題が原因のことが多いです。特に、日本語キーボードを使用している場合、initramfs段階でのキーボードレイアウトがUS配列になっている可能性があります。

解決策：

Bash

# keymap HOOKを追加
# /etc/mkinitcpio.confのHOOKS行を修正
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

# 日本語キーボード用のキーマップを設定
echo "KEYMAP=jp106" | sudo tee /etc/vconsole.conf

問題2: システムが起動しない（復号に失敗）

mkinitcpioの設定を変更後、システムが起動しなくなることがあります。この場合、Live USBから起動して修復作業を行います。

復旧手順：

Bash

# Live USBから起動
# 暗号化パーティションを開く
sudo cryptsetup open /dev/sda2 cryptroot

# マウント
sudo mount /dev/mapper/cryptroot /mnt
sudo mount /dev/sda1 /mnt/boot

# chroot環境に入る
sudo arch-chroot /mnt

# mkinitcpio.confを修正
nano /etc/mkinitcpio.conf

# initramfsを再生成
mkinitcpio -P

問題3: systemd-boot使用時の特殊な対応

systemd-bootを使用している場合、追加の設定が必要です。

Bash

# /boot/loader/entries/arch.confを編集
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=あなたのUUID:cryptroot root=/dev/mapper/cryptroot rw

セキュリティ強化：より安全な暗号化設定

自動解除を防ぐだけでなく、より高いセキュリティを実現するために、以下の追加設定を推奨します：

Bash

# LUKSパスワードの強化
sudo cryptsetup luksChangeKey /dev/sda2

# キックスロットの追加（オプション）
sudo cryptsetup luksAddKey /dev/sda2

# 古いキーの削除
sudo cryptsetup luksKillSlot /dev/sda2 0

また、TPM（Trusted Platform Module）を使用した自動解除と通常のパスワード入力の併用も検討できます：

Bash

# TPM2の有効化（ハードウェアが対応している場合）
sudo pacman -S tpm2-tools
sudo systemctl enable tpm2-abrmd

まとめ

本記事では、Arch系OSでLUKS暗号化を設定したにもかかわらず、なぜか自動的に暗号化が解除されてしまうという厄介な問題の原因と解決方法を詳しく解説しました。

  • 問題の根本原因：mkinitcpioがキーファイルをinitramfsに組み込んでしまい、systemdが自動的に暗号化を解除してしまう
  • 診断方法：initramfsの内容確認と、mkinitcpio.confの設定確認
  • 解決策：適切なHOOKSの設定、不要なキーファイルの削除、正しいカーネルパラメータの設定
  • トラブルシューティング：起動失敗時の復旧手順と、各種エラーの対処法

この記事を通して、読者はArch系OSでの安全なディスク暗号化の実装方法を習得し、意図しない自動解除を防ぐことができるようになりました。今後は、TPM2.0を使用したより高度な暗号化管理や、複数の認証方法を組み合わせたハイブリッドなアプローチについても記事にする予定です。

参考資料