組込みシステムエンジニアのためのファームウェアセキュリティ

ファームウェアはOSがロードされる前に実行され、再起動後も永続し、完全なハードウェア権限で実行されます。この組み合わせにより、ファームウェアは高価値なターゲットとなり、アプリケーション層のセキュリティモデルでは対応できない攻撃対象領域を持つことになります。ファームウェアセキュリティをプロジェクトの後半に適用するソフトウェアチェックリストとして扱うエンジニアは、常に最悪のタイミングでそのギャップを発見します。ライフサイクルとアーキテクチャのコンテキストについては、組込みファームウェア開発ライフサイクルとアーキテクチャのページを参照してください。この記事は、セキュリティ固有の意思決定に完全に焦点を当てています。

ファームウェアターゲットに特化したセキュリティ脅威モデリング

ファームウェア特有の攻撃ベクトル：物理、サプライチェーン、およびアップデートチャネルの脅威

ファームウェアには、標準的なCVEおよびOWASPモデルではうまく対処できない3つの脅威ウィンドウ、すなわち物理アクセス、サプライチェーン改ざん、OTAアップデートチャネルの悪用が存在します。

物理アクセス攻撃は直接的であり、しばしば過小評価されます。ボードにアクセスできる攻撃者は、JTAGまたはSWDプローブを接続し、デバッグインターフェイスがロックされたままであれば、数分でフラッシュの内容を読み取ることができます。本番ビルドで有効化されたままのUARTシェルは、コマンドインターフェイスを公開します。一部の設計では、フラッシュチップをはんだ付けして取り外し、市販のプログラマーで外部で読み取ることができます。これらは理論上のリスクではなく、製品の分解分析や競合他社のリバースエンジニアリングで標準的に使用される手法です。

サプライチェーン改ざんは、製造および流通のウィンドウを標的とします。契約製造業者に提供されるファームウェアイメージが整合性検証なしで提供された場合、デバイスの組み立て前に置き換えられたり変更されたりする可能性があります。この脅威は悪意のある攻撃者に限定されません。設定ミスのあるプログラミング治具が誤ったイメージをフラッシュする可能性があり、デバイスは起動時にその置き換えを検出する方法がありません。

OTAアップデートチャネルは、接続デバイスで最も頻繁に悪用されるベクトルです。ファイル整合性のみを検証し、デバイスに保持されている公開鍵に紐付けられた暗号署名検証を行わないアップデートパイプラインでは、アップデートサーバーを傍受またはなりすますことができるあらゆる当事者が任意のファームウェアをプッシュできます。アップデートエンドポイントでの認証が弱いこともこれを悪化させます。デプロイ前およびデプロイ後の脅威ウィンドウには異なる制御が必要であり、それらを混同すると両方にギャップが生じます。

標準的な脆弱性分類フレームワークは、汎用オペレーティングシステムで実行されるソフトウェアのために構築されました。ファームウェアの脅威モデリングには、独自のメソドロジーが必要です。

ファームウェア固有の信頼境界と資産分類

いずれかのセキュリティ制御を選択する前に、エンジニアはファームウェアが実際に何を保護する必要があるかを特定する必要があります。資産リストには通常、暗号鍵、デバイスID証明書、キャリブレーションまたは設定データ、およびバイナリに埋め込まれた独自のアルゴリズムが含まれます。各資産は異なるリスクプロファイルを持ち、異なる保護アプローチを必要とします。

組み込みターゲットにおける信頼境界マッピングは、サーバーサイドアーキテクチャとは1つの重要な点で異なります。境界は論理的なものでもあり、物理的なものでもあります。ブートローダーは、ハードウェアの信頼のルート（root of trust）によって検証されたもののみを信頼します。アプリケーションファームウェアは、ブートローダーによって渡されたもののみを信頼します。クラウドバックエンドは、デバイスによって認証されたもののみを信頼します。そのチェーンのいずれかのリンクが切断されると、モデル全体が壊れます。

リスク階層化により、限られたハードウェアへの投資を優先順位付けできます。OTPヒューズに格納された長期間使用されるデバイスIDキーは、専用のセキュアエレメントを正当化します。1回の更新サイクルのみで使用されるセッショントークンはそうではありません。すべての資産に均一な保護を適用するエンジニアは、低リスクデータにリソースを浪費し、結果として高リスク資産の保護が不十分になりがちです。

セキュアファームウェアアーキテクチャ：ブートチェーンとメモリ保護レイアウト

セキュアブートチェーン設計とハードウェアルートオブトラストの統合

セキュアブートチェーンは、製造元が一度書き込み、製造後に変更できないROM常駐コードに信頼をアンカーします。この変更不可能なブートステージは、実行を転送する前にブートローダーの署名をチェックします。次に、ブートローダーがアプリケーションイメージを検証します。各ステージは、前のステージが検証したもののみを信頼します。

キー（鍵）ストレージは、このチェーンにおける最も重要な設計上の選択です。各オプションには、 real trade-offs が伴います：

OTPヒューズ： 低コスト、一度だけ書き込み可能、外部依存なし—ただし、プロビジョニング後のキーローテーションは不可
セキュアエンクレーブ（例：Cortex-A上のTrustZone、Cortex-M上のTF-M）： より柔軟性の高いソフトウェア分離型キー保存機能ですが、適切な設定に依存します
専用セキュアエレメントまたはTPM: ハードウェア分離型、改ざん防止、最高の攻撃耐性 — 部品コストと基板面積が増加します

起動時のメモリ保護ユニット（MPU）設定により、データセクションに対する実行禁止領域、および検証済みイメージに対する読み取り専用領域が強制されます。MPUの強制がない場合、アプリケーションのバッファオーバーフローによって、クリーンな起動検証後であっても任意のコードを上書きして実行される可能性があります。

ロールバック防止はしばしば見落とされます。OTPまたはセキュアNVMに単調増加するバージョンカウンタを保存し、それより低いバージョン番号のイメージを拒否することで、パッチ適用済みの脆弱性を再露呈させるダウングレード攻撃をブロックします。

専用セキュリティMCUと統合セキュリティ機能のどちらを選択するかは、脅威レベルと単価の制約によって異なります。たとえば、制約のあるハードウェアターゲット向けの組み込みファームウェア設計では、統合されたTrustZoneまたはセキュアブートペリフェラルが、BOMコストを低く抑えながら十分な保護を提供することがよくあります。高価値または安全性が重要なアプリケーションでは、通常、個別のセキュアエレメントが正当化されます。

開発パイプライン全体でのファームウェアセキュリティ制御の実装

ファームウェアイメージの署名、暗号化、およびセキュアOTAアップデートの実装

イメージ署名は公開鍵暗号方式を使用します。秘密鍵はビルド環境内のハードウェアセキュリティモジュールに格納され、そこから出ることはありません。対応する公開鍵は製造時にデバイスにプロビジョニングされ、アプリケーションが上書きできない領域に格納されます。起動時、ブートローダーは実行前にイメージ署名をその公開鍵に対して検証します。

暗号化と署名は異なる目的を果たします。署名はイメージが信頼できるソースから提供されたことを証明します。暗号化は、バイナリの内容の抽出を防ぎます。多くの製品では署名のみが必要です。バイナリ自体に保護可能なIP（独自のアルゴリズムやキャリブレーションモデルなど）が含まれ、脅威モデルに物理的なフラッシュ読み出しが含まれる場合に暗号化が正当化されます。

OTAアップデートのセキュリティには、署名付きイメージ以上のものが必要です。完全なパイプラインは、まずアップデートマニフェストを検証し、バージョン番号をロールバックカウンターと比較し、イメージ署名を検証してからフラッシュに書き込みます。マニフェスト検証をスキップすると、有効だが古い署名付きイメージを使用したリプレイ攻撃が可能になります。

鍵管理は独自のエンジニアリング計画に値します。鍵生成はHSM内で行われるべきです。ローテーションポリシーは、デバイスの期待されるサービス寿命を考慮する必要があります。組み込みデバイスでの失効はサーバーよりも困難です。ほとんどのデザインでは、リアルタイムの失効チェックではなく、証明書の有効期限と必須アップデートを通じて処理されます。 IoTデバイスのファームウェアアップデートと接続パターンの場合、クラウドバックエンドの信頼境界は、このパイプラインに別のレイヤーを追加し、別途処理する必要があります。

本番環境で定期的に発生する1つの障害パターンは、エンジニアがビルド時にプリストリップバイナリに署名し、その後ポストストリップイメージをリリースすることです。署名が一致しません。修正策は、ビルド完了前にハッシュ比較によって検証され、フラッシュされる正確なアーティファクトへの署名を強制するCIゲートです。

実行時セキュリティ制御：ウォッチドッグ、スタック保護、セキュア通信

スタックカナリアは、実行をリダイレクトする前にバッファオーバーフローを検出します。MPUで強制されたスタック境界と組み合わせることで、オーバーフローが成功した場合の被害範囲を、システム全体を破損させるのではなく、障害が発生したタスクに限定します。ほとんどのCortex-Mターゲットでは、MPUスタックガード領域は実行時のコストをほとんど追加しません。

ウォッチドッグタイマーは可用性制御です。ファームウェアループ攻撃（意図的または偶発的）によりウォッチドッグがサービスされなくなると、リセットがトリガーされます。エンジニアリングのトレードオフは、ウォッチドッグタイムアウトの選択です。短すぎると、正当な処理遅延が誤ったリセットを引き起こします。長すぎると、デバイスがロック状態にとどまる時間が長くなり、運用上の損傷を引き起こす可能性があります。産業用HMIアプリケーションの典型的な範囲は、最悪の場合の正当な処理ウィンドウに合わせて調整された500msから数秒です。

ファームウェアレイヤーでのセキュア通信は、サーバー証明書の検証だけでなく、MQTTおよびHTTPS接続のためのTLS相互認証を意味します。証明書ピンニングは、侵害されたCAに対する保護を追加しますが、証明書のローテーションを複雑にします。制約のあるデバイスでは、リーフ証明書ではなくCA証明書をピンニングすることで、セキュリティと運用の柔軟性のバランスを取ります。

デバッグインターフェイスのロックダウンは、設定の問題であると同時にCIの強制の問題でもあります。JTAGロックビットとUARTシェルの無効化は、本番ビルド構成で検証され、デバッグが有効な状態で出荷されることをブロックする必要があります。署名前にバイナリのデバッグヒューズ構成をチェックするCIゲートは、これが本番環境に到達するのを防ぎます。

フォールトインジェクション対策は、物理アクセスが現実的な脅威となる場合に適用されます。電圧グリッチ検出回路と冗長なクリティカルチェック（同じセキュリティ決定を2回実行して結果を比較する）は、セキュアブートまたはキー派生操作に対する成功したグリッチ攻撃のコストを増加させます。

セキュリティ検証：ファームウェアの静的解析、ファジング、ペネトレーションテスト

ファームウェアを対象とした静的解析は、アプリケーション層のスキャンとは異なる脆弱性を特定します。優先度の高い問題としては、境界チェックなしの安全でないメモリ操作、フラッシュメモリへのハードコードされた認証情報、キー生成のための弱いエントロピーソース、通信ハンドラにおける検証されていない外部入力などが挙げられます。PC-lint、Polyspace、Coverityのようなツールは、コードがハードウェアに到達する前にこれらの多くを検出します。

ファームウェアのファジングは、2つのアプローチに分かれます。エミュレーションベースのファジングは、ソフトウェアエミュレータでファームウェアイメージを実行し、ハードウェアなしで高速な入力生成とカバレッジ測定を可能にします。ハードウェアインザループ（HIL）ファジングは、実際のターゲット上で実行され、エミュレータが見逃すハードウェア固有の動作を検出します。トレードオフは速度と忠実度です。ほとんどのチームは、開発の早い段階で広範なカバレッジを得るためにエミュレーションを使用し、リリース前に通信インターフェースのターゲットテストのためにHILを使用します。

ファームウェアのペネトレーションテストの範囲には、本番ハードウェアへの物理的な抽出試行、リプレイまたは変更されたパッケージを使用したアップデートチャネルの悪用、ロックされたデバイスでのデバッグインターフェースのプロービングが含まれるべきです。ソフトウェアロジックのみをテストすると、物理的な攻撃面が完全に無視されます。

CIにおけるセキュリティチェックには、既知の脆弱なライブラリバージョンに対するバイナリスキャン、すべてのファームウェア依存関係を追跡するためのSBOM生成、およびすべてのビルド成果物に対する自動署名検証が含まれるべきです。コンプライアンスフレームワーク（産業システムの場合はIEC 62443、プラットフォームファームウェアの回復性の場合はNIST SP 800-193、Armベースのデバイスの場合はPSA Certified）は、これらのパイプライン制御によく対応する構造化された検証基準を提供します。

これらの制御を社内で構築するか、専門のパートナーと協力するかを評価するエンジニアは、セキュアキープロビジョニングとHSM統合におけるチームの専門知識を特に評価する必要があります。これらのステップは、ギャップが最も頻繁に現れる箇所です。セキュリティ要件を最初から組み込んで構築されたカスタムファームウェアは、アーキテクチャがサポートするように設計されていなかった制御の後付けコストを回避します。

ファームウェアセキュリティとは、早期に行われ、ビルドパイプラインを通じて継続的に強制される設計上のコミットメントのセットです。プロジェクトの開始時に脅威モデリングと署名インフラストラクチャを埋め込んだチームは、リリース時にセキュリティ制御を追加したチームよりも、大幅に低い修正コストで済みます。STONE HMIは、産業用HMIシステム向けのプロダクショングレードのファームウェアを開発しています。ビルドパイプラインに追加されるのではなく、組み込まれたセキュリティ制御のようなプロセス規律は、展開されたデバイス全体でのパッチ適用にコストがかかる、最終段階での手戻りやフィールドでの脆弱性のリスクを直接低減します。