Chapter 11

ファームウェア抽出とデバッグポート

この章がなぜ必要なのか——攻撃は、ほぼ必ずここから始まるから.

09 章のサイドチャネルも、10 章のフォールトも、 まずファームウェアを読んで、狙う場所を特定するところから始まる。

そして実務では——ファームウェアを読まれた時点で、 ハードコードされた鍵やパスワードが出てきて、それで終わることが非常に多い。

ここを塞ぐことが、費用対効果の最も高い対策である。

この章で使う既出の用語（定義は各リンク先）. 数万円（01 章 2 節）、物理攻撃（04 章 6 節）、OTFDEC（06 章 6 節）、Secure（07 章 3 節）、TrustZone（07 章 2 節）、サイドチャネル（07 章 8 節）、フォールト（07 章 8 節）、両方（07 章 3 節）、必要（09 章 6 節）

1. ファームウェアはどこから漏れるか

デバッグポートとファームウェア抽出経路

各経路をクリックすると、攻撃の手順と対策が表示される。

上から 5 つは、すべて「設定ミス」で開く.

つまり追加の部品コストをかけずに塞げる。 ここを塞がずに暗号アクセラレータの議論をしても意味がない。

2. 経路 1: 公開ファームウェアと OTA

最も見落とされる経路である。

# 攻撃者がやること（イメージ）
$ binwalk firmware.bin          # 中身の構造を調べる
$ binwalk -e firmware.bin       # ファイルシステムを展開
$ strings firmware.bin | grep -i -E 'key|passwd|secret|token|BEGIN'
$ grep -r "AWS" extracted/      # クラウドの認証情報を探す

対策:

「暗号化すれば安全」ではない.

OTA イメージを暗号化しても、全機器が同じ鍵で復号するなら、 1 台から鍵を取れば全イメージが復号できる。

だから「イメージの暗号化」は時間稼ぎであって、根本対策ではない。 根本対策は「ファームウェアに秘密を含めないこと」である。

秘密（機器固有鍵、証明書）は、 工場でのプロビジョニング（12 章）か、初回起動時の生成で入れる。 ファームウェアイメージには入れない。

3. 経路 2: UART コンソール

基板を見ると、4 ピンのパターン（VCC・GND・TX・RX）がよく残っている。

1. 基板のテストパッドやピンヘッダを探す
2. USB シリアル変換を繋ぎ、ボーレートを総当たりする（9600〜921600）
3. 起動ログが流れてくる → ブートローダの種類、カーネル、ファイルシステム構成が分かる
4. Enter を押す → シェルプロンプトが出ることがある
5. ブートローダで起動を中断 → 起動引数を書き換えて init=/bin/sh

/* ビルド設定で切り分ける */
#ifdef PRODUCTION_BUILD
    #define DEBUG_CONSOLE_ENABLED   0
    #define LOG_LEVEL               LOG_ERROR
#else
    #define DEBUG_CONSOLE_ENABLED   1
    #define LOG_LEVEL               LOG_DEBUG
#endif

「デバッグ機能をコンパイル時に除去する」ことが重要である.

実行時のフラグで無効化するだけでは、 コードが残っているのでグリッチや脆弱性で有効化されうる。

量産ビルドには、そもそもコードを含めない。 リンカマップを見て、デバッグ用シンボルが残っていないか確認するとよい。

4. 経路 3: SWD / JTAG

最も直接的な経路である。 デバッガを繋げば、

• フラッシュ全体を読み出せる
• RAM の内容を読める（鍵が乗っている）
• CPU を停止・ステップ実行できる
• レジスタを書き換えられる

保護の方法

認証付きデバッグ

閉じるか開けるかの二択ではなく、「認証すれば開く」という第 3 の道である。

認証付きデバッグは、RMA（返品分析）の切り札である.

14 章で詳しく扱うが、 「量産品を完全にロックすると、故障解析ができない」という深刻な問題がある。

認証付きデバッグなら——

• 出荷時は閉じている
• メーカーだけが持つ鍵で開けられる
• 開けたときに鍵を自動消去する設定にもできる（機密は守られる）

これがあるかどうかは、SoC 選定の重要な基準である。

5. 経路 4: 外付けフラッシュ

MCU がどれだけ堅牢でも、外付けフラッシュは別のチップである。

1. SPI フラッシュ（W25Qxx、MX25Lxx など）を基板上で特定する
2. SOIC クリップ（基板に載ったままのチップへ上から挟んで配線を取り出す治具）を付けてその場で読む、またはホットエアで外してプログラマで読む
3. 数分でフルダンプが取れる

バスの盗聴も可能である.

フラッシュを外さなくても、SPI バスにロジックアナライザを繋げば 転送内容が読める。XIP で実行していれば、実行中のコードがそのまま流れる。

だから「起動時だけ復号する」のでは足りない。 常時暗号化されたまま転送される必要がある。 これがオンザフライ復号エンジンの役割である。

6. 経路 5: ISP / ブートローダモード

多くの MCU が、工場書き込み用の ROM ブートローダを持っている。 基板に実装したまま外部から書き込める仕組みなので ISP（In-System Programming）と呼ばれる。

これらは「書き込み」だけでなく「読み出し」もできる場合がある。

必ずデータシートで「保護レベルと ROM ブートローダの関係」を確認すること.

「フラッシュ読み出し保護をかけたのに、 ROM ブートローダ経由では読めた」という事故が起こりうる。

特に、保護をかけても「消去」はできる設計になっていることが多い。 消去は攻撃者にとって直接の利益にならないが、 消去 → 保護解除 → 自分のコードを書き込んで、外付けフラッシュを読ませる という 2 段構えの攻撃が成立する場合がある。

7. RAM に残る秘密

フラッシュを守っても、実行中の RAM には平文の鍵が乗っている。

対策:

/* 使い終わった鍵は必ず消す（[08 章](08_暗号エンジンと乱数.md#落とし穴-2-dma-と共有バス)） */
mbedtls_platform_zeroize(session_key, sizeof(session_key));

/* リセット時・起動時に SRAM をクリアする */
void SystemInit(void) {
    extern uint32_t _sram_start, _sram_end;
    for (uint32_t *p = &_sram_start; p < &_sram_end; p++) *p = 0;
}

8. ファームウェアの解析を難しくする

塞ぎきれない前提で、解析コストを上げるという考え方もある。

難読化は「セキュリティ」ではなく「時間稼ぎ」である.

Security through obscurity（隠すことによる安全）は原則として避けるべきである。 暗号鍵や認証の強度を難読化に依存してはいけない。

ただし、正しい対策の上に追加で載せる分には価値がある。 特にシンボルの除去は、コストゼロで効果が大きいので必ずやること。

# リリースビルドでは必ず
arm-none-eabi-strip --strip-all firmware.elf
# マップファイルを確認して、デバッグ用シンボルが残っていないか見る

9. 出荷前チェックリスト

この章の内容は、そのままチェックリストになる。

7 番目の確認方法.

# 出荷イメージに対して、必ず実行する
strings firmware.bin | grep -i -E 'password|passwd|secret|api[_-]?key|token|BEGIN (RSA|EC|PRIVATE)'
binwalk -E firmware.bin      # エントロピーを見る（高エントロピー領域 = 鍵かもしれない）

CI に組み込んで、毎ビルドで自動チェックすること。 人間のレビューでは必ず見落とす。

より本格的には、シークレットスキャナ（gitleaks、trufflehog など）を ソースとビルド成果物の両方に対して回す。

10. この章のまとめ

ここまでで第 III 部は終わりである。 次章から第 IV 部——機器の一生を通した鍵と状態の管理に入る。