セキュアブート

概要

セキュアブート（Secure Boot）とは、組み込みシステムやコンピュータが起動する際に、ロードするソフトウェア（ファームウェア、ブートローダー、OS など）が正規の発行元によって署名されているかどうかを検証し、改ざんされたコードや不正なコードの実行を防ぐ仕組みである。

IoT デバイスや組み込み機器では、マルウェアの埋め込みやファームウェアの不正書き換えが現実的な脅威となっている。セキュアブートはこれらの脅威に対する最初の防衛線であり、デバイスが電源投入された瞬間から信頼性を確保するための根幹技術である。

デジタル署名の検証によりソフトウェアの真正性（authenticity）と完全性（integrity）を確認し、信頼チェーン（Chain of Trust）と呼ばれる階層的な検証構造を形成する。

歴史・背景

セキュアブートの概念は 2000 年代初頭から研究されてきたが、広く普及したのは次のような背景がある。

2011年: UEFI フォーラムが UEFI Secure Boot 仕様を策定。Windows 8 以降の PC で必須となり、PC 領域での認知が一気に高まった。
組み込み・IoT 領域: ARM TrustZone の普及とともに、SoC レベルでのセキュアブートが標準的になった。STM32, i.MX, TI AM シリーズなど主要 MCU/MPU が専用の ROM ブートローダーを搭載するようになった。
NIST SP 800-193 (2018年): 「Platform Firmware Resiliency Guidelines」としてファームウェアセキュリティの包括的なガイドラインが公表され、セキュアブートが重要要素として明記された。
IoT セキュリティ法規制: EU の Cyber Resilience Act（CRA）や米国の大統領令 14028 など、法規制レベルでセキュアブートが要求されるようになっている。

技術仕様

信頼チェーン（Chain of Trust）

セキュアブートは以下の階層構造で信頼を連鎖させる。

[ルートオブトラスト (RoT)] → [ブートROM] → [ブートローダー] → [OS/ファームウェア] → [アプリケーション]

各ステージが次のステージの署名を検証してから制御を移す。最初の信頼の起点となる RoT がハードウェア的に保護されていることが全体の前提となる。

署名アルゴリズム

アルゴリズム	鍵長	用途
RSA-2048 / RSA-4096	2048〜4096 bit	多くの組み込み向けブートROM
ECDSA P-256 / P-384	256〜384 bit	省電力・省スペースが求められる MCU
Ed25519	256 bit	高速・軽量。新しい実装で増加中

ハッシュアルゴリズム

署名検証では以下のハッシュが使用される。

アルゴリズム	出力長	状態
SHA-256	256 bit	現在の主流
SHA-384 / SHA-512	384 / 512 bit	高セキュリティ要件向け
SHA-1	160 bit	非推奨（脆弱性あり）

動作原理

基本的な検証フロー

1. 電源投入
2. ハードウェアROM（変更不可）がブートローダーをロード
3. ブートローダーのハッシュを計算
4. OTP/eFuse に焼き付けられた公開鍵でデジタル署名を検証
5. 検証成功 → 次ステージへ制御移行
6. 検証失敗 → 起動停止またはリカバリモード移行

鍵管理と OTP / eFuse

検証に使用する公開鍵（またはそのハッシュ）は、One-Time Programmable (OTP) メモリや eFuse に書き込まれる。一度書き込まれると変更不可能であるため、製造時の鍵管理が非常に重要になる。

/* STM32 での RDP (Read Protection) + OTP 設定例（概念コード） */
#define OTP_BASE_ADDR   0x1FFF7000UL
#define OTP_LOCK_ADDR   0x1FFF7200UL

/* 公開鍵ハッシュを OTP に書き込み（一度だけ実行可能） */
void program_pubkey_hash(const uint8_t *hash, size_t len) {
    HAL_FLASH_Unlock();
    for (size_t i = 0; i < len; i += 4) {
        uint32_t word = *(uint32_t *)(hash + i);
        HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD,
                          OTP_BASE_ADDR + i, word);
    }
    HAL_FLASH_Lock();
}

U-Boot での Verified Boot 実装例

# FIT イメージの署名鍵生成
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 \
    -out dev.key
openssl req -new -x509 -key dev.key -out dev.crt

# FIT イメージ作成と署名
mkimage -f kernel.its kernel.itb
mkimage -F -k keys/ -K u-boot.dtb -r kernel.itb

# u-boot の設定
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_RSA=y
CONFIG_SPL_FIT_SIGNATURE=y

ロールバック防止（Anti-Rollback）

セキュアブートと組み合わせて、古い（脆弱な）ファームウェアへのダウングレードを防止するロールバック防止機能が重要である。バージョン番号を OTP に書き込み、それより古いバージョンの起動を拒否する。

用途・ユースケース

産業機器・制御システム

PLC やスマートメーターなど、フィールドに長期展開される機器では、悪意ある書き換えによる制御システムの乗っ取りが致命的な被害をもたらす。セキュアブートは最初の防衛手段として必須とされる。

自動車（車載機器）

AUTOSAR Adaptive Platform や OEM の要件として、ECU のセキュアブートが義務化されている。EVITA（E-safety Vehicle Intrusion Protected Applications）プロジェクトでも重要なセキュリティ要件として定義されている。

スマートホーム・IoT デバイス

Matter プロトコル認証の要件にもセキュアブートが含まれており、スマートスピーカーや家庭用ルーターでも採用が進んでいる。

医療機器

FDA のサイバーセキュリティガイダンス（2023年）でも、医療機器に対してセキュアブートの実装が推奨されている。

実装・開発のポイント

鍵の階層化（Key Hierarchy）

単一の鍵ではなく、鍵を階層化することでリスクを分散させる。

製造者ルート鍵（オフライン保管）
    └── 中間署名鍵（開発環境）
            └── ファームウェア署名鍵（CI/CD）

ルート鍵は HSM（Hardware Security Module）で管理し、オフラインに保つ。

デバッグポートの制御

セキュアブートを有効化する際は、JTAG/SWD デバッグポートも適切に制限する必要がある。開発中はデバッグを許可し、量産品ではロックする仕組みを設計段階で組み込む。

/* STM32 JTAG 無効化例 */
__HAL_RCC_AFIO_CLK_ENABLE();
__HAL_AFIO_REMAP_SWJ_DISABLE(); /* JTAG + SWD を無効化 */

フォールバック戦略

署名検証に失敗した際のフォールバック戦略が重要である。

戦略	メリット	デメリット
完全停止	セキュリティ最高	可用性ゼロ（産業用途では問題）
リカバリパーティション起動	復旧可能	リカバリ自体のセキュリティが必要
アラート送出後停止	異常を記録可能	通信機能が必要

テストの重要性

セキュアブートの実装ミスはデバイスをブリックさせる（文鎮化）リスクがある。以下を徹底する。

開発・量産向けに別々の鍵セットを用意する
QEMU などのエミュレータで検証する
段階的にロールアウト（一部デバイスで先行確認）する

他技術との比較

技術	役割	セキュアブートとの関係
ルートオブトラスト	信頼の起点	セキュアブートの基盤
TPM	セキュリティチップ	鍵保管・PCR による整合性測定
セキュアエレメント	鍵保管専用チップ	鍵をより安全に保管
ファームウェア署名	署名処理	セキュアブートの検証対象
OTAセキュリティ	無線更新セキュリティ	更新されたファームへのセキュアブート適用

セキュアブートは「起動時」の保護であり、実行中のコードの保護（実行時保護）とは異なる。完全なセキュリティには、セキュアブートに加えてランタイム保護、通信の暗号化、定期的なセキュリティアップデートを組み合わせる必要がある。

概要