1.前言

我們知道，在車載網(wǎng)絡(luò)中，大部分的數(shù)據(jù)都是以明文方式廣播發(fā)送且無認(rèn)證接收。這種方案在以前有著低成本、高性能的優(yōu)勢，但是隨著當(dāng)下智能網(wǎng)聯(lián)化的進程，這種方案所帶來的安全問題越來越被大家所重視。

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

而隨著車載網(wǎng)絡(luò)技術(shù)的發(fā)展，我們有了更多的方式來實現(xiàn)網(wǎng)絡(luò)安全。之前我們曾介紹過E2E（End to End）的技術(shù)，本期我們將介紹SecOC方案。

2.SecOC簡介

SecOC全稱Secure Onboard Communication，主要用于對車內(nèi)敏感信息進行認(rèn)證。

其數(shù)據(jù)結(jié)構(gòu)如下：Authentic I-PDU是需要被保護的數(shù)據(jù)；Authenticator為認(rèn)證信息（通常使用消息認(rèn)證碼，即Message Authentication Code，簡稱MAC，后文以MAC來簡稱此內(nèi)容）；Secured I-PDU Header為可選用的報頭；Freshness Value為可選用的新鮮度值。

圖1 Secured I-PDU結(jié)構(gòu)

而在實際使用中，新鮮度值和MAC可能會使用較多長度的數(shù)據(jù)來提高安全性，但這又會消耗大量的帶寬等資源，所以常使用截取的方式做平衡處理。新鮮度值和MAC都按照完整的值來生成，但是在發(fā)送和認(rèn)證的時候只會截取一部分，如下圖所示：

圖2 Secured I-PDU的截取

以CANoe demo中的ARXML為例，其節(jié)點ECU1發(fā)送的Secured_PDU_1分別包含了8個字節(jié)的Authentic I-PDU，1個字節(jié)的新鮮度值（實際長度8字節(jié)）和3個字節(jié)的MAC（實際長度16字節(jié)）。

圖3 Secured I-PDU在ARXML中的排布示例

接下來我們就以此Demo為例，來詳細(xì)談?wù)凷ecOC中2個重要的組成部分：新鮮度值管理（Freshness Value Manager，簡稱FVM）和MAC生成。

3.新鮮度值管理

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

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

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

3）基于同步的復(fù)合counter

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

圖4新鮮度值結(jié)構(gòu)

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

圖5新鮮度值示例

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

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

圖7新鮮度值的分發(fā)示例

4.MAC生成

MAC是對受保護數(shù)據(jù)的身份認(rèn)證。其中涉及的加密算法多種多樣，每個算法還可以有多個配置。這里我們以SecOC提供的一個方案Profile 1進行說明，其使用CMAC/AES-128的算法，截取8 bit的新鮮度值和24 bit的MAC，配置信息如下所示。

圖8 Profile 1配置

除此配置外，MAC生成還需要128 bit的密鑰（這里預(yù)先定義了0x0102030405060708090A0B0C0D0E0F10）、16 bit的Data ID（這里預(yù)先定義了33）、完整的新鮮度值和需要認(rèn)證的數(shù)據(jù)。Data ID是用來標(biāo)識I-PDU的數(shù)據(jù)，可以給密鑰管理機制提供支持。以Demo中時間戳為8.300203的I-PDU進行說明，需要認(rèn)證的數(shù)據(jù)為0xE8030000000000FF，完整的新鮮度值為0x100000405，實際進行加密運算的數(shù)據(jù)為Data ID、待認(rèn)證數(shù)據(jù)和完整新鮮度值的拼接，計算后的實際MAC為0x498330e818f3fbb068759ff3b72d015f，截取24 bit后發(fā)送的MAC為0x498330。

圖9 MAC發(fā)送示例

這里使用的加密為對稱加密，以更快地進行I-PDU的交換。通常的做法還包括利用非對稱加密的方式來傳遞對稱加密的密鑰，以此完成密鑰的定期更新。通過對Data ID、I-PDU和密鑰的映射，以及密鑰的更新和分發(fā)，可以做到一個非常完整的密鑰管理方案。

5. SecOC測試開發(fā)

從上面可以看出，SecOC的機制是比較復(fù)雜的，按照過往的項目經(jīng)驗，需要測試驗證的內(nèi)容包括新鮮度值管理、MAC認(rèn)證、密鑰分發(fā)等。

為了保證ECU的運行環(huán)境，并監(jiān)測ECU自身的行為，我們需要仿真其外部條件，包括同步報文、ECU接收的SecOC報文等。為了實現(xiàn)此仿真環(huán)境，可以使用CANoe提供的Security模塊。

在CANoe的Security Configuration中，對SecOC方案的進行選擇與配置，并將其與控制器的端口形成映射。

圖10 Security Configuration配置

在ARXML中，可直接配置相關(guān)的信息，包括Data ID、新鮮度值的長度等。通過這種方式，可以對每個I-PDU進行不同Data ID的配置從而形成I-PDU和Data ID的映射。

圖11 ARXML相關(guān)配置

在CANoe的Security Manager中，可以對Data ID進行其密鑰的寫入，實現(xiàn)密鑰與Data ID的映射。

圖12 Security Manager相關(guān)配置

除了使用CANoe的Security模塊，還可以集成CANoe的SecOC接口函數(shù)等進行編程來實現(xiàn)仿真環(huán)境。解決了仿真環(huán)境后，需要依據(jù)所開發(fā)的測試用例實現(xiàn)測試腳本。一方面驗證正向的SecOC流程，另一方面驗證SecOC機制的防“攻擊”特性。通過使用CANoe的各個內(nèi)置函數(shù)及外部第三方編程接口，對仿真條件進行相應(yīng)的輸入控制器，并監(jiān)測ECU的反饋，就可以高效地完成SecOC的驗證。

圖13 SecOC測試用例展示

6.總結(jié)

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

北匯信息專注于汽車電子測試、與眾多OEM合作，在總線網(wǎng)絡(luò)診斷測試開發(fā)相關(guān)領(lǐng)域積累了豐富的經(jīng)驗。本次為大家簡單介紹了SecOC，后續(xù)將會為大家?guī)砀嘈畔踩南嚓P(guān)內(nèi)容。關(guān)于車內(nèi)的通信、診斷刷寫中各類網(wǎng)絡(luò)安全相關(guān)的測試驗證方案，歡迎垂詢和溝通，共同探討。

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

參考文獻

[1] AUTOSAR_SWS_SecureOnboardCommunication

[2] AUTOSAR_SWS_CryptoServiceManager

[3]NIST Special Publication 800-38B