作者 | 金媛宝、孤单键盘手
导读 ：
百度小程序曾经在百度开源联盟的多家宿主 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 的根底上次要做了以下几方面的工作：
- 轻量级。砍掉了客户端认证相干的内容；间接内置签名公钥，防止证书替换环节，缩小验证时网络替换次数。
- 安全性。选用的根底明码组件均是 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 行号优化