3、通信加密与密钥管理：Matter的加密套件与密钥生命周期

加密这事儿，说白了就是Matter设备的“防偷听”和“防篡改”机制。我在做Zigbee产品时就吃过亏——密钥管理没做好，设备被中间人攻击，整个网络都得重新入网。到了Matter，协议层把加密套件和密钥生命周期定义得非常清楚，咱们照着做就行。

3.1 核心加密套件：AES-CCM、ECDH、HKDF

Matter用了三个核心算法，各司其职。我习惯把它们分成“加密认证”、“密钥协商”和“密钥派生”三块。

算法	作用	Matter中的使用场景
AES-CCM	加密 + 完整性校验	所有应用层数据帧、CASESession、Group消息
ECDH	密钥协商（P256曲线）	PASE / CASE 握手阶段，生成共享秘密
HKDF	密钥派生（基于SHA-256）	从共享秘密派生出会话密钥、Group密钥

嗯，这里要注意——AES-CCM的nonce构造。Matter把nonce拆成两部分：前8字节是帧计数器（递增防重放），后5字节是随机数。我在项目中遇到过有人把nonce写死，结果重放攻击直接打穿。千万别这么干。

3.2 会话密钥的派生与更新

Matter的会话密钥不是一成不变的。每次设备建立安全通道（PASE或CASE），都会走一遍完整的派生流程。

3.2.1 派生流程

1. ECDH握手：双方交换公钥，计算共享秘密 SharedSecret = ECDH(私钥, 对方公钥)
2. HKDF-Expand：以SharedSecret为输入材料，加上会话上下文（Session ID、随机数等），派生出 SessionKey
3. 拆分密钥：SessionKey被拆成加密密钥（AES-CCM Enc Key）和完整性密钥（AES-CCM MIC Key）

// 伪代码示意：Matter会话密钥派生
shared_secret = ecdh_derive(my_private_key, peer_public_key)
salt = "Matter Session Key"  // 固定盐值
info = session_id || initiator_random || responder_random
session_key = hkdf_expand(shared_secret, salt, info, 16)  // 128位
enc_key = session_key[0:8]
mic_key = session_key[8:16]

3.2.2 密钥更新机制

Matter支持两种更新方式：

• 主动更新：设备检测到帧计数器接近上限（2^32 - 1），发起新的CASE握手，重新派生密钥
• 被动更新：管理员主动下发 UpdateSessionKey 指令，强制设备更新

我个人建议，在固件里把帧计数器阈值设在2^31左右就触发更新。别等到快溢出了才处理，万一网络延迟导致计数器溢出，整个会话就断了。

3.3 Group Key的广播机制

Group Key是Matter里比较有意思的设计。它解决的是“一对多”加密问题——一个灯控指令，要同时发给10个灯泡，总不能建10条独立加密通道吧？

3.3.1 Group Key结构

每个Group Key包含两个部分：

字段	长度	说明
Group Key ID	2字节	全局唯一标识
Group Key Value	16字节	AES-CCM 128位密钥
Group Key Hash	4字节	用于快速校验密钥是否匹配

3.3.2 广播流程

1. 密钥分发：管理员通过单播安全通道，把Group Key分发给每个组成员
2. 组播加密：发送方用Group Key加密消息，通过UDP组播地址（IPv6 FF02::1）发出
3. 接收方解密：组成员收到组播包，用本地存储的Group Key解密

3.3.3 密钥更新与撤销

Group Key也需要更新。Matter的做法是：

• 管理员生成新Group Key，通过单播通道分发给所有组成员
• 旧Key保留一段时间（默认30秒），用于处理正在传输中的消息
• 超时后，设备删除旧Key

嗯，这里有个细节——如果某个设备离线了，没收到新Key怎么办？Matter的机制是：设备重新上线后，会主动向管理员请求最新的Group Key列表。所以你的固件里一定要实现这个重请求逻辑。

3.4 知识体系总览

下面这张图把本章的核心逻辑串起来了。我建议你保存下来，做开发时对照着看。