Chapter 19
NXP — i.MX RT / LPC / Kinetis / i.MX
この章の位置づけ.
NXP はセキュリティを主要な差別化要素にしているベンダである。
特徴的なのは 2 点。
- PUF を MCU に統合している（06 章）——他社では珍しい
- EdgeLock ブランドで、SoC 内蔵からセキュアエレメントまで一貫して展開している
スマートカード事業と自動車事業の蓄積が、汎用 MCU に降りてきている構図である。
注意: 以下は執筆時点の公開情報に基づく概観である。 必ず対象品種のリファレンスマニュアルと、 NXP のセキュリティアプリケーションノートで確認すること。
この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、ハッシュ（04 章 4 節）、署名検証（04 章 4 節）、eFuse（06 章 2 節）、クローン対策（06 章 6 節）、ヘルパーデータ（06 章 3 節）、リプレイ（06 章 6 節）、温度範囲（06 章 3 節）、起動時間（06 章 3 節）、Crypto（07 章 4 節）、Non-secure（07 章 3 節）、Secure（07 章 3 節）、TrustZone（07 章 2 節）、AES（08 章 8 節）、必要（09 章 6 節）、Espressif（12 章 3 節）、NXP（12 章 3 節）、ライフサイクル状態（12 章 1 節）、ロールバック防止（13 章 1 節）、市場（14 章 5 節）、認証付きデバッグ（14 章 3 節）、量産（14 章 5 節）、開発（14 章 5 節）、要件（15 章 8 節）、フラッシュ（16 章 3 節）、Cortex-M33（17 章 2 節）、RNG（18 章 4 節）
1. NXP のファミリ構成
NXP のセキュリティ機能を調べる
ファミリを選ぶと、そのファミリが持つ機能と、対応する概念が表示される。
| ファミリ | コア | 位置づけ |
|---|---|---|
| Kinetis | Cortex-M0+/M4 | 汎用 MCU（レガシー寄り） |
| LPC5500 (LPC55S6x など) | Cortex-M33 | PUF 搭載。TrustZone 対応 |
| i.MX RT（RT1050/1060/1170、RT500/600） | Cortex-M7 / M33 | クロスオーバー MCU。高性能 |
| i.MX 6/7/8/9 | Cortex-A（+ M） | アプリケーションプロセッサ |
| S32（自動車） | 各種 | HSM 搭載。ISO 21434 対応 |
| MCX（新世代） | Cortex-M33 など | LPC / Kinetis の後継的位置づけ |
2. セキュアブート — HAB と AHAB
NXP のセキュアブートは、世代によって 2 系統ある。
| 名称 | 対象 | 内容 |
|---|---|---|
| HAB（High Assurance Boot） | i.MX 6/7、i.MX RT の一部 | ROM に実装。SRK（Super Root Key）のハッシュを eFuse に焼く |
| AHAB（Advanced HAB） | i.MX 8/9 系 | HAB の後継。コンテナ形式。ELE / EdgeLock secure enclave が処理 |
| ROM ブート認証 | LPC55、MCX | ROM が RoTK（Root of Trust Key）のハッシュで検証 |
HAB の仕組み（05 章との対応）
SRK が 4 個あり、個別に失効できるのが重要である（12 章）。
署名鍵が漏洩したら、その SRK の失効ビットを焼くことで無効化できる。 残りの 3 個で運用を継続できる。
12 章で述べた「ROTPK の複数スロットと失効機構」が、まさにこれである。 選定時に「何個の鍵スロットがあり、失効できるか」を確認すること。
CSF — 柔軟だが複雑
HAB の CSF は「何をどう検証するか」をコマンド列で記述する。
| 長所 | 短所 |
|---|---|
| 複数領域の検証、暗号化、鍵のインストールを柔軟に記述できる | 記述を誤ると保護が抜ける |
| 段階的なブートを表現できる | 学習コストが高い |
CSF の記述ミスによる保護漏れは、実際に報告されている.
「検証対象の領域指定が実際のイメージ範囲をカバーしていない」といった ミスがあると、署名検証を通過しつつ、検証されていない部分を改ざんできる。
NXP のツール（
cst）とドキュメントに従い、 検証範囲がイメージ全体を覆っていることを必ず確認すること。 可能なら、意図的に改ざんしたイメージが弾かれるかを試験する。
3. PUF — NXP の特徴的な機能
LPC55S6x、i.MX RT500/600 などが SRAM PUF を搭載している（06 章）。
| 用語 | 内容 |
|---|---|
| Activation Code (AC) | エンロールメント時に生成されるヘルパーデータ。公開してよい |
| Key Code (KC) | ラップされた鍵。フラッシュに保存できる |
| エンロールメント | 初回に AC を生成する工程。工場で 1 回だけ行う |
PUF の運用上の注意.
- エンロールメントは 1 回きり。やり直せない品種がある
- AC を失うと、鍵が永久に復元できない（バックアップが要る）
- 動作温度範囲全域で安定するか、データシートの条件を確認する
- 起動時間が伸びる（数 ms〜数十 ms）
一方で、得られる利点は大きい。
- 鍵が保存されていない（剥がしても読むものがない）
- 鍵がチップに縛られる（クローン対策）
- OTP を鍵の保管に消費しなくてよい
4. PRINCE / BEE / OTFAD — メモリ暗号化
NXP は、メモリの種類ごとに違う機構を持つ。
| 機構 | 対象 | 内容 |
|---|---|---|
| PRINCE | 内部フラッシュ | 内部フラッシュのオンザフライ暗号／復号（LPC55 など） |
| BEE（Bus Encryption Engine） | 外部フラッシュ | i.MX RT の一部。AES-CTR / ECB |
| OTFAD（On-The-Fly AES Decryption） | 外部フラッシュ | i.MX RT の一部。複数領域に対応 |
| CAAM の Blob | 任意のデータ | 鍵でラップしたデータの保管形式（i.MX） |
「内部フラッシュも暗号化する」PRINCE の意義.
内部フラッシュは外部バスに出ないので、通常は暗号化不要に見える。 だが——
- フラッシュを物理的に読み出す攻撃（クラス 4 以上）には効く
- 読み出し保護がグリッチで破られた場合の第 2 の防壁になる（10 章）
多層防御（defense in depth）の考え方である。 1 つの保護が破られても、次がある。
5. 暗号アクセラレータ
| 機構 | 搭載ファミリ | 内容 |
|---|---|---|
| CAAM（Cryptographic Accelerator and Assurance Module） | i.MX | 対称・ハッシュ・公開鍵（PKHA）・RNG。Black Key / Blob |
| DCP（Data Co-Processor） | i.MX RT の一部 | AES、SHA（軽量版） |
| HASHCRYPT | LPC55 | AES、SHA |
| CASPER | LPC55 | 公開鍵演算のコプロセッサ（ECC / RSA） |
| ELS / PKC | MCX、新しい i.MX RT | EdgeLock Secure Subsystem の暗号エンジン |
| ELE（EdgeLock secure Enclave） | i.MX 8ULP / 93 など | 独立したセキュリティサブシステム |
CAAM の Black Key / Blob
06 章の鍵ラッピングの、NXP における実装である。
これは 06 章で述べた「鍵をチップに縛る」の実装である.
フラッシュをまるごとコピーしても、 別のチップでは Blob を復号できないので動かない。 クローン品対策として有効である。
ELE — EdgeLock secure Enclave
i.MX 8ULP / 93 などが持つ、独立したセキュリティサブシステムである。
| 特徴 | 内容 |
|---|---|
| 専用のコア | メインの Cortex-A / M とは別のプロセッサが動く |
| すべてのセキュリティ機能を集約 | セキュアブート、鍵管理、暗号、ライフサイクル |
| メインコアからは API 経由でのみアクセス | メッセージング単位で分離される |
これは 07 章の「レベル 3: 物理的な分離」に相当する.
TrustZone（同じコアの中の分離）より強い。 メインコアが完全に侵害されても、ELE の内部の鍵には触れない。
Silicon Labs の Secure Element、Infineon の HSM、 TI の HSM コアなども同じ思想である（21 章）。 高セキュリティ品種は、この方向に収束しつつある。
6. Debug Authentication
NXP も認証付きデバッグを提供している（11 章・14 章）。
| 制御できる項目の例 | 内容 |
|---|---|
| デバッグの可否 | 全体／コアごと |
| Secure / Non-secure の別 | 非セキュア側だけ開ける |
| 対象デバイスの限定 | 特定の UUID にのみ有効な証明書を発行できる |
「特定の 1 台にだけ有効なデバッグ証明書」が発行できるのは強力である.
RMA で返ってきた機器 1 台のために証明書を作り、 その証明書が漏れても、他の機器には使えない。
14 章で述べた RMA のジレンマに対する、洗練された解である。
7. ライフサイクル状態
| 状態（LPC55 系の例） | 内容 |
|---|---|
| Blank / NXP Provisioned | 出荷時 |
| Development | 開発中。デバッグ可 |
| Deployed | 量産・市場。デバッグは DC が必要 |
| Returned (RMA) | 返品分析用 |
| Bricked | 恒久的に無効化 |
i.MX の HAB では、eFuse の SEC_CONFIG により 「Open」と「Closed」の 2 状態を持つ（Closed で署名検証が強制される）。
「Closed にし忘れる」が最も多い事故である（14 章）。
HAB は Open 状態でも署名検証を「実行」するが、 失敗しても起動を止めない（イベントログに残るだけ）。
だから開発中は「署名検証が通っているつもり」で進み、 Closed にした途端に起動しなくなる、ということが起きる。
HAB のイベントログ（
hab_status）を開発中から必ず確認すること。 エラーが 0 件であることを確認してから Closed にする。
8. i.MX（Cortex-A）のセキュリティ
Linux が動くアプリケーションプロセッサでは、構成が変わる。
| 層 | 内容 |
|---|---|
| ブート | ROM → SPL/U-Boot → OP-TEE → Linux（各段で署名検証） |
| TEE | OP-TEE が標準的（17 章） |
| セキュアストレージ | CAAM の Blob、または RPMB（eMMC の保護領域） |
| セキュア JTAG | チャレンジ・レスポンス方式のデバッグ保護 |
| TrustZone-A | CSU（Central Security Unit）などで周辺を割り当て |
Linux 系では、鍵の置き場所が難しい.
ファイルシステム上に鍵を置くと、root を取られたら読まれる。
- CAAM の Blob に入れて、必要なときだけ CAAM で使う
- OP-TEE の Secure Storage に入れる
- RPMB（リプレイ保護つき領域）を使う
- 外付けセキュアエレメント（SE050）に入れる（22 章）
13 章のロールバック防止で触れた RPMB は、 単調カウンタの実装先としても有用である。
9. EdgeLock ブランドの全体像
NXP は「EdgeLock」でセキュリティ製品を横断的にブランド化している。
| 製品 | 内容 |
|---|---|
| EdgeLock secure enclave (ELE) | SoC 内蔵のセキュリティサブシステム |
| EdgeLock SE050 / SE051 | 外付けセキュアエレメント（CC EAL6+ 相当を謳う）（22 章） |
| EdgeLock A5000 | セキュア認証用 |
| EdgeLock 2GO | クラウドのプロビジョニング・鍵管理サービス（12 章） |
EdgeLock 2GO が、12 章のプロビジョニング問題への回答である.
- チップに事前プロビジョニングされた鍵と証明書
- クラウドサービスが、機器と各種 IoT プラットフォームの紐づけを管理
- 自社で CA を運用しなくてよい
小〜中規模の製品では、 こうしたサービスを使うほうが、自前で PKI を構築するより安全で安価である。
10. NXP を選ぶときのチェックリスト
| # | 確認項目 |
|---|---|
| 1 | セキュアブートは HAB か AHAB か ROM 認証か（世代で違う）（05 章） |
| 2 | SRK / RoTK のスロット数と失効機構（12 章） |
| 3 | CSF の記述が検証範囲を完全に覆っているか（試験で確認） |
| 4 | PUF を搭載しているか（LPC55、i.MX RT500/600 など）（06 章） |
| 5 | PUF のエンロールメント手順が量産ラインに組み込めるか |
| 6 | PRINCE / BEE / OTFAD のどれが使えるか（06 章） |
| 7 | CAAM / CASPER / ELS の性能は要件を満たすか（08 章） |
| 8 | Debug Authentication に対応しているか（14 章） |
| 9 | ライフサイクル状態の遷移が量産手順に入っているか（14 章） |
| 10 | HAB のイベントログがクリーンか（Closed 化の前に必ず） |
| 11 | TF-M / PSA Certified の対応状況（17 章） |
| 12 | EdgeLock 2GO のようなプロビジョニングサービスを使うか（12 章） |
11. この章のまとめ
| ポイント | 内容 |
|---|---|
| 特徴 | PUF の MCU 統合と、EdgeLock による一貫した製品群 |
| セキュアブート | HAB / AHAB / ROM 認証の 3 系統。世代で違う |
| SRK | 4 個の鍵スロットを個別に失効できる（12 章の要件を満たす） |
| CSF | 柔軟だが記述ミスで保護が抜ける。検証範囲を試験で確認する |
| PUF | 鍵が保存されていない。エンロールメントは 1 回きり。AC のバックアップが要る |
| PRINCE | 内部フラッシュも暗号化する。多層防御の考え方 |
| CAAM の Black Key / Blob | 鍵をチップに縛る。クローン対策 |
| ELE | 独立したセキュリティサブシステム。TrustZone より強い分離 |
| Debug Authentication | 特定の UUID にだけ有効な証明書を発行できる。RMA に最適 |
| HAB の落とし穴 | Open では検証失敗でも起動する。イベントログを開発中から確認する |
| i.MX（Linux） | 鍵は Blob / OP-TEE Secure Storage / RPMB / 外付け SE へ |
| EdgeLock 2GO | 自社で PKI を持たずにプロビジョニングできるサービス |
次章は Espressif を見る。Wi-Fi/BLE 一体型で、まったく違う設計思想を持つ。