CP AUTOSAR信息安全机制全面解析

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信息安全固件解决方案的开发，最后如何适配上述机制以构建整车的网络安全体系，这无疑是需要大量网络安全人才的宝贵经验。 果然，工作就是不停地打怪升级，难度极大，而所谓舒适区是需要自己内心来把控。

审核编辑：黄飞