3. Matter中的证书体系：DAC、PAI、PAA的角色与生命周期
聊到Matter安全，绕不开的就是证书体系。说实话，我第一次看Matter的证书链时，脑子里冒出的第一个念头是：“这不就是PKI那一套吗？”但深入项目之后才发现，它把传统PKI玩出了新花样——尤其是针对物联网设备这种资源受限、离线部署的场景，做了很多精巧的设计。
今天我们就来拆解Matter证书体系里的三个核心角色：DAC（设备认证证书）、PAI（产品认证中间证书）、PAA（产品认证根证书）。我会结合我在实际项目中踩过的坑，帮你把这些概念彻底搞明白。
3.1 证书链的整体结构
Matter的证书体系是一个三层结构，从上到下依次是：
- PAA —— 信任锚点，由CSA（连接标准联盟）或授权机构签发
- PAI —— 中间证书，由设备制造商持有，用于签发具体设备
- DAC —— 设备证书，每个设备唯一，出厂时烧录
你想想看，为什么不用两层？直接用根证书签设备不行吗？嗯，这里有个关键原因：安全隔离。如果每个设备都用根证书直接签，一旦某个设备的私钥泄露，整个产品线的信任就崩了。加一层PAI，相当于给每个产品线一个独立的“子信任域”，泄露一个设备，最多影响该产品线，根证书依然安全。
核心原则：Matter证书链的设计遵循“最小泄露半径”原则。每一层证书只负责自己范围内的信任，出了问题可以快速隔离。
下面这张图展示了完整的证书链结构：
3.2 DAC：设备的身份证
DAC是离设备最近的一层证书。每个Matter设备出厂时，都会烧录一个唯一的DAC。它包含了设备的公钥、设备信息（如VID/PID），以及设备类型等元数据。
我在项目中遇到过一件事：有个厂商把DAC的私钥用明文存到了Flash里。结果呢？测试阶段就被我们抓到了。你想想看，私钥泄露等于设备身份被盗用，攻击者可以伪造任意设备加入网络。所以，DAC私钥必须存储在安全元件（SE）或TPM中，这是底线。
避坑指南：我曾经见过一个团队，为了省成本，把DAC私钥放在通用MCU的Flash里。结果产品上市三个月，就被爆出大规模仿冒问题。记住：DAC私钥的安全存储，不是可选项，是必选项。
DAC的生命周期大致如下：
- 生成：在制造商的CA系统中生成密钥对，并签发DAC
- 烧录：在生产线上写入设备的安全存储区
- 使用：设备加入Matter网络时，用DAC证明自己的身份
- 失效：设备报废或证书过期（通常DAC有效期较长，但建议不超过10年）
3.3 PAI：产品线的信任代理
PAI是连接PAA和DAC的桥梁。每个产品线（或者说每个型号）通常对应一个PAI。制造商用自己的PAI私钥签发所有该型号设备的DAC。
为什么要单独搞一个PAI？说白了，就是为了权限分离。PAA的私钥通常被严密保护，可能一年只用几次。日常的设备签发工作，交给PAI来做。这样即使PAI私钥泄露，也只是影响一个产品线，而不是整个制造商的所有产品。
| 特性 | PAA | PAI | DAC |
|---|---|---|---|
| 签发者 | CSA或授权机构 | 制造商（使用PAA签发） | 制造商（使用PAI签发） |
| 私钥保护级别 | 最高（离线存储） | 高（HSM或安全服务器） | 中（设备安全元件） |
| 泄露影响范围 | 整个制造商所有产品 | 单个产品线 | 单个设备 |
| 有效期 | 10-20年 | 5-10年 | 3-10年 |
| 使用频率 | 极低（仅签发PAI时使用） | 中等（签发DAC时使用） | 高（每次入网认证时使用） |
我个人习惯，在管理PAI时，会为每个产品线单独生成一个PAI密钥对，并记录在案。这样万一某个产品线出问题，可以单独吊销该PAI，不影响其他产品线。
3.4 PAA：信任的锚点
PAA是整个Matter证书体系的根。它由CSA（连接标准联盟）或CSA授权的机构签发。所有Matter设备在入网时，最终都要追溯到PAA来验证信任。
PAA的私钥是最高机密。我记得在参与一个Matter认证项目时，CSA要求PAA私钥必须存储在离线HSM中，且每次使用需要多人授权。这可不是闹着玩的——一旦PAA私钥泄露，整个制造商的Matter产品信任体系就崩塌了。
我的建议：如果你所在的公司要申请Matter认证，PAA的生成和存储一定要找专业的CA服务商。别自己搞，风险太大。我见过有厂商自己用OpenSSL生成PAA，结果证书格式不符合CSA规范，被退回重做，白白浪费了两个月。
3.5 证书的生命周期管理
证书不是永久的。Matter证书体系对生命周期有明确要求：
- 签发：所有证书必须使用符合CSA规范的算法（目前是ECDSA P-256）
- 使用：设备入网时，必须提供完整的证书链（DAC + PAI + PAA）
- 更新：证书到期前，需要重新签发。对于DAC，通常随设备报废而结束
- 吊销：通过CRL（证书吊销列表）或OCSP（在线证书状态协议）实现
这里有个容易忽略的点：Matter设备通常是离线工作的，所以OCSP这种在线查询方式不太适用。Matter更依赖CRL，设备在固件更新时同步最新的吊销列表。
我曾经在项目中遇到一个坑：设备出厂时烧录了DAC，但忘了烧录PAI证书。结果设备入网时，只发了DAC，没有PAI，导致验证失败。排查了半天才发现是产线脚本漏了这一步。所以，产线烧录时一定要验证证书链的完整性。
3.6 证书验证流程
当设备加入Matter网络时，验证流程是这样的：
- 设备发送DAC + PAI给控制器（如手机或智能音箱）
- 控制器用PAI的公钥验证DAC的签名
- 控制器用PAA的公钥验证PAI的签名
- 控制器检查PAA是否在信任列表中
- 全部通过，设备认证成功
你想想看，这个流程保证了什么？它保证了：设备确实是某个合法制造商生产的，且没有被篡改过。即使攻击者拿到了DAC的通信数据，没有私钥也无法伪造身份。
一句话总结：Matter证书体系通过PAA→PAI→DAC的三层结构，实现了从联盟到制造商再到单个设备的逐级信任传递。每一层证书各司其职，共同构建了Matter设备的安全基石。