摘要

隨著汽車以太網的興起和車載通信系統數量的增加，網絡整合成為控制復雜性和成本的關鍵。當前架構呈現明確分層：以太網（100/1000Mbit/s）支撐信息娛樂、ADAS等高帶寬應用，而CAN/CAN FD（0.5-5Mbit/s）處理發動機管理等實時控制。未來CAN XL和10BASE-T1S將瞄準中速控制領域。值得注意的是，當前約90%的車載節點通信速率仍≤10Mbit/s，凸顯了中低速通信的基礎性地位。

虹科PCAN XL套件

01. 深度防御

過去數十年間，IT行業始終秉持深度防御（Defense-in-Depth）核心理念，通過在信息技術系統中部署多層級獨立安全控制機制，為潛在的單點失效提供冗余防護。基于這一理念，在車載10Mbit/s通信領域同步構建兩種技術體系的安全防護層，已成為汽車行業應對網絡整合趨勢的必然要求。

本文針對多點數據層安全架構建設中的兩個關鍵難題展開研究：其一聚焦于高效密鑰協商協議的開發，其二探索橋接設備跨網絡連接場景下的端到端加密實現方案。

需要特別說明的是，本文提出的安全增強方案嚴格遵循分層防護理念，其設計目標并非取代現有OSI協議棧中的安全機制（如車載SecOC協議、IPSec或TLS等），而是通過縱向協同構建更完備的防御體系。

02. MACsec 和 CANsec

以太網已經有了MACsec及其配套的密鑰協商協議MKA，且已定義了十年之久，而國際CiA協會正通過CiA613-2為CAN XL制定CANsec規范。MACsec和CANsec的目標都是在各自的數據層之上，以線速性能提供保密性、完整性和認證性。

圖1 MACsec / CANsec

為滿足這些要求，這兩種技術都使用具有提供認證加密和相關數據（AEAD）操作模式的分組密碼。MACsec只支持AES，而CANsec則計劃以 ASCON[3]的形式支持輕量級加密。

受保護的幀攜帶一個單調遞增的分組編號（PN），以防止重放攻擊。這個分組編號用于生成一個隨機數（Nonce），該隨機數是相應AEAD算法所需的輸入。

那么有了這些基石，就不可能在網絡的整個生命周期中使用永久有效的加密密鑰，因為使用相同密鑰意味著重復使用隨機數，這樣實際上會使加密無效。

因此，需要一種機制來協商一個臨時有效的會話密鑰，或者根據MKA規范稱為安全關聯密鑰（SAK），并定期更換該密鑰。

03. 10Mbit/s速率領域的MKA

以太網擁有經過充分驗證、功能豐富但也相當復雜的MACsec密鑰協議，專門用于解決這一難題，因此，選擇MKA作為CANsec(CAN XL)和MACsec(10BASE- T1S)的密鑰協議解決方案也是很自然的。

MKA是圍繞零知識和零假設方法設計的，每個參與者只依賴自己的實施質量。由于MKA使用專用的MACsec密鑰協議數據單元 (MKPDU)，它不需要知道有多少參與者正在、將要或曾經在線，也不要求參與者以一定的頻率發送數據。此外，每個參與者在啟動時生成的隨機成員標識符確保了重放保護。如果相關參與者的隨機數生成器質量較高，則該參與者可以安全地抵御MKA控制信息的重放攻擊。

不過，典型的MKA應用與在10Mbit/s速率領域的預期應用之間存在兩個決定性差異。

首先，雖然MACsec密鑰協商是為任意數量的參與者（或根據IEEE 802.1標準稱為對等節點）制定的，但實際使用中很少超過兩個參與者。

其次，MKA的Hello時間為兩秒。因此，建立密鑰協商至少需要兩秒，平均需要三秒。

雖然這種密鑰協議時間在數據中心等典型的以太網環境中是可以接受的，但在汽車或其他對時間更敏感的環境中就不行了。對于增加一個安全層所造成的通信延遲具體有多少是可以接受的，目前還沒有達成共識。觀點有從幾毫秒到一百多毫秒不等。這完全取決于具體的使用情況，但對于大多數（汽車）使用情況來說，MKA所需的平均3秒鐘太慢了。

04. 更快的MKA

以下優化措施的目標都是在不違反現有規范[2]的情況下，縮短密鑰協商時間（即從所有參與者上線到所有參與者能夠相互通信的時間間隔）。因此，MKPDU，尤其是其中包含的所有參數集都不會以任何方式進行修改，也不會違反IEEE規范中的任何「應」和「可」規則。

2021年，V?lker博士[1]提出了一些修改建議，以優化密鑰協商時間。其基本思路是：根據MKPDU的內容對其進行分類，并相應地修改發送頻率。

最直觀的，你能想到的規則是，每當有有助于達成密鑰協議的消息要發送時，每個參與者都要發送一個更新的MKPDU。這些規則是：

(1) 潛在對等節點或活動對等節點列表發生了變化

(2) 需要分發新的安全關聯密鑰

(3) 已安裝新的安全關聯密鑰，需要進行確認

(4) 新參與者想要加入連接關聯

我們將這組規則稱為基本配置文件。

如文獻[1]所示，這些修改產生了顯著效果，將密鑰協議所需的時間減少到了30毫秒以下。

05. 多節點應用場景

讓我們將這些修改應用于MKA，將參與者數量擴展到n，并從理論上分析需要交換多少消息，以及每個參與者必須處理多少消息。

如果所有參與者同時上線，每個參與者都會生成一個MKA Hello消息，其中包含其隨機生成的成員標識符。每個參與者都會收到n-1條這樣的消息，每次處理一條，就向其潛在對等節點列表中添加n-1個條目，并回復n-1次。那么總共會發送n2條消息，每個參與者必須處理n2-n條消息。因此，密鑰協商的這一初始步驟與參與者數量并非呈線性關系。

圖2 基本資料——參與方發現

如果我們將規則稍作修改，這個問題就可以得到解決：

(1) 在潛在對等節點或活動對等節點列表中添加一個密鑰服務器對等節點。

我們將這組修改后的規則稱為優化配置文件。在典型設置中，通常只有一兩個具備密鑰服務器功能的參與者。

這使得每個參與者必須處理的消息數量減少到O(n)。

圖3 優化配置文件——參與方發現

在密鑰分發過程中也能觀察到類似的現象。根據MKA規范，如果有參與者添加到活動對等節點列表中，密鑰服務器應分發新的SAK。

在我們的系統啟動場景中，密鑰服務器在收到第一個MKA Hello響應時會發出一個新的SAK，收到第二個響應時再發出一個，如此繼續，直到活動對等節點列表最終包含所有參與者的成員標識符。總共會分發n-1個SAK，但只有最后一個會得到所有參與者的確認。不幸的是，所有SAK都會被其MKA Hello消息最先被密鑰服務器處理的參與者確認，除第一個SAK外，其他SAK都會被其MKA Hello消息第二個被處理的參與者確認，如此繼續，直到最后分發的SAK最終被所有參與者接受和確認。為了完成密鑰協商，每個參與者總共必須處理O(n2) 數量的消息。

圖4 基本配置文件——密鑰分發

為了解決這個問題，必須減少密鑰服務器分發的密鑰分發消息數量。一種實現方法是讓密鑰服務器知道參與者的數量。有了這個信息，密鑰服務器可以有意延遲SAK的分發，直到收到所有預期參與者的MKA Hello消息。但這需要完全靜態的網絡設置，因此并不適用于所有用例。例如，若有一個參與者的啟動速度明顯慢于其他參與者，就會導致網絡中的其他部分無法通信。

另一種保持MKA對網絡拓撲無感知特性的方法是限制新SAK的發布。密鑰服務器在處理完一個傳入的MKPDU后，會進入一個需要發布新SAK的狀態。此時，它不是立即發送相應的MKPDU，而是將發送延遲一定時間。這使密鑰服務器有時間處理其他傳入的MKA Hello消息（見圖5），并發布一個可供更多甚至所有參與者使用的SAK。讓我們將這種行為添加到優化配置文件中。

在對16個參與者進行的模擬中，這種優化將分發的SAK數量減少到兩個，從而消除了運行時間隨參與者數量呈二次方增長的問題。這種方法具有很大的靈活性。根據網絡設置，你可以選擇合適的延遲時間來優化密鑰協商時間。

例如：

(1)所有參與者速度相同。你可以將延遲時間設置為一個較小的值，但要足夠讓密鑰服務器處理所有MKA Hello響應。

(2)有一個參與者比其他參與者慢得多，但它提供了重要信息。你可以將延遲時間設置為能讓這個慢的參與者有足夠時間發送其MKA Hello響應的值。

更有利的是，如果連接的參與者不提供此選項，或者你無法訪問其配置，那么只需對密鑰服務器應用此配置即可。

06. MKA的替代方案

密鑰協商協議的選擇取決于對密鑰協商的具體要求，以及協議名稱所隱含的特性。如果你的保護目標是使密鑰協商不會受到來自孤立參與者的有效記錄流量的攻擊，那么密鑰協商協議需要包含一些挑戰響應協議部分，強制加入一個潛在攻擊者無法控制且質量良好（盡可能隨機）的值（即挑戰）。

有兩種方法可以實現這一點。第一種方法需要一個高度同步的公共時間源，這本身就是一個難題，本文不對此進行討論。第二種方法要求每個參與者生成一個隨機數，并將其發送給所有其他參與者，而其他參與者則必須在響應中包含所有這些隨機數（在MKA中稱為成員標識符）。

這正是MKA所采用的方式。任何替代方案都必須采取類似的做法，并且不可避免地至少需要一個消息往返，因此會涉及傳輸和處理時間。如果沒有設置時間，就無法實現能夠抵御這種重放攻擊的密鑰協商。

07. 小結

仿真結果清楚地表明，MKA可以優化到在典型網絡設置中，最多16個參與者的密鑰協商能夠在50毫秒內完成。與標準MKA相比，這是一個巨大的改進，因為我們只是對時間進行了更精確的調整，并分析了關鍵因素。

這種優化方法保留了MKA的所有優點（功能豐富、經過充分驗證、與網絡無關），使其適用于許多需要更快通信啟動時間的用例。

08. 橋接場景中的端到端 CANsec

在某些用例中，橋接設備是兩個或更多CAN XL網絡的一部分，用于實現消息在CAN總線A和CAN總線B之間的轉發。

圖6 橋接的CAN XL網絡

可能會出現這樣的情況：CAN總線A上的消息的優先級標識符已被CAN總線B中的CAN XL節點使用，因此如果不進行修改就轉發消息，會導致優先級標識符沖突。

如果你想使用CANsec保護這樣的系統，可以為總線A和總線B分別建立不同的連接關聯。橋接設備對傳入的消息進行解密，根據需要修改優先級標識符，然后重新加密消息。考慮到深度防御原則，這可能不是最佳選擇，因為這意味著橋接設備必須擁有兩個關聯的長期密鑰，這使其成為攻擊者的主要目標。

從安全角度來看，端到端加密更為理想，即橋接設備不進行加密操作，因此無需訪問任何密鑰。為了在CANsec中實現這種場景，當前的CiA 613-2草案規定了一些選項，可以將優先級標識符和虛擬CAN標識符（VCID）排除在CANsec提供的完整性保護之外。

雖然這些選項確實使實現此類場景成為可能，但請確保你極其謹慎地使用它們，因為優先級標識符和VCID都不能包含語義信息，這一點至關重要。

09. 切勿將優先級標識符用作標識符

CAN XL相較于傳統CAN和CAN FD的改進之一，是它打破了標識符字段在語義上不太合理的雙重用途。在CAN XL出現之前，標識符字段既是物理層的優先級指令，又是消息標識符。因此，在不改變消息含義的情況下，無法更改標識符字段。而在CAN XL中，優先級指令由優先級標識符承擔，接受字段（AF）負責識別消息的含義。

在理想情況下，設計CAN XL網絡的系統工程師會牢記這一點，不會混淆這兩個字段的獨立用途。在這種情況下，CANsec的排除選項支持端到端加密的橋接。但是，如果至少有一個CAN XL節點只是對現有CAN FD實現的簡單遷移，會發生什么情況呢？

很可能優先級標識符只是遺留項目中的CAN標識符，因為這是將項目遷移到CAN XL的最簡單方法。這樣一來，優先級標識符的含義超出了預期，在不失去CANsec保護的情況下，無法橋接CAN XL消息。

遺憾的是，當前的CANsec草案并未針對這種情況提供安全的解決方案。

CANsec排除選項的另一個缺點是，網絡中的所有節點都必須預先配置，以表明某些消息要進行轉發，并因此將優先級標識符從其完整性校驗值（ICV）計算中排除。如果不更改配置，就無法通過橋接設備連接第二條CAN總線，而這可能由于無法訪問所有節點而無法實現，這限制了擴展選項。

10. CAN-in-CAN

如果遇到優先級標識符傳達語義信息的情況，并且/或者希望能夠靈活地選擇或臨時添加橋接設備，就需要一種滿足以下要求的解決方案：

(1) 節點無需知道其消息是否會跨越其 CAN XL 網絡的邊界。

(2) CAN XL 報頭的所有字段都受到 CANsec 的保護

CAN-in-CAN就是一種滿足上述要求且不會破壞端到端加密的解決方案：

發起方網絡的配置保持不變，因此每個節點都傳輸CANsec保護的幀。橋接設備識別要轉發的幀，并將整個CAN XL幀（包括其報頭數據）作為新「封裝」幀的有效載荷，并為其添加一個新的CAN XL報頭。圖9展示了這一概念。

圖9 CAN-in-CAN

接收網絡中的節點通過特殊的服務數據類型識別轉發的幀，移除目標網絡報頭，然后可以驗證未修改的CANsec保護幀。如果不使幀無效，就無法篡改其任何內容（包括優先級標識符和 VCID）。

圖10 通信示例

由于MKA控制消息也必須以相同方式通過橋接設備，因此所有參與節點都必須支持CAN-in-CAN概念。

總結.

雖然CAN-in-CAN概念在CAN XL有效載荷中需要額外占用12個字節，但它提供了更大的靈活性，并為使用遺留組件安全橋接 CAN XL 網絡提供了可能。

文章來源

本文基于Peter Decker（Vector）在第18屆國際CAN大會（iCC）的演講。已刊于《第18屆iCC會議論文集》2024版，由CiA出版。虹科智能互聯團隊翻譯并分享，旨在與行業同仁共享前沿技術成果。

參考文獻

[1] Starting Up MACsec for Automotive Ethernet, Dr. Lars V?lker

[2] IEEE802.1X-2020

[3] Ascon - Lightweight Authenticated Encryption & Hashing????

審核編輯 黃宇