Matter Commissioning（新设备加入 Fabric 流程）全解析

因为在ESP32 尝试控制设备时，发生了证书错误，所以留下了此篇笔记，深入了解一下 Matter 配网认证的流程

Matter Commissioning（设备入网配网）是将 “未配网的 Matter 设备（Uncommissioned Device）” 安全接入指定 Fabric（家庭 / 楼宇网络域）的核心流程，其核心目标是建立设备与 Fabric 的加密信任关系，同时完成网络配置与身份认证。以下内容基于 Matter 官方核心规范（Matter Core Specification 1.2）、乐鑫（Espressif）ESP Matter 文档及 Google Matter 开发者指南编写，全程对标官方定义。

一、核心定义（官方）

1. 关键角色

2. 核心目标

建立 Commissioner 与 Commissionee 的安全加密会话，防止配网过程被窃听 / 篡改；

验证设备合法性（防伪造设备接入）；

为设备分配 Fabric 唯一标识（Node ID），并分发加密通信所需的根密钥；

配置设备接入 Wi-Fi/Thread 等数据网络，使其成为 Fabric 的合法节点。

二、完整 Commissioning 流程（Matter 1.2 官方规范）

Matter Commissioning 分为6 个核心阶段，前 4 阶段通过 BLE（低功耗蓝牙）完成（设备未接入数据网络时的临时通信通道），后 2 阶段切换到 Wi-Fi/Thread 数据网络（全程加密）。

阶段 1：设备发现（Discovery）

官方参考：Matter Core Spec 11.2.1 Discovery of Commissionable Devices

核心目标：Commissioner 发现周边处于 “配网模式” 的 Commissionee，并建立 BLE 连接。

配网模式触发：Commissionee 上电后进入配网模式（如长按按键、出厂重置），持续广播包含 Matter 配网标识的 BLE Beacon；

关键参数解析：Commissioner 扫描 BLE 广播包，解析其中的「Discriminator（区分码）」和「Setup PIN Code（配网 PIN 码）」（设备贴纸 / 说明书提供）；

设备匹配与连接：用户在 Commissioner（如手机 App）输入 PIN 码（或通过 NFC / 二维码自动读取），Commissioner 基于 Discriminator 过滤目标设备，发起 BLE 连接（对应日志中Device Discriminator match. Attempting to connect）。

控制器若已通过扫码 / NFC / 手动输入获取了完整参数，可通过 BLE 广播快速过滤并匹配目标设备

阶段 2：安全配对建立（PASE）

官方参考：Matter Core Spec 11.3 PASE (Password-Authenticated Session Establishment)

核心目标：基于 PIN 码建立加密会话，为后续配网指令提供安全通道。

密钥派生：双方基于 PIN 码执行 PBKDF2（密码基密钥派生函数）算法，生成共享会话密钥（对应日志中Sent PBKDF param request/PASE_Pake1/2/3）；

安全会话建立：完成密钥协商后，建立 Secure Session（安全会话），后续所有配网指令均通过该加密通道传输（日志中SecureSession State change 'kEstablishing' --> 'kActive'）；

安全保障：即使 PIN 码简单（如 00000000），PBKDF2 通过 “加盐 + 多次哈希” 强化，确保生成高强度会话密钥，避免弱 PIN 码导致的安全风险。

阶段 3：设备认证（Device Attestation, DA）

官方参考：Matter Core Spec 11.4 Device Attestation (DA)

核心目标：验证设备是 “合规的 Matter 设备”（你之前报错的核心阶段）。

证书链请求：Commissioner 向 Commissionee 发送请求，读取证书链 —— DAC （设备认证证书）+ PAI （产品认证中间证书）（日志中SendPAICertificateRequest/SendDACCertificateRequest）；

信任链验证：

解析 PAI 证书的 AKID（授权密钥标识符），查找对应的 PAA（产品认证根证书）（本地信任库 / Matter 官方 DCL 分布式合规账本）；

用 PAA 公钥验证 PAI 签名 → 用 PAI 公钥验证 DAC 签名 → 确认 DAC 绑定的设备身份与实际设备一致；

吊销检查（可选）：验证 DAC/PAI 是否被 Matter 联盟吊销；

失败场景：若 Commissioner 找不到 AKID 对应的 PAA（如你日志PAA not found in DCL and/or local PAA trust store），认证失败，配网终止。

补充：完整的设备认证流程

DAC 证书：设备自身的设备认证证书（由厂商 / 工厂签发）；PAI 证书：签发 DAC 证书的中间 CA 证书（由 PAA 机构签发）；PAA 证书：Matter 生态的根级认证证书（由 Matter 联盟合规的机构签发，如芯片厂商、第三方合规 CA）；AKID ：AKID（Authority Key Identifier）的本质是：当前证书的签发者的公钥哈希值（SHA-1）日志中的 AKID = 签发该 PAI 证书的PAA 证书的公钥标识符 → 简单说，这个 AKID 属于 “某家 PAA 机构的公钥标识”。

控制器（如 chip-tool / 手机网关）在配对时执行的「AttestationVerification」步骤，本质是验证设备的 DAC 证书是否可信，完整流程如下（对应你的报错场景）：

步骤 1：控制器从设备读取证书链

配对时，控制器通过 BLE 向设备发送请求，读取 3 类数据：

设备的 DAC 证书（含设备信息、签名、AKID 字段）；

签发 DAC 的 PAI 证书（含 PAI 信息、签名、AKID 字段）；

设备的 Attestation Nonce（随机数，防重放攻击）。

步骤 2：解析证书的 AKID，定位验签公钥

控制器先解析 PAI 证书的「AKID 字段」（即日志中的35:57:52:A3:...），这个 AKID 的含义是：“要验证我（PAI 证书）的签名，需要用 AKID 对应的 PAA 公钥”。

控制器会去两个地方找这个 AKID 对应的 PAA 公钥：

本地「Attestation Trust Store」（例如idf.ppy menuconfig 里配置的测试 / 自定义 / PFFS 信任库）；

Matter 官方 DCL（分布式合规账本，云端的 PAA 公钥库）。

步骤 3：验证 PAI 证书的合法性（核心：数字签名验证）

如果控制器找到 AKID 对应的 PAA 公钥，会执行：

用 PAA 公钥解密 PAI 证书的「数字签名」（PAI 证书签发时，PAA 用自己的私钥对 PAI 内容加密，生成签名）；

对比解密后的结果与 PAI 证书的原文内容：

一致 → PAI 证书是可信的（确由该 PAA 签发，未被篡改）；

不一致 → PAI 证书伪造 / 篡改，认证失败。

步骤 4：用 PAI 验证 DAC 证书（同理）

控制器再解析 DAC 证书的 AKID（对应 PAI 的公钥标识），用步骤 3 验证通过的 PAI 公钥，解密 DAC 证书的签名，验证 DAC 是否由该 PAI 合法签发、未被篡改。

关键结论：

合规的 Matter 设备中，DAC 由 PAI 签发、PAI 由 PAA 签发 → DAC 的 AKID 指向 PAI 公钥，PAI 的 AKID 指向 PAA 公钥 → 两者 AKID 必然不同；

只有两种极端情况可能 “相同”（均不符合 Matter 官方合规要求）：

厂商跳过 PAI，直接用 PAA 私钥签发 DAC（违反 Matter 证书层级规则）→ DAC 的 AKID = PAA 公钥哈希 = PAI 的 AKID（此时 PAI 本身不存在，无实际意义）；

厂商错误地将 PAI 和 DAC 用同一组 CA 公钥签发（测试固件 / 违规量产）→ 两者 AKID 偶然相同。

步骤 5：验证设备的 Attestation 信息（最终确认）

控制器用 DAC 公钥验证设备的 Attestation 签名（包含随机数、设备信息），确认 “当前配对的设备，就是 DAC 证书绑定的设备”（防设备冒充）。

步骤 6：最终结果

所有步骤通过 → 设备认证成功，配对继续；

任意步骤失败（如找不到 AKID 对应的 PAA 公钥、签名验证失败）→ 认证失败（即你日志中的Error CHIP:0x00000020）。

阶段 4：读取配网信息（Read Commissioning Info）

官方参考：Matter Core Spec 11.5 Commissioning Information Exchange

核心目标：获取设备基础能力，为后续配置做准备。

指令发送：Commissioner 发送 ReadRequest 指令，读取 Commissionee 的 Commissioning Cluster 属性（日志中Sending read requests for commissioning information）；

关键信息获取：设备支持的网络类型（Wi-Fi/Thread）、硬件版本、Endpoint 列表、地域配置（Regulatory Config）等；

容错机制：若部分属性读取失败（如你日志Ignoring failure to read IsCommissioningWithoutPower），仅跳过非必要属性，不影响核心配网。

阶段 5：网络与 Fabric 配置（Provisioning）

官方参考：Matter Core Spec 11.6 Network Provisioning / 11.7 Fabric Provisioning

核心目标：配置数据网络，绑定 Fabric 身份。

子阶段 5.1：网络配置（Network Provisioning）

Commissioner 向设备发送 Wi-Fi SSID / 密码（或 Thread 网络参数，如 PAN ID、主密钥）；

设备尝试接入指定网络，接入成功后向 Commissioner 反馈状态。

子阶段 5.2：Fabric 配置（Fabric Provisioning）

为设备分配 Fabric 内唯一的 Node ID；

分发 Fabric 核心密钥：Fabric Secret（根密钥）、Operational Credentials（操作凭证）；

设备将 Fabric 信息存储到本地安全分区（如 ESP32 的工厂分区），完成 Fabric 绑定。

阶段 6：配网收尾（Commissioning Completion）

官方参考：Matter Core Spec 11.8 Commissioning Completion

核心目标：确认配网完成，设备进入正常工作状态。

超时保护：Commissioner 发送 ArmFailSafe 指令，设置 60 秒配网超时（日志中Arming failsafe (60 seconds)），确保超时前完成所有配置；

网络切换：设备从 BLE 切换到 Wi-Fi/Thread 数据网络，与 Commissioner 重新建立加密会话；

完成确认：Commissioner 发送 Commissioning Complete 指令，设备解除 FailSafe 状态，正式加入 Fabric；

最终状态：设备成为 Fabric 的合法节点，可接收 Fabric 内的控制指令（如开关灯、读取状态）。

四、官方补充说明（乐鑫 / Google）

ESP Matter 优化：

ESP32 系列设备支持 “测试配网”，可通过 menuconfig 禁用 DA 认证（CONFIG_DISABLE_DEVICE_ATTESTATION），仅用于开发测试；

ESP Matter 默认使用TEST_ATTESTATION_TRUST_STORE（测试信任库），仅包含 Matter 官方测试 PAA，量产需切换到 DCL/SPIFFS 信任库。

Google Home 配网要求：

量产设备必须通过 Matter 认证，DA 阶段需能从 DCL 获取 PAA；

测试设备需在 Google Home 开发者模式下禁用 DA 验证。

五、官方文档参考

Matter Core Specification 1.2（Chapter 11 Commissioning）：https://matter.google.com/specifications/core

Espressif ESP Matter Commissioning 指南：https://docs.espressif.com/projects/esp-matter/en/latest/esp32/commissioning.html

Google Matter Commissioning 开发者指南：https://developers.google.com/home/matter/guides/commissioning

日志参考