作者 |沈平 上海控安可信軟件創(chuàng)新研究院汽車網(wǎng)絡(luò)安全組

來源 |鑒源實驗室

社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區(qū)”

在現(xiàn)代汽車行業(yè)中，隨著電子控制單元（ECUs）的普及以及車與車之間通信的不斷增加，確保通信安全變得尤為關(guān)鍵。AUTOSAR (Automotive Open System Architecture) 的 SecOC (Secure Onboard Communication) 模塊，正是為應(yīng)對這種挑戰(zhàn)而設(shè)計的。AUTOSAR作為一套開放的汽車軟件標準，其中的SecOC模塊在其架構(gòu)中起到了至關(guān)重要的角色，它主要職責(zé)是確保車輛內(nèi)部的通訊數(shù)據(jù)安全無虞。通常，SecOC模塊是位于AUTOSAR通訊堆棧的PDU Router與更底層的通訊驅(qū)動之間，確保所有通過這個堆棧的信息都得到了適當?shù)募用芎捅Ｗo。實際應(yīng)用中，SecOC模塊還能與HSM (Hardware Security Module) 模塊相結(jié)合，借助硬件來更快速地進行數(shù)據(jù)加密和消息認證。

圖1 SecOC在BSW中的架構(gòu)圖

SecOC通信流程依賴于兩大核心組件：消息認證與新鮮度值（Freshness Value，F(xiàn)V）。為了確保消息的真實性與完整性，SecOC利用消息認證碼（Message Authentication Code，MAC）進行核實。在消息發(fā)送過程中，系統(tǒng)會利用預(yù)定的密鑰生成MAC，并將其附加在原消息之后。而在消息接收端，系統(tǒng)會再次利用相同的密鑰計算MAC，并與接收到的MAC進行校驗。如若不符，則表明消息在傳輸過程中可能遭到了篡改，或者并非來自一個合法的發(fā)送方。而Freshness Value（FV）的存在主要是為了應(yīng)對“重放攻擊”。為此，每一條消息都會伴隨一個FV值。這是一個不斷變化的動態(tài)值，如計數(shù)器或時間戳，確保每一條發(fā)送的消息均具有其獨特性。在MAC的生成過程中，F(xiàn)V也起到了關(guān)鍵作用。這一整個流程如圖2所示。

圖2 SecOC通訊流程圖

接下來，我們將根據(jù)AUTOSAR SecOC官方文檔的附錄11.4，深入探討基于多新鮮度計數(shù)器的SecOC機制是如何實現(xiàn)的。在此示例中，我們遇到三個關(guān)鍵運行實體，它們是：新鮮度管理器ECU（即“Master”），以及負責(zé)接收和發(fā)送報文的ECU（我們稱之為“Slave”）。在此機制中，Slave的任務(wù)是接收來自Master廣播的Freshness Value（FV）計數(shù)，以便同步更新其本地的FV計數(shù)。簡單地說，Master負責(zé)維護并廣播當前的FV計數(shù)，而Slave根據(jù)接收到的計數(shù)進行更新，確保它們的計數(shù)值保持一致。這種同步機制是為了確保在整個系統(tǒng)中，每次的通信都有一個獨特的、不斷更新的FV，以加強安全性。這三者之間的交互和關(guān)系可以在圖3中看到。

圖3 多新鮮度計數(shù)器管理關(guān)系圖

在SecOC通信流程中，所有的數(shù)據(jù)傳輸都默認采用大端模式。發(fā)送者發(fā)送的安全報文（簡稱S-I-PDU）由幾個部分組成：S-I-PDU報文頭、待保護的交互層協(xié)議數(shù)據(jù)單元（I-PDU）、Freshness Value（FV）和Authenticator（也稱為MAC）。值得注意的是，S-I-PDU報文頭和FV并不是每次都必須的，它們是可選組件。另外，I-PDU不一定包含原始報文中的所有載荷（payload），它可能僅包含部分數(shù)據(jù)。進一步說，通常情況下，我們不會完整地發(fā)送FV和MAC的所有數(shù)據(jù)。為了效率和安全性的考慮，我們通常只選取其中的部分數(shù)據(jù)包含在S-I-PDU中。具體來說，對于FV，我們從其低位開始，選取一定長度的數(shù)據(jù)；而對于MAC，我們則從其高位開始，選取一定長度的數(shù)據(jù)。這種數(shù)據(jù)組織和截取的方式確保了在有限的報文長度內(nèi)，我們可以傳輸最關(guān)鍵的、具有代表性的數(shù)據(jù)。如圖4和圖5所詳細展示。

圖4 安全報文構(gòu)成圖

圖5 FV和MAC截取示意圖

MAC（消息認證碼）的計算是關(guān)于數(shù)據(jù)完整性和真實性驗證的核心。在SecOC中，其生成主要采用對稱加密算法。例如，通過使用AES算法，我們可以得到CMAC（加密消息認證碼）。為了計算MAC，我們需要考慮幾個關(guān)鍵部分：

· Data Id：這是一個兩字節(jié)的數(shù)據(jù)標識符，它有助于區(qū)分和識別不同的I-PDU。

· I-PDU的保護部分：這并不是完整的I-PDU數(shù)據(jù)，而是我們選擇需要加密保護的部分。

· 完整的FV (Freshness Value)：如前所述，F(xiàn)V是一個動態(tài)的值，用于確保每條消息的獨特性，避免重放攻擊。

將這三個部分組合起來，我們就可以得到MAC的輸入數(shù)據(jù)。然后通過應(yīng)用特定的加密算法（如AES生成CMAC），將這些輸入轉(zhuǎn)化為獨特的MAC值。如圖6所示。

圖6 生成MAC數(shù)據(jù)構(gòu)成圖

在此示例中，完整的Freshness Value（FV）是由以下四個部分構(gòu)成的：

· Trip Counter (TripCnt)：由主Freshness Value Manager（主FVM）控制，每一次“trip”（如車輛啟動和關(guān)閉的周期）都會遞增。它主要記錄了車輛啟動的次數(shù)。上下電時觸發(fā)。

· Reset Counter (ResetCnt)：由主FVM管理，它基于配置的周期（ResetCycle）進行周期性遞增。可以看作是一個中間級別的計數(shù)器，用于追蹤系統(tǒng)重置的次數(shù)。

· Message Counter (MsgCnt)：與發(fā)送器ECU相關(guān)，每次發(fā)送信息時都會遞增。用于追蹤特定ECU發(fā)送的消息數(shù)量。

· Reset Flag (ResatFlag)：與ResetCnt同步更新。它直接取自ResetCnt的低位數(shù)據(jù)，大小通常為兩個bit。作為一個標志位，它提供了關(guān)于系統(tǒng)重置狀態(tài)的快速參考。

當我們談到需要截取的FV時，特指Reset Flag和MsgCntLower（消息計數(shù)器的低位部分）。如圖7所示，這些組件如何組合以形成完整的FV。同時，它們之間的更新關(guān)系和如何相互影響可以在圖8中看到。這種設(shè)計確保了在保持消息的唯一性和安全性的同時，系統(tǒng)能夠高效地進行操作。

圖7 FV構(gòu)成與截取圖

圖8 FVCnt更新邏輯圖

接下來，我們將探討SecOC的同步報文（稱為SyncMsg）及其結(jié)構(gòu)。在SecOC的上下文中，同步報文起著至關(guān)重要的作用，它確保系統(tǒng)中的所有實體（例如Slave）與主控制實體（例如Master或通常在整車中的網(wǎng)關(guān)）保持同步。簡而言之，它允許這些實體對關(guān)鍵的計數(shù)器值和狀態(tài)有一個統(tǒng)一的理解，從而確保整個通信過程的安全性。同步報文的構(gòu)成如下：TripCnt、ResetCnt和MAC。如圖9所示，這三個部分組合形成了完整的同步報文。Master（通常是網(wǎng)關(guān)）會定期發(fā)送這些同步報文，確保系統(tǒng)中的所有Slave能夠與之保持同步，從而維護整個系統(tǒng)的安全通信。

圖9 SyncMsg構(gòu)成

同步報文的MAC計算與安全報文的MAC確實存在細微差異。在同步報文的環(huán)境中，為了確保消息的真實性和完整性，我們需要使用稍有不同的數(shù)據(jù)元素來生成MAC。在同步報文中，生成MAC需要以下數(shù)據(jù)：

· Message ID (MsgID)：這是一個唯一標識該消息的值。它有助于區(qū)分和識別不同的同步報文。MsgID通常占用兩個Byte。

· Freshness Value (FV)：在這種上下文中，F(xiàn)V由TripCnt和ResetCnt組成。

為了確保整體數(shù)據(jù)長度為整個Byte，如果這兩個計數(shù)器的組合不構(gòu)成完整的Byte長度，那么后續(xù)的空白部分會用0來補齊。如圖10所示，MsgID、TripCnt和ResetCnt是順序排列的，然后將這些數(shù)據(jù)輸入加密算法來生成MAC。

圖10 同步報文MAC生成數(shù)據(jù)構(gòu)成圖

上文為大家淺析了SecOC的通訊機制。接下來，我們將模擬這一機制進行實驗。利用特定的CAN總線仿真工具，我們配置了一個Master節(jié)點和一個Slave發(fā)送節(jié)點。為確保仿真節(jié)點的SecOC機制無誤，我們還使用了某CAN總線測試工具進行驗證和檢驗。

將同步報文ID配置為0x100、TripCnt的長度配置為24 bit、ResetCnt的長度配置為18 bit以及MAC的長度配置為16 bit，MAC生成的對稱加密算法選擇為AES-128，密鑰為12345678901234567890123456789012。將以上同步報文以2秒將ResetCnt遞增的方式。具體信息如圖11所示。

圖11 同步報文配置信息表

將安全報文ID配置為0x0、IPDU長度配置為40 bit，F(xiàn)V的長度配置為8 bit以及MAC的長度配置為16 bit。MAC生成的對稱加密算法選擇為AES-128，密鑰為12345678901234567890123456789012。具體信息如圖12所示。

圖12 安全報文配置信息表

在仿真節(jié)點中完成以上參數(shù)的配置后，在測試工具中完成相應(yīng)的參數(shù)配置，并進行SecOC機制的驗證，通過測試結(jié)果調(diào)試自己的仿真節(jié)點邏輯。如圖13、14、15所示。

圖13 SecOC機制參數(shù)配置圖

圖14 安全報文驗證圖

在圖14中，紅色框中內(nèi)容表示測試工具作為安全報文接收節(jié)點，收到發(fā)送節(jié)點（仿真節(jié)點）發(fā)送的安全報文信息，其中要保護的I-PDU為78901234，截斷的FV為00，截斷的MAC為E27277（16進制）。綠色框中內(nèi)容表示安全報文生成MAC時所需的數(shù)據(jù)。藍色框中內(nèi)容為測試工具根據(jù)配置信息所生成的MAC值。只有測試工具計算的MAC值與收到的截斷MAC值匹配才測試通過。

圖15 同步報文驗證圖

在圖15中，紅色框中內(nèi)容表示測試工具作為同步報文接收方，收到主節(jié)點發(fā)送的同步報文信息，其中TripCnt值為91，ResetCnt值為77，截斷的MAC為D608（16進制）。綠色框中內(nèi)容表示測試工具根據(jù)配置信息整合出來要生成MAC的數(shù)據(jù)（16進制，符合前文圖10結(jié)構(gòu)）。藍色框中內(nèi)容表示測試工具計算得到的MAC值。只有測試工具計算的MAC值與收到的截斷MAC值匹配才測試通過。

本文對AUTOSAR SecOC通訊機制進行了簡單的闡述，并通過建立仿真節(jié)點實現(xiàn)SecOC通訊機制，隨后通過測試工具驗證所實現(xiàn)的SecOC機制。

參考文檔：

AUTOSAR. (2022). Specification of Secure Onboard Communication. AUTOSAR Standard Working Specification.

審核編輯 黃宇