前言
我們知道，在車載網路中，大部分的資料都是以明文方式廣播傳送且無認證接收。這種方案在以前有著低成本、高效能的優勢，但是隨著當下智慧網聯化的程式，這種方案所帶來的安全問題越來越被大家所重視。
為了提高車載通訊的安全性，各OEM已經採用針對敏感資料增加諸如RollingCounter和Checksum的資訊，但其能實現的安全性十分有限。
而隨著車載網路技術的發展，我們有了更多的方式來實現網路安全。之前我們曾介紹過E2E（End to End）的技術，本期我們將介紹SecOC方案。
SecOC簡介
SecOC全稱Secure Onboard Communication，主要用於對車內敏感資訊進行認證。
其資料結構如下：Authentic I-PDU是需要被保護的資料；Authenticator為認證資訊（通常使用訊息認證碼，即Message Authentication Code，簡稱MAC，後文以MAC來簡稱此內容）；Secured I-PDU Header為可選用的報頭；Freshness Value為可選用的新鮮度值。
圖1 Secured I-PDU結構
而在實際使用中，新鮮度值和MAC可能會使用較多長度的資料來提高安全性，但這又會消耗大量的頻寬等資源，所以常使用擷取的方式做平衡處理。新鮮度值和MAC都按照完整的值來生成，但是在傳送和認證的時候只會擷取一部分，如下圖所示：
圖2 Secured I-PDU的擷取
以CANoe demo中的ARXML為例，其節點ECU1傳送的Secured_PDU_1分別包含了8個位元組的Authentic I-PDU，1個位元組的新鮮度值（實際長度8位元組）和3個位元組的MAC（實際長度16位元組）。
圖3 Secured I-PDU在ARXML中的排布示例
接下來我們就以此Demo為例，來詳細談談SecOC中2個重要的組成部分：新鮮度值管理（Freshness Value Manager，簡稱FVM）和MAC生成。
新鮮度值管理
在SecOC中，給出了多種新鮮度值管理方案：
- 基於counter的遞增，即包含了原有方案的機制
- 基於全域性時間戳，源於時間戳的唯一性
- 基於同步的複合counter
這裡我們主要談一下第三種方案。在此方案中，完整的新鮮度值包括同步計數器（Trip Counter）、重置計數器（Reset Counter）、重置標誌值（Reset Flag）和訊息計數器（Message Counter）。其中訊息計數器又分為高值和低值，而真正在報文中傳送的值只包含訊息計數器的低值和重置標誌值。
圖4 新鮮度值結構
新鮮度值的更新如下所示，完整的新鮮度值為0x10000040F，實際傳送的新鮮度值為0xF。而由於重置標誌值為1 bit，訊息計數器雖然以步長1遞增，實際傳送到匯流排上的新鮮度值則是以2的步長遞增。
圖5 新鮮度值示例
從上述內容可以看出，新鮮度值存在2個重要的基準：同步計數器和重置計數器，這2個計數器需要接收方和傳送方保持一致。SecOC在新鮮度值管理上提出了主從模式的框架，由主節點向接收方和傳送方分發同步計數器和重置計數器，從而達到同步的目的。
圖6 主從模式的新鮮度值管理
圖7 新鮮度值的分發示例
MAC生成
MAC是對受保護資料的身份認證。其中涉及的加密演算法多種多樣，每個演算法還可以有多個配置。這裡我們以SecOC提供的一個方案Profile 1進行說明，其使用CMAC/AES-128的演算法，擷取8 bit的新鮮度值和24 bit的MAC，配置資訊如下所示。
圖8 Profile 1配置
除此配置外，MAC生成還需要128 bit的金鑰（這裡預先定義了0x0102030405060708090A0B0C0D0E0F10）、16 bit的Data ID（這裡預先定義了33）、完整的新鮮度值和需要認證的資料。Data ID是用來標識I-PDU的資料，可以給金鑰管理機制提供支援。以Demo中時間戳為8.300203的I-PDU進行說明，需要認證的資料為0xE8030000000000FF，完整的新鮮度值為0x100000405，實際進行加密運算的資料為Data ID、待認證資料和完整新鮮度值的拼接，計算後的實際MAC為0x498330e818f3fbb068759ff3b72d015f，擷取24 bit後傳送的MAC為0x498330。
圖9 MAC傳送示例
這裡使用的加密為對稱加密，以更快地進行I-PDU的交換。通常的做法還包括利用非對稱加密的方式來傳遞對稱加密的金鑰，以此完成金鑰的定期更新。通過對Data ID、I-PDU和金鑰的對映，以及金鑰的更新和分發，可以做到一個非常完整的金鑰管理方案。
SecOC測試開發
從上面可以看出，SecOC的機制是比較複雜的，按照過往的專案經驗，需要測試驗證的內容包括新鮮度值管理、MAC認證、金鑰分發等。
為了保證ECU的執行環境，並監測ECU自身的行為，我們需要模擬其外部條件，包括同步報文、ECU接收的SecOC報文等。為了實現此模擬環境，可以使用CANoe提供的Security模組。
在CANoe的Security Configuration中，對SecOC方案的進行選擇與配置，並將其與控制器的埠形成對映。
圖10 Security Configuration配置
在ARXML中，可直接配置相關的資訊，包括Data ID、新鮮度值的長度等。通過這種方式，可以對每個I-PDU進行不同Data ID的配置從而形成I-PDU和Data ID的對映。
圖11 ARXML相關配置
在CANoe的Security Manager中，可以對Data ID進行其金鑰的寫入，實現金鑰與Data ID的對映。
圖12 Security Manager相關配置
除了使用CANoe的Security模組，還可以整合CANoe的SecOC介面函式等進行程式設計來實現模擬環境。解決了模擬環境後，需要依據所開發的測試用例實現測試指令碼。一方面驗證正向的SecOC流程，另一方面驗證SecOC機制的防“攻擊”特性。通過使用CANoe的各個內建函式及外部第三方程式設計介面，對模擬條件進行相應的輸入控制器，並監測ECU的反饋，就可以高效地完成SecOC的驗證。
圖13 SecOC測試用例展示
總結
在網路安全領域，越高的安全性要求，意味安全機制的複雜性，對系統資源消耗和效能的更高要求。那麼，需分析和確認哪些資料需要被保護、網路安全等級如何定義也尤為重要。結合應用場景，考慮資料的敏感性、實時性等要求，才能選擇合適的方案。不管是E2E更偏向資料完整性的校驗，還是SecOC中更關注身份合法性的認證，包括SSL、TLS提供的保密性，都是可供選擇的方案。
北匯資訊專注於汽車電子測試、與眾多OEM合作，在匯流排網路診斷測試開發相關領域積累了豐富的經驗。本次為大家簡單介紹了SecOC，後續將會為大家帶來更多資訊保安的相關內容。關於車內的通訊、診斷刷寫中各類網路安全相關的測試驗證方案，歡迎垂詢和溝通，共同探討。
注：文中圖片來源於AUTOSAR、Vector CANoe
參考文獻
[1] AUTOSAR_SWS_SecureOnboardCommunication
[2] AUTOSAR_SWS_CryptoServiceManager
[3] NIST Special Publication 800-38B