汽车Cyber Security入门之TLS

TLS概况

什么是TLS？TLS的全称是Transport Layer Security，传输层安全性协议。与很多Cyber Security技术类似，TLS在IT界和通讯界久负盛名，例如我们平时在网页浏览器输入网址时看到的“https”中的s就是指TLS。TLS的前期版本被命名为SSL, Secure Socket Layer（分别有1.0/2.0/3.0版本），有资历的互联网人可能对SSL这个名字更为熟悉。

TLS 1.0定义于1999年，是SSL 3.0的升级版。由于SSL与Netscape公司有很大关系，IETF（互联网工程任务组）将其名称改为TLS，以取悦当时拥有最流行浏览器Internet Explorer 5的微软公司。2006年出现了TLS 1.1，随后在2008年出现了TLS 1.2。2018年出现了TLS 1.3，这也是当前最新版本。而在2021年IETF正式宣布弃用TLS1.0和1.1。所以我们现在上网用到的基本都是TLS 1.2和1.3。

图1：https中的s就是指TLS

TLS和DTLS

TLS属于工作在传输层的协议，它介于传输层底层协议和上层应用协议之间。而以太网的传输层主要有两大底层协议：TCP（Transmission Control Protocol）和UDP （User Datagram Protocol）。二者各有特点，互为补充，不管在传统互联网上，还是车载以太网上，两者都是常见的传输层底层协议。

简单来说，TCP协议是面向连接和可靠的，例如TCP需要“三次握手”来建立连接，而结束连接时则需要“四次挥手”，讲究有来有回，属于谨慎细腻的“暖男”。而UDP则是无连接的，没有可靠性保证，但是实时性和传输效率高，支持一对多的组播，属于风风火火大大咧咧的“阳光男孩”。

上文提到的TLS其实属于狭义的TLS。如下图所示，不同的传输层底层协议实际上对应着不同的传输层安全保护协议。也就是采用TCP传输的，就用TLS保护。采用UDP传输的，就用DTLS保护。DTLS的全称是Datagram Transport LayerSecurity，比TLS多出来的“D”，指的就是UDP中的“D”。TLS和DTLS本身有很多相似的地方，在平时工作生活中，很多时候广义的TLS和狭义的TLS也会混用，需要我们按照情景来判断。而接下来本文描述的，除非特别注明，否则TLS均指狭义的TLS。

图2：TLS和DTLS在OSI 层次模型中的位置

TLS和DTLS各有不同的版本，目前主流支持的还是1.2和1.3版本。两者的对应关系如下：

• DTLS 1.0 对应 TLS1.1 （已宣布弃用）
• DTLS 1.2 对应 TLS1.2
• DTLS 1.3 对应 TLS1.3

TLS与汽车

那么广义TLS和汽车又有什么关系呢？这个逻辑大概是：有智能汽车的地方就有以太网，有以太网的地方就有广义TLS。

TLS顾名思义，就是在发生在传输层的安全协议。这里的传输层，对应OSI或者TCP/IP模型中的传输层。它所针对的也就是端对端传输过程中的信息安全，防止数据在通讯过程中被泄露或者篡改等，能够有效防止中间人攻击。

图3：中间人攻击示意图

随着汽车网联化的发展，以太网通讯已经在车内通讯及车联网普及， TLS和DTLS也更多地出现在汽车行业的视野里。AUTOSAR在Classic Platform （CP）和Adaptive Platform（AP）中也加入了TLS和DTLS的规范。其中CP 4.4明确了支持1.2和1.3，优先选择1.3。AP R21-11中只描述了1.2。但相信将来版本也会加上1.3。

广义TLS作为传输层的中坚力量，可以支撑上层的SOMEIP、MQTT和HTTP等协议。不但可以用于V2X的通讯安全，也可以用于车内通讯节点之间的通讯安全。当然像Tbox等可以与车外节点通讯的ECU来说，其安全性要求更高，可以应用更加完整的广义TLS，既安全，又灵活。而车内ECU之间一般IP地址、端口、服务接口等都固定，安全性要求也不如Tbox高，则可以应用广义TLS中的预享密钥（TLS_PSK）等套件，既高效，又稳定。

图4：汽车上可以灵活应用不同TLS套件

TLS原理

对TLS来说，无论1.2还是1.3，其协议内部都是基于分层结构的。下层是TLS记录协议，为TLS上层子协议提供分片、消息加解密、重新组装等操作。而上子层则包含了握手协议（handshake），应用数据协议（application_data），警报协议（ alert）和Change_cipher_spec。

图5：TLS上下两个子层的协议

应用数据协议就是最常规的部分，比如有了对称密钥之后，加密过或压缩过的数据就通过它来传输。

Change_cipher_spec在TLS1.2中是用来通知对端，接下来要用新协商的加密套件和密钥了。TLS1.3中取消了这一机制，但为了和之前版本兼容，保留了该协议格式。

警报协议则主要是用来提示终止信息和错误情况，在汽车上，这可以用来触发DTC。

握手协议主要是通过非对称加密的手段来协商出对称密钥的。这也是TLS协议中最核心的部分。

在展开讨论握手协议前，我们先简单看看对称加密和非对称加密。这里举一个简单例子。假设甲和乙之间说小秘密的时候，都将字母向后偏移X位。比如X=1，当想说“car”，加密后的密文就会变成“dbs”。这里“X”就是甲乙之间的对称密钥，只有甲和乙知道，有了它就能加密解密。

甲乙还可以换一种方式说小秘密。假设有一种宝盒，谁都可以往里面放东西并上锁，但是只有甲的人脸识别可以开锁。当乙想向甲说小秘密，就把小纸条放宝盒里面，然后派人交给甲。当甲想向乙说小秘密的时候也是同理。这就是非对称加密。这个谁都能放东西和上锁的宝盒就是公钥，而对应的人脸就是私钥。这种看似神奇的非对称性，是天才科学家们利用大质数乘积难以因式分解、模幂计算等实现的，此处不展开。

上面例子中可以感受到，对称加密简单，计算效率高。非对称加密安全性更高，但加解密效率低。那么能不能互补一下呢？例如每天通过宝盒传递一次小纸条，纸条上面写了对称密钥“X”，当天后续的会话就用“X”来对称加解密。这其实就是TLS的整体思路。握手协议就是在TCP会话开始时（TCP“三次握手”后）互传宝盒，协商出来对称密钥。之后就应用该对称密钥加解密，通过应用数据协议来传输。

TLS 1.2 握手过程

如下图所示，我们先来细看下TLS1.2握手的过程，以拟人化的口吻帮助理解。

1. Client Hello：“您好，我是客户端，这些是我支持的TLS版本、加密套件，这个是我刚生成的客户随机数。”
2. Server Hello：“您好，我是服务端，考虑到你支持的参数，这次我们就用这个TLS版本和加密套件吧。这个是我刚生成的服务端随机数。”
3. Certificate: “这是我作为服务端的工作证书。”
4. Server Key Exchange: “这是我的公钥，用它加密的东西只有我的私钥才能解密哦。”
5. Server Hello Done：“好了，先给你这么些文件，这次招呼我打完了。”
6. Cient KeyExchange：“您好，我刚生成了一个预主密钥（Premaster Secret），用您给的服务端公钥加密过了，请查收。”
7. Change Cipher Spec, Client Finished：“我准备好了，现在就按我们之前协商好的加密套件和密钥来做对称加密吧，从这条信息开始，都是只有我们两个知道的小秘密。”
8. Change Cipher Spec, Server Finished：“您好，我也准备好了，刚才对称加密的小秘密我这边也能收到了！”

 图6：TLS1.2 握手过程

上图中第1到8步就是一般TLS1.2握手协商加密套件和生成对称密钥的过程了。用于会话的对称密钥简单来说就是通过“客户端随机数”、“服务端随机数”和“预主密钥”三者生成的。所以第6步中，客户端是用服务端的公钥加密预主密钥后发送，对应上图的棕色小锁。而从第7步开始，双方就用对称密钥开始通讯了，对应蓝色小锁。

虽然详细来看，握手分了8步，但其中第2到5步的几条消息都可以通过一个底层数据包囊括。第1到5步就是握手协议消耗的第一次往返时间（RTT，round trip time）。同理，第6到8步就是第二次往返时间。所以整个TLS1.2的握手需要2段RTT。

TLS 1.3 握手过程

有了TLS1.2的基础，理解TLS1.3就很简单了。总的来说，TLS1.3就是简化了握手过程，不给双方那么多选择了，协议本身直接选好比较安全的协商手段，上来就是干货，不墨迹。所以TLS1.3比1.2更强大的点就是：更加高效，更加安全。

TLS1.2中没那么安全的（比如静态RSA）密钥协商方式被禁止。TLS1.3握手过程中客户端和服务端会互相传递一个“共享密钥信息”，配合各自的私钥就能得出对称的会话密钥。但在TLS1.3规定的协商方法中，各自的私钥（加密参数）是动态变化的，确保即使某个会话的私钥或者对称密钥被破解了，其他历史会话也不能被破解，也就是确保了完美前向保密（Perfect Forward Secrecy，PFS）。

同样拟人化地来看看TLS1.3的握手过程。

1. Client Hello：“您好，我是客户端，这是我支持的加密套件和我支持的几种共享密钥信息。”
2. Server Hello：“您好，我是服务端，这是我从你的支持列表中选出的加密套件和刚算出来的共享密钥信息。”
3. Certificate：“这是我作为服务端的工作证书，用刚生成的对称会话密钥加密过了。”
4. Server Finished：“我准备好了，下面开始我们的小秘密吧。”
5. Client Finished+应用数据：“我也准备好了。这就是我想偷偷跟你说的……”

图7：TLS1.3握手过程

上图可见，TLS1.3的握手过程清爽了很多。信息一来一回之后就可以开始交流应用数据了，跟1.2比少了一次往返时间。而在第2步之后，双方就已经得出对称的会话密钥了，所以从第3步开始的信息就已经是加密过的。

DTLS原理

DTLS出现得比TLS略晚，后来版本的发布也晚于TLS。原则上DTLS就想复用TLS的协议规则，其不同点都是为了适配底层UDP和TCP的差异。所以有了上面关于TLS的理解，下面再看DTLS就像砍瓜切菜一样轻松了。

图8：DTLS1.2和1.3握手过程

如上图所示，DTLS和TLS的握手协议过程的主要差别是在开头多打了一声招呼。这是由于UDP跟TCP相比，是无状态不可靠的，也没有会话建链过程。所以在应用安全协议DTLS的时候，需要在开始阶段多一次往返，通过服务端返回Cookie来补偿建立连接。服务端和客户端都会设定相应的计时器，如果超时了就自动重发请求，以提高DTLS握手过程的可靠性。同时也可以防止DoS攻击。

另一方面，由于UDP发包的无状态和不可靠，DTLS报文还补充了一个显性的序列号码（Sequence Number）和纪元号码（Epoch），通过这两个号码可以把不同组的DTLS数据区分开来。在第二次Client Hello之后，DTLS的握手就跟TLS几乎一样了。

写在最后

TLS和DTLS是汽车Cyber Security的一件防御神装，有助于汽车网联化升级和SOA安全保证。当然与很多底层通讯技术一样，TLS和DTLS博大精深，RFC的规范不下100页。而在实际工作中，不同的应用主体对于TLS和DTLS也有不同的聚焦方向。比如对底层协议栈的供应商，可能会聚焦在RFC规范的详细需求，软件实现细节，保证协议栈的兼容性和开发配套的SDK。而对主机厂的网络信息安全工程师来说，可能更关心整车安全架构下哪些地方要用TLS或者DTLS，用哪个版本，用哪个加密套件和密钥长度等。本文抛砖引玉，尝试从基础背景出发，探讨其基本原理，希望能帮助入门者快速理解，欢迎各位交流和指正。

本文转载自公众号：焉知智能汽车