本文主要介绍软件层面的芯片功能安全架构设计。

尽管芯片尺寸较小，但其设计是一项复杂的系统性工程。芯片的功能安全设计也需要遵循 V 模型流程。因此，安全方面仅仅考虑硬件显然是不够的。本节讨论芯片设计中的软件安全、通信安全信息安全设计考量。

#01 芯片的软件安全

芯片通常是基于 SEooC 方式进行开发和设计的，因此，一款通过功能安全认证的芯片需要对其应用的上下文环境做一些假设，而这些假设往往涉及系统层面的安全考量。

所以，在芯片内部部署相关的硬件安全设施还不够。这些基础设施需要软件进行合理的配置，才能正确地实现安全功能。

本节将选取几个芯片，讨论在功能安全设计过程中，软件层面的一些安全设计。

其实，前文提到的芯片内部的电源、时钟、存储器、温度传感器等都有对应的寄存器需要软件进行配置。软件将故障报告出去，芯片内部的故障收集器收集后，根据系统层面的策略做出对应的故障响应。

1. 温度传感器

在芯片内部署了两个温度传感器来检测芯片的工作结温，软件的工作是根据传感器采集到的温度来判断当前芯片结温是否超过预设范围（例如-40℃~150℃)，并将计算得到的状态写入对应寄存器以表征芯片的温度状  态。应用层软件根据该信号状态做出处理策略，比如进入复位状态、发出加大风扇转速指令进入强制冷却模式等。图  12 所示为芯片内部温度检测示意图。

另外，温度传感器作为芯片用于应对共因失效的一种安全机制，其本身的失效在设计过程中需要进行考虑，即需要考虑防止温度传感器成为潜在故障的机制。这可以在硬件上实现，如果是在芯片内部实现，可以进一步增加硬件，但这会增加芯片设计成本，还会改变现有的芯片架构，似乎不怎么合适。如果通过软件来实现呢？

对于潜在故障，常用的措施是在上电 / 下电过程中检测安全相关的硬件组件，以确认其是否具备正常功能。此措施同样适用于作为安全机制的温度传感器，不会增加软件开销，也不会影响软件后续的正常运行。

可供参考的实施方式：系统上电过程中，软件读取两个温度传感器的信号，判断两个信号的值是否在量程范围内且两个值的差是否在一定误差范围内，不满足任何一个条件都认为当前传感器不可信。

Q：对于温度传感器转换后的信号表征状态的读取，软件在设计过程中应该考虑哪些因素来提高读取的准确性？

2. “看门狗”

“看门狗”全称为“看门狗定时器”（Watchdog Timer，WDT），是一种定时器电路，通常有一个输入信号（称为喂狗信号），还有一个输出连接到  MCU 的复位（RST）端。MCU 正常工作时，定期发出喂狗信号以将定时器清零。如果在规定时间内没有喂狗，定时器将向微控制器发送复位信号，尝试让系统重新恢复正常。

随着看门狗技术的发展，“看门狗”分为硬件“看门狗”和软件“看门狗”。根据相对于微控制器的物理位置，硬件“看门狗”又可分为内部“看门狗”和外部“看门狗”。图13总结了常见的“看门狗”类型。

图 13 “看门狗”类型

不管是哪种类型的“看门狗”，其基本原理都是相同的，只是方式有所不同。软件“看门狗”包括一个喂狗进程。喂狗进程按一定周期执行喂狗操作，该周期小于或等于定时器的周期。

芯片内部部署专门的定时器和相应的寄存器来实现软件“看门狗”机制。在功能安全相关设计中，“看门狗”可用于对软件实施程序流进行分析，检查软件程序的运行行为是否符合既定流程。

此外，功能安全要求所有软件组件在同一微控制器上运行时必须实现免于干扰（Freedom from Interference,  FFI）。因此，如何实现免于干扰的软件设计，不仅是芯片厂商需要考虑的问题，也是系统应用方需要关注的问题。

图 14 展示了软件设计过程中免于干扰机制实现的示意图。

图 14 免于干扰机制实现示意图

芯片内部部署的“看门狗”需要通过软件配置相应的寄存器才能起作用。当程序中的各个模块以错误的顺序或过长的时间段运行时，可以使用“看门狗”来检测有缺陷的程序序列。一旦启用“看门狗”，需要定期且及时地执行“看门狗”服务程序。在服务超时之前在配置的时间窗口内完成服务。

可供参考的实施方式：假设使用两个定时器 T0 和 T1 对主程序的运行进行监控。对 T0 设定特定的定时时间，当定时中断发生时，对一个变量进行赋值。这个变量在主程序运行开始时已经有一个初始值。设定的定时值需要小于主程序的运行时间，这样可以在主程序的末尾对变量的值进行判断。如果该值发生了预期的变化，就表明  T0 中断正常；如果没有发生变化， 则使程序复位。

T1 用于监控主程序的运行。对 T1 设定一定的定时时间，在主程序中对其进行复位。如果不能在规定时间内对其进行复位，T1  的定时中断就会使单片机复位。在这里，T1 的定时时间要设定得大于主程序的运行时间，给主程序留有一定的裕量。

T1 的中断正常与否由 T0 定时中断子程序来监控。这样就构成了一个循环，T0 监控 T1，T1 监控主程序，主程序又监控  T0，从而保证系统的稳定运行。

图 15 展示了软件“看门狗”机制示意图。

图 15 软件“看门狗”机制示意图

3. ADC 故障检测

ADC 在芯片内部也属于共享资源的范畴，这意味着 ADC 的故障会引发相关失效。芯片的功能安全设计过程中需要考虑该失效所引发的风险。

BIST 模块可用于ADC的自测，以验证ADC硬件功能的完整性。除了BIST 模块，我们还可以使用软件ADC预采样功能来检测ADC故障。软件可以通过配置ADC相关寄存器来启用对每一通道转换电路的预采样。预采样允许在ADC内部电容器从芯片I/O引脚接收模拟输入的采样和转换之前对其进行预充电或放电。

在预采样阶段，ADC 对内部产生的电压进行采样。在采样阶段，ADC 对来自I/O 引脚的模拟输入进行采样。在转换阶段，最后一个采样值被转换为数字值。图  16 展示了两个通道的 ADC“预采样 – 采样 – 转换”操作顺序。

图 16 ADC“预采样 – 采样 – 转换”操作顺序

图中的 VADC_VDD_ref 或 VADC_GND_ref 假设是可用于预采样的参考电压。

如果 ADC 中的模拟多路复用电路存在开路故障，ADC 转换的信号将不是来自I/O 引脚的模拟输入，而是预采样参考电压。图  17 展示了多路复用电路中预采样阶段和转换阶段的信号路径。

图 17 多路复用电路中预采样阶段和转换阶段的信号路径示意图

除了检测开路故障，预采样功能还可用于检测 ADC 内部的短路故障。为了检测短路故障，ADC 通过获取两个不同的电压，比较这两者与预期值的一致性。如果这两者与预期值不符，则认为  ADC 中多路复用电路存在短路故障，如图 18 所示。

为了实现该检测，可以对 ADC 预采样操作顺序进行配置。软件通过配置相关寄存器，将ADC 预采样配置为通道的采样被旁路（通过  I/O 关键的输入采样被旁路），并且预采样参考电源电压被转换，如图 19 所示。

图 18 多路复用电路短路故障检测示意图

图 19 ADC 预采样短路故障检测操作顺序

#02 芯片的通信安全

芯片内部集成了各种通信模块，如 CAN、ETH、LIN、SPI、I2C 等，以与外部进行数据传输。对于确保各类总线的通信安全，除了在芯片设计中考虑基本的防护措施外，还需要在软件应用层或系统层保障通信安全。

通信总线失效模式如表 2 所示。

表 2 通信总线失效模式

像 CAN 、ETH 、LIN 、SPI 、I2C 等总线，除了其协议规范中包含的功能安全机制之外，并没有其他特殊的功能安全机制。仅依靠这些协议难以应对通信总线的失效。因此，我们需  要在系统层面考虑在通信模块接口上提供功能安全机制，以满足功能安全要求。

可以通过在软件应用层扩充用于通信安全的总线协议，使其具备一定的通信故障容忍和检测能力，形成额外的一层通信故障容错协议，这就是我们常说的  E2E 保护机制。

应用软件、中间件软件或操作系统需要在相关通信模块的接口上提供以下功能安全机制，以满足功能安全要求。

• 端到端 CRC用于检测数据损坏； • 序列编号用于检测消息重复、删除、插入和错误排序； • 用于检测消息延迟的确认机制或超时检测。 • 用于检测伪装的发件人身份标识。

关于 E2E 保护机制，可以参考 AUTOSAR 中关于 E2E 库的软件需求规范，其中描述了数据通信的各种失效模式，并且有相关需求进行覆盖，能够满足功能安全对通信安全完整性的要求。图  20 展示了 AUTOSAR 中E2E 通信保护架构。

图 20 AUTOSAR 端到端（E2E）通信架构示例

关于芯片功能安全软件设计的内容就讲到这里。当然，软件层面的芯片安全设计工作远不止这些，比如寄存器的保护、中断控制、堆栈溢出检测、系统故障管理等。

#03 芯片的信息安全

随着汽车智能化、网联化程度的提高，各种车用控制器的功能越来越丰富和复杂，其中自动驾驶对车载电子控制单元（ECU）功能的复杂度和集成度要求最高。自动驾驶可谓汽车技术的“集大成者”，涉及整车及电子电气控制技术的各个方面。自动驾驶的发展还催生了对  汽车其他安全相关的要求，如预期功能安全（SOTIF）、网络安全（CS），并且相关标准也陆续发布。

为此，自动驾驶功能相关的电子电气系统不仅要满足汽车功能安全标准 ISO 26262 的要求，还要满足预期功能安全标准  ISO 21448 的要求和网络安全 ISO/SAE 21434 的要求，实现整车电子电气系统的安全，笔者习惯称之为“大安全”。

图 21 展示了功能安全、预期功能安全和网络安全三者在整车系统安全中各自扮演的 “角色”与关系。

图 21 预期功能安全、功能安全、网络安全的关系

接下来，我们讨论一下为满足汽车发展要求所采用的信息安全技术。

（ 1 ）硬件安全模块

随着汽车电子电气架构的日益复杂，车辆与外部设备、云端设备的交互场景也越来越多，汽车成为一个自主移动的终端系统。在这种情况下，整车的信息安全就成为一个不可回避的话题。信息安全的核心是密码学。它是一门对信息进行加解密的学科，涉及多种加密算法，  如 AES、DES、SHA、RSA 等。通过应用这些算法，可实现信息的加解密，以保证信息的安全。

网络安全是系统信息安全的重要组成部分。通常，我们根据系统架构及其通信网络来构 建分层的网络安全架构，进而构建系统的网络安全纵深防御体系。在汽车电子电气架构中，不同控制单元的功能由内而外基于整车通信网络划分为不同层次，从而形成整车电子电气网络的纵深防御体系。图  22 展示了汽车电子网络安全的参考架构。

图 22 汽车电子网络安全参考架构

从图 22 可知，ECU处于汽车网络安全纵深防御的最底层，这意味着ECU的设计必须满足信息安全的要求，确保ECU在网络上进行数据收发的安全，而其中的关键便是加密算法。由于整车系统信息安全的要求，在IT  领域常用的AES、SHA、RSA 等加密算法被越来越多地应用到汽车上。通常，这类加解密算法需要进行大量数学运算，消耗大量CPU资源。汽车上的ECU具有较高的实时性要求，为了节省主CPU的资源，芯片厂家在微控制器内部专门开辟了一个模块—HSM（HardwareSecurityModule，硬件安全模块），以提供ECU通信数据的加解密功能，并满足ECU  信息安全开发的要求。

硬件安全模块（HSM）是专用于实现加解密算法的微控制器上的独立模块，可以理解为 一个“信息安全岛”。HSM  通常配备独立的 CPU，专门用于加解密运算，并且包含一些针对特定算法（如 AES-128、SHA-256  等）的硬件加速器，相当于为 ECU 提供了一个可信计算平台。

有了 HSM，微控制器就可以将加解密运算交给 HSM 来执行，主 CPU 可以去做其他工作。一段时间后查询结果，或等待  HSM 计算完成后通过中断等方式通知主 CPU 计算结果即可。

HSM 通常还拥有单独的存储区，包括 RAM 和 NVM 。HSM 的存储区在正常运行状态下应只允许  HSM 核读写，主功能核不能读写。这样就可以将算法密钥等重要数据存储在 HSM 存储区，与主核进行隔离，进一步加强安全性。

根据 EVITA（E-safety Vehicle Intrusion Protected Application）项目给出的  HSM 基本结构，可以将 HSM 分为安全存储、硬件密码加速和应用核心 3 部分，如图 23 所示。

图 23 HSM 基本结构

根据 HSM在汽车电子不同网络层次的应用，EVITA将HSM划分为3 个等级：Full HSM、MediumHSM  和LightHSM。其中，FullHSM 主要用于V2X的通信单元和中央网关；Medium HSM  用于板间通信的ECU；Light HSM 则用于传感器和执行器。

1 ）Full HSM 结构如图 24 所示。

图 24 Full HSM 结构

Full HSM 不仅支持安全存储（RAM 、NVM）、对称算法（如 AES）的硬件加速引擎、随机数生成器、安全  CPU 等基本功能，还进一步支持非对称算法（如 RSA 、ECC）的硬件加速引擎和哈希硬件引擎。这些功能使得  Full HSM 能够提供最高级别的安全保护。

2 ）Medium HSM 结构如图 25 所示。

与 Full HSM 相比，Medium HSM 没有包括 ECC-256 和 WHIRLPOOL  密码模块（NIST 提出的基于 AES 的哈希函数），并且 Medium HSM 所要求的 CPU  性能要低一些。因此，Medium HSM 没有基于硬件加速的非对称密码和哈希算法。

图 25 Medium HSM 结构

3 ）Light HSM 结构如图 26 所示。

图 26 Light HSM 结构

Light HS仅包含基于AES-128的对称加解密模块，以满足传感器和执行器在成本和效率方面的高需求。基于Light HSM，传感器和执行器能够确保通信数据的真实性、完整性和机密性。此外，与FullHSM 和MediumHSM  相比，LightHSM 未提供独立的处理和存储单元，应 用处理器和软件可以完整访问所有的密码数据。因此，可以考虑对LightHSM  进行安全增强，提供内部非易失性存储器和RAM，以及基于AES的伪随机数生成器。这样，LightHSM  可以更加安全地生成、处理和存储密钥。

目前看到的带 HSM 的功能安全微控制器的结构大部分是 Medium 、Full HSM 类型的。图  27 所示的是 Infineon AURIX TC39X 系列微控制器中的 HSM 结构。

图 27 AURIX TC39X 系列微控制器中的 HSM 结构

TC39X 系列的 HSM 具有以下特征。

• 满足 Full HSM 结构要求。

• 包含 ARM Cortex-M3 的处理器、AES 加速引擎、PKC 模块和 Hash 模块。

• AES 加速引擎支持 AES-128 算法（对称加密算法），PKC 支持 ECC256（非对称加密算  法）、SHA256 等。

（2）安全硬件扩展

除了 HSM，一些微控制器内部还部署了安全硬件扩展（SHE）固件，以扩展硬件安全策略。 SHE 的基本结构如图  28 所示。

SHE 可以提供以下功能。

• 对称数据加密和解密。 • MAC 生成 / 验证。 • 安全 MAC 验证。 • 随机数管理。 • 安全引导。 • 开发调试。 • 非对称加密和解密（可选项）。

图 28 SHE 的基本结构

（3）示例：安全板载通信

接下来以 AUTOSAR 中的安全板载通信（Secure On-board Communication  ，SecOC）功能为例，介绍芯片中集成的 HSM 在车载领域的实际应用。

SecOC 模块的作用是确保通过汽车通信网络交换信息的两个或多个 ECU 之间的安全数据传输。如图  29 展示了 AUTOSAR SecOC 示意图。

图 29 AUTOSAR SecureOC 示意图

基于非对称密码算法和消息摘要算法的数字签名技术可以用于实现高安全等级的板间通信。数字签名的实现方式参见图  30。

图 30 数字签名实现示意图

由于板间通信对实时性有一定要求，基于效率和成本的考虑，ECU 之间通信的保护采用对称密码算法是合理的。因此，针对  ECU 板间通信，一般使用 HSM 中的“AES-128+CMAC”算 法对通信数据进行加密，以保证消息来源的真实性和完整性。这是一种“对称加密  + 消息认证码”技术，实施步骤如下。

1 ）在发送端，通过消息摘要算法对数据 ID 和 PDU 计算对应的消息摘要（MD，即 MAC），  然后用加密算法（AES-128）和私钥对 MAC 进行加密以获得密文 S。接着，将密文 S 与数据  一同发送。

2）在接收端，先用私钥将签名后的数据进行解密得到 MAC，再用同样的摘要算法对签 名后的数据计算得到新的消息认证码  MAC'，将 MAC' 和接收到的摘要 MAC 比较。

3）结果确认，如果比较结果一致，数据就是合法且完整、真实的；否则，数据是不可信的，不予采用。

关于芯片架构设计过程中需要考虑的信息安全措施，我们就讨论到这里。除了软硬结合的固件加密技术，当然还有其他措施来保证信息安全，例如单次可编程（OTP）、遵守信息安全的流程等。此外，在应用层面，可以将功能安全中提到的  MPU（内存保护单元）和加密技术相结合，从各个环节来保证信任链的完整性。所有这些措施都是为了建立一个可信的安全系统。