??摘要

控制器局域網(wǎng)（CAN）安全網(wǎng)關(guān)通常用于將車輛的不可信部分與可信部分隔離開來。盡管從概念上講，它很簡單，但有時可能會造成一些難以察覺的問題。這些問題在測試階段可能不會被發(fā)現(xiàn)，直到車輛投入使用或遭遇復(fù)雜的安全攻擊時才會顯現(xiàn)出來。特別是在處理傳輸幀時，常見的問題有加密保護間歇性失效、消息丟失或損壞，以及受保護的CAN總線上的通信中斷。想要構(gòu)建穩(wěn)健安全的網(wǎng)關(guān)就必須避免這些問題。

01. 引言

安全網(wǎng)關(guān)是保障CAN總線安全的常用技術(shù)（與加密消息傳遞、入侵檢測和硬件安全一同使用[1]）。其主要目的是保護硬實時機電控制總線，使其免受無線連接的易受攻擊設(shè)備的干擾，例如遠程信息處理控制單元（TCU）和車載信息娛樂系統(tǒng)（IVI）。這是非常必要的，因為（對于足夠復(fù)雜的系統(tǒng)而言，是「何時」而非「是否」[2]）當這些易受攻擊的設(shè)備在攻擊中被攻破時，安全網(wǎng)關(guān)等技術(shù)可以保證攻擊者無法危及車輛的基本控制功能。

安全網(wǎng)關(guān)在車輛網(wǎng)絡(luò)中還有第二個用途：將CAN總線劃分為多個網(wǎng)段，能做到當某個網(wǎng)段受到物理攻擊時，其他網(wǎng)段仍能繼續(xù)正常運行而不受干擾。例如，CAN注入攻擊[3]通過汽車上易于觸及的部位（如大燈連接器）接入CAN總線，使盜竊裝置能夠偽造消息（例如發(fā)送禁用防盜器或解鎖車門的指令）。而在易于竊入的CAN總線與車輛其他部分之間設(shè)置安全網(wǎng)關(guān)，就可以防止此類攻擊。

一種常見的定義安全性的方法是通過「CIA 三元組」：保密性（Confidentiality）、完整性（Integrity）、可用性（Availability）。對于CAN總線來說，最常見的攻擊是完整性攻擊：攻擊者選擇CAN標識符來發(fā)送偽造消息，使接收者誤以為是真實消息并據(jù)此執(zhí)行操作。

因此，CAN安全網(wǎng)關(guān)在概念上很簡單：它是一個連接兩條CAN總線的設(shè)備，能夠過濾幀，僅將合適的子集從一條總線復(fù)制到另一條總線（見圖 1）。

但是，安全網(wǎng)關(guān)有許多容易被忽視的細節(jié)，尤其是在可用性方面。如果處理不當，將會導(dǎo)致網(wǎng)絡(luò)不安全或無法正常運行。

美國國家汽車貨運協(xié)會（NMFTA）制定了一套安全網(wǎng)關(guān)的要求，以確保其正確運行。這些要求以正式的需求語言定義，并已公開[5]。本文基于這些要求，重點討論CAN安全網(wǎng)關(guān)的兩個關(guān)鍵方面：1）幀傳輸；2）幀丟棄。

02. 幀傳輸

幀的傳輸看似簡單，實則暗藏陷阱。首先是傳輸順序問題。CAN安全網(wǎng)關(guān)絕不能重新排序幀，因為事件的順序?qū)?yīng)用程序至關(guān)重要。例如，ISO-TP[6]傳輸協(xié)議會從一系列CAN幀中組合一條大消息，如果幀的順序被打亂，整個消息的接收可能會失?。總€CAN幀都附有序列號，但有些檢錯實現(xiàn)方式只是檢查是否有間隙，然后觸發(fā)錯誤，甚至有些直接忽略序列號）。

當幀受到加密保護時，也會出現(xiàn)這個問題，例如使用SecOC[7]或CryptoCAN[8]。加密方案旨在防范重放攻擊[9]，即攻擊者復(fù)制合法幀并在稍后重新發(fā)送，以誘使接收者執(zhí)行操作。這些方案通常會將重排序的幀視為重放攻擊的嘗試，這往往會導(dǎo)致誤報，而過多的誤報會導(dǎo)致真正的攻擊被忽視。

CAN幀通常不是由專門編寫的安全網(wǎng)關(guān)軟件重新排序，而是由CAN控制器硬件造成的。大多數(shù)CAN控制器都有一個傳輸優(yōu)先級隊列，隊列中的下一個要發(fā)送的幀不是隊首的幀，而是CAN標識符最低的幀。有些控制器硬件通過一組比較器電路來比較每個幀緩沖區(qū)槽的標識符，有些則通過狀態(tài)機順序掃描幀緩沖區(qū)槽，跟蹤目前看到的最低數(shù)值。無論哪種方式，當隊列中有兩個或更多具有相同標識符的CAN幀時，就會出現(xiàn)問題：硬件必須決定先發(fā)送哪一個。在大多數(shù)情況下，這種「平局」是隨機解決的（例如根據(jù)幀緩沖區(qū)槽的編號，或者順序掃描中最后看到的幀）。

兩個具有相同標識符的幀同時出現(xiàn)在傳輸隊列中的一個原因是幀到達抖動（Frame Arrival Jitter）。一般來說，抖動是指周期性事件特定時間的變化性。車輛控制網(wǎng)絡(luò)中的大多數(shù)CAN幀是周期性生成的（通常它們攜帶由電子控制單元ECU中的周期性控制回路產(chǎn)生的數(shù)據(jù)）。雖然它們是嚴格周期性生成的（即生成一個幀與下一個幀之間有固定的時間間隔），但到達接收者的時間并不相同：基本周期相同，但到達時間存在抖動（見圖5）。

抖動意味著如果將周期性幀直接從輸入的CAN控制器先進先出隊列（FIFO）復(fù)制到輸出的優(yōu)先級隊列中，那么同一時間隊列中可能會有多個具有相同標識符的幀（見圖6）。

幀抖動是一個特別棘手的問題，因為在運行時觀察到的給定幀的抖動取決于兩條CAN總線上的特定流量模式。在測試期間，可能不會觀察到CAN幀的重排序，但在兩條總線處于特定負載情況下，安全或ISO-TP消息傳遞可能會出現(xiàn)高度間歇性故障，從而暴露這個問題。在后期制作環(huán)境中可能根本無法追蹤此類故障的原因，而且在任何情況下，故障都不是簡單的錯誤造成的，而是安全網(wǎng)關(guān)的設(shè)計缺陷。

解決重排序問題的方法是在傳輸隊列中采用FIFO緩沖。然而，這又會直接導(dǎo)致另一個問題：CAN優(yōu)先級反轉(zhuǎn)[4]。當FIFO隊列的前端是一個低優(yōu)先級幀，而緊急的高優(yōu)先級幀在其后時，就會發(fā)生優(yōu)先級反轉(zhuǎn)。如果總線長時間被更高優(yōu)先級的流量占用，隊列前端的幀將長時間無法贏得仲裁，從而導(dǎo)致緊急幀被長時間延遲（見圖7）。

與幀抖動一樣，優(yōu)先級反轉(zhuǎn)也可能是間歇性的：它可能在測試中不會出現(xiàn)，因為這取決于總線上排隊和傳輸?shù)腃AN幀的特定順序。但若發(fā)生其后果同樣嚴重：一個周期為10ms的緊急幀有時可能會被延遲90ms，這可能會導(dǎo)致各種故障（包括觸發(fā)超時，使組件被誤認為發(fā)生故障）。在量產(chǎn)車輛中，此類故障的后果可能非常嚴重。

解決既要保證優(yōu)先級又要保證FIFO傳輸這一看似矛盾的問題的方法是，認識到FIFO傳輸?shù)囊笫轻槍哂邢嗤瑯俗R符的幀。這意味著網(wǎng)關(guān)中正確的幀傳輸策略不是僅設(shè)置一個優(yōu)先級隊列，而是為每個幀標識符設(shè)置一個FIFO，再將其輸入到優(yōu)先級隊列中（見圖8）。

幀抖動還會給安全網(wǎng)關(guān)帶來另一個問題：它會破壞目標總線的實時特性。

從圖6中可以看出，CAN A的到達抖動會導(dǎo)致幀在時間上「聚集」，而安全網(wǎng)關(guān)會將這些幀立即放入CAN B的隊列中，這使得兩個幀在比在CAN A上短得多的時間內(nèi)排隊。而這意味著在短時間間隔內(nèi)，由于轉(zhuǎn)發(fā)幀導(dǎo)致的總線負載會高得多（當然，在長時間間隔內(nèi)，總線負載是相同的，但實時系統(tǒng)關(guān)注的是短期利用率）。

安全網(wǎng)關(guān)導(dǎo)致的這種較高的短期總線負載意味著攻擊者可以在CAN總線上精心設(shè)計一種流量模式，在受安全網(wǎng)關(guān)保護的CAN總線上引發(fā)定時故障，從而導(dǎo)致故障（例如上文提到的錯過超時）。在CIA三元組中，這是可用性故障的一個例子，屬于一種拒絕服務(wù)攻擊。

為了抵御這種類型的攻擊（并消除由于抖動導(dǎo)致的間歇性定時故障），安全網(wǎng)關(guān)應(yīng)實施幀延遲機制：在自上一個幀排隊起至少經(jīng)過一個幀周期時間之前，不應(yīng)將幀放入其傳輸FIFO中（見圖9）。

通過將幀延遲到其周期時間結(jié)束，目標總線上的定時行為與原始發(fā)送 ECU 直接排隊該幀時沒有區(qū)別。唯一的區(qū)別是，在這種情況下，延遲會增加第二個幀的延遲時間。但是，通過網(wǎng)關(guān)的額外延遲不會導(dǎo)致最壞情況下的延遲增加：實際上，抖動會使幀比預(yù)期更早出現(xiàn)，而延遲機制僅適用于提前到達的幀。通過延遲提前到達的幀，安全網(wǎng)關(guān)可以維持現(xiàn)有CAN定時分析[10]所保證的最壞情況延遲，從而維持從一條CAN總線到另一條CAN總線的端到端延遲保證。

03. 幀丟棄

CAN在常見的現(xiàn)場總線中獨具特色，它提供原子廣播功能。這一特性對于構(gòu)建穩(wěn)健的系統(tǒng)非常有用，許多應(yīng)用程序都依賴于它（即使是在不知情的情況下）。當發(fā)送方將消息標記為「已發(fā)送」時，發(fā)送方就知道每個在線節(jié)點都接收到了該消息的有效副本。

實際上，CAN在硬件層面實現(xiàn)了共識機制。而對于其他協(xié)議，如以太網(wǎng)，如果接收到的消息不正確（例如以太網(wǎng)幀的CRC，即幀校驗序列不匹配），則該幀將被丟棄。這意味著總線上的簡單噪聲就可能導(dǎo)致節(jié)點對系統(tǒng)狀態(tài)的看法出現(xiàn)分歧（一個接收方只能看到舊的傳感器讀數(shù)，而另一個接收方看到的是較新的讀數(shù)）。分布式共識是穩(wěn)健的分布式實時控制系統(tǒng)的關(guān)鍵組成部分，要在非穩(wěn)健的現(xiàn)場總線上通過軟件協(xié)議實現(xiàn)這一特性非常困難。事實上，蘭伯特的拜占庭將軍問題就源于一個試圖解決此問題的研究項目[11]。

這就對安全網(wǎng)關(guān)提出了一個重要要求：維護CAN的分布式共識特性。引入安全網(wǎng)關(guān)不應(yīng)破壞現(xiàn)有應(yīng)用程序的假設(shè)，尤其是那些隱含的假設(shè)。換句話說，安全網(wǎng)關(guān)絕不能丟棄幀（當然，除非系統(tǒng)確實存在故障，這里的「故障」包括對系統(tǒng)的攻擊）。

當然，有時為了抵御攻擊，安全網(wǎng)關(guān)必須丟棄某些幀。例如，除非連接了合法的診斷測試儀，否則診斷測試儀幀應(yīng)被丟棄；在遭受泛洪攻擊時，相關(guān)幀也應(yīng)被丟棄等。但是，安全網(wǎng)關(guān)也絕不能因為瞬態(tài)過載導(dǎo)致緩沖區(qū)空間不足而丟棄幀。

在接收端，這意味著必須以CAN總線的全速接收和處理幀：如果兩個具有相同標識符的幀連續(xù)到達，CAN控制器硬件及其驅(qū)動軟件絕不能丟失其中任何一個幀。通常，這意味著要通過中斷服務(wù)程序（ISR）來處理CAN幀，并且CPU的調(diào)度必須能夠在各自的截止時間內(nèi)處理來自所有CAN控制器的所有中斷（以及CPU的所有其他需求）。這通常需要對CPU進行仔細的調(diào)度，并了解ISR的最壞情況執(zhí)行時間。對于CAN幀的傳輸，必須有足夠的空間來存儲所有待發(fā)送的幀（包括延遲的幀）。

一種限制緩沖區(qū)空間的方法，類似于在ECU軟件中限制堆?？臻g，即不斷增加緩沖區(qū)空間，直到不再出現(xiàn)溢出情況。顯然，這不是一種好方法，因為它依賴于在測試期間觀察到最壞情況（因此，幾乎不可能同時觀察到兩條CAN總線上的最壞情況流量模式）。更好的方法是通過計算給定幀在隊列中可能停留的最長時間（即其在CAN目標總線上的最壞情況延遲）、可以延遲但仍存儲的時間，以及在這些時間內(nèi)從源CAN總線合法接收的最大次數(shù)，來限制緩沖區(qū)空間。

總結(jié) .

安全網(wǎng)關(guān)必須滿足一些非功能性要求，以充分保護CAN總線免受攻擊，同時也不能給系統(tǒng)引入故障。美國國家汽車貨運協(xié)會（NMFTA）已經(jīng)用正式的描述語言列舉了此類網(wǎng)關(guān)的所有要求，并將其公開。

安全網(wǎng)關(guān)在保護CAN總線的實時性和分布式共識特性方面有非常具體的要求，這需要在傳輸CAN幀時仔細處理幀的順序和緩沖，以避免常見CAN控制器硬件設(shè)計的陷阱以及CAN總線上的幀到達抖動問題。

在設(shè)計階段如果不考慮這些問題，可能會在瞬態(tài)過載情況下導(dǎo)致故障。這些故障在測試期間可能難以觀察到，但在量產(chǎn)車輛數(shù)百萬小時的運行過程中很可能會顯現(xiàn)出來，進而引發(fā)可靠性和安全問題，甚至可能導(dǎo)致業(yè)務(wù)層面的失敗。能夠限制CAN總線的實時行為是確保在開發(fā)過程中通過分析發(fā)現(xiàn)問題的關(guān)鍵，而不是將問題留到實際使用中才被發(fā)現(xiàn)。

文章來源

本文基于Ben Gardiner（美國國家貨運協(xié)會，NMFTA）、John Maag（康明斯）、Dr. Ken Tindell（JK能源）在第18屆國際CAN大會（iCC）的演講。已刊于《第18屆iCC會議論文集》2024版，由CiA出版。虹科智能互聯(lián)團隊翻譯并分享，旨在與行業(yè)同仁共享前沿技術(shù)成果。

參考文獻

[1] Defending The CAN Bus: Security Gateways (https://kentindell.github.io/2021/11/24/cansecurity-part-3)

[2] Pwn2Own Automotive 2024 (https://vicone.com/pwn2own-automotive)

[3] CVE-2023-29389 (https://nvd.nist.gov/vuln/detail/CVE-2023-29389)

[4] CAN Priority Inversion (https://kentindell.github.io/2020/06/29/can-priority-inversion)

[5] Implementation Requirements for Secured Gateways, NMFTA (https://nmfta.org/whitepaper/implementation-requirements-for- secured-gateways)

[6] ISO 15765-2:2016 Road vehicles, Diagnostic communication over Controller Area Network (DoCAN) Part 2: Transport protocol andmnetwork layer services

[7] Specifcation of Secure Onboard ommunication Protocol, AUTOSAR 969 R23-11 2023-11-23

[8] Securing CAN: Introduction to CryptoCAN, CAN Newsletter December 2022, (CAN in Automation)

[9] Replay attack (https://en.wikipedia.org/wiki Replay_attack)

[10] Guaranteeing Message Latencies on

Controller Area Network (CAN), K. Tindell and A. Burns, Proceedings 1st International CAN Conference, 1994

[11] The Byzantine Generals Problem, L. Lamport, R. Shostak, M. Pease, ACM Transactions on Programming Languages and SystemsVolume 4 Issue 3, 1982

虹科是一家在通訊領(lǐng)域，尤其是汽車電子和智能自動化領(lǐng)域擁有超過16年經(jīng)驗的高科技公司，致力于為客戶提供CAN/CAN FD、LIN、車載以太網(wǎng)、TSN等全方位的一站式智能互聯(lián)解決方案。????

審核編輯 黃宇