セキュアブートと信頼の連鎖（UEFI・署名検証）

なぜ「起動の最初」を守る必要があるのか

OS が起動する前のコードを乗っ取る攻撃を**ブートキット（bootkit）**と呼びます。ブートローダやカーネルが読み込まれる前に常駐すれば、後から立ち上がる OS のセキュリティ機構（アンチウイルス、コード署名検証、ディスク暗号化）をすべて下から無力化できます。「最初に動くものが最も強い」のがブートの世界の鉄則です。

そこで UEFI Secure Boot は、電源投入直後から OS カーネルまで、各段が次段の正当性を署名で確かめてから制御を渡すという「信頼の連鎖（chain of trust）」を構築します。連鎖の起点（信頼の根、root of trust）はファームウェア内の改ざん困難な領域に焼かれた検証ロジックと鍵で、ここから一段ずつ信頼を伝播させます。

PK / KEK / db / dbx：四つの鍵データベースの役割

Secure Boot の中核は、ファームウェアの不揮発メモリ（NVRAM）に保持される四つの署名データベースです。これらは単なる鍵の置き場ではなく、「誰が誰の更新を承認できるか」という階層的な権限構造をなします。

検証時の優先順位が重要です。あるブートイメージに対し、ファームウェアはまず dbx を先に確認します。dbx に一致（証明書・署名・イメージのハッシュのいずれか）があれば、たとえ db で許可されていても即座に拒否します。dbx は db に優先する拒否リストであり、これが「いったん許可した鍵やイメージを後から失効させる」唯一の手段です。脆弱性が見つかったブートローダのハッシュを dbx へ追加することで、世界中の端末でその版の起動を止められます。

各ブート段階での署名検証フロー

電源投入から OS までの連鎖を順に追います。各段は「次に実行するコードの署名を db で検証し、合格したものにのみ制御を渡す」を繰り返します。

[1] SEC/PEI（ファームウェア初期段）   ... 信頼の根。ハードウェアで保護
        |  （内部完全性は Boot Guard 等が担保）
[2] DXE / BDS（ブートデバイス選択）   ... db/dbx を読み込み検証器を起動
        |  検証: EFI ブートローダの署名を db と照合、dbx を確認
[3] ブートローダ（shim / GRUB / bootmgfw）
        |  検証: 次段（GRUB やカーネル）の署名を確認
[4] OS カーネル
        |  検証: カーネルモジュール・ドライバの署名を確認
[5] ユーザー空間

検証アルゴリズムの実体は、EFI 実行ファイル（PE/COFF 形式）に埋め込まれた Authenticode 署名の確認です。手順は (1) イメージの所定領域を除いてハッシュを計算、(2) 署名に付随する証明書チェーンを db のルートまでたどって検証、(3) 署名されたハッシュと実測ハッシュの一致を確認、です。署名検証の数学的な中身（RSA-PSS や ECDSA の検証式）は デジタル署名スキーム を参照してください。連鎖の各段が「上位の鍵で署名されたものだけを信頼する」点は、X.509 チェーン検証 のパス検証と本質的に同じ構造です。

shim：Microsoft の鍵と Linux の現実の橋渡し

ここで実務上の難所が現れます。ほとんどの PC のファームウェアの db には、Microsoft の鍵だけが初期登録されています（Microsoft UEFI CA）。Linux ディストリビュータが自分の鍵を全端末の db に入れるのは非現実的です。

この溝を埋めるのが shim です。shim は Microsoft によって署名された小さな第一段ローダで、db の検証を通過できます。shim 自身は二つ目の鍵ストア、**MOK（Machine Owner Key）**を持ち、ディストリビュータの鍵やユーザー独自の鍵を MOK に登録できます。

• 起動すると shim が読み込まれ、ファームウェアは shim を **db（Microsoft 鍵）**で検証して実行する。
• shim は次段（GRUB やカーネル）を、まず db、次に自前の MOKで検証する。db に無くても MOK にあれば通す。
• MOK の追加は再起動時の MokManager で物理操作（パスワード確認）を要求し、リモートからの勝手な鍵追加を防ぐ。

この設計により、ファームウェアの db を一切変更せずに、Microsoft 署名という単一の入口から各ディストリの信頼を分岐させられます。サプライチェーン攻撃の観点では、shim という単一の信頼点が侵害されると影響が広範になるため、shim 自体の脆弱性（過去に GRUB のパーサ経由で署名検証を回避する欠陥が複数報告された）は dbx 更新で迅速に失効させる対象になります。

Secure Boot と Measured Boot は目的が違う

混同されやすいのが Secure Boot と Measured Boot です。両者は補完関係にあり、片方が他方を代替しません。

Measured Boot は各段が「次に実行するコードのハッシュ」を計算し、TPM の **PCR（Platform Configuration Register）**へ書き込みます。書き込みは上書きではなく **PCR 拡張（extend）**で、PCR_new = Hash(PCR_old || 測定値) という連鎖計算です。一度どこかの段で異なるコードが測定されれば、以降の PCR 値はすべて変わり、後から辻褄を合わせることができません。これは ハッシュの連結構造 と同じ一方向性に支えられています。

最終的な PCR 値は Remote Attestation（遠隔証明） に使えます。端末は TPM が署名した PCR 値（Quote）を検証サーバーへ送り、サーバーは期待値と照合して「正しい構成で起動したか」を判定します。Secure Boot が「その場で起動を止める」のに対し、Measured Boot は「起動は許すが証跡を残し、後で正当性を問える」点が決定的に異なります。なお、ディスク暗号化鍵を特定の PCR 値に**封印（seal）**しておけば、改ざんで PCR がずれた場合に鍵が解放されず、データを保護できます（TPM ベースの BitLocker / LUKS が典型）。

まとめ

UEFI Secure Boot は PK→KEK→db/dbx の鍵階層を信頼の根とし、ブートの各段が次段の Authenticode 署名を db で検証して制御を渡す「信頼の連鎖」です。dbx は db に優先する拒否リストで、脆弱なブートコードを事後に失効させる唯一の手段になります。db に Microsoft 鍵しかない現実を埋めるのが shim と MOK で、単一の署名入口から各ディストリへ信頼を分岐させます。

ブートキットの多くは署名検証を破るのではなく、署名済みコードの脆弱性を突くため、防御は dbx 更新と確実な更新運用の両輪です。Secure Boot が「起動を阻止する強制機構」なのに対し、Measured Boot は TPM の PCR へ測定値を拡張して「起動構成を記録し遠隔証明できる検知機構」であり、目的が異なるため併用されます。信頼の根からの連鎖という発想は PKI や X.509 チェーン検証 と一本でつながります。