# 从车灯模组的角度聊聊信息安全需求

1. 前言

最近在和一些车灯客户交流时，发现很多车灯项目都多了信息安全的需求，为了进一步了解信息安全的需求，笔者收集了信息安全相关的文档进行学习和梳理。
下文是笔者自己整理的信息安全需求，并从车灯模组的角度增加了一些看法。如有不对的地方，欢迎指出。

2.信息安全需求

本章节主要从硬件安全、系统安全、通信安全、数据安全四个方面介绍下信息安全的需求，重点介绍硬件安全和系统安全。

2.1 硬件安全

硬件安全主要关注的是PCB板的保密措施和关键芯片的加密功能。

2.1.1 接口安全

• 量产阶段，调试接口（如JTAG，SWD等）不宜直接暴露在PCB板上，如果无法避免，建议改为测试PIN方式分散布置。
• 量产阶段，调试接口需要设置安全的身份验证，身份验证的口令至少为8位，且必须包含数字、大小写字母。

对于车灯模组来说，需要注意的是主控MCU的调试接口，其他的外围芯片基本不涉及到代码读取。

2.1.2 主板安全

• 量产阶段，主板上的关键芯片（如主控芯片、硬件加密芯片、收发器等）、端口和管脚功能的标识丝印需要去除。
• 芯片间敏感数据的通信线路应尽量隐藏，对抗针对控制器内部数据传输的窃听和伪造攻击。
• 主板上的关键芯片采用可靠焊接封装（如BGA、CSP），防止关键芯片被拆下读取芯片内部信息。

2.1.3 芯片安全

为保证整车的网络安全，需考虑硬件级的安全加密，一般选择集成了FULL EVITA等级的HSM模块的MCU，如果使用的MCU没有加密模块，可以外接一个车规级别SE芯片，该SE芯片至少可提供如下接口：

• AES128算法接口
• 对称密钥存储接口
• SHA256算法接口
• RSA2048算法接口
• 非对称密钥存储接口
• 真随机数获取接口

主要芯片及加密芯片需满足抗攻击保护，满足：

• 使用必要的安全机制，防御针对芯片的电压、时钟的单次故障注入攻击；
• 使用必要的安全机制，防御针对芯片的电磁、激光的单次故障注入攻击；
• 使用必要的防护措施，对抗针对加密芯片的侧信道简单功耗分析（SPA）攻击；
• 使用必要的防护措施，对抗针对加密芯片的侧信道一阶差分功耗分析（DPA）攻击；
• 使用必要的防护措施，对抗针对加密芯片的侧信道相关功耗分析（CPA）攻击。

EVITA(E-safety Vehicle Instruction Protected Applications)项目定义了可用于汽车网络信息安全领域的HSM(Hardware security module)的相关规范，针对不同的硬件能力将其分为Full、Medium和Light HSM。EVITA官网有对应的分类表，如下所示。

不同等级的HSM模块以及SHE(Secure Hardware Extension)支持的详细功能对比如下：

2.3 系统安全

系统安全主要关注的是整个系统的软件代码的真实性和完整性，以及如何防止软件泄露的措施。

2.3.1 代码安全

系统开发过程中对代码进行安全扫描或分析，并提供代码扫描报告。
对核心功能相关代码实施代码混淆、加固，防止被逆向分析。

车灯模组使用的MCU一般都是M0，M4内核的，代码相比BCM，网关等不算复杂，不太需要安全扫描。如果是高端车型需要做ADB，这部分算法目前比较复杂，建议实施代码混淆、加固。

2.3.2 软件读保护

在代码存储区增加外部读保护机制，对固件进行保护，防止被窃取。

2.3.3 安全启动

• 保证可信根安全；
• 对bootloader、应用程序的真实性和完整性进行校验，防止被恶意篡改。

2.3.4 安全升级

• 对要升级的应用层程序进行来源合法性和完整性校验；
• 对flash驱动进行真实性和完整性校验。

2.3.5 安全诊断

• 应支持适配新的诊断、刷写的安全访问算法；
• 禁止开放未定义的诊断服务。

2.4 通信安全

通信安全关注的是ECU之间如何保证关键消息的可靠传输。

• 关键数据需要加密传输和消息认证，保证消息来源的合法性和完整性。
• 消息认证需要符合车厂的SecOC(Security Onboard Communication)规范

对使用速率较高的CAN FD通信的ECU，车厂会要求一些关键数据在传输时先进行对称加密然后再传输加密后的消息。目前前灯模组逐渐开始使用CAN FD通信，但是车厂并不强制要求通信安全。

2.5 数据安全

数据安全关注的是关键信息的安全存储。

• 重要数据和个人敏感信息应实现安全存储和隔离，防止未经授权的访问、篡改、删除和检索；
• 实现重要数据和个人敏感信息的安全传输，保证其机密性、完整性和可用性。

车灯模组主要的诉求要保存用于加密重要数据的密钥，使用带HSM模块的MCU或者外挂的SE芯片，都是支持该功能的。

3. 安全启动流程

随着车规MCU自带的加密模块功能变丰富之后，安全启动（Secure Boot）也变得更加容易实现。如下是安全启动的流程示意图。

MCU上电之后，先运行可信引导程序。可信引导程序会去验证bootloader对应区域的数据是否被篡改，即验证bootloader的真实性和完整性。如果Bootloader验证成功，就跳转到bootloader，然后由bootloader验证应用程序的真实性和完整性。应用程序验证成功后，就跳转到应用程序，至此整个安全启动流程就结束。

对于带硬件加密模块的MCU来说，可信引导程序一般通过加密模块进行使能以及配置需要验证的bootloader的大小。如S32K144的Secure boot，需要通过CSEc模块进行使能；S32K3的Secure boot功能由HSE模块负责。推荐阅读如下文章：

• S32K3亮点介绍-secure boot功能

对应上述安全启动流程的方案有三种，如下所示，接下来详细介绍下这三种方案。

• 基于签名技术的安全启动方案
• 基于对称签名技术的安全启动方案
• 基于CMAC技术的安全启动方案

3.1 基于签名技术的安全启动方案

方案框图如下：

生产阶段：

MCU在出厂前，对bootloader和应用程序的bin文件分别使用Hash算法（SHA256选用较多）得到概要值（或称为完整性度量值），然后使用私钥和RSA2048算法对概要值进行签名，最后将bin文件、签名之后的概要值以及公钥一起烧录到MCU中。

安全启动阶段用到的私钥，其生成、存储和运算由汽车零部件供应商负责，汽车厂商不参与。

启动阶段：

MCU上电之后，可信引导程序开始运行，根据预先保存的bootloader的地址信息，通过Hash运算得到bootloader的概要值1。然后使用预先保存的公钥对bootloader的签名概要使用RSA2048算法进行验签，得到概要值2。最后将概要值1和概要值2进行比较，如果一样，MCU就跳转到bootloader运行，否则就一直保持复位或者其他车厂要求的状态。

bootloader运行之后，根据预先保存的应用程序的地址信息、公钥、签名概要，执行和可信引导程序一样的操作，验证应用程序的真实性和完整性。

3.2 基于对称签名技术的安全启动方案

方案框图如下：

生产阶段：

MCU在出厂前，对bootloader和应用程序的bin文件分别使用Hash算法（SHA256选用较多）得到概要值（或称为完整性度量值），然后使用密钥和对称算法（不低于AES128）对概要值进行加密得到MAC值，最后将bin文件、MAC值以及密钥一起烧录到MCU中。

MAC：Message Authentication Code，消息身份验证代码。

启动阶段：

MCU上电之后，可信引导程序开始运行，根据预先保存的bootloader的地址信息，通过Hash运算得到bootloader的概要值1。然后使用预先保存的密钥对bootloader的MAC值使用对称算法（不低于AES128）进行解密，得到概要值2。最后将概要值1和概要值2进行比较，如果一样，MCU就跳转到bootloader运行，否则就一直保持复位或者其他车厂要求的状态。

bootloader运行之后，根据预先保存的应用程序的地址信息、密钥、MAC值，执行和可信引导程序一样的操作，验证应用程序的真实性和完整性。

3.3 基于CMAC技术的安全启动方案

方案框图如下：

生产阶段：

MCU在出厂前，对bootloader和应用程序的bin文件分别使用密钥和CMAC应用的算法（不低于AES128）得到各组的CMAC值，然后将bin文件、CMAC值以及密钥一起烧录到MCU中。

CMAC：Cipher Block Chaining-Message Authentication Code，也简称为CBC_MAC，它是一种基于对称密钥分组加密算法的消息认证码。

启动阶段：

MCU上电之后，可信引导程序开始运行，根据预先保存的bootloader的地址信息，使用预先保存的密钥对bootloader的BIN文件使用CMAC算法（不低于AES128）得到CMAC值1，然后将预先保存的CMAC值和CMAC值1进行比较，如果一样，MCU就跳转到bootloader运行，否则就一直保持复位或者其他车厂要求的状态。

bootloader运行之后，根据预先保存的应用程序的地址信息、密钥、CMAC值，执行和可信引导程序一样的操作，验证应用程序的真实性和完整性。

4. 安全升级流程

安全升级和传统的升级方式相比，主要是验证应用程序的真实性和完整性的方法更加完善了，一般采用3.1-3.3中的任意一种方式即可。下面只介绍下基于签名技术的安全升级方案，其他两种方案就不赘述了。

4.1 基于签名技术的安全升级方案

方案框图如下：

生产阶段：

客户只需要将车厂分配过来的公钥和BIN文件一起烧录进MCU即可。

私钥的生成、存储和运算有主机厂负责。

升级阶段：

零部件厂商登录车厂指定的网站，提交更新后的应用程序的BIN文件，车厂审核通过后，会从云端下发到车身网关。在这个过程中，应用程序的BIN文件也增加了对应的签名概要（如上图左框部分）。

车身网关将BIN文件和签名概要通过CAN/LIN总线传输给对应的ECU节点。ECU中的MCU会对BIN文件进行
Hash和验签操作，然后将得到的签名概要和传输过来的签名概要进行比较，如果一样，就升级传输过来的应用程序，否则放弃此次升级并删除传输过来的应用程序。

5. 参考资料

• Microsoft Word - EVITA_Final_Publishable_Summary.docx (evita-project.org)

• 硬件安全模块- HSM_hsm she_ppyang395942297111的博客-CSDN博客

---

如果觉得本篇文章对你有用， 不妨给个一键三连！！！