3. 设备认证机制：DAC、PAI与根证书链
设备认证，说白了就是回答一个问题：“你怎么证明你是你？”
在Matter生态里，每一台设备出厂时都带着一套“身份证”。这套身份证不是一张纸，而是一串数字证书。我刚开始接触Matter时，觉得证书链这东西挺绕的。后来亲手拆过几个设备的DAC，才真正理解它的设计精妙之处。
今天我们就来拆解这套认证机制的核心：DAC、PAI、根证书，以及它们如何串成一条可信的链条。
3.1 三张证书，各司其职
Matter的设备认证体系由三级证书组成。你可以把它想象成三代人的关系：
- 根证书（Root Certificate）：最高权威，由CSA（连接标准联盟）或授权CA签发。它自签名，是整个信任链的“祖宗”。
- PAI（Product Attestation Intermediate，产品认证中间证书）：由根证书签发，代表一个产品系列或制造商。它证明“这批设备来自某家合法厂商”。
- DAC（Device Attestation Certificate，设备认证证书）：由PAI签发，每台设备独一份。它证明“这台具体的设备是正品”。
关键点：DAC里嵌入了设备的公钥，对应的私钥在设备出厂时就被烧录进安全芯片（如SE或TPM）。私钥永远不离开芯片，这是硬件级安全的底线。
我在项目中遇到过一批设备，DAC私钥是用软件模拟的，结果被攻击者提取出来伪造了上百台虚拟设备。嗯，从那以后我再也不敢省安全芯片的钱了。
3.2 DAC结构深度拆解
DAC是一张X.509 v3证书，但它的字段有Matter特定的要求。我们直接看一个典型的DAC结构：
Certificate:
Data:
Version: 3 (0x02)
Serial Number: 0x12345678
Signature Algorithm: ECDSA-with-SHA256
Issuer: CN = PAI-ExampleManufacturer, OU = Matter PAI
Validity:
Not Before: Jan 1 00:00:00 2024 GMT
Not After : Dec 31 23:59:59 2034 GMT
Subject: CN = DAC-Device001, OU = Matter DAC
Subject Public Key Info:
Public Key Algorithm: EC
EC Curve: secp256r1 (P-256)
Public Key: (65 bytes uncompressed)
Extensions:
subjectKeyIdentifier: hash of public key
authorityKeyIdentifier: hash of PAI public key
keyUsage: digitalSignature
extendedKeyUsage: matterDeviceAttestation (1.3.6.1.4.1.53866.1.1)
basicConstraints: CA:FALSE
Signature: (ECDSA-SHA256 signature bytes)注意几个关键字段：
- 曲线必须用secp256r1，也就是P-256。用别的曲线，Matter协议栈直接拒掉。
- extendedKeyUsage里必须包含Matter定义的OID：
1.3.6.1.4.1.53866.1.1。这是Matter设备的“专用章”。 - basicConstraints: CA:FALSE，DAC不能签发下级证书，它只是终端实体证书。
我的习惯：在解析DAC时，先检查extendedKeyUsage。如果这个OID不对，后面的验证都不用做了，直接判定为非法设备。这能省下不少计算时间。
3.3 PAI与根证书的角色
PAI是承上启下的中间证书。它由根证书签发，但它的职责是授权给具体的DAC。PAI的结构和DAC类似，但有两点不同：
| 属性 | DAC | PAI |
|---|---|---|
| basicConstraints | CA:FALSE | CA:TRUE, pathLen:0 |
| keyUsage | digitalSignature | keyCertSign, digitalSignature |
| 签发对象 | 单台设备 | 一个产品系列 |
| 生命周期 | 通常10年 | 通常10-20年 |
根证书是自签名的，它的公钥是信任锚点。在Matter生态里，根证书通常预置在认证设备（如手机、智能音箱）的固件中。设备入网时，会用这个根证书去验证DAC和PAI的签名。
你想想看，如果根证书被篡改，整个信任链就崩塌了。所以根证书的存储必须是防篡改的，通常放在只读存储器或安全启动校验的区域。
3.4 证书链验证流程
验证流程其实不复杂，但每一步都不能少。我把它拆成四个步骤：
- 提取证书：从设备获取DAC，从制造商或联盟获取PAI和根证书。
- 格式检查：验证证书版本、签名算法、有效期、扩展字段是否符合Matter规范。
- 签名验证：用根证书的公钥验证PAI的签名，再用PAI的公钥验证DAC的签名。
- 完整性校验：确认DAC的公钥与设备提供的签名数据匹配，防止证书被替换。
下面这张图展示了完整的证书链验证逻辑：
验证过程中，有一个容易被忽略的细节：证书撤销列表（CRL）。Matter协议要求验证者检查DAC和PAI是否在CRL中。如果一张证书被撤销，即使签名正确，也不能信任。
我曾经踩过这个坑：在开发Matter桥接器时，只验证了签名链，没检查CRL。结果一台被撤销的设备成功入了网，导致整个网络的安全策略失效。后来我加上了CRL检查，并定期从联盟拉取最新的撤销列表。
3.5 实战中的避坑指南
根据我的经验，以下几个问题最容易出幺蛾子：
- 证书有效期重叠：DAC、PAI、根证书的有效期必须合理衔接。如果根证书过期了，即使DAC还在有效期内，验证也会失败。
- 公钥格式不匹配：Matter要求使用未压缩的65字节公钥。有些厂商用了压缩格式，导致签名验证失败。
- 扩展字段缺失：extendedKeyUsage里的Matter OID是必填项。我见过一些测试设备漏了这个字段，结果在认证测试时被卡住。
- 私钥保护不到位：DAC私钥必须存储在安全元件中。用普通Flash存储的，基本等于没锁门。
嗯，说到私钥保护，我再多提一句。Matter规范里明确要求DAC私钥的生成和存储必须在安全环境中完成。如果你用的是MCU内置的硬件安全模块（如ARM TrustZone或NXP的EdgeLock），记得确认它是否通过了CC EAL4+或FIPS 140-2认证。这是合规的硬门槛。
3.6 小结
设备认证是Matter安全的第一道防线。DAC、PAI、根证书这三层结构，既保证了每台设备的唯一性，又通过证书链实现了可追溯的信任传递。验证流程虽然只有几步，但每一步都关系到整个网络的安全。
我个人觉得，理解这套机制最好的方式就是亲手解析一张DAC。你可以用OpenSSL的命令行工具，把证书的每个字段都打印出来看看。看多了，你自然就能一眼识别出问题证书。