摘要

網絡安全已成為汽車行業的一個關鍵挑戰。在現階段，ISO/SAE 21434描述的框架不足以導出供應商級別安全汽車網絡嵌入式系統設計的具體方法。本文介紹了一個案例研究，其中包含設計安全系統的可操作步驟，并系統地提出了可追溯的網絡安全需求，以彌補這一差距。該案例研究與ISO/SAE 21434標準相一致，可為將網絡安全工程集成到公司特定流程和實踐規范中提供基礎。

01.簡介

車輛正在從孤立的、主要是電子機械系統變為帶輪子的互聯計算機。這一趨勢是由汽車行業希望提供創新的移動服務以及向部分和完全自動化車輛的進一步發展所驅動。這些目標很可能只有通過合作和自動化車輛才能實現。然而，為了實現安全、自動化和互動的車輛，需要進一步改進網絡安全。

最近的評估和披露表明，在當前車輛中幾乎所有連接元素都存在多個漏洞，以下例子可以說明這一點：如今，汽車制造商充當本地互聯網注冊機構(LIR)并維護IP地址、證書和證書管理系統集群，以確保車隊中的車輛能安全遠程訪問外部基礎設施和服務。為此，現代車輛使用基于Linux的網關服務器來實現對外部服務的遠程訪問。每輛車的網關服務器在生產線末端(EOL)生產過程中都配置有單獨的密鑰材料和證書。除了網關服務器，車輛還提供各種其他協議來訪問車載功能，例如車載診斷(OBD)接口和服務、WLAN、藍牙和專用Vehicle2X通信協議。這些連接功能擴大了現代車輛的攻擊面，使它們容易受到外部攻擊。

圖1：針對聯網車輛的多層遠程網絡安全攻擊示例

圖1展示了一次成功對市場上出售的車輛上進行的的遠程網絡安全攻擊。在這種多層攻擊中，通過利用遠程接口中的漏洞來獲得車輛車載功能的訪問權限，最終導致不必要的車輛轉向。所描述的攻擊包括以下步驟：

1）信息泄露：在第一步中，攻擊者使用相同型號的車型進行攻擊準備。通過OBD接口嗅探車輛總線消息，攻擊者可以了解總線通信的細節（即消息目錄的部分內容）。此外，還可以識別車輛制造商使用的IP地址集群。為了進行后續攻擊，通過嗅探目標車輛與車主智能手機之間的通信，可以獲得受攻擊車輛的具體IP地址。

2）權限提升：在下一步中，利用Linux網關防火墻的已知漏洞來獲取root權限，從而使攻擊者能夠訪問車輛的內部網絡。在此階段，可以使用網關從遠程設備向車輛內部網絡發送惡意命令，并在網關上部署惡意軟件。

3）仿冒攻擊：在最后一步中，通過執行先前部署在網關上的腳本對車輛進行攻擊。該腳本向車輛內部網絡發送包含惡意但適當組裝的轉向控制命令和車速信息的消息。消息結構在第一步攻擊中被識別，并且現在用于所謂的仿冒攻擊，以模擬其他總線參與者的行為/消息。在具體示例中，模擬的車速信息（即車輛以低于5km/h的速度行駛）欺騙了轉向控制單元（SCU）接受來自停車輔助控制單元（PACU）的轉向命令，即使在高速行駛的情況下。最后，使攻擊者能夠遠程操控車輛。

1.1 問題陳述

如今，只有少數網關服務器開發公司與原始設備制造商（OEM）密切合作，共同設計車輛的電氣/電子（E/E）架構和車隊安全服務架構（SSA）。因此，大多數汽車開發仍然與交付電子控制的網絡嵌入式車輛功能有關，這些功能實現了例如車輛轉向、加速和制動等。

這些功能需要以安全的方式集成到SSA和E/E架構中，以緩解新出現的安全威脅。因此，網絡安全正成為汽車工業成功的基石，與可靠性和安全性并列。這一事實反映在最近的網絡安全法規中，這些法規要求在將車型引入市場時提供網絡安全證明（即聯合國歐洲經濟委員會（UNECE）批準，特別是UNECE WP.29/R155和UNECE WP.29/R.156）。

在這方面，汽車行業已經利用其他行業的經驗，在發展和實施安全連接車輛方面取得了進展。然而，該行業仍面臨幾個特定的挑戰。因此，迫切需要制定行業標準，以解決網絡安全工程的問題，保護現代互聯車輛和移動基礎設施免受網絡攻擊。

雖然這些標準沒有提供關于網絡安全開發和實施的細節，但它們提供了一個提供一般指導的框架。而道路車輛網絡安全工程標準ISO/SAE 21434是在認識到網絡安全過程活動的大部分缺乏成熟的最新技術的基礎上制定的。因此，標準中只能給出一個框架。這個框架未來需要補充完善，以提供具體指導，建立一個安全的開發過程。

1.2 目的

本文旨在提出與汽車領域標準和適用于電子控制網絡車輛功能安全設計的法規相一致的可操作步驟和方法。這些步驟應補充這些標準，并為工程師提供有關開發安全車輛功能的實用指導。本工作的重點是工程方面，包括風險驅動的系統設計和系統性的引出需求，以解決汽車開發工作流程不同階段識別出的網絡安全風險。涉及的工作流程步驟包括系統和架構設計階段、硬件/軟件設計階段以及硬件/軟件詳細設計階段，如圖2所示。案例研究旨在展示如何應用安全驅動的分析方法來創建必要的證據（即工作產品），以引出由堅實的基于證據的和標準一致的論證支持的網絡安全需求。

圖2：網絡安全開發工作流程和支持工作產品

1.3 案例研究

該案例研究聚焦于負責控制車輛轉向的轉向控制單元(SCU)的開發。在圖3中，SCU被突出顯示，該圖例說明了典型汽車一級供應商項目的范圍，該項目針對特定車輛功能的開發。從安全角度來看，SCU應被設計為安全地集成到給定的E/E架構中。

如圖3所示，正如第1節開頭所介紹的，現代網聯車輛使用網關服務器來建立與例如路邊基礎設施和其他車輛的遠程連接。當今的車輛E/E架構將車載通信網絡分成不同的子網域，以將安全關鍵的網絡車輛功能與次要或非關鍵的娛樂和通信功能分開。然而，為了確保整車的正常運行，負責控制和協調整車行為的各個電子控制單元(ECU)必須互連。為此，網關服務器和子網域控制器通過實時以太網、CAN FD或兩者互連。特定網絡域內的各個ECU仍然依賴CAN FD通信，以保證較短的啟動時間和毫秒級時間框架內的實時控制。

圖3：典型供應商集成到安全服務架構(SSA)中

將不同的網絡域進行清晰劃分，為防御網絡攻擊提供了額外的防護層。這也允許使用已經建立的汽車開發流程和工具，來工程化安全關鍵的電子控制車輛功能。然而，在汽車領域內，尚無確立的最佳實踐指南或安全工程流程與安全系統設計。因此，汽車供應商必須調整其開發生命周期，以將網絡安全工程方面集成到其流程環境中。

在本工作的剩余部分，將描述提出的安全驅動工程步驟和方法，以進行此類適應。這些步驟和方法符合ISO/SAE 21434標準。該標準要求的主要規范活動包括項目定義以及威脅分析和風險評估（TARA）。

圖4顯示了電動助力轉向系統的項目定義，它定義了項目范圍和案例研究范圍。此外，它在概念層面描述了正在開發的系統（SUD）的系統組件以及內部和外部接口。從安全角度來看，項目定義可以支持系統識別關鍵資產。根據ISO/SAE 21434，資產被定義為SUD的一個元素，其網絡安全屬性的妥協可能會損害項目的利益相關者，即受損害影響的個人或組織。因此，項目定義中的元素通常被識別為需要保護的資產，因為對它們的成功攻擊通常會顯著影響車輛的功能性、安全性或網絡安全。

圖4：轉向控制單元（SCU）的項目定義

案例研究的示例基于兩個并聯運行的三相電機，每個電機都安裝在轉向架上。兩個主/從處理單元用于控制三相電機，這兩個單元都根據ASIL D（汽車安全完整性級別）的約束進行開發。這些處理單元連接到車輛總線，用于與其他ECU交換信息。給定項目定義中的網絡安全關鍵系統資產標記為Axx，并被分組。呈現的系統架構旨在滿足現代高度自動化車輛的安全和故障運行要求。

02.系統級網絡安全工程

網絡安全工程中的一般策略與每個可訪問的系統接口都會增加潛在攻擊面這一事實有關。因此，對系統接口及其相關的網絡安全威脅的更好理解，越能適當地處理網絡安全風險，并在受到攻擊時保護系統。此外，從接口級別開始分析潛在的攻擊路徑有助于理解和評估對利益相關者的風險和攻擊影響。

2.1 TARA準備

威脅分析和風險評估(TARA)的目標是識別SUD的潛在網絡安全威脅，以及對識別威脅相關的風險進行后續評估。在進行TARA之前，應執行一些預分析步驟，包括：(a)上一節中描述的網絡安全項定義，(b)關鍵功能塊分析的衍生信息，該分析描述主要系統功能，(c)對正在使用的技術堆棧分析，詳細說明了實現特定網絡安全機制的硬件和軟件構建模塊，以及(d)威脅建模，以表示每個網絡（物理）系統固有的對抗性網絡威脅。

這些預分析步驟有助于更全面地了解系統、其潛在的攻擊接口，以及攻擊者可能需要達成其目標的所需知識和技術技能。此外，可以更適當地詳細闡述系統資產及與網絡安全相關的風險，這也有助于正確定義網絡安全目標和選擇緩解措施。

簡而言之，在進行TARA之前，首先應使用（半）結構化方法（a）至（d）來識別系統資產。下面解釋這些方法的結果。

圖5顯示了通過網絡安全項定義、關鍵功能分析和技術棧分析識別的資產摘錄。得出的系統級資產清單包括，例如接口、固件、配置數據、加密密鑰材料、功能塊、傳感器和執行器等。資產分析是后續TARA的主要輸入。

圖5：資產清單摘錄

系統級威脅模型（0級威脅模型）有助于開發SUD固有的對抗性威脅的表示。因此，系統級威脅模型是結構化和指導資產識別過程的寶貴工具。此外，威脅模型促進了與模型中每個元素相關的潛在威脅的系統性（和自動化）推導。因此，目的是開發系統級威脅模型，以表示在之前的頭腦風暴等步驟中識別的系統級資產（例如，數據存儲、數據流、服務、人員和功能），并添加缺失的元素/資產。

SCU的系統級威脅模型如圖6所示。它反映了項目定義的系統結構，包括先前識別的資產組。所描述的威脅模型基于STRIDE方法，并且僅允許有限的一組模型元素，這減少了模型復雜性，并能夠自動推導與代表潛在系統資產的每個模型元素相關的威脅。

圖6：轉向控制系統0級威脅模型

STRIDE方法最初用于IT系統威脅分析，現已用于汽車應用。表1概述了STRIDE威脅、受特定威脅影響的網絡安全特性，以及每個威脅組的汽車特定示例。使用STRIDE方法，可以（自動）識別適用于系統級威脅模型中包含的特定元素/資產的威脅。與每種威脅相關的風險在隨后的TARA中進行分析。

表1：STRIDE威脅及其受影響的安全屬性

2.2 TARA執行

威脅分析和風險評估(TARA)應基于已識別的資產和相關威脅進行。應使用模式對威脅進行分類，并對威脅風險進行適當地估計和分類。由于ISO/SAE 21434沒有提供風險評估的規范性分類方案，因此可以采用Heavens或SAHARA等方法。在這項工作中，TARA步驟是基于Heavens方法的。TARA執行的各個步驟和工作產品如圖7至圖11所示。

圖7顯示了資產描述的摘錄、適用于資產的STRIDE威脅以及特定威脅場景的描述。對于每項資產，可能適用多種STRIDE威脅。合理的威脅場景應從系統級威脅模型中得出，并針對每個適用的威脅進行描述。

在圖7所示的特定示例中，ADAS域控制器通過車輛總線傳輸的轉向角請求描述了要分析的資產。該資產在圖6中建模為數據流元素，是資產組A01的一部分。根據STRIDE方法，以下三種威脅適用于數據流（即要分析的資產）：篡改、信息泄露和拒絕服務(TID)。圖7描述了兩種威脅場景，一種用于篡改威脅，另一種用于信息泄露威脅。一般來說，威脅場景描述不應包含預期攻擊的（技術）細節。相反，威脅場景應是對預期威脅的高級描述，應使用創建的威脅模型檢查其合理性。

圖7：威脅場景描述

應針對利益相關者的特定威脅情景的影響（即影響級別（IL））以及成功攻擊的可能性（即威脅級別（TL））應對每個威脅情景進行估算。這兩個獲得的評級合并為一個風險值（即安全級別 (SecL)），用于對特定威脅場景及其關聯的資產（即與特定資產和威脅對相關的風險）進行分類。

為了適當估算特定威脅場景對利益相關者的影響，建議定義潛在的損害場景，描述對系統的預期損害以及對利益相關者的影響。示例如圖8所示。

圖 8：影響分析的潛在損害場景描述

Heavens方法使用四個分類參數來估算不同利益相關者的損壞場景的影響和預期損失：(a)對系統安全的影響，(b)財務影響，(c)對車輛運行/行為/功能的影響，以及(d)隱私和立法影響。這些影響使用從“無影響”到“高影響”的定性等級進行評估，然后合并為最終影響級別評級。圖9顯示了“意外轉向/車輛行為”損壞場景的示例分類（包括理由）。

圖9：損壞場景影響級別的分類

一般來說，已識別的損害場景可以映射到多個資產/威脅對及其相關的威脅場景。損壞/影響分析僅考慮最嚴重的損壞情況。因此，將最高影響級別評級分配給特定的威脅場景，如圖10所示。

圖10：潛在損害場景與威脅場景的鏈接

除了影響等級外，還應估計成功攻擊的可能性，這由威脅級別（TL）評級表示。該評級基于以下四個參數的估計：(a)攻擊者所需的專業知識，(b)攻擊者對目標系統的知識，(c)給定的發動攻擊的機會窗口，以及 (d)發起攻擊所需的設備和工具。系統級威脅模型應作為支持工具，用于估計和證明威脅等級分類。

圖11：威脅級別評級的分類以及由此產生的安全級別

圖11的左側部分顯示了與ADAS轉向角請求消息（即資產）相關的篡改威脅的威脅等級評定及其理由。圖11的右側部分顯示了安全等級評定的結果，這是威脅級別和影響級別的組合。安全級別評級描述了與給定資產/威脅對相關的網絡安全風險。對于每種適用的威脅，應定義一個網絡安全目標。該網絡安全目標定義了為降低已識別威脅的風險而應實施的高級網絡安全屬性。安全級別和網絡安全目標的配對，可視為與汽車安全工程中已知的ASIL評級和安全目標配對類似的概念。

網絡安全目標可以轉化為旨在通過預防潛在威脅的利用來降低網絡安全風險的高級網絡安全要求。應注意的是，對多個資產/威脅對的評估可能會導致定義類似的網絡安全目標。從這些網絡安全目標衍生的網絡安全需求，應繼承與這些網絡安全目標相關的最高確定的網絡安全級別。

03.網絡安全需求獲取和可追溯性

網絡安全需求源自網絡安全目標和客戶需求，例如寶馬集團標準GS 95014或大眾KGAS標準對網絡安全（和功能安全）工程的需求。這些需求可以包括功能性和非功能性需求，也可以與特定的開發流程相關聯，例如以確保與汽車（網絡安全）標準的合規性。這些需求應整合到項目的需求管理系統中，作為網絡安全客戶需求。

TARA中識別的網絡安全目標是在項目開始時特別重要的，用于在客戶和供應商之間建立網絡安全的共同理解。因此，網絡安全目標應與客戶和隨后的管理層一致，就像客戶需求一樣。為了確保需求和設計決策之間的可追溯性，網絡安全客戶需求應與網絡安全目標和用于支持TARA流程的中間工作產品相關聯。在符合ASPICE的開發過程中，通常會使用需求規范模板。該模板應擴展為包括相關的網絡安全屬性，例如網絡安全目標標識符和安全級別。這些屬性可以支持優先考慮網絡安全相關的開發活動，并可用于展示網絡安全要求的覆蓋范圍，例如在認證評估期間。

圖12舉例說明了鏈接/可追溯性模型。該模型顯示了系統分析期間創建的工作產品與從分析結果（即工作產品）衍生的需求之間的追溯鏈接。綠色圓圈中的數字表示網絡安全工程工作流程步驟。紅線表示步驟之間的鏈接和可追溯性標識符。前四個步驟在第2節中進行說明。其余步驟將在下面進行說明。在此之前，給出了需求提出工作流程步驟的總結：

1）應使用頭腦風暴和系統建模來識別資產，如第2.1節所述。

2）應使用威脅建模技術來識別和分析資產威脅。此外，應評估與這些威脅相關的風險，如第2.1節和第2.2節所述。

3）網絡安全目標應源自TARA（即步驟1和2），如第2.2節所述。

4）應從網絡安全目標和客戶的需求規范中衍生客戶網絡安全需求，如第3節所述。

5）網絡安全客戶需求應細化/轉化為（技術）網絡安全系統需求。

6）應識別影響系統網絡安全的硬件/軟件功能（例如，從總線發送/接收數據、加密算法）。這些功能隨后被稱為安全關鍵功能（SCF）。

7）每個功能的目的是處理信息/數據。假設SCF處理的信息/數據影響系統網絡安全，例如加密材料、配置數據和總線消息。在這種情況下，該信息/數據應被視為安全關鍵數據/信息(SCD)并鏈接到正在處理SCD的SCF。

8）每個SCD應與處理SCD的SCF互相關聯，反之亦然。

9）應將網絡安全目標分配給SCF和SCD元素。通過將分配的網絡安全目標，與由TARA過程中識別的網絡安全目標確定的SUD網絡安全屬性進行比較，可以用于識別系統及其設計中的弱點。識別的弱點應推動系統設計的改進和硬件/軟件需求的提出。

10）應識別和整合適當的安全設計模式和緩解技術到系統設計中，以解決已識別的弱點。這些模式和技術應記錄為硬件/軟件需求，并與應實施特定模式所實現的網絡安全屬性的相應SCD和SCF元素相關聯。

11）攻擊模式描述了已知網絡安全攻擊中使用的策略和技術。這些攻擊模式可用于支持適當設計模式和緩解技術的衍生，以防止已知攻擊。

12）網絡安全設計模式和攻擊模式，可用于基于針對SUD及其實施的緩解技術的已知攻擊和漏洞的系統性安全測試衍生。

圖12：鏈接/可追溯性模型，包括網絡安全需求和網絡安全分析的工作產品

在接下來的內容中，我們繼續探討SCU示例中的工作流程步驟5，即將網絡安全客戶需求細化為（技術）網絡安全系統需求。在此階段，已經定義了網絡安全目標并將其與資產相關聯。此外，這些目標已作為網絡安全客戶需求整合到需求管理系統中。這些步驟與表2中第1到4項相關，表2提供了相關工作產品和需求的摘錄。

在給出的示例中，ADAS轉向角請求被歸類為高風險資產。定義高級安全目標SecG_01來應對這一風險。接下來，安全目標被分解為兩個客戶需求及其對應的系統需求Sys_01和Sys_02。按照工作流程步驟7至10，接下來應識別SCF和SCD元素。SCF和SCD元素旨在支持系統分析和需求獲取過程。因此，這些元素不一定是描述特定機制實現的需求。相反，這些元素也可以是高級概念、功能、技術和信息，可用于構建設計決策的結構化論證。基于此類論證，應開發（詳細的）硬件/軟件設計，并得出相應的需求，即步驟9和10。這些步驟將在以下段落中更明確地解釋。

表2指出從車輛總線讀取消息被識別為安全關鍵功能SCF_01。為了滿足Sys_01，必須以安全的方式認證關鍵車輛總線消息，這導致定義了軟件需求SW_Req_01，即應使用標準AUTOSAR接口進行消息認證。此外，還定義了硬件需求一和二，以確保在硬件級別上適當支持加密算法（例如，安全消息認證算法）的實現。

采用類似的方法來衍生出實施系統需求Sys_02的硬件/軟件需求，該需求規定車輛總線消息應安全地記錄，以確保不可否認性（即SCF_02）。為此，每個車輛總線消息（即SCD_01）被嵌入到日志條目中（即SCD_02），應寫入內存中的先進先出（FIFO）隊列（即SW_Req_02）。這個FIFO隊列只應在每次系統關閉時存儲到安全閃存中，以防止由于頻繁使用而導致閃存的損壞（即SW_Req_03）。為了確保即使在惡劣條件下（例如斷電），FIFO隊列的內容也被寫入閃存，硬件安全模塊（HSM）應提供加速寫入閃存的硬件支持（即HW_Req_03）。

表2：相關分析結果和需求示例。通過下劃線突出顯示要實現的網絡安全屬性

上述示例旨在展示如何使用上述定義的工作流程來構建可追溯的論證來支持設計決策，并以結構化的方式提出相關需求。工作流程步驟9至12旨在通過提供識別設計弱點和選擇適當的網絡安全措施和技術來解決這些弱點的指導，以支持需求提出過程，從而滿足所需的系統網絡安全屬性（即安全目標）。

為了識別設計弱點（即步驟9），首先應識別當前系統設計提供的網絡安全屬性，并將其分配給SCF和SCD元素。建議使用系統和威脅模型來識別這些屬性。其次，網絡安全目標（即所需的系統網絡安全屬性）應分配給SCF和SCD要素。比較分配的所需和提供的屬性，以識別系統設計中的差距/弱點。

到目前為止，已經討論了如何使用網絡安全屬性來系統地和可追溯地識別設計缺陷。在步驟10中，網絡安全屬性用于通過基于系統應滿足的網絡安全屬性系統地選擇安全設計模式來提高系統安全性。這種方法中選擇模式來實現特定的網絡安全屬性。表3顯示了這樣的安全設計模式（即高級安全控制）的摘錄，這些模式可用于在特定系統級別上實現特定的網絡安全屬性。其中一些安全控制已在上文中討論，例如控制流完整性（即Sys_01和相關需求）、安全存儲和靜態數據加密（即Sys_02和相關需求）。

綜上所述，通過選擇合適的安全設計模式和緩解機制，可以提高SUD的安全性。此外，這些模式可以支持以結構化和可追溯的方式引導合適的的硬件/軟件安全需求和安全測試場景的提出（參見圖12）。

表3：適用于各個系統級別的安全設計模式和安全控制示例

04.硬件和軟件網絡安全前景

上一節討論了系統網絡安全系統和需求工程的流程，其中包括衍生適當的網絡安全控制措施以滿足特定的網絡安全目標。本節簡要討論如何將網絡安全控制（例如表3中提供的控制措施）整合到通常用于汽車嵌入式系統的典型AUTOSAR的基礎系統棧中。

圖13顯示了這樣的系統堆棧，它被結構化為多個層次。底層由用于代碼執行、數據存儲和連接的硬件元件組成。硬件安全模塊（HSM）也位于此層。HSM提供硬件支持用于安全地存儲和訪問私鑰材料，這對于充分實現各種高級安全控制至關重要。此外，HSM還可能提供硬件加速的加密算法，即使需要對毫秒和亞毫秒范圍內安全保護循環通信，也能滿足汽車網絡系統的嚴格實時要求。

圖13：基于AUTOSAR的分層硬件/軟件堆棧

與其他硬件組件一樣，HSM可以通過位于微控制器抽象層(MCAL)的驅動程序集成到軟件堆棧中。在圖13中，該驅動程序表示為虛擬HSM(vHSM)。假設沒有專用的硬件HSM，HSM功能可以通過軟件模擬。因此，vHSM可以將服務請求轉發到位于復雜驅動程序層的基于軟件的HSM實現。值得注意的是，基于軟件的HSM方法不如使用專用HSM安全。

應用程序（例如app1）可以通過運行時環境(RTE)層訪問HSM的專用加密服務，RTE指定了與加密服務管理器（CSM）的接口。RTE將應用程序的服務請求轉發到位于AUTOSAR核心操作系統(OS)層的系統服務和CSM。除了通過RTE直接訪問HSM之外，還可以配置位于AUTOSAR OS層的通信服務，以管理HSM服務的使用，以建立安全的車載通信(SecOC)會話。在這種情況下，SecOC服務被配置為檢查和確保特定消息的真實性，使基于HSM的安全機制對應用層透明。

除了HSM之外，還利用幾個其他組件和安全控制來確保系統安全。例如，實施安全啟動過程應確保整個軟件系統的完整性，包括系統固件和持久數據。為此目的，在EoL生產過程中可以建立所謂的信任錨（另請參見第1節），例如通過將主引導程序的公鑰哈希(PKH)存儲在微控制器的OTP熔絲內。每次系統啟動時，微控制器首先使用PKH來驗證引導加載程序的完整性。只有在可以驗證引導加載程序的完整性（即引導程序未被篡改）時，引導過程才會繼續。在隨后的啟動階段，可以通過檢查固件和數據的簽名的有效性來驗證它們，例如使用EoL生產過程中存儲在HSM內的密鑰材料。

05.結論

目前，將網絡安全集成到汽車行業的開發流程中仍處于早期階段，尚無普遍接受的最新技術。ISO/SAE 21434標準是朝這個方向邁出的重要一步。然而，在現階段，ISO/SAE 21434僅提供了關于如何設計此類開發流程的粗略指導。因此，本文旨在提供可操作的步驟和方法，幫助工程師將安全系統設計技術和系統性網絡安全需求提出方法集成到他們已建立的開發流程中。本工作使用案例研究來演示在電動助力轉向系統示例中應用所提出的步驟和方法。所呈現的案例研究和工作流程是根據實際專家知識和前期研究結果結合汽車系統工程領域的需求而衍生出來的。我們未來的工作包括在更多項目中驗證和完善所呈現的方法，并將結果和見解反饋給不同的標準化工作組中。此外，我們旨在開發一個通用的安全驅動開發生命周期模型，用于當前和未來汽車電子系統和架構的開發。