汽車安全性能亟待升級 嵌入式系統(tǒng)把關(guān)護(hù)航
1 摘要
汽車安全離不開安防,例如,只有通過安防措施保護(hù)制動ECU(電子控制單元)固件的完整性和真實性,才能保證汽車的制動安全,防止惡意修改固件等威脅。
安全需要安防的另一個示例是板載網(wǎng)絡(luò),板載網(wǎng)絡(luò)將關(guān)鍵數(shù)據(jù)從傳感器傳輸?shù)街苿覧CU。只有通過安防措施防止板載網(wǎng)絡(luò)抵御修改數(shù)據(jù)、注入消息和拒絕服務(wù)等威脅,才能保證制動ECU及時收到正確的傳感器值。
人們希望在汽車中推出Android™或MeeGo™等開放的軟件平臺,從而出現(xiàn)了一個全新的安全和安防挑戰(zhàn):為了允許通過按鈕與用戶進(jìn)行交互并為導(dǎo)航應(yīng)用從汽車提取當(dāng)前車速、剩余油量、行駛里程、位置等信息,軟件平臺及其應(yīng)用程序需要參與板載汽車通信。然而,需要保護(hù)汽車不出應(yīng)用故障。虛擬化以及運(yùn)行軟件平臺(包括沙箱內(nèi)的應(yīng)用程序)是在ECU內(nèi)實現(xiàn)保護(hù)的安防措施之一。
在上述情況下,安防措施完善了安全性。然而,在一些情況下,安防需求與安全需求相互矛盾。例如,要保護(hù)固件的保密性,在組裝了ECU后便以不可逆地方式禁用微控制器的調(diào)試端口。如果由于ECU發(fā)生故障而導(dǎo)致返修,那么被禁用的調(diào)試端口會導(dǎo)致無法在微控制器內(nèi)進(jìn)行根本原因分析。特別是無法分析是否有軟件、配置或硬件缺陷。新興的功能安全標(biāo)準(zhǔn)ISO26262要求調(diào)查現(xiàn)場返修,以便檢測系統(tǒng)故障,然后啟動召回。只有借助智能安防生命周期和安全調(diào)試等方法,才能滿足安全需求并在現(xiàn)場返修時分析根本原因。
本文介紹了先進(jìn)的微控制器的主要安全特性,以及如何應(yīng)用這些特性確保汽車安全:具體而言,本文涵蓋了安全啟動、組件保護(hù)和虛擬化。此外,本文也概述了對保證安全和處理現(xiàn)場返修的解決方案。
2 簡介
在過去的幾年里,汽車微控制器(MCU)的安全特性變得越來越重要。這種趨勢受到傳統(tǒng)的安全使用案例的推動,例如防盜裝置或組件保護(hù),可防止汽車被盜。然而,車對車通信等新的使用案例及更高的安全性要求也增加了安全需求。對于這些用例,汽車行業(yè)開始制定安全硬件擴(kuò)展(SHE)功能規(guī)范等規(guī)范,或EVITA項目提出的安全架構(gòu)。
半導(dǎo)體公司開始在新一代微控制器中實施這些規(guī)范。這項工作的第一批成果之一便是Qorriva MPC564xB/C系列,該系列實現(xiàn)了一個易于使用的安全模塊,以滿足SHE規(guī)范要求。
i.MX系列等汽車處理器植根于消費電子市場,現(xiàn)在已經(jīng)打入汽車市場,以實現(xiàn)最先進(jìn)的駕駛員信息娛樂系統(tǒng)。這些處理器提供硬件安全,支持復(fù)雜的數(shù)字版權(quán)管理系統(tǒng)。
3 Qorivva MPC564xC/B系列
QorivvaMPC564xC/B系列32位微控制器面向安全的、新一代高端汽車車身控制模塊(BCM)和網(wǎng)關(guān)應(yīng)用。它提供高度集成,可以滿足OEM和一級客戶對增強(qiáng)功能集和增加內(nèi)存空間的日益增長的需求。
從安全性角度來看,MPC564xC/B包含一個加密服務(wù)引擎(CSE)。CSE是一組加密硬件特性,允許在ECU之間安全、可信任地傳輸信息。
MPC564xC/B系列還具有雙Power Architecture®內(nèi)核選項,提供近300DMIP的處理功能和低功耗待機(jī)/等待模式,幫助降低功耗,還具有廣泛的通信外設(shè)集,面向與BCM/網(wǎng)關(guān)模塊對接的廣泛的子系統(tǒng)。此外,這些可擴(kuò)展器件都由使能生態(tài)系統(tǒng)支持,該生態(tài)系統(tǒng)包括軟件驅(qū)動程序、操作系統(tǒng)和配置代碼,以幫助您快速部署您的設(shè)計。圖1展示了Qorivva MPC564xC/B框圖。
圖1:Qorriva MPC564xC/B框圖
3.1 加密服務(wù)引擎(CSE)的安全特性
加密服務(wù)引擎(CSE)是集成在Qorriva MPC5464中的加密硬件模塊。CSE模塊實現(xiàn)安全硬件擴(kuò)展(SHE)功能規(guī)范中描述的安全功能。圖2展示了CSE模塊的框圖。
圖2:CSE框圖
CSE的設(shè)計包括一個帶有一組內(nèi)存映射寄存器的主機(jī)接口,這些寄存器被CPU用于發(fā)起加密命令。此外,還有一個系統(tǒng)總線接口允許CSE直接訪問系統(tǒng)內(nèi)存。在這里,CSE模塊的行為與任意其他主機(jī)相似。通過主機(jī)接口,應(yīng)用程序可以配置和控制CSE,例如使CSE進(jìn)入低功耗模式,中斷完成的命令處理或暫停命令處理。狀態(tài)和錯誤寄存器將提供深入的系統(tǒng)信息。如需完整的CSE命令列表,請參考MPC564xC/B參考手冊[3]。兩個專用系統(tǒng)閃存塊被CSE用于加密密鑰存儲。其他主機(jī)無法從系統(tǒng)訪問這些模塊,因此這些模塊被稱為安全閃存。
CSE模塊的AES塊作為從機(jī)連接到CSE模塊的內(nèi)部總線。它處理加密/解密,并提供基于密文的消息認(rèn)證碼(CMAC)。CMAC功能用于實現(xiàn)安全啟動機(jī)制。
隨機(jī)數(shù)生成器包括一個偽隨機(jī)數(shù)生成器(PRNG)。PRNG的種子由真隨機(jī)數(shù)發(fā)生器(TRNG)生成。
CSE控制通過測試接口從外部訪問安全閃存,在生產(chǎn)過程中使用該功能,也用于現(xiàn)場返修驗證。當(dāng)Qorriva MPC564xC/B半導(dǎo)體從飛思卡爾工廠出廠時,測試接口是打開的,當(dāng)加密密鑰被編程到器件中后該接口將關(guān)閉。
質(zhì)量工程師可以使用SHE規(guī)范中描述的CMD_DEBUG函數(shù)重新打開測試接口。CMD_DEBUG函數(shù)將刪除安全存儲器中的所有數(shù)據(jù),然后才會授權(quán)訪問測試接口。CMD_DEBUG函數(shù)的一個輸入?yún)?shù)為MASTER_KEY,這是一個單獨的預(yù)編程128位值,對于各個器件都不同。只有MASTER_KEY的知識載體才能成功地啟動CMD_DEBUG函數(shù)。
在附著了調(diào)試器后,可以單獨禁用加密密鑰。禁用密鑰意味著CSE可用該密鑰拒絕任何加密功能。
3.2 CSE支持的一些用例
CSE有助于實現(xiàn)下列用例或系統(tǒng):
•防盜裝置
•組件保護(hù)
•安全閃存編程
•數(shù)據(jù)集保護(hù)(例如行駛里程)
•防止芯片調(diào)節(jié)
目前還有許多用例,將來會出現(xiàn)更多。以下段落詳細(xì)描述了兩個重要的使用案例。
3.2.1 安全啟動和信任鏈
當(dāng)MPC564xC/B重置后,CSE將在公共閃存中自動驗證陣列。該陣列的基地址和長度由開發(fā)人員指定。同一個地址條目被用作主內(nèi)核的第一個指令地址。
CSE在該陣列外計算CMAC值,并將其與存儲在安全內(nèi)存中的預(yù)先計算的值進(jìn)行比較。根據(jù)比較結(jié)果,CSE將提供加密服務(wù)或不提供。由于系統(tǒng)閃存較大-MPC564xC/B提供高達(dá)3MB的閃存-因此安全啟動過程可能需要一些時間。由于這個原因,開發(fā)人員可以設(shè)置一個信任鏈。在這種情況下,閃存驗證步驟被分為幾個子步驟。第一個閃存塊由CSE驗證,如前所述;對以下閃存塊的驗證必須由主內(nèi)核通過已經(jīng)過驗證的程序代碼觸發(fā)。
3.2.2 組件保護(hù)
組件保護(hù)功能防止從汽車拆除單個ECU,并在其他汽車中重復(fù)使用。通常盜取汽車的目的是為了將單個ECU重新銷售到零件市場。
OEM現(xiàn)在可以用一個安全組件保護(hù)系統(tǒng)解決幾個問題。首先,汽車制造商可以減少被盜汽車的數(shù)量;其次,他們可以防止對信譽(yù)和配置產(chǎn)生負(fù)面影響;第三,他們可以保護(hù)自己的售后業(yè)務(wù)。
基于CSE的組件保護(hù)系統(tǒng)似乎能夠達(dá)到上述目的。最有價值的ECU將包含一個帶有CSE模塊的微控制器??梢酝ㄟ^設(shè)計分配一個或多個主ECU,也可以使用特定算法進(jìn)行動態(tài)分配。主ECU將輪詢組件保護(hù)系統(tǒng)的所有其他ECU,并要求一個特定答案(例如加密的唯一ID)。在這種情況下,只有帶有正確的保密密鑰的ECU才能發(fā)回一個有效的響應(yīng)。此外,主ECU可以使用特定汽車內(nèi)組裝的所有ECU數(shù)據(jù)庫交叉校驗收到的ID。
在使用汽車時可定期進(jìn)行組件檢查。如果主節(jié)點在汽車網(wǎng)絡(luò)中檢測到未經(jīng)授權(quán)的ECU,它能夠作出反應(yīng)。