Chapter 23
選定指針と設計チェックリスト
この章の位置づけ.
ここまでの 22 章を、実際に使える形にまとめる。
- 要件から必要な機能を導く
- 機能から品種を絞る
- 設計・実装・出荷の各段階でチェックする
01 章で述べたとおり、ハードウェアに関わる決定は後から変えられない。 だからこの章の内容は、基板を起こす前に通す必要がある。
この章で使う既出の用語（定義は各リンク先）. デフォルトパスワード（01 章 5 節）、可用性（01 章 4 節）、決済（03 章 5 節）、物理攻撃（04 章 6 節）、署名検証（04 章 4 節）、OTFDEC（06 章 6 節）、不可（06 章 1 節）、完全性（06 章 6 節）、機密性（06 章 6 節）、鍵ラッピング（06 章 4 節）、TrustZone（07 章 2 節）、サイドチャネル（07 章 8 節）、フォールト（07 章 8 節）、割り込み（07 章 3 節）、AES（08 章 8 節）、エントロピーレート（08 章 3 節）、必要（09 章 6 節）、フラッシュ暗号化（11 章 5 節）、最も重要（11 章 2 節）、SFI（12 章 3 節）、ロールバック防止（13 章 1 節）、CRA（14 章 6 節）、市場（14 章 5 節）、認証付きデバッグ（14 章 3 節）、量産（14 章 5 節）、開発（14 章 5 節）、廃止（15 章 8 節）、窓口（15 章 7 節）、要件（15 章 8 節）、運用（15 章 8 節）、Matter（16 章 4 節）、RAM（16 章 3 節）、ポート（16 章 6 節）、PACBTI（17 章 1 節）、PSA（17 章 1 節）、TF-M（17 章 4 節）、アーキテクチャ（17 章 1 節）、ELE（19 章 5 節）、EdgeLock（19 章）、PRINCE（19 章 4 節）、ブート（19 章 8 節）、CPMS（21 章 2 節）、HSM（21 章 6 節）、RMA（21 章 5 節）、プリプロビジョニング（21 章 7 節）、独立セキュリティコア（21 章 7 節）、AVA_VAN（22 章 3 節）、標準的（22 章 2 節）、第三者評価（22 章 2 節）
1. 要件から機能へ
SoC 機能セレクタ
要件を選ぶと、必要なハードウェア機能と、それを持つベンダ・品種の傾向が表示される。
3 つのレベルで考える
| レベル | 想定 | 必要な機能 |
|---|---|---|
| レベル A: 基本 | クラス 1〜2（好奇心・愛好家）。規制の最低限を満たす | セキュアブート、デバッグ無効化、機器固有鍵、セキュア OTA、TLS |
| レベル B: 標準 | クラス 3（犯罪者）。EU 市場向けの一般的な IoT | 上記 + 分離（TrustZone）、鍵の不可視化、フラッシュ暗号化、認証付きデバッグ |
| レベル C: 高 | クラス 4〜5。決済・重要インフラ・自動車 | 上記 + 物理攻撃対策（DPA / フォールト）、セキュアエレメント、第三者認証 |
レベル A — 必須の最低ライン
これを満たさない製品は、2025 年以降の市場では通用しない。
| # | 要件 | 必要な機能 | 章 |
|---|---|---|---|
| 1 | ファームウェアの完全性 | セキュアブート（ROM ベース）、ROTPK を焼く OTP | 05 |
| 2 | ファームウェアの更新 | A/B 面が取れるフラッシュ容量、署名検証 | 13 |
| 3 | ロールバック防止 | 単調カウンタ（OTP ビットでも可） | 13 |
| 4 | 機器固有の ID と鍵 | TRNG、鍵の保管先、プロビジョニング手段 | 08, 12 |
| 5 | デバッグの遮断 | 読み出し保護 / デバッグ無効化 | 11, 14 |
| 6 | 通信の保護 | TLS が動く RAM/フラッシュ、できれば公開鍵アクセラレータ | 08, 16 |
| 7 | デフォルトパスワードの廃止 | （ソフトウェア設計） | 03 |
| 8 | 脆弱性対応の体制 | （プロセス）SBOM、開示ポリシー | 15 |
フラッシュ容量が最初の関門になることが多い.
\[ \text{必要なフラッシュ} \approx \text{ブートローダ（20〜60 KB）} + \text{アプリケーション} \times 2 + \text{スクラッチ} + \text{データ} \]アプリケーションが 200 KB なら、最低でも 512 KB、実用上は 1 MB 欲しい。 企画段階でここを見誤ると、後で更新機能が入らなくなる。
レベル B — 標準的な IoT 製品
レベル A に加えて:
| # | 要件 | 必要な機能 | 章 |
|---|---|---|---|
| 9 | 脆弱性を突かれても鍵を守る | TrustZone-M（Armv8-M）、周辺と DMA の分離 | 07 |
| 10 | 鍵を CPU に見せない | 鍵ラッピング / KMU / DS ペリフェラル / SE | 06 |
| 11 | 外部フラッシュの保護 | オンザフライ復号（OTFDEC / PRINCE / Flash Encryption） | 06 |
| 12 | RMA 対応 | 認証付きデバッグ、または鍵消去つき RMA 状態 | 11, 14 |
| 13 | ライフサイクル管理 | 不可逆な状態遷移の機構 | 14 |
| 14 | 良質な乱数 | NIST SP 800-90B / AIS 31 準拠の TRNG | 08 |
| 15 | 認証取得の下地 | PSA Certified Level 2 以上を取得したチップ | 03, 17 |
レベル C — 高セキュリティ
レベル B に加えて:
| # | 要件 | 必要な機能 | 章 |
|---|---|---|---|
| 16 | サイドチャネル耐性 | DPA 対策済みの暗号エンジン（ST の SAES など） | 09 |
| 17 | フォールト耐性 | 電圧／クロック／温度／光センサ、冗長化された保護判定 | 10 |
| 18 | 鍵が保存されない | PUF | 06 |
| 19 | 最強の分離 | 独立したセキュリティコア（ELE / HSE / HSM） | 07, 19, 21 |
| 20 | 長期鍵の保護 | セキュアエレメント（CC EAL6+ / AVA_VAN.5） | 22 |
| 21 | 第三者評価 | PSA Certified Level 3 / SESIP 4+ / CC AVA_VAN.4+ | 03 |
2. SoC 選定の実務
評価すべき項目
| カテゴリ | 項目 |
|---|---|
| コア | Armv8-M（TrustZone）か。Armv8.1-M（PACBTI）か |
| メモリ | フラッシュ容量（A/B + ブートローダ + TF-M）、RAM |
| RoT | ROM ベースのセキュアブート。ROTPK のスロット数と失効機構 |
| OTP | 容量。何を焼けるか。読み出し保護の粒度 |
| 鍵の保管 | 鍵ラッピング／PUF／鍵スロット。平文が CPU に出ないか |
| 分離 | TrustZone、周辺の割り当て粒度、DMA の分離 |
| 暗号 | AES（モード）、SHA、公開鍵アクセラレータの性能、DPA 対策 |
| 乱数 | 標準準拠、エントロピーレート、健全性テスト |
| 外部メモリ | オンザフライ復号の有無、完全性の扱い |
| デバッグ | 認証付きデバッグ、権限の粒度 |
| ライフサイクル | 状態の種類、RMA 対応、遷移の認証 |
| プロビジョニング | ベンダの支援（SFI / EdgeLock 2GO / CPMS など） |
| 認証 | PSA Certified のレベル、SESIP、CC |
| ソフトウェア | TF-M / MCUboot の対応、ドキュメントの充実度 |
| サポート | 脆弱性開示ポリシー、セキュリティアドバイザリの発行実績 |
| 供給 | 長期供給の保証（10〜20 年） |
最後の 3 つが、実は最も差が出る.
- ドキュメントが不十分だと、機能があっても使えない
- セキュリティアドバイザリを出さないベンダは、問題を隠している可能性がある
- 供給終了は、長寿命機器にとって致命的
データシートの機能一覧だけでなく、 「そのベンダが過去にどう振る舞ったか」を調べること。
調べ方
- 候補チップの Security Application Note を全部読む → 「機能の一覧」ではなく「どう使うか」が書かれているか
- PSA Certified の Web サイトで認証状況を確認する → Level 1 / 2 / 3 のどれか。証明書の日付
- 公知の攻撃事例を検索する → 「チップ名 + glitch」「チップ名 + fault injection」「チップ名 + CVE」 → 事例があること自体は失格ではない。★ 対応したかを見る
- ベンダのセキュリティアドバイザリのページを見る → 過去の発行実績。対応の速さ。情報の詳しさ
- リファレンス実装を実際にビルドして動かす → ★ これが最も重要。ドキュメントどおりに動くか
5 番目を必ずやること.
「TrustZone 対応」「TF-M 提供」と書かれていても、 実際にビルドすると通らない、サンプルが古い、ドキュメントと合わない ということが起こりうる。
評価ボードで、セキュリティ機能を全部有効にしたサンプルを動かす。 ここで詰まるなら、量産開発ではもっと詰まる。
3. 設計チェックリスト
設計レビュー用チェックリスト
分野を選んで、設計・コードレビューで使える形で確認できる。
企画・アーキテクチャ段階
- ☐ 保護資産を定義したか（完全性／機密性／IP／可用性）（01 章）
- ☐ 想定攻撃者クラスを決めたか（02 章）
- ☐ 信頼境界を図示したか（02 章）
- ☐ STRIDE で脅威を洗い出したか（02 章）
- ☐ 受容するリスクを明記したか（02 章）
- ☐ 販売地域と適用規制を確認したか（03 章）
- ☐ サポート期間を決めたか（CRA・PSTI の要件）（03 章）
- ☐ セキュリティ目標を 1 ページで文書化したか（02 章）
SoC 選定段階
- ☐ セキュアブートの方式と ROTPK のスロット数（05 章・12 章）
- ☐ フラッシュ容量が A/B 面 + ブートローダ + セキュア FW に足りるか（13 章）
- ☐ OTP の容量が、必要な鍵とカウンタに足りるか（06 章・13 章）
- ☐ 単調カウンタの実装先があるか（13 章）
- ☐ 鍵の不可視化機構があるか（06 章）
- ☐ TrustZone または相当の分離があるか（07 章）
- ☐ DMA と周辺の分離ができるか（07 章）
- ☐ TRNG が標準準拠か（08 章）
- ☐ 公開鍵演算の速度が起動時間要件を満たすか（05 章・08 章）
- ☐ 外部フラッシュを使うなら、オンザフライ復号があるか（06 章）
- ☐ 認証付きデバッグがあるか（RMA 対応）（11 章・14 章）
- ☐ PSA Certified / SESIP / CC の取得状況（03 章）
- ☐ 公知の攻撃事例と、その対応状況（10 章）
- ☐ 10〜20 年の供給が見込めるか
鍵とプロビジョニング
- ☐ 機器ごとに違う鍵を使うか（12 章）★最重要
- ☐ 鍵の生成場所を決めたか（チップ内 / HSM / 事前プロビジョニング）（12 章）
- ☐ 工場に平文の鍵を渡さない仕組みがあるか（12 章）
- ☐ オーバービルド対策（発行数のカウント）があるか（12 章）
- ☐ テスト鍵と本番鍵が分離されているか（14 章）
- ☐ 本番の署名鍵は HSM にのみあるか（12 章・14 章）
- ☐ ROTPK が漏れたときの切り替え手段があるか（12 章）
- ☐ デバイス ID が秘密鍵の所持で証明される形か（12 章）
- ☐ 証明書の有効期間が機器寿命と整合しているか（12 章）
実装
- ☐ 署名検証で、公開鍵を OTP のハッシュと照合しているか（05 章）★
- ☐ ヘッダも署名対象に含まれているか（05 章）
- ☐ 検証の分岐がフォールト耐性を持つか（二重検証・冗長値）（10 章）
- ☐ 秘密値の比較が定時間実装か（09 章）
- ☐ RSA-CRT の署名後に検証しているか（10 章）
- ☐ TrustZone の入口でポインタ検証をしているか（07 章）★
- ☐ Secure 側に入力パーサを入れていないか（07 章）
- ☐ 鍵バッファを使用後に zeroize しているか（08 章）
- ☐ AEAD を使い、IV を再利用していないか（08 章）
- ☐ 乱数取得の失敗で止まる設計か（08 章）
- ☐ TLS の証明書検証とホスト名検証が有効か（16 章）★
- ☐ 信頼する CA を自社のものに限定しているか（16 章）
- ☐ ファームウェアに秘密が埋まっていないか（11 章）★
- ☐ デバッグ用コードが量産ビルドから除去されているか（11 章）
- ☐ コンパイラの警告とスタック保護が有効か（15 章）
検証・出荷
- ☐ 量産と同じ設定で全機能を検証したか（14 章）★
- ☐ 不正な証明書を提示して拒否されるか実機で試験したか（16 章）
- ☐ 改ざんしたファームウェアが起動しないか試験したか（05 章）
- ☐ 古いバージョンへのロールバックが拒否されるか試験したか（13 章）
- ☐ CI で
stringsとシークレットスキャンを回しているか（11 章） - ☐ ファジングをプロトコル処理に対して実行したか（15 章）
- ☐ SBOM を生成したか（15 章）
- ☐ 既知の脆弱性がないか確認したか（15 章）
- ☐ LCS を進める工程が量産手順書にあるか（14 章）★
- ☐ 出荷検査で LCS とデバッグ無効化を確認しているか（14 章）
- ☐ eFuse / オプションバイトの最終状態を確認したか（14 章）
- ☐ リカバリ・ISP 経路が無効化されているか（11 章）
運用
- ☐ 脆弱性開示ポリシーと
security.txtを公開したか（15 章） - ☐ ベンダのセキュリティアドバイザリを購読しているか（15 章）
- ☐ SBOM と脆弱性 DB の照合を自動化したか（15 章）
- ☐ OTA の段階的展開ができるか（13 章）
- ☐ 更新の成否を把握できるか（13 章）
- ☐ インシデント報告の体制があるか（CRA は 24 時間）（03 章）
- ☐ サポート終了後の動作を定義したか（14 章）
- ☐ 工場出荷時リセットとクラウド側の紐づけ解除が連動するか（14 章）
4. よくある失敗パターン
| # | 失敗 | 結果 | 対策 |
|---|---|---|---|
| 1 | 全台に同じ鍵 | 1 台の解析で全台が破られる | 機器固有鍵（12 章） |
| 2 | デバッグポートを開けたまま出荷 | ファームウェアと鍵が抜かれる | LCS の遷移を量産手順に（14 章） |
| 3 | TLS の証明書検証を無効化 | 中間者攻撃が成立する | 実機で拒否試験（16 章） |
| 4 | ファームウェアに鍵をハードコード | strings で出る | CI で自動チェック（11 章） |
| 5 | ロールバック防止を実装していない | 修正前の版に戻される | SVN + 単調カウンタ（13 章） |
| 6 | フラッシュ容量が足りず OTA を諦める | 脆弱性が直せない | 企画段階で容量を確保（13 章） |
| 7 | 出荷直前にセキュリティを有効化して動かない | 「今回は無効で出そう」 | 早い段階から常用（14 章） |
| 8 | 署名検証で公開鍵を OTP と照合していない | 攻撃者の鍵で通る | 実装レビュー（05 章） |
| 9 | サンプルコードのテスト鍵をそのまま使用 | 誰でも署名を作れる | 鍵の分離（14 章） |
| 10 | UART に root シェルが出ている | 分解するだけで乗っ取られる | 量産ビルドから除去（11 章） |
| 11 | クラウド側の紐づけ解除を忘れる | 元所有者が新所有者を覗ける | リセット処理の設計（14 章） |
| 12 | 脆弱性情報を追跡していない | 既知の脆弱性を放置。CRA 違反 | SBOM + 自動照合（15 章） |
1〜4 番が圧倒的に多い.
どれも高度な技術を必要としない。 知っていれば防げるものばかりである。
DPA 対策や PUF を検討する前に、この 4 つを潰すこと。
5. 段階的な導入計画
すべてを一度にやろうとすると、何も進まない。
| 段階 | やること | 期間の目安 |
|---|---|---|
| 第 1 歩 | ETSI EN 303 645 の ★1 項目（デフォルトパスワード廃止、報告窓口、攻撃面の削減）（03 章） | 数週間 |
| 第 2 歩 | 出荷前チェックリスト（11 章）を通す。デバッグ遮断、秘密の除去 | 数週間 |
| 第 3 歩 | 機器固有鍵の導入（12 章）。プロビジョニング済み SE を検討 | 1〜3 か月 |
| 第 4 歩 | セキュアブートの導入（05 章）。MCUboot を使う | 2〜4 か月 |
| 第 5 歩 | セキュア OTA（13 章）。ロールバック防止まで | 2〜4 か月 |
| 第 6 歩 | SBOM と脆弱性管理の体制（15 章）。CRA 対応の中核 | 継続 |
| 第 7 歩 | 分離（TrustZone）の導入（07 章）。次の SoC 世代から | 次期製品 |
| 第 8 歩 | 物理攻撃対策（09 章・10 章）。必要な製品のみ | 必要に応じて |
第 1 歩と第 2 歩は、既存製品にも適用できる.
ハードウェアを変えずに、 設定とビルド構成の見直しだけで大きく改善する。
今日から始められるのは、ここである。
6. 姉妹シリーズとの関係
このシリーズは、暗号やスケジューリングの詳細には踏み込んでいない。 より深く知りたい部分は、以下を参照してほしい。
| 内容 | 参照先 |
|---|---|
| 有限体、CRC、RSA、楕円曲線、AES の中身 | 動いて理解する暗号と誤り訂正 |
| RTOS の分離、割り込み、排他制御 | 動いて理解する OS（FreeRTOS） |
| 信号処理 | 動いて理解する DSP |
| 統計・リスク評価の基礎 | 動いて理解する統計学 |
| スマートホーム機器の実装 | 動いて理解する Matter |
7. このシリーズのまとめ
| 部 | 学んだこと |
|---|---|
| I. 前提 | 攻撃者が現物を持てる。守るのは「破られない」ではなく「割に合わない」。規制が要件を決める |
| II. 信頼の基点 | RoT は小さく不変に。セキュアブートは公開鍵の照合が核心。鍵はCPU に見せない。分離で壊れても鍵は守る。乱数が全部の土台 |
| III. 物理攻撃 | DPA は1 バイトずつ独立に破れる。グリッチは数万円でできる。攻撃はファームウェア解析から始まる |
| IV. ライフサイクル | 機器固有鍵が最大の防御。更新できない機器は終わり。時期で開ける穴が違う |
| V. ソフトと通信 | セキュアブートは脆弱なコードを止めない。TLS は正しく使えば安全 |
| VI. 各社の実装 | 独立セキュリティコアへの収束、プリプロビジョニングの普及。どの会社も同じ概念を違う名前で呼んでいる |
最後に、最も重要なことを繰り返す。
高度な対策より先に、基本の穴を全部塞ぐこと。
- 機器ごとに違う鍵を使う
- デバッグポートを閉じる
- ファームウェアに秘密を埋め込まない
- TLS の証明書を検証する
- 更新できるようにする
この 5 つができていない製品に、DPA 対策は必要ない。 攻撃者は、常に最も安い経路を選ぶからである。