摘要

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

虹科PCAN XL套件

01. 深度防御

過去數(shù)十年間，IT行業(yè)始終秉持深度防御（Defense-in-Depth）核心理念，通過在信息技術(shù)系統(tǒng)中部署多層級獨立安全控制機制，為潛在的單點失效提供冗余防護?；谶@一理念，在車載10Mbit/s通信領(lǐng)域同步構(gòu)建兩種技術(shù)體系的安全防護層，已成為汽車行業(yè)應(yīng)對網(wǎng)絡(luò)整合趨勢的必然要求。

本文針對多點數(shù)據(jù)層安全架構(gòu)建設(shè)中的兩個關(guān)鍵難題展開研究：其一聚焦于高效密鑰協(xié)商協(xié)議的開發(fā)，其二探索橋接設(shè)備跨網(wǎng)絡(luò)連接場景下的端到端加密實現(xiàn)方案。

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

02. MACsec 和 CANsec

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

圖1 MACsec / CANsec

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

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

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

因此，需要一種機制來協(xié)商一個臨時有效的會話密鑰，或者根據(jù)MKA規(guī)范稱為安全關(guān)聯(lián)密鑰（SAK），并定期更換該密鑰。

03. 10Mbit/s速率領(lǐng)域的MKA

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

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

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

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

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

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

04. 更快的MKA

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

2021年，V?lker博士[1]提出了一些修改建議，以優(yōu)化密鑰協(xié)商時間。其基本思路是：根據(jù)MKPDU的內(nèi)容對其進行分類，并相應(yīng)地修改發(fā)送頻率。

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

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

(2) 需要分發(fā)新的安全關(guān)聯(lián)密鑰

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

(4) 新參與者想要加入連接關(guān)聯(lián)

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

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

05. 多節(jié)點應(yīng)用場景

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

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

圖2 基本資料——參與方發(fā)現(xiàn)

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

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

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

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

圖3 優(yōu)化配置文件——參與方發(fā)現(xiàn)

在密鑰分發(fā)過程中也能觀察到類似的現(xiàn)象。根據(jù)MKA規(guī)范，如果有參與者添加到活動對等節(jié)點列表中，密鑰服務(wù)器應(yīng)分發(fā)新的SAK。

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

圖4 基本配置文件——密鑰分發(fā)

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

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

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

例如：

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

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

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

06. MKA的替代方案

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

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

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

07. 小結(jié)

仿真結(jié)果清楚地表明，MKA可以優(yōu)化到在典型網(wǎng)絡(luò)設(shè)置中，最多16個參與者的密鑰協(xié)商能夠在50毫秒內(nèi)完成。與標準MKA相比，這是一個巨大的改進，因為我們只是對時間進行了更精確的調(diào)整，并分析了關(guān)鍵因素。

這種優(yōu)化方法保留了MKA的所有優(yōu)點（功能豐富、經(jīng)過充分驗證、與網(wǎng)絡(luò)無關(guān)），使其適用于許多需要更快通信啟動時間的用例。

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

在某些用例中，橋接設(shè)備是兩個或更多CAN XL網(wǎng)絡(luò)的一部分，用于實現(xiàn)消息在CAN總線A和CAN總線B之間的轉(zhuǎn)發(fā)。

圖6 橋接的CAN XL網(wǎng)絡(luò)

可能會出現(xiàn)這樣的情況：CAN總線A上的消息的優(yōu)先級標識符已被CAN總線B中的CAN XL節(jié)點使用，因此如果不進行修改就轉(zhuǎn)發(fā)消息，會導(dǎo)致優(yōu)先級標識符沖突。

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

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

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

09. 切勿將優(yōu)先級標識符用作標識符

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

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

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

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

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

10. CAN-in-CAN

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

(1) 節(jié)點無需知道其消息是否會跨越其 CAN XL 網(wǎng)絡(luò)的邊界。

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

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

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

圖9 CAN-in-CAN

接收網(wǎng)絡(luò)中的節(jié)點通過特殊的服務(wù)數(shù)據(jù)類型識別轉(zhuǎn)發(fā)的幀，移除目標網(wǎng)絡(luò)報頭，然后可以驗證未修改的CANsec保護幀。如果不使幀無效，就無法篡改其任何內(nèi)容（包括優(yōu)先級標識符和 VCID）。

圖10 通信示例

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

總結(jié).

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

文章來源

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

參考文獻

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

[2] IEEE802.1X-2020

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

審核編輯 黃宇