基于 TLS 1.3 的百度安全通信协议 bdtls 介绍

2022 年 8 月 11 日
上海
本文字数：8076 字
阅读完需：约 26 分钟

作者 | 金媛宝、孤独键盘手

导读：百度小程序已经在百度开源联盟的多家宿主 APP 上运行，为了保证小程序框架、小程序、宿主 APP 等业务方相互之间的通信服务不被恶意攻击，运营类活动不被薅羊毛，基于最新的 TLS1.3 的协议标准，百度小程序研发团队推出了一套安全防固多 APP、多业务的百度安全通信协议方案。下面将从握手到加密业务传输各个阶段，介绍相关算法、技术选型、Server 与 Client 的实现方案。
全文 9260 字，预计阅读时间 24 分钟。

01 前言

随着移动互联网的高速发展，智能手机的全面普及，各式各样的 APP 出现，方便了人们的生活，同时也带来了巨大的安全风险。APP 主要面临的风险：

静态攻击：APP 被反编译分析源码后，被破解、篡改、二次打包、仿冒/钓鱼等攻击手段；
动态攻击：APP 在运行期，用户操作行为不可控，通过模拟器、多开器、加速器、注入攻击、动态调试（抓包）、设备篡改、位置欺诈等攻击手段；
业务作弊：黑产用户通常在 APP 注册、登录、运营活动、页面爬虫等场景进行批量化、机器化的一些手段操作；

面对以上这些攻击手段，最终第三方会通过网络骗取到服务器的信任，窃取一些有效信息，最后威胁平台和用户的利益，因此，网络通信安全的意识也受到各方关注。国内外的网络服务提供商逐渐提供了全站的安全通信服务，如苹果公司在 2017 年 1 月 1 日要求所有提审的 APP 必须启用 App Transport Security（ATS）安全功能，强制使用 HTTPS，否则无法通过审核；国内主流大厂百度、阿里、腾讯等，已经全站部署 HTTPS。虽然有了 HTTPS 的加持，但是并不意味着网络通信就安全，常见的加密通信协议都在业务层，包体加密、包头明文，这样通过抓包方式还是能获取到明文的请求头、返回数据。百度智能小程序的开源方案已经在多个开源宿主 APP 上落地（比如：爱奇艺、小红书、百度地图等），为了保证百度智能小程序在每个宿主 APP 上通信安全，需要一套小程序的请求从 Client 到 Server 端数据全程加密保护，于是诞生出 bdtls。

02 目标

基于百度智能小程序自身业务特点，涉及到小程序开发者、宿主 APP 开发者、小程序框架开发者多方参与（后续非小程序业务场景），在安全性、性能和可用性等指标上存在相互影响，因此设计出来的安全协议必须满足以下几点：

安全性：支持双向认证，通信内容加密；支持前向安全，若发生密钥泄露，也不能破解出历史请求的数据；
低延迟：足够高的性能，对内容的加解密性能损耗要小于请求整体耗时 10%；
可用性：支持分级（分业务、宿主）降级服务、快速恢复服务；
可扩展：支持业务分级通信、支持分 App 认证、协议升级（可替换安全等级更高的密码套件）；

通过分析业界公开的安全通信协议--TLS（在 2018 年前，正式最高版本为 1.2），发现在安全、性能等方面已经跟不上如今的互联网时代，在建立握手连接过程中需要 2-RTT，导致额外的网络延迟；同时，TLS1.2 还存在许多不安全的加密算法：

伪随机数函数 PRF；
RC4、DES 对称加密算法；
ECB、CBC 等传统分组模式；
MD5、SHA1、SHA-224 摘要算法；
RSA、DH 密钥交换算法和许多命名曲线；
记录协议里使用压缩算法；

对比即将发布的 TLS1.3 协议有三个主要的改进目标：兼容、安全、性能，正好满足我们的需求，于是我们基于 TLS1.3 的草案标准，设计了百度自己的安全通信协议-- bdtls。

03 bdtls 协议设计

3.1 总体架构

bdtls 协议的实现参考 TLS1.3 协议规范，不依赖某个特定的网络传输协议。不同的是，TLS 过程处于传输层和网络层之间，对传输层的数据进行加密，而 bdtls 处于应用层和传输层之间，对应用层数据进行加密，不影响原有的网络策略。bdtls 架构主要分两部分功能：握手（握手阶段）和加密数据传输（业务阶段），这两部都是基于以下协议完成双方通信。

3.2 协议介绍

借鉴 TLS1.3 的设计原理，精简了部分子协议及字段，保留了 Record、Handshake、Application、Alert 四个协议，下面是这些协议之间的关系如下图：

Handshake 协议：握手协议，用于 Client 和网关 Server 之间的握手阶段，协商 bdtls 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统；
Application 协议：应用协议，用于 Client 和业务 Server 之间的业务阶段，在加密数据传输阶段，构造加密传输数据、解析 response 的加密业务数据，是 Record 协议的上层协议；
Alert 协议：警报协议，用于握手阶段、业务阶段，Server 以提醒、错误方式通知到 Client 端，进行关闭连接、降级、恢复等操作；
Record 协议：记录协议，规定了 TLS 收发数据的基本单位：记录（record）。用于握手阶段、业务阶段，负责数据的发送，数据分割、压缩、加密，然后发给底层的协议（TCP）进行处理；接收方对数据解密、校验、解压、聚合，再发给上层的协议（Handshake、Application、Alert）；

结合以上协议，下面是 bdtls 握手阶段和加密数据传输阶段的过程图：

对比 TLS1.2 握手协商阶段，密码套件大幅度简化，压缩了“Hello”协商过程，删除了“Key Exchange”消息，将握手时间减少“1-RTT”（消息往返），效率提升一倍。bdtls 在 Handshake 协议加入扩展实现了 TLS1.3 里面标准的“1-RTT”握手，客户端在“Client Hello”消息里直接用“supported_groups”带上支持的曲线，比如 P-256、x25519，用“key_share”带上曲线对应的客户端公钥参数，用“signature_algorithms”带上签名算法。服务器收到后在这些扩展里选定一个曲线和参数，再用“key_share”扩展返回服务器这边的公钥参数，就实现了双方的密钥交换。

TLS1.3 还引入了“0-RTT”握手，利用“pre_shared_key”和“early_data”扩展，在 TCP 连接后立即就建立安全连接发送加密消息，不过“0-RTT”的实现依赖长期保存的密钥 ticket_key，如果 ticket_key 泄露，那么加密的数据就不太安全了，所以“0-RTT”密钥协商过程中，需要提高前向安全性，本次不再详细赘述，bdtls 结合自身业务的需要，仅提供“1-RTT”握手。

3.2.1 Handshake 协议

Handshake 协议主要工作就是用于 Client 和 Server 握手协商，协商出一个对称加密密钥 Key 以及其他密码材料为后面的数据加密传输做准备。要实现安全的握手，这里需要注意两个问题：

问题 1：如何安全地进行密钥交换？
问题 2：如何防止密钥信息被伪造？

第一个问题涉及密钥如何传输，需要用到密钥交换算法；第二个问题涉及密钥信息被伪造、篡改，信息是否完整，需要用到数字签名算法。这在 TLS1.3 里提供了多种密钥交换和数字签名算法，我们可以根据自己的业务诉求和实现成本选择合适的算法。

问题 1 解答：对于密钥交换的问题，只能选择非对称加密算法，TLS 提供密钥协商算法有：DH、ECDH、RSA、ECC、PFS 方式的（DHE、ECDHE）等，bdtls 选择 DHE 算法，它的核心是取模运算，具有单向不可逆性，数据“前向安全”，关键在于“E”表示的临时性（ephemeral），每次交换密钥时双方的私钥都是随机选择、临时生成的，用完就扔掉，下次通信不会再使用，相当于“一次一密”。所以，即使攻击者破解了某一次的私钥，其他通信过程的私钥仍然是安全的，不会被解密，实现了“前向安全”。有没有比 DHE 速度更快，可逆难度更难的算法吗？ECDHE，基于 ECC 和 DHE 基础上进行组合，就是把 DHE 算法里整数域的离散对数，替换成了椭圆曲线上的离散对数，这种椭圆曲线离散对数的计算难度比普通的离散对数更大，所以 ECDHE 的安全性比 DHE 还要高，更能够抵御黑客的攻击。但是基于百度智能小程序当时的业务，选择了实现成本较低的 DHE 算法，后面密钥交换会逐步升级成 ECDHE。下面简单介绍 DH 算法基础实现：

明白了以上模运算的交换流程，我们就能知道它是怎么用来传递钥匙的了，过程如下：

Alice 和 Bob 两人共同约定底数 G、模数 P（G、P 要求是质数，比如：G = 5、P = 17），这两个数是公开的；
Alice 随便选择一个整数 A（比如：A = 10），鲍 Bob 也随便选择一个整数 B（比如：B = 5)，他们随机选择整数作为私钥，这两个数是严格保密的；
有了 DH 的私钥，Alice 通过函数：G ^ A % P 计算幂α（α = 9），Bob 通过函数：G ^ B % P 计算幂β（β = 14），各自计算出来的幂作为公钥，这两个数是可以公开的，因为根据离散对数的原理，从真数反向计算对数 a 和 b 是非常困难的；
Alice 和 Bob 互相交换各自的 DH 公钥α、β；
Alice 通过函数：β ^ A % P，计算出共享密钥 K（K = 8），Bob 通过函数：α ^ B % P 计算出共享密钥 K（K = 8）；
最后 Alice 和 Bob 分别计算完后，得到相同的数字，这个结果就可以当作他们之间的钥匙。整个通信过程没人传递过钥匙，但双方都拿到了同样的钥匙。对窃听者来说，只偷听到的 DH 公钥，因为这种运算是不可逆的，所以窃听者也白听。这个钥匙叫会话密钥，双方的共享密钥，也就是 TLS 里面的 Pre-Master。

小结：bdtls 密钥协商算法套件：DHE，协商出共享密钥。

问题 2 解答：通过 DHE 算法得到的共享密钥，并不能让 Client 和 Server 双方安全通信，攻击者可以在密钥交换前冒充对 Client，与 Server 分别完成密钥交换，并进行正常的认证加密通信，这时通信双方可能是难以察觉的，这就带来了数据泄露、被篡改的风险，这种攻击称为中间人攻击（Man-In-The-Middle attack），是需要对密钥信息进行认证。当前对消息认证有两种方式：基于消息认证码（Message Authentication Code）的对称认证（简称 MAC）和基于数字签名的非对称认证，消息认证码无法防止否认，存在密钥配送问题，而数字签名具有防止否认特性，不存在密钥配送问题，这样数字签名与密钥协商搭配更合适，常用的数字签名算法有：RSA、ELGamal、DSA、ECDSA 等，在 bdtls 中采用数字签名算法为 RSA，下面是 RSA 签名与验签的流程：

一般来说身份认证是需要相互验证，但在实际的通信过程中，只要保证通信一方签名的协商数据不被中间人攻击就可以了，bdtls 只对 Client 做认证。上面将密钥协商（DHE）与数字签名（RSA）结合起来，实现了一套带认证的密钥协商方案：

握手前的工作：

首先由 Server 生成 RSA 的公私钥对（rsa_publickey、rsa_privatekey）；
Server 将 RSA 公钥（rsa_publickey）发送给 Client，私钥（rsa_privatekey）自己保留；
Client 通过 DHE 算法，生成协商前的 DH 私钥（client_dhe_privatekey）、公钥（client_dhe_publickey）、加密公钥（client_encrypt_dhe_publickey：RSA 加密生成）。

握手中的工作：

Server 接收到 Client 的加密后 DH 公钥（client_encrypt_dhe_publickey），RSA 解密出 client_dhe_publickey；
Server 通过 DHE 算法，生成协商前的 DH 私钥（server_dhe_privatekey）、公钥（server_dhe_publickey）、加密公钥（server_encrypt_dhe_publickey：RSA 加密生成）；
Server 将 client_dhe_publickey 与 server_dhe_privatekey 协商后，得到共享密钥 master_secret，是 Server 进行业务加解密所需要的对称密钥；
Server 再将 master_secret 通过 AES 算法，得到加密后的 skr，Server 在业务阶段解密出 skr，得到 master_secret；
Server 将 server_encrypt_dhe_publickey 进行 hash 后，通过 RSA 的私钥进行签名。

握手后的工作：

Client 解密出 Server 协商后的 server_dhe_publickey；
Client 将 server_dhe_publickey 进行 hash 后，通过 RSA 的公钥进行签名；
验签通过后，将 server_dhe_publickey 与 client_dhe_privatekey 协商后，得到共享密钥 master_secret，是 Client 进行业务加解密所需要的对称密钥；
验签不通过，握手请求中断，业务请求失败。

小结：bdtls 数字签名算法套件：RSA，私钥签名，公钥验签。

3.2.2 Alert 协议

Alert 用来通知对方本次数据交互中出现的问题，协议参照 TLS 协议，分为 warning 和 fatal 两个错误级别。

服务端的 Alert 返回包含两类：

服务端对客户端当前会话周期不信任，此时客户端应重新发起握手，交换新的加密密钥。
服务端对客户端身份不信任，客户端应该直接报错，不再尝试重新握手。

3.2.3 Application 协议

握手完成后，需要 Client 与业务 Server 通信，将业务数据输入到 record 层，进行分段、MAC、加密操作。通过抓包工具，数据格式如下：

http(https)的 body 请求体里是密文，response 里也是密文，通过协商共享密钥将整个传输内容全部加密，对于第三方的攻击完全黑盒。业务传输过程中，由于非对称加密算法效率比对称加密算法的要低，影响网络传输，所以业务传输使用的加密算法一般选择对称算法。TLS 里有非常多的对称加密算法可供选择，比如：RC4、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，通常都禁止使用，当前 TLS1.3 提供的只有 AES 和 ChaCha20。AES 是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，优势没有 AES 明显。bdtls 加密算法选择 AES，分组密码选择 GCM。

对于数据完整性校验，需要用到 Hash 散列算法，常见的 Hash 散列算法有：MD5、SHA-0、SHA-1、SHA-2、SHA-3，MD5、SHA-0、SHA-1 这三个已经不安全了，比较常用的是 SHA-2 家族的 SHA-256、SHA-512，还未被攻破，SHA-3 发布比较晚，普及比较慢。bdtls 数据完整性校验算法选择 SHA-256。

小结：根据对称加密与完整性校验算法的性能对比，bdtls 业务层使用加密与完整性算法套件：AES-128-GCM-SHA256。

04 实现方案

4.1 Sever 端实现方案

服务端的实现方案分为两个部分：握手服务和加解密服务。

4.1.1 握手服务

握手阶段主要解决问题是安全的协商出一份密钥，协商部分的机制和流程可以参考 “3.2.1 Handshake 协议” 。除此之外，握手服务在做了以下三件事情：

宿主身份校验
包签名校验
业务方校验

首先，宿主身份校验。bdtls 不仅支持手百宿主，还支持所有开源联盟中的宿主，如爱奇艺、小红书甚至 oppo、vivo 浏览器等。如何安全和多个宿主进行握手同时防止宿主私下里交换密钥信息，是这一步需要考虑的问题。我们的解决方案是对不同的宿主签发不同的密钥对，并在协议中增加宿主身份标识，通过身份标识解决密钥对的匹配问题，并在握完手之后生成的 skr 中写入宿主身份信息。在后续的业务请求阶段，会再次校验 skr 的宿主身份信息和请求数据中的宿主身份信息是否匹配。通过以上的一整套流程，就完成了对宿主身份的校验。

然后，包签名校验。在实际使用中，我们发现一个宿主可能会衍生出不同的包，如正常发行版、企业版等。由于密钥对签发的最小单位是宿主，一个宿主下不同 APP 使用的都是同一份配置，这会导致两个问题：

1）服务端无法区分流量来源；

2）宿主开发者滥用宿主信息，造成 APP 身份不可信。

我们的解决方案是针对每一个接入的 APP 强制进行包签名校验。包签名对于正式发版到应用商店的 APP 包是唯一的身份标识，通过对包签名的校验，就确保了每一个握手的客户端都是一个可信任的客户端。

最后，业务方校验。按照业务纬度，通过对业务方的校验，没有授信的业务方请求，就会在握手服务中被拦截；加上对业务方校验，建立安全业务隔离机制，增强安全防固功能。业务方可以根据自己的需求，选择统一网关（bdtls 握手服务）和业务方网关（bdtls SDK）其中的一种模式，进行握手服务。

此外需要说明的是，无论是手百，还是开源联盟宿主，无论是内部业务还是外部业务，使用的都是同一个握手服务，协商生成有具备一定有效期的密钥 master secret，并用业务相应的密钥将其加密（即 skr），返回给客户端。

4.1.2 加解密服务

业务请求阶段，根据握手的网关服务模式，提供了两种接入方式：

统一网关接入：内务服务可以选择挂载到小程序服务网关之下（服务网关已经集成 bdtls 插件），即可无侵入的拥有 bdtls 数据加解密功能；
业务方网关接入：bdtls 提供了加解密的 SDK，外部业务（比如：支付业务）通过集成 SDK 的方式实现对请求数据的解密和响应数据的解密。

在对业务数据进行加解密的过程中，主要的流程如下：

skr 解密：业务方利用预先分配的密钥将 skr 解密，获得协商密钥和过期时间等信息；
skr 过期校验：如果发现该协商密钥密钥已经过期，则返回 skr 过期的 Alert 信息，此时客户端会重新发起握手；
加解密：利用解密出的 secretKey 对业务数据进行解密和加密。

4.2 客户端实现方案

图 1 和图 2，代表两个不同业务方的 bdtls 请求，不同点在于多通道的握手方式，图 1 使用统一握手通道服务（小程序的握手服务），业务方不需要在自己的 Server 端部署握手服务，仅需要在客户端设置统一握手模式，就可以用统一握手的密钥对请求参数加密、返回数据解密。图 2 使用支付的握手通道服务（业务方自己的握手服务），业务方需要在自己的 Server 端部署握手服务（业务方网关），同时还要在客户端设置当前业务方的 access key。除了多通道握手方式支持外，客户端还采用了以下策略，保证 bdtls 稳定、高效地运行。

4.2.1 策略 1：多路握手合并

问题：

相同的业务方同时发起多个 bdtls 业务请求时，首次没有密钥，必须先通过握手这个关卡获取到，这时在多线程下，会造成多次冗余的握手情况，对于 bdtls 网关 server 的 QPS 会增大，这样以来，我们的后端需要扩容更多的服务器。因此，客户端在密钥有效期内，仅需要保证一次有效的握手就可以降低握手频次，节省 bdtls 网关 server 的开销。

方案：

为每个业务分配一个 task，task 管理自己的握手通路；
为每个握手通路独立分配一个常驻线程，保证握手通路安全；
为每个握手通路增加“哨兵”机制，检测握手的状态；
握手中，所有的即将发起的业务请求任务都被加入到握手的 block 队列中；
等握手结束，握手的 block 队列将前面拦截的业务请求任务逐一分发。

4.2.2 策略 2：密钥数据缓存

问题：

每次握手后，得到密钥数据（密钥 secretKey、密钥标识 skr、密钥有效时间、DH groupID），如果放在内存中进行管理，APP 下次冷启动，这些密钥数据丢失，显然密钥的有效期时间作用域只在 APP 的生命周期内有效，客户端需重新发起一次握手请求，这样以来会造成多余无效请求。

方案：

将密钥数据组合归档成一个可持久化的对象；
为每组密钥数据按业务方分配一个缓存密钥的 key；
按照缓存密钥的 key，将归档的密钥对象存储到缓存区；
下次 APP 冷启动，优选从缓存区获取密钥数据进行解档为密钥对象，业务方进行 bdtls 请求时，密钥有效，就不需要发起握手请求，直接对业务的请求 body 体加密。

05 最佳实践

bdtls 作为百度智能小程序业务的基建能力，不仅在小程序的场景有应用，而且在百度内部其他业务也被逐步推广应用。

小程序所有开源宿主 APP；
小程序核心业务：PMS（小程序包管理）、授权、swan.request 端能力等；
百度内部业务：支付（聚合收银台）、任务 SDK（运营）、搜索影视第三方资源转码等。

最近，通过国家网络安全攻防演练（HVV）项目，健康宝小程序百度客户端经受住外部严格的攻击，成功守住百度的安全高地，本次安全防固部分使用了 bdtls 安全通信协议，从而证明了 bdtls 技术在安全上是可靠的。

06 小结

bdtls 是参考 TLS1.3 草案标准设计实现的，使用 DHE 来做密钥协商，RSA 进行数字签名，AES-GCM 作为对称加密算法来对业务数据包进行认证加密，使用 HKDF 进行密钥扩展，摘要算法为 SHA256。另外，结合具体的使用场景，bdtls 在 TLS1.3 的基础上主要做了以下几方面的工作：