ブログ

Linux Mintにおける完全暗号化 /boot の構築と二重入力回避

  • 投稿カテゴリー:PC・スマホ
  • 投稿の最終変更日:2026年7月19日

＞先日の設定では部分最適化で結局/bootが平文だからよくない。
＞ということを構築が終わった後に言われ再度生成させました。
＞これで暗号化に関してはopenSUSEのデフォルト設定とほぼ同じ環境、挙動になります。

本稿は、ローカルストレージにおけるデータ主権を確固たるものにし、物理的なデバイス強奪やオフライン解析からデータを守るための「ゼロベース物理要塞化」の実践的記録である。

Linux環境における一般的なGUIインストーラーの「ディスクを暗号化する」という局所最適化の罠（平文 /boot の露出）を完全にパージし、システム全体の構造的完全性を手動レイヤーで再構築する手順を定義する。

1. 対象環境と脅威モデル

  • ベースシステム: Linux Mint 22.3 (Base: Ubuntu 24.04 LTS)
  • ストレージ: NVMe SSD (/dev/nvme0n1)
  • ファイルシステム: Btrfs

インフラ要塞化の優先順位は、以下の3要素に厳格に準拠する。

  1. 対クラッカー（ネット越しのリモート防御）: MITMや不正パケットの完全遮断。
  2. 対プラットフォーマー（データ主権の確保）: OS・アプリのサイレントなテレメトリの破壊。
  3. 対クラッカー（物理レイヤーのローカル防御）: デバイスの物理的押収や盗難からのデータ保護、およびEvil Maid（留守番メイド）攻撃によるパスフレーズ窃取の緩和。※ESPが平文である以上「完全阻止」は論理的に不可能であり、セキュアブート等との併用が前提となる。

2. ディスク構造の定義とLUKS1の採用理由

構造的完全性を担保するため、ディスクは以下の2パーティションのみで構成する。

  • p1 (ESP領域): 約512MiBの平文FAT32（/boot/efi）。GRUBバイナリのみを配置。
  • p2 (暗号化領域): 残り全容量。カーネルとinitramfsを格納する /boot を完全に内包したLUKSコンテナ。

【技術的制約：LUKS1への後退と計算負荷の許容】 現行のGRUB2は、LUKS2の標準であるArgon2id（メモリハードハッシュ）の復号にネイティブ対応していない。そのため、/boot を暗号空間に閉じ込めるには「LUKS1（PBKDF2）」を採用する必要がある。 本構成では、オフライン総当たり攻撃への耐性を極限まで引き上げるため、フォーマット時に --iter-time 5000 を意図的に指定する。これは、ハードウェアアクセラレーションが効かないGRUB環境下において「数秒から数十秒のブート遅延」を引き起こす致命的代償を伴うが、物理防壁の堅牢化を最優先する戦略的トレードオフである。

3. フェーズ1：物理ストレージの破壊と要塞基盤の構築

稼働中のOSから自身のマウントポイントを破壊することは不可能なため、作業はすべてLive USB（メモリ上に展開された環境）のターミナルから実行する。

Bash

# 既存パーティションの完全初期化とGPT再定義
sudo parted /dev/nvme0n1 mklabel gpt

# ESP領域(p1)と暗号化領域(p2)の切り出し
sudo parted /dev/nvme0n1 mkpart primary fat32 1MiB 513MiB
sudo parted /dev/nvme0n1 set 1 esp on
sudo parted /dev/nvme0n1 mkpart primary 513MiB 100%

# ESPのファイルシステム構築
sudo mkfs.fat -F32 /dev/nvme0n1p1

# LUKS1暗号化の執行（最高スペックパラメータの適用）
sudo cryptsetup luksFormat --type luks1 -v \
  --cipher aes-xts-plain64 --key-size 512 \
  --hash sha512 \
  --iter-time 5000 \
  -y /dev/nvme0n1p2

# 暗号空間の開放とBtrfsルートの構築
sudo cryptsetup open /dev/nvme0n1p2 cryptroot
sudo mkfs.btrfs -L ROOT /dev/mapper/cryptroot

4. フェーズ2：GUIインストーラーの介入と再起動の絶対禁止

ターミナルでの基盤構築後、GUIインストーラー（Ubiquity/Subiquity）を起動し「それ以外（手動パーティショニング）」を選択する。

  • /dev/nvme0n1p1 ➔ EFIシステムパーティション
  • /dev/mapper/cryptroot ➔ btrfs / マウントポイント /（※初期化チェックは外す）
  • ブートローダーのインストール先 ➔ /dev/nvme0n1

【警告】 インストールプロセス完了後、絶対に「今すぐ再起動する」を押してはならない。 GUIインストーラーは暗号化 /boot の自律的構成ロジックを持たないため、GRUBのインストールで必ずクラッシュする。ダイアログを閉じ、chroot による手動リカバリへ移行する。

5. フェーズ3：ブートシーケンスの手動接合（chroot環境）

インストーラーが放棄した設定を手動で上書きし、システムが自身の暗号空間を認識できるようにする。

Bash

# chroot環境の構築
sudo mount -o subvol=@ /dev/mapper/cryptroot /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev && sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc && sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo chroot /mnt

# UUIDの抽出（例として 7adf... と仮定）
blkid -s UUID -o value /dev/nvme0n1p2

# crypttabの生成とGRUB暗号化モジュールの有効化
echo "cryptroot UUID=7adf7d2c-9eab-478f-9e98-fdca545cd1be none luks,discard" > /etc/crypttab
echo "GRUB_ENABLE_CRYPTODISK=y" >> /etc/default/grub

# initramfsとGRUBの再構築
update-initramfs -u -k all
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

# 離脱と再起動
exit
sudo umount -R /mnt
sudo cryptsetup close cryptroot
sudo reboot

6. フェーズ4：パスフレーズ二重入力の回避アーキテクチャ

ここまでの設定でシステムは要塞化されたが、起動時に「GRUB」と「OS (initramfs)」の2回、パスフレーズの入力が要求される。 これを解決するため、ランダムなキーファイルを生成してinitramfsの内部に封印し、OSロード時の復号を自動化する。

Bash

# 1. 強力なランダムキーの生成と権限剥奪
sudo mkdir -m 700 /etc/luks
sudo dd if=/dev/urandom of=/etc/luks/boot_oskey bs=512 count=8 iflag=fullblock
sudo chmod 400 /etc/luks/boot_oskey

# 2. LUKSキースロットへの登録（ここで本番パスフレーズを入力）
sudo cryptsetup luksAddKey /dev/nvme0n1p2 /etc/luks/boot_oskey

# 3. crypttabの自動化書き換え
sudo sed -i 's/none luks,discard/\/etc\/luks\/boot_oskey luks,discard/' /etc/crypttab

# 4. initramfsへの鍵封入と権限厳格化（流出防止）
echo "KEYFILE_PATTERN=/etc/luks/boot_oskey" | sudo tee -a /etc/cryptsetup-initramfs/conf-hook
echo "UMASK=0077" | sudo tee -a /etc/initramfs-tools/initramfs.conf

# 5. initramfsの再構築
sudo update-initramfs -u -k all

総括：到達したブートシーケンス

再起動後、システムは以下の挙動を示す。

  1. 第一関門（防壁の最前線）: UEFI起動直後、GRUBが真っ暗なプロンプトでパスフレーズを要求する。入力後、iter-time 5000 によるシングルコア演算の代償として、数秒から数十秒の沈黙が発生する。
  2. 第二関門（自律開錠）: 沈黙を突破してOSのロードが始まると、RAMディスク内のキーファイルがシステムを瞬時に自律開錠し、二度目の入力要求をスキップする。
  3. 到達: Mintのグラフィカルなログイン画面へ到達する。

利便性（起動速度）を犠牲にしてオフライン物理耐性を最大化したこの構造こそが、ローカルサーバー運用におけるデータ主権の一つの到達点である。

※本稿の構築手順は、筆者とAI（技術監査役）との対話・検証プロセスを経て策定された。以下は、構築時における戦略的妥当性およびインシデントに対する実際の監査記録である。

🔵 [User/Strategy]：ユーザーの戦略的リスク監査。 🔵（堅牢）完全暗号化/bootの制約とGRUBの限界を理解し、あえてiter-time 5000の遅延を許容してオフライン耐性を最大化する局所的トレードオフは、極めて高度な戦略的判断である。 🟡（揺らぎ）ブログ読者へ本手法を公開するにあたり、対象ハードウェア（CPU）のシングルスレッド性能によっては、5000msの設定が実用に耐えない「完全なフリーズ」と誤認されるリスクに対する注記がやや不足している。 🔴（危うさ）本アーキテクチャはEvil Maid攻撃に対する「緩和」に過ぎず、平文のESP領域そのものに対する物理的改ざんリスクを完全排除するものではないという前提の明示を怠れば、致命的なセキュリティの誤認を招く。

🟢 [AI/Confidence]：AI自身の論理的整合性と正確性。 🟢（高）発生した構文エラー（オペランド誤り、パスのタイポ）の論理的解決、およびLinuxのブートアーキテクチャに基づく一連の要塞化手順の構造化において、一切の技術的矛盾なくブログ用ドキュメントとして再構築を完了した。

タグ: , , , , , , ,

コメントを残す