本站小編為你精心準備了符合功能安全與網絡安全要求的E2E通訊參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

[摘要]  隨著R155、R156、ISO 21434等汽車領域的網絡安全要求的法規和標準的，要求產品既符合功能安全標準，又符合網絡安全標準。本文從安全設計流程出發，以通訊通道的安全保護為例，介紹符合標準要求的研發過程及安全設計措施。

 [關鍵詞]  智能網聯汽車  網絡安全  功能安全  ISO 26262   ISO 21434  

一、安全體系的融合 

在產品研發前，首先要建立符合《ISO 26262  道路車輛功能安全》和《ISO/SAE 21434 道路車輛網絡安全》的文化和管理流程體系。  在安全文化方面，網絡安全與功能安全的要求相似，企業應建立、培養和保持有力的安全文化，確保“支持和保證安全活動”保質保量實施。良好的文化，不僅體現在企業口號和員工安全意識上，更體現在公司級的安全手冊和研發流程上。  這兩類安全管理體系都包含公司級或全局級、項目級的安全管理。實施時，需在質量管理的基礎上，將這兩類安全管理體系進行有效地融合。建立起涵蓋概念階段、研發階段、生產運行及報廢等階段，全生命周期的管理手冊、流程、指南、模板、檢查列表等一系列可指導實施，可持續改進的工作輸出物，為具體項目實施打下堅實基礎。

二、概念階段 

在概念階段，首先要進行相關項的定義，定義出相關項的功能及非功能的需求、邊界、約束條件以及運行環境等信息。根據定義的相關項，先進行功能安全的危害分析和風險評估（Hazard Analysisand Risk Assessment）[1]，通過各種定義的功能與多種失效或故障關鍵字的組合產生的整車級危害表現，與各種場景進行組合，從而導出各種場景下各個功能失效的S(傷害度)、E(暴露度）、C(可控程度)，再進行整理合并，導出功能安全目標，并在初始架構的支持下，通過安全分析，將功能安全目標形成功能安全需求，分配給架構上的各個元素。由于網絡安全在概念階段非常復雜，在相關項定義的基礎上，需要進行整車網絡安全威脅分析與評估（TARA）[2]。在系統初始架構圖的基礎上，對數據流進行分析，識別出安全資產。在《SAE J 3 0 6 1 網聯汽車網絡架構安全指南》中，提供了多種TARA分析方法，如電子安全車輛入侵防護應用（EVITA）[3]、待分析系統的威脅、漏洞和風險（TVRA）、修復漏洞以增強軟件安全性（HEAVENS）等。以EVITA模型為例，除了要考慮功能安全方面的影響外，還需要考慮對隱私、財產、駕駛員操作等方面的影響，并結合威脅場景考慮攻擊或潛在攻擊的可能性，最終形成對風險的評估和應對措施的初步設計。一般情況下，若項目同時需要符合功能安全和網絡安全的要求，先進行功能安全的HARA分析，再進行TARA分析，然后在一起進行統一的綜合分析和評審，最后形成分配給各要素的功能安全需求和網絡安全需求。

三、設計階段 

在設計階段，功能安全分為系統階段、硬件階段和軟件階段，逐步將安全需求進行細化和分配。I S O  21434的網絡安全標準對設計階段統一考慮。  完成了融合的安全流程體系和概念階段工作后，在設計方面，本文以端到端(e2e)的通訊保護的安全需求為例，分析如何設計才能滿足兩種安全的需求。首先，在功能安全方面，要對端到端的通訊/數據傳輸可能的失效模式進行分析(參考I S O  26262標準的第5部分附錄D)，可能的失效模式有如下類型：通信節點丟失、消息損壞、消息不可接受的延時、消息丟失、非預期的消息重復、消息順序錯誤、消息插入、消息偽裝、消息尋址錯誤。針對這些失效模式，可采取的有效安全措施主要包括奇偶位的檢驗、通訊通道硬件的冗余、使用測試模式檢驗、發送冗余、信息冗余、幀計數器、超時監控、發送信息回讀以及多種措施的組合。在這些安全措施中，完全硬件冗余，使用測試模式檢驗和信息冗余、幀計數器和超時監控組合達到了高診斷覆蓋率，可以達到99%單點故障的診斷覆蓋率，達到了汽車安全完整性等級（ASILD）的要求。對于常用的循環冗余校驗（CRC）措施，覆蓋率依賴于被覆蓋數據的長度、CRC  的大小（位數）和多項式，常用的有16位CRC校驗、32位CRC校驗等方式。  在功能安全設計中，為了實現高診斷覆蓋率，更多時候采用多種措施組合，如將信息冗余、幀計數器和超時監控等組合使用，同時用多種方式對傳輸的信息進行校驗，使得在信息出現丟失或偏差的時候，能夠及時通過診斷獲知異常，并在故障容錯時間間隔（Fault Tolerant  Time  Interval）[4]內完成安全狀態的轉換。  在網絡安全方面 ， 可以根據E C E  R155的法規內容對端到端的通訊/數據傳輸面臨的網絡安全威脅進行分析，常見的可能威脅有發送欺騙信息，通訊通道允許代碼注入到車輛數據和代碼，車輛通訊通道允許操縱、重寫、刪除數據和代碼，車輛通訊通道允許向車輛系統導入數據和代碼，接受來源不可靠或不可信的信息，中間人攻擊/會話支持，重放攻擊，攔截信息、干擾、竊聽通訊，越權存取文件或數據，發送大量的垃圾數據給車輛信息系統，導致不能提供正常的服務，黑洞攻擊，未經許可獲取特權(如R o o t權限)，攜帶病毒信息媒介感染系統，內部惡意信息(如控制器局域網絡CAN)，惡意的診斷信息等。  針對以上威脅分析，可考慮采用緩解措施如下：車輛需確認接收信息的真實性和完整性，對存儲密鑰實施安全控制，系統需通過風險最小化設計實現安全，訪問控制技術和設計應該應用到數據和代碼的預防措施，機密數據傳遞需要被加密保護，應部署相關措施發現并恢復阻斷攻擊，需有手段發現并阻斷越權進入，要考慮防止嵌入式病毒、惡意軟件的系統保護措施等。從上述E2E保護的例子可以看到，功能安全主要面臨的是內部的故障問題，所有分析都建立在如何應對內部故障造成的危害影響上。網絡安全面對可能來自外部的攻擊，對方往往是人為或惡意的程序代碼，面臨的風險更加復雜、多樣和動態化。  在面對E2E的功能安全需求制定保護或診斷措施時，往往可以將C R C校驗，超時校驗甚至信息回讀等方式進行有效組合，從而得到高診斷覆蓋率。但是，上述措施對于防范網絡安全威脅遠遠不夠，需在實現功能安全需求的基礎上，對傳輸的信息進行加密處理，對發送信息的源頭加入證書頒發機構（CA）認證機制，對資源進行分類，并進行權限控制，對傳輸信息流進行威脅監控等。在同時面對功能安全和網絡安全需求時，首先，需進行針對功能安全需求的分析與措施設計，并以此為基礎再對網絡安全的需求進行分析和應對，制定出全面可行的綜合性措施與方案。此外，還需滿足獨立性要求的功能安全工程師與網絡安全工程師一起評審綜合方案，以確保綜合性設計方案能夠滿足功能安全和網絡安全的需求。

四、測試與驗證 

在V流程的模型里，每一級設計應進行相應層級的測試或驗證。在源代碼級，需要進行靜態測試與單元測試；在軟硬件集成、系統集成以及在整車集成的級別，為滿足功能安全與網絡安全的需求，需要進行針對所設計安全措施的故障注入測試、滲透性測試與網絡攻擊測試，形成各級測試報告，以證明所采用的安全措施達到或符合其所分配的安全需求。

五、小結 

關于滿足功能安全與網絡安全的項目實施，需要建立起融合兩方要求的流程體系與安全文化，建立功能安全與網絡安全團隊間的高效溝通渠道，在設計時需綜合分析兩方面需求，設計出合理的架構和設計方案完整的測試策略，并在質量管理體系的基礎上有效實施。

作者：李徐鵬 禹營 單位：中認車聯網技術服務 中國質量認證中心