在上一篇《芯片功能安全架构设计（上）》中给大家介绍了下芯片设计过程中的一些硬件安全设计考量，芯片虽小但其设计却是一项复杂的系统性工程，芯片的功能安全设计也需要遵照V模型流程进行全生命周期进行管理，所以安全方面光考虑硬件显然是不够的。

那么接下来谈一谈芯片设计过程中还会有那些安全设计考量。

接下来我们继续按下方目录谈一谈芯片设计的软件方面以及信息安全方面的一些考量。

2. 芯片软件安全设计

2.1 温度检测

2.2 软件看门狗

2.3 ADC故障检测

2.4 安全通信

3. 芯片信息安全设计

3.1 硬件安全模块(HSM)

3.2 安全硬件扩展(SHE)

3.3 示例—安全板间通信（SecOC）

2. 芯片的软件安全设计

芯片硬件安全设计介绍了一些芯片在进行架构设计过程中对于安全方面会考虑的一些硬件安全措施，但芯片都是基于SEooC的方式进行开发和设计，所以一款能过功能安全认证的微控制器芯片需要对于其应用的上下文环境作一些假设，而这些假设往往是对系统层面的安全考量。

所以，在芯片内部部署了相关的硬件安全技术设施还不够，这些基础设施是要给软件用的，软件对于这些基础设施相关的寄存器进行合理的配置和应用才能正确地实现一个完整的安全相关的功能。

这里我们就挑几个芯片用于功能安全的设计过程中软件对于芯片实施的一些安全设计。

其实上一篇文章提到的芯片内部的电源、时钟、存储器、温度传感器这些都有对应的寄存器需要软件去进行设置，软件需要将故障报出去，由芯片内部的故障收集器收集后根据系统层面的策略来作出对应的故障响应。

2.1 温度检测

先拿上一篇文章提到的温度传感器举例。在芯片里面部署了两个温度传感器用于检测芯片的工作结温，软件的工作是根据传感器采集到的温度来判断当前芯片结温是否超过预设范围(e.g. -40~150℃)，并将计算得到的状态写入对应寄存器以表征芯片的温度状态，应用层软件根据该信号状态作出处理策略，比如进入复位状态、发出加大风扇转速指令进入强制冷却模式等。

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

对于潜伏故障，常用的措施便是在上电/下电过程中对安全相关的硬件组件进行检测，检测相关硬件是否具备行使正常功能的能力，这个措施对于作为安全机制的温度传感器当然也是适用的，这不仅不会增加什么软件开销也不会影响软件后续的正常运行。

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

Q: 对于温度传感器转换后的信号表征状态的判读软件在设计过程中会考虑什么来提高判断的准确性？

2.2 软件看门狗

不得不说“看门狗”一词用在技术上具有一定艺术性，所谓“艺术源于生活也高于生活”, 现实生活中狗狗也像人一样需要按时来个一日几餐，如果由于主人某种原因(如睡着了)超过时间没给它喂食，狗狗可能就会来咬裤脚或叫起来给主人一些“提示”，提醒主人该喂食了。嵌入式电子技术里的“看门狗”机制的灵感可能就源于类似生活中的示例。

“看门狗”全称是看门狗定时器(Watchdog Timer—WDT), 是一个定时器电路。一般有一个输入(WDI)，叫喂狗信号，一个输出(RST)，连到微控制器(uC)的复位脚, uC正常工作的时候, 每隔一段时间输出一个喂狗信号给WDT清零, 如果超过规定时间不喂狗, WDT就会给出一个复位信号到微控制器, 试图让系统重新恢复正常。

随着看门狗技术的发展，按照种类分可以分为硬件看门狗和软件看门狗；按相对于微控制器物理位置可将硬件看门狗分为内部看门狗和外部看门狗。

不管什么类型的看门狗，基本原理都是一样的，只是方式上的差异。软件看门狗包括一个喂狗(kicking the dog or service the dog)进程。喂狗进程按一定的周期执行喂狗操作，该周期小于等于定时器的周期。

具体地，当系统正常工作的时候，周期性地输出一个信号到喂狗端(WDI)，给定时器清零。如果超过规定的时间不喂狗，定时器超时，就会输出一个复位信号(RST)到微控制器，使系统复位，以防止系统死机。

功能安全的软件设计要求实施程序流分析(控制流+数据流)，用于验证软件架构设计/程序序列是否符合要求，这时对软件实施程序流分析就需要有专门的硬件支持。

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

另外，功能安全对于各软件组件运行在同一个微控制器上有免于干扰(Freedom from Interference_FFI)的要求，所以如何实现免于干扰的软件设计要求既是芯片厂家要考虑的也是系统应用方要考虑的。

芯片内部部署的看门狗需要软件配置对应的寄存器起来才能起作用。当程序中的各个单元以错误的顺序或过长的时间段运行时，使用软件看门狗可用于检测有缺陷的程序序列。一旦软件看门狗被启用，它就需要定期和及时地执行看门狗服务程序。在服务超时到期之前，必须在配置的时间窗口内执行服务过程。

可供参考的实施方式：假设用两个定时器T0, T1来对主程序的运行进行监控。

对T0设定一定的定时时间，当产生定时中断的时候对一个变量进行赋值，而这个变量在主程序运行的开始已经有了一个初值，在这里我们要设定的定时值要小于主程序的运行时间，这样在主程序的尾部对变量的值进行判断，如果值发生了预期的变化，就说明T0中断正常，如果没有发生变化则使程序复位。

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

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

2.3 ADC故障检测

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

在上一篇文章中提到的BIST模块可用于ADC的自测，以验证ADC硬件行使功能的完整性。除了BIST，应用软件还可以使用ADC预采样(presampling)功能来实现对ADC故障的检测。

软件可以通过配置ADC相关寄存器来使能对里面每一通道转换电路的预采样。预采样允许在ADC内部电容器开始从芯片I/O管脚接收的模拟输入的采样和转换相位之前对其进行预充电或放电。

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

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

如果ADC中模拟多路复用电路中存在开路故障，则ADC转换的信号不是来自I/O管脚的模拟输入，而是预采样参考电压（VADC_VDD_ref 或 VADC_GND_ref）。下图描述了模拟多路复用电路中用于预采样阶段和转换阶段的信号路径。

除了开路故障的检测，预采样功能还可以用于ADC内部短路故障的检测。

为了检测短路故障，ADC通过获取两个不同的电压，比较两电压预预期值的一致性。如果这些值与预期值不同，则认为ADC中多路复用电路上存在短路故障。

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

2.4 安全通信

芯片内部部署了各种通信模块，如CAN, ETH, LIN, SPI, I2C等，用于同外部进行数据收发。如何保证各类总线的通信安全除了芯片设计本身要考虑基本的防护措施，更多的是要在软件应用层面/系统层面来保证安全通信。

先看下标准对于通信总线类要考虑哪些失效模式，如下。

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

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

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

• 端到端CRC，用于检测数据损坏；

• 序列编号，用于检测消息重复、删除、插入和错误排序；

• 用于检测消息延迟的确认机制或超时检测；

• 用于检测伪装的发送者身份标识；

关于E2E保护可以参考AUTOSAR中关于E2E库的软件需求规范，里面关于数据通信的各种失效模式都有描述并且有相关需求进行覆盖，能满足功能安全对于通信安全完整性的要求。

以上关于芯片功能安全软件设计就谈到这里，当然软件基于芯片的硬件安全设施要做的事远不止这些，比如还有寄存器的保护、中断控制、堆栈溢出检测、系统故障管理等等，都是软件要结合硬件实施的安全设计，水平有限，只能泛泛而谈啊！

3. 芯片信息安全设计

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

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

接下来我们来谈一谈安全的微控制器芯片为满足汽车发展的趋势考虑了哪些信息安全的技术。

3.1 硬件安全模块(HSM)

由于自动驾驶对于整车各节点数据处理的能力有非常高的要求，比如数据吞吐量、传输及时性等，传统的以CAN总线为主的单一通信网络已不能满足自动驾驶汽车数据处理的要求，整车的通信网络为适应技术的发展也随之发生了一些变化，比如车载以太网的加入，不仅用于车内大容量数据的传输还用于远程数据的传输，这是实现车联网的非常重要的车内基础设施。

随着汽车电子电气架构越来越复杂，车与外部设备、云端设备交互场景也越来越多，车也变成了一个“自主移动的终端系统”，这个时候整车的信息安全也就变成了一个绕不开的话题。

信息安全的核心是密码学，密码学是一门对信息进行加解密的学科，里面涉及多种加密算法，比如AES, DES, SHA, RSA等，通过应用加密算法实现对信息的加解密从而保证信息的安全性（保密性）。

网络安全是系统信息安全的一部分，一般会根据系统架构及其通信网络来构建分层的网络安全架构，根据不同的网络层次来构建出系统的网络安全纵深防御体系。汽车电子电气架构中不同控制单元的功能由内到外基于整车通信网络也可以分为不同层次，从而构建整车电子电气网络的纵深防御体系。如下汽车电子网络安全的参考架构。

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

HSM是Hardware Security Module的缩写，硬件安全/安保模块，是微控制器上专门用于实现加解密算法的一个独立模块，你可以理解为它是一个“信息安全岛”（Security Island）。HSM一般会有一个独立的CPU，专门用来进行加解密运算，还有一些针对特定算法（如AES-128、SHA-256等）的硬件加速器(crypto engine)，它相当于给ECU提供了一个可信计算平台。

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

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

根据EVITA（E-safety vehicle intrusion protected applications）项目给出的HSM基本结构，将HSM分为安全存储、硬件密码加速和应用核心三部分组成，如下。

根据HSM在汽车电子不同网络层次的应用，EVITA进一步把HSM分为三个等级/类别：

1）EVITA full HSM。对应结构如下：

2）EVITA medium HSM。对应结构如下：

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

3）EVITA light HSM（或是EVITA small HSM）。对应结构如下：

其中，EVI-TA full HSM主要用于V2X的通信单元，以及中央网关；EVITA medium HSM用于ECU之间通信场景的ECU；EVITA light HSM则用于传感器、执行器。

light HSM只包含基于AES-128的对称加解密模块，以满足传感器和执行器在成本和效率方面的严格需求（消息大小、时间、协议限制、处理器能力等）。基于light HSM，使得传感器和执行器能够保证通信数据的真实性、完整性和机密性。另外，同full和medium HSM相比，light HSM没有提供独立的处理和存储单元，应用处理器和应用软件可以完整访问所有的密码数据。

为此，可以考虑对light HSM进行安全增强，提供内部的非易失性存储器和RAM，以及基于AES的伪随机数生成器。这样，light HSM可以更加安全地生成、处理和存储密钥。

目前看到的带HSM的功能安全微控制器芯片的结构大部分是EVITA medium/high HSM类型的，如下Infineon AURIX TC39x系列微控制器集成的HSM结构。

TC39X系列的HSM具备以下特征：

3.2 安全硬件扩展(SHE)

除了HSM模块，一些微控制器芯片内部还部署有安全硬件扩展(SHE)固件，用于扩展微控制器的硬件安全策略。SHE的基本结构如下：

SHE可以提供以下功能：

3.3 示例—安全板载通信（SecOC）

接下来以AUTOSAR中的安全板载通信(Secure On-board Communication-SecureOC)功能为例来看下芯片中集成的HSM在车载领域的实际应用。

安全板载通信（SecOC）模块的目的保证通过汽车通信网络交换信息的两个或多个ECU之间传输安全数据。

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

由于板间通信对实时性有一定要求，基于效率和成本方面的考虑，ECU之间通信的保护采用对称密码算法具备合理性。

因此，ECU在进行板间通信时，一般使用HSM中“AES128+CMAC”算法来对通信数据进行加密来保证消息来源的真实性和完整性，这是一种“对称加密+消息认证码”的算法，实施步骤参考如下：

1）在发送端，通过消息摘要算法对数据ID和PDU计算得到对应的消息摘要(MAC)，然后用加密算法(AES128)和私钥(PriKey)对MAC进行加密得到密文S，将密文S和数据一起发出。

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

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

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

到这里，关于芯片的功能安全架构设计话题就要和大家告一段落了。功能安全是流程和技术的结合体，芯片设计过程中既要遵循该领域特定的流程，出于安全合规的考虑相关标准(如ISO26262,ISO21448,ISO/SAE 21434)的一些开发流程和技术要求也要一并考虑，由于芯片通常都是基于SEooC的方式进行，所以芯片的安全设计往往要系统性的考虑功能安全、预期功能安全和信息安全的要求以满足下游相关项系统对于这些安全领域(safety section)的要求。

参考：

[1] ISO 26262-5:2018 Product development at the hardware level

[2] ISO 26262-6:2018, Product development at the software level

[3] ISO 26262-9:2018, Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

[4] ISO 26262-11:2018 Guidelines on application of ISO 26262 to semiconductors

[5] IEC61508-2:2010 Requirements for electrical/electronic/programmable electronic safety-related systems

[6] IEC61508-7:2010 Overview of techniques and measures

[7] MPC5746RRMAD Rev. 3, 06/2017

[8] Specification of SWC End to End Communication Protection Library AUTOSAR Release 4.2.1

[9] 汽车电子网络安全标准化白皮书

[10] AURIX™ Security Solutions https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/aurix-security-solutions/#

[11] 2nd Generation AURIX™ TC3xx Hardware Security Module, HSM Version 2.0

[12] 针对TMS570LS04x 和 03x的安全手册 Hercules™ARM® 安全微控制器的安全手册用户指南

[13] 信息安全工程师教程

个人观点，仅供参考