隨著汽車網聯化和智能化，汽車不再孤立，越來越多地融入到互聯網中。在這同時，汽車也慢慢成為潛在的網絡攻擊目標，汽車的網絡安全已成為汽車安全的基礎，受到越來越多的關注和重視。AUTOSAR作為目前全球范圍普遍認可的汽車嵌入式軟件架構，已經集成的相關信息安全模塊對實現信息安全需求有著充分的支持，例如保護車內通信或保護機密數據。由于CP AUTOSAR 和AP AUTOSAR 的體系結構不同，目前信息安全模塊的相關技術實現也存在差異。

1. SecOC

在車載網絡中，CAN 總線作為常用的通訊總線之一，其大部分數據是以明文方式廣播發送且無認證接收，這種方案具有低成本、高性能的優勢。但是隨著汽車網聯化、智能化的業務需要，數據安全性越來越被重視。傳統的針對報文添加RollingCounter 和 Checksum 信息的方法，實現的安全性十分有限，也容易被逆向破解，進而可以偽造報文控制車輛。

SecOC 是在AUTOSAR 軟件包中添加的信息安全組件，主要增加了加解密運算、密鑰管理、新鮮值管理和分發等一系列的功能和新要求。該模塊的主要作用是為總線上傳輸的數據提供身份驗證，它可以有效地檢測出數據回放、欺騙以及篡改等攻擊。

圖4.1-1消息認證和新鮮度驗證流程

在SecOC 標準中，AUTOSAR 主要基于MAC 的身份驗證和Freshness 的防重放攻擊，來實現數據的真實性和完整性校驗。首先MAC（Message Authentication Code）是保障信息完整性和認證的密碼學方法之一，其中CMAC（Cipher based MAC）一般用于對稱加密，整車廠可在車輛下線刷寫程序時靜態分配密鑰，也可選擇使用云端服務器動態地給車輛分配密鑰）是車載總線加密認證常用方案。MAC 的作用不是防止有效數據被泄露，而是為了保護數據不會被攻擊方篡改，即完成數據來源的認證。如需保護通信數據不被攻擊方監聽，則報文的有效數據還需要進行額外的加密。

為了降低重復攻擊的風險，則需要在Secured I-PDU 中加入新鮮度值，Freshness Value 是一個根據一定邏輯不斷更新的數值，Freshness Value 的更新方法多種多樣，AUTOSAR 標準將基于計數器或基于時間的新鮮度值作為典型選項。

在CP AUTOSAR 平臺，SecOC 模塊依賴于PduR 的API 和功能，提供了PDU Router 所需的上下兩層API（upper and lower layer API）功能。依賴于由CSM 模塊在AUTOSAR 中提供的加密算法。SecOC 模塊需要API 函數來生成和驗證加密簽名（Cryptographic Signatures）或消息驗證碼（Message?Authentication Codes）。為RTE 提供具有管理功能的API 作為服務接口進行調用。

SecOC 通信協議特性同樣適用于AP AUTOSAR 平臺標準中，其主要目標是實現與CP AUTOSAR平臺SecOC 功能互操作性，尤其適用于使用 UDP 多播的消息場景（SecOC 是目前唯一支持的協議）和與CP AUTOSAR 之間基于信號的網絡綁定的安全通信場景。

圖4.1-2 AP AUTOSAR通信管理中的SecOC

為了實現與CP AUTOSAR 平臺的互操作性，SecOC 同樣應用于Adaptive CM 中。認證信息包括認證器（例如，消息認證碼）和可選的新鮮度值。為了保持與CP AUTOSAR 平臺的互操作性并提供可選的新鮮度值管理功能，AP AUTOSAR CM 將依賴于可插入的新鮮度值管理庫。該庫將提供新鮮度值管理相關的API，包含CP AUTOSAR 平臺關于Freshness Management 客戶端、服務端接口的副本以及調用定義的相關功能。

SecOC 的核心思想在于通信認證，但是不涉及報文加密。雖然偽造報文的難度已經大大提升了，但是在通信過程中采用明文傳輸，依舊有一定的風險；認證信息的強度和信息長度相關，通信認證方案會加大報文負載（傳統CAN 報文的負載只用8-64 個字節），從而導致負載率提升，通信實時性下降，可能使得正常功能受到影響，應考慮信息安全強度與通信實時性的相互平衡；MAC 技術應考慮對稱密鑰的管理和共享的問題，目前大部分MCU 是沒有安全功能的，對稱密鑰也是明文保存在系統或者內存中。共享該密鑰時采用明文通信，這是非常不安全的。但MCU 的計算能力和存儲空間是有限的，采用了安全機制以后，必然占用很大的資源消耗，應充分考慮系統的穩定性，以保障業務與安全機制能夠正常運行；SecOC 用于保證安全通信，必然涉及密鑰（key）的管理，應考慮灌裝、更新和維護該key, 同時還需考慮換件后key 的一致性。

2. TLS

TLS（Transport Layer Security）作為傳輸層的中堅力量，可以支撐上層的SOME/IP、MQTT 和HTTP 等協議。不但可以用于V2X 的安全通訊，也可以用于車內通訊節點之間的安全通訊。當然像T-BOX等可以與車外節點通訊的節點來說，其安全性要求更高，可以應用更加完整的廣義TLS，既安全，又靈活。而車內之間一般IP 地址、端口、服務接口等都固定，安全性要求也不如T-BOX 高，則可以應用廣義TLS中的預共享密鑰（TLS_PSK）等套件，既高效，又穩定。

TLS 屬于工作在傳輸層的協議，它介于傳輸層底層協議和上層應用協議之間。而以太網的傳輸層主要有兩大底層協議：TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。二者各有特點，互為補充。不管在傳統互聯網上，還是車載以太網上，兩者都是常見的傳輸層底層協議。不同的傳輸層底層協議實際上對應著不同的傳輸層安全保護協議，采用TCP 傳輸的，就用TLS 保護。采用UDP 傳輸的，就用DTLS 保護。DTLS 的全稱是Datagram Transport Layer?Security，比TLS 多出來的“D” ，指的就是UDP 中的“D” 。TLS 和DTLS 各有不同的版本，目前主流支持的還是1.2 和1.3版本。

AUTOSAR 標準基于Ethernet 架構同時提供了ISO DoIP 的解決方案。DoIP 全稱是Diagnostic Over?IP，顧名思義就是基于IP 的診斷。DoIP 具有處理大量數據、節省重編程時間、方便接入IT 設施、標準通信靈活使用等優勢。普通的DoIP 是基于TCP 進行診斷通信，在ISO 13400-2 2019 版本中定義了安全的DoIP 會話，即基于TLS 進行診斷通信。

DoIP server 協議棧會根據DoIP client 實體的請求，確定使用TCP 還是TLS 進行診斷信息的傳輸。TLS 允許在Client DoIP 實體和Server DoIP 實體之間建立經過身份認證和加密的通信通道，Client DoIP實體身份的驗證可以在診斷應用層中實現，例如ISO 14229 中定義的0x29 服務。

TLS 技術仍有自身的技術局限性。大部分控制器都是采用了MCU，計算能力和存儲空間都是有限的，采用了安全機制，例如加解密算法、消息摘要算法、簽名驗簽算法等，必然占用很大的資源消耗，應考慮在不影響正常功能的情況下安全策略能夠正常實施。SSL/TLS 采用安全認證的方式來識別對方身份，需要提前灌裝安全證書，如果控制器進行換件，應保證證書的一致性，讓新的控制器能夠進行身份的合法驗證，從而正常通信。在實際應用場景中，大部分控制器可能沒有安全存儲環境（SE 或者HSM 等），應考慮保證證書和私鑰的安全存儲。在采用TLS 進行安全認證通信中，必然會降低通信的效率，應考慮通信的實時性。安全技術應用的同時會帶來一些資源消耗，產生一定的局限性。應當在滿足汽車信息安全相關法規標準的原則下，技術手段在不影響控制器正常運行的前提下，進行方案選型完成集成部署，如果內部安全通信技術手段消耗過多的控制器資源并影響了正常業務運行，應適當降低安全等級，必須同時兼顧控制器運行和內部安全通信。

隨著汽車網聯化的發展，以太網通訊已經在車內通訊及車聯網普及，TLS 和DTLS 也更多地出現在汽車行業的視野里。AUTOSAR 在CP 和AP 中也加入了TLS 和DTLS 的規范。從AUTOSAR CP 4.4 標準開始就明確了支持1.2 和1.3 版本，優先選擇1.3 版本。AP R21-11 中只描述了1.2 版本，但相信將來版本也會加上1.3 版本。

3. IPsec

IPsec（Internet Protocol Security）是網絡安全協議，運行在OSI 模型的第三層（Internet Protocol，IP 層），在VPN（Virtual Private Network）應用很廣泛。IPsec 在IP 層對報文提供數據機密性、數據完整性、數據來源認證、防重放等安全服務，定義了如何在IP 數據包中增加字段來保證IP 包的完整性、私有性和真實性，以及如何加密數據包。

圖4.1-3 IPsec協議及組件功能

IPsec 提供了兩種安全機制：認證和加密。認證機制使IP 通信的數據接收方能夠確認數據發送方的真實身份以及數據在傳輸過程中是否遭篡改。加密機制通過對數據進行加密運算來保證數據的機密性，以防數據在傳輸過程中被竊聽。

IPsec 的安全體系由驗證頭協議（Authentication Header，AH）、安全封裝協議（Encapsulating?Security Payload ，ESP）及安全聯盟（Security Association，SA）三部分組成。AH 是認證頭協議（IP?協議號為51），主要提供的功能有數據源驗證、數據完整性校驗和防報文重放功能，可選擇的散列算法有MD5（Message Digest ），SHA1（Secure Hash Algorithm）等。ESP 是報文安全封裝協議（IP 協議號為50），ESP 將需要保護的用戶數據進行加密后再封裝到IP 包中，驗證數據的完整性、真實性和私有性。可選擇的加密算法有DES，3DES，AES 等。SA（Security Association）是IPsec 的基礎，也是IPsec的本質，IPsec 對數據流提供的安全服務通過SA 來實現，它包括協議、算法、密鑰等內容。IPsec 有隧道（tunnel）和傳輸（transport）兩種運行模式，運行模式和安全體系中的AH 及ESP 組合形成4 種情況：隧道模式+AH、隧道模式+ESP、傳輸模式+AH 以及傳輸模式+ESP。

AUTOSAR CP R19-11 標準在TCP/IP 模塊加入IPsec 相關功能介紹，并對功能實現進行了條件約束，目前只支持IPsec 運輸運行模式，隧道運行模式、IPv6 和多點傳播都暫不支持。并規定了其他模塊可執行的操作內容，KeyM 模塊可為IPsec 子模塊提供證書處理，CSM 允許執行IPsec 子模塊所使用的加密作業和密鑰操作。

AUTOSAR AP 中IPsec 協議實施的目標是在車載IP 網絡中提供安全的通信通道。在 AUTOSAR 自適應平臺中實施IPsec 將為網絡節點之間的通信提供保密性、完整性或兩者兼備的選項。IPsec 作為標準網絡安全協議提供了安全通信的手段，同時支持多供應商堆棧互操作性。自適應平臺沒有為電子控制單元指定任何操作系統，因此是IPsec 功能最好的實踐方式。

4. Crypto Stack

為了汽車軟件提供統一的安全加密/ 解密接口，AUTOSAR 在4.3 版本推出Crypto Stack 模塊。Crypto Stack 是AUTOSAR 架構體系中負責數據加密保護和密鑰管理的模塊，由Crypto Service Manager,Crypto Interface, Crypto Driver 三個部分組成，為應用程序和系統服務提供了標準化的密碼服務接口。密碼服務可以是哈希計算，非對稱簽名驗證，對稱加密等。其主要應用于ECU 通信加密、SecurityAccess 流程保護和KEY 的管理等使用場景。

CSM(Crypto Service Manager）是加密服務管理器，位于AUTOSAR 的SYS 模塊最高層的服務層。服務層是基礎軟件的最高層，它的任務是為應用軟件和基本軟件模塊提供基本服務，即為應用軟件和基本軟件模塊提供最相關的功能。CSM 基于一個依賴于軟件庫或硬件模塊的加密驅動程序來提供加密功能的服務，也可以使用多個加密驅動程序的混合設置。CSM 通過CryIf(Crypto Interface）訪問不同的加密驅動程序。

圖4.1-4 CSM和鄰近模塊的關系

CSM 作為服務層，為SWC 或BSW 提供加密操作的接口。CSM 的主要任務是對服務進行調度和排序，并調用加密接口（CryIf）進行進一步操作。CryIf 將請求調度到加密驅動程序及其靜態分配給該服務的加密驅動程序對象。CSM 使用基元（CsmPrimitives，已配置加密算法的實例）的靜態配置來定義加密操作。然后將這樣的基元分配給Job(Job 是配置過的CsmJob，指的是密鑰、密碼原語和參考信道），該配置決定進一步的屬性，如優先級、異步或同步執行以及程序執行中應使用的密鑰。需要注意的是，密鑰總是位于加密驅動程序本身中，CSM 只使用對它的引用。

密鑰和基元的分離允許加密操作和密鑰管理API 分離。這使得應用程序可以專注于所需的加密操作，如MAC 計算和驗證，而密鑰管理器則在配置設置期間提供密鑰。

CSM的API大致可以分為兩類：直接AP（I 主要用于密鑰管理）和基于Job的AP（I 主要用于加密操作）（見下圖）直接API 與CryIf 和Crypto Driver 中的函數有直接對應關系，這些函數只能同步調用，CSM將把參數從應用程序直接傳遞給函數調用。基于Job 的API 使用一個Job 結構，即Crypto_JobType，它包含靜態和動態參數以及對結構的引用，為執行該Job 的加密驅動程序提供所有必要的信息，使用Job 的每個服務都將使用此結構。服務的所有必要參數將由CSM 打包到結構的元素中，然后調用CryIf，然后調用配置好的Crypto Driver。

圖4.1-5 CSM、CryIf和Crypto的Job API和直接API調用樹

Job 可以同步運行，也可以異步運行，這取決于靜態配置。加密服務信息、加密算法族和模式的參數決定了加密驅動程序中要執行的確切的加密算法。

CryIf（Crypto Interface）是加密接口模塊，位于BSW（Basic SoftWare）的抽象層。CryIf 模塊提供了唯一的接口來管理不同的加密硬件和軟件解決方案，如 HSM、SHE 或基于軟件的 CDD。

圖4.1-6 AUTOSAR Layered View with Crypto-Interface

CryDrv 有如下兩種實現方式：

1. Crypto（HW based）：硬件加密模塊的驅動程序，用于控制HSM（Hardware Security Module）或SHE（Security Hardware Extensions），和具體芯片有關。

2. Crypto（SW based）：基于軟件的CDDs（Complex Device Drivers） 實現的加密算法， 如AES-128 等算法。

基于以上兩種不同的實現方式，CryIf 模塊提供了唯一的接口來管理不同的加密硬件和軟件解決方案。因此，基于 CryIf 維護的映射方案，CSM 模塊可以使用多個底層的Crypto HW 以及 Crypto SW 解決方案。此外，CryIf 還確保了對加密服務的并發訪問，從而能夠同時處理多個加密任務。

與CP AUTOSAR 不同，AUTOSAR 自適應平臺支持用于通用加密操作和安全密鑰管理的API。該API 支持在運行時動態生成密鑰和加密作業，以及對數據流進行操作。API 實現可以引用一個中央單元（加密服務管理器）來實現平臺級任務，例如跨應用程序一致地進行訪問控制和證書存儲。該實現還可以使用加密服務管理器來協調功能到加密驅動程序的卸載，例如硬件安全模塊（HSM）。為了在潛在的應用程序受損的情況下支持密鑰的安全遠程管理，Crypto Stack 集成了密鑰管理體系結構，其中密鑰和相關數據以端到端的保護形式進行管理。密鑰可以基于現有的供應密鑰以受信任的方式引入系統，也可以通過本地密鑰生成以不受信任的方式引入系統。

5. IAM

車內信息娛樂應用程序由于與外界互聯網相連，因此被入侵的風險很高，像這類應用程序在設計時一定是不被允許使用車身控制相關服務的。例如信息娛樂系統被外界攻擊，然后被遠程控制去使用制動服務，為了保障安全，必須要阻止這種信息娛樂應用程序對制動服務訪問的任何嘗試。

日益增長的信息安全需求驅動了身份和訪問管理（IAM）的概念，因為AUTOSAR Adaptive 平臺需要和應用程序建立健壯和良好定義的信任關系。IAM 為Adaptive 應用程序引入了特權分離，并針對攻擊時的特權升級提供了保護。另外，在部署期間，IAM 能夠使集成者提前驗證Adaptive 應用程序要求的資源訪問權限。IAM 為來自適應應用程序對服務接口，Adaptive 平臺基礎功能簇和相關模型資源的的請求提供了訪問控制框架。

IAM 框架為AUTOSAR Adaptive 平臺堆棧和Adaptive 應用程序的開發人員提供了一種機制，這種機制用于對每個應用程序的意圖進行建模，根據訪問請求提供訪問控制決策，并執行控制訪問。IAM 側重于提供方法來限制Adaptive 應用程序對Adaptive 平臺基礎接口、服務接口與功能集群相關的明確資源接口( 例如KeySlots) 的訪問。特別對系統資源( 如CPU 或RAM) 的強制配額不包括在IAM 中。

在運行期間，IAM 的進程對Adptive 應用程序是透明的，除非請求被拒絕并發出通知。遠程Adaptive平臺提供的服務實例請求由IAM 覆蓋的，傳入請求的PDPs 必須由Adaptive 應用程序實現。

該框架旨在運行期間執行對AUTOSAR 資源的訪問控制。假設Adaptive 應用程序將在啟動時進行身份驗證，并且現有受保護的運行時環境確保Adaptive 應用程序被正確隔離，并且防止它們的特權升級( 例如繞過訪問控制)。

考慮一個簡單的應用場景，對于訪問權限的描述，通常可以用一個訪問權限矩陣來表示：

圖4.1-7 訪問權限矩陣

訪問權限矩陣顯示的是訪問主體和訪問客體之間的訪問權限。所謂訪問主體，是指一個想要獲得其他服務訪問權限的對象，通常是指系統中的一個進程；所謂訪問客體，是指應當授權被訪問的對象，通常它可以是指系統中的一個進程也可以是系統中的其他資源。

訪問權限相關的信息需要以清單文件的形式部署在系統中。對于這份清單文件，有兩種組成形式：

第一種，針對每一個服務和應用，從訪問權限主體的角度，列舉每個訪問主體的訪問意圖，也就是每個訪問主體擁有的其他服務或應用程序（訪問客體）的訪問權限；

第二種，針對每一個服務和應用，從被訪問的客體角度，列舉出它支持被哪些其他服務和應用（訪問主體）訪問。對于訪問主體，通常情況下它可訪問的客體清單文件是不會隨著時間推移而改變；但是對于一個訪問客體，它的被訪問清單會隨著部署了新的應用而更新。

6. KeyM

在一個加密功能中，密鑰和證書的功能比重很大。首先，密鑰是一種參數，它是在明文轉換為密文或將密文轉換為明文的算法中輸入的參數。許多加密算法需要使用到密鑰，因此，就需要KeyM 模塊來管理密鑰，而KeyM 對于密鑰的管理主要體現在更新和生成密鑰方面。而證書以加密或解密的形式保障了用戶網絡交流中的信息和數據的完整性和安全性。KeyM 模塊可以實現證書鏈的配置保存與驗證，這使得網絡中的信息和數據的安全性更高。

AUTOSAR KeyM 模塊由兩個子模塊組成：密鑰子模塊和證書子模塊。密鑰子模塊用于初始化、更新和維護的密鑰材料；證書子模塊允許定義和配置證書，以便在生產時存儲它們，并進一步用于多種用途。

圖4.1-8 AUTOSAR layered view with KEYM

密鑰子模塊提供了一個API 和配置項，用于引入或更新預定義的加密密鑰材料。它充當一個關鍵客戶端，解釋從一個關鍵服務器提供的數據，并創建相應的關鍵材料，這些密鑰被提供給加密服務管理器。成功安裝密鑰材料后，應用程序就能夠進行加密操作。

證書子模塊提供了對證書進行操作的API 和配置。允許配置證書鏈，在配置中將證書的屬性和關系設置好，上層應用通過 API 將證書數據傳給KeyM 后，證書子模塊將根據配置內容及HSM 按照標準結構解析的證書存儲配置的位置（NVM、CSM 或 RAM）。此外，證書子模塊允許BSW 模塊和SWC 在AUTOSAR 軟件架構的中心點上更有效地使用證書進行操作。此類操作的示例包括驗證完整的證書鏈或從運行時提供并驗證的證書中檢索元素。所需的加密操作（如驗證證書簽名）仍然由加密服務管理器中定義的相關加密作業執行。

與CP AUTOSAR 不同，AP AUTOSAR 平臺的更新和配置、通信、持久性或診斷等服務，也需要加密服務作為其功能的一部分。因為架構差異的原因，AP AUTOSAR 平臺會將需要用戶自定義、差異性的功能在應用層去實現，所以應用程序可以定義所需的密鑰插槽、加密提供程序和證書。當需要關鍵材料時，必須由自適應應用程序（例如OEM key manager）配置，平臺應指定槽型機器的關鍵槽。為了管理關鍵材料，一個專用的自適應應用程序（密鑰管理器）可以指定相同的密鑰插槽（即相同的參數和插槽型機器）。

7. IdsM

車輛中的許多新功能建立在車載和后臺服務之上，需要面對保護車輛免受網絡攻擊的挑戰。為車輛的E/E 架構配置了安全機制，更新簽名軟件、安全啟動和安全車載通信系統正在逐步建立。目前，IDS 作為一種額外的安全機制正在引起OEM 和供應商的關注。

入侵檢測系統管理器（IdsM）是一個基礎軟件模塊（適用于Classic AUTOSAR）或平臺服務（適用于Adaptive AUTOSAR），用于收集和集中聚合可能由車輛軟件、通信或電子系統受到惡意攻擊而導致的安全事件。軟件組件IdsM 提供了接收板載安全事件SEv 通知的標準化接口。SEv 可以通過BSW (Basic?Software Modules）和SW-C (application Software Components）實現的安全傳感器上報。此外，可以用可選的上下文數據（如事件類型和可疑數據）報告SEv，這些數據對于在后端執行的安全取證來說是有用的信息。

除了收集，IdsM 還可以根據可配置的規則對SEv 進行篩選。IdsM 將上報的SEv 過濾并轉換為合格的機載安全事件（QSEv)，IdsM 進一步處理QSEv，用于存儲或轉發。根據總體安全概念的不同，QSEv可以通過安全事件內存（Sem）在本地持久化，也可以傳播到已配置的接收器，或者兩者兼有。可用的接收器是診斷事件管理器（Dem）模塊和IDS 報告器模塊（IdsR)，它們可以將QSEv 數據傳遞給后端中的安全操作中心（SOC)。

在車輛內的每個安全相關或機器中，IdsM 模塊或服務的實例會收集和過濾安全事件（可選地包括附加數據），以便將它們存儲在本地安全事件內存（Sem）和/ 或通過車輛網絡將它們轉發到中央入侵檢測系統報告器（IdsR)。例如，該IdsR 可能位于遠程信息處理單元內，使其能夠通過蜂窩網絡向OEM 的安全操作中心（SOC）發送安全報告和相關數據。然后，安全事件管理（SIEM）分析這些信息，并在必要時用于制定和決定適當的防御或緩解措施以應對攻擊。

AUTOSAR 標準指出BSW 模塊、CDD 和SWC 都可以充當安全傳感器，安全傳感器將安全事件（SEv）報告給IdsM，AUTOSAR 標準化可以由AUTOSAR BSW 報告的安全事件類型的子集。每個BSW 的規格里列出了自己產生的安全事件類型，這些事件由相應模塊報告，業務組件也可以報告在AUTOSAR 中未標準化的自定義安全事件類型，可以使用安全性摘要（SecXT）指定由特定ECU 報告的安全性事件類型的屬性。AUTOSAR 入侵檢測系統管理器是通用的、提供靈活的配置。它獨立于底層通信系統，在上述限制和假設條件下可以應用于任何汽車領域。

編輯：黃飛

?