車載信息安全架構的案例
帶你走進信息安全軟件架構
汽車信息安全逐步受到重視，網絡安全相關法律法規陸續頒布。在這樣的背景下，AUTOSAR 組織也發布了有關信息安全模塊和 Crypto Stack( 加密協議棧 )，落地有關汽車信息安全法律法規要求，應對汽車網絡安全風險。從 2011 年起，經緯恒潤緊跟行業發展大勢，開始研究信息安全相關標準和技術。
經緯恒潤車端信息安全解決方案整合了 MCU 端以及 MPU 端的信息安全解決方案，具體方案包括 Security Boot、安全通信、安全存儲、安全診斷和入侵檢測等，能滿足歐標強制法規要求和國內信息安全法規要求，符合歐標出口要求的車載信息安全技術架構。
SecOC 安全通信模塊
SecOC 主要功能是為所需要加密的通信報文提供加密服務和認證機制，能夠抵御報文的重防攻擊。
Crypto 加密驅動模塊
Crypto 主要功能是支持芯片硬件安全擴展模塊所提供的所有加密技術功能，能夠與固件進行交互，完成有關信息安全管理和加解密功能。
HSM Firmware 安全固件
HSM 安全基礎固件主要功能是提供安全計算環境和安全存儲環境 , 具備如下：隨機數生成，對稱密碼算法，消息認證碼，哈希算法，非對稱密碼算法，密鑰派生，X.509 證書解析，運行中篡改檢測，SecOC 協議棧適配，安全日志，安全啟動，安全刷寫，安全診斷等功能。
安全啟動
安全啟動方案主要功能是保證車載系統軟件滿足安全的啟動信任鏈，或軟件被篡改后無法正常啟動。
展開 技術 | 用于自動駕駛的安全車載以太網——多級安全架構
例如，8年前被視為安全的數據加密方法現在可能會受到攻擊，因為當時的密鑰長度對于現在來說太短了。
四、多級安全架構
多級安全架構可以有效對抗這些外部威脅，這個概念可避免黑客僅攻破一道安全屏障就能破解整個系統，從而造成巨大的破壞。
Elektrobit (EB) 開發的安全架構包括4個等級，可以分層保護系統。第1級“加密網絡權限”，嚴格限制網絡訪問權，盡可能讓惡意攻擊者難以進入通信網絡。這一級已經能夠提供非常有效的防護。如果第一級被攻破了，第2級“安全車載通信”可確保被交換的所有安全相關消息得到保護，防止被攻擊者篡改。如果這一級也被攻破，第3級“數據使用政策”會要求執行特定的用戶驗證以進行保護。在進一步處理敏感消息內容前，系統會在特定的用戶環境中執行檢查。最后第4級是“檢測與防御”。這一級會檢查整個通信模式的異常情況。如果發現攻擊行為，防御機制會確保恢復被攻破的1-3級安防層。這種多級架構可為針對系統可用性、完整性和保密性的攻擊提供全面的防護。
第一級 加密網絡權限
安全架構的第一級通過四項措施限制對車載網絡的訪問：(1) 集中的非車內連接，(2) 安防區域，(3) 設備身份驗證，(4) 凍結網絡配置
第一個措施旨在減少具有非車內連接的控制設備數量，將潛在攻擊點限制為少數實現充分防護的控制設備。例如，在“智能天線模塊”中，應用程序層網關將外部網絡與內部網絡完全分開，從而保護此類控制設備。這意味著攻擊者無法從外部直接訪問內部網絡節點。
第二個措施將網絡劃分為多個安防區域。這種系統通常無法采用實際的物理劃分形式，所以按照IEEE 802.1Q通過虛擬局域網（VLAN）進行劃分。在以太網頭和數據之間插入VLAN標簽。
展開 適用于新型電子電氣架構的信息安全綜合解決方案
并且大多數先進架構中都會使用以太網及移動OS，原先很多分析攻擊的思路，攻擊用的工具也可以在車上使用。最后一個特點到不是完全由E/E架構演進帶來的。就是網聯化與全車OTA。這個變化帶來的是，幾乎車上的所有控制器，隨時，隨地都可能遭受攻擊。
這里只列舉了很少一部分新挑戰，實際上挑戰比這里列的肯定要多得多。那么我們應該怎樣去應對這些挑戰呢？
04
如何應對新的挑戰
關于應該如何應對這些挑戰，我這里提出兩個觀點：
第一個觀點，我們要具備全網絡空間視角。這里指的是，在評估風險的時候，將云管端核，以及所有已售出在運行的同類型車輛當作一個整體來考慮。而要做到這樣，其實對人的能力要求非常之高。
第二個觀點，就是我們可以將網絡空間粗略分成云管端核四個層級，我們在導出信息安全需求的時候會發現，有很多需求跨了多個層級，要實現相應的設計工作，需要有一個頂層視角開展頂層設計，最后將需求層層落實。
我將如何應對E/E架構演進帶來的挑戰歸納為以下5個步驟：
第一步，將全網絡空間當作整體進行分析評估，這里的方法論使用ISO21434。
第二步，在該網絡空間中構建安全架構覆蓋可能產生風險的方方面面。
第三步，將導出的安全需求分層布置，跨層跨終端的需求從頂層設計，部分部署在云端，路端的需求在這個層級就已經可以落地了。
第四步，將拆解到整車的信息安全需求分解到整車，此時整車會被視為一個終端。
第五步，將需求進一步分解到控制器層級，最后在控制器層級實施落地。以上是在應對新挑戰時，應該關注的2個要點以及5個步驟。
展開 面向新一代架構的OTA和信息安全解決方案
來源 |
燃云汽車
車載E/E架構不斷升級，整車架構指引趨勢
2015年首個車載以太網規范100Base-T1發布，僅需要一對雙絞線進行傳輸，可以減少70-80%的連接器成本，減少30%以上的重量，并且能夠有效的滿足車內EMC電磁干擾的要求。隨著1000Base-T1以及更高帶寬NGBase-T1以太網標準的不斷推出，以太網有望成為未來智能汽車時代的車載主干網絡
關于“面向服務”通信協議，支持SOA架構升級
SOME/IP面向服務通信協議，支持SOA架構升級。隨著以太網不斷的普及，SOME/IP (Scalable service-Oriented MiddlewarEover IP)概念開始引入車載網絡通信領域，它2011年由BMW集團推出，是車載以太網的通信中間件，位于OSI 7層模型的第5層，并于2013年被納入AUTOSAR 4.1規范中。傳統的CAN/LIN總線為主的車載網絡中，通信過程是面向信號，其信號的發送是根據發送者的需求，不會考慮接收者是否有需求。而SOME/IP則不同，它在接收方有需求的時候才會發送，這種方法優點在于總線上不會出現過多不必要的數據，降低負載。
以太網支持下SOA架構
在SOME/IP協議和以太網的支持下，通信架構和協議支持面向服務的SOA架構升級，將各種控制算法、顯示功能等應用程序抽象為“服務”，并通過API接口和中間件（Middleware）使得所有有需求的任務都可以對其進行訪問。
5、 算力需求+SOA架構推動“功能域”集成，“Zone”區域控制成為重要組成
控制器“功能域”集中成為趨勢。
展開 車載SOA軟件架構設計
SOA設計—圖表設計
SOA設計和軟件架構( architecture)數據應以表格格式或圖表形式可視化。
應使用定制的表格格式來可視化SOA設計數據和軟件架構定義面向服務的體系結構圖(SOAD):該圖應可視化給定功能或服務、服務角色(服務提供者和服務使用者)、服務端口和服務接口。下面是SOA圖的示例視圖:
軟件架構圖（SWAD）：
一旦SOA定義完成，就應該定義軟件組件方面的服務部署。此圖顯示了用于數據交換的軟件組件、軟件端口及其之間的連接（軟件程序集連接器）。還應顯示每個軟件組件上部署的邏輯功能。下面是軟件架構圖示：
車載SOA軟件架構：服務設計
服務定義
服務使用SOME/IP總線向客戶端提供一些功能。所提供的功能既可以作為請求消息公開，也可以作為發送消息公開。
服務集群劃分
服務是基于子系統重新劃分群集的。
服務描述模板
服務描述必須包括以下信息：
服務描述：服務目的的簡單描述。
消息類型：方法或事件。
訊息名稱：訊息名稱。
消息描述：消息用途的簡短描述。
消息輸入參數：此規范類型使用的輸入參數的完整列表。
返回參數：此規范類型使用的返回參數的完整列表。
此外，必須描述枚舉和自定義類型。
展開 大陸汽車：區域架構對車載軟件分布的影響
來源 |
燃云汽車
RTaW—基于車載以太網TSN的下一代E/E架構設計優化工具
不斷新增的功能也將在更廣的范圍內支持車載網絡全網時間分析及優化。
經緯恒潤持續關注車載以太網國際新趨勢，為客戶提供各類優質先進的車載以太網相關工程咨詢服務，涉及車載以太網設計、AVB/TSN量產應用、SOA架構、網絡安全設計和測試等多個領域。RTaW兩年前由經緯恒潤引入國內，是該公司在中國的重要合作伙伴。恒潤已為國內多家知名汽車企業提供了基于RTaW-Pegase產品的車載以太網TSN設計工程咨詢服務，更多資訊請訪問經緯恒潤官網或官微。
[1]O. Creighton, N. Navet, P. Keller, J. Migge, “Towards Computer-Aided, Iterative TSN-and Ethernet-based E/E Architecture Design,” IEEE Standards Association (IEEE-SA) Ethernet & IP @ Automotive Technology Day, 2020.
[2]J. Yoshida, “Unveiled: BMW’s Scalable AV Architecture,” EE|Times, 4 2020.
展開 淺談系統安全架構設計
對于一個系統，架構設計通常決定了該系統的整體性能表現，而功能安全標準對架構設計的要求及安全分析方法論引用比較復雜，如何在系統設計之初，合理并充分的考慮其安全設計成為了當前很多同行在做安全設計的一個難點。
筆者從事功能安全領域工作八年有余，有過多家外企合資企業的三電系統，ADAS系統相關產品的安全開發設計經驗。此次受SESETECH安全技術論壇邀請，結合個人經驗分享一下對系統安全架構設計的淺薄理解，希望能夠解決部分同行對于安全架構設計的痛點。限于個人認知，此文僅供各位同行交流討論，不針對任何企業或者產品安全提出設計建議。
內容框架：
安全架構設計必須了解的術語及安全方法說明
E-GAS三層架構的理解及使用約束
ADAS系統安全架構設計及安全等級的分解
02
安全架構設計必須了解的
術語及安全方法說明
在ISO 26262的第三部分，第四部分及第九部分，提到了很多關于系統或者相關項的安全術語，包括故障類型判斷，安全分解策略，故障控制/避免措施，等。如何正確地理解并應用這些術語及背后的方法論，對于安全架構設計尤為重要。本文主要針對涉及到系統安全架構設計的必要術語進行一些系統性闡述，幫助大家理解其中關系。
故障控制措施（Fault control）
和故障避免措施（Fault avoidance）
在功能安全標準或者一些教學中，經常會提到系統性失效和隨機硬件失效兩個概念作為電子電氣系統的兩大失效來源。
展開 從功能安全視角看軟件架構設計
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：
選取和建立一個層次分明，易于理解的軟件架構；
第二：
在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 從功能安全視角看軟件架構設計
來源 | 薄說安全
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：選取和建立一個層次分明，易于理解的軟件架構；
第二：在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。
展開 
針對智能駕駛的預期安全系統架構
然而，由于近期無人駕駛事故頻發，安全性能令人擔憂。為了解決安全問題，提出了一種智能駕駛安全系統。該系統針對智能汽車感知、決策和控制方面的預期問題，實時提供安全分析和監控服務模塊。基于預期功能安全的概念，對駕駛場景和系統安全進行分析和評估，以提高智能駕駛的安全性，有助于智能駕駛的發展。
1. 介紹
智能駕駛汽車的駕駛行為高度依賴于操作系統的穩定性、智能性、安全性。
安全風險主要來源于以下三類：
硬件安全
與傳統汽車相比，智能駕駛汽車不要求駕駛員直接控制車輛，而是將部分或者是全部的控制權限交由自動控制系統。硬件架構設置是否科學合理；各無人計算控制單元和控制器的設置是否完善；無人駕駛的傳感器是否完善；車輛能夠快速準確地獲取道路環境信息，車輛運動感知和信息融合功能在無人駕駛車輛中起著決定性作用。
軟件安全
與傳統汽車相比，自動駕駛汽車的開發時間較短，技術開發仍不成熟，軟件系統仍需要長期的可靠性分析。例如，著名的無人駕駛汽車制造商谷歌已經在無人駕駛汽車平臺上進行了9年的封閉式測試，但測試時間不夠，因素也相對很簡單。因此，其安全性和穩定性仍需要長期監測。
環境安全
在人工智能算法的基礎上，智能駕駛汽車能夠實現自動避障和完成自動駕駛在一些較為復雜的道路上。然而，無人駕駛汽車仍然需要其他的交通參與者的正確駕駛來駕駛。只有當其他駕駛員做出正確駕駛的判斷時，無人駕駛汽車的測試才會相應做出正確、合理的判斷。
該論文在對無人駕駛事故和安全隱患的分析基礎上，提出了自動駕駛汽車的預期安全系統。
展開 前沿 | 針對智能駕駛的預期安全系統架構
然而，由于近期無人駕駛事故頻發，安全性能令人擔憂。為了解決安全問題，提出了一種智能駕駛安全系統。該系統針對智能汽車感知、決策和控制方面的預期問題，實時提供安全分析和監控服務模塊。基于預期功能安全的概念，對駕駛場景和系統安全進行分析和評估，以提高智能駕駛的安全性，有助于智能駕駛的發展。
1.介紹
智能駕駛汽車的駕駛行為高度依賴于操作系統的穩定性、智能性、安全性。
安全風險主要來源于以下三類：
硬件安全
與傳統汽車相比，智能駕駛汽車不要求駕駛員直接控制車輛，而是將部分或者是全部的控制權限交由自動控制系統。硬件架構設置是否科學合理；各無人計算控制單元和控制器的設置是否完善；無人駕駛的傳感器是否完善；車輛能夠快速準確地獲取道路環境信息，車輛運動感知和信息融合功能在無人駕駛車輛中起著決定性作用。
軟件安全
與傳統汽車相比，自動駕駛汽車的開發時間較短，技術開發仍不成熟，軟件系統仍需要長期的可靠性分析。例如，著名的無人駕駛汽車制造商谷歌已經在無人駕駛汽車平臺上進行了9年的封閉式測試，但測試時間不夠，因素也相對很簡單。因此，其安全性和穩定性仍需要長期監測。
環境安全
在人工智能算法的基礎上，智能駕駛汽車能夠實現自動避障和完成自動駕駛在一些較為復雜的道路上。然而，無人駕駛汽車仍然需要其他的交通參與者的正確駕駛來駕駛。只有當其他駕駛員做出正確駕駛的判斷時，無人駕駛汽車的測試才會相應做出正確、合理的判斷。
該論文在對無人駕駛事故和安全隱患的分析基礎上，提出了自動駕駛汽車的預期安全系統。該系統可以進行監督、預測和保證智能駕駛車輛的駕駛狀態，從感知、決策和控制等方面提高智能駕駛的安全性。
2.系統架構
智能駕駛離不開幾項關鍵技術。
展開 符合功能安全的Level2層VCU架構設計
來源 |
電動學堂
隨著軟件定義汽車的趨勢日益加強，道路車輛電子電器系統滿足功能安全已經成為基本要求。近期，在歐盟車輛型式批準（typeapproval依據部分UNECE法規）和我國車輛的CCC認證中，對采用電子控制的轉向、制動、動力電池管理系統等也引入了功能安全要求。高效的軟件架構設計顯然對功能安全的實施和落地起著引導性作用，所以電子電器系統滿足功能安全要求已經成為產品基本屬性。
針對軟件架構如何滿足功能安全要求，業內人士紛紛借鑒了E-Gas架構，E-Gas最先被應用于發動機控制器EMS，由Level1功能層、Level2功能監控層、Level3控制器監控層三部分組成。國內相關論文分別將E-Gas架構應用于各個控制功能中，其中專利、文獻、文獻、文獻、文獻都針對功能安全標準設計了整車控制器硬件和軟件，但并未涉及Level2軟件架構。
因此，為了彌補E-Gas架構未明確提出基于模型開發MBD的Level2軟件架構的缺陷，且架構設計要滿足高內聚低耦合、合適的分層等功能安全要求，本文針對整車控制器VCU設計了一種Level2功能監控層軟件架構，不但符合功能安全架構設計要求，而且可應用于其他ECU功能安全Level2設計中，有助于功能安全設計進一步落地，降低實施難度。
一、VCU模型整體架構
設計整車控制器VCU模型Level1、Level2架構，如圖1所示，包括時序調度、輸入信號、Level1、Level2和輸出信號模塊，需滿足功能安全可理解性、一致性、簡單性、可驗證性、模塊化、抽象化、封裝性、可維修性等架構設計原則和要求。
展開 要解決安全問題，創新處理器架構呼之欲出
在今年8月舉行的Hot Chips會議上，一個學術小組表示，可能需要對當今的微處理器進行全面的重新設計，以解決當今的安全問題。
數字安全的復雜性、無效性和成本使數字技術行業陷入不知所措的境地，一些行業領導者表示，現在或許是新的處理器架構出現并發揮作用的時候了，以結束當前數字安全技術的無力與混亂狀態。
在美國加州圣何塞舉行的2018年Arm TechCon上，Arm發布了其物聯網安全宣言的第二個版本。那么，我們就來看一下嵌入式行業在實現該文件最初制定并在今年擴展的目標方面取得了哪些進展。
關于Meltdown and Spectre（MDS）一節的新一期宣言中有一條線索：今年早些時候發現的這些安全漏洞將2017年宣言的目標變成了“一頂豎起的帽子”，原因很簡單，因為這些漏洞被整合到了硬件中。雖然已發布補丁，但用戶和攻擊系統的犯罪分子都可以輕松關閉這些補丁。幾乎每個供應商都承認這是他們面臨的一個大 麻煩，問題還不止于此，軟件補丁導致給定處理器性能下降了10％~15％。
我已經對多家公司的首席信息和安全官員（CISO）進行了大約5周的采訪，提出的是一個簡單的問題：如何才能使您的網絡真正安全？不是互聯網，只是他們公司內部的網絡系統，而每個人的答案都驚人的相似：“我們無能為力。”
購買和實施安全技術和服務的公司首席信息安全官知道，理想狀態下，即使他們能購買一切可能的軟硬件，它也不能保證互聯網或內聯網絕對安全，而如果確實這樣實施的話，會使他們自己的生產力水平降低到近乎停滯狀態，這樣會導致對更多技術的投資缺乏合理性。一位不愿透露姓名的電信主管說：“數字安全技術的狀態就像一個污水池。每隔一段時間，我們就會拋出新的東西，把我們的槳插入水中，然后攪拌，但它仍然很臭。
展開 