電子發(fā)燒友App
01
背 景
隨著車聯(lián)網(wǎng)的迅猛發(fā)展，汽車已經(jīng)不再是傳統(tǒng)的機械交通工具，而是智能化、互聯(lián)化的移動終端。然而，隨之而來的是對車輛通信安全的日益嚴峻的威脅。在車聯(lián)網(wǎng)生態(tài)系統(tǒng)中，車輛通過無線網(wǎng)絡與其他車輛、基礎設施以及云端服務進行廣泛通信，這種高度互聯(lián)的狀態(tài)也使得車輛系統(tǒng)更容易受到各種潛在的威脅和攻擊。
通信安全問題在車聯(lián)網(wǎng)中尤為突出，可能面臨諸如數(shù)據(jù)竊取、信息篡改、惡意注入以及拒絕服務等多種威脅。黑客可能試圖獲取車輛傳感器和控制單元的敏感信息，篡改車輛間的通信數(shù)據(jù)，甚至遠程控制車輛執(zhí)行危險操作。這些潛在的威脅對駕駛安全、車輛保障以及交通管理都構成了巨大的挑戰(zhàn)。
為了有效應對這些安全威脅，通信安全加密成為車聯(lián)網(wǎng)中的關鍵環(huán)節(jié)。在這一背景下，傳輸層安全協(xié)議（TLS）作為一種通用的安全通信協(xié)議，為車輛通信提供了可靠的安全保護。通過強化數(shù)據(jù)的保密性、完整性和身份驗證，TLS在車聯(lián)網(wǎng)中發(fā)揮著至關重要的作用，有效應對通信安全所面臨的復雜挑戰(zhàn)。
02
TLS 基本原理
2.1 ?基本介紹
傳輸層安全協(xié)議（TLS）是一種加密通信協(xié)議，用于確保在網(wǎng)絡上的數(shù)據(jù)傳輸過程中的安全性和隱私保護。TLS的前身是安全套接層協(xié)議（SSL），后來在標準化過程中發(fā)展成為TLS。TLS協(xié)議的主要目標是通過加密和認證機制，保護網(wǎng)絡通信的機密性、完整性和身份驗證，以抵御可能的網(wǎng)絡攻擊和竊聽。
TLS協(xié)議主要通過以下方式實現(xiàn)安全通信：
加密（Encryption）：使用加密算法對傳輸?shù)臄?shù)據(jù)進行加密，確保在傳輸過程中數(shù)據(jù)不被未授權的第三方讀取或修改。
認證（Authentication）：通過數(shù)字證書等機制驗證通信雙方的身份，確保通信的對端是合法的，并防止中間人攻擊。
完整性保護（Integrity Protection）： 使用消息摘要算法（如哈希函數(shù)）來驗證數(shù)據(jù)在傳輸過程中是否被篡改，以保障數(shù)據(jù)的完整性。
TLS協(xié)議廣泛應用于互聯(lián)網(wǎng)通信中，尤其在Web瀏覽器與服務器之間的安全通信中扮演關鍵角色。當用戶訪問使用“https://”協(xié)議的網(wǎng)站時，TLS協(xié)議就會啟動，確保用戶與網(wǎng)站之間的數(shù)據(jù)傳輸是安全可信的。TLS協(xié)議的不斷升級和改進也反映了對網(wǎng)絡安全不斷演進的需求。
2.2 ?TLS握手過程
2.2.1 TLS 1.2 握手過程
TLS（Transport Layer Security）握手過程是確保安全通信的關鍵步驟，它涉及到協(xié)商加密算法、驗證通信雙方的身份，并生成用于加密通信的會話密鑰，通常包含以下幾個流程：
客戶端發(fā)出請求（ClientHello）。在此流程中，客戶端會提供如下信息：
客戶端生成一個隨機數(shù)，稱為ClientRandom，這個隨機數(shù)的目的是在握手過程中引入熵（entropy），增加通信的隨機性，提高安全性；
客戶端會列舉支持的加密算法、摘要算法以及密鑰交換算法等。這是為了告知服務器它可以使用哪些算法來保護通信；
客戶端會提供其他通信參數(shù)，例如支持的壓縮算法等。這些參數(shù)提供了有關客戶端支持的通信設置的信息。
使用Wireshark打開包含TLS ClientHello數(shù)據(jù)的流量包時，通常可以看到如下內(nèi)容：
ClientHello:
Random: [隨機數(shù)]
CompressionMethods: [支持的壓縮算法列表]
Extensions: [其他擴展，例如SNI（Server Name Indication）]? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
圖1 ClientHello示意圖
ClientHello的目標是為服務器提供足夠的信息，以便服務器能夠做出響應，并在握手過程中建立一個安全的通信通道。服務器將使用這些信息來選擇合適的加密算法、生成自己的隨機數(shù)、以及執(zhí)行其他必要的步驟來協(xié)商出一個安全的連接。
服務器回應（SeverHello）。在此流程中，服務器會回復以下信息：
服務器會生成一個隨機數(shù)，稱為ServerRandom。類似于ClientRandom，它增加了握手過程的熵，提高了通信的隨機性和安全性；
服務器從客戶端提供的加密算法列表中選擇一個算法，用于后續(xù)的通信加密；
服務器確認客戶端提供的其他通信參數(shù)，例如TLS版本、壓縮算法等；
如果服務器支持會話緩存和復用，還會生成一個Session ID發(fā)送給客戶端。客戶端可以在未來的握手中使用該Session ID來恢復先前的會話狀態(tài)，以加速握手過程。
使用Wireshark打開包含TLS ServerHello數(shù)據(jù)的流量包時，通?？梢钥吹饺缦聝?nèi)容：
ServerHello:
Random: [隨機數(shù)]
CipherSuite: [選擇的加密算法]
CompressionMethod: [選擇的壓縮算法]
Session ID: [會話標識，如果支持會話復用]
Extensions: [其他擴展，例如支持的應用層協(xié)議（ALPN）]
圖2 ServerHello示意圖
客戶端回應。在此流程中，客戶端會回復以下信息：
客戶端和服務器使用已經(jīng)在之前握手步驟中交換的隨機數(shù)生成一個預主密鑰，稱為Pre-Master Secret，并使用服務器的公鑰進行加密，發(fā)送給服務器。
服務器再次回應。在此流程中，服務器會回復以下信息：
服務器收到客戶端傳輸?shù)募用苄畔⒑螅褂闷渌借€解密并獲得 Pre-Master Secret。
服務器和客戶端使用已經(jīng)交換的隨機數(shù)和 Pre-Master Secret 生成一個 Master Secret（主密鑰）。
隨后，客戶端發(fā)送ChangeCipherSpec消息給服務器，通知服務器從此時開始使用新生成的密鑰加密通信內(nèi)容，服務器同樣給出回應，至此，整個握手階段全部結束。
圖3 ChangeCipherSpec示意圖
2.2.2 TLS雙向認證
單向認證和雙向認證是TLS常用的兩種身份驗證機制，它們的主要區(qū)別在于驗證的參與方和方式。
單向認證是指單向認證僅驗證一方的身份，通常是客戶端驗證服務器的身份，確保客戶端連接到合法的服務器。流程與上述握手過程相同。單向認證適用于大多數(shù)互聯(lián)網(wǎng)服務，服務提供商或服務的擁有者驗證其身份，而客戶端無需提供身份驗證。
雙向認證是指通信過程中需要驗證兩方的身份。客戶端請求連接服務器，服務器提供數(shù)字證書，客戶端驗證服務器的身份；同時，客戶端也會發(fā)出CertificateRequest請求，要求客戶端也提供數(shù)字證書，服務器發(fā)送Certificate驗證至客戶端的身份，至此，雙向認證完成。雙向認證通常用于對通信安全性要求較高的場景，例如在線支付、云服務、金融應用等，確保通信的雙方都是合法的。
圖4 Certificate示意圖
2.3 TLS 1.3
2.3.1 握手過程
TLS 1.3在握手過程上進行了一些改進，提高安全性和性能。在上述的TLS 1.2握手過程中，通常需要進行ClintHello、ServerHello、兩次密鑰交換，共兩個來回的完整握手過程，而在TLS 1.3中將Hello和密鑰交換過程進行了合并，有效減少了握手次數(shù)。
圖5 TLS 1.3中ServerHello直接進行了密鑰交換
2.3.2 其他改進
1）刪除不安全算法支持：
TLS 1.3棄用了一些不安全或弱密碼算法，進一步提高了安全性。例如，去除了對MD5、SHA-1、RC4等算法的支持。
2）使用HKDF進行密鑰派生：
TLS 1.3使用基于HMAC的密鑰派生函數(shù)（HKDF）來派生密鑰材料，增強了密鑰派生的安全性。
3）提供前向保密：
TLS 1.3使用Diffie-Hellman密鑰交換算法的TLS 1.3握手過程中，提供了前向保密性，保證即使服務器的長期私鑰泄漏，以前的通信也不會受到影響。
4）支持0-RTT恢復：
TLS 1.3引入了支持0-RTT（零輪往返時間）的特性，允許客戶端在第一次連接時發(fā)送數(shù)據(jù)，從而進一步提高性能。
03
結 語
通過以上對TLS的介紹，希望大家能夠?qū)LS原理有更清晰的認識，能夠使用wireshark對TLS流量包進行簡單的分析。如今TLS在車聯(lián)網(wǎng)中扮演著關鍵的角色，通過加密、身份驗證和完整性保護等機制，為車輛之間和車輛與基礎設施之間的通信提供了可靠的安全保障。這對確保車輛網(wǎng)絡的穩(wěn)定性、用戶隱私和遠程控制的安全性都至關重要。
審核編輯：黃飛
?
工商網(wǎng)監(jiān)
評論