zbm-openwrt-clevis

解決する課題

ZFSBootMenuは暗号化されたZFSをうまく起動できますが、鍵は人が入力することを前提としています。リモートサーバーや無人のマシンではそれでは不十分です。オペレーターは、その入力プロンプトが以前に信頼したブート環境のものかどうかを判断できません。本プロジェクトでは、TPMの計測値がオペレーターが前回の再シール時に承認した状態と一致する場合にのみ、鍵が自動的に取り出されます。一致しなければ自動起動は停止し、オペレーターに通知が届き、パスワードで保護されたOpenWrtシステムが手動での判断を待ちます。

主な機能

• clevisによりTPM PCRに結び付けた自動アンロック。検証済みのポリシーclevis.pcr_ids=1,4,5,7,9は、rEFIndが渡すカーネルコマンドラインもカバーします。
• フォールバック先はパスワードなしのシェルではなく、パスワードまたはSSH鍵でログインする完全なOpenWrtシステムです。ベースイメージではrootがロックされています。
• コンソールまたはSSHでの手動アンロックと、新しい計測状態への再シール。Wi-Fi経由や2系統のWANアップリンクでも行えます。
• シールされたJWEの保存先は3種類：ZFSプロパティ、EFI変数、VFATパーティション上のファイル。
• 対象システムのカーネルとinitramfsを更新しても、手動アンロックをやり直す必要はありません。これらは暗号化プールの中にあり、計測対象のランタイムの外にあるためです。
• 自動アンロックに失敗した際のTelegram通知（任意）。イメージにはディスクとネットワークの修復ツールも含まれます。

仕組み

rEFIndは1つのOpenWrt UKIを読み込み、カーネルコマンドラインでポリシーを渡します。起動時にzbm-auto-bootがzbm-startを実行し、load-keyフックがclevisに鍵の復元を求めて、借用したZFSBootMenuランタイムに渡します。ZFSBootMenuは暗号化されたルートから対象のカーネルとinitramfsを読み込み、kexecで起動します。自動と手動のどちらの入口も同じ経路を通り、1つのロックを共有します。プールは読み取り専用でインポートされ、再シールの結果をZFSプロパティに保存するときだけ短時間書き込みが行われます。

UEFI → rEFInd → OpenWrt UKI → zbm-auto-boot → zbm-start
     → load-key hook / clevis → ZFSBootMenu → kexec → Ubuntu (ZFS)

要件

• ネイティブ暗号化されたZFSルート上の対象システムで、鍵の場所がファイル（keylocation=file://…）であること。
• UEFI、ブートマネージャーとしてのrEFInd、TPM 2.0。ポリシーはrEFIndのoptions行に記述します。
• ビルドホスト：リポジトリのOpenWrt ImageBuilderによるビルド手順、ukify、refind、一般的なビルドツール。
• ラボ環境：qemu-system-x86_64、OVMF、swtpm。検証済みの対象は暗号化ZFS上のUbuntuです。