網絡安全：關于SecOC及測試開發實踐簡介

1.前言

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

為了提高車載通信的安全性，各OEM已經采用針對敏感數據增加諸如RollingCounter和Checksum的信息，但其能實現的安全性十分有限。

而隨著車載網絡技術的發展，我們有了更多的方式來實現網絡安全。之前我們曾介紹過E2E（End to End）的技術，本期我們將介紹SecOC方案。

2.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生成。

3.新鮮度值管理

在SecOC中，給出了多種新鮮度值管理方案：

1）基于counter的遞增，即包含了原有方案的機制

2）基于全局時間戳，源于時間戳的唯一性

3）基于同步的復合counter

這里我們主要談一下第三種方案。在此方案中，完整的新鮮度值包括同步計數器（Trip Counter）、重置計數器（Reset Counter）、重置標志值（Reset Flag）和消息計數器（Message Counter）。其中消息計數器又分為高值和低值，而真正在報文中發送的值只包含消息計數器的低值和重置標志值。

圖4新鮮度值結構

新鮮度值的更新如下所示，完整的新鮮度值為0x10000040F，實際發送的新鮮度值為0xF。而由于重置標志值為1 bit，消息計數器雖然以步長1遞增，實際發送到總線上的新鮮度值則是以2的步長遞增。

圖5新鮮度值示例

從上述內容可以看出，新鮮度值存在2個重要的基準：同步計數器和重置計數器，這2個計數器需要接收方和發送方保持一致。SecOC在新鮮度值管理上提出了主從模式的框架，由主節點向接收方和發送方分發同步計數器和重置計數器，從而達到同步的目的。

圖6主從模式的新鮮度值管理

圖7新鮮度值的分發示例

4.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和密鑰的映射，以及密鑰的更新和分發，可以做到一個非常完整的密鑰管理方案。

5. 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測試用例展示

6.總結

在網絡安全領域，越高的安全性要求，意味安全機制的復雜性，對系統資源消耗和性能的更高要求。那么，需分析和確認哪些數據需要被保護、網絡安全等級如何定義也尤為重要。結合應用場景，考慮數據的敏感性、實時性等要求，才能選擇合適的方案。不管是E2E更偏向數據完整性的校驗，還是SecOC中更關注身份合法性的認證，包括SSL、TLS提供的保密性，都是可供選擇的方案。

北匯信息專注于汽車電子測試、與眾多OEM合作，在總線網絡診斷測試開發相關領域積累了豐富的經驗。本次為大家簡單介紹了SecOC，后續將會為大家帶來更多信息安全的相關內容。關于車內的通信、診斷刷寫中各類網絡安全相關的測試驗證方案，歡迎垂詢和溝通，共同探討。

注：文中圖片來源于AUTOSAR、Vector CANoe

參考文獻

[1] AUTOSAR_SWS_SecureOnboardCommunication

[2] AUTOSAR_SWS_CryptoServiceManager

[3]NIST Special Publication 800-38B