目录
1.安全启动
- 对于MCU，安全启动主要是以安全岛BootROM为信任根，在MCU启动后，用户程序运行前，硬件加密模块采用逐级校验、并行校验或者混合校验的方式，对Flash中的用户关键程序进行数据完整性和真实性进行校验，确认程序没有被篡改。
- 对于SOC，安全启动主要是同样以安全岛BootROM为信任根，通常采用逐级校验的方式对manifest中定义的image镜像文件进行校验。常见顺序为BootROM -> SecureBL-> Application。BootROM用于验签和解压SecureBL程序，确保SecureBL是可信软件后将其加载到RAM中进行运行；SeucreBL负责对存放在Flash中的App进行解密、数据完整性和真实性的验证，确保没有被篡改后，从Flash拷贝至RAM中运行，或者直接在Flash运行。
2.安全升级
随着汽车智能网联的迅猛发展，汽车升级技术引入OTA(Over-the-Air Technology)的方式。
通常意义下，汽车OTA分为SOTA和FOTA两种：
- SOTA：Software over the Air，即对车载IVI运行在Linux、IOS或Android系统上的应用软件升级，例如对导航地图信息的升级、音乐播放软件的升级等；
- FOTA：Firmware over the Air，即对整车偏控制类的ECU进行固件升级，通常包括制动系统、动力系统等。
OTA升级的抽象模型如下：
T-Box(或者带有T-Box功能的座舱域)接收到来自云端的升级包后，对升级包进行验签解密，完成数据包的拆分，同时作为OTA Master对车内所有ECU进行差分升级。
除OTA之外，线下4S店或工厂通过OBD对特定ECU进行升级的方式也需要进行数据的真实性和完整性的校验。
综上，为保证上述两种升级包的发布来源有效、数据完整不被篡改、升级内容不被恶意截获，一方面需要为升级包进行签名，保证数据来源可靠，数据完整没有被篡改；另一方面还需要对升级包进行加（OBD方式除外），传输数据过程通过密文传输，从而降低软件更新时数据暴露的风险。
3.安全存储
安全存储通常是有两种方式实现。
- Flash某些Sector通过设置访问权限，从而防止非法访问或篡改；
- OTP:eFuse，只能被烧写一次。
4.安全通信
安全通信分为车内网络通讯和车云网络通讯。
- 车内网络通讯，目前常见的是CAN通信，以明文的方式在整车内部进行交互，攻击者可随意伪造报文对车辆控制器特别是动力、制动系统进行控制。因此，需要在关键报文上做PDU级别的身份验证机制，以防止数据被篡改或是被重放攻击。常见的是对CAN使用SecOC模块，对以太帧使用MACsec模块等。
- 车云网络通讯安全主要是TLS(Transport Layer Security)/SLS(Secure Socket Layer)进行保护。
5.安全调试
安全调试通常是指产品下线后对MCU进行片上debug，一般使用基于挑战\响应的身份验证机制来限制调试器访问。只有授权的调试设备（具有正确响应的设备）才能访问调试端口
在生产或者下线阶段，必须要禁用或者锁定相关的调试接口，禁用意味着无法与硬件调试接口建立连接，锁定意味着硬件调试接口受到保护，只能根据安全调试解锁来访问。
以某中央网关芯片的安全调试为例，其挑战-响应机制如下：
6.安全诊断
车载诊断时，读取特定内存位置、执行特定例程、下载数据等服务时需要进行身份认证；下载数据服务即上述提到的基于UDS安全升级，需要对数据或者程序进行身份认证。读取特定内存位置的服务也需要进行身份认证，以防数据通过OBD口泄露。
安全诊断就是是通过某种认证算法来确认Client的身份，并决定Client端是否被允许访问。可以通过对随机数种子生成的非对称签名进行验证或者通过基于对称加密算法的消息校验码来验证其身份。
ISO 14229-2020版本就提出了0x29服务(Authentication Service)，如下：
具体步骤如下：
- 客户端(通常是诊断仪)发送证书至服务器，证书中一般包含客户端的公钥
- 服务器接着确认证书的有效性，验证客户端是否合法；若不合法则停止认证流程，返回否定响应，合法则继续认证流程
- 服务器继续对证书发起挑战，请求客户端对所发证书的所有权证明，通常挑战中包含认证所需随机数
- 客户端接收到挑战信息后使用私钥对接收到的随机数进行计算得到签名，放入响应消息中发给服务器
- 服务器使用客户端的公钥解密并验证应答消息中的签名信息，与挑战消息比较，向客户端回复认证结果
对于支持安全诊断通信的客户端和服务器，在认证过程中同步使用Diffie-Hellman算法生成密钥。
7.小结
本文主要是在梳理当前项目security方案的需求时，顺便整合了下车-管-端的需求分析，虽然我们用不到这么多需求。这里分享给大家。