前言

專注分享開源項目整套解決方案，完全開源、可學習、可商用、寶藏庫。

完整開源項目后端技術棧：Spring6、JDK17、SpringBoot、Spring Cloud、Docker、Nginx、Redis、MongoDB、MySql不管你技術提升還是接私活都可以用到。

完整開源項目前端技術棧：vue3、vite3、TypeScript/4、Ant-Design-Vue/3.2、element-plus/2.2、uniapp、H5網頁、PC、微信小程序等最新的技術。

每天提供一個超棒的開源項目包含：物聯網平臺、WMS系統、ERP系統、OMS系統、知識社區、個人博客系列。

在本專題系列文章中，我們將根據 EMQ 在車聯網領域的實踐經驗，從協議選擇等理論知識，到平臺架構設計等實戰操作，與大家分享如何搭建一個可靠、高效、符合行業場景需求的車聯網平臺。

一、前言

在汽車出行愈加智能化的今天，我們可以實現手機遠程操控車輛解鎖、啟動通風、查看車輛周圍影像，也可以通過 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 配置如下：

# 監聽端口我們使用默認的 8883listener.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.3listener.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 配置如下：

# 監聽端口我們使用默認的 8883listener.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.3listener.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 協議的使用方式，在實際業務場景中正確應用，實現車聯網通信安全保障。

來源：汽車電子電氣架構創新發展論壇