1. 動機

CAN Bus 不安全可能是當今汽車網絡中被提及最多的安全問題。已經發(fā)表了許多關于為什么車輛容易受到攻擊的論文，其中 CAN 總線是這些聲明的核心。其根本原因在于，上世紀 80 年代發(fā)明的 CAN 總線并未考慮網絡威脅，這或許是可以理解的，因為車輛連接性尚未納入范圍。隨著車輛功能的發(fā)展和對安全性的需求變得越來越明顯，提出了許多安全解決方案來解決 CAN 不安全問題。也許最有說服力的解決方案是 AUTOSAR 提出的解決方案，它依賴于使用共享對稱密鑰驗證 CAN 幀并包括新鮮度保護：

圖像

圖 1 Autosar 中的 SecOC 流程

由于 AUTOSAR 的普及，該解決方案是當今最流行的解決方案，但由于執(zhí)行新鮮度管理和數據認證任務需要多層軟件，因此會對主機 CPU 造成性能損失。

圖像

圖 2 Autosar 分層架構中的 SecOC BSW

如上所示，當收到一個安全的PDU時，它會被路由到SecOC進行MAC驗證。SecOC 依靠新鮮度值管理器 （FVM） 來確定接收到的新鮮度值是否在可接受的窗口內。在這里，可以根據 OEM 偏好使用各種 FVM 策略。由于 CAN 有效載荷長度有限，許多解決方案需要截斷的新鮮度值，這導致需要定期同步完整的新鮮度值。在 FVM 的響應之后，SecOC 將請求發(fā)送到加密服務管理器 （CSM） 以執(zhí)行加密功能以驗證 MAC。在將結果返回給 SecOC 之前，CSM 可能依賴軟件庫或 HSM 加密驅動程序來執(zhí)行這項工作。最后，如果驗證成功，則 SecOC 將 PDU 轉發(fā)到 PDU 路由器，或者引發(fā)錯誤標志并丟棄幀。這些任務對應的 CPU 工作量很大。

由于趨勢是消息和 CAN 通道的數量增加，CPU 開銷懲罰的問題只會變得更糟。為了滿足吞吐量需求，芯片供應商提供集成在硬件安全模塊 （HSM） 中的 AES 加速器。但經驗表明，負責處理數百條消息的身份驗證請求的中央 HSM 由于數據復制進出 HSM 的開銷而成為瓶頸。請注意，AES 引擎延遲僅占 HSM 執(zhí)行身份驗證所花費的總時間的一小部分。大部分延遲是由于作業(yè)設置、數據傳輸、作業(yè)調度、密鑰獲取和響應主機的軟件開銷造成的。隨著 CAN XL 的推出，它將支持高達 2048 字節(jié)長的有效載荷和高達 10Mbps 的波特率，對 HSM 的性能要求必然會變得更差。如果除了身份驗證之外還需要加密，那么將數據傳輸出 HSM 的額外開銷將進一步增加主機 CPU 傳輸或接收數據的總體延遲。顯然，今天的安全硬件和軟件架構是不夠的。

2. 威脅模型

CAN總線面臨許多威脅。此處的列表顯示了最令人擔憂的威脅：

欺騙：由于 CAN 總線的廣播特性，任何 CAN 節(jié)點都可以通過欺騙 CAN ID、DLC 和有效載荷來發(fā)送任何消息

嗅探和重放：由于 CAN 數據的開放性和豐富的 CAN 分析工具，CAN 幀可以很容易地被嗅探和重放，以使 ECU 執(zhí)行某些功能，例如解鎖門或應用中斷

否認：由于 CAN 總線的廣播特性，當傳輸惡意 CAN 幀時，無法證明哪個 ECU 負責發(fā)送虛假消息

資源耗盡：當使用 AUTOSAR SecOC 啟用消息身份驗證時，惡意攻擊者可以發(fā)送精心挑選的新鮮值，使接收者忙于驗證同一幀的真實性以耗盡 CPU 資源

拒絕服務：惡意 ECU 可以連續(xù)發(fā)送零 ID 消息，導致它們始終贏得仲裁并拒絕其他 ECU 在總線上成功傳輸。此外，不合格的 CAN 硬件可以通過破壞某些字段（例如插入填充位或修改物理層 CRC）來殺死特定的 CAN 幀，從而導致目標 ECU 進入 BusOff 狀態(tài)。

CANsec 可以解決除拒絕服務之外的所有上述威脅，拒絕服務需要額外的檢測和預防機制。

3. 安全 CAN 控制器

為了在降低 CPU 開銷的同時應對數據認證的吞吐量和帶寬不斷增長的需求，建議將 CANsec 層集成到 CAN 控制器中，以支持線速的認證和/或加密。

圖像

圖 3 CANsec 架構

在 ECU 啟動期間，車載通信密鑰從 HSM 安全存儲器緩存到 CAN 控制器專用 KEY RAM。此 RAM 只能由 HSM 通過專用總線訪問，以防止惡意 CPU 訪問。它也只能由 CAN 控制器內的 AES 引擎直接訪問。添加了額外的 CAN 寄存器以允許用戶為每個安全通道標識符 （SCI） 指定密鑰索引映射。類似地，為每個消息添加一個專用寄存器來存儲幀新鮮度值。后者必須在 ECU 關閉之前存儲到安全內存中，以確保在下一個引導周期同步。當接收到 CAN 傳輸請求時，CAN 控制器執(zhí)行以下序列：

根據 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 規(guī)范的早期版本，在 FPGA 中實現了原型 CANsec 實現。為了比較蘋果和蘋果，我們還在軟件中實現了 CANsec 協(xié)議。由于上述原因，不適合使用 SecOC。

該圖顯示了基于軟件的實現所需的 CPU 性能。處理時間與 Payload 數據量成正比，這是顯而易見的，因為更多的數據需要更多的時間來處理。預計 CANsec 軟件的 RX 延遲和 TX 延遲不會有不同的斜率。相反，模型應該具有幾乎相同的斜率。但是在 SW 中還有一個更大的步驟是為了發(fā)送幀而不是為了接收幀。這可能是軟件優(yōu)化的一個領域。但是，接收和發(fā)送的總體趨勢是相同的。

圖像

圖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 來消耗更少的芯片尺寸來實現進一步的優(yōu)化。

圖像

圖 5 CANsec 硬件延遲時間

5. 結論

CANsec 是一種實用的解決方案，可保護 CAN 總線免受 CAN 網絡面臨的最常見威脅，同時減少主機 CPU 開銷和對更大、更強大 HSM 的需求。將高速身份驗證/加密任務從 HSM 卸載到分布在外圍設備中的加密引擎可以減輕 CPU 負擔。通過以線速執(zhí)行身份驗證，它以最小的信號延遲為應用程序提供無縫的安全性。讓 HSM 控制密鑰緩存可以創(chuàng)建安全策略，以限制 ECU 在應用程序不再被視為受信任時發(fā)送安全消息的能力。

進一步表明，在硬件和軟件中實現 CANsec 是可行的。當然，在軟件中實現將具有與今天基于 SecOC 的實現相同的缺點。然而，軟件實現將允許在開始時平滑遷移該技術，當時并非所有控制器都支持 CANsec 的硬件實現。

審核編輯：郭婷