端到端加密的Zoom会议技术解析

# 端到端加密的Zoom会议技术解析 ## 1. 成员认证与Zoom的cmKEM方案 ### 1.1 成员认证 在许多操作中，如向现有会话添加用户或指示用户加入另一个会话时，对手可以提供相应的用户标识符。不过，安全机制确保对手无法冒充未被破坏的长期身份。也就是说，除非关联的长期身份ID已被破坏，否则对手无法注入临时用户UID。 ### 1.2 Zoom的cmKEM方案 Zoom的cmKEM方案采用点对点加密，通过循环群 \(G = \langle g \rangle\) 上的Diffie - Hellman密钥交换来向参与者传达新密钥。用户标识符UID主要由Diffie - Hellman公钥 \(upk \in G\) 、会议标识符的上下文数据、用户的长期身份ID、用户的长期公钥 \(ipk\) 以及用户长期签名密钥 \(isk\) 下的签名组成。相应的私钥 \(usk := DLog_g(upk)\) 作为协议状态的一部分存储。 对于每个时期（epoch），领导者采样一个新种子，通过迭代应用伪随机生成器（PRG）来推导该时期内各时间段的密钥和下一个时间段的种子。当移除参与者时，领导者启动下一个时期，并将新种子传达给所有剩余参与者。添加参与者时，若 `newEpoch = true` ，领导者将种子传达给所有参与者；若 `newEpoch = false` ，领导者仅将下一个密钥的种子发送给新加入的参与者，并指示其他参与者向前推进。 为了向一方发送种子，方案首先从自身私钥 \(usk\) 和接收者公钥 \(upk'\) 的Diffie - Hellman元素中为每个接收者推导出一个共享对称密钥，使用HKDF进行推导，并将其建模为随机预言机。为提高效率，该密钥作为发送者秘密状态的一部分进行缓存，用于未来与同一方的消息传输。种子使用基于随机数的AEAD加密，随机数作为密文的一部分传输，关联数据包含会议和发送者标识符以及固定上下文字符串。 服务器协议通过将相应的AEAD密文传递给每个参与方，并向未指定此类密文的参与方发送特殊的“棘轮周期”消息来工作。 ### 1.3 安全性 在Gap - DH假设下，如果AEAD方案安全、哈希具有抗碰撞性、签名方案满足EUF - CMA安全、PRG满足与随机的标准不可区分性，且HKDF被建模为随机预言机，Zoom的cmKEM方案是安全的。 Zoom的方案在Curve25519上执行Diffie - Hellman操作，使用XChaCha20Poly1305作为基于随机数的AEAD方案，HKDF用于密钥推导和PRG，签名方案采用EdDSA over Ed25519。 ## 2. 基于领导者的带活性的GCKA方案 ### 2.1 概述 将Zoom的端到端加密会议协议核心抽象为基于领导者的带活性的连续组密钥协商（LL - CGKA）方案。与cmKEM方案相比，它有以下不同： 1. 参与者了解群组名单，仅使用已知名单的密钥。 2. 参与者在时间段上不能领先于领导者。 3. 强制保证活性。 为实现活性，LL - CGKA方案基于时间，算法可依赖时间，除了基于事件的操作，还有时间驱动的操作。假设每个参与方有本地时钟，且运行速度相同，本地算法瞬间完成。 ### 2.2 语法 LL - CGKA方案的算法与cmKEM方案类似，但有两个主要区别：客户端算法将当前本地时间作为输入；有时钟滴答算法，用于指定时间驱动的操作。 服务器负责消息路由，并向新加入的参与方提供当前公共群组状态。LL - CGKA方案的算法包括： #### 用户管理 - `(ust, uid, sig) ← CreateUser(time, id, meetingId)`：为给定身份和会议创建临时用户，输出用户初始状态 \(ust\)、身份 \(uid\) 和绑定凭证 \(sig\)。 - `id ← Identity(uid)` 和 `meetingId ← Meeting(uid)`：分别返回临时用户的长期身份和会议。 - `ust′ ← CatchUp(ust, time, grpPub)`：处理服务器提供的当前公共群组状态，为用户加入群组做准备。 #### 领导者算法 - `(ust′, M) ← L