前言

網路安全（Cyber Security）是近幾年汽車電子圈與乙太網、自動駕駛、車聯網等並駕齊驅的熱門話題，為何（Why）？目前的標準和現狀是什麼（What）？網路安全防的是誰（Who）？是從哪裡發起攻擊（Where）？面對這些攻擊，何時（When）要做網路安全工作？如何做（How）？

作為當代“汽車人”，讓我們從這5W1H來聊聊汽車網路安全這個話題。

Why：背景

從行業應用的角度

• 自動駕駛的下沉和技術升級➔網路安全的缺陷如潛伏的灰犀牛，影響和危害更大
• 車聯網廣泛的需求➔更多攻擊源，更大的個人資訊外洩風險（如在車端交易付款的賬戶資訊）

從技術通路的角度

• 乙太網通訊技術的普及➔已存的基於乙太網的攻擊技術將無縫遷移
• 下一代基於高效能運算平臺的電子電器架構➔使Linux、QNX等作業系統在域（Domain）控制器/區（Zone）控制器中得以廣泛應用，同步引入了成熟的攻擊“套路”（如下圖1）

圖1 針對QNX作業系統的攻擊過程

上述的 “疊加效應”以及過去幾年發生的安全事件和攻防演練案例（以15年大切諾基的網路安全“網紅事件”開始），讓大家對網路安全更為敏感和重視。但網路安全該如何行之有效地落地，這也是當前行業同仁們的焦慮點之一。

What：概念及現狀

名詞解釋

“Cyber Security”，其中之一的英文說明：“A attribute of a cyber-physical system that relates to avoiding unreasonable risk due to an attack”，很掙扎地把它翻譯為：網路物理系統中“避免由於攻擊而引起不合理風險”的一種屬性。後續章節通過對比的方式將給大家展示更形象的釋義。

網路安全常涉及的四個名詞：Vulnerability vs. Threat vs. Attack vs. Risk，借用下圖予以解釋。

圖2 網路安全名詞解釋

網路安全vs資訊保安

前者更巨集觀，包括通訊鏈路安全以及“鏈路”所運載的資料安全；後者更具體，強調的是資料的安全，例如對通過藍芽共享在車機中電話薄資訊的保護。

以鐵路運輸為例，網路安全包括鐵路幹線執行安全和執行之上的列車及貨物安全，資訊保安側重於列車中貨物安全（防火防盜），是網路安全的子集。

網路安全vs功能安全（Security vs Safety）

先說區別：
Security的目標是如何免受攻擊（Attack），保護財產、隱私資訊、生命安全，所需應對的威脅和攻擊具有不可預測及動態的特性。

圖3 網路安全與功能安全區別示意圖

以通訊作為對比示例：

Safety Communication：防止非惡意故障（如ECU自身軟體的執行錯誤）對通訊鏈路的影響，如訊息損壞、訊息丟失。採用的機制包括CRC/E2E等，保證資訊的完整性。

Security Communication：防止惡意攻擊（如ECU軟體被非法替換）對通訊鏈路的影響，如訊息的插入、刪除、修改、延遲等。採用機制包括SecOC等，保證資訊的真實性及完整性。

再說聯絡：

SAE J3061從兩個維度闡述了兩者之間的關係：

• 從實體或載體的角度，功能安全關鍵系統是網路安全關鍵系統的子集

舉例來說，ADAS控制器是毋容置疑的“關鍵的”功能安全系統。同樣的安全漏洞在此類載體中所產生的危害更大，所以對它不僅要求滿足對應功能安全等級的技術條件，同時也必須應用網路安全相關技術，這也是為何很多網路安全技術在此類功能安全關鍵系統中應用更廣的推動力。反之，T-Box是公認的網路安全的關鍵系統，但卻不是功能安全的關鍵系統。

• 從工程開發的角度，兩者既有區別，又有聯絡

功能安全和網路安全的設計開發流程相互影響，部分要素互為輸入。在ISO26262 2018版中專門闡述了兩者之間在概念、開發、生產各階段的潛在的互動關係。

圖4 Security與Safety之間的關係

標準及現狀

為了更好地理解及應用，可簡單地將近些年汽車網路安全相關主要標準及組織按照如下二維座標進行定位。

圖5 部分標準和組織的網路安全的關注點定位

關於上述標準文件的解讀不在此展開，只說明幾點：

• AUTOSAR所定義的網路安全技術，對車內ECU是快速落地的最佳選擇
• ISO 21434將於2020年正式釋出，可能會取代SAE J3061
• 在傳統IT及工業領域的ISO 15408、ISO 27001、IEC 62443可充分借鑑參考
• 某些情況下“車內”和“車外”的界線並不明顯，具體問題具體分析
• 國家非常重視交通運輸領域網路安全標準的制定和推廣，相關的標準、行業白皮書需大家關注

小結

網路安全和功能安全都是相對的，不存在絕對的“安全”。許多已有網路安全技術本身既炫酷也有效，但為何卻並未如預期普及呢（如車內報文加密、基於機器學習的IDS、IPS等）？汽車行業的開發是分釐計較的，多一點程式碼/多一點儲存空間佔用/多一點CPU開銷都需精打細算其對成本和效能帶來的影響，所以平衡最重要也最難。

圖6 應用IDS和IPS後轉發性能的對比（圖片來源：Bosch）

Who：防的是誰

網路安全需要認清一個現實：“道高一尺，魔高一丈”，如果有足夠資源（時間、金錢、裝置等），一切安全措施都可能被突破。而嘗試攻擊的人，可大致分兩類：

• 技術段位極高的，想揚名立萬的黑客級玩家，主觀上無損害他人人身和財產安全的意願
• 具備攻擊手段的，利益薰心的不法之徒

顯然，要防範的重點是後者。從社會經濟學的角度，既然逐利，後者同樣會分析投入與收益的關係。所以對於網路安全的設計者而言，需建立相應的安全措施去重點保護可讓攻擊者獲益的漏洞，從而讓攻擊者覺得投入回報不具吸引力。

弄清和了解“誰是我們的敵人”，做到知己知彼，方可有的放矢！他自狠來他自惡，我自一口真氣足。

補充一點，嘗試攻擊的除上述以外，當然還存在有組織、有紀律的團體，其目標非單一維度的“獲名”或“獲利”來描述，不在本文討論的範疇。

Where：從哪裡發起攻擊

根據車內和車外進行劃分，可以把潛在攻擊點彙總如下圖，針對ADAS感測器端的攻擊不屬於本文的討論範疇。

圖7 攻擊埠的示意圖

When：何時

關於When 可分為兩個層面：

• 現在是否要做網路安全技術的實踐

建議：技術儲備只爭朝夕，方案落地結合實際。

• 車內ECU何時設防

通宵達旦處於防備狀態為理想，但對車輛而言功耗和饋電的緊箍咒，決不允許ECU如此“任性”。所以可行的方式是網路安全相關的功能/任務，要“早起晚睡”：從ECU喚醒和啟動的時刻開始佈防，如下文將提到的Secure Boot，同時站好最後一班崗。

How：如何實現網路安全

簡單有效的開發方法

若是解決短期的網路安全設計困惑，可借鑑如下圖8所示的相對簡單有效的方式實現網路安全。

體系化的流程

若長遠考慮建立網路安全開發機制，可以參照和解讀SAE J3061，定義與功能安全十分相似的開發過程：

• Concept Phase

推薦通過TARA（Threat Analysis and Risk Assessment）的方法（此處畫重點，和功能安全中的HARA分析方法異曲同工），評估和定義網路安全特性及需求。

• Product Development

定義產品在系統層面、硬體層面、軟體層面網路安全開發流程。

• Production, Operation and Service

定義車輛生產、使用和售後維護過程的網路安全需求，比如售後診斷刷寫工具等。

• Supporting Processes

可與ISO26262所定義的支援過程共用的，比如配置管理，文件管理，變更管理等，同時需根據網路安全開發的特點進行一定的定製，如網路安全需求管理、分散式開發的處理。

圖9 網路安全的Concept階段和產品開發階段的工作流（來自SAE J3061）

總的來說，SAE J3061定義了涵蓋產品完整的生命週期網路安全開發流程，後續在ISO 21434中進行繼承和補充，但是與ISO26262相同的：定義的都是What，不是How！

網路安全實現的技術方案

基於車輛電子電器系統和區域性的特點，網路安全的技術框架普遍採用層層設防的分層理念。同時，按照保護、監測、響應不同的目標階段，對所涉及的技術可簡要彙總如下圖。

圖10 網路安全所涉及的技術

對各層新技術趨勢，舉例來說：

• L1

針對多核多作業系統域控制器，為了保證網路安全就需要控制器從邏輯或物理上實現隔離分割槽，這樣可保證一旦某個作業系統下的漏洞被攻破，不會影響其它作業系統的通訊和功能。

• L2

乙太網本身自帶一些安全機制（VLAN/ACL等），同時TSN定義了802.1Qci，實現入口過濾和監控，以滿足作為主幹網通訊的網路安全需求。另外，診斷通訊也將定義新的診斷指令以更好地支援網路安全。

• L3

採用以功能域為導向或以網路安全關鍵性為導向的架構設計方案。

• L4

包括資料加密和身份認證等技術，以實現防探測和防篡改，網路安全技術的晶片化是趨勢；同時，3GPP主導的C-V2X中網路安全相關標準在起草中，值得關注。

圖11 以功能域和安全關鍵性為導向的架構設計示意圖

從技術應用的落地角度，對車內可區別對待，先從功能安全（ADAS/VCU等）和網路安全關鍵系統(GW/TBOX/HMI等)著手，先從可行的技術著手；而車外可藉助IT行業成熟經驗和技術，保證TSP及TSP與TBox之間通訊，手機端APP及手機端與TSP之間通訊的網路安全。

網路安全測試

測試依然負責堅守最後的防線，但與以前有些不同。對於網路安全而言，測試的地位明顯提高，因為網路安全測試的過程也是模擬攻擊，發現漏洞的過程。

包括ISO 21434和SAE J3061等在內的標準和文件，介紹瞭如下幾種常用的測試方法：

• 功能性測試

基於網路安全設計需求的正向和逆向測試和效能測試，可黑盒實現。

• 介面測試

通過功能測試，驗證從輸入和輸出是否滿足設計需求，可歸類至功能性測試，可黑盒實現。

• 模糊測試

通過產生隨機數，或“規律的”隨機數，驗證系統的行為，可黑盒或灰盒實現。

• 漏洞掃描

在白盒或灰盒的狀態下進行掃描測試，例如基於CERT的Guideline進行程式碼掃描，或基於已知的安全漏洞Checklist進行審查，漏洞掃描的結果可作為滲透測試的輸入。

• 滲透測試

利用系統漏洞，發起“攻擊”，嘗試獲得系統控制、訪問等各種許可權。基於測試結果識別網路安全需求，強化系統的安全設計。可在黑盒、灰盒或白盒狀態下開展，對測試人員的要求極高。

ISO 21434中定義了1級-4級的CAL（Cybersecurity Assurance Level）。與ASIL相似，不同CAL等級的部件需採用不同Level的測試方法和手段。

總結

技術落地要從實際出發，要結合汽車行業自身的特點。以大家耳熟能詳的SecOC中的MAC（Message Authentication Code）應用為例：

從系統設計角度

• CAN報文中增加了MAC資料，對資料場分配帶來了影響，進而可能對網路負載產生影響
• 是否需要採用CAN FD以容納新增的資料場？如果是，就需要進行CAN FD通訊需求設計；如果否，需要對原有的網路設計進行重定義和優化
• 如使用CAN FD通訊了，需考慮是否基於CAN FD實現診斷刷寫，是否增加閘道器的路由型別等問題，這些將會影響系統架構的設計

以部件實現而言

• MAC對於接收端和傳送端都將產生額外的資源消耗，需通過專用的硬體HSM模組來處理，才能降低CPU/MCU開銷，並減少收發延遲
• HSM硬體模組採用何種方案，對開發和成本影響有多大，都需要予以考慮

由此可見，哪怕只是增加一個MAC的特性，就已涉及了內部和外部的上下游，涵蓋從頂層設計至具體實現的方方面面，每走一步的包袱和慣性自然會大一些，更何況是網路安全這樣的大話題。所以，更需要策略性的應對，堅持“合適的才是最好”的原則。

關於網路安全，總的來說，對傳統的“汽車人”而言，當前更為缺失的是對網路安全系統性的、全面的認識，以及有條不紊的、有的放矢的行動。他強由他強，清風拂山崗；他橫由他橫，明月照大江。

此次成文拋磚，對網路安全的知識框架和技術脈絡的梳理，既是對自我認知學習的小結，也希望藉此分享可以給大家帶來一些啟發和思想碰撞。疏漏及謬誤之處，請予指正！關於當前行業內網路安全技術的具體應用情況和進展，歡迎當面溝通交流！

本文來自部落格園，作者：{北匯信息}，轉載請註明原文連結：{https://www.cnblogs.com/polelink/}