網(wǎng)絡安全與功能安全的智能聯(lián)合

在帶有嵌入式硬件安全模塊的 CPU 上運行的安全堆棧如今被認為是汽車網(wǎng)絡安全的核心。 因此，它們也是車輛功能安全的關鍵先決條件。 在最壞的情況下，針對網(wǎng)絡攻擊的安全保護不足的車輛系統(tǒng)最終可能會導致危及生命的情況。 ESCRYPT 解釋了為什么最好將硬件安全模塊及其安全功能直接集成到車輛的安全概念中。

基于硬件安全模塊 （HSM） 的微控制器和微處理器是當今許多汽車 ECU 的最先進技術。帶有硬件安全模塊的芯片現(xiàn)在被廣泛使用，特別是在車輛的眾多安全關鍵部件中，例如安全氣囊、電池管理系統(tǒng)、轉向系統(tǒng)和制動系統(tǒng)。因此，HSM 固件是功能安全的車輛系統(tǒng)的核心組件。

作為單獨的硬件組件連接到主機控制器，HSM 包括自己的處理器、加密功能以及用于硬件安全固件和安全數(shù)據(jù)的專用存儲器。HSM 固件為硬件添加了額外的安全功能，將這些功能捆綁到復雜的安全協(xié)議中，以支持專用的 OEM。即使在多核環(huán)境中，底層搶占式實時操作系統(tǒng)也能確保優(yōu)化的、優(yōu)先級驅動的資源利用率。所有功能都通過 API 接口提供給主機應用程序，從而確保 HSM 堆?？梢暂p松集成到引導加載程序或任何 Autosar 堆棧中——使用“復雜驅動程序”或通過 Autosar 加密驅動程序，隨附HSM 固件，如圖 1。HSM 核心和軟件構成了車輛系統(tǒng)的信任錨。硬件安全模塊成為系統(tǒng)可用于檢查真實性和完整性的一種基準，例如驗證車載網(wǎng)絡內的軟件更新或消息（安全車載通信，SecOC）。

HSM 的功能安全

雖然當今大多數(shù)汽車微控制器和微處理器都配備了此類硬件安全模塊，但實際上這些 HSM 中為功能安全而設計的很少。盡管硬件設計在很大程度上是在質量管理流程的基礎上進行的，但這很少是涵蓋可能的系統(tǒng)故障的符合 ISO-26262 的流程 ［1］。即使在過程符合 ISO-26262 的情況下，HSM 中也沒有針對偶發(fā)性故障實施單獨的保護，例如以硬件冗余或附加檢查器功能的形式。這似乎令人驚訝，但考慮到通常沒有直接分配給 HSM 本身的安全目標，這是完全有道理的。

由于上述硬件情況，HSM 固件的通用功能安全方法不是有用的解決方案。相反，需要深入考慮個別用例。HSM 包含在許多與安全相關的 ECU 中，在應用范圍內用于各種功能，包括防止操縱、初始化、軟件更新、診斷、車載通信和許多其他功能。因此，需要在 HSM 中進行特定于案例的實現(xiàn)。

安全與干擾共存

HSM 的典型用途是在集成環(huán)境中，它與執(zhí)行安全相關功能的軟件解決方案共存，分配的安全目標高達 ASIL D。因此，根據(jù)ISO 26262實現(xiàn)無干擾非常重要。這里通常的方法是使用芯片上可用的硬件功能來保護主機驅動程序和來自那些執(zhí)行安全關鍵功能的軟件模塊的共享資源，例如通過使用專用保護機制或內存保護單元 （MPU） 。

然而，這種影響深遠的基于硬件的劃分對系統(tǒng)來說不一定有用，因為在相互保護的兩個不同域之間交換數(shù)據(jù)和切換任務將不可避免地降低性能，潛在地導致的瓶頸會與其他運行時的要求產(chǎn)生沖突。更重要的是，這種硬件機制甚至可能不適用于為優(yōu)化整體系統(tǒng)成本而選擇的低成本設備。

HSM 固件作為上下文之外的安全元素

合格的 HSM 固件提供了針對此問題的優(yōu)雅解決方案，該固件包括根據(jù) ISO 26262 中指定的 ASIL 要求開發(fā)的主機驅動程序。這將允許 HSM 輕松集成到車輛 ECU 中，無需分區(qū)或內存保護，因此不會影響性能，如圖 2。

基于 HSM 本身不會在硬件方面執(zhí)行任何安全相關功能的假設，并考慮到上下文中固件最終將被多方面且未知地使用，它被設計為上下文之外的安全元素（ SEooC） ［1］。與此同時，必須在系統(tǒng)層面采取措施確保固件安全集成，換句話說，以可靠的方式防止硬件安全模塊與其安全相關功能的主機內核之間的干擾。理想情況下，應為 HSM 固件提供專門的安全手冊，其中包含關于如何在集成 SEooC 時確保不受干擾的說明。

使用安全的CMAC降低風險

一般來說，需要進行徹底的安全分析，以識別系統(tǒng)中的威脅和漏洞，并設計適當?shù)膶Σ?。通過將網(wǎng)絡安全方面納入功能安全評估，可以從功能安全的角度進行知情風險評估，并據(jù)此確定安全完整性水平（SIL），如圖3。但是，上述無干擾共存可能不會，對于某些系統(tǒng)設計和特定功能，即網(wǎng)絡安全機制中的故障產(chǎn)生安全關鍵的影響［2］。例如，如果ECU之間交換的車載通信消息和信號與安全相關，則會出現(xiàn)這種情況。如果此類信息已損壞但仍被轉發(fā)，則可能導致具有嚴重后果的危險情況，例如錯誤的制動信號或錯誤的轉向角。

因此，Autosar為交換安全相關數(shù)據(jù)指定了端到端（E2E）保護。E2E概念在運行期間檢測并處理通信網(wǎng)絡中硬件和軟件端的故障。因此，該概念適用于ASIL D之前的安全兼容通信。然而，與此同時，還有一些新的、更智能的系統(tǒng)設計實現(xiàn)方法，它們補充了E2E方法，同時設法避免其造成的開銷。其中一種新穎的補充方法是安全CMAC，它使用基于密碼的消息認證碼（CMAC）保護安全關鍵消息。

滿足ASIL D的基于HSM的安全機制

事實上，車內網(wǎng)絡中的每條消息通常都包含一個CMAC，該CMAC被路由到硬件安全模塊以驗證消息的真實性。然而，同樣的是這種MAC身份驗證也可以用作檢測損壞消息的功能安全措施。然而，HSM中的單點故障，例如隨機HSM硬件故障，可能導致違反ASIL D規(guī)定的ECU安全目標，即避免轉發(fā)非真實消息的要求。

因此，對于HSM，有必要定義一個額外的安全要求，即不驗證任何虛假MAC是否正確；這適用于所有安全相關信息，無論有多少。根據(jù)使用情況，安全相關消息的數(shù)量將從每個驅動循環(huán)的單個消息和軟件更新到100%的消息不等。另一方面，如果對所有消息（包括非安全相關消息）實施基于HSM的此類安全機制，這只會導致不必要的開銷。因此，特定于用例的實施概念再次需要智能HSM固件，該固件提供了多個選項，用于在需要時集成基于CMAC的車輛系統(tǒng)功能安全。

可能的安全機制之一是基于應用程序啟動的錯誤MAC自檢。系統(tǒng)集成商必須確保執(zhí)行和評估測試本身以及進入安全狀態(tài)所需的時間滿足要求的故障處理時間間隔（FHTI），即故障檢測時間間隔（FDTI）和故障反應時間間隔（FRTI）的總和。此解決方案最多可用于ASIL B。另一種安全機制基于循環(huán)冗余校驗（CRC），并應用于每個與安全相關的MAC驗證。集成到HSM固件的性能優(yōu)化批量CMAC接口中，可最大限度地減少因附加CRC計算和比較功能而導致的目標與時間的權衡，尤其是在設備硬件支持CRC的情況下。此解決方案最多可用于ASIL D。

關鍵系統(tǒng)功能安全的工具化

智能的成本和性能優(yōu)化安全概念可以將功能安全目標委托給硬件安全模塊。與其采取一般方法，不如對照整個系統(tǒng)的安全目標檢查每個單獨的用例，以得出硬件安全模塊的特定功能安全要求。這方面的基本先決條件是具有相應功能安全包的適當復雜的HSM固件，該軟件包可以涵蓋ASIL D之前的用例，具體取決于每個用例中的目標和上下文。但是，這必須始終符合以下條件：HSM中定義的安全措施與主機側的適當功能安全措施相伴隨。

最新一代設備中使用的硬件已經(jīng)具有增強的安全機制和性能。盡管如此，對提供更高性能的成本優(yōu)化系統(tǒng)設計的需求仍然存在。在這方面，一個開創(chuàng)性的解決方案似乎是將網(wǎng)絡安全機制工具化通過使用智能HSM固件實現(xiàn)硬件安全模塊的安全性，以確保關鍵車內系統(tǒng)的功能安全。

原文標題：網(wǎng)絡安全與功能安全的智能聯(lián)合

文章出處：【微信公眾號：ETAS易特馳】歡迎添加關注！文章轉載請注明出處。
責任編輯:pj