??摘要

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

01. 引言

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

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

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

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

但是，安全網關有許多容易被忽視的細節，尤其是在可用性方面。如果處理不當，將會導致網絡不安全或無法正常運行。

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

02. 幀傳輸

幀的傳輸看似簡單，實則暗藏陷阱。首先是傳輸順序問題。CAN安全網關絕不能重新排序幀，因為事件的順序對應用程序至關重要。例如，ISO-TP[6]傳輸協議會從一系列CAN幀中組合一條大消息，如果幀的順序被打亂，整個消息的接收可能會失敗（每個CAN幀都附有序列號，但有些檢錯實現方式只是檢查是否有間隙，然后觸發錯誤，甚至有些直接忽略序列號）。

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

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

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

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

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

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

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

解決既要保證優先級又要保證FIFO傳輸這一看似矛盾的問題的方法是，認識到FIFO傳輸的要求是針對具有相同標識符的幀。這意味著網關中正確的幀傳輸策略不是僅設置一個優先級隊列，而是為每個幀標識符設置一個FIFO，再將其輸入到優先級隊列中（見圖8）。

幀抖動還會給安全網關帶來另一個問題：它會破壞目標總線的實時特性。

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

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

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

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

03. 幀丟棄

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

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

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

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

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

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

總結 .

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

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

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

文章來源

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

參考文獻

[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

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

審核編輯 黃宇