当前位置：首页 > backend >正文

Matter安全实现

backend 2025/9/5 7:56:43

Matter分析与安全验证
上一篇文章简单的介绍了Matter的架构、实现、以及部分安全验证过程；这里继续补充一下Matter的其他安全验证流程，以更好的实现Matter安全。

Matter提供的安全实现流程大概总结起来是这个流程

硬件信任根→安全启动→动态证书→加密通信→ACL权限控制→DCL全局验证

上一篇介绍了前面的部分，这里再根据这个流程来汇总一下；

Matter安全实现流程

🔒 1. 硬件信任根（Hardware Root of Trust）

实现机制：
- 安全芯片固化密钥：设备出厂时在安全芯片（如Silicon Labs的Secure Vault）中预烧唯一密钥对和厂商证书（DAC），私钥不可读取仅用于签名运算。
- 物理防篡改设计：采用防物理探测的存储区域（Secure Enclave），确保密钥不被提取（如Nordic nRF54系列芯片）。
作用：为后续安全启动和证书链提供不可篡改的信任起点，防止设备克隆和固件伪造。

🚀 2. 安全启动（Secure Boot）

启动验证流程：
1. Bootloader使用硬件信任根的公钥验证首层固件签名（ECDSA算法）。
2. 逐级验证：每个固件模块验证下一级签名，形成信任链（Chain of Trust）。
3. 失败处理：签名无效则终止启动或回滚至安全版本（双镜像设计）。
关键配置：芯片OTP存储器锁定启动策略（如禁用调试接口、强制加密OTA）。
防攻击设计：
- 前面两部分需要硬件安全支持，在安全芯片的支持下实现，但是大部分低成本的芯片都不具有安全能力，但是我们给方案的时候也需要考虑类似的方案，硬件信任根还是需要落地，但是没有了安全芯片的支持，就需要放到不可读取区域来防止复制和伪造。

📜 3. 动态证书（Dynamic Certificates）

证书体系结构：
- DAC（设备认证证书）：出厂预置，包含设备唯一ID（VID/PID）和公钥，用于身份证明。
- NOC（节点操作证书）：配网时由控制器动态签发，绑定设备与特定Fabric网络。
证书生命周期：
- 签发：配网阶段控制器通过CSR请求生成设备唯一NOC，私钥在设备安全区域生成。
- 吊销：控制器可推送证书吊销列表（CRL），阻断恶意设备。
防攻击设计：
- 设备配网认证阶段使用，这里的DAC证书的颁发者是产品认证中间证书，一般是设备厂商持有，所以设备认证阶段要通过DAC进行，而不是跟常规的设备认证通过某个设备序列号或者MAC信息来判断设备身份；那么这里就要防止设备唯一NOC伪造的情况出现，防止客户端自签NOC证书的设计出现，要让设备厂商来签发NOC证书，并做好身份验证以及权限控制。

📡 4. 加密通信（Encrypted Communication）

分层加密协议：
- PASE（配网阶段）：基于配网密码（QR码/PIN）生成临时会话密钥（AES-128），保护初始配置数据传输。
- CASE（运行阶段）：基于NOC证书交换，通过ECDH协商长期会话密钥，所有通信使用AES-128-CCM加密并附加消息认证码（MAC）。
防攻击设计：
- 消息计数器：每个报文携带递增计数器，防重放攻击。
- 密钥轮换：会话密钥定期更新（默认24小时），降低密钥泄露风险。

🛡️ 5. ACL权限控制（Access Control Lists）

规则实现：
- 动态策略：ACL规则以JSON格式存储于控制器，定义设备/用户的操作权限（如Operate开关权限、Manage规则修改权限）。
- 执行逻辑：设备处理命令前，通过安全会话向控制器请求授权，验证节点ID和操作权限。
示例场景：门锁设备仅允许管理员角色执行Unlock命令，传感器仅可Read状态。
详细分析见后文

🌐 6. DCL全局验证（Distributed Compliance Ledger）

验证流程：
1. 设备入网时向控制器提交DAC证书链（DAC→PAI→PAA）。
  1. 设备认证证书 (DAC)
  2. 产品认证中间证书 (PAI)
  3. 产品认证根证书 (PAA)
2. 控制器访问DCL节点，验证：
  - 证书有效性：PAA根证书是否在DCL信任列表。
  - 设备合规性：VID/PID是否通过CSA认证，固件哈希是否匹配。
  - 吊销状态：查询DCL中的证书吊销列表（CRL）。
3. 动态拦截：若DCL返回未认证或已吊销，控制器拒绝设备入网。
去中心化优势：DCL由CSA成员节点共识维护，防单点篡改（如伪造证书需攻破多数节点）

看完整个Matter的安全实现流程，可以看出对于安全验证这块基本上都设计的非常的全面，但是开发者按照Matter的设计文档来实现时，却是会漏洞百出，为什么会出现这种情况呢？这里列举几种可能性，以及对应的坑点；

成本
1. 拿硬件信任根和安全启动来说，这里是需要硬件成本的，在芯片选型这块就需要决策，如果一开始因为成本原因采用不具有安全能力的芯片的话就无从谈起；
2. 有些情况是选择了具有安全能力的芯片，但是开发者却没有使用安全芯片的能力去设计实现，调用相关安全能力也是挺无奈的，当然这块是偷懒行为；
3. 当然了，还有一种是芯片厂商的锅，对外宣传具有安全能力，宣发文档写的该有都有，实际对接的接口文档却没有办法使用；
开发者理解错误
1. 这块属于常见问题，类似于云端验证和实现的部分放到客户端去实现了；比如说动态证书部分NOC证书的生成，如果放到客户端生成，那么攻击者就可以自己伪造自签NOC证书；
业务实现设计错误（偷懒）
1. 当开发者已经按照所有的验证流程来完成Matter的安全实现了，包括前面的安全芯片、设备认证、加密通信以及Matter的证书链；但是ACL权限却是懒得去配置，或者说依旧是客户端自己维护默认的，这种情况就会导致设备权限混乱的问题；
2. 那么ACL规则要如何配置？

ACL规则参数解析

1. ACL 核心参数详解

(1) Subject（主体）

含义：被授权操作的设备标识，即执行操作的设备 Node ID。
配置选项：
- 单一设备：0x123（16 进制 Node ID）
- 设备组：Group:LightSwitches（需提前定义设备组）
- 生态域（Fabric）内所有设备：Fabric:All

案例模板：

Subject:Type: SingleDevice# 单一设备Value: 0x123# 开关的 Node ID

(2) Target（目标）

含义：被操作的资源，支持三级粒度控制。

配置选项：

类型	示例	作用范围
Endpoint	`Endpoint: 1`	指定设备的单个端点（如灯泡）
Cluster	`Cluster: OnOffServer`	端点内的功能模块（如开关控制）
DeviceType	`DeviceType: DimmableLight`	同一类型的所有设备（如所有调光灯）

案例模板：

Target:Type: Cluster# 目标类型为 ClusterValue: OnOffServer# 操作 OnOff 功能Scope: Endpoint:1# 限制在端点 1 生效

(3) Permission（权限）

含义：定义操作级别，分三级权限。

配置选项：

权限	操作范围	示例
`View`	读取属性（如状态查询）	读取灯泡开关状态
`Operate`	触发命令（如开关控制）	发送 `Toggle` 命令
`Manage`	管理 ACL（如增删规则）	允许添加新控制设备

案例模板：

Permission: Operate# 允许触发命令（如开关灯泡）

(4) AuthMode（认证模式）

含义：设备间通信的安全认证方式。
配置选项：

模式 适用场景 安全性
PASE 配网阶段临时认证（如扫码配对）中低
CASE 运行时长期认证（如设备间控制）高

模式	适用场景	安全性
`PASE`	配网阶段临时认证（如扫码配对）	中低
`CASE`	运行时长期认证（如设备间控制）	高

案例模板：

AuthMode: CASE# 高安全场景（如门锁控制）

2. 特殊配置注意事项

(1) 桥接设备配置

非 Matter 设备（如 Zigbee 传感器）需通过桥接接入：

桥接端点映射：将 Zigbee 设备映射为 Matter 端点和 Cluster。

案例片段：效果：Zigbee 传感器可触发 Matter 灯泡。

Bridge:Endpoint: 2DescriptorCluster:DeviceType: MotionSensor# 映射为运动传感器ServerList: OccupancySensing# 支持占用感知 Cluster

(2) 权限冲突解决

当多条规则冲突时，精确匹配优先：

# 规则 1：允许所有设备查看灯泡状态ACE1:Subject: Fabric:AllTarget: Endpoint:1Permission: View# 规则 2：禁止特定开关操作灯泡ACE2:Subject: 0x999# 优先级高于 ACE1Target: Endpoint:1Permission: Deny# 显式拒绝

3. 调试技巧

ACL 验证工具：使用 chip-tool 发送测试命令：
```
./chip-tool onoff toggle 0x123 1 --paakeyt 123456
```
日志分析：检查设备日志中的 Access Control 模块，确认规则匹配结果。

chip-tool是Matter测试条件中的一个工具，另一篇文章中介绍该工具的具体使用。

Matter 测试套件chip-tool

4. 安全实现

Matter ACL 通过 主体-目标-权限-认证 四元组实现精细控制，开发者需注意：

最小权限原则：避免滥用 Manage 权限。
认证分级：门锁等设备强制使用 CASE。
桥接兼容：非 Matter 设备需完整映射端点和 Cluster

在实际开发场景中，业务和开发为了偷懒会直接所有设备端点都设置为"endpoint": 0，也就是控制网络中所有设备都是根端点，就会导致所有设备都是管理员权限；

下面给一个完整Matter网络ACL权限控制列表：

{"acl": {// ACL元数据"version": "Matter-1.3",  // 遵循的规范版本"fabric": "0xABCD1234",   // 所属生态域标识符"description": "智能家居设备控制策略","accessControlEntries": [{// 规则1：手机App管理员权限"label": "Admin-FullAccess","subject": "0x789",     // 管理员设备Node ID"target": {"endpoint": 0,        // 设备根端点"cluster": "ACLServer" // 管理ACL的集群},"permission": "Manage", // 允许修改ACL规则"authMode": "CASE"      // 强制证书认证[1](@ref)},{// 规则2：运动传感器联动所有调光灯"label": "Sensor-LightControl","subject": "0x456",     // 传感器Node ID"target": {"deviceType": "DimmableLight", // 目标设备类型"cluster": "LevelControlServer" // 亮度控制集群},"permission": "Operate", // 允许调整亮度"authMode": "CASE"       // 高安全认证[2](@ref)},{// 规则3：开关控制特定灯泡"label": "Switch-Bulb1","subject": "0x123",     // 开关Node ID"target": {"endpoint": 1,        // 灯泡端点"cluster": "OnOffServer" // 开关集群},"permission": "Operate", // 允许开关命令"authMode": "CASE"       // 标准认证[1](@ref)},{// 规则4：桥接Zigbee传感器只读权限"label": "Bridge-Sensor-Read","subject": "0x555",     // 桥接设备Node ID"target": {"endpoint": 2,        // 映射端点"cluster": "OccupancySensing" // 占用感知集群},"permission": "View",    // 仅允许读取状态"authMode": "PASE"       // 配网阶段临时认证[1](@ref)},{// 规则5：显式拒绝未知设备"label": "Deny-Unknown","subject": "Fabric:All", // 所有设备"target": {"deviceType": "DoorLock" // 门锁设备},"permission": "Deny",    // 显式拒绝访问"authMode": "CASE"       // 强制生效}],// 特殊配置区"securityParameters": {"certificateMode": "PAA-TRUST", // 使用根证书信任链[1](@ref)"groupKeyRotation": 3600        // 组密钥轮换周期(秒)}
}