3. Matter 证书体系：PAA / PAI / DAC 的信任链
聊到 Matter 安全，绕不开的就是证书。说实话，我第一次接触 Matter 的证书体系时，也觉得有点绕——三个缩写来回倒。但搞明白之后你会发现，这套设计其实非常精巧。它解决了一个核心问题：怎么让一个几十块钱的智能灯泡，安全地加入你家网络，并且证明自己不是山寨货。
我个人习惯把 Matter 的证书体系想象成一个「身份证系统」。你想想看，国家发身份证，有公安部（根）、有省厅（中间）、有派出所（签发）。Matter 也一样，只是它用证书链来体现。
3.1 证书链结构：三层信任模型
Matter 的证书链分三层，从上到下依次是：
- PAA（Product Attestation Authority）——产品认证机构，相当于根 CA。
- PAI（Product Attestation Intermediate）——产品认证中间机构，相当于中间 CA。
- DAC（Device Attestation Certificate）——设备认证证书，相当于设备的身份证。
这三层的关系，说白了就是「信任传递」。根 CA 信任中间 CA，中间 CA 信任设备。设备拿 DAC 出来，验证方只要往上追溯到 PAA，就能确认这个设备是合法的。
核心要点：Matter 不要求设备存储整条证书链，但验证方（比如 Matter 控制器）必须能通过 DAC 找到对应的 PAI 和 PAA。实际通信中，设备通常只发 DAC + PAI，PAA 由验证方本地缓存或从 DCL（分布式合规账本）获取。
我在项目中遇到过一个问题：有厂商把 PAA 证书也塞进设备里，结果固件 OTA 升级时证书体积太大，导致传输失败。嗯，这里要注意——设备只存 DAC 和 PAI 就够了，PAA 不需要。
3.2 证书签发流程：谁签谁？
签发流程其实就三步，我画个图你就明白了。
签发流程具体是这样的：
- PAA 自签名：根 CA 自己签自己，这是信任的起点。PAA 的私钥必须离线保存，最好放在 HSM（硬件安全模块）里。
- PAA 签发 PAI：每个厂商可以申请一个或多个 PAI。PAI 的私钥由厂商自己保管，用于签发设备证书。
- PAI 签发 DAC：设备生产时，PAI 私钥为每个设备签发唯一的 DAC。DAC 里包含了设备的公钥和 VID/PID（厂商 ID/产品 ID）。
⚠️ 我曾经踩过的坑：有次厂商把 PAI 私钥直接放在生产线的工控机上，结果被病毒扫走了。后来他们不得不吊销所有已签发的 DAC，重新换 PAI。记住——PAI 私钥必须放在离线环境或 HSM 里，生产线上只放公钥和签名请求接口。
3.3 DAC 的生成：从 CSR 到证书
DAC 的生成，说白了就是设备向 PAI 申请一张「身份证」。流程如下：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 设备生成密钥对 | 在设备安全元件（SE）或 TEE 中生成，私钥永不出芯片 |
| 2 | 设备生成 CSR | CSR 包含公钥、VID/PID、设备序列号等信息 |
| 3 | CSR 发送到 CA 服务器 | 通过安全通道（如 TLS）传输，防止中间人篡改 |
| 4 | CA 验证 CSR 信息 | 检查 VID/PID 是否合法、设备是否在授权列表里 |
| 5 | CA 签发 DAC | 使用 PAI 私钥签名，生成 X.509 v3 证书 |
| 6 | DAC 注入设备 | 写入设备的安全存储区，与私钥绑定 |
这里有个细节：DAC 的 Subject 字段必须包含 VID 和 PID。Matter 协议规定，验证方会从 DAC 里提取 VID/PID，然后去 DCL 查这个 VID/PID 是否对应一个合法的 PAI。如果对不上，直接拒绝入网。
💡 我的建议：生产线上生成 DAC 时，最好用硬件安全模块（HSM）来做签名。HSM 的签名速度虽然比软件慢一点，但安全性高一个数量级。我见过用软件签名导致私钥泄露的案例，那真是欲哭无泪。
3.4 DAC 的验证：设备入网时的安全检查
设备入网时，Matter 控制器会验证 DAC。验证过程分三步：
- 证书链验证：从 DAC 到 PAI 到 PAA，逐级检查签名。只要有一级签名不对，直接拒绝。
- 有效期检查：DAC、PAI、PAA 都有有效期。过期了也不行。
- VID/PID 匹配：DAC 里的 VID/PID 必须与 PAI 的 Subject 里声明的 VID/PID 一致。
你以为这就完了？不，还有一步——DCL 查询。Matter 控制器会去分布式合规账本（DCL）上查这个 PAA 和 PAI 是否被吊销。如果 PAA 被列入了黑名单，那下面所有设备都进不了网。
关键点：DAC 验证是 Matter 安全的第一道防线。它保证了入网的设备是经过认证的、没有被篡改的。但注意——DAC 验证通过不代表设备是安全的，它只证明设备是「正品」。设备固件有没有漏洞、会不会被攻击，那是另一回事。
3.5 代码示例：用 OpenSSL 模拟 DAC 签发
为了让你更直观地理解，我写了个简单的 OpenSSL 命令序列。你可以在测试环境里跑一下，感受整个流程。
# 1. 生成 PAA 自签名证书（根 CA）
openssl req -x509 -newkey rsa:2048 -keyout paa_key.pem -out paa_cert.pem \
-days 3650 -nodes -subj "/CN=Matter Test PAA/O=Test Org/C=CN"
# 2. 生成 PAI 密钥和 CSR
openssl req -newkey rsa:2048 -keyout pai_key.pem -out pai_csr.pem \
-nodes -subj "/CN=Matter Test PAI/O=Test Org/C=CN"
# 3. 用 PAA 签发 PAI 证书
openssl x509 -req -in pai_csr.pem -CA paa_cert.pem -CAkey paa_key.pem \
-CAcreateserial -out pai_cert.pem -days 1825 -sha256
# 4. 生成设备密钥和 CSR
openssl req -newkey rsa:2048 -keyout device_key.pem -out device_csr.pem \
-nodes -subj "/CN=Device 001/OU=VID:1234/O=Test Org/C=CN"
# 5. 用 PAI 签发 DAC
openssl x509 -req -in device_csr.pem -CA pai_cert.pem -CAkey pai_key.pem \
-CAcreateserial -out dac_cert.pem -days 365 -sha256
# 6. 验证证书链
openssl verify -CAfile paa_cert.pem -untrusted pai_cert.pem dac_cert.pem
跑完最后一步，如果输出 dac_cert.pem: OK，说明证书链验证通过。你可以试试把中间某个证书换掉，看看验证会不会失败——嗯，肯定会报错。
⚠️ 注意：上面的命令只是演示用。生产环境里，RSA 2048 位密钥已经不够安全了，我建议用 ECDSA P-256 曲线。Matter 协议也推荐使用 ECDSA，因为签名更短、性能更好。
3.6 证书生命周期管理
证书不是永久的。Matter 规定了证书的有效期：
| 证书类型 | 建议有效期 | 吊销方式 |
|---|---|---|
| PAA | 10-15 年 | 通过 DCL 发布吊销列表 |
| PAI | 3-5 年 | 通过 DCL 发布吊销列表 |
| DAC | 设备生命周期 | 设备端无法吊销，只能通过 PAI 吊销间接失效 |
你可能会问：DAC 有效期为什么是设备生命周期？因为设备一旦出厂，DAC 就焊死在芯片里了，没法更新。如果 DAC 过期了，设备就永远无法入网。所以 Matter 规定 DAC 的有效期要覆盖设备的预期寿命，通常是 10 年以上。
我曾经帮一个客户设计证书策略，他们一开始把 DAC 有效期设成了 3 年。结果产品上市两年后，大量设备无法入网——因为 DAC 过期了。最后只能召回设备，损失惨重。所以记住：DAC 有效期一定要设得足够长。
3.7 小结
Matter 的证书体系，说白了就是一套「信任传递」机制。PAA 信任 PAI，PAI 信任 DAC。设备入网时，控制器通过验证 DAC 的签名链，确认设备是正品。这套体系的关键在于：
- 私钥保护：PAA 和 PAI 的私钥必须离线存储，DAC 的私钥必须留在安全元件里。
- 证书链完整：验证时一定要逐级检查，不能跳过任何一级。
- DCL 查询：别忘了查吊销列表，否则被吊销的证书还能继续用。
嗯，证书这部分内容比较多，但它是 Matter 安全的基石。搞懂了证书链，后面讲 TLS 握手和 CASE 协议时，你就会觉得轻松很多。