共计 9559 个字符，预计需要花费 24 分钟才能阅读完成。
前言
在汽车出行更加智能化的明天，咱们能够实现手机近程操控车辆解锁、启动通风、查看车辆四周影像，也能够通过 OTA（地面下载技术）实现降级车机固件、更新地图包等操作，主动驾驶技术更是能够让车辆依据路面情况主动辅助施行转向、减速和制动。
然而，每项晋升咱们应用体验的性能，都有可能成为致命的安全漏洞。腾讯平安科恩实验室曾向外界披露并演示过如何凭借 3/4G 网络或者 WiFi 网络，在近程无物理接触的状况下入侵智能汽车，实现对车辆信号灯、显示屏、门锁甚至是刹车的近程管制。不仅如此，攻击者甚至能够利用某个已知破绽获取智能汽车的 Autopilot 控制权，对车辆行驶方向进行操控。
因而，咱们在车联网平台构建时也应充分认识到通信安全、身份认证、数据安全的重要性，正确应用相干加密认证等技术手段来提供保障。
本篇文章咱们将全面介绍 SSL/TLS 协定在车联网通信安全中的利用，心愿能让大家对 SSL/TLS 的作用有更清晰直观的意识。此外，咱们还将具体解说 SSL/TLS 的配置形式，确保大家能正确应用 SSL/TLS，实现安全性保障。
车联网平安通信 MQTTS 协定
MQTTS 协定是在 MQTT 协定的根底上，封装了一层基于 SSL/TLS（ 传输层平安） 的加密协议，它确保车机端和车联网平台通信是加密的。但如果没有正确配置 SSL/TLS，仍然会存在很多安全隐患。想要真正使用好 SSL/TLS，咱们必须理解 SSL/TLS 解决了哪些问题，以及对 SSL/TLS 用到的明码技术有初步的认知。
通常状况下，通信过程须要具备以下四个个性，能力被认为是平安的，别离是：机密性、完整性、身份认证和不可否认。
机密性
机密性是平安通信的根底，短少机密性任何窃听通信的人都能够轻而易举获取到你的诸如登录明码、领取明码等要害隐衷信息。实现机密性最罕用的伎俩就是加密，这样窃听者只能失去加密后的毫无意义的一串数据，只有持有密钥的人才能将密文复原成正确的原始信息。依据密钥的应用办法，加密形式能够分为对称加密和非对称加密两种。对称加密是指加密和解密应用雷同的密钥，非对称加密则是指加密和解密时应用不同的密钥。
对称加密因为通信单方要应用雷同的密钥来进行加解密，所以必然会遇到密钥配送问题，即我须要对方可能解密我发送过来的密文，我就必须把我加密时应用的密钥通知对方，然而我如何保障将密钥与对方同步的过程中密钥不会透露？这就是对称加密的密钥配送问题。
目前罕用的解决方案是应用非对称加密和应用 Diffie-Hellman 密钥替换算法。非对称加密的外围是生成一对密钥，一个是公钥，一个是私钥，公钥用于加密，它是公开的，能够派发给任何人应用，私钥用于解密，不参加通信过程，须要被妥善保存，这样就解决了密钥配送问题。Diffie-Hellman 密钥替换算法的核心思想则是通信单方替换一些公开的信息就可能计算出雷同的共享密钥，而窃听者取得这些公开信息却无奈计算出雷同的密钥。Diffie-Hellman 算法的一个益处是没有非对称加密的性能问题，非对称加密尽管解决了密钥配送问题，但非对称加密算法的运算速度远远不迭对称加密算法，它们甚至能有几百倍的差距。尽管保障了平安，但重大影响了通信的效率，丢失了实用性。因而理论利用时通常会将对称加密和非对称加密联合应用，即应用伪随机数生成器生成会话密钥后，用公钥进行加密并发送给对方，对方收到密文后应用私钥解密取出会话密钥，后续通信将齐全应用该会话密钥。这样既解决了密钥配送问题，又解决了非对称加密带来的性能问题，这种形式通常又被称为混合加密。
完整性
仅仅具备机密性还不足以实现平安的通信，攻击者仍旧能够篡改、伪造密文内容，而接收者既无奈判断密文是否来自正确的发送者，也无奈判断解密后的明文是否是未经篡改的。只管对加密之后的密文进行针对性篡改的难度有所回升，例如篡改之后明文的数据结构很有可能会受到毁坏，这种状况下接收者可能很轻易地回绝这个明文。但仍然存在篡改之后正好使得解密失去的明文音讯中某些自身就具备随机属性的字段的值发生变化的概率，例如电机转速字段的值从 500 变为了 718，无非是几个比特位的变动，如果接收者失常承受这些音讯，就可能带来意想不到的隐患。
因而，咱们还须要在机密性的根底上进一步保障信息的完整性。常见的做法就是应用单向散列函数计算音讯的散列值，而后将音讯和散列值一起发送给接收者。单向散列函数可能确保音讯中哪怕只有 1 比特的扭转，也有很高的概率产生不同的散列值。这样接收者就能够计算音讯的散列值，而后比照收到的散列值来判断数据是否被人篡改。
身份认证
但惋惜的是，当攻击者同时伪造音讯和对应的散列值时，接收者仍然无奈识破这个假装。因而咱们不仅须要确认音讯的完整性，还须要确认音讯是否来自非法的发送者，也就是说还须要对身份进行认证。这个时候咱们就须要用到音讯认证码，音讯认证码仍然基于单向散列函数，但它的输出除了本来的音讯以外，还包含了一个发送者与接收者之间共享的密钥。因为音讯认证码自身并不提供音讯机密性的保障，所以在理论应用中，通常会将对称加密与音讯认证码联合应用，以同时满足机密性、完整性和认证的要求，这种机制也被称作认证加密（AEAD）。具体怎么应用上，产生了以下几种计划：
- Encrypt and MAC：先用对称明码将明文加密，再计算明文的 MAC 值，最初把二者拼接起来发给接管方。
- MAC then Encrypt：先计算明文的 MAC 值，而后将明文和 MAC 值同时用对称明码加密，加密后的密文发送给接管方。
- Encrypt then MAC：先用对称明码将明文加密，再后计算密文的 MAC 值，最初把二者拼接起来发给接管方。
在很长一段时间内，SSL/TLS 都采纳了第二种计划，但事实上以上三种计划都曾经陆续被验证为存在安全漏洞。SSL/TLS 历史上的 POODLE 和 Lucky 13 攻打都是针对 MAC then Encrypt 计划中的破绽实现的。目前业界举荐的平安计划是采纳 AEAD 算法，SSL/TLS 1.3 版本中也正式破除了其余加密形式，仅反对 AEAD 加密。
不可否认
当初，咱们曾经保障了音讯的机密性，同时也能辨认出假装和篡改，然而因为音讯认证码的外围是须要通信单方共享密钥，因而又引发了新的问题，即无奈对第三方证实以及无奈避免否定。假如 Bob 接管了来自 Alice 的音讯，想要向第三方证实这条音讯确实是 Alice 发送的，就须要将本来只有两个人晓得的密钥通知给第三方，这显然会减少后续持续应用这个密钥通信的平安危险。同时，即使第三方拿到了密钥，也无奈得出无效的论断，例如 Bob 能够声称这条音讯是由 Alice 结构的，因为 Alice 也持有雷同的密钥。
因而，咱们还须要引入数字签名机制，它的原理与非对称秘密很像，又正好相同。数字签名须要发送者用私钥对音讯施加签名，而后将音讯与签名一并发送给接收者，接收者则应用对应的公钥验证签名，确认签名来自非法的发送者。因为只有持有私钥的人才能施加正确的签名，这样发送者就无从否定了。而公钥只是用来验证签名，所以能够随便派发给任何人。可能敏感的读者到这里心中曾经有些疑难了，是的，取到公钥的人如何确认这个公钥确实来自本人冀望的通信对象呢？如果攻击者伪装成发送者，并把本人的公钥给了接收者，那么就能在无需破解数字签名算法的前提下实现攻打。
咱们曾经陷入了一个死循环，数字签名是用来用辨认音讯篡改、假装以及否定的，但在此之前咱们又必须从没有被假装的发送者失去没有被篡改的公钥才行。到了这一步，咱们只能借助外力的帮忙了，委托公认的可信第三方，也就是咱们当初常说的认证机构或 CA，由它来给各个公钥施加签名，造成公钥证书。不言而喻的是，认证机构须要致力确保本人的私钥不被窃取，以保障数字签名的有效性。尽管认证机构的私钥仍然有透露的概率，甚至认证机构自身也可能被攻击者假装，咱们仍然无奈取得相对的平安，但提前信赖几个已知的认证机构，总是比从全新的通信对象获取并信赖他的公钥要牢靠的多。
以上这些明码技术，独特形成了古代平安通信畛域的基石。而 SSL/TLS 作为目前世界上利用最宽泛的明码通信办法，综合使用了后面提到的对称加密、非对称加密、音讯认证码、数字签名、伪随机数生成器等明码技术，来提供通信安全保障。思考到密码学技术是不断进步倒退的，或者说目前看似牢靠的加密算法，可能在第二天就会被宣告攻破，所以 SSL/TLS 并没有强制应用某一种明码技术，而是提供了明码套件（Cipher Suite）这一机制，当某项明码技术被发现存在弱点，能够随时像整机一样替换它，当然前提是客户端和服务端应用雷同的明码技术。这也延长出了 SSL/TLS 的握手协定，协商应用的明码套件就是这一部分协定的次要工作之一。
想要 SSL/TLS 具备良好的安全性，就须要防止应用曾经被攻破或者曾经被验证为弱安全性的加密算法，要防止应用容易被预测的伪随机数生成器，要尽量保障各个算法具备近似的安全性（短板效应）。
因而，如何正确抉择明码套件，也成为了保障安全性的一个重要环节。这里我也会对目前举荐的明码技术和加密算法进行一个简略的整顿，心愿能够帮忙各位读者查漏补缺：
- 对称加密算法中 RC4、DES、3DES 都曾经被认为是不平安的了，目前举荐应用的只有 AES 和 ChaCha20。ChaCha20 是 Google 设计的一种加密算法，如果 CPU 或软件不反对 AES 指令集，ChaCha20 可提供比 AES 更好的性能。
- AES 这类对称加密算法只能加密固定长度的明文，想要加密任意长度的明文，还须要用到分组模式。晚期的 ECB、CBC、CFB、OFB 等分组模式曾经被认定为存在安全漏洞，目前更举荐应用 GCM、CCM 和 Poly1305。
- 罕用的非对称加密算法有 DH、RSA、ECC 这几种。因为 DH 和 RSA 都不具备前向安全性，目前曾经不举荐应用，TLS 1.3 中更是间接破除了 DH 和 RSA 算法，取而代之的是平安强度和性能都显著优于 RSA 的 ECC 算法，它有两个子算法，ECDHE 用于密钥替换，ECDSA 用于数字签名。但须要留神的是，因为 ECDHE/DHE 不提供身份验证，因而服务端该当启用对客户端证书的验证。
- 散列算法方面，咱们熟知的 MD5 和 SHA-1 都曾经被认定为不再牢靠，不举荐持续应用。目前通常倡议应用 SHA256 或更高版本。
在理解举荐应用的明码技术当前，兴许咱们想要批改客户端或服务端的明码套件配置，但此时咱们可能会发现这些明码套件的名称还有点难以了解。例如 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384，其中 TLS 只是示意协定，ECDHE 示意密钥替换算法，ECDSA 示意身份认证算法，AES_256_CBC 示意批量加密算法，SHA384 示意音讯认证码 MAC 算法。这通常是 TLS 1.2 中明码套件的命名格局，而到了 TLS 1.3 则又产生了一些变动。因为 TLS 1.3 只承受应用 ECDHE 算法进行密钥替换，并且应用 ECDSA 进行身份认证，因而它的明码套件名称能够精简成 TLS_AES_256_GCM_SHA384 这种格局。
如果仅从安全性角度登程，集体倡议应用 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 和 TLS_AES_256_GCM_SHA384。但思考到目前仍有很多以 RSA 形式签发的证书正在应用，因而咱们还须要依据本身状况来抉择是否要持续应用 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。
构建平安认证体系典型架构
采纳基于 PKI/CA 的数字证书体系是解决车联网平安要害的一步，也是大多数车企典型平安管理体系。其次要的设计思路如下：
- 基于数字证书的身份标识：通过 PKI/CA 零碎建设谨严的证书治理和应用标准，为车联网的利用和终端颁发数字证书，虚构身份和实在身份进行绑定，解决身份标识和唯一性问题（可实现一机一密或一型一密）；
- 所有数据交互时通过终端的身份惟一标识证实身份的真实性，避免第三方歹意入侵；
- 基于数字证书平安性能，提供身份甄别、身份认证、数据加解密、数字签名与验签等多种性能，满足车联网中 TSP、OTA 等多业务平安需要。
车联网平台平安通信交互流程，个别是将车机端申请终端证书，下载并残缺装置后通过 MQTTS 平安协定与云端平台申请建设平安连贯。在云端咱们能够抉择在云厂商的负载平衡产品、基于 Nginx/HAProxy 自行搭建的 LB 层或是 MQTT Broker 层进行认证鉴权，同时通过 proxy_protocol v2 将车机端的 ID 信息、用户名明码及证书的 CN/SN 等信息通过调用 PKI/CA 对立认证接口进行唯一性认证，实现一机一密或一型一密的平安认证。
MQTTS 通信中单、双向认证的配置形式
SSL/TLS 连贯认证认证的是对方身份，是否是可信的通信对象，认证的根据则是通信对象提供的证书。通常状况下是由客户端对服务端的身份进行认证，也就是所谓的单向认证。那么双向认证顾名思义就是在单向认证的根底上，服务端对客户端的身份进行认证。
认证的原理其实非常简单，以单向认证为例，最简略的状况就是服务端在 SSL/TLS 握手阶段发送服务端证书，客户端验证该证书是否由受信赖的 CA 机构签发，也就是应用受信赖的 CA 证书中的公钥来验证服务端证书中的数字签名是否非法。当然大部分状况会比这个略微简单一些，即服务端的证书不是由最顶层的 CA 机构间接签发的，而是由根 CA 机构对上层 CA 机构的公钥施加数字签名，造成两头 CA 证书，这样的关系可能会多达几层，以尽可能爱护根证书的平安。大部分状况下常见 CA 机构的根 CA 证书和两头 CA 证书都曾经内置在咱们的操作系统中了，只有多数状况下须要自行添加信赖的 CA 证书。
多级证书或者说证书链的认证过程会略微简单一些，但如果咱们搞明确了后面说的证书签发逻辑，其实了解起来也很简略。还是以单向认证为例，如果客户端只信赖了根 CA 证书，那么服务端在握手阶段就须要发送服务端证书和根 CA 证书到服务端证书之间的所有两头 CA 证书。只有客户端拿到了残缺的证书链，能力通过本人持有的根 CA 证书一层一层往下验证，短少两头 CA 导致证书链不残缺或者蕴含了谬误的两头 CA，都会导致信赖链中断而无奈通过认证。
如果客户端除根 CA 证书以外，还持有一部分两头 CA 证书，那么在认证过程中，服务端还能够省略这些两头 CA 证书的发送，来进步握手效率。
因而，当咱们配置单向认证时，须要在服务端指定服务端证书和两头 CA 证书（可选），以及服务端私钥文件。客户端则须要信赖相应的根 CA 证书，信赖的形式能够是在连贯时指定或者通过证书管理工具将该根 CA 证书增加到信赖列表。通常客户端库还提供了对端验证选项容许抉择是否验证证书，敞开对端验证将在不验证证书的状况下间接创立加密的 TLS 连贯。但这会带来中间人攻打的平安危险，因而强烈建议启用对端验证。
在启用对端验证后，客户端通常还会查看服务器证书中的域名（SAN 字段或 CN 字段）与本人连贯的服务器域名是否匹配。如果域名不匹配，则客户端将回绝对服务器进行身份验证或建设连贯。
双向认证的配置形式只须要在单向认证的根底上，在服务端启用对端验证即示意启用双向认证以外，再参考服务端证书的配置形式正确配置客户端证书即可。
常见 TLS 选项介绍
当应用 EMQX 配置 SSL/TLS 连贯时，通常会有 certfile、keyfile 等选项，为了帮忙大家更好地理解这些选项的配置形式，接下来咱们会对这些常见的 TLS 选项做一个简略的梳理和介绍：
- certfile，用于指定服务端或客户端证书和两头 CA 证书，须要指定多个证书时通常将它们简略地合并到一个证书文件中即可。
- keyfile，用于指定服务端或客户端私钥文件。
- cacertfile，用于指定 Root CA 证书，单向认证时客户端须要配置此选项以校验服务端证书，双向认证时服务端也须要配置此选项以校验客户端证书。
- verify，用于指定是否启用对端验证。客户端启用对端验证后通常还会去查看连贯的服务器域名与服务器证书中的域名是否匹配。客户端与服务端同时启用则意味着这将是一个双向认证。
- fail_if_no_peer_cert，这是一个服务端的选项，通常在服务端启用对端验证时应用，设置为 false 示意容许客户端不发送证书或发送空的证书，相当于同时开启单向认证和双向认证，这会减少中间人攻打的危险。
- versions，指定反对的 TLS 版本。通信单方会在握手过程中，将 versions 选项中指定的版本发送给对方，而后切换至单方都反对的最高版本。同时也会基于该协定版本来协商明码套件。
- ciphers，指定反对的明码套件。注意事项：防止应用前文提到的或其余被认定为弱安全性的明码套件，以及当应用蕴含 ECDSA 签名算法的明码套件时，须要额定留神本人的证书是否为 ECC 类型。
- server_name_indication，服务器名称批示，这是一个客户端的选项。通常在客户端启用对端验证且连贯的服务器域名与服务器证书中的域名不匹配时应用。例如服务器证书中的域名为 abc.com，而客户端连贯的是 123.com，那么就须要客户端在连贯时指定 server_name_indication 为 abc.com 示意本人信赖该域名以通过证书查看。又或者将 server_name_indication 设置为 disable 来敞开此项查看，但这会减少中间人攻打的危险，通常并不倡议这样做。
示例
为了便于演示，咱们会应用 EMQX（4.3.0 版本及以上）作为服务端，在 EMQX 的控制台中应用 Erlang 的 ssl:connect/3 函数作为客户端。
单向认证
批改 EMQ X 配置如下：
# 监听端口咱们应用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，蕴含了服务端证书和两头 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 不开启对端验证
listener.ssl.external.verify = verify_none
# 反对 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端反对的明码套件
listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384启动 EMQ X 并进入控制台：
$ ./emqx console应用 ssl:connect/3 函数连贯：
%% 1. 指定用于验证服务端证书的 Root CA 证书
%% 2. 启用对端验证
%% 3. 仅反对 TLS 1.2
%% 4. 仅反对 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这一个明码套件
ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
{verify, verify_peer},
{versions, ['tlsv1.2']},
{ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).双向认证
为了尽快进入正题，这里将持续应用服务端证书来充当客户端证书，这会有重大的安全隐患，在生产环境中请禁止这样应用！
批改 EMQ X 配置如下：
# 监听端口咱们应用默认的 8883
listener.ssl.external = 8883
# 服务端私钥文件
listener.ssl.external.keyfile = etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key
# 证书捆绑包文件，蕴含了服务端证书和两头 CA 证书
listener.ssl.external.certfile = etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt
# 指定用于验证客户端证书的 Root CA 证书
listener.ssl.external.cacertfile = etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem
# 启用对端验证
listener.ssl.external.verify = verify_peer
# 要求客户端必须提供证书
listener.ssl.external.fail_if_no_peer_cert = true
# 反对 TLS 1.2 和 TLS 1.3
listener.ssl.tls_versions = tlsv1.3,tlsv1.2
# 服务端反对的明码套件
listener.ssl.external.ciphers = TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384启动 EMQ X 并进入控制台，而后应用 ssl:connect/3 函数连贯：
%% 1. 指定用于验证服务端证书的 Root CA 证书
%% 2. 启用对端验证
%% 3. 仅反对 TLS 1.2
%% 4. 仅反对 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这一个明码套件
ssl:connect("zhouzb.club", 8883, [{cacertfile, "etc/certs/zhouzb.club/DigiCertGlobalRootCA.crt.pem"},
{certfile, "etc/certs/zhouzb.club/Nginx/1_zhouzb.club_bundle.crt"},
{keyfile, "etc/certs/zhouzb.club/Nginx/2_zhouzb.club.key"},
{verify, verify_peer},
{versions, ['tlsv1.2']},
{ciphers, ["TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]}]).结语
工业和信息化部印发的《车联网网络安全和数据安全规范零碎建设指南》中明确指出，要构建车联网网络安全和数据安全的规范体系。车联网畛域的网络通信平安和数据安全将受到越来越多的关注，是车联网企业进步竞争力的要害影响因素之一。心愿通过本文，读者能够把握 SSL/TLS 协定的应用形式，在理论业务场景中正确利用，实现车联网通信安全保障。
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.com/zh/blog/ssl-tls-for-internet-of-vehicles-communication-security
