網路安全:關於SecOC及測試開發實踐簡介

北匯資訊發表於2021-12-16

前言

 


我們知道,在車載網路中,大部分的資料都是以明文方式廣播傳送且無認證接收。這種方案在以前有著低成本、高效能的優勢,但是隨著當下智慧網聯化的程式,這種方案所帶來的安全問題越來越被大家所重視。


為了提高車載通訊的安全性,各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