AUTOSAR R23-11發布有一段時間了，不知大家有沒有淺嘗一下。

據發布會介紹，這次版本主要面向下一代EE架構新增了Safety、Security的特性，因此為了跟上節奏，現將最新CP AUTOSAR關于security機制進行匯總。

1. CP AUTOSAR Security模塊

根據AUTOSAR架構整理出信息安全框架，可以發現相較于之前R22-11模塊變化不大，灰色部分屬于關聯模塊，橙色部分和藍色部分屬于Security功能，如下圖：

SecOC(Secure Onboard Communication)：板級安全通信

MKA(MACsec Key Agreement)：提供MACsec 數據加密密鑰協商方法

IdsM(Instrusion Detection System Manager)：收集和過濾板級信息安全事件并分發不同處理端

KeyM(Key Manager)：密鑰和證書管理

CSM(Crypto Service Manager)：為所有軟件組件提供提供基礎密碼服務

CryIf(Crypto Interface)：提供統一接口管理不同加密驅動等

SHE(Security Hardware Extension)

HSM(Hardware Security Module)

值得一提是，在R23-11的通信模塊中新增了Firewall模塊，根據預定義的防火墻規則對網絡流量進行過濾，保護主機免受惡意報文的攻擊。 這一模塊的出現完善了整車的IDPS系統，從而進一步構建了整車的網絡縱深防御體系。

2. CP AUTOSAR信息安全機制

2.1 SecOC

這個模塊一定是我們工程師最先接觸到的AUTOSAR信息安全機制，主要用于ECU板級的安全通信。 大家應該有印象，在以往沒有該機制，CAN通信通常是使用Checksum和RollingCounter來檢驗是否掉幀或者漏幀，并沒有一個機制來保證報文數據的有效和可信。 基于此，SecOC應運而生，用于實現板級整幀報文的完整性和真實性，實現ECU的Security；而Checksum和RollingCounter這類機制也沒有被拋棄，它被逐步優化為E2E，用于實現信號級別的Safety，在此不表。 在AUTOSAR架構下SecOC關聯模塊如下：

以CAN的接收報文驗證為例，數據流如下： CanIf-> PduR -> SecOC-> CSM ->CryIf ->Crypto Driver -> SHEHSM 當加密模塊對CAN報文進行驗證后，會在SecOC處理驗證結果，如果驗證成功，則數據經由SecOC->PduR-> COM傳至用戶端，否則丟棄該報文，并準備開始診斷事件的處理。 進一步的，SecOC整體驗證流程如下：

假設左右兩個框分別為ECU1和ECU2，ECU1向ECU2發送一個安全報文，那么在ECU1這一端首先需要生成該報文的MAC值（根據SecOC規范一般使用對稱算法AES128-CMAC用于生成MAC值）。 用于生成MAC值的原始明文一般為該報文的ID+原始數據+完整新鮮度值(FV)。在生成完MAC值后，會將MAC和新鮮度值部分截取，并與原始報文組成一個安全PDU發送給ECU2。 ECU2首先檢查新鮮度值是否是在合理范圍內，同時對原始報文進行MAC驗證（對安全PDU進行CMAC計算并與接收到的MAC比較），驗證成功則放行至上層。 需要注意的是，SecOC目前使用MAC（通常為CMAC）保證完整性和身份認證、使用新鮮度值(Freshness)防止重放攻擊，所以一般來講帶有SecOC屬性的報文不是加密的。 2.2 MKA MKA(MACsec Key Agreement protocol (IEEE Std 802.1X))模塊是在CP AUTOSAR R22-11首次提出，并在R23-11進行了優化。 在講MKA之前，首先需要了解MACsec的基本概念(以下來源華為官網技術文章)。

MACsec主要應用在點對點組網的環境中，是基于802.1AE和802.1X協議的局域網上的安全通信方法，它通過身份認證、數據加密、完整性校驗、重放保護等功能保證以太網數據幀的安全性，防止設備處理有安全威脅的報文。

本端和對端之間使用安全密鑰對數據報文進行加密和解密，密鑰的協商以及安全通道的建立和管理由MKA（MACsec Key Agreement）協議負責。

MKA協議定義了復雜的密鑰生成體系，確保MACsec數據傳輸的安全性。

其中，CAK（secure Connectivity Association Key）是用戶在設備上配置的密鑰，不直接用于數據報文的加密，而是由它和其他參數派生出用于數據加密的SAK（Secure Association Key）。

MACsec的交互過程主要分為3步：會話協商、安全通信和會話保持。

會話協商

在兩端設備的接口上開啟MACsec功能，并配置相同的CAK后，兩端設備會通過MKA協議選舉出密鑰服務器（Key Server），密鑰服務器根據CAK生成用于加密數據報文的SAK，分發給對端設備。

安全通信

發送方使用SAK加密數據報文，接收方使用SAK解密數據報文。兩端設備既可以作為發送方，也可以作為接收方，通信過程都受到MACsec保護。

會話保活

MKA協議定義了一個MKA會話保活定時器，用于規定MKA會話的超時時間。MKA會話協商成功后，兩端設備會通過交互MKA協議報文確認連接的存在。設備收到對端的MKA協議報文后，啟動定時器。 如果在該超時時間內收到對端的MKA協議報文，則重啟定時器。 如果在該超時時間內未收到對端的MKA協議報文，則認為該連接已不安全，刪除建立的會話，重新進行MKA協商。

而MKA模塊在AUTOSAR架構如下：

該模塊的主要作用如下：

配置MACsec實體，使受MACsec保護的流量生效

生成處理MKPDUs

使用CSM生成和校驗MKPDU的ICV(Integrity Check Value)

由于這個模塊才被加入到AUTOSAR中，在汽車ECU的車載以太網上的使用有一定的滯后性，不過這個在園區交換機早就廣泛應用了。

2.3 IdsM

該模塊之前專門拿過一章講過，它的出現主要是為了建立起車載視角下的入侵檢測和防御系統。

該模塊被放在AUTOSAR的Crypto Stack的服務層，如下：

旨在用于檢測受保護系統的活動狀態，及時收集和過濾信息安全相關事件，并轉發到不同的處理端。

2.4 Firewall

Firewall在R23-11首次被提出，它主要通過檢測網絡數據包并根據預定義的規則集對其進行過濾，從而保護AUTOSAR堆棧免受惡意消息的攻擊。 可以看到，該模塊其實與IdsM是一個互補的關系，雖然汽車MCU的性能逐步提升和電子電氣架構的演進，車載以太網是一個趨勢，因此借鑒其他行業成熟方案可以提高整車的網絡安全。 在R22-11AUTOSAR_FO_RS_Firewall 中，提出了域控架構的防火墻部署場景，如下：

并且提出了IDS體系和防火墻之前的關系，防火墻可以作為IdsM的Sensor傳輸安全事件(SEv)：

而在CP AUTOSRA視角下， Firewall是處在EthIf和IdsM之間

Firewall在EthIf層對以太網報文進行檢測和過濾

Firewall在遇到阻塞網絡幀后會向IdsM發送安全事件

Firewall狀態受BswM管理

3.小結

從上面幾個機制可以看到，網絡安全正逐步受到各大汽車組織、OEM和供應商的重視； 而這些機制關聯的模塊和開發內容對于汽車人來說是全新且有難度的， 從Crypto Stack的構建，再到HSM信息安全固件解決方案的開發，最后如何適配上述機制以構建整車的網絡安全體系，這無疑是需要大量網絡安全人才的寶貴經驗。 果然，工作就是不停地打怪升級，難度極大，而所謂舒適區是需要自己內心來把控。

審核編輯：黃飛