セキュアブート(Secure Boot)と信頼の連鎖(Chain of Trust)
1. 概要
A. 定義
セキュアブート(Secure Boot) とは、ハードウェアに固定された信頼の根(Root of Trust, RoT) から出発し、電源投入直後からファームウェア → ブートローダ → オペレーティングシステムのカーネル → アプリケーションに至る各段階が、次の段階のコードを実行する前にその完全性を暗号学的に検証(または測定)し、信頼を引き渡すブートセキュリティ体系である。このように段階ごとに信頼が途切れず継承される構造を信頼の連鎖(Chain of Trust) と呼び、UEFI Secure Boot・Measured Boot・リモート構成証明(Attestation)がこれを実装する代表的な技術である。
セキュアブートの根本的な発想は、「何がセキュリティソフトウェア自身の完全性を保証するのか」という循環問題を断ち切る点にある。ウイルス対策・EDR・ファイアウォールといったセキュリティソリューションは結局オペレーティングシステム上で実行されるコードであるため、カーネルや、それより先に起動するブートローダ・ファームウェアが改ざんされれば、セキュリティソフトウェアが読み込まれる前にすでに掌握されてしまう。すなわち「最初に実行されるコード」が信頼されなければ、その上のすべてのセキュリティは砂上の楼閣となる。セキュアブートは、改ざんが困難なハードウェアに信頼の出発点を打ち込み、そこから上位層へ信頼を一段ずつ「証明しながら」引き渡すことで、この空白を埋める。
ここで核心となるのは、信頼が推移的(transitive)に継承されるという点である。RoT 自身は外部が検証してくれるものではなく、ハードウェア的に「信じると前提する」公理(axiom)であり、その後のすべての段階は直前の段階が検証してくれるがゆえに信頼される。したがって、連鎖のいずれか一つの環でも検証なしに飛ばされたり、根が損なわれたりすれば、その下位全体の信頼が崩壊する。セキュアブート設計が「最も弱い環」の問題に帰着するのはこのためである。
B. 登場の背景と必要性
従来のセキュリティは、OS が起動した「後」を守ることに集中してきた。しかし、攻撃者が OS より先に居座るブートキット(Bootkit)・ルートキット(Rootkit)・ファームウェアインプラントが登場したことで、OS レベルのセキュリティでは事実上検知も除去も不可能な脅威が現実化した。ブート初期段階を掌握したマルウェアは、カーネル署名検証を回避し、BitLocker・HVCI・Defender といった防御をブート過程であらかじめ無力化し、OS を再インストールしてもディスク外(ファームウェア・ESP)に残って再感染を引き起こす。
こうした脅威の深刻さは実際の事例で明らかになった。2023 年に公開された BlackLotus は、完全にパッチが適用された Windows 11 でも UEFI Secure Boot を回避した初の商用ブートキットであり、旧来の脆弱なブートローダを差し戻して仕込む CVE-2022-21894(Baton Drop) と後続の CVE-2023-24932 を悪用した。米国 NSA が別途の緩和ガイドを発行し、Microsoft が脆弱なブートローダを失効リスト(dbx)に登録する対応を段階的に展開しなければならなかったほど波及は大きかった。これは「セキュアブートがある」という事実だけでは不十分であり、脆弱化した信頼要素を失効(Revocation) させ、鮮度を保つ運用まで併せて行わなければならないことを示している。
さらにセキュアブートは、サプライチェーン・デバイス信頼の土台であるという点で必要性が高まっている。ゼロトラスト(Zero Trust)で「このデバイスを信じてよいか」を判断するには、その機器が改ざんされていない状態でブートされたというハードウェア的根拠がなければならない。データセンターのサーバファームウェア改ざん、IoT・OT 機器のファームウェア交換、中古・持ち込み機器のインプラントといったサプライチェーンリスクが高まるにつれ、セキュアブートとその測定値に基づくリモート構成証明は、選択ではなく基本要件として定着しつつある。
2. 信頼の連鎖の全体構造と中核概念
セキュアブートは「ハードウェアの根 → 上位層」へ信頼が一方向に継承される階層構造として理解すべきである。以下の全体構造図は、電源投入直後に不変の RoT から信頼が始まり、各段階が次の段階を検証(Verify)または測定(Measure)しながら制御を引き渡し、測定値が TPM に累積されて最終的にリモート構成証明に活用される流れを示している。
flowchart TD
RoT["信頼の根(RoT) - 不変 Boot ROM·ヒューズ"]
FW["プラットフォームファームウェア(UEFI/BIOS)"]
BL["ブートローダ(shim·GRUB など)"]
OS["OS カーネル·ドライバ"]
APP["アプリケーション·サービス"]
TPM[("TPM - PCR 累積")]
VER["リモート検証サーバ(Attestation)"]
RoT -->|"検証後に制御を引き渡し"| FW
FW -->|"検証後に制御を引き渡し"| BL
BL -->|"検証後に制御を引き渡し"| OS
OS -->|"検証後に制御を引き渡し"| APP
RoT -.->|"測定値 extend"| TPM
FW -.->|"測定値 extend"| TPM
BL -.->|"測定値 extend"| TPM
OS -.->|"測定値 extend"| TPM
TPM -->|"PCR 署名(Quote) を提出"| VER
style RoT fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style TPM fill:#eafbea,stroke:#2f9e44,stroke-width:1px
style VER fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px
A. 信頼の根(Root of Trust)
信頼の連鎖は必ず「変わらない何か」から出発しなければならない。この出発点が RoT であり、通常はチップ製造時にマスク ROM に焼き込まれた不変コード(immutable Boot ROM) と、OEM 公開鍵のハッシュを格納し書き込み不能なワンタイムヒューズ(OTP fuse) で実装される。ソフトウェアで交換・修正できないため攻撃者が最も手を出しにくい地点であり、まさにこの性質が「信頼の公理」となる資格を与える。
RoT は機能により三種類に分かれる。測定の根(RTM, Root of Trust for Measurement) はブート要素のハッシュを最初に計算して信頼の連鎖の測定を開始し、保存の根(RTS) は鍵と測定値を安全に保管し、報告の根(RTR) は測定結果を外部に信頼性をもって証明する。TPM が RTS・RTR を、CPU 内部の最初の測定コード(CRTM)が RTM を担う形で役割が分担される。このように根を機能別に明確に定義してこそ「何を信じ、何を証明するのか」が明確になる。
重要な設計原則は、根は小さく単純でなければならないという点である。RoT コードが大きく複雑であれば、その中の欠陥がそのまま全体の信頼の崩壊につながるため、検証可能な最小限のコード(数 KB 程度)のみを置き、残りの機能は上位層へ委ねる。この「最小信頼基盤(Minimal TCB)」原則は、セキュアブートのみならずすべての信頼コンピューティング設計に共通する教訓である。
B. 信頼の継承(Chain of Trust)の原理
信頼の連鎖の各環は同一のパターンを繰り返す。(1) 現在の段階が次に実行するコードをメモリに読み込む → (2) そのコードの署名・ハッシュを検証(または測定)する → (3) 検証を通過した場合にのみ制御権を引き渡す。 この「検証後実行(verify-then-execute)」規則が途切れず根まで続くときにはじめて、「ブートされたソフトウェアスタック全体が信頼できる」という保証が成立する。
ここで重要なのは、信頼が下方向にのみ流れるという非対称性である。上位層は下位層を信頼せざるを得ないが、下位層は上位を信じず、むしろ検証する。したがって、連鎖の途中の一要素が脆弱であれば、その下(以後の段階)はすべて汚染されるが、その上(以前の段階)は影響を受けない。BlackLotus が「ブートローダ」段階を狙ったのも、その下のカーネル・OS 全体を一挙に掌握できるからである。
C. 検証型ブートと測定型ブート
セキュアブートには性格の異なる二つのアプローチがあり、実際のシステムは両者を併用する。検証型ブート(Verified/Secure Boot) は署名検証に失敗すればブートを中断する「予防(Prevention)」中心の方式であり、測定型ブート(Measured Boot) は各段階のハッシュを TPM PCR に記録するのみでブートは続行し、その測定値で後から状態を「証明」させる「検知(Detection)」中心の方式である。前者は改ざんされたコードの実行そのものを防ぎ、後者は「どの状態でブートされたか」を事後に証拠として残す。
| 区分 | 検証型ブート(Verified Boot) | 測定型ブート(Measured Boot) |
|---|---|---|
| 目的 | 予防(不正コードの実行遮断) | 検知(ブート状態の証明) |
| 動作 | 署名検証失敗時にブート中断 | ハッシュを TPM PCR に累積、ブート続行 |
| 根拠 | db/dbx·公開鍵署名 | PCR 値 + リモート構成証明 |
| 限界 | 許可された脆弱コードは通過 | 遮断は不可(判断は検証者の役割) |
| 代表 | UEFI Secure Boot | TPM ベース Measured Boot |
二つの方式は相互補完的である。検証型のみでは「署名は有効だが脆弱な」ブートローダ(例: Baton Drop の旧バイナリ)を防げず、測定型のみでは改ざんコードが一度実行された後にはじめて検知される。そのため実務では、検証型で一次遮断し、測定型+リモート構成証明で「許可されたもののうち実際に何が起動したか」まで検証して深層防御(Defense in Depth)を構成する。
3. 動作メカニズム — UEFI Secure Boot·TPM 測定·リモート構成証明
以下の詳細図は、x86 プラットフォームを基準に、UEFI ファームウェアが鍵階層(PK·KEK·db·dbx)でブートローダ署名を検証する流れと、同時に各段階のハッシュが TPM PCR に累積されてリモート構成証明へつながる過程を併せて示している。検証(実線)と測定(破線)が同じブート過程で並行することが核心である。
sequenceDiagram
participant FW as UEFI ファームウェア
participant KEYS as 鍵 DB(PK·KEK·db·dbx)
participant BL as ブートローダ
participant TPM as TPM(PCR)
participant SRV as 検証サーバ
FW->>KEYS: ブートローダ署名を照会
KEYS-->>FW: db(許可)·dbx(失効) の有無を応答
alt 署名有効かつ dbx に無し
FW->>TPM: ブートローダハッシュを extend(PCR)
FW->>BL: 制御引き渡し(実行)
BL->>TPM: カーネル·設定ハッシュを extend(PCR)
else 署名不一致または dbx に登載
FW--xBL: ブート中断(検証型遮断)
end
BL->>SRV: ブート完了、Quote 要求をトリガ
TPM-->>SRV: PCR 値の署名(Quote) を提出
Note over SRV: 基準値(golden) と比較して信頼を判定
A. UEFI Secure Boot の鍵階層
UEFI Secure Boot は四種類の変数で信頼を管理する。最上位の PK(Platform Key) はプラットフォーム所有者(OEM)の権限を象徴し、KEK を管理する。KEK(Key Exchange Key) は db・dbx を更新できる権限鍵である。db(Signature Database) はブートを許可する署名者・ハッシュの「許可リスト」であり、dbx(Forbidden Signature Database) は脆弱・悪性と判明したバイナリを阻む「失効リスト」である。ファームウェアは、ブートローダの署名が db にあり dbx には無いときにのみ実行する。
この階層構造が重要な理由は、失効(dbx)と権限分離にある。特定のブートローダが脆弱化すれば、そのハッシュを dbx に追加して世界的に遮断でき、これは証明書失効と同一の原理である。Linux 陣営は Microsoft UEFI CA が署名した shim ブートローダを置き、ディストリビューションが自己鍵で署名した GRUB・カーネルを Microsoft の信頼の下でブートさせる方式で相互運用性を確保する。しかしこの構造は、PK が安全に管理されるという前提に全面的に依存する。
まさにその前提が崩れた代表事例が 2024 年の PKfail である。Binarly は、American Megatrends(AMI)がテスト用に作成し「DO NOT TRUST」と明示した Platform Key が交換されないまま、Acer・Dell・HP・Lenovo・Supermicro などの約 813 製品(2012 年 5 月~2024 年 6 月出荷のファームウェア)にそのまま出荷された事実を突き止めた(BRLY-2024-005)。流出したテスト PK の秘密鍵を握る攻撃者は、KEK・db・dbx を操作して Secure Boot を無力化できる。これは「信頼の根である鍵管理が崩れれば、上位のすべての検証が意味を失う」という信頼の連鎖の本質をそのまま示した事件である。
B. 測定型ブートと TPM PCR
測定型ブートの心臓は、TPM の PCR(Platform Configuration Register) 累積記録である。各段階は次のコードを実行する前にそのハッシュを計算して PCR に記録するが、このとき上書きではなく PCR_new = Hash(PCR_old ‖ 測定値) の形で extend(累積) する。この演算は不可逆であるため、ブート過程のいずれか一段階でも変われば最終 PCR 値が完全に変わる。すなわち PCR は「偽造不能なブート履歴の指紋」となる。
たとえば PCR0~7 にはファームウェア・オプション ROM・設定・ブートローダの測定値が、その上には OS ローダ・カーネルの測定値が分かれて記録される。このように段階別に PCR を分離すれば、後で「ファームウェアは正常だがブートローダのみ変わった」のように改ざん地点を細分化して判断できる。測定記録は TPM 外のイベントログとともに保持され、検証者が各測定値の意味を再構成できるようにする。
C. リモート構成証明(Remote Attestation)とロールバック防止
測定値を機器内部だけに置けば、「自分自身を信じてほしい」という自己参照にとどまる。そこで TPM は PCR 値群を構成証明鍵(AIK/AK)で署名(Quote) してリモート検証サーバに提出し、サーバはこれを事前に確保した基準値(golden measurement) と比較して、その機器が信頼できる状態でブートされたかを判定する。これがゼロトラストでデバイス信頼をハードウェア的根拠で裏付ける核心であり、機密コンピューティング(Intel TDX・AMD SEV-SNP)の VM 構成証明も同じ原理を用いる。
一方、信頼の連鎖はロールバック(ダウングレード)攻撃にも備えなければならない。署名は有効だがすでに脆弱性が知られている旧バージョンのファームウェア・ブートローダへ差し戻す攻撃を防ぐため、単調増加カウンタ(monotonic counter)やヒューズで最小許可バージョンを強制するアンチロールバック(Anti-rollback) を置く。さらに NIST SP 800-193(Platform Firmware Resiliency)は、ファームウェアセキュリティを保護(Protection)・検知(Detection)・復旧(Recovery) の三軸で規定し、改ざん時に信頼できる復旧版へ自動回復するレジリエンシ(Resiliency) まで要求する。
4. プラットフォーム別実装の比較と事例
信頼の連鎖の原理は共通だが、根をどこに置きどのように検証するかはプラットフォームごとに異なる。サーバ・PC は CPU・チップセットに根を置く Intel Boot Guard・AMD PSB でファームウェア自体をまず検証し、モバイル・組込みは SoC 内部の Boot ROM と ARM TrustZone・TF-A 連鎖を用い、閉鎖的エコシステムである Apple は不変 Boot ROM と Secure Enclave で非常に堅牢な連鎖を構成する。この違いは「どれだけ開放的で交換可能か」と「どれだけ統制され堅牢か」のトレードオフを反映する。
| プラットフォーム | 信頼の根 | 検証連鎖 | 特徴 |
|---|---|---|---|
| x86 PC/サーバ | Intel Boot Guard·AMD PSB(ヒューズ) | ファームウェア→UEFI Secure Boot→ブートローダ | 開放·相互運用(shim)、dbx 失効 |
| ARM モバイル/組込み | SoC Boot ROM | BL1→BL2→BL31→ブートローダ(TF-A) | TrustZone セキュアワールド分離 |
| Apple | 不変 Boot ROM·Secure Enclave | LLB→iBoot→カーネル | 閉鎖·強堅牢、ロールバック強制 |
| Android | ハードウェア RoT | Android Verified Boot(dm-verity) | パーティション完全性·ロールバック防止 |
| Chromebook | 読取専用ファームウェア | RO→RW(A/B)→カーネル | 復旧用二重化·自己復旧 |
具体的な事例として、Google Chromebook の Verified Boot は読取専用ファームウェアを根とし、読み書き用ファームウェアを二組(A/B)置いて、一方が損傷すれば他方や復旧モードで自動回復する — NIST SP 800-193 が述べる「復旧」を製品レベルで実装した例である。Android の AVB(Android Verified Boot) は dm-verity でシステムパーティションのブロック単位の完全性を検証し、vbmeta に最小許可バージョンを格納してダウングレードを阻む。Apple は Boot ROM からカーネルまで署名が一つでも食い違えば復旧モードに落ちる連鎖を構成し、事実上、商用機器の中で最も改ざんが困難な部類に入る。
5. 深化 — 信頼の連鎖の攻撃·回避と最新動向
セキュアブートが普及すると、攻撃者は連鎖の「最も弱い環」を狙う方向へ進化した。第一の流れは、署名は有効だが脆弱な要素を差し戻して仕込む回避である。BlackLotus(2023)が Baton Drop(CVE-2022-21894)の旧ブートローダを再利用してパッチ適用済み Windows 11 の Secure Boot を越えたのが典型で、これは「許可リスト(db)ベースの検証だけでは不十分で、失効(dbx)を鮮度よく保たなければならない」という教訓を残した。しかし dbx 更新はともすれば正常な機器をブート不能にしかねず、Microsoft は慎重な段階的展開(KB5025885 など)で対応せざるを得なかった。
第二の流れは、根·鍵管理そのものの崩壊である。PKfail(2024)は、テスト PK が数百のモデルに放置されれば、いかに上位の検証が精緻でも、根の鍵が共有・流出すれば全体が崩れるという点を露呈した。これは、セキュアブートのリスクが暗号アルゴリズムではなく、鍵ライフサイクル管理(生成·注入·交換·失効) という運用問題にあることを示唆する。
第三の流れは、TPM の無い軽量·IoT 環境への拡張である。TCG の DICE(Device Identifier Composition Engine) は、専用セキュリティチップの無い小型機器向けに、チップ固有秘密(UDS)と各層の測定値を鍵導出関数に入れて層別の複合識別子(CDI)を導出する方式で、ハードウェア信頼と機器固有の識別子を同時に提供する。各層が使用後に自身の秘密を消去して上位へ継承するため、低コストな MCU でも信頼の連鎖とリモート構成証明を実装でき、Android・機密コンピューティングなどで採用が増えている。
第四の流れは、暗号アジリティ(Crypto Agility)とポスト量子移行である。ブート署名に用いる RSA・ECDSA が量子コンピューティングの脅威にさらされるにつれ、ブート検証アルゴリズムを ML-DSA などの耐量子暗号(PQC)へ交換できるよう、ファームウェア・鍵構造を設計する議論が進んでいる。根の鍵と署名体系を交換することは大規模な再署名・失効を伴うため、信頼の連鎖のアルゴリズム交換可能性をあらかじめ設計に反映することがますます重要になっている。
6. 考慮事項および示唆点
第一に、セキュアブートは「機能の有無」ではなく「運用·失効体系」で評価すべきである。 BlackLotus の事例のように、Secure Boot が有効でも脆弱要素を失効(dbx)できなければ回避される。組織はファームウェア・ブートローダ・dbx の最新化を資産管理・パッチ管理に組み込み、失効配布が正常な機器をブリック化しないよう事前検証・段階的ロールアウトの手順を備えなければならない。
第二に、信頼の根である鍵管理を最優先で統制しなければならない。 PKfail が示すように、根の鍵の共有・流出は上位の検証全体を無力化する。OEM・運用者は、機器別の固有 PK 生成、テスト鍵の生産持ち込み遮断、HSM ベースの署名、鍵交換・失効手順をサプライチェーンセキュリティ要件として明文化し、調達段階でこれを検証しなければならない。
第三に、検証型と測定型を併用して深層防御を構成し、リモート構成証明をゼロトラストと連携させなければならない。 検証型で不正コードの実行を防ぎつつ、測定型+リモート構成証明で「許可されたもののうち実際にブートされた状態」まで検証してデバイス信頼の判断に活用する。これは MDM・条件付きアクセス・機密コンピューティング構成証明と統合するとき実効性が高まる。
第四に、レジリエンシ(Resiliency)を設計要素として含めなければならない。 NIST SP 800-193 の保護・検知・復旧の原則に従い、ファームウェア改ざん検知時に信頼できるゴールデンイメージへ自動復旧するメカニズム(二重化·復旧領域)を備えてこそ、可用性とセキュリティを同時に守れる。とりわけ無人・遠隔運用されるサーバ・OT・IoT では復旧の自動化が必須である。
第五に、展望的に軽量 RoT と暗号アジリティへ先制的に投資すべきである。 TPM の無い大規模 IoT・エッジへ信頼コンピューティングを拡張するには、DICE のような軽量 RoT 標準を検討し、長期的に PQC 移行に備えてブート署名アルゴリズムを交換可能な構造で設計しなければならない。セキュアブートは一度限りの構築ではなく、信頼要素を継続的に更新・証明・復旧する信頼サプライチェーン(Trust Supply Chain) 管理の問題であると認識することが、技術士レベルの観点である。
参考資料
- NIST, "SP 800-193: Platform Firmware Resiliency Guidelines", https://csrc.nist.gov/publications/detail/sp/800-193/final
- NSA, "BlackLotus Mitigation Guide" (2023.06), https://media.defense.gov/2023/Jun/22/2003245723/-1/-1/0/CSI_BlackLotus_Mitigation_Guide.PDF
- Binarly, "PKfail: Untrusted Platform Keys Undermine Secure Boot" (2024), https://binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
- Binarly Advisory BRLY-2024-005, https://binarly.io/advisories/brly-2024-005
- Android Open Source Project, "Device Identifier Composition Engine (DICE)", https://source.android.com/docs/security/features/dice
一言まとめ: セキュアブートはハードウェアの信頼の根(RoT)から出発し、ファームウェア・ブートローダ・カーネルまで「検証後実行」で信頼を継承する連鎖であり、UEFI Secure Boot(検証型)・TPM 測定型・リモート構成証明を併用しつつ、dbx 失効・鍵管理・レジリエンシ(NIST SP 800-193)まで運用してこそ BlackLotus・PKfail のような回避を防げる。