在現代汽車行業中，隨著電子控制單元（ECUs）的普及以及車與車之間通信的不斷增加，確保通信安全變得尤為關鍵。AUTOSAR (Automotive Open System Architecture) 的 SecOC (Secure Onboard Communication) 模塊，正是為應對這種挑戰而設計的。AUTOSAR作為一套開放的汽車軟件標準，其中的SecOC模塊在其架構中起到了至關重要的角色，它主要職責是確保車輛內部的通訊數據安全無虞。通常，SecOC模塊是位于AUTOSAR通訊堆棧的PDU Router與更底層的通訊驅動之間，確保所有通過這個堆棧的信息都得到了適當的加密和保護。實際應用中，SecOC模塊還能與HSM (Hardware Security Module) 模塊相結合，借助硬件來更快速地進行數據加密和消息認證。
圖1 SecOC在BSW中的架構圖
SecOC通信流程依賴于兩大核心組件：消息認證與新鮮度值（Freshness Value，FV）。為了確保消息的真實性與完整性，SecOC利用消息認證碼（Message Authentication Code，MAC）進行核實。在消息發送過程中，系統會利用預定的密鑰生成MAC，并將其附加在原消息之后。而在消息接收端，系統會再次利用相同的密鑰計算MAC，并與接收到的MAC進行校驗。如若不符，則表明消息在傳輸過程中可能遭到了篡改，或者并非來自一個合法的發送方。而Freshness Value（FV）的存在主要是為了應對“重放攻擊”。為此，每一條消息都會伴隨一個FV值。這是一個不斷變化的動態值，如計數器或時間戳，確保每一條發送的消息均具有其獨特性。在MAC的生成過程中，FV也起到了關鍵作用。這一整個流程如圖2所示。
圖2 SecOC通訊流程圖
接下來，我們將根據AUTOSAR SecOC官方文檔的附錄11.4，深入探討基于多新鮮度計數器的SecOC機制是如何實現的。在此示例中，我們遇到三個關鍵運行實體，它們是：新鮮度管理器ECU（即“Master”），以及負責接收和發送報文的ECU（我們稱之為“Slave”）。在此機制中，Slave的任務是接收來自Master廣播的Freshness Value（FV）計數，以便同步更新其本地的FV計數。簡單地說，Master負責維護并廣播當前的FV計數，而Slave根據接收到的計數進行更新，確保它們的計數值保持一致。這種同步機制是為了確保在整個系統中，每次的通信都有一個獨特的、不斷更新的FV，以加強安全性。這三者之間的交互和關系可以在圖3中看到。
圖3 多新鮮度計數器管理關系圖
在SecOC通信流程中，所有的數據傳輸都默認采用大端模式。發送者發送的安全報文（簡稱S-I-PDU）由幾個部分組成：S-I-PDU報文頭、待保護的交互層協議數據單元（I-PDU）、Freshness Value（FV）和Authenticator（也稱為MAC）。值得注意的是，S-I-PDU報文頭和FV并不是每次都必須的，它們是可選組件。另外，I-PDU不一定包含原始報文中的所有載荷（payload），它可能僅包含部分數據。進一步說，通常情況下，我們不會完整地發送FV和MAC的所有數據。為了效率和安全性的考慮，我們通常只選取其中的部分數據包含在S-I-PDU中。具體來說，對于FV，我們從其低位開始，選取一定長度的數據；而對于MAC，我們則從其高位開始，選取一定長度的數據。這種數據組織和截取的方式確保了在有限的報文長度內，我們可以傳輸最關鍵的、具有代表性的數據。如圖4和圖5所詳細展示。
圖4 安全報文構成圖
圖5 FV和MAC截取示意圖
MAC（消息認證碼）的計算是關于數據完整性和真實性驗證的核心。在SecOC中，其生成主要采用對稱加密算法。例如，通過使用AES算法，我們可以得到CMAC（加密消息認證碼）。為了計算MAC，我們需要考慮幾個關鍵部分：
- Data Id：這是一個兩字節的數據標識符，它有助于區分和識別不同的I-PDU。
- I-PDU的保護部分：這并不是完整的I-PDU數據，而是我們選擇需要加密保護的部分。
- 完整的FV (Freshness Value)：如前所述，FV是一個動態的值，用于確保每條消息的獨特性，避免重放攻擊。
將這三個部分組合起來，我們就可以得到MAC的輸入數據。然后通過應用特定的加密算法（如AES生成CMAC），將這些輸入轉化為獨特的MAC值。如圖6所示。
圖6 生成MAC數據構成圖
在此示例中，完整的Freshness Value（FV）是由以下四個部分構成的：
- Trip Counter (TripCnt)：由主Freshness Value Manager（主FVM）控制，每一次“trip”（如車輛啟動和關閉的周期）都會遞增。它主要記錄了車輛啟動的次數。上下電時觸發。
- Reset Counter (ResetCnt)：由主FVM管理，它基于配置的周期（ResetCycle）進行周期性遞增。可以看作是一個中間級別的計數器，用于追蹤系統重置的次數。
- Message Counter (MsgCnt)：與發送器ECU相關，每次發送信息時都會遞增。用于追蹤特定ECU發送的消息數量。
- Reset Flag (ResatFlag)：與ResetCnt同步更新。它直接取自ResetCnt的低位數據，大小通常為兩個bit。作為一個標志位，它提供了關于系統重置狀態的快速參考。
當我們談到需要截取的FV時，特指Reset Flag和MsgCntLower（消息計數器的低位部分）。如圖7所示，這些組件如何組合以形成完整的FV。同時，它們之間的更新關系和如何相互影響可以在圖8中看到。這種設計確保了在保持消息的唯一性和安全性的同時，系統能夠高效地進行操作。
圖7 FV構成與截取圖
圖8 FVCnt更新邏輯圖
接下來，我們將探討SecOC的同步報文（稱為SyncMsg）及其結構。在SecOC的上下文中，同步報文起著至關重要的作用，它確保系統中的所有實體（例如Slave）與主控制實體（例如Master或通常在整車中的網關）保持同步。簡而言之，它允許這些實體對關鍵的計數器值和狀態有一個統一的理解，從而確保整個通信過程的安全性。同步報文的構成如下：TripCnt、ResetCnt和MAC。如圖9所示，這三個部分組合形成了完整的同步報文。Master（通常是網關）會定期發送這些同步報文，確保系統中的所有Slave能夠與之保持同步，從而維護整個系統的安全通信。
圖9 SyncMsg構成
同步報文的MAC計算與安全報文的MAC確實存在細微差異。在同步報文的環境中，為了確保消息的真實性和完整性，我們需要使用稍有不同的數據元素來生成MAC。在同步報文中，生成MAC需要以下數據：
- Message ID (MsgID)：這是一個唯一標識該消息的值。它有助于區分和識別不同的同步報文。MsgID通常占用兩個Byte。
- Freshness Value (FV)：在這種上下文中，FV由TripCnt和ResetCnt組成。
為了確保整體數據長度為整個Byte，如果這兩個計數器的組合不構成完整的Byte長度，那么后續的空白部分會用0來補齊。如圖10所示，MsgID、TripCnt和ResetCnt是順序排列的，然后將這些數據輸入加密算法來生成MAC。
圖10 同步報文MAC生成數據構成圖
上文為大家淺析了SecOC的通訊機制。接下來，我們將模擬這一機制進行實驗。利用特定的CAN總線仿真工具，我們配置了一個Master節點和一個Slave發送節點。為確保仿真節點的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，FV的長度配置為8 bit以及MAC的長度配置為16 bit。MAC生成的對稱加密算法選擇為AES-128，密鑰為12345678901234567890123456789012。具體信息如圖12所示。
圖12 安全報文配置信息表
在仿真節點中完成以上參數的配置后，在測試工具中完成相應的參數配置，并進行SecOC機制的驗證，通過測試結果調試自己的仿真節點邏輯。如圖13、14、15所示。
圖13 SecOC機制參數配置圖
圖14 安全報文驗證圖
在圖14中，紅色框中內容表示測試工具作為安全報文接收節點，收到發送節點（仿真節點）發送的安全報文信息，其中要保護的I-PDU為78901234，截斷的FV為00，截斷的MAC為E27277（16進制）。綠色框中內容表示安全報文生成MAC時所需的數據。藍色框中內容為測試工具根據配置信息所生成的MAC值。只有測試工具計算的MAC值與收到的截斷MAC值匹配才測試通過。
圖15 同步報文驗證圖
在圖15中，紅色框中內容表示測試工具作為同步報文接收方，收到主節點發送的同步報文信息，其中TripCnt值為91，ResetCnt值為77，截斷的MAC為D608（16進制）。綠色框中內容表示測試工具根據配置信息整合出來要生成MAC的數據（16進制，符合前文圖10結構）。藍色框中內容表示測試工具計算得到的MAC值。只有測試工具計算的MAC值與收到的截斷MAC值匹配才測試通過。
本文對AUTOSAR SecOC通訊機制進行了簡單的闡述，并通過建立仿真節點實現SecOC通訊機制，隨后通過測試工具驗證所實現的SecOC機制。
參考文檔：
AUTOSAR. (2022). Specification of Secure Onboard Communication. AUTOSAR Standard Working Specification.
轉自汽車ECU開發
