课程导论：联邦学习与多方密钥协商的背景、意义及应用场景
背景：隐私保护催生的新范式
联邦学习这几年火得不行。但很多人刚开始接触时，最容易忽略一个问题：「大家的模型参数在交换时，怎么保证安全？」
我2021年参与过一个医疗影像联合建模项目。几家医院数据不出院区，按理说很安全。可合作方突然问：「你们这模型梯度传过来，会不会泄露病人信息？」当场把我问住了。那时候我才意识到，光有联邦学习框架远远不够，通信加密和密钥协商才是真正的命门。
传统做法是中心服务器统一分发密钥，但训练节点一旦被攻破，整个通信就裸奔了。所以多方密钥协商要解决的核心矛盾是：
- 不需要可信第三方：每个参与方自己生成部分密钥
- 协商过程公开但不泄露：任何人都能看到协议交互，但拿不到最终密钥
- 容忍部分节点掉线：只要足够多节点在线，协议就能完成
意义：为什么非要多方密钥协商？
你想想看，联邦学习里每个客户端都要和服务器交换梯度参数。如果只用服务器生成的单一密钥，一旦服务器被黑，所有客户端的历史通信都能被解密。这不就白忙活了吗？
多方密钥协商的意义就在于「去中心化」。每个参与方贡献一点点随机数，共同拼出一把只有大家才能算出来的密钥。具体好处有三点：
- 前向安全性：就算攻击者拿到历史通信记录，只要没参与当时协商，就解不开密钥。
- 抗合谋攻击：只要大部分参与方诚实，少数合谋者无法推导出密钥。
- 动态节点可扩展：新节点加入联邦时，只需重新跑一轮协商，不必重启整个系统。
我记得在金融风控场景里，银行A和银行B要联合训练反欺诈模型。双方都不愿意把自己的私钥交给对方或第三方。我们用了一个基于Diffie-Hellman变种的多方协议，四轮交互就完成了密钥协商。说实话，调参过程踩了不少坑——比如某个银行节点用的椭圆曲线参数不兼容，导致协商卡死。后来我把参数检查前置到握手阶段，就再也没出过类似问题。
应用场景：什么地方最需要它？
下面这张表总结了我经历过的几种典型场景：
| 领域 | 联邦学习需求 | 密钥协商关键点 | 常见壁垒 |
|---|---|---|---|
| 医疗影像 | 多家医院联合训练诊断模型 | 病人敏感数据不出院区，密钥必须在医院间协商 | 医院网络结构差异大，端口不通 |
| 金融风控 | 银行/保险共享黑名单特征 | 交易流水是高度机密，需一次性协商密钥 | 合规审计要求日志可追溯 |
| 物联网边缘 | 智能设备协同训练语音模型 | 设备算力弱，密钥协商必须轻量 | 设备频繁上下线，掉线处理棘手 |
| 政务数据 | 不同部门联合统计 | 每个部门有独立CA，跨信任域协商 | 政策要求密钥必须国产化 |
以医疗场景为例。我曾给一家省级医疗集团做过方案，三甲医院之间要共享眼底影像特征。他们最初想用中心化密钥分发，结果监管直接否决——因为密钥掌握在牵头医院手里，其他医院等于交出数据控制权。后来我们用门限密钥协商：每家医院各自生成部分私钥，最终合成一把主密钥；而解密需要至少2/3的医院共同参与。这样任何一家医院都无法单独解密，监管也认可了。
关系图：联邦学习中的密钥协商流程
上面这张图是我画的一个简化架构。从左侧的客户端各自生成部分密钥，一方面与聚合服务器交互（梯度上传），另一方面通过协商协议计算出共享密钥。然后客户端用共享密钥加密梯度上传，服务器用协商好的密钥解密。注意，聚合服务器不参与密钥协商——它只负责聚合，看不到原始密钥材料。
我在实际部署时发现，如果在同一个网络里同时跑联邦学习和密钥协商，容易产生死锁（比如协商消息和训练消息混杂）。后来我统一加了消息队列，按"协商阶段→训练阶段→重协商"的周期来调度，才稳定下来。
嗯，这就是第一章要讲的核心背景。后面我们会一步步深入到具体的协议实现中去。