企业官网建设流程全解析

什么是 CASE

CASE 是 Certificate Authenticated Session Establishment 的简称，可以翻译成“基于证书认证的会话建立”。

通俗理解：两个已经加入同一个 Matter Fabric 的节点，在正式通信前，先互相验明身份，再各自计算出本次通信要用的临时会话密钥。

它要解决三件事：

1. 确认身份：对方是不是同一个 Fabric 里的合法节点？
2. 协商密钥：这次通信用哪组临时加密密钥？
3. 建立安全会话：后面的 Read / Write / Invoke / Subscribe 都走这个加密通道。

这里有一个关键点：CASE 不会把最终会话密钥直接发给对方。双方只交换公钥、随机数、证书和签名，然后用相同算法在本地算出同一组密钥。

CASE 会话建立

下面以 Home Assistant / Matter Server 和 Matter Bridge 之间建立 CASE 会话为例。

参与方

在 Matter 里，CASE 通常用于已经完成配网和入网的节点之间。比如 Controller 已经给 Bridge 发过 NOC，双方都知道同一个 Fabric 的相关信息。

第一步：Sigma1，Initiator 发起

Home Assistant / Matter Server 作为 Initiator，会先准备这些材料：

1. 生成临时 ECDH key pair
   1. InitiatorEphemeralPrivateKey
   2. InitiatorEphemeralPublicKey
2. 生成 InitiatorRandom。
3. 分配 InitiatorSessionId。
4. 计算 DestinationId。
5. 可选：如果要尝试会话恢复，还会带上 ResumptionID / InitiatorResumeMIC。

然后发出 Sigma1：

┌──────────────────────────────┐ │ Sigma1 │ ├──────────────────────────────┤ │ InitiatorRandom │ │ InitiatorSessionId │ │ DestinationId │ │ InitiatorEphemeralPublicKey │ │ option: Session Parameters │ │ option: Resumption Info │ └──────────────────────────────┘

DestinationId 是什么
白话理解：DestinationId 是 Initiator 用来告诉对方“我找的是某个 Fabric 里的某个目标节点”，但又不想把 Fabric ID、Node ID 这些身份信息直接裸露在网络上。
Responder 收到 Sigma1 后，会拿自己 Fabric Table 里的信息逐个计算和匹配。如果能匹配上，说明这个请求大概率是找自己的某个 Fabric 身份。
如果 DestinationId 匹配不上，常见原因是：

1. Home Assistant 和 Bridge 不在同一个 Fabric。
2. 目标 Node ID 不对。
3. IPK 不一致。
4. Fabric 信息不一致。
5. Controller 找错设备或找错 Fabric。

第二步：Sigma2，Responder 回复

Matter Bridge 收到 Sigma1 后，会做这些事情：

1. 用自己的 Fabric Table 信息和 IPK 尝试匹配 DestinationId。
2. 找到匹配的 Fabric。
3. 生成自己的临时 ECDH key pair。
4. 用 ResponderEphemeralPrivateKey 和 InitiatorEphemeralPublicKey 计算 ECDH SharedSecret。
5. 准备自己的证书和签名证明材料。
6. 派生一个临时加密密钥，用来加密 Sigma2 里的 Encrypted2。
7. 发送 Sigma2。

Sigma2 大致包含：

┌──────────────────────────────┐ │ Sigma2 │ ├──────────────────────────────┤ │ ResponderRandom │ │ ResponderSessionId │ │ ResponderEphemeralPublicKey │ │ Encrypted2 │ │ option: Session Parameters │ │ option: Resumption Info │ └──────────────────────────────┘

Encrypted2 里可以通俗理解成 Bridge 的身份材料：

1. Bridge 的 NOC。
2. Bridge 的 ICAC，如果证书链里有中间 CA。
3. Bridge 的签名。
4. 可选的会话恢复相关信息。

这个签名的作用是证明：Bridge 不只是拿到了一张 NOC，它还确实拥有这张 NOC 对应的 Operational Private Key。

注意：Sigma2 阶段用来加密 Encrypted2 的密钥，还不是最终业务通信使用的 I2RKey / R2IKey。它是握手过程中的临时密钥。

第三步：Initiator 验证 Sigma2

Home Assistant 收到 Sigma2 后，会做两类事情。

第一类是计算同一个 SharedSecret。

Home Assistant 有自己的临时私钥和 Bridge 的临时公钥；Bridge 有自己的临时私钥和 Home Assistant 的临时公钥。由于 ECDH 的数学性质，双方可以算出同一个 SharedSecret。

第二类是验证 Bridge 身份。

Home Assistant 要验证：

1. Bridge 的 NOC 是否属于同一个 Fabric。
2. NOC / ICAC / Root CA 证书链是否可信。
3. Bridge 的签名是否正确。
4. Bridge 是否真的拥有 NOC 对应的 Operational Private Key。
5. Fabric ID / Node ID 是否符合预期。
6. Sigma1 / Sigma2 的 transcript 是否一致，防止握手消息被篡改。

如果这些验证失败，Home Assistant 通常不会继续发送有效的 Sigma3。

第四步：Sigma3，Initiator 证明自己

Home Assistant 验证 Bridge 通过后，会把自己的证明材料放到 Encrypted3 里发给 Bridge。

Encrypted3 里可以通俗理解成 Home Assistant 的身份材料：

1. Home Assistant 的 NOC。
2. Home Assistant 的 ICAC，如果证书链里有中间 CA。
3. Home Assistant 的签名。

它的作用是向 Bridge 证明：“我也是这个 Fabric 里的合法节点，而且我拥有这张 NOC 对应的 Operational Private Key。”

Bridge 收到 Sigma3 后，也会做类似验证：

1. 验证 Home Assistant 的证书链。
2. 验证 Home Assistant 的签名。
3. 确认证书里的 Fabric ID / Node ID 是否合理。
4. 确认 transcript 没有被篡改。

验证通过后，双方才会进入真正的安全会话。

CASE 的密钥到底是怎么派生的？

CASE 里容易混淆的是：握手过程中有临时加密密钥，握手完成后还有真正的会话密钥。

1. ECDH 先得到 SharedSecret

双方各自用“自己的临时私钥 + 对方的临时公钥”计算出同一个 ECDH SharedSecret。

Initiator: InitiatorEphemeralPrivateKey + ResponderEphemeralPublicKey -> SharedSecret Responder: ResponderEphemeralPrivateKey + InitiatorEphemeralPublicKey -> SharedSecret

SharedSecret 不会在网络上传输。

2. 握手阶段派生 Sigma2 / Sigma3 临时加密密钥

Sigma2 的 Encrypted2 和 Sigma3 的 Encrypted3 都是加密的。为了加密这些字段，双方会基于 SharedSecret、随机数和握手 transcript 派生握手阶段的临时密钥。

这类密钥只用于保护 CASE 握手里的身份材料，不是后续业务报文使用的最终会话密钥。

3. 握手完成后派生最终会话密钥

双方会把以下材料放进 HKDF 这类密钥派生过程：

1. ECDH SharedSecret。
2. IPK。
3. Sigma1 / Sigma2 / Sigma3 的 transcript hash。
4. 会话建立相关信息。

最终派生出安全会话要用的材料，核心包括：

1. I2RKey：Initiator -> Responder 方向的加密密钥。
2. R2IKey：Responder -> Initiator 方向的加密密钥。
3. AttestationChallenge：与该安全会话绑定的挑战值，供需要会话绑定挑战的上层流程使用。它不是一个方向加密密钥。

Matter SDK 中，CASESession 会在握手完成后调用类似DeriveSecureSession的逻辑，把 SharedSecret、IPK 和 transcript 相关摘要输入到密钥派生流程。CryptoContext 再根据本端角色分配 I2R / R2I 方向密钥，并派生 session keys 和 attestation challenge。

再次强调：CASE 不是把密钥发过去，而是双方通过相同输入和相同算法，各自在本地算出同一组密钥。

CASE 报文中的关键字段解释

Sigma1

Sigma2

Sigma3

CASE 成功后会发生什么

CASE 成功后，双方会保存一个安全会话上下文。这个上下文里通常包含：

1. 本端 Session ID。
2. 对端 Session ID。
3. Peer Node ID。
4. Fabric Index。
5. I2RKey / R2IKey。
6. 消息计数器和重放保护状态。

后续 Interaction Model 报文，例如 Read / Write / Invoke / Subscribe，会使用这个安全会话进行加密、认证和重放保护。

CASE 失败常见原因

如果 CASE 建立失败，通常不是 I2RKey / R2IKey “不知道”，而是前面的输入或身份验证不一致。

调试日志建议

在 HA / Matter Server 侧找：

CASE session establishment Sigma1 sent Sigma2 received Sigma3 sent Secure session established Failed to establish CASE Peer node id Fabric index Session id

在 Bridge 侧找：

Received Sigma1 Found matching fabric Sending Sigma2 Received Sigma3 CASE session established Allocated secure session Peer node id Local session id Peer session id

排查时建议按这个顺序看：

1. Sigma1 是否发出。
2. Bridge 是否匹配到 Fabric 和 DestinationId。
3. Sigma2 是否发回。
4. Home Assistant 是否通过 Bridge 的 NOC 和签名验证。
5. Sigma3 是否发出。
6. Bridge 是否通过 Home Assistant 的 NOC 和签名验证。
7. 是否创建 Secure Session。
8. CASE 成功后，业务报文失败时再看 ACL、Endpoint、Cluster 和 Bridge 映射。