Chapter 12

デバイス ID とプロビジョニング

この章がなぜ必要なのか——「機器ごとに違う鍵」が最大の防御だから.

02 章で見たとおり、クラス 3（金銭目的の犯罪者）は規模を求める。 「1 台破ると全台破れる」構造があるときにだけ、攻撃は経済的に成立する。

機器ごとに違う鍵を使えば、その経済性が崩壊する。

だが実務では——「工場でどうやって鍵を入れるか」が、 組み込みセキュリティで最も難しい部分である。

この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、ハッシュ（04 章 4 節）、CSR（06 章 7 節）、容易（06 章 1 節）、鍵ラッピング（06 章 4 節）、Secure（07 章 3 節）、TRNG（08 章 8 節）、必要（09 章 6 節）

1. 何を入れるのか

このうち「最重要の秘密」を、どうやって安全に入れるかが本章の主題である。

2. 3 つの方式

プロビジョニング方式を比較する

方式を選ぶと、秘密鍵がどこを通り、誰が知りうるかが表示される。

方式 A: 外部で生成して注入する

「工場を信頼できるか」という問題が核心である.

製造を海外の EMS に委託する場合、 「秘密鍵の入ったファイルを渡す」ことになりかねない。

• 従業員が持ち出せる
• 過剰生産（オーバービルド）に使われる
• 書き込み装置のログに残る

だから多くのベンダが、工場に平文の鍵を渡さずに済む仕組みを提供している（本章 4 節）。

方式 B: 機器の中で生成する（推奨）

機器は内部で鍵ペアを生成し、公開鍵に機器情報を添えた「証明書にしてください」という依頼書 ——CSR（Certificate Signing Request・証明書署名要求）——を出力する。 CA は CSR を検証して証明書を発行する。秘密鍵は最初から最後まで機器の中にある。

これが理想である。可能なら常にこちらを選ぶ。

ただし注意点がある。

• 鍵生成時のエントロピーが十分か（08 章の起動直後の問題）
• CSR を送る相手が本物の CA か（工場の装置がなりすませないか）
• 「どの CSR が正規の機器から来たか」をどう保証するか

最後の点が重要で、これは次節の「事前プロビジョニング済みチップ」で解決できる。

方式 C: 事前プロビジョニング済みチップを買う

小〜中規模の製品には、これが最も現実的な解である.

自社で HSM を用意して、CA を運用して、工場の書き込み装置を保護して…… という体制を作るのは非常に高くつく。

「セキュアエレメントを 1 個載せて、プロビジョニング済み品を買う」なら、 BOM に数十〜数百円足すだけで済む。22 章で詳しく扱う。

3. 工場側の保護

方式 A を選ばざるを得ない場合、工場側の設計が重要になる。

「発行数のカウント」が、オーバービルド対策の核心である.

契約が 10,000 台なら、HSM は 10,000 個しか鍵を発行しない。 委託先が 12,000 台作っても、2,000 台は鍵が入らず、クラウドに接続できない。

これは技術で商業リスクを制御する良い例である。

セキュアプロビジョニングの支援機能

各社が「工場に平文を渡さない」ための仕組みを持っている。

ST の SFI の考え方（代表例として）:

この仕組みの美点は「工場を信頼しなくてよい」ことである.

委託先が悪意を持っていても、

• ファームウェアの中身は見られない（IP 保護）
• 契約数以上作れない（オーバービルド対策）
• 鍵を抜き取れない

信頼の必要な範囲（TCB）を、工場から HSM カードへ縮めている。

4. デバイス ID の設計

何を ID にするか

決定的な点: ID は「秘密鍵を持っていること」で証明されなければならない.

「UID が一致したら本物」という認証は、まったく意味がない。 UID は誰でも読めて、誰でも名乗れる。

正しい構成:

• デバイス ID = 証明書のサブジェクト（またはその公開鍵のハッシュ）
• 認証 = TLS クライアント認証（秘密鍵で署名できることを示す）

これなら、秘密鍵を持たない者は ID を主張できない。

証明書チェーンの設計

証明書を発行・管理・失効させる体制の全体を PKI（Public Key Infrastructure・公開鍵基盤）と呼ぶ。 その階層をどう切るかが、ここでの設計になる。

証明書の有効期間は難しい判断である.

• 短くする（1〜2 年） → 更新の仕組みが必要。ネットワーク断で更新できないと文鎮化
• 長くする（20 年） → 更新不要だが、鍵が漏れたときの影響が長期化。 アルゴリズムが陳腐化する

実務的には、「長期の製造証明書（出生証明書）」と 「短期の運用証明書」を分ける構成がよく使われる。

これは AWS IoT の「Just-in-Time Provisioning / Registration」や Azure IoT の DPS（Device Provisioning Service）の考え方と同じである。

5. ゼロタッチプロビジョニング

「箱から出して電源を入れるだけで、安全にクラウドに繋がる」を実現する仕組み。

ユーザ体験とセキュリティが両立する良い例である.

「設定画面でパスワードを入力させる」より、 証明書ベースのゼロタッチのほうが安全で、しかも簡単である。

ETSI EN 303 645 の規定 12「導入・保守を容易にする」にも合致する。

6. 全台共通鍵の何が問題か

改めて明確にしておく。

経済モデルが完全に変わる.

攻撃の期待利益を \(V\)（1 台あたりの価値）、攻撃コストを \(C\)、 出荷台数を \(N\) とすると——

方式	攻撃者の損得
全台共通鍵	利益 \(N \cdot V\) − コスト \(C\) → N が大きいほど儲かる
機器固有鍵	利益 \(V\) − コスト \(C\) → 1 台の価値がコストを超えないと成立しない

これが、あらゆるセキュリティ対策の中で最も費用対効果が高い設計判断である。 ハードウェアを変えずに、プロビジョニングの設計だけで実現できる。

「共通鍵」がやむを得ない場合

署名検証鍵が共通なのは問題ない、という点は重要である.

公開鍵は公開情報である。漏れても攻撃に使えない。 危険なのは「署名する側の秘密鍵」であり、これは工場にも機器にも置かない （CI/CD の HSM に置く）。

7. 鍵の更新と失効

ROTPK の切り替え

セキュアブートの検証鍵が漏れたら、どうするか。

設計時に「鍵が漏れたらどうするか」を決めておくこと.

ROTPK スロットが 1 個しかない SoC を選ぶと、 署名鍵が漏れた時点で、出荷済み全台が回収対象になる。

複数スロットと失効機構があるかは、選定基準に入れるべきである。 20 章（Espressif）と 19 章（NXP）で具体的に見る。

8. この章のまとめ

次章では、その鍵と証明書を使って行う—— セキュアな OTA 更新を扱う。