基于 TLS 1.3的百度安全通信协议 bdtls 介绍
作者 | 金媛宝、孤独键盘手
导读
introduction
01
静态攻击:APP被反编译分析源码后,被破解、篡改、二次打包、仿冒/钓鱼等攻击手段;
动态攻击:APP在运行期,用户操作行为不可控,通过模拟器、多开器、加速器、注入攻击、动态调试(抓包)、设备篡改、位置欺诈等攻击手段;
业务作弊:黑产用户通常在APP注册、登录、运营活动、页面爬虫等场景进行批量化、机器化的一些手段操作;
02
安全性:支持双向认证,通信内容加密;支持前向安全,若发生密钥泄露,也不能破解出历史请求的数据;
低延迟:足够高的性能,对内容的加解密性能损耗要小于请求整体耗时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
3.1 总体架构
bdtls 协议的实现参考 TLS1.3 协议规范,不依赖某个特定的网络传输协议。不同的是,TLS 过程处于传输层和网络层之间,对传输层的数据进行加密,而 bdtls 处于应用层和传输层之间,对应用层数据进行加密,不影响原有的网络策略。bdtls 架构主要分两部分功能:握手(握手阶段)和加密数据传输(业务阶段),这两部都是基于以下协议完成双方通信。
3.2 协议介绍
Handshake协议:握手协议,用于Client 和 网关Server之间的握手阶段,协商 bdtls 版本号、随机数、密码套件等信息,然后交换证书和密钥参数,最终双方协商得到会话密钥,用于后续的混合加密系统;
Application协议:应用协议,用于Client 和 业务Server之间的业务阶段,在加密数据传输阶段,构造加密传输数据、解析response的加密业务数据,是Record协议的上层协议;
Alert协议:警报协议,用于握手阶段、业务阶段,Server以提醒、错误方式通知到Client端,进行关闭连接、降级、恢复等操作;
Record协议:记录协议,规定了 TLS 收发数据的基本单位:记录(record)。用于握手阶段、业务阶段,负责数据的发送,数据分割、压缩、加密,然后发给底层的协议(TCP)进行处理;接收方对数据解密、校验、解压、聚合,再发给上层的协议(Handshake、Application、Alert);
3.2.1 Handshake协议
问题1:如何安全地进行密钥交换?
问题2:如何防止密钥信息被伪造?
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,协商出共享密钥。
首先由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协议
服务端对客户端当前会话周期不信任,此时客户端应重新发起握手,交换新的加密密钥。
服务端对客户端身份不信任,客户端应该直接报错,不再尝试重新握手。
3.2.3 Application协议
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 握手服务
宿主身份校验
包签名校验
业务方校验
然后,包签名校验。在实际使用中,我们发现一个宿主可能会衍生出不同的包,如正常发行版、企业版等。由于密钥对签发的最小单位是宿主,一个宿主下不同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:多路握手合并
为每个业务分配一个task,task管理自己的握手通路;
为每个握手通路独立分配一个常驻线程,保证握手通路安全;
为每个握手通路增加“哨兵”机制,检测握手的状态;
握手中,所有的即将发起的业务请求任务都被加入到握手的block队列中;
等握手结束,握手的block队列将前面拦截的业务请求任务逐一分发。
4.2.2 策略2:密钥数据缓存
将密钥数据组合归档成一个可持久化的对象;
为每组密钥数据按业务方分配一个缓存密钥的key;
按照缓存密钥的key,将归档的密钥对象存储到缓存区;
下次APP冷启动,优选从缓存区获取密钥数据进行解档为密钥对象,业务方进行bdtls请求时,密钥有效,就不需要发起握手请求,直接对业务的请求body体加密。
05
小程序所有开源宿主APP;
小程序核心业务:PMS(小程序包管理)、授权、swan.request端能力等;
百度内部业务:支付(聚合收银台)、任务SDK(运营)、搜索影视第三方资源转码等。
06
轻量级。砍掉了客户端认证相关的内容;直接内置签名公钥,避免证书交换环节,减少验证时网络交换次数。
安全性。选用的基础密码组件均是 TLS1.3 推荐、安全性高的密码组件。
高可用性。服务器的过载保护,确保服务器能够在容灾模式下提供安全级别稍低的有损服务。
可扩展性。支持多宿主、多业务进行加解密服务。
在密钥协商过程中,TLS1.3 提供了当前性能最优的密钥协商套件算法-- ECDHE-ECDSA ,而bdtls提供的密钥协商算法-- DHE-RSA 还需升级。同时,bdtls已经完全脱离小程序业务,可作为百度内部中台化的安全服务组件,提供给更多的业务使用。
END