1. 動(dòng)機(jī)

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

圖像

圖 1 Autosar 中的 SecOC 流程

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

圖像

圖 2 Autosar 分層架構(gòu)中的 SecOC BSW

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

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

2. 威脅模型

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

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

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

否認(rèn)：由于 CAN 總線的廣播特性，當(dāng)傳輸惡意 CAN 幀時(shí)，無法證明哪個(gè) ECU 負(fù)責(zé)發(fā)送虛假消息

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

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

CANsec 可以解決除拒絕服務(wù)之外的所有上述威脅，拒絕服務(wù)需要額外的檢測(cè)和預(yù)防機(jī)制。

3. 安全 CAN 控制器

為了在降低 CPU 開銷的同時(shí)應(yīng)對(duì)數(shù)據(jù)認(rèn)證的吞吐量和帶寬不斷增長的需求，建議將 CANsec 層集成到 CAN 控制器中，以支持線速的認(rèn)證和/或加密。

圖像

圖 3 CANsec 架構(gòu)

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

根據(jù) SCI 的密鑰索引獲取密鑰明文值并加載到 AES 引擎中

獲取新鮮度值并將其增加 1

輸入 CAN ID | 下載內(nèi)容 | CAN 負(fù)載 | Freshness Value， Payload Type， 進(jìn)入 AES 引擎生成完整性校驗(yàn)值 （ICV）

當(dāng)幀以線速傳輸時(shí)，將 CANsec 標(biāo)頭（新鮮度值）和 ICV 插入有效負(fù)載

在接收期間，將遵循類似的過程，并附加將接收到的新鮮度值和 ICV 與預(yù)期值進(jìn)行比較的步驟。為了檢查新鮮度，將接收到的值與存儲(chǔ)的新鮮度值加上預(yù)配置的接受窗口進(jìn)行比較。這對(duì)于允許可能不同步的 ECU 重新同步到接收到的新鮮度值是必要的，而無需復(fù)雜的新鮮度值管理策略。如果 Freshness 和 ICV 值都符合預(yù)期，CAN 控制器會(huì)使用接收到的值更新 Freshness Value 寄存器并設(shè)置接收標(biāo)志以讓應(yīng)用程序處理數(shù)據(jù)。否則，它會(huì)設(shè)置錯(cuò)誤標(biāo)志以通知主機(jī) CPU 接收到幀但數(shù)據(jù)無效。

4. 概念證明

瑞薩電子進(jìn)行了一項(xiàng)可行性研究，以證明實(shí)施 CANsec 概念是有意義的。基于 CiA 613-2 CANsec 規(guī)范的早期版本，在 FPGA 中實(shí)現(xiàn)了原型 CANsec 實(shí)現(xiàn)。為了比較蘋果和蘋果，我們還在軟件中實(shí)現(xiàn)了 CANsec 協(xié)議。由于上述原因，不適合使用 SecOC。

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

圖像

圖4 CANsec CPU處理時(shí)間

該軟件在 1.2GHz 的 R-Car H3 SoC 的 ARM 內(nèi)核上運(yùn)行。如果這個(gè)數(shù)據(jù)會(huì)被分解到一個(gè) 400MHz 的 MCU；那么在 100% 的總線負(fù)載下，CPU 將被占用 25%（@252byte 有效負(fù)載）。這是一項(xiàng)相當(dāng)大的工作，考慮到這樣的 MCU 有多個(gè) CAN-XL 通道，那么 CPU 很快就會(huì)過載。因此，將其實(shí)現(xiàn)為 CAN-XL IP 中的硬件加速功能是有意義的。

下圖顯示了硬件實(shí)現(xiàn)的處理延遲。CANsec 模塊在 CAN 控制器的數(shù)據(jù)路徑中實(shí)現(xiàn)。為此，延遲必須比 CAN 總線上的 CAN-XL 幀處理時(shí)間短，以確保以線速進(jìn)行處理。在我們的原型實(shí)現(xiàn)中，CANsec 模塊的時(shí)鐘頻率為 80MHz，并使用 16 個(gè) S-Box 進(jìn)行 AES 算法，通過這種設(shè)置，我們得到的值遠(yuǎn)低于 CAN 總線上消息的占用時(shí)間。例如，可以通過使用更少的 S-Box 來消耗更少的芯片尺寸來實(shí)現(xiàn)進(jìn)一步的優(yōu)化。

圖像

圖 5 CANsec 硬件延遲時(shí)間

5. 結(jié)論

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

進(jìn)一步表明，在硬件和軟件中實(shí)現(xiàn) CANsec 是可行的。當(dāng)然，在軟件中實(shí)現(xiàn)將具有與今天基于 SecOC 的實(shí)現(xiàn)相同的缺點(diǎn)。然而，軟件實(shí)現(xiàn)將允許在開始時(shí)平滑遷移該技術(shù)，當(dāng)時(shí)并非所有控制器都支持 CANsec 的硬件實(shí)現(xiàn)。

審核編輯：郭婷