Chapter 11
セキュリティの全体像 — 何を、誰から守るのか
この章がなぜ必要なのか——Matter のセキュリティは「後から足せない」.
Matter では、暗号化されていない通信は存在しない。 「開発中だけ平文で」というオプションはない（テスト用の緩和はあるが、本質は変わらない）。
そして仕様の複雑さの多くは、セキュリティ要件から来ている。 「なぜ証明書が 3 段もあるのか」「なぜコミッショニングが 10 ステップもあるのか」—— 脅威モデルを知れば、すべて必然だと分かる。
この章は 12 章〜14 章（証明書・コミッショニング・運用時）の前提を整える。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、コミッショニング（01 章 3 節）、セキュリティ（01 章 2 節）、ネットワーク（01 章 3 節）、ACL（02 章 4 節）、Node（02 章 2 節）、マルチキャスト（03 章 3 節）、Wi-Fi（04 章 9 節）、必要（05 章 5 節）、Session（06 章 5 節）、再送（06 章 3 節）、運用時（06 章 4 節）、Fabric-Scoped（07 章 7 節）
1. 脅威モデル — 何を想定しているか
| 脅威 | 具体例 | Matter の対策 |
|---|---|---|
| 盗聴 | 家庭内の通信を傍受される | 全通信を AES-CCM で暗号化 |
| 改竄 | コマンドを書き換えられる | 認証付き暗号（MIC） |
| なりすまし（機器） | 偽の電球が正規品を装う | DAC による機器認証（12 章） |
| なりすまし（管理者） | 第三者が勝手に操作する | CASE + ACL（14 章） |
| リプレイ攻撃 | 過去のコマンドを再送される | メッセージカウンタ |
| 遅延実行 | 保留したコマンドを後で流す | Timed Interaction（09 章） |
| 不正な参加 | 勝手にネットワークに入られる | パスコードによる PASE（13 章） |
| 総当たり | パスコードを推測される | SPAKE2+ と試行回数制限 |
| 追跡 | 機器の存在を追跡される | Rotating Device ID、Privacy 拡張 |
| Fabric 間の情報漏れ | 他エコシステムの設定を覗く | Fabric-Scoped / Sensitive（07 章） |
| サプライチェーン | 偽造品の流通 | DAC + CD + DCL（12 章） |
想定していないもの（あるいは限界がある領域）:
- 物理的な分解。基板を剥がして鍵を吸い出す攻撃には、 SoC のセキュアエレメント／セキュアブートで対抗する。仕様の外である。
- 正規の管理者による濫用。Fabric の管理者は正当な権限を持つ。
- ユーザーが QR コードを他人に見せてしまうこと。
2. 使われている暗号プリミティブ
Matter は枯れた標準的なものだけを使う。独自の暗号は一切ない。
| 用途 | アルゴリズム |
|---|---|
| 共通鍵暗号（認証付き） | AES-CCM（128 bit 鍵、16 byte MIC） |
| ハッシュ | SHA-256 |
| メッセージ認証 | HMAC-SHA-256 |
| 鍵導出 | HKDF-SHA-256 |
| パスワードからの鍵導出 | PBKDF2-HMAC-SHA-256 |
| 楕円曲線 | NIST P-256（secp256r1） |
| 鍵交換 | ECDH（P-256） |
| 署名 | ECDSA-SHA-256（P-256） |
| パスワード認証鍵交換 | SPAKE2+（P-256） |
| 乱数 | 暗号学的に安全な DRBG |
すべて P-256 に統一されている. 曲線が 1 つしかないので、実装が単純になり、 ハードウェアアクセラレータも 1 種類で済む。 組み込み機器にとってこれは大きい。
RSA は使わない。 証明書もすべて ECDSA P-256 である。
乱数の品質が決定的である
これが最も見落とされる実装上の穴である.
- 鍵生成、ノンス、ソルト、Discriminator、パスコード——すべて乱数に依存する。
- 弱い乱数は暗号を全部無効にする。
- 組み込み機器では、起動直後にエントロピーが足りないことがある。
rand()や、シード固定の疑似乱数は絶対に使ってはいけない。SoC のハードウェア TRNG を使い、十分にエントロピーが溜まってから鍵を生成する。 認証テストでも乱数の質は問われる（22 章）。
3. 鍵の全体像
Matter には複数種類の鍵が登場する。整理する。
| 鍵 | いつ作られる | 用途 | 保存場所 |
|---|---|---|---|
| DAC 秘密鍵 | 工場出荷時 | 機器の身元証明 | 不揮発・取り出し不可が理想 |
| Operational 秘密鍵 | Fabric 参加時 | CASE の認証 | 不揮発（Fabric ごと） |
| PASE セッション鍵 | コミッショニング時 | 一時的な通信 | 揮発（終わったら破棄） |
| CASE セッション鍵 | セッション確立時 | 運用通信 | 揮発 |
| IPK | Fabric 参加時 | Fabric の識別・グループ鍵の基 | 不揮発 |
| Group Key | グループ設定時 | マルチキャスト通信 | 不揮発 |
DAC 秘密鍵の保護
これが最も重要な秘密である. DAC 秘密鍵が漏れると、その機器になりすませる。 量産の全個体で同じ鍵を使っていれば、1 個の解析で全製品が偽造可能になる。
保護の水準（上ほど強い）:
方式 内容 セキュアエレメント（SE） 専用チップ。鍵は外に出ない。署名だけ依頼する SoC 内蔵のセキュア領域 TrustZone、eFuse で保護された鍵領域 暗号化されたフラッシュ チップ固有鍵でフラッシュを暗号化 平文でフラッシュに保存 論外（読み出せば終わり）
4. 多層防御の構造
Matter の通信は複数の層で守られている。
┌─────────────────────────────────────┐
│ アプリケーション: ACL（誰が何をできるか） │ ← [14 章](14_運用時のセキュリティ.md)
├─────────────────────────────────────┤
│ セッション: CASE 鍵で AES-CCM 暗号化 │ ← [14 章](14_運用時のセキュリティ.md)
├─────────────────────────────────────┤
│ 参加時: DAC で機器認証、PASE で参加認可 │ ← [12 章](12_デバイス認証と証明書.md)〜[13 章](13_コミッショニング.md)
├─────────────────────────────────────┤
│ ネットワーク: Thread ネットワーク鍵 │ ← [04 章](04_Thread.md#operational-dataset-thread-の-ネットワーク設定)
│ / Wi-Fi の WPA2/3 │
└─────────────────────────────────────┘各層が独立していることが重要である. Wi-Fi のパスワードが漏れても、Matter の通信は読めない。 Thread のネットワーク鍵が漏れても同じ。 1 つ破られても全部は破られない——これが多層防御の意味である。
5. セッション確立の 2 つの道
| PASE | CASE | |
|---|---|---|
| 正式名 | Passcode Authenticated Session Establishment | Certificate Authenticated Session Establishment |
| 認証の根拠 | パスコード（QR コードの数字） | 証明書（NOC） |
| 使う場面 | コミッショニング時のみ | 運用時のすべて |
| プロトコル | SPAKE2+ | SIGMA（SIGMA-I 系） |
| 前提 | 機器はまだ Fabric に属していない | 双方が同じ Fabric の NOC を持つ |
| 章 | 13 | 14 |
なぜ 2 つ必要なのか.
新品の機器は、まだどの Fabric にも属していない。証明書を持っていない。 だから証明書ベースの認証（CASE）は使えない。
かといって平文で通信するわけにはいかない。 そこで「QR コードに書かれたパスコードを知っている」ことを根拠に、 安全なセッションを張る——これが PASE である。
PASE で安全な通路を作り、その中で証明書を発行してもらい、 以降は CASE に移行する。この 2 段構えが Matter のセットアップの本質である。
6. SPAKE2+ の考え方（詳細は 13 章）
パスワードから安全な共有鍵を作るプロトコル（PAKE の一種）。
素朴な方法の何が問題か. 「パスコードをハッシュして鍵にする」では、 盗聴者が通信を記録してオフラインで総当たりできてしまう。 パスコードは 8 桁（約 1 億通り、27 bit）なので、現代の計算機なら一瞬である。
SPAKE2+ の性質:
- 盗聴者は、通信を記録してもオフライン総当たりができない
- 1 回の通信で試せるパスコードは 1 つだけ（オンライン攻撃に限定される）
- 機器側はパスコードそのものを保存しなくてよい（検証子だけを持つ）
だから機器は試行回数を制限すればよい。 仕様では、一定回数失敗したらコミッショニングウィンドウを閉じることを求めている。
検証子（Verifier）
機器が保存するのは、パスコードから PBKDF2 で導出した w0 と L（検証子）である。
passcode ──PBKDF2(salt, iterations)──> w0, w1
↓
L = w1 × P（楕円曲線上の点）
機器が保存: w0, L （w1 とパスコード本体は保存しなくてよい）これにより、機器のフラッシュを読んでもパスコードは直接得られない. ただし w0/L から総当たりでパスコードを探すことは可能なので、 検証子も秘密として扱う必要がある。
7. 証明書の 2 系統（詳細は 12・14 章）
Matter には用途の違う証明書が 2 系統ある。混同しやすいので整理する。
(a) デバイス認証用（工場で焼く、変わらない）
PAA（Product Attestation Authority） ← 業界のルート。DCL に登録
└── PAI（Product Attestation Intermediate） ← メーカーの中間 CA
└── DAC（Device Attestation Certificate） ← 個体ごと「この機器は本物の X 社の製品 Y である」を証明する。 出荷時に書き込まれ、生涯変わらない。
(b) 運用用（Fabric 参加時に発行、Fabric ごと）
RCAC（Root CA Certificate） ← その Fabric のルート
└── ICAC（Intermediate CA、任意）
└── NOC（Node Operational Certificate） ← Fabric における身分証「この機器はこの Fabric の Node ID = N である」を証明する。 Fabric に参加するたびに新しく発行される。
この 2 系統を混同すると、まったく理解できなくなる.
デバイス認証 (DAC) 運用 (NOC) 何を証明 製品の真正性 Fabric 内の身元 発行者 メーカー（PAI） Fabric の管理者 いつ 工場出荷時 コミッショニング時 個数 1 個（生涯） Fabric の数だけ 使う場面 コミッショニング時の検証 CASE のたび 「工場の身分証」と「入館証」の関係に近い。 入館証をもらうために身分証を見せる、という順序である。
8. アクセス制御（詳細は 14 章）
認証（誰であるか）と認可（何ができるか）は別である。
| 特権 | できること |
|---|---|
| View | 属性の読み取り |
| ProxyView | プロキシ用 |
| Operate | 通常の操作（ON/OFF など） |
| Manage | 設定変更 |
| Administer | Fabric 管理、ACL 変更 |
上位は下位を包含する（Administer は Operate も含む）。
各属性・コマンドに必要な特権は仕様で決まっている. 「ドアロックの解錠」には高い特権が要り、「温度の読み取り」は View で済む。 実装者が決めるものではない。
9. 実装者が守るべきこと
チェックリスト:
- ☐ 乱数は暗号学的に安全なものを使う（
rand()禁止）- ☐ DAC 秘密鍵をセキュアに保管する（SE か、少なくとも暗号化フラッシュ）
- ☐ 個体ごとに異なる passcode / discriminator / DAC（全個体同じは論外）
- ☐ テスト用証明書（VID 0xFFF1 など）を製品に載せない
- ☐ メッセージカウンタを不揮発に保存する（06 章）
- ☐ ファクトリリセットで鍵を確実に消す
- ☐ セキュアブートを有効にする（改竄ファームの実行を防ぐ）
- ☐ OTA イメージの署名を検証する（18 章）
- ☐ デバッグポート（JTAG/SWD）を出荷時に閉じる
- ☐ ログに鍵・パスコードを出さない
最後の項目は開発中に必ず違反する. デバッグのために鍵をログに出す——これ自体は必要だが、 リリースビルドで確実に消えることを確認する。
#ifdef DEBUGで囲む、ログレベルで制御するなど、仕組みで担保すること。 GitHub の issue に貼ったログから鍵が漏れる事故は実際に起きている。
10. まとめ
- Matter に平文通信は存在しない。セキュリティは後付けできない設計である。
- 暗号はすべて標準的なもの（AES-CCM、SHA-256、HKDF、P-256、ECDSA、SPAKE2+）。 独自暗号はない。曲線は P-256 に統一。
- 乱数の質がすべての土台。ハードウェア TRNG を使う。
- セッションは PASE（パスコード、コミッショニング時） と CASE（証明書、運用時） の 2 段構え。
- 証明書は DAC 系（製品の真正性、工場で焼く） と NOC 系（Fabric 内の身元、参加時に発行） の 2 系統。混同しない。
- DAC 秘密鍵の保護方式は、量産設計で最初に決めるべき項目である。