1. Matter安全架构概览：安全模型、信任根与DCL、安全域与节点角色

各位好，我是老周。今天咱们开始聊Matter安全架构。

说实话，Matter协议最让我佩服的就是它的安全设计。它不是那种「先上线再补安全」的思路，而是从骨子里就把安全嵌进去了。我参与过几个智能家居项目，见过太多「设备配网五分钟，安全漏洞一箩筐」的案例。Matter这套架构，说白了就是要把这些坑一次性填平。

1.1 Matter安全模型：三层防御

Matter的安全模型，我习惯把它理解成「三道门」。

层级	名称	核心作用	我踩过的坑
第一层	设备认证	确保设备是合法的，不是山寨货	曾经有客户用自签证书，结果DCL验证死活过不去
第二层	通信加密	所有消息都加密，中间人攻击无效	记得有一次抓包发现明文，原来是CASE会话没建立成功
第三层	访问控制	谁可以操作哪个设备，精确到每个端点	ACL配置错了，管理员删不掉自己的设备，尴尬

这三层不是独立的。它们环环相扣。设备认证不过，通信加密就无从谈起。通信加密没建立，访问控制就是个摆设。嗯，这里要注意，很多新手只盯着加密算法，忽略了认证和ACL，结果出问题的时候一脸懵。

1.2 信任根与分布式合规账本（DCL）

信任根是什么？说白了就是「谁说了算」。

Matter的信任根是CSA（Connectivity Standards Alliance）维护的。每个合法的Matter设备，出厂时都要烧录一个设备证书（DAC）。这个证书的根，就是CSA的根证书。

但问题来了——谁来证明这个证书是真的？

这就是DCL的活。DCL全称Distributed Compliance Ledger，分布式合规账本。它本质上是一个区块链，记录了所有通过认证的设备信息。

DCL的查询流程是这样的：

1. 手机App发起配网
2. 设备把自己的DAC证书发过来
3. App去DCL查这个证书的哈希值是否存在
4. 如果存在，继续；如果不存在，直接拒绝

我曾经遇到一个案例：客户说「我的设备明明烧录了证书，为什么连不上？」我查了半天，发现DCL上根本没有这个产品的记录。原来是他们送测的样品和量产版的PID不一致。这种坑，你不踩一次真的想不到。

1.3 安全域与节点角色

Matter把整个网络划分成不同的安全域。每个域有自己的信任根和操作权限。

安全域	包含内容	信任根
Fabric域	同一个Matter网络的所有设备	Fabric根证书
管理域	管理员和Commissioner	管理员证书
操作域	普通用户设备	节点证书

节点角色这块，我建议你记住三个核心角色：

• Commissioner（配网器）：负责把新设备拉进网络。通常是手机App或智能音箱。
• Controller（控制器）：可以操作设备，但不能配网。比如一个开关面板。
• Device（设备）：被控制的终端，比如灯泡、插座。

你想想看，这种设计有什么好处？

举个例子：你家有个智能门锁（设备），你的手机（Controller）可以开锁。但如果有人黑进了你的灯泡，灯泡是没法开锁的，因为它没有那个权限。这就是安全域隔离的价值。

1.4 整体架构图

下面这张图是我自己画的Matter安全架构概览。你看一眼，基本就能把上面说的串起来。

这张图我建议你保存下来。每次排查安全故障的时候，对着图一层一层查：

• 设备认证过了吗？→ 查DCL
• 通信加密建立了吗？→ 查CASE/PASE会话
• 访问控制允许吗？→ 查ACL配置

按这个顺序查，90%的安全问题都能定位。剩下的10%，嗯，那就要看具体场景了，后面章节我会一个个讲。