疫情當下,各種消息滿天飛,不如一起在家看SecOC!!!

通訊加密的必要性

隨著汽車電子的發(fā)展及整車功能復雜性的提高,車載控制器數(shù)量從之前的寥寥幾個增加至規(guī)模復雜的上百個。基于功能的需求,各個控制器每時每刻需要進行大量數(shù)據(jù)的交互,數(shù)據(jù)交互的方式也多種多樣,比如Lin、CAN、CANFD、FlexRay 、車載Ethernet等。

其中成本低、可靠性高、應用普遍的有Lin、CAN通訊,而FlexRay、車載Ethernet等基于成本因素,目前主要在高端車型中使用(FlexRay后續(xù)得到普遍應用的可能性較小,樓主主要認為其比較尷尬,首先成本方面接近車載以太網(wǎng)而通訊速率又遠低于它,而伴隨著未來智能化、網(wǎng)聯(lián)化的趨勢,車載Ethernet在未來得到推廣的可能性要比FlexRay高很多)。

但在目前的車載網(wǎng)絡中,大部分數(shù)據(jù)傳輸都是在沒任何安全措施的情況下進行的,即使有安全措施也大都非常簡陋。因此在絕大多數(shù)情況下,控制器基本以原始數(shù)據(jù)的形式進行數(shù)據(jù)交互。即使接收節(jié)點能對數(shù)據(jù)進行合理性檢查,這些措施對數(shù)據(jù)可靠性的提升也是有限的。接收節(jié)點無法驗證數(shù)據(jù)來自于期望的發(fā)送節(jié)點還是其他節(jié)點,即無法驗證數(shù)據(jù)是否真實。同時,總線上傳輸?shù)臄?shù)據(jù)也是可以自由訪問的,因此可以通過分析總線上傳輸?shù)脑�始�?shù)據(jù)來反推得到其表示的內(nèi)容,這樣的數(shù)據(jù)傳輸既不進行保密也不進行認證。例如應用最廣的CAN通訊設計之初是沒有考慮過信息安全問題的。其明文傳輸、報文廣播傳輸、極少網(wǎng)絡分段等特性,讓進入整車網(wǎng)絡的黑客如同進了游樂場,輕松便可以偽造報文對車輛進行控制。

為了給CAN通訊增加一定的安全性,攻城獅們在CAN報文的負載中做文章,即在報文中增加RollingCounter和Checksum進行報文丟幀和數(shù)據(jù)準確性的檢驗,RollingCounter就不說了,我個人感覺就是心理安慰罷了,報文計數(shù)符合一定的累加原則就可以仿造,而Checksum的計算方法大部分OEM定義的也比較簡單,很容易被破解從而對總線的數(shù)據(jù)進行篡改,一旦能夠直接訪問車輛的總線,任何人都可以讀取總線上傳輸?shù)脑�始�?shù)據(jù),甚至可以截獲這些數(shù)據(jù)并且修改后重新發(fā)送到總線系統(tǒng)中,這毫無疑問會影響整車的功能和安全性;另一方面,一個標準CAN報文的數(shù)據(jù)部分最多有8個字節(jié),本身需要承載很多車輛運行的功能數(shù)據(jù),從中拿出任何Bit用于承載RollingCounter和Checksum都會對總線的繁忙程度產(chǎn)生負面影響,因此OEM盡量使用少的Bit位來承載RollingCounter和Checksum,這也讓黑客較容易就可逆向出算法。

所以,加密通信(Cyber Security或Security Onboard Communication)近年來受到了越來越多的關注,因最近幾年也發(fā)生了很多對車載網(wǎng)絡的惡意攻擊事件。為了響應汽車行業(yè)對數(shù)據(jù)加密和驗證的需求,AUTOSAR組織補充了全稱為Secure Onboard Communication(SecOC)的組件,為車載通訊總線引入了一套通信加密和驗證的標準,可以說SecOC是目前為止車載網(wǎng)絡上一種有效的信息安全方案。

SecOC介紹

SecOC是在AUTOSAR軟件包中添加的信息安全組件(組件位置及可應用的通訊方式如下圖所示),該Feature增加了加解密運算、秘鑰管理、新鮮值管理和分發(fā)等一系列的功能和新要求。SecOC模塊在PDU級別上為關鍵數(shù)據(jù)提供有效可行的身份驗證機制。認證機制與當前的AUTOSAR通信系統(tǒng)無縫集成,同時對資源消耗的影響應盡可能小,以便可為舊系統(tǒng)提供附加保護。該規(guī)范主要使用帶有消息認證碼(MAC)的對稱認證方法。與不對稱方法相比,它們使用更小的密鑰實現(xiàn)了相同級別的安全性,并且可以在軟件和硬件中緊湊高效地實現(xiàn)。但是,規(guī)范提供了兩種方法必要的抽象級別,因此對稱和非對稱身份驗證方法都可使用。

1．對稱加密算法

     對稱加密算法的加密和解密使用的密匙是相同的,也就是說如果通訊兩方如果使用對稱加密算法來加密通訊數(shù)據(jù),那么通訊雙方就需要都知道這個密匙,收到通訊數(shù)據(jù)后用這個密匙來解密數(shù)據(jù)。

2．非對稱加密算法

     非對稱算法中用到的密匙有兩個,分別是公匙和私匙,要求通訊雙方都有自己的公匙和私匙,自己公匙加密的數(shù)據(jù)只有自己的私匙才能解開,自己私匙加密的數(shù)據(jù)也只有自己的公匙才能解開。公匙是可以公布在網(wǎng)絡上的,相當于一個公共的電話簿,可以被其他人獲取到的。

以一個通信的例子來說明非對稱算法:

     A 要和 B 進行通信,A在網(wǎng)絡上獲取到B的公匙,然后把數(shù)據(jù)用B的公匙進行加密發(fā)送給B,B收到了數(shù)據(jù)后就用自己的私匙進行解密數(shù)據(jù),然后就可以看到數(shù)據(jù)內(nèi)容了,即使在網(wǎng)絡傳輸中加密數(shù)據(jù)被黑客截取,由于黑客沒有對應的私匙,他也無法解密數(shù)據(jù)進行查看。

     在通信中對稱加密算法比較高效,但是需要告知對方加密鑰匙,在實際運用時比較麻煩,所以一般都是用非對稱加密算法來加密對稱加密算法的鑰匙,然后發(fā)送給對方,對方收到對稱加密算法的鑰匙后,后續(xù)通信就用對稱加密算法來加密消息內(nèi)容了

若控制器之間實現(xiàn)SecOC功能,則需要發(fā)送和接收控制器都集成并實現(xiàn)SecOC模塊。在AUTOSAR中,需要加密保護的數(shù)據(jù)信息被稱為Authentic I-PDU。SecOC模塊基于Authentic I-PDU和密鑰使用一定的加密算法得到Authenticator(例如 MAC)。Authenticator和Authentic I-PDU再加上一些必要的報頭即得到Secured I-PDU,Secured I-PDU也可選包含新鮮度值Freshness  Value,Secured I-PDU的結構如下圖所示:

其中MAC和新鮮度分別具有不同的作用,在SecOC標準中,AUTOSAR主要基于兩種手段來實現(xiàn)數(shù)據(jù)的真實性和完整性的校驗:基于MAC的身份驗證和基于Freshness的防重放攻擊。首先MAC(Message Authentication Code)是保障信息完整性和認證的密碼學方法之一,其中CMAC(Cipher–based Message Authentication Code,CMAC一般用于對稱加密,整車廠可在車輛下線刷寫程序時靜態(tài)分配密鑰,也可選擇使用云端服務器動態(tài)地給車輛分配密鑰。)是車載總線加密認證常用方案。MAC的作用不是防止有效數(shù)據(jù)被泄露,而是為了保護數(shù)據(jù)不會被攻擊方篡改,即完成數(shù)據(jù)來源的認證。如需保護通信數(shù)據(jù)不被攻擊方監(jiān)聽,則報文的有效數(shù)據(jù)還需要進行額外的加密。

為了降低重復攻擊的風險,則需要在Secured I-PDU中加入新鮮度值,Freshness Value是一個根據(jù)一定邏輯不斷更新的數(shù)值,Freshness Value的更新方法多種多樣,AUTOSAR 標準將計數(shù)器或基于時間的新鮮度值作為典型選項。具體使用何種和具體的加密方式,以及如何定義新鮮度度其實并不在標準之內(nèi),這就給OEM有了各自定制化方案的可選余地,因此OEM 在實施 SecOC 方案時需要定義和做好兩個關鍵部分:新鮮度值管理和密鑰管理。

基于SecOC的通訊加密和認證過程如下所示:

在發(fā)送節(jié)點,SecOC模塊向待發(fā)送的Authentic I-PDU添加認證信息從而創(chuàng)建Secured I-PDU。認證信息包括Authenticator(例如CMAC)和可選的Freshness Value。無論Freshness Value是否包含在打包后的Secured I-PDU中,在生成Authenticator期間都會考慮Freshness Value。

在接收節(jié)點,SecOC模塊通過驗證收到的Secured I-PDU中包含的Authenticator來判斷Authentic I-PDU的來源。為了實現(xiàn)認證,接收節(jié)點除了需要Authentic I-PDU外還需要知道發(fā)送節(jié)點計算Authenticator時使用的Freshness Value。

總結

車載通訊加密除了AUTOSAR推薦的方案,也有很多私有的定制化方案,其目的都是保證整車通訊的安全性,這在未來的汽車電子發(fā)展中是非常重要的一方面,但是實施SecOC后,其會大量占用CAN報文負載,對于只有可憐巴巴的8字節(jié)傳統(tǒng)CAN通訊來說可能無福消受了,因認證信息的強度和信息長度強相關。在傳統(tǒng)CAN上應用不僅導致總線負載率提升、通信實時性下降,甚至可能影響正常功能,最終既得不到預想的信息安全強度,又犧牲了相當大的CAN通信能力,因此SecOC更適合配合CANFD協(xié)議使用。

參考文獻:

1、Autosar 、Vector、EB、CSDN等資料)