一、为什么密钥交换是加密传输的第一关

提到加密传输，多数人先想到算法：选一个足够强的密码算法，数据就安全了。实际顺序正好相反，算法本身是公开的，真正的门槛在钥匙。对称加密要求收发双方持有同一把密钥，这把钥匙不能明文发送，一旦明文发送，加密就形同虚设。密钥交换解决的就是这个死结：在一条不安全的线路上，让双方安全地协商出共享密钥。

1. 报送场景把问题放大了

34号文2024年发布后，国资监管数据报送进入穿透式监管阶段，按三阶段时间表推进，到2026年底全级次穿透覆盖率不低于90%。报送主体从集团本部扩展到全级次子企业，数据从汇总报表变为明细数据，传输链路从偶尔一条变成常态化的成百上千条。每条链路都要建通道，每个通道都要过密钥交换这一关，安全建设的基数被成倍放大。

2. 出问题的往往不是算法

从公开的安全事件看，加密体系被攻破，多数不是算法被破解，而是密钥管理出了纰漏：私钥硬编码在代码里、证书过期无人更换、弱随机数让密钥可被预测。算法强度是数学问题，早有定论；密钥的生成、交换、存储、轮换是工程问题，工程问题只能靠制度加工具管住。密钥交换是这条链条的起点，起点不牢，后面全白搭。

3. 随机数质量是隐性前提

密钥交换的每一步都依赖随机数：客户端随机数、服务端随机数、临时密钥对的生成，全要从高质量的随机源出来。随机数不过关，再强的算法也守不住，历史上多起安全事件的根因就是随机数可预测。企业侧的检查不复杂：确认随机数发生器符合规范，虚拟机克隆场景要重置随机数种子，避免多台主机生成相同序列。

二、密钥交换在解决什么问题

把问题抽象一下：两个人当着窃听者的面，在电话里商量出一个窃听者不知道的数。听起来像魔术，数学上确实有解。

1. 对称加密的钥匙分发难题

对称加密（如SM4、AES）加解密用同一把钥匙，速度快，适合大流量数据。软肋在分发：钥匙通过网络交给对方，监听者也能拿到；提前用其他渠道送，渠道本身的安全又成了新问题。企业内部几条链路还能靠人工送钥匙，成规模的报送网络里，人工分发既不安全也不可运维。

2. 公钥密码破局

公钥密码（如SM2、RSA）每个用户有一对钥匙：公钥随便公开，私钥自己留着，用公钥加密的数据只有私钥能解开。钥匙分发问题就此消失：想给我发秘密，拿我的公钥加密就行。代价是公钥算法运算慢，直接加密大流量数据不现实。实际的加密传输是两种算法的接力：公钥密码负责协商或保护一把对称密钥，对称密码负责加密业务数据。密钥交换，就是这场接力的第一棒。

三、TLS握手：安全通道建立的完整过程

HTTPS、FTPS、数据库的TLS连接，安全通道的建立流程都遵循TLS协议。以一次典型的握手为例，拆开看每一步在做什么。

1. 客户端打招呼

客户端发送ClientHello报文，附上自己支持的TLS版本、密码套件清单（国密的ECDHE_SM4_SM3、国际的ECDHE_RSA_WITH_AES_256_GCM等）和一个客户端随机数。这一步相当于递上名片：我能做什么，你来挑。

2. 服务端应答并出示证书

服务端从清单里选定一套算法，回复ServerHello，附上服务端随机数和数字证书。证书里含有公钥和身份信息，由CA机构签名背书。客户端验证证书链：签发机构是否可信、域名是否匹配、是否过期、是否被吊销。任何一项不过，握手立即终止。验证由客户端自动完成，管理员要做的是保证本机信任库干净：根证书定期审计，来历不明的一律清出。

3. 密钥协商

若选定ECDHE套件，双方各自生成临时椭圆曲线密钥对，交换公钥，各自算出同一个预主密钥。临时密钥用完即弃，即使服务端的长期私钥将来泄露，历史流量也无法解密，这叫前向保密。若选定RSA套件，则由客户端生成预主密钥，用服务端公钥加密后发送，这类套件不具备前向保密，正被逐步淘汰。

4. 派生会话密钥并收尾

两边用预主密钥和两个随机数派生出主密钥，再派生出一组会话密钥，分别用于两个方向的加密和校验。握手末尾双方交换Finished报文，内容是对前面全部握手报文的校验值，用刚派生的密钥加密。对方能解开且校验一致，证明密钥协商成功、握手未被篡改，安全通道就此建立，后续报文全部走对称加密。

四、证书：确认“对端是谁”

密钥交换解决“钥匙怎么给”，证书解决“对面是谁”。没有证书校验，通道建得再牢，也可能建到了冒名者手里，这类攻击叫中间人攻击。

1. 证书与信任链

数字证书把公钥和身份绑定在一起，由CA机构用私钥签名。操作系统和浏览器内置一批根CA证书，验证时逐级核对签发链，链条通到可信根，证书才被认可。信任的本质是：你信根CA，根CA信它签发的下级，一层层传递下来。

2. 国资报送里的双向认证

普通网站只需服务端出示证书。国资监管数据报送这类机对机场景，通常启用双向TLS：客户端也要出示证书，服务端验证通过才继续握手，两边都确认了对方身份，通道才可信。集团统一为所属企业签发客户端证书、到期前统一轮换，是常见的集团级做法，搭贝的集团版支持这套统一签发与批量轮换的证书管理方式，全级次企业共用一套身份基线。

3. 自建链路的证书策略

集团到监管平台的通道，用监管方认可的CA签发证书。集团内部系统之间的链路，私有CA是常见选择：自建根证书，为各系统签发服务端和客户端证书，双向认证在内部自成一体。私有CA的关键在管理纪律：根证书私钥离线保存，签发有台账，吊销机制要真正可用。仅限内部测试的自签证书不要流到生产环境，证书校验一旦配置成忽略错误，等于给中间人攻击开了门。双向认证在集团内部自成体系，与对外通道互不干扰。

五、国密算法的密钥交换

国资企业建设报送通道，商用密码是绕不开的要求。国密体系里的密钥交换，有自己的一套组合方式。

1. SM2顶上协商位置

SM2基于椭圆曲线，既能做签名也能做密钥交换，对应顶替国际算法里ECDHE和RSA的位置。国密TLS协议（TLCP）将SM2的协商能力纳入握手流程，逻辑与国际套件一致，算法基础不同。

2. SM3与SM4各就其位

SM3杂凑算法用于握手过程中的摘要计算和Finished报文校验；SM4负责握手完成后的对称加密。一条国密通道跑下来，协商用SM2，校验用SM3，加密用SM4，算法体系全栈国产。

3. 密评的硬要求

商用密码应用安全性评估对算法使用有明确要求：新建系统应使用国密算法，密钥管理制度要覆盖生成、存储、分发、更换、销毁的全生命周期。报送通道上线前把密评要求纳入设计，比上线后返工省得多。搭贝的传输组件预置了国密套件支持，密评要求的密钥管理动作在平台内建，方案按用户数报价。

六、落地要点与日常管理

密钥交换由协议自动完成，把它管好却是持续的日常动作。三个要点。

1. 协议版本与套件收口

禁用TLS 1.0和1.1，服务端只保留TLS 1.2及以上，密码套件剔除已知弱算法（RC4、3DES、RSA密钥交换）。收口动作每年复查一次，安全基线随算法演进逐步收紧。

2. 证书与密钥的生命周期

建立证书台账，记录每张证书的签发对象、有效期、责任人，到期前三十天启动轮换，避免通道因证书过期中断。私钥存放用加密介质或密钥管理服务，禁止出现在代码仓库和配置文件明文里。搭贝这类集团级报送平台可以把证书申请、部署、轮换做成统一流程，全级次企业共用一套通道安全基线，管理成本随企业数量增加趋于平稳。密钥轮换周期要有明文规定，写进制度而不是依赖个人经验。

3. 会话复用与性能

完整握手要消耗一对非对称运算，高并发场景可用会话票据复用已有通道参数，跳过完整的密钥协商。复用与安全存在权衡，票据密钥本身要纳入轮换范围，复用策略按业务流量特征定，不盲目开满。

常见问题

Q：每次传输都要做一次完整密钥交换吗？

不必。TLS支持会话复用，同一客户端短时间内再次连接，可凭会话票据跳过完整握手，只做简化协商。业务上更常见的是长连接：通道建立后保持，批量报送复用同一条通道，密钥在连接存续期内持续使用，到期或断开后重新协商。长连接还可设会话密钥更新阈值，超时或超量后主动重新协商，降低同一密钥长期使用的暴露面。

Q：走了HTTPS，数据还要再加密一遍吗？

看数据敏感级别。HTTPS保护的是传输链路，数据到达服务端解密后，在内部系统间的流转不再受这层保护。对高敏感字段（如人员身份信息、未披露财务数据），应用层再加一层字段级加密，两层各管一段，互不冲突。

Q：国密和国际算法能在同一条通道里混用吗？

能，但要有明确策略。TLCP协议走国密套件，常规TLS走国际套件，两端按能力协商。混用的问题在管理口径：密评要求国密覆盖的场景，混用比例要说得清。建议按报送对象定死算法策略，对监管平台走国密，对其他外部系统按需选择，避免逐连接临时决定。

Q：密钥交换失败一般是什么原因？

排查集中在四处：协议版本不匹配（一端只开TLS 1.2，另一端还停在旧版本）、密码套件没有交集、证书过期或链不完整、服务器时间不同步导致证书有效期校验失败。多数故障在同步时间或更新证书后消失，反复出现的要检查两端算法基线配置是否一致。