Chapter 12

デバイス認証と証明書 — DAC / PAI / PAA / CD / DCL

この章がなぜ必要なのか——ここが製品化で最初にぶつかる壁だから.
「サンプルは動いた。さあ製品にしよう」となったとき、 証明書をどう調達し、どう量産ラインで書き込むかという問題が立ちはだかる。
これは技術の問題であると同時に、調達・契約・製造プロセスの問題でもある。リードタイムも長い。開発の最後に考え始めると必ず間に合わない。
この章では証明書の構造と、実務での選択肢を整理する。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、コミッショニング（01 章 3 節）、セキュリティ（01 章 2 節）、ネットワーク（01 章 3 節）、相互運用性（01 章 2 節）、mDNS（03 章 4 節）、BLE（05 章 1 節）、必要（05 章 5 節）、Info（10 章 5 節）、署名（11 章 2 節）、証明書（11 章 5 節）、追跡（11 章 1 節）

1. なぜデバイス認証が必要なのか

偽造品を排除するためである.
Matter がなければ、誰でも「Matter 対応」を名乗る機器を作れてしまう。認証を受けていない機器が相互運用性を壊し、セキュリティの穴を持ち込み、標準全体の信頼を損なう。
Matter は暗号学的に「これは認証を受けた正規品である」ことを検証する。コミッショニング時にコントローラが確認し、検証に失敗した機器は（エコシステムの方針により）拒否されるか、警告が出る。

2. 証明書チェーンの構造

PAA（Product Attestation Authority）
  │  ・業界のルート CA
  │  ・DCL（分散台帳）に登録されている
  │  ・CSA 自身、またはメーカーが運営
  ↓
PAI（Product Attestation Intermediate）
  │  ・メーカー（または製品ライン）ごとの中間 CA
  │  ・VID を含む（PID を含むこともある）
  ↓
DAC（Device Attestation Certificate）
     ・個体ごとに 1 枚
     ・VID / PID を含む
     ・対応する秘密鍵が機器の中にある

証明書	個数	保管場所
PAA	業界に数十枚	DCL に公開
PAI	メーカーごとに数枚	機器にも格納（チェーン検証用）
DAC	1 個体につき 1 枚	機器に格納

すべて X.509 v3、ECDSA P-256、SHA-256 である。

証明書に含まれる Matter 固有の情報

DAC / PAI の Subject には、Matter 独自の属性が入る。

OID の意味	内容
`matter-vid`	Vendor ID
`matter-pid`	Product ID

VID は必ず含まれる。PID は PAI では省略可能である。 検証時には、DAC の VID/PID が CD（次節）に記載された VID/PID と一致することが確認される。

3. CD（Certification Declaration）

「この VID/PID の製品は CSA の認証を受けている」という CSA の署名付き宣言。

項目	内容
形式	CMS（Cryptographic Message Syntax）署名
署名者	CSA（の認証鍵）
含まれるもの	VID、PID のリスト、認証タイプ、証明書 ID、セキュリティレベル、デバイスタイプなど
保管場所	機器に格納（DAC と一緒に工場で書き込む）

DAC と CD の役割の違いが分かりにくいので整理する.
DAC CD
誰が発行 メーカー（の PAI） CSA
何を言っている「この個体は私が作った本物だ」「この製品モデルは認証を通っている」
個体ごとに違うはいいいえ（モデル共通）
秘密鍵とペアはいいいえ（署名の検証だけ）
両方揃って初めて「認証を受けた正規品の個体」が証明される。 DAC だけなら「メーカーが作った」ことしか言えないし、 CD だけなら「そのモデルは認証済み」だが個体の真正性は分からない。

	DAC	CD
誰が発行	メーカー（の PAI）	CSA
何を言っている	「この個体は私が作った本物だ」	「この製品モデルは認証を通っている」
個体ごとに違う	はい	いいえ（モデル共通）
秘密鍵とペア	はい	いいえ（署名の検証だけ）

4. DCL（Distributed Compliance Ledger）

CSA が運営する分散台帳。ブロックチェーン技術を使っている。

登録されるもの	内容
PAA 証明書	信頼すべきルート CA の一覧
モデル情報	VID/PID、製品名、メーカー、製品 URL
コンプライアンス情報	認証日、認証されたバージョン、ソフトウェアバージョン範囲
OTA 情報	ファームウェアの配布 URL（任意）

コントローラは DCL から PAA のリストを取得する. 「どの PAA を信頼するか」を自分で判断せず、DCL を信頼の起点にする。
ただし実運用では、エコシステムが独自にキャッシュ・管理していることが多い。 DCL に登録された直後は、各エコシステムに反映されるまで時間がかかることがある。 認証取得から実際に各社ハブで動くまでのラグは製品計画で考慮すべき点である。

5. 検証のフロー

コミッショニング中、コントローラは次を行う（13 章の一部）。

1. コントローラ → 機器: AttestationRequest（32 byte のノンス）
2. 機器 → コントローラ: AttestationResponse
       ├── attestation_elements（CD、ノンス、タイムスタンプなどを TLV で束ねたもの）
       └── attestation_signature（DAC の秘密鍵で署名）
3. コントローラ → 機器: CertificateChainRequest(DAC)
4. 機器 → コントローラ: DAC
5. コントローラ → 機器: CertificateChainRequest(PAI)
6. 機器 → コントローラ: PAI

コントローラ側の検証:
  a. DAC ← PAI ← PAA のチェーンを検証（PAA は DCL から取得）
  b. attestation_signature を DAC の公開鍵で検証
  c. ノンスが自分の送ったものと一致するか（リプレイ防止）
  d. CD の CSA 署名を検証
  e. CD の VID/PID と DAC の VID/PID が一致するか
  f. Basic Information の VID/PID とも一致するか

ノンスが要る理由. ノンスがなければ、正規品から一度取った署名を偽造品が使い回せる。 毎回違うノンスに署名させることで、鍵を実際に持っていることを証明させる。
e と f の照合が偽造対策の要である. DAC を他社製品から流用しても、CD や Basic Information の VID/PID と食い違えば弾かれる。

6. 証明書の調達 — 実務の選択肢

ここが製品化の分岐点である。

(a) CSA の PAA を使う（多くのメーカーの選択）

CSA の PAA
 └── 自社の PAI（CSA から発行してもらう、または CSA 認定の PKI ベンダー経由）
      └── DAC（自社または委託先が個体ごとに発行）

利点	欠点
PAA を自分で運営しなくてよい	発行プロセスに時間がかかる
DCL への登録が確実	外部への依存

(b) 自社 PAA を運営する

大手メーカーが自社ルートを DCL に登録する方式。

利点	欠点
発行を完全に自社で制御	PKI の運営責任を全部負う
大量生産で有利	ルート鍵の管理（HSM 必須）

(c) PKI ベンダーに委託

証明書サービスを提供するベンダー（半導体メーカー系、セキュリティベンダー系）を使う。

利点	欠点
鍵の生成・保管・注入まで一括	コスト
セキュアエレメントとセットで提供されることも	ベンダーロックイン

半導体メーカーの提供するサービスが有力な選択肢である. 一部の SoC ベンダーは、チップに DAC を事前注入して出荷するサービスを提供している。これを使えば、量産ラインでの鍵注入設備が不要になる。
ただし VID は自社のものを使う必要があるので、 事前に CSA から VID を取得しておく（22 章）。

7. 量産ラインでの書き込み

DAC・PAI・CD・鍵を、個体ごとに製造時に書き込む必要がある。

書き込む内容（Factory Data）

項目	個体ごとに違うか
DAC 証明書	○
DAC 秘密鍵	○
PAI 証明書	×（製品共通）
CD	×（製品共通）
Discriminator	○（ランダム推奨）
SPAKE2+ 検証子（w0, L）	○
SPAKE2+ の salt / iteration count	○（salt は個体ごと）
VID / PID	×
シリアル番号 / UniqueID	○
Rotating Device ID の鍵	○

課題

課題	内容
鍵の生成場所	機器内で生成するか、外で作って注入するか
注入の秘匿	製造ラインのネットワークで鍵が流れる
委託製造	EMS に鍵を渡すことの是非
速度	1 個あたりの書き込み時間 × 生産数
トレーサビリティ	どの個体にどの証明書を入れたかの記録

最も安全なのは「機器内で鍵を生成し、公開鍵だけを外に出して CSR で署名してもらう」方式である. 秘密鍵が一度もチップの外に出ない。セキュアエレメントを使えばこれが自然に実現できる。
ただし製造ラインがオンラインで CA と通信する必要があるため、工場のネットワーク設計が絡む。
オフラインで事前生成した鍵を注入する方式の方が製造は簡単だが、鍵の受け渡し経路をどう守るかという問題が残る。 どちらを取るかは、製品のセキュリティ要件とコストで決める。

8. 開発用のテスト証明書

開発中は、SDK に含まれるテスト用の証明書を使う。

項目	値
テスト VID	`0xFFF1`〜`0xFFF4`
テスト PID	`0x8000` 番台など
テスト PAA	SDK に同梱
デフォルト passcode	`20202021`
デフォルト discriminator	`3840`

# chip-tool でテスト PAA を信頼する（開発時）
chip-tool pairing onnetwork 1 20202021 --paa-trust-store-path ./credentials/development/paa-root-certs

これを製品に載せてはいけない. テスト VID の機器は、各エコシステムから拒否されるか、「認証されていない機器」として警告付きで扱われる。
しかも全開発者が同じ鍵を使っているので、セキュリティは皆無である。
量産ビルドとテストビルドを、ビルドシステムのレベルで確実に分けること。 「うっかりテスト証明書で量産した」という事故は起こりうる。

9. Rotating Device Identifier

機器を識別しつつ、追跡を防ぐための仕組み。

RDI = 上位バイト（カウンタ）+ SHA-256(カウンタ ‖ 一意な機器情報) の一部

一定条件で値が変わる
同じ機器だと知っている者（一度ペアリングした相手）だけが同一性を確認できる
通りすがりの第三者には、毎回違う機器に見える

なぜ必要か. 常に同じ ID を BLE や mDNS で広告していると、店舗や公共の場でその機器（≒持ち主）を追跡できてしまう。スマートフォンの MAC アドレスランダム化と同じ発想である。

10. 落とし穴

落とし穴	内容・対処
証明書の調達を最後に考える	リードタイムが長い。開発初期に着手する
テスト証明書で量産	ビルドを分ける。CI でチェックする
全個体で同じ DAC	1 個の解析で全製品が偽造可能になる
DAC 秘密鍵を平文フラッシュに置く	SE か暗号化領域を使う
CD の VID/PID と DAC が不一致	検証で弾かれる。発行時に照合する
Basic Information の VID/PID が不一致	同上
証明書の有効期限	Matter の運用証明書は無期限（`9999-12-31`）とすることが多い。DAC も慎重に設計
フラッシュ容量の見積り漏れ	証明書は数百バイト〜。チェーン全部で 1〜2 KB 程度
DCL 登録の遅れ	認証取得後、各エコシステムに反映されるまでのラグを見込む

有効期限は要注意である. 家電は 10 年使われる。証明書が 5 年で切れたら、その時点で機器が使えなくなる可能性がある。 Matter の運用証明書では「無期限」を表す特別な値を使うのが一般的である。 DAC の有効期限をどう設定するかは、製品寿命と合わせて設計すること。

11. まとめ

デバイス認証の目的は偽造品の排除。暗号学的に「認証済みの正規品」を検証する。
チェーンは PAA → PAI → DAC。すべて X.509 / ECDSA P-256。
DAC（メーカー発行、個体ごと）と CD（CSA 発行、モデル共通）は役割が違う。 両方揃って初めて証明が成立する。
DCL が PAA と製品情報の公開台帳。コントローラの信頼の起点。
検証ではノンスへの署名と、CD / DAC / Basic Information の VID/PID 一致を確認する。
証明書の調達方式（CSA の PAA / 自社 PAA / PKI ベンダー）は製品化の重要な判断。 リードタイムが長いので早期に着手する。
量産では Factory Data の書き込み設計（鍵の生成場所・注入経路・記録）が必須。
テスト証明書（VID 0xFFF1 等）を製品に載せない。ビルドを分けて仕組みで防ぐ。