Chapter 20

Espressif — ESP32 系

この章の位置づけ.

ESP32 系は、Wi-Fi / BLE 一体型で圧倒的に安価なため、 IoT 製品で非常に広く使われている。

だが——セキュリティ機能は「既定で無効」であり、 有効化しないまま出荷される事例が極めて多い。

機能自体は充実している。問題は「使われていない」ことである。

注意: ESP32 系は品種（ESP32 / S2 / S3 / C3 / C6 / H2 / P4 など）と シリコンリビジョンで機能が大きく異なる。 必ず対象品種の Technical Reference Manual と ESP-IDF の Security ドキュメントで確認すること。

この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、物理攻撃（04 章 6 節）、署名検証（04 章 4 節）、RSA-3072（05 章 3 節）、eFuse（06 章 2 節）、不可（06 章 1 節）、完全性（06 章 6 節）、機密性（06 章 6 節）、起動時間（06 章 3 節）、Non-secure（07 章 3 節）、Secure（07 章 3 節）、サイドチャネル（07 章 8 節）、AES（08 章 8 節）、Nordic（11 章 4 節）、Espressif（12 章 3 節）、Renesas（12 章 3 節）、量産（14 章 5 節）、開発（14 章 5 節）、運用（15 章 8 節）、RAM（16 章 3 節）、フラッシュ（16 章 3 節）、TrustZone-M（17 章 1 節）、TEE（19 章 8 節）

1. ファミリの整理

ESP32 のセキュリティ機能を調べる

品種を選ぶと、対応する機能と設定手順の要点が表示される。

「ESP32」と一括りにしないこと.

初代 ESP32 のリビジョン 1 では Secure Boot v2 が使えない。 新規設計では、S3 / C3 / C6 など新しい世代を選ぶことを強く推奨する。

2. eFuse — すべての土台

ESP32 のセキュリティ設定は、すべて eFuse で制御される（06 章）。

各ブロックには「読み出し保護」と「書き込み保護」のビットがある。

espefuse.py の操作は、すべて不可逆である.

# 必ず --do-not-confirm なしで、内容を確認してから実行する
espefuse.py -p /dev/ttyUSB0 burn_key BLOCK_KEY0 secure_boot_key.pem SECURE_BOOT_DIGEST0
espefuse.py -p /dev/ttyUSB0 summary        # ← 状態を確認する

間違えたチップは廃棄するしかない。 量産前に、捨ててよいチップで手順を通しで検証すること。

用途ビット（KEY_PURPOSE）

鍵ブロックに「何に使うか」を宣言するのが優れた設計である。

セキュアブートのダイジェストが 3 個持てるのは重要である（12 章）。

署名鍵が漏洩したら、その鍵を失効させて、残りの鍵で運用を継続できる。 SECURE_BOOT_KEY_REVOKE0/1/2 の eFuse で個別に失効できる。

鍵の失効機構を持つのは、この価格帯の MCU では特筆すべき点である。

3. Secure Boot v2

有効化の手順

# menuconfig で設定
idf.py menuconfig
  → Security features
      → [*] Enable hardware Secure Boot in bootloader
      → Secure Boot: Signing scheme = RSA-3072
      → [*] Sign binaries during build
      → Secure bootloader mode = One-time flash（★推奨）

# 署名鍵を生成（★ HSM 管理を推奨。ここでは例示）
espsecure.py generate_signing_key --version 2 secure_boot_signing_key.pem

# ビルド・書き込み
idf.py build
idf.py -p /dev/ttyUSB0 flash

「Reflashable」モードを量産で使わないこと.

ESP-IDF には 2 つのモードがある。

モード	内容
One-time flash	eFuse にダイジェストを焼き、以後は署名済みイメージしか書けない
Reflashable	開発の利便性のため、鍵を再利用できる

Reflashable は開発専用である。 量産では One-time flash を使う。

見落としがちな設定

これが 11 章のチェックリストそのものである.

Secure Boot を有効にしても、 シリアルダウンロードモードや JTAG が開いていたら意味がない。

ESP-IDF の menuconfig には Security features → UART ROM download mode の設定があり、 Permanently disabled を選べる。

量産では必ず無効化すること。

4. Flash Encryption

外付け SPI フラッシュの内容を暗号化する（06 章）。

Development モードと Release モード

この違いが決定的に重要である。

Development モードのまま出荷する事故が実際にある.

Development モードでは、攻撃者が UART 経由で平文を書き込める。 つまり任意のファームウェアを動かせる。Flash Encryption の意味がない。

Security features
  → Enable flash encryption on boot
  → Enable usage mode = Release   ★ 必ず Release

一度 Release にすると Development には戻せない。 だからこそ、量産前に Release モードで全機能を検証すること（14 章）。

Flash Encryption が守るもの・守らないもの

Secure Boot と Flash Encryption は、必ず両方有効にすること.

有効にしたもの	残る穴
Secure Boot のみ	フラッシュを読める → 鍵やロジックが漏れる
Flash Encryption のみ	改ざんを検出できない（06 章の「暗号化 ≠ 完全性」）
両方	実用上の防御が成立する

5. HMAC と DS ペリフェラル

ESP32-S2/S3/C3 以降が持つ、非常に有用な機能である。

HMAC ペリフェラル

DS（Digital Signature）ペリフェラル

これが最も特徴的な機能である。

これは ESP32 系の大きな価値である.

06 章で述べた「鍵の不可視化」を、 追加のチップなしで実現できる。

ESP-IDF には esp_secure_cert_mgr というコンポーネントがあり、 DS ペリフェラルを使った TLS クライアント認証が AWS IoT / Azure IoT との接続で使える。

ただし——物理攻撃（クラス 4 以上）への耐性は、 専用のセキュアエレメントには及ばないことを理解しておくこと（22 章）。

6. NVS 暗号化

設定値やユーザデータを保存する NVS（Non-Volatile Storage）も暗号化できる。

Wi-Fi のパスワードやクラウドのトークンは、NVS に保存されることが多い.

NVS 暗号化を有効にしないと、フラッシュを読むだけでこれらが取れる。 Flash Encryption を有効にしていれば間接的に守られるが、 NVS 暗号化も併せて有効にするのが正しい構成である。

7. ESP-TEE（新しい取り組み）

ESP-IDF v5.4 以降、ESP32-C6 向けに ESP-TEE が導入された。

RISC-V には標準の TrustZone 相当がない（07 章）ので、 ベンダ独自の機構で埋めているという構図である。

対応品種と成熟度は発展途上なので、 採用を検討する場合は、最新の ESP-IDF ドキュメントで 対応状況を確認すること。

8. ESP32 の設定チェックリスト

この章の内容を、実行可能な形にまとめる。

# 出荷前に必ず実行する確認コマンド
espefuse.py -p /dev/ttyUSB0 summary
# → SECURE_BOOT_EN = True
# → SPI_BOOT_CRYPT_CNT が Release 相当の値
# → DIS_DOWNLOAD_MODE = True
# → 鍵ブロックが読み出し保護されている

9. 実務上の注意点

「起動時間が伸びる」は製品要件に影響する.

電池駆動で「ボタンを押したら即座に反応する」製品では、 Secure Boot + Flash Encryption の起動時間増加が問題になりうる。

企画段階で実測し、要件に織り込むこと。 後から「起動が遅いのでセキュリティを切る」は最悪の判断である。

10. この章のまとめ

次章は、その他の主要ベンダをまとめて見る。