摘要 ? ?

在汽車行業(yè)，網(wǎng)絡(luò)安全的實施程度很低。一輛汽車有多個電子控制單元（ECU），每個ECU通過控制區(qū)網(wǎng)絡(luò)（CAN）與另一個ECU進行大量的信息交流。如果黑客入侵系統(tǒng)，那么它就像一個開放的資源來源，任何有價值的信息都可以被操縱。這可能會導(dǎo)致巨大的損失。這是一個驗證各種現(xiàn)有網(wǎng)絡(luò)安全功能的動機，了解系統(tǒng)，然后實施網(wǎng)絡(luò)安全功能。

本文討論了密鑰槽驗證設(shè)計、最大權(quán)威計數(shù)器驗證設(shè)計和用戶模式實現(xiàn)。汽車工業(yè)的發(fā)展采用了汽車開放系統(tǒng)架構(gòu)（AUTOSAR）平臺。

I.簡介

近年來，正如人們所看到的，機械系統(tǒng)正在被電子元件所取代?，F(xiàn)在，汽車不再是一個機械裝置和一個電子設(shè)備，連接性使它成為一個物聯(lián)網(wǎng)（IOT）設(shè)備。在汽車行業(yè)，一輛汽車有許多電子控制單元（ECU）。這些ECU已被編程以執(zhí)行許多功能。

早期的網(wǎng)絡(luò)安全問題只是用計算機進行各種攻擊的黑客。如今，有許多網(wǎng)絡(luò)安全功能在非計算機上實現(xiàn)，例如，家用電器、交通、公用事業(yè)以及各行業(yè)。隨著每個設(shè)備都在向自動化和物聯(lián)網(wǎng)方向發(fā)展，許多工廠和行業(yè)都在發(fā)展。隨著連接性的增加，物聯(lián)網(wǎng)概念在汽車行業(yè)得到了廣泛的應(yīng)用。

這種連接性的增加也增加了網(wǎng)絡(luò)風(fēng)險，這是一個嚴(yán)重的問題，也是一個社會問題。ECU被編程了許多功能，這些功能被用于汽車中，如駕駛輔助、安全氣囊和許多其他應(yīng)用。這些ECU通過控制區(qū)網(wǎng)絡(luò)（CAN）相互連接，這是廣泛用于車輛的通信協(xié)議。在CAN總線上有許多信息傳輸，而某些信息與安全有非常重要的關(guān)系。如果這些安全信號在CAN總線上被操縱，對車輛的影響是危險的，車輛沒有安全保障將導(dǎo)致巨大的風(fēng)險。

II.理論和方法

A.安全通信

發(fā)射器ECU和接收器ECU通過CAN總線連接。發(fā)射器有硬件安全模塊（HSM），它能夠計算出信息驗證碼（MAC）。HSM計算MAC的輸入是時間戳和信息或有效載荷。MAC被生成并與信息和時間戳一起發(fā)送給接收方ECU。接收器也與HSM相關(guān)聯(lián)，它有能力驗證發(fā)射器通過CAN總線發(fā)送的MAC。一旦MAC被HSM驗證，信息就被接收器接受。

在這種情況下，時間戳顯示為7'O clock，如圖1所示。有一個黑客ECU監(jiān)視著總線，并有意在總線上捕獲信息。當(dāng)黑客ECU捕獲信息時，很明顯，MAC和時間戳7'O時鐘也從總線上被捕獲?，F(xiàn)在，黑客ECU以不同的時間戳發(fā)送相同的信息。圖1中的不同時間戳是9'O時鐘。

在9點鐘，黑客ECU通過CAN總線向接收器發(fā)送相同的信息。當(dāng)接收方在驗證MAC時，時間戳不匹配。接收者沒有關(guān)于不同時間戳的信息。因此，該信息被拒絕。



圖1. 信息認(rèn)證

現(xiàn)在，可能有這樣的情況：發(fā)射器和接收器之間有時間延遲，信息連同MAC和時間戳到達接收器時有一些延遲。這不會有任何問題，因為時間戳只不過是一個計數(shù)器而已。計算MAC的計數(shù)值和接收方關(guān)于該計數(shù)值的信息將保持不變。接收方的計數(shù)器值不會遞增。因此，即使總線上有一定的延遲，MAC也會被接收器驗證。

B.基于密碼的信息驗證碼

基于密碼的信息驗證碼（CMAC）是一種用于MAC生成和驗證的算法。這種算法在ECU的硬件安全模塊（HSM）中進行。如圖2所示，CMAC算法與發(fā)射器的對應(yīng)密鑰槽相耦合。有效載荷或信息和防重放計數(shù)器被作為輸入給CMAC算法以生成MAC。

這是與安全信息相關(guān)的計數(shù)器。因此，CMAC算法的輸入是有效載荷和防重放計數(shù)器。每一個安全發(fā)射器信息都與一個密鑰槽相關(guān)。



圖2. CMAC生成鑰匙槽也被稱為密鑰ID。密鑰ID是提供鑰匙的槽位。在提供的鑰匙槽中提供鑰匙，然后設(shè)置MAC標(biāo)志。有一些內(nèi)部值被設(shè)置為MAC Only ?ag。該標(biāo)志用于生成MAC。這些生成的密鑰與CMAC算法相連，該算法將生成以有效載荷和防重放計數(shù)器為輸入的MAC。

用于MAC驗證的值是不同的，該標(biāo)志值只能驗證MAC。與安全發(fā)射器信息相比，安全接收者信息被賦予不同的密鑰ID?！癕AC驗證”的值在提供密鑰后設(shè)置。MAC驗證標(biāo)志有一個設(shè)置好的內(nèi)部值。這個過程將生成MAC驗證的密鑰。因此，這些密鑰被耦合到CMAC層，用于MAC生成或MAC驗證。

C.用戶模式和管理模式

兩種特權(quán)模式的操作是管理模式和用戶模式。監(jiān)督員模式將可以訪問所有的資源控制操作。它就像一個管理員，擁有所有內(nèi)存位置的讀、寫和可執(zhí)行權(quán)限。 所有的任務(wù)都在一個單一的平臺上運行，除了管理員，沒有人可以改變?nèi)魏稳蝿?wù)、任何代碼或任何配置。這使得該系統(tǒng)非常僵硬。

在汽車工業(yè)中，汽車中的電子設(shè)備之一是ECU。這個ECU只在監(jiān)督員模式下運行。寄存器和內(nèi)存位置只能在監(jiān)督員模式下訪問。所有的應(yīng)用程序都在監(jiān)督員模式下運行。 當(dāng)處理器在用戶模式下運行時，它對系統(tǒng)的訪問將受到限制。如果實施了用戶模式，那么在這種模式下，用戶將有對資源控制操作有限的訪問權(quán)，某些內(nèi)存位置將有有限的權(quán)限。要了解從管理模式切換到用戶模式，并檢索到管理模式。

了解機器狀態(tài)寄存器（MSR）是很重要的。這個MSR決定了處理器的狀態(tài)。MSR是一個32位的寄存器。MSR中的問題狀態(tài)寄存器（PR）位表示處理器是處于用戶模式還是監(jiān)督模式。如果PR位=0，處理器處于管理模式。如果PR位=1，處理器在用戶模式下運行。

ECU在監(jiān)督員模式下運行。其中一個功能將被定義為在用戶模式下運行。因此，代碼是在該功能中開發(fā)的，以便ECU在用戶模式下運行該特定功能。當(dāng)代碼正在執(zhí)行時，MSR的PR位被設(shè)置為1，而不會干擾MSR中的任何其他位。將PR位改為1后，ECU現(xiàn)在在用戶模式下運行。

如果ECU必須切換回管理模式，則必須執(zhí)行系統(tǒng)調(diào)用或中斷，以將MSR寄存器的PR位更改為零。



圖3. 用戶模式概念

MSR將其值存儲在特殊用途寄存器（SPR）中，同時執(zhí)行系統(tǒng)調(diào)用。SPR的作用是將MSR值的PR位位置改為1。當(dāng)MSR從SPR中檢索到它的值時。對它的指示，是保持在管理模式，因為MSR的PR位將是1。這個概念證明了可以從管理模式切換到用戶模式，反之亦然。通過使用這個概念，用戶和管理模式可以在ECU中成功實現(xiàn)。

III.設(shè)計

本節(jié)將解釋網(wǎng)絡(luò)安全三個功能的設(shè)計，前兩個設(shè)計將證明現(xiàn)有的代碼運行良好。第三個設(shè)計是ECU中用戶模式的實現(xiàn)。

A.鑰匙槽驗證

驗證任何一個ECU都不得使用安全外圍設(shè)備內(nèi)的同一密鑰槽來生成和驗證MAC。ECU已被校準(zhǔn)以生成有效的非零MAC。已使用不同的密鑰來生成和驗證MAC。

行動

觸發(fā)ECU發(fā)送安全信息。選擇由ECU在總線上發(fā)送的安全發(fā)射器信息，并形成必要的數(shù)據(jù)發(fā)送到MAC生成接口操縱應(yīng)用程序代碼，將密鑰槽號為4的數(shù)據(jù)發(fā)送至MAC 生成與接收方信息密鑰槽號相對應(yīng)的密鑰槽接口。密鑰槽驗證的設(shè)計如圖4所示。



圖4. 密鑰槽驗證設(shè)計

設(shè)計顯示，密鑰槽號11、12、13、14、15是接收信息的密鑰槽號，這些密鑰槽被強制放在密鑰槽號4上，一次一個。MAC生成的密鑰閃光，這些密鑰與密鑰槽11、12、13、14、15相關(guān)。這些鑰匙應(yīng)該被生成。這個動作將觸發(fā)錯誤。這個錯誤就是無效的鑰匙。

所有的鑰匙槽都經(jīng)過驗證，每次使用不同的接收器鑰匙槽時，應(yīng)用程序代碼都會提供相同的錯誤。

B.最具權(quán)威性的反核查

確保ECU在權(quán)威性計數(shù)器達到最大值時設(shè)置一個DTC，并發(fā)送零MAC。

行動

觸發(fā)ECU來發(fā)送安全信息。驗證ECU正在發(fā)送它所支持的所有發(fā)送器信息。選擇一個安全的發(fā)送器信息，并操作應(yīng)用程序代碼，將相應(yīng)的權(quán)威計數(shù)器設(shè)置為其最大值。



圖5. 最具權(quán)威性計數(shù)器驗證設(shè)計圖

權(quán)威的計數(shù)器是與安全發(fā)射器信息相關(guān)的內(nèi)部計數(shù)器。如果該計數(shù)器達到其最大值，那么應(yīng)用代碼應(yīng)該設(shè)置診斷故障代碼（DTC）。還可以觀察到，選定的安全發(fā)射器信息中的MAC值應(yīng)該是零。

當(dāng)代碼中出現(xiàn)錯誤時，DTC就是設(shè)定的。DTC可以被設(shè)置為各種錯誤，通過這個應(yīng)用層提示某些內(nèi)容沒有按照預(yù)期工作。

IV.用戶模式驗證

最初，ECU將在管理模式下執(zhí)行功能。在管理模式的功能結(jié)束時，會引入一個鏈?zhǔn)饺蝿?wù)，并將一個用戶模式定義的功能作為參數(shù)給出。這些函數(shù)不能在用戶模式下訪問寄存器，因為它們是不被信任的函數(shù)，所以引入了包裝器，如圖6所示，它顯示了用戶模式的實現(xiàn)設(shè)計。

這些是映射到可信函數(shù)的不信任函數(shù)，以調(diào)用原始函數(shù)，在用戶模式下執(zhí)行。當(dāng)包裝器在函數(shù)中被調(diào)用時。它應(yīng)該在實時操作系統(tǒng)（RTOS）中進行配置，這些函數(shù)被配置為可信函數(shù)。

這樣就可以訪問寄存器和函數(shù)，在用戶模式下執(zhí)行?，F(xiàn)在，為了將運行在用戶模式下的ECU切換到管理模式，在用戶模式函數(shù)的末端調(diào)用一個鏈?zhǔn)饺蝿?wù)，傳遞給它的參數(shù)是管理模式函數(shù)。



圖6. 用戶模式的實現(xiàn)設(shè)計

因此，ECU將以管理模式運行。在函數(shù)執(zhí)行結(jié)束時，會調(diào)用一個終止鏈任務(wù)，該任務(wù)將終止該進程。

V.結(jié)果

所有三種設(shè)計的結(jié)果都顯示在本節(jié)中。

A.密鑰槽位驗證結(jié)果

CAN總線通常在傳輸所有的發(fā)射器和接收器信息，如ECU所規(guī)定的。這些信息將包含分配給每個信息的原始密鑰槽。選定的安全發(fā)射器信息包含密鑰槽ID為4，這是最初分配的密鑰ID。不會有任何錯誤。該測試案例也沒有啟用。



圖7. 密鑰槽驗證的結(jié)果 現(xiàn)在，測試案例被啟用，接收器的鑰匙槽ID，一次一個被強制送到特定選擇的發(fā)射器信息的應(yīng)用代碼中。

在圖7中，接收器的鑰匙槽號11、12、13、14、15是強制的。在提供鑰匙后，應(yīng)用程序代碼會出現(xiàn)錯誤。出現(xiàn)的錯誤是INVALID KEY。在這種情況下，發(fā)射器信息2被迫接受改變了的鑰匙槽11、12、13、14、15。所有的接收器鑰匙槽ID都給出了同樣的錯誤，因此，這將證明，當(dāng)接收器鑰匙槽被強制取代發(fā)射器鑰匙槽時，沒有一個ECU能夠發(fā)揮作用。

B.最具權(quán)威性的計數(shù)器結(jié)果

發(fā)射器指數(shù)2的選擇是為了使權(quán)威的計數(shù)器達到最大。這將導(dǎo)致為安全發(fā)送器信息2設(shè)置DTC，并且傳輸?shù)腗AC值也為零。這在圖8中顯示。



圖8. 最大權(quán)威性計數(shù)器的驗證結(jié)果 結(jié)果證明，測試案例是經(jīng)過驗證成功的。DTC也被設(shè)置，并且該特定信息的MAC值為零。其他信息通常會執(zhí)行一個有效的MAC。

C.用戶模式的結(jié)果

圖9顯示了管理模式的結(jié)果。決定ECU狀態(tài)的寄存器是MSR。在圖9中，MSR的值是00009000。這表明第17位是0，也就是確定監(jiān)督員模式的PR位。



圖9. 管理模式的結(jié)果 如圖10所示，MSR寄存器的值是00029000。 這清楚地表明，MSR的PR位等于1，這代表處理器運行在用戶模式下。?



圖10. 管理模式的結(jié)果

所有其他的位子都沒有受到影響，ECU有能力在用戶和監(jiān)管理模式下切換和執(zhí)行功能。它甚至能夠訪問所需的特權(quán)寄存器和內(nèi)存位置。

VI.總結(jié)

由于攻擊率高，網(wǎng)絡(luò)安全只出現(xiàn)在計算機中。現(xiàn)在，車輛通信中的網(wǎng)絡(luò)安全已經(jīng)成為汽車行業(yè)不可或缺的一部分。沒有鑰匙，就沒有安全。因此，鑰匙在有關(guān)安全的HSM中起著重要作用。

目前只討論、設(shè)計和實現(xiàn)了三個功能，但汽車行業(yè)的網(wǎng)絡(luò)安全是一項巨大的研究課題。實現(xiàn)了許多功能，每一個功能都需要對AUTOSAR、CAN通信和許多其他功能的平臺有深入的了解。一旦理解了這些特性，就可以設(shè)計和實現(xiàn)其他安全特性。

審核編輯：劉清