1.前言

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

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

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

2.SecOC簡(jiǎn)介

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

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

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

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

圖2 Secured I-PDU的截取

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

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

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

3.新鮮度值管理

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

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

2）基于全局時(shí)間戳，源于時(shí)間戳的唯一性

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

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

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

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

圖5新鮮度值示例

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

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

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

4.MAC生成

MAC是對(duì)受保護(hù)數(shù)據(jù)的身份認(rèn)證。其中涉及的加密算法多種多樣，每個(gè)算法還可以有多個(gè)配置。這里我們以SecOC提供的一個(gè)方案Profile 1進(jìn)行說(shuō)明，其使用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是用來(lái)標(biāo)識(shí)I-PDU的數(shù)據(jù)，可以給密鑰管理機(jī)制提供支持。以Demo中時(shí)間戳為8.300203的I-PDU進(jìn)行說(shuō)明，需要認(rèn)證的數(shù)據(jù)為0xE8030000000000FF，完整的新鮮度值為0x100000405，實(shí)際進(jìn)行加密運(yùn)算的數(shù)據(jù)為Data ID、待認(rèn)證數(shù)據(jù)和完整新鮮度值的拼接，計(jì)算后的實(shí)際MAC為0x498330e818f3fbb068759ff3b72d015f，截取24 bit后發(fā)送的MAC為0x498330。

圖9 MAC發(fā)送示例

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

5. SecOC測(cè)試開(kāi)發(fā)

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

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

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

圖10 Security Configuration配置

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

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

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

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

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

圖13 SecOC測(cè)試用例展示

6.總結(jié)

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

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

注：文中圖片來(lái)源于AUTOSAR、Vector CANoe

參考文獻(xiàn)

[1] AUTOSAR_SWS_SecureOnboardCommunication

[2] AUTOSAR_SWS_CryptoServiceManager

[3]NIST Special Publication 800-38B