摘要

  • MLS 群组成员都能计算相应时期内各发送链的公共封装 AEAD 密钥，因此密文成功打开只证明某个群组密钥持有者具备生成能力，并不锁定某一客户端。
  • 客户端签名提供更强的来源证据；身份服务的绑定、应用层的授权、交付服务的送达和现实中的结果仍需各自的凭据。
  • 新时期能够更新密码学状态，却不是自动生成的事件结案证明。恢复必须说明哪类秘密受损，以及移除、吊销、收敛和业务结果分别如何确认。

设想一个高压应急群组：一条改变操作计划的消息突然出现。系统显示“认证成功”，值班人员于是把四件事连在一起——消息来自某位负责人，该负责人当时仍有权限，全部终端已经收到，现场也会照此执行。实际上，界面可能只知道最前面的一小段：一层密码学封装能够被打开。

RFC 9750 对 Messaging Layer Security 的架构说明给出了一个很少被管理界面忠实保留的边界。MLS 的群组成员拥有群组秘密，因此能够计算当期所有发送链所需的 AEAD 密钥。公共封装的认证在这个特定意义上是“弱”的：成功解密能够保证消息来自某个群组成员，或来自已经取得相关 AEAD 材料的攻击者，却不能从所有可能持有者中选出唯一客户端。

这不是算法没有完成承诺，而是共享能力只能产生集合层面的证据。只要多个主体都能计算同一类密钥，验证结果就只能把来源缩小到这个能力集合。将其展示成“某某发送”不是额外的密码学成果，而是系统或分析者添加的推断。

两道密码学检验不能合成一个词

RFC 9420 规定每条消息还要带有数字签名。成员发送时，验证者使用指定叶索引对应 LeafNode 中的签名密钥。签名覆盖消息内容、线上表示以及当前时期的 GroupContext，使消息与某一群组状态中的具体签名能力相连。

这道检验比共享 AEAD 更能说明来源。如果攻击者只拿到 AEAD 秘密，可能构造能够通过封装检验的密文；没有有效客户端的签名能力，就不能把它伪装成该客户端。相反，签名私钥泄露会直接冲击归因。即使私钥值从未离开硬件，如果攻击者能调用一个按其请求签名的接口，实际危害也可能与取走密钥相近。

因此，审计记录应分别保留“AEAD 打开”“时期与代次接受”“重放检查通过”“指定叶索引的签名通过”。把它们压成一个“已认证”字段，看似简化了运维，实则删除了事件调查最需要的差异：攻击者究竟取得了群组能力，还是取得了特定客户端能力？

RFC 9750 建议优先保护签名私钥，并讨论硬件安全模块或安全隔离区。群组秘密频繁变化，未必适合完全相同的保护方式。管理层不应因为两者都叫“密钥”便要求一套抽象策略，而应按生命周期、调用方式和失陷后果分配保护强度。

签名指向客户端，身份仍由另一套制度产生

MLS 的基本单位是客户端，不是自然人。一个用户可以拥有多台设备，每台设备都有自己的签名密钥。认证服务负责签发凭据、把凭据中的身份与公钥同参考标识相比较，并判断两份凭据是否代表同一客户端。这些决定围绕协议发生，却不是消息签名本身创造的事实。

有效签名加有效凭据，可以在认证服务的规则下确认一台客户端。它并不自动证明某个人亲手操作、某个组织职务当时仍然有效，或该动作获得了业务授权。自动化进程、委托使用、共享终端、尚未同步的离职状态，都可能留下完全正确的签名。

授权属于应用。RFC 9750 明确指出，MLS 本身并不执行群组操作的访问控制。谁可以新增成员、移除成员、批准内容或改变管理状态，应由应用策略定义。Proposal 描述拟议变化，Commit 才改变群组状态；两者即使在协议上有效，也不能单独充当“获授权负责人同意”的会议记录。

面向读者的措辞必须守住这条线。“客户端签名有效”是一项观察，“凭据与预期标识相符”是认证服务的判断，“该动作获得授权”则是应用策略的判断。用一个“可信”徽章覆盖三者，会让最底层的技术检验在视觉上借到它没有的组织权力。

密文到达一台设备，不等于群组收到

交付服务负责路由 MLS 消息并分发初始密钥材料。部署可以提供强排序，也可以采用最终一致性。一个故障或被控制的交付服务可能延迟、抑制消息，向不同客户端呈现不同的有效历史，或让成员对当前时期和选定的 Commit 发生分歧。MLS 希望它无法读取内容或伪造可接受的客户端消息，但机密性和来源验证不会自动带来可用性与收敛。

所以，一台客户端接受密文，并不能证明所有目标客户端都已拉取、按同一时期处理、显示给用户，或促成了行动。若组织要对“送达”作出承诺，就要拥有独立证据链：交付服务接收、扇出、逐客户端获取、密码学处理、状态收敛、读者可见呈现，以及必要时对现实结果的观察。

新客户端的加入最能暴露这种误差。Welcome 消息已经发出，不说明新设备已经收到或成功解密。直到它真正加入，并以其他成员可以验证的方式为群组秘密作出贡献，现有成员都不能把它当成已正常工作的群组成员。派发不是收件，收件不是解密，解密也不是全群状态一致。

事件恢复首先要说清是哪一种秘密

“已经轮换密钥”缺少最关键的主语。棘轮秘密受损，可能暴露某条发送链在本时期的当前和未来 AEAD 密钥，而被正确删除的过去密钥仍受保护。更广泛的群组秘密受损，可能影响多个受损时期的加解密。签名能力受损则改变客户端归因，需要处理不同的凭据与权限问题。

面对被动失陷，完成修复后的诚实 Commit 可以在协议给出的后失陷安全条件下推进到新时期。若攻击者仍主动参与协议，问题更难：在其余成员诚实的前提下，移除被攻陷的一方，才是为后续时期恢复机密性的关键操作。

即便如此，新时期只是密码学状态凭据，而不是事件结案收据。运维还必须证明受损客户端已被移除或更新，相关凭据在需要时已吊销，替代设备正确加入，应用权限恢复，目标成员完成收敛。与其说“系统已安全”，不如说“在移除指定客户端后，群组从上一时期推进到新时期；列出的终端已确认收敛”。较窄的陈述反而更可核验。

把证据梯子写进系统

可操作的记录至少要回答八个问题：密文是否成功解析并打开 AEAD；时期、代次和重放状态是否接受；发送者签名是否针对指定成员或允许的外部发送者通过；认证服务是否按预期参考标识验证凭据；该客户端是否属于当前群组；应用策略是否允许这项具体操作；交付服务和接收端是否给出所需的送达与处理凭据；所声称的人类或业务结果是否得到独立观察。

后一层可以依赖前一层，却不能由前一层冒名顶替。跨过任何一级都不是密码学捷径，而是新的分析判断。只要这个判断将推动纪律处分、资金转移、成员移除或事件结案，它就应拥有自己的数据来源与责任人。

RFC 9750 是信息类架构文档；RFC 9420 是标准轨道上的协议规范。它们没有证明任何具名产品已经实现这些边界，也没有报告某个实际攻击或测量结果。它们真正提供的是一套控制语言：每个结果必须保留产生它的机制范围。采购可以据此要求正确的日志，运维可以据此选择恢复动作，管理层也能避免把一个绿色状态扩写成整个组织都无法验证的故事。

来源