芯片功能安全架构设计 —— 软件层面

以下文章来源于汽车电子与软件，作者王伟峰

荐 言：

今天推荐王伟峰老师的新书《一本书讲透汽车功能安全》，这是一本系统、深度解读ISO 26262/GB/T34590功能安全标准并解决标准落地难题的实战性著作，为读者打通标准与工程实践的桥梁，能有效弥合二者的差距。本书是作者从事汽车电子与功能安全10余年经验的总结，得到了众多行业专家的高度评价。特别推荐给大家！

正 文：

接前文：芯片功能安全架构设计 —— 硬件层面

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

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

#01

芯片的软件安全

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

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

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

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

1.温度传感器

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

图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）通信架构示例

来源：AUTOSAR_SWS_E2ELibrary

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

#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结构

来源：2nd Generation AURIX TC3xx Hardware Security Module, Figure 1-1

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（内存保护单元）和加密技术相结合，从各个环节来保证信任链的完整性。所有这些措施都是为了建立一个可信的安全系统。