MLS 消息层安全协议：树形密钥分发与端到端组加密标准

协议详解 · 2026-09-18

概述

在现代即时通讯应用中，端到端加密（E2EE）已成为用户隐私保护的基础设施。然而，当通信从一对一扩展到一对多时，密钥管理面临指数级复杂度挑战。

MLS（Messaging Layer Security，RFC 9420） 是 IETF 标准化工作组为解决这一挑战而设计的组通信安全协议。与 Signal 协议依赖 O(N) 双边会话的扩展方式不同，MLS 采用 Ratchet Tree（棘轮树） 结构，将组成员更新的通信开销降至 O(log N)。

MLS 于 2023 年 7 月正式发布为 RFC 9420，配套架构规范为 RFC 9750。截至 2026 年，该协议已被 Cisco Webex、Google Messages over RCS、Apple iMessage over RCS 3.0 等多个平台部署，标志着组通信安全进入标准化时代。

历史演进：从信号协议到 MLS

信号协议的组密钥扩展困境

Signal 协议通过 Double Ratchet（双棘轮） 机制实现一对一会话的前向保密与后破损安全（Post-Compromise Security, PCS）。然而，当扩展到组通信时，Signal 采用以下策略：

CODE

Sender Key = 对称密钥链，由发送方广播给所有成员
每次成员变更 = O(N) 次双边加密操作

这意味着在 1000 人组中，每添加一个成员需要执行 1000 次加密操作。对于超大规模群组（如抗议组织、新闻媒体来源保护），这一复杂度不可接受。

MLS 的树形创新

MLS 的核心创新在于引入 TreeKEM（Tree-based Key Encapsulation Mechanism）：

维度	Signal 组扩展	MLS
密钥模型	N 对双边会话 + Sender Key	单一共享 TreeKEM 状态
组成员更新复杂度	O(N)	O(log N)
1000 人组更新成本	1000 次加密	~10 次加密
前向保密	依赖于双边密钥更新频率	每个 Commit 生成新 root key
后破损安全	依赖下一个活跃发送者	自动触发，不依赖特定成员

标准化历程

CODE

2017-2019    draft-ietf-mls-protocol     IETF MLS 工作组成立
2021-2022    RFC 9420 草案迭代          形式化安全分析完成
2023-07      RFC 9420 正式发布           互联网标准（Standards Track）
2023-07      RFC 9750 发布              MLS 架构规范
2025         Webex/Google/Apple 大规模部署开始

核心架构概念

Group 与 Epoch

MLS 的基本抽象是两个核心概念：Group 和 Epoch。

CODE

Group = {成员集合, 当前 Epoch, Ratchet Tree}
Epoch = 一次组成员状态变更后的版本编号

Group：逻辑上的成员集合，共享同一份密钥状态
Epoch：线性时间序列，每个 Epoch 对应一次 Commit 操作后的一组成员状态

每个 Epoch 拥有独立的 Ratchet Tree，这是 MLS 实现高效组成员管理的关键数据结构。

Ratchet Tree（棘轮树）

Ratchet Tree 是一棵完全二叉树，每个叶子节点代表一个组成员，内部节点存储派生密钥。

CODE

[root] ← epoch_secret
                   /      \
              [node_L]    [node_R]
             /      \      /      \
          [leaf_A] [leaf_B] [leaf_C] [leaf_D]
           Alice    Bob    Carol    Dave

密钥派生规则：

CODE

key(node) = HKDFExpand(key(left_child) || key(right_child), label, info)

叶子节点持有自身的 HPKE 密钥对
内部节点的密钥由子节点密钥派生
root 节点密钥即为 epoch_secret（epoch 秘密）

核心安全属性

MLS 提供两种关键安全保证：

前向保密（Forward Secrecy, FS）：攻击者获取当前所有成员密钥后，无法解密之前的历史消息
后破损安全（Post-Compromise Security, PCS）：某个成员被破解后，下一次 Commit 即可恢复安全性

这两个属性通过 epoch_secret 的周期性刷新 实现：每次 Commit 都生成新的 root key，并销毁旧的密钥链。

协议工作流详解

组成员初始化

当客户端创建新组时，流程如下：

CODE

1. 客户端向 DS（Delivery Service）请求其他成员的 KeyPackage
2. 客户端验证 KeyPackage 的签名（防止伪造）
3. 客户端将 KeyPackage 作为 Add Proposal 包含在 Commit 中
4. 客户端生成新的 LeafNode 密钥对，更新 Ratchet Tree 路径
5. 客户端通过 HPKE 加密路径密钥，生成 Welcome 消息
6. Welcome 消息发送给新成员（一对一通道）
7. Commit 消息广播给所有现有成员

Commit 消息处理

Commit 是 MLS 的核心操作，用于执行组状态变更：

PYTHON

# 伪代码：Commit 消息处理流程
def process_commit(commit_msg):
    # 1. 验证 Commit 签名
    assert verify_signature(commit_msg.sender_key, commit_msg.signature)
    
    # 2. 解析 Proposals 列表
    proposals = commit_msg.proposals
    
    # 3. 应用到本地 Ratchet Tree
    for proposal in proposals:
        apply_proposal(proposal)
    
    # 4. 重新计算路径密钥
    new_path_keys = update_ratchet_tree_path(commit_msg.sender_leaf)
    
    # 5. 更新 epoch_secret
    epoch_secret = derive_epoch_secret(new_path_keys.root)
    
    return epoch_secret

密钥调度管线

MLS 使用 HPKE 作为 KEM 基础，构建完整的密钥调度体系：

CODE

Group Context
    ↓
Transcript Hash（会话上下文哈希）
    ↓
init_secret（初始秘密）← 来自 External Init 或 Resumption PSK
    ↓
epoch_secret（epoch 秘密）← 从 init_secret 派生
    ↓
├── encryption_secret（加密密钥）
│   ↓
│   Secret Tree（每成员每消息的 AEAD 密钥）
│
├── exporter_secret（导出密钥）
│   ↓
│   供其他协议使用（如 MLS 扩展）
│
└── resumption_psk_secret（恢复预共享密钥）
    ↓
    用于快速恢复会话

消息封装格式

MLS 定义两种消息封装类型：

消息类型	加密	认证	用途
PrivateMessage	✓	✓	应用数据、握手消息（推荐）
PublicMessage	✗	✓	仅签名的提案和 Commit（允许 DS 审查）

CODE

MLSMessage {
    PublicMessage  public;    // 未加密，仅签名
    PrivateMessage private;   // 加密+签名
}

PrivateMessage {
    epoch: EpochNumber;
    nonce: Nonce;
    ciphertext: HPKE_Sealed;  // AES-GCM 或 ChaCha20-Poly1305
}

Cipher Suite 设计

MLS 支持多种密码套件组合，定义在 RFC 9420 第 17.1 节：

Suite ID	KEM	KDF	AEAD	Hash	Signature
0x0001	HPKE_P256	HKDF_SHA256	AES_128_GCM	SHA256	ECDSA
0x0002	HPKE_P256	HKDF_SHA256	AES_128_GCM	SHA256	Ed25519
0x0003	HPKE_P256	HKDF_SHA256	ChaCha20_Poly1305	SHA256	ECDSA
0x0004	HPKE_P256	HKDF_SHA256	ChaCha20_Poly1305	SHA256	Ed25519
0x0005	HPKE_P384	HKDF_SHA384	AES_256_GCM	SHA384	ECDSA
0x0006	HPKE_P384	HKDF_SHA384	AES_256_GCM	SHA384	Ed448

国密适配现状：RFC 9420 未标准化任何国密算法实例。如需使用 SM2/SM3/SM4 组合，必须定义私有 Suite ID（0xFE00-0xFFFF 范围），并通过自定义扩展实现兼容性。

与相关协议的架构对比

MLS vs Signal 协议

特性	MLS (RFC 9420)	Signal Protocol
标准化状态	IETF Standards Track	事实标准，无正式 RFC
组通信模型	TreeKEM，O(log N)	双边会话 + Sender Key，O(N)
初始握手	KeyPackage + Welcome	X3DH + PreKey
持续消息 ratchet	Secret Tree + Ratchet	Double Ratchet
后破损安全	自动（Commit 即重置）	依赖下一个活跃发送者
服务器角色	DS 负责消息分发	Server 不接触密钥
生产部署	Webex, Google RCS, Apple RCS	WhatsApp, Signal, iMessage

MLS vs TLS 1.3

特性	MLS	TLS 1.3
通信模型	多方组通信	点对点客户端-服务器
密钥分发	Ratchet Tree（异步）	单轮握手（同步）
前向保密	每个 epoch 独立	通过 ephemeral DH
适用场景	群聊、协作应用	HTTPS、API 调用

MLS 与 HPKE 的关系

MLS 将 HPKE（RFC 9180）作为其 KEM 层：

CODE

HPKE Base Mode = MLS 的单向加密基础
MLS Group Context = HPKE 的多人扩展版本

关键差异：

HPKE 是点对点封装，MLS 是多点封装
MLS 引入 TreeKEM 实现高效的多人密钥分发
MLS 定义完整的密钥调度管线，HPKE 仅提供 KEM+KDF+AEAD 三元组

工程实践要点

交付服务（DS）的角色

MLS 架构将密钥分发从协议中分离，委托给 Delivery Service（DS）：

CODE

DS 的职责：
1. 消息持久化与可靠投递
2. KeyPackage 目录服务
3. 群组创建通知
4. 离线消息队列

DS 不接触：
- 消息内容（端到端加密）
- 组成员密钥
- 握手元数据（若使用 PrivateMessage）

KeyPackage 管理策略

KeyPackage 是客户端的"入组凭证"，包含：

HPKE 公钥（用于接收 Welcome 消息）
签名公钥（用于组成员身份认证）
能力列表（支持的协议版本、密码套件等）

最佳实践：

定期更新 KeyPackage 并上传到 DS
每个 KeyPackage 仅使用一次（防重放）
保留少量 "last resort" KeyPackage 用于紧急情况

性能基准估算

基于 TreeKEM 结构的复杂度分析：

组成员数 N	Update 加密操作数	Welcome 加密操作数
10	3-4	1
100	6-7	1
1,000	10	1
10,000	13-14	1
100,000	17-18	1

对比 Signal 协议：

组成员数 N	Signal Sender Key 加密操作数
10	10
100	100
1,000	1,000
10,000	10,000

已知工程陷阱

KeyPackage 重用攻击：若同一 KeyPackage 被用于多个组的加入，攻击者可关联跨组身份。修复：强制 KeyPackage 一次性使用。

Ratchet Tree 不平衡：非平衡树会导致路径更新复杂度退化至 O(N)。修复：强制完全二叉树结构。

Epoch 重放攻击：旧 Epoch 的 Commit 消息可能重放。修复：维护已处理 Epoch 的哈希列表。

国密适配困难：RFC 9420 无国密实例，自定义 Suite 需解决 KeyPackage 签名验证、HPKE 兼容性等问题。

国密视角：适配挑战与路径

当前状态

RFC 9420 未标准化任何国密算法组合。若要在国密环境中部署 MLS，需要：

CODE

自定义 Cipher Suite 映射：
KEM:        HPKE_SM2（需定义 SM2 KEM 变体）
KDF:        HKDF-SM3
AEAD:       SM4-GCM 或 SM4-CTR + HMAC-SM3
Hash:       SM3
Signature:  SM2 签名
Suite ID:   0xFE01（私有范围）

关键技术障碍

SM2 KEM 标准化缺失：GM/T 0003.4-2012 定义 SM2 加密，但未明确 KEM 封装接口
SM4-GCM 库支持不足：标准 cryptography 库不支持 SM4-GCM，需使用 Tongsuo/BabaSSL
KeyPackage 签名兼容：SM2 签名算法与 MLS 默认 Ed25519/ECDSA 互操作性差

替代方案建议

在国密合规场景下，可考虑以下替代路径：

需求	推荐方案	说明
简单组通信	GM/T 0024（国密 TLS）+ 应用层信封	利用现有 TLS 基础设施
大规模群组	自定义 TreeKEM + SM2/SM4	需自研或等待 IETF 国密扩展
快速落地	Signal 协议 + 国密 TLS 传输层	加密层用国际标准，传输层用国密

MLS 消息层安全协议：树形密钥分发与端到端组加密标准

概述

历史演进：从信号协议到 MLS

信号协议的组密钥扩展困境

MLS 的树形创新

标准化历程

核心架构概念

Group 与 Epoch

Ratchet Tree（棘轮树）

核心安全属性

协议工作流详解

组成员初始化

Commit 消息处理

密钥调度管线

消息封装格式

Cipher Suite 设计

与相关协议的架构对比

MLS vs Signal 协议

MLS vs TLS 1.3

MLS 与 HPKE 的关系

工程实践要点

交付服务（DS）的角色

KeyPackage 管理策略

性能基准估算

已知工程陷阱

国密视角：适配挑战与路径

当前状态

关键技术障碍

替代方案建议

参考文献

相关实践