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

原创欢迎关注的百度Geek说

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

导读

introduction

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

全文9260字，预计阅读时间24分钟。

GEEK TALK

前言

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

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

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

GEEK TALK

目标

基于百度智能小程序自身业务特点，涉及到小程序开发者、宿主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。

GEEK TALK

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。

GEEK TALK

实现方案

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体加密。

GEEK TALK

最佳实践

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

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

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

GEEK TALK

小结

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

轻量级。砍掉了客户端认证相关的内容；直接内置签名公钥，避免证书交换环节，减少验证时网络交换次数。　
安全性。选用的基础密码组件均是 TLS1.3 推荐、安全性高的密码组件。
高可用性。服务器的过载保护，确保服务器能够在容灾模式下提供安全级别稍低的有损服务。
可扩展性。支持多宿主、多业务进行加解密服务。

在密钥协商过程中，TLS1.3 提供了当前性能最优的密钥协商套件算法-- ECDHE-ECDSA ，而bdtls提供的密钥协商算法-- DHE-RSA 还需升级。同时，bdtls已经完全脱离小程序业务，可作为百度内部中台化的安全服务组件，提供给更多的业务使用。　

END

参考资料：

[1] TLS 协议分析与现代加密通信协议设计

[2]The Transport Layer Security (TLS) Protocol Version 1.3

[3] TLS 1.2/1.3 加密原理

[4] 基于 TLS 1.3的微信安全通信协议 mmtls

百度用户产品流批一体的实时数仓实践

如何治理资源浪费？百度云原生成本优化最佳实践

面向大数据存算分离场景的数据湖加速方案

百度APP Android包体积优化实践（三）资源优化

ffplay视频播放原理分析

AI+BI+可视化，Sugar BI架构深度剖析

百度APP Android包体积优化实践（二）Dex行号优化

一键三连，好运连连，bug不见👇

继续滑动看下一个