小田桐慶



EU CRA対応「セキュアブート」の難所: eFuse書き込みと鍵管理設計

ミラクシアエッジテクノロジーの小田桐です。プロダクトセキュリティ、セキュリティコンプライアンスを担当しています。

2027年の欧州サイバーレジリエンス法（EU CRA）全面適用に向け、製造業の現場では対応が急ピッチで進んでいることと思います。特に「製品のセキュリティ要件（Annex I）」への適合は待ったなしの状況です。しかし、現場のエンジニアにとって、CRA対応の一つである「セキュアブートの実装」は、単なる機能追加とは異なる独特の緊張感を伴う作業ではないでしょうか。なぜなら、「一度失敗したら、その基板は二度と起動しなくなる（文鎮化する）」という、物理的なやり直しがきかない作業 が含まれているからです。

本記事では、産業用ゲートウェイ等で広く採用されている NXPセミコンダクターズ社の i.MX 8M Plus を例に、CRA要件を満たすセキュアブートの実装フローと、2027年以降を見据えた「鍵管理運用」の技術的な勘所について解説します。

※注意: 本記事は i.MXシリーズを例に説明しています。各 SoCメーカーの eFuse への書き込み前の署名検証・動作確認については仕様の違いがあります。i.MXシリーズ以外の SoC を使用する場合は、各メーカーのドキュメントを参照してください。

1. CRAが求める「完全性」と SoC に書き込むルートオブトラスト

まず、なぜCRA対応でセキュアブートが必須となるのかを整理します。 CRAの基本要件（Annex I）には、「製品の完全性（Integrity）の保護」が明記されています。これは平たく言えば、「メーカーが意図していない（署名されていない）不正なファームウェアやOSが動作しないことを保証せよ」 ということです。

※補足：CRAの条文そのものが特定の技術（セキュアブート等）を指名して強制しているわけではありません。しかし、この「完全性」の要件を満たすための技術的手段として、整合規格の候補である IEC 62443-4-2 などの国際標準では「ブートプロセスの完全性 (CR 3.14)」が定義されており、実質的な解としてセキュアブートの実装が求められる可能性が高いです。

この要件を実現するために SoC にはセキュアブート機能が搭載されています。NXP の i.MX 8M Plus では HABv4 (High Assurance Boot version 4) という機能が搭載されています。HABv4は、以下の流れで「信頼の連鎖（Chain of Trust）」を構築します。

  1. BootROM: SoC製造時に焼き込まれた変更不可能なコード。これが最初のブートローダー（SPL）の署名を検証する
  2. SPL (Secondary Program Loader): 署名検証されたSPLが、次の U-Boot 本体の署名を検証する
  3. U-Boot: 署名検証されたU-Bootが、Linuxカーネル（およびDevice Tree）の署名を検証する
  4. Linux Kernel: 起動を完了する

この連鎖の起点 (ルートオブトラスト)となるのが、SoC内部にある SRK (Super Root Key) の情報です。 ここで重要なのは、SoCのeFuse（電子ヒューズ）に書き込むのは「公開鍵そのもの」ではなく、「公開鍵のハッシュ値 (SRK Hash)」 であるという点です。これにより、鍵のサイズを抑えつつ、後述する「鍵のローテーション（無効化）」が可能になる柔軟な設計となっています。

2. eFuse 書き込みを乗り越える

セキュアブート実装における最大のハードルは、eFuseへの書き込みです。 fuse prog コマンド等で一度 eFuse を焼き切ってしまうと、元に戻すことは物理的に不可能です。もし書き込むハッシュ値を間違えれば、SoCは「正当な署名を持つソフトが存在しない」と判断し、二度とブートしなくなります。いわゆる「文鎮化（ブリック化）」です。

このリスクを回避するために、以下のステップを踏みます。

ステップ1：SRKハッシュの書き込み（まだ閉じない）

まず、作成した鍵ペアから生成したハッシュ値をeFuseに書き込みます。この時点では、まだセキュリティ機能は有効化（Enforced）しません。これを「Open」な状態と呼びます。

ステップ2：「Open」状態でのシミュレーション検証

ここが最も重要です。デバイスを「Close（完全ロック）」する前に、「もし今Closeしていたら、正しく起動できたか？」を検証します。

i.MXシリーズのU-Bootには、HABの状態を確認するコマンドやAPIが用意されています。

u-boot=> hab_status

このコマンドを実行した際、理想的な出力は以下のようになります（バージョンにより表記は異なります）。

**Secure boot disabled**
**No HAB Events Found!**

「Secure boot disabled」と表示されているのに「No HAB Events Found（エラーイベントなし）」であることが重要です。これは、セキュリティ機能はまだ強制していないけれど、署名確認の検証は可能 であることを意味します。 ここで逆に HAB Event エラーが出ている場合は、署名の手順や鍵の組み合わせが間違っています。しかし、まだOpen状態なので、何度でも書き直しや修正が可能です。この段階でエラーを完全に潰すことが、量産品質への絶対条件となります。

3. 最終工程「SEC_CONFIG」と「攻撃面」の削減

Open状態での検証が完了したら、いよいよデバイスを「Close」します。 具体的には、SEC_CONFIG という特定のヒューズを書き込みます。これにより、SoCは署名検証に失敗したプログラムの実行を拒否するようになります。

しかし、CRA対応としてはこれだけでは不十分です。 CRAでは「攻撃対象領域の削減（Attack Surface Reduction）」が求められます。セキュアブートでソフトを守っても、JTAGデバッグポート が開いたままでは、物理的にメモリを覗き見られたり、改ざんされたりするリスクが残ります。

最終製品としてはJTAG等のデバッグ機能を無効化する必要があります。 ただし、ここには大きなトレードオフが存在します。**「JTAGを閉じると、市場不具合が発生した際の解析（メモリダンプ等）が極めて困難になる」**という点です。 「いつ閉じるか」「完全に閉じるか、パスワード認証付きのデバッグモード（Secure Debug）を残すか」。ここは技術的な実装だけでなく、製品の保守ポリシーに関わる重要な判断となります。

4. 2027年以降を見据えた「鍵の更新（Revocation）」と運用設計

ここまでは従来の組込開発でも語られてきた内容ですが、CRA対応で新たに重要になるのが**「脆弱性管理と鍵のライフサイクル」**です。

もし、製品出荷後に署名用の「秘密鍵」が漏洩したらどうなるでしょうか？ 攻撃者はその鍵を使って不正なファームウェアに「正規の署名」を行い、CRA対応製品にバックドアを仕掛けることができてしまいます。

これに対処するため、i.MX 8M PlusのHABv4には Key Revocation (鍵の無効化/失効) という機能があります。 SRKテーブルには、最大4つの公開鍵を登録できます。eFuseには、この4つの鍵の「ハッシュ」が登録されています。

  • 初期出荷時: 1番目の鍵 (Index 0) を使用して署名
  • インシデント発生時: 1番目の鍵が漏洩したと判断
  • 対策: OTAアップデート等で、「1番目の鍵を無効化（Revoke）するヒューズ」を書き込むスクリプトと、「2番目の鍵 (Index 1) で署名し直した新しいファームウェア」を配布

これにより、漏洩した1番目の鍵で作られた不正ソフトは起動しなくなり、正規の2番目の鍵で署名されたソフトのみが動作するようになります。

**「量産時に鍵をどう登録するか」**が運命の分かれ道です。 もし、何も考えずに鍵を1つしか用意していなければ、その鍵が漏洩した時点で、ハードウェア全体のリコール（回収）が必要になるかもしれません。 CRA時代には、開発段階で「2番目、3番目の予備鍵」を生成し、厳重に保管（オフライン管理やHSM利用）しておく運用設計が不可欠なのです。

まとめ

CRA対応におけるセキュアブートは、単に「機能をONにする」ことではありません。

  1. eFuse書き込みに対する、確実な検証プロセスの確立
  2. デバッグポート閉塞と保守性のトレードオフ判断
  3. 製品寿命期間を見据えた鍵管理（Revocation）の運用設計

これらハードウェア、ソフトウェア、そして運用プロセスが一体となった「エンジニアリング」が必要です。

ミラクシアエッジテクノロジーでは、大手機器メーカー様の量産開発で培ったBSP技術を活かし、お客様のハードウェア構成に合わせたセキュアブートの実装支援を行っています。 「eFuseを焼くのが怖い」「鍵管理の運用フローが決まらない」「Yocto環境での署名自動化をどうすべきか」。 そのようなお悩みがあれば、ぜひミラクシアにご相談ください。設計のアドバイスだけでなく、「実際に動く、守れる実装」 を私たちが伴走して作り上げます。

採用情報

ミラクシアでは一緒に組込みソフト開発をする仲間を募集しています。 OSポーティング、ドライバ開発、セキュリティ実装など、深い技術に触れられる環境があります。


Miraxia採用サイト

参考文献

  • EU Cyber Resilience Act (Regulation (EU) 2024/2847)
  • NXP Semiconductors, “AN4581: i.MX Secure Boot on HABv4 Supported Devices”