Chapter 14
ライフサイクル状態と廃棄
この章がなぜ必要なのか——「開発中は開けたい、量産では閉じたい」という矛盾.
デバッグポートは、開発中には必須である。だが出荷時には閉じなければならない。 鍵は、量産時には書き込む必要がある。だが運用中は書き換えられては困る。
時期によって、開けるべき穴が違う。 この切り替えを安全に行うのが、ライフサイクル状態管理（LCS）である。
そして最後に——廃棄と所有権移転という、最も忘れられる問題がある。
この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、物理攻撃（04 章 6 節）、eFuse（06 章 2 節）、不可（06 章 1 節）、Secure（07 章 3 節）、TrustZone（07 章 2 節）、必要（09 章 6 節）、フラッシュ暗号化（11 章 5 節）、Renesas（12 章 3 節）、ライフサイクル状態（12 章 1 節）
1. ライフサイクル状態とは
チップの「今どの段階か」を、不可逆に進む状態として持つ。
| 性質 | 内容 |
|---|---|
| 不可逆 | 一度進めたら戻せない（OTP に記録される） |
| 状態ごとに権限が違う | デバッグ、鍵の読み書き、フラッシュの消去などが状態で決まる |
| ハードウェアで強制される | ソフトウェアの分岐ではなく、回路で制御される（望ましい） |
ライフサイクル状態を遷移させる
各状態で何ができ、何ができなくなるかを確かめられる。
2. 各社の実装
名前は違うが、考え方はほぼ同じである。
| ベンダ | 状態の呼び名 | 章 |
|---|---|---|
| Arm PSA | Assembly & Test → PSA RoT Provisioning → Secured → Non-PSA RoT Debug → Recoverable PSA RoT Debug → Decommissioned | 17 |
| ST（STM32H5 など） | OPEN → PROVISIONING → IROT_PROVISIONED → TZ_CLOSED → CLOSED → LOCKED | 18 |
| ST（従来の RDP） | RDP Level 0 → Level 1 → Level 2 | 18 |
| NXP（LPC55 など） | Blank → Development → Deployed → Returned → Bricked | 19 |
| Renesas RA（DLM） | CM → SSD → NSECSD → DPL → LCK_DBG → LCK_BOOT → RMA_REQ → RMA_ACK | 21 |
| TI | GP → HS-FS（Field Securable）→ HS-SE（Security Enforced） | 21 |
| Espressif | eFuse のビット群で表現（明示的な「状態」名はない） | 20 |
| Silicon Labs | Secure Boot / Secure Debug の設定と Tamper 設定の組み合わせ | 21 |
Renesas の DLM（Device Lifecycle Management、21 章）は、状態の設計が特に丁寧なので参考になる.
状態 意味 CM (Chip Manufacturing) ルネサス工場出荷時 SSD (Secure Software Development) セキュア領域の開発中。全デバッグ可 NSECSD (Non-Secure Software Development) 非セキュア側だけデバッグ可。セキュア側は保護される DPL (Deployed) 市場投入。デバッグ不可 LCK_DBG デバッグを恒久的にロック LCK_BOOT ブートインタフェースも恒久ロック RMA_REQ / RMA_ACK 返品分析用。鍵を消去してからデバッグを開ける NSECSD の存在が実用的である。 セキュリティ部分の開発が終わったら NSECSD に進めれば、 アプリ開発チームはデバッグを続けられるのに、鍵は保護される。
RMA の状態も重要である。 次節で扱う。
3. RMA — 「返ってきた機器をどう調べるか」
これが実務で最も悩ましい問題である。
3 つの解法
| 解法 | 内容 | 評価 |
|---|---|---|
| 解析を諦める | 完全ロックする。返品は廃棄する | 安全だが、品質改善ができない |
| 認証付きデバッグ | メーカーの鍵でだけ開けられる（11 章） | 最も望ましい |
| RMA 状態への遷移 | 鍵を消去してからデバッグを開ける | 実用的。多くのベンダが対応 |
RMA 状態の仕組み
「消してから開ける」という順序が肝である.
- 機密は守られる（消えているから）
- 解析はできる（コードとハードウェアの状態は見られる）
- 不可逆なので、攻撃者がこの手順を使っても得るものがない
ただし——「鍵が消えた後の機器」では、 鍵が絡む不具合の解析はできない。トレードオフである。
認証付きデバッグとの組み合わせ
理想的には、次の 2 段階を用意する。
| レベル | 開ける条件 | 消去 |
|---|---|---|
| 限定デバッグ | メーカーの鍵で認証 | 消去しない。鍵絡みの不具合も解析できる |
| フルデバッグ | メーカーの鍵で認証 | 鍵を消去してから開く |
Arm の ADAC（Authenticated Debug Access Control）は、 証明書に権限を記述することで、こうした段階的な制御を可能にしている。
4. 状態遷移の安全性
状態を進める処理そのものが攻撃対象になる。
| 攻撃 | 内容 | 対策 |
|---|---|---|
| 遷移を飛ばす | 「Production に進める」処理をグリッチで飛ばし、開いたままにする | 冗長チェック（10 章）、ハードウェアラッチ |
| 状態を偽装する | 状態レジスタを書き換える | OTP に記録し、起動時にハードウェアが読む |
| 戻す | 不可逆のはずの状態を戻す | OTP のビットは物理的に戻せない設計にする |
| 中断させる | 遷移の途中で電源を切る | 中間状態でも安全側に倒れる設計 |
「出荷時に状態を進め忘れる」が最も多い事故である.
量産ラインの手順書に「LCS を Production にする」が入っていないと、 全数が開いたまま出荷される。
対策:
- 書き込み装置の最後の工程で必ず実行する
- 出荷検査で LCS を読んで確認する（読めるようになっている品種が多い）
- 抜き取り検査でデバッガを繋いでみる
これは技術ではなくプロセスの問題だが、実際に頻発している。
5. 開発と量産の切り分け
| 段階 | デバッグ | 鍵 | ファームウェア |
|---|---|---|---|
| 開発 | 全部開く | テスト鍵（本番鍵は絶対に使わない） | デバッグビルド |
| 検証 | 開く | テスト鍵 | 量産と同じビルド（デバッグ機能なし） |
| 量産 | 閉じる | 本番鍵 | 量産ビルド |
| 市場 | 閉じる | 本番鍵 | 量産ビルド |
「テスト鍵と本番鍵を分ける」は絶対の原則である.
テスト鍵は開発者全員の PC にあり、CI にあり、時にはリポジトリにある。 これが本番に使われたら終わりである。
対策:
- 本番鍵は HSM にのみ置く。人間が値を見られない
- 署名は CI の専用ジョブでのみ行う。承認プロセスを通す
- テスト鍵で署名したイメージは、本番の LCS では起動できない設計にする （ROTPK が違うので自動的にそうなる）
最後の点が重要で、LCS と鍵を連動させると、間違いが物理的に起きなくなる。
検証段階の重要性
セキュリティ機能を有効にすると、動かなくなることは頻繁にある。
| 有効にすると壊れがちなもの | 理由 |
|---|---|
| TrustZone | メモリ配置・周辺の割り当てミス |
| フラッシュ暗号化 | XIP のアドレス、ブート時間の増加 |
| セキュアブート | 署名の付け忘れ、イメージ形式の不整合 |
| デバッグ無効化 | 「ログが出ないと分からない」ことに気づく |
| 読み出し保護 | 書き込みツールが動かなくなる |
「セキュリティを有効にした状態」を、開発の早い段階から常用すること.
出荷直前に有効化すると、必ず問題が出て、 「時間がないから今回は無効のままで」という最悪の判断につながる。
6. 廃棄と所有権移転
最も忘れられる領域である。 だが規制は明確に要求している。
| 規制 | 要求 |
|---|---|
| ETSI EN 303 645 規定 11 | ユーザが個人データを削除できること |
| GDPR | 削除権（忘れられる権利） |
| CRA | セキュアなデフォルトと、データ保護 |
消すべきもの
| 対象 | 内容 |
|---|---|
| ユーザデータ | 設定、履歴、映像、音声、位置情報 |
| 認証情報 | Wi-Fi パスワード、クラウドのトークン、ペアリング情報 |
| 機器固有鍵（場合による） | 所有権移転なら残す、廃棄なら消す |
| ログ | 動作履歴、ネットワークの痕跡 |
3 つのシナリオ
| シナリオ | やること |
|---|---|
| 工場出荷時リセット | ユーザデータと認証情報を消す。機器固有鍵は残す（再セットアップできるように） |
| 所有権移転（中古売却） | 上に加えて、クラウド側の紐づけも解除する |
| 廃棄 | すべて消す。機器固有鍵も含む |
「クラウド側の紐づけ解除」が抜けがちである.
機器をリセットしても、クラウド上では元の所有者のアカウントに紐づいたまま、 ということが起きる。すると——
- 新しい所有者が登録できない
- 元の所有者が、新しい所有者の機器を見られる（重大なプライバシー侵害）
機器側のリセットと、クラウド側の解除を連動させる設計が必要である。 ETSI EN 303 645 の規定 11 でも、この点が触れられている。
確実に消す
| 手法 | 内容 | 注意 |
|---|---|---|
| 上書き | 0 やランダム値で上書きする | フラッシュのウェアレベリングで残ることがある |
| 暗号消去 (Crypto Erase) | データを暗号化しておき、鍵だけを消す | 最も確実で速い |
| フラッシュの消去コマンド | ブロック消去 | 予備ブロックに残ることがある |
| タンパー時の即時消去 | ハードウェア機能 | 物理攻撃への対策も兼ねる |
暗号消去（Crypto Erase）が最も優れている.
所有権移転・廃棄・工場出荷リセットのすべてで使える。設計段階から「全部暗号化」にしておくことが条件
- 速い（数バイト消すだけ。数 GB のデータでも一瞬）
- 確実（ウェアレベリングで残ったブロックも復号できない）
- 検証しやすい
これは SSD の「Secure Erase」や、 スマートフォンのファクトリーリセットで使われている手法と同じである。
設計の初期段階で「データは常に暗号化して保存する」と決めておくこと。 後から追加するのは難しい。
7. 経年と保守
長寿命機器（01 章）では、時間そのものが問題になる。
| 問題 | 内容 | 対策 |
|---|---|---|
| 証明書の期限切れ | 機器の証明書、サーバの証明書、CA 証明書 | 更新の仕組み、期間の設計（12 章） |
| 暗号の陳腐化 | SHA-1、RSA-1024、TLS 1.0 が使えなくなる | 暗号アジリティ（04 章） |
| 時刻同期の喪失 | NTP サーバの停止、RTC の電池切れ | 複数の時刻源、証明書検証の設計 |
| クラウドサービスの終了 | メーカーがサービスを止める | ローカル動作へのフォールバック |
| PUF の劣化 | ビット反転率が上がる（06 章） | 誤り訂正の余裕、定期的な再エンロール |
| フラッシュの劣化 | データ保持期間（高温では短い） | リフレッシュ、ECC |
「サービス終了後の機器」は、規制の観点でも問題になりつつある.
メーカーがクラウドを止めると、機器が文鎮化する。 消費者保護の観点から、 「サービス終了後もローカルで動くこと」を求める動きがある。
03 章の PSTI・CRA の「サポート期間の明示」も、この文脈にある。 設計時に「クラウドがなくなったらどう動くか」を決めておくこと。
8. ライフサイクル設計のチェックリスト
| # | 項目 |
|---|---|
| 1 | LCS の遷移が量産手順書に明記されているか |
| 2 | 出荷検査で LCS を確認しているか |
| 3 | テスト鍵と本番鍵が分離されているか |
| 4 | 本番鍵は HSM にのみあるか（人が値を見られないか） |
| 5 | 量産と同じ設定で全機能の検証をしているか |
| 6 | RMA の手順が決まっているか（認証付きデバッグ or RMA 状態） |
| 7 | 工場出荷時リセットで、消すものと残すものが定義されているか |
| 8 | クラウド側の紐づけ解除が連動しているか |
| 9 | ユーザデータが暗号化されて保存されているか（暗号消去のため） |
| 10 | サポート終了後の動作が定義されているか |
| 11 | 証明書の有効期限が機器寿命と整合しているか |
| 12 | LCS の遷移処理がフォールト耐性を持つか（10 章） |
9. この章のまとめ
| ポイント | 内容 |
|---|---|
| LCS の役割 | 時期によって開けるべき穴が違う。それを不可逆な状態で管理する |
| 実装 | ベンダごとに名前が違うが、考え方はほぼ同じ |
| Renesas DLM の NSECSD | 非セキュア側だけデバッグ可。実用的な中間状態 |
| RMA のジレンマ | 完全ロックすると故障解析できない |
| RMA の解法 | 認証付きデバッグ、または鍵を消してから開けるRMA 状態 |
| 最多の事故 | 出荷時に LCS を進め忘れる。プロセスで防ぐ |
| 鍵の分離 | テスト鍵と本番鍵を絶対に分ける。本番鍵は HSM のみ |
| 検証 | 量産と同じ設定で全機能を検証する。早い段階から常用する |
| 廃棄 | ユーザデータ・認証情報・鍵。シナリオごとに消すものが違う |
| クラウド連動 | 紐づけ解除を忘れると、元所有者が新所有者を覗ける |
| 確実な消去 | 暗号消去（鍵だけ消す）が最も速く確実。設計初期に決めておく |
| 経年 | 証明書期限・暗号の陳腐化・サービス終了後の動作 |
ここまでで第 IV 部は終わりである。 次章から第 V 部——ソフトウェアと通信のセキュリティに入る。