1. 動機
CAN Bus 不安全可能是當今汽車網絡中被提及最多的安全問題。已經發表了許多關于為什么車輛容易受到攻擊的論文,其中 CAN 總線是這些聲明的核心。其根本原因在于,上世紀 80 年代發明的 CAN 總線并未考慮網絡威脅,這或許是可以理解的,因為車輛連接性尚未納入范圍。隨著車輛功能的發展和對安全性的需求變得越來越明顯,提出了許多安全解決方案來解決 CAN 不安全問題。也許最有說服力的解決方案是 AUTOSAR 提出的解決方案,它依賴于使用共享對稱密鑰驗證 CAN 幀并包括新鮮度保護:
圖 1 Autosar 中的 SecOC 流程
由于 AUTOSAR 的普及,該解決方案是當今最流行的解決方案,但由于執行新鮮度管理和數據認證任務需要多層軟件,因此會對主機 CPU 造成性能損失。
圖 2 Autosar 分層架構中的 SecOC BSW
如上所示,當收到一個安全的PDU時,它會被路由到SecOC進行MAC驗證。SecOC 依靠新鮮度值管理器 (FVM) 來確定接收到的新鮮度值是否在可接受的窗口內。在這里,可以根據 OEM 偏好使用各種 FVM 策略。由于 CAN 有效載荷長度有限,許多解決方案需要截斷的新鮮度值,這導致需要定期同步完整的新鮮度值。在 FVM 的響應之后,SecOC 將請求發送到加密服務管理器 (CSM) 以執行加密功能以驗證 MAC。在將結果返回給 SecOC 之前,CSM 可能依賴軟件庫或 HSM 加密驅動程序來執行這項工作。最后,如果驗證成功,則 SecOC 將 PDU 轉發到 PDU 路由器,或者引發錯誤標志并丟棄幀。這些任務對應的 CPU 工作量很大。
由于趨勢是消息和 CAN 通道的數量增加,CPU 開銷懲罰的問題只會變得更糟。為了滿足吞吐量需求,芯片供應商提供集成在硬件安全模塊 (HSM) 中的 AES 加速器。但經驗表明,負責處理數百條消息的身份驗證請求的中央 HSM 由于數據復制進出 HSM 的開銷而成為瓶頸。請注意,AES 引擎延遲僅占 HSM 執行身份驗證所花費的總時間的一小部分。大部分延遲是由于作業設置、數據傳輸、作業調度、密鑰獲取和響應主機的軟件開銷造成的。隨著 CAN XL 的推出,它將支持高達 2048 字節長的有效載荷和高達 10Mbps 的波特率,對 HSM 的性能要求必然會變得更差。如果除了身份驗證之外還需要加密,那么將數據傳輸出 HSM 的額外開銷將進一步增加主機 CPU 傳輸或接收數據的總體延遲。顯然,今天的安全硬件和軟件架構是不夠的。
2. 威脅模型
CAN總線面臨許多威脅。此處的列表顯示了最令人擔憂的威脅:
欺騙:由于 CAN 總線的廣播特性,任何 CAN 節點都可以通過欺騙 CAN ID、DLC 和有效載荷來發送任何消息
嗅探和重放:由于 CAN 數據的開放性和豐富的 CAN 分析工具,CAN 幀可以很容易地被嗅探和重放,以使 ECU 執行某些功能,例如解鎖門或應用中斷
否認:由于 CAN 總線的廣播特性,當傳輸惡意 CAN 幀時,無法證明哪個 ECU 負責發送虛假消息
資源耗盡:當使用 AUTOSAR SecOC 啟用消息身份驗證時,惡意攻擊者可以發送精心挑選的新鮮值,使接收者忙于驗證同一幀的真實性以耗盡 CPU 資源
拒絕服務:惡意 ECU 可以連續發送零 ID 消息,導致它們始終贏得仲裁并拒絕其他 ECU 在總線上成功傳輸。此外,不合格的 CAN 硬件可以通過破壞某些字段(例如插入填充位或修改物理層 CRC)來殺死特定的 CAN 幀,從而導致目標 ECU 進入 BusOff 狀態。
CANsec 可以解決除拒絕服務之外的所有上述威脅,拒絕服務需要額外的檢測和預防機制。
3. 安全 CAN 控制器
為了在降低 CPU 開銷的同時應對數據認證的吞吐量和帶寬不斷增長的需求,建議將 CANsec 層集成到 CAN 控制器中,以支持線速的認證和/或加密。
圖 3 CANsec 架構
在 ECU 啟動期間,車載通信密鑰從 HSM 安全存儲器緩存到 CAN 控制器專用 KEY RAM。此 RAM 只能由 HSM 通過專用總線訪問,以防止惡意 CPU 訪問。它也只能由 CAN 控制器內的 AES 引擎直接訪問。添加了額外的 CAN 寄存器以允許用戶為每個安全通道標識符 (SCI) 指定密鑰索引映射。類似地,為每個消息添加一個專用寄存器來存儲幀新鮮度值。后者必須在 ECU 關閉之前存儲到安全內存中,以確保在下一個引導周期同步。當接收到 CAN 傳輸請求時,CAN 控制器執行以下序列:
根據 SCI 的密鑰索引獲取密鑰明文值并加載到 AES 引擎中
獲取新鮮度值并將其增加 1
輸入 CAN ID | 下載內容 | CAN 負載 | Freshness Value, Payload Type, 進入 AES 引擎生成完整性校驗值 (ICV)
當幀以線速傳輸時,將 CANsec 標頭(新鮮度值)和 ICV 插入有效負載
在接收期間,將遵循類似的過程,并附加將接收到的新鮮度值和 ICV 與預期值進行比較的步驟。為了檢查新鮮度,將接收到的值與存儲的新鮮度值加上預配置的接受窗口進行比較。這對于允許可能不同步的 ECU 重新同步到接收到的新鮮度值是必要的,而無需復雜的新鮮度值管理策略。如果 Freshness 和 ICV 值都符合預期,CAN 控制器會使用接收到的值更新 Freshness Value 寄存器并設置接收標志以讓應用程序處理數據。否則,它會設置錯誤標志以通知主機 CPU 接收到幀但數據無效。
4. 概念證明
瑞薩電子進行了一項可行性研究,以證明實施 CANsec 概念是有意義的。基于 CiA 613-2 CANsec 規范的早期版本,在 FPGA 中實現了原型 CANsec 實現。為了比較蘋果和蘋果,我們還在軟件中實現了 CANsec 協議。由于上述原因,不適合使用 SecOC。
該圖顯示了基于軟件的實現所需的 CPU 性能。處理時間與 Payload 數據量成正比,這是顯而易見的,因為更多的數據需要更多的時間來處理。預計 CANsec 軟件的 RX 延遲和 TX 延遲不會有不同的斜率。相反,模型應該具有幾乎相同的斜率。但是在 SW 中還有一個更大的步驟是為了發送幀而不是為了接收幀。這可能是軟件優化的一個領域。但是,接收和發送的總體趨勢是相同的。
圖4 CANsec CPU處理時間
該軟件在 1.2GHz 的 R-Car H3 SoC 的 ARM 內核上運行。如果這個數據會被分解到一個 400MHz 的 MCU;那么在 100% 的總線負載下,CPU 將被占用 25%(@252byte 有效負載)。這是一項相當大的工作,考慮到這樣的 MCU 有多個 CAN-XL 通道,那么 CPU 很快就會過載。因此,將其實現為 CAN-XL IP 中的硬件加速功能是有意義的。
下圖顯示了硬件實現的處理延遲。CANsec 模塊在 CAN 控制器的數據路徑中實現。為此,延遲必須比 CAN 總線上的 CAN-XL 幀處理時間短,以確保以線速進行處理。在我們的原型實現中,CANsec 模塊的時鐘頻率為 80MHz,并使用 16 個 S-Box 進行 AES 算法,通過這種設置,我們得到的值遠低于 CAN 總線上消息的占用時間。例如,可以通過使用更少的 S-Box 來消耗更少的芯片尺寸來實現進一步的優化。
圖 5 CANsec 硬件延遲時間
5. 結論
CANsec 是一種實用的解決方案,可保護 CAN 總線免受 CAN 網絡面臨的最常見威脅,同時減少主機 CPU 開銷和對更大、更強大 HSM 的需求。將高速身份驗證/加密任務從 HSM 卸載到分布在外圍設備中的加密引擎可以減輕 CPU 負擔。通過以線速執行身份驗證,它以最小的信號延遲為應用程序提供無縫的安全性。讓 HSM 控制密鑰緩存可以創建安全策略,以限制 ECU 在應用程序不再被視為受信任時發送安全消息的能力。
進一步表明,在硬件和軟件中實現 CANsec 是可行的。當然,在軟件中實現將具有與今天基于 SecOC 的實現相同的缺點。然而,軟件實現將允許在開始時平滑遷移該技術,當時并非所有控制器都支持 CANsec 的硬件實現。
審核編輯:郭婷
-
控制器
+關注
關注
112文章
16346瀏覽量
177905 -
CAN
+關注
關注
57文章
2744瀏覽量
463653 -
總線
+關注
關注
10文章
2879瀏覽量
88063
發布評論請先 登錄
相關推薦
評論