セキュアブート
セキュアブートとは、電源投入からOS起動までの各ステージで実行コードの正当性を暗号学的に検証し、改ざん物の起動を防ぐ仕組みである。ブートROMなど改変不能な最初の信頼の根（Root of Trust）が保持する公開鍵で次段のブートローダ署名を検証し、以降は連鎖的に検証（Chain of Trust）を進める。これによりマルウェアの侵入やサプライチェーン改ざん、ロールバック攻撃を抑止し、産業機器や車載ECU、サーバ、PCまで広く適用される。
基本概念
セキュアブートの核は「改変不能な少量のコード」と「公開鍵基盤」である。SoCのブートROMやOTP/EFUSEに格納したハッシュ・公開鍵を信頼の根とし、次段のイメージに付与された署名をRSA/ECCで検証する。署名対象は通常イメージ全体のSHA-256等ハッシュで、検証成功時のみ実行を許可する。認証（正当性）と暗号化（秘匿）は別概念であり、前者が必須、後者は要件に応じて併用する。
UEFIにおける構成
PC/サーバではUEFIが標準で、固有の鍵階層を持つ。プラットフォーム鍵（PK）が最上位で、管理鍵（KEK）、許可リスト（db）、失効リスト（dbx）を制御する。OSローダやドライバはdbに登録された証明書で署名され、dbxに載った失効バイナリは起動不可となる。企業環境では独自PKへの切替やdb/dbxの内製管理で供給網リスクを最小化できる。
- PK：プラットフォーム信頼を束ねるルート証明
- KEK：db/dbx更新の権限制御
- db：許可証明（署名済みバイナリ群）
- dbx：失効バイナリ/証明のブラックリスト
組込み機器での実装パターン
組込みでは、BootROM→第1段ブートローダ→第2段/OS→アプリの段階検証を行う。鍵はSoCのOTP、TrustZone/TEE、外付けSecure Element（例: ATECC）に格納し、デバッグIFは量産時にロックする。ロールバック対策として単調増加カウンタやバージョンフェンスを署名内に含め、古い署名付きFWの復元を拒否する。
- 鍵格納：OTP/EFUSE、TEE、Secure Element
- 耐タンパ：デバッグ無効化、電圧/クロックグリッチ検出
- ロールバック防止：マージン付きカウンタ、フェンス付き更新
鍵管理と更新運用
セキュアブートは設計時より運用設計が重要である。製造時プロビジョニングでデバイスIDと公開鍵ハッシュを焼き込み、署名用秘密鍵はHSMで厳重管理する。運用では中間鍵のローテーション計画、鍵流出時の失効手順、A/Bパーティションや安全なロールフォワード更新、OTAでの段階展開（カナリア）を組み合わせ、可用性と安全性を両立する。
Measured Bootとの違い
Verified Boot（狭義のセキュアブート）は不正なら起動を拒否する。一方Measured Bootは各段のハッシュをTPMのPCRへ拡張記録し、起動後にリモート証明（アテステーション）で状態を示す。産業システムでは両者を併用し、運用監査やゼロトラスト構成と結合すると効果が高い。
代表的な脅威と対策
想定脅威は（1）鍵漏えい（ビルド環境侵害、サプライヤ流出）、（2）ロールバック、（3）故障注入（グリッチ、レーザ）、（4）DMA/周辺機器経由注入、（5）ブート後の権限昇格である。対策はHSM運用、dbxの迅速更新、フェイルセーフ設計、デバッグロック、コード測定の併用、サイドチャネル抑止（時間ランダム化等）など多層で行う。
- 署名強度：ECC P-256/RSA-3072以上、SHA-256/384
- 更新保護：バージョンカウンタ、時刻署名、有効期限
- 実装耐性：定数時間実装、電圧/温度センサー連携
検証・評価とツール
実装後は静的/動的解析と署名検証テストを自動化する。UEFIでは「sbverify」「pesign」等で署名検証、Linux系では「fwupd」でdb/dbx反映後の起動確認を行う。組込みではブート計測ログ、ホワイトボックス署名テスト、電源グリッチ耐性試験を取り入れ、量産前に鍵ロールと失効のリハーサルを行うのが実務である。ガイドラインとしてNIST SP 800-193等が参考になる。
よくある誤解と設計上の注意
セキュアブートは暗号化と同義ではない。ストレージ暗号は機密性、署名検証は完全性を担保する別レイヤであり、両輪設計が望ましい。また「既定鍵のまま」はリスクが高く、量産機では独自鍵への切替と失効運用を前提にするべきである。デュアルブートやカスタムドライバを許容する場合はdb/dbx方針とQAフローを明文化し、可用性を損なわない運用境界を定義することが重要である。
コメント（β版）