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

原创
08/11 11:38
阅读数 7.7K

图片

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

导读: 百度小程序已经在百度开源联盟的多家宿主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 的基础上主要做了以下几方面的工作:

  1. 轻量级。砍掉了客户端认证相关的内容;直接内置签名公钥,避免证书交换环节,减少验证时网络交换次数。

  2. 安全性。选用的基础密码组件均是 TLS1.3 推荐、安全性高的密码组件。

  3. 高可用性。服务器的过载保护,确保服务器能够在容灾模式下提供安全级别稍低的有损服务。

  4. 可扩展性。支持多宿主、多业务进行加解密服务。

在密钥协商过程中,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行号优化

展开阅读全文
加载中

作者的其它热门文章

打赏
2
4 收藏
分享
打赏
0 评论
4 收藏
2
分享
返回顶部
顶部