目录
1.安全启动
2.安全升级
3.安全存储
4.安全通信
5.安全调试
6.安全诊断
7.小结
废话不多说,目前识别到的关于汽车ECU的网络安全方案需求如下:
01
—
- 对于MCU,安全启动主要是以安全岛BootROM为信任根,在MCU启动后,用户程序运行前,硬件加密模块采用逐级校验、并行校验或者混合校验的方式,对Flash中的用户关键程序进行数据完整性和真实性进行校验,确认程序没有被篡改。
- 对于SOC,安全启动主要是同样以安全岛BootROM为信任根,通常采用逐级校验的方式对manifest中定义的image镜像文件进行校验。常见顺序为BootROM -> SecureBL-> Application。BootROM用于验签和解压SecureBL程序,确保SecureBL是可信软件后将其加载到RAM中进行运行;SeucreBL负责对存放在Flash中的App进行解密、数据完整性和真实性的验证,确保没有被篡改后,从Flash拷贝至RAM中运行,或者直接在Flash运行。
—
- SOTA:Software over the Air,即对车载IVI运行在Linux、IOS或Android系统上的应用软件升级,例如对导航地图信息的升级、音乐播放软件的升级等;
- FOTA:Firmware over the Air,即对整车偏控制类的ECU进行固件升级,通常包括制动系统、动力系统等。
OTA升级的抽象模型如下:
03
—
安全存储
- Flash某些Sector通过设置访问权限,从而防止非法访问或篡改;
- OTP:eFuse,只能被烧写一次。
04
—
安全通信
- 车内网络通讯,目前常见的是CAN通信,以明文的方式在整车内部进行交互,攻击者可随意伪造报文对车辆控制器特别是动力、制动系统进行控制。因此,需要在关键报文上做PDU级别的身份验证机制,以防止数据被篡改或是被重放攻击。常见的是对CAN使用SecOC模块,对以太帧使用MACsec模块等。
MACsec模块
SecOC
- 车云网络通讯安全主要是SLS(Secure Socket Layer)/TLS(Transport Layer Security)进行保护。
05
—
安全调试
06
—
安全诊断
具体步骤如下:
- 客户端(通常是诊断仪)发送证书至服务器,证书中一般包含客户端的公钥。对于支持安全诊断通信的客户端和服务器,在认证过程中同步使用Diffie-Hellman算法生成密钥
- 服务器接着确认证书的有效性,验证客户端是否合法;若不合法则停止认证流程,返回否定响应,合法则继续认证流程
- 服务器继续对证书发起挑战,请求客户端对所发证书的所有权证明,通常挑战中包含认证所需随机数
- 客户端接收到挑战信息后使用私钥对接收到的随机数进行计算得到签名,放入响应消息中发给服务器
- 服务器使用客户端的公钥解密并验证应答消息中的签名信息,与挑战消息比较,向客户端回复认证结果
07
—
小结
往期回顾:
1.汽车标定合集
2.AUTOSAR合集
3.汽车网络安全合集
4.汽车功能安全合集
原文始发于微信公众号(汽车MCU软件设计):汽车网络安全方案需求分析