本文节选自机工社 25 年 3 月出版的《一本书读懂智能汽车安全》，该书是一本全面讲解智能汽车安全的通俗性著作，系统讲解了汽车研发全流程的功能安全、预期功能安全和网络安全，以及三者在汽车研发中的融合之道。本书由 SASETECH 汽车安全社区组织编写，汇聚了博世、蔚来、小鹏、磐时、卓驭、地平线、上汽、吉林大学等业界和学界在汽车安全领域的实践经验和研究成果。
以下是正文：
硬件安全机制是保障硬件随机性失效(功能安全)或攻击(网络安全)能够被探测和控制的重要手段。从功能安全的角度来看，硬件需要具备自我诊断和故障容忍的能力，以确保在发生硬件故障的情况下仍能提供可靠的操作。而从网络安全机制的角度来看，硬件需要采用安全认证和加密技术，以保护车辆内部数据免受恶意攻击。本节将重点介绍硬件在功能安全机制和网络安全机制方面的关键技术和要求，全面介绍智能汽车功能安全、网络安全中不同安全机制的适用性和注意事项。
01.传感器的安全机制
1. 有效范围检查
对于传感器的安全来说，检查其输出的有效范围几乎是最容易实现且最常见的安全机制，同时在传感器的各种安全机制中也是诊断覆盖率最低的，通常被认为只能检测出短路和短电源的故障。该机制的实现方法是：如果一个传感器的输出范围在各种工况下都在 20 至 80 之间，那么控制器如果读到一个小于 10 或者大于 90 的数值，可以认为该传感器的输出不在合理范围内，判断其有故障。诊断覆盖率一般被认为是“低”。
2. 1oo2、2oo2、2oo3 输入比较
利用相互独立的传感器实现投票表决。这种投票表决的安全机制不仅适用于传感器，也适用于处理器和执行器。
常见的投票机制包括 One-out-of-one(1oo1，一选一 )、One-out-of-two(1oo2，二选一 )、Two-out-of-two(2oo2，二选二)、Two-out-of-three(2oo3，三选二)。
在这样的 M-out-of-N 的投票中，第一个数字 M 代表保证表决结果正确所要求的有效传感器数量，后一个数字 N 代表传感器总数。
在 1oo2 设计中，主备组件之间会进行实时数据同步，包括输入、输出和内部状态等。比较机制会定期比较主备组件的输出结果，如果发现结果不一致，可能意味着主组件或备组件出现故障或错误。针对动态信号、变化率有要求的信号，可以实现高诊断覆盖率；但是对于静态信号，通常认为只有中等诊断覆盖率。在判断 1oo2 设计的诊断覆盖率时，我们还需要依赖诊断周期和信号变化周期的关系。
在 2oo3 设计中，其中三个相同的组件执行相同的功能，系统需要至少两个组件在输出上达成一致才被认为是有效的。表 5-11 展示的是 2oo3 系统的输入-输出真值表。
表 5-11 2oo3 系统的输入-输出真值表
在这个真值表中，输入 A、B 和 C 表示冗余组件的输入，输出表示 2oo3 系统的最终输出。 如果至少有两个输入达成一致(即设为 1)，输出也将为 1；如果只有一个或没有输入达成一致(全部设为 0 或只有一个设为 1)，输出将为 0。这种冗余方案确保系统即使其中一个组件发生故障或提供错误的输出，仍然保持可操作性。该方案诊断覆盖率一般被认为是与设计相关，最高可以达到“高”。
3. 测试模式
这种测试是为传感器提供一个定义好的输入，再比较“传感器理论上应该的输出”和“实际的输出”。例如，对于一个电流传感器来说，生成一个变化的电流，再比较该传感器对变化的波形解析出的实际数字结果和预设的结果是否足够吻合，以判断其是否有故障。这个例子中的测试模式需要在系统中实现。有些传感器则将这种测试集成到了传感器内部，自行产生输入并进行判断，输出给外界处理器的就是一个故障状态的信号。该方案诊断覆盖率一般被认为与设计相关，最高可以达到“高”。
4. 传感器相关性诊断
简单来说，该方案就是通过两个类似的传感器的结果比较进行相关性诊断。以温度传感器为例，用电路搭建两个斜率相反的 NTC 电路，一个上拉，一个下拉，如图 5-5 所示。
图 5-5 电路结构
再用模数转换器 (Analogue to Digital Converter，ADC)采集两个输出电压，比较换算后的电压值差异是否在一定范围内，就可以使 MCU 对该部分的温度进行相关性诊断。(如果对 ADC 有独立性要求，需要考虑使用不同的 ADC，并注意 ADC 参考电压的独立性。)该方案诊断覆盖率一般被认为是“高”。
5. 传感器合理性校验
该方案诊断思路与传感器相关性诊断方案类似，不同之处在于合理性校验采用了不同传感器的结果，然后将两者转化为等效值进行校验。以温度传感器为例，在一个系统中，如果某个执行器的电流上升，温度升高，MCU 通过 NTC 也会读到温度升高。但如果其他环境因素保持不变，电流上升而温度反而下降，可以认为两者中有一个可能存在故障。该方案诊断覆盖率一般被认为是“中等”。
02.控制器及周边器件的安全机制
1. 时钟的安全机制
看门狗是一种用于监控 MCU 程序是否失控或已停止运行的定时器。如果 MCU 发生失效或故障，我们可以依靠看门狗的独立路径来重启或复位 MCU。看门狗定时器 (WDT)和 MCU 在电路结构上的关系如图 5-6 所示。
图 5-6 看门狗定时器 (WDT)和 MCU 在电路结构上的关系
从功能上看，看门狗分类如下。
(1) 超时看门狗
如果在设定的时间间隔内未收到来自 MCU 的喂狗信号，则看门狗输出复位信号。这种看门狗逻辑最简单，但其诊断覆盖率为低。
这种看门狗的局限在于，如果 MCU 的时钟过快，过早地喂狗，它是无法发现的。
注：大家常说的“喂狗”其实是指：用信号触发看门狗，使其计数器刷新，重新开始计时。
(2)窗口看门狗
窗口看门狗相比超时看门狗增加了闭合窗口时间段的设计，即在此时间段外不允许接收喂狗信号。
如果在设定的时间间隔内没有接收到来自 MCU 的信号，或过早接收到来自 MCU 的信 号 (或者多个类似信号)，看门狗定时器则会判断 MCU 发生故障并输出复位信号。
图 5-7 很好地解释了过早或过晚喂狗后看门狗复位的逻辑。窗口看门狗的诊断覆盖率为中等。这种看门狗的局限在于，如果 MCU 内部的算术逻辑单元(Arithmetic Logic Unit，ALU) 发生问题，它是无法发现的。
(3) 问答看门狗
这种看门狗通常基于时间窗口。 MCU 根据“看门狗发来的问题”或者“上一次回答的答案” 或者“预设的序列”向看门狗发送这次的答案。看门狗根据 “MCU 发送的答案与预定数据是否匹配”以及“是否在时间窗口内”来判断 MCU 是否正常工作。诊断覆盖率被认为是“高”。
图 5-7 过早或过晚喂狗后看门狗复位的逻辑
如果从时钟源上划分，看门狗分类如下：
- 独立时钟源的看门狗。这种看门狗有独立的时钟源，才被认为能提供诊断覆盖。
- 非独立时钟源的看门狗。非独立时钟源的看门狗一般被认为连低诊断覆盖率都达不到。如果从看门狗的位置是否和 MCU 在同一个 Die 上划分，看门狗可以被分为外部看门狗、内部看门狗。
通常，只有外部看门狗才被认为能提供诊断覆盖。因为 MCU 的故障很可能也会影响内部看门狗，即两者很可能存在共因失效，导致 MCU 发生问题时，内部看门狗无法触发 RESET。
2.存储的安全机制
(1) Parity
Parity 分为奇校验和偶校验。
- 奇校验：数据位和奇校验位所有位上的 1 相加为奇数。
- 偶校验：数据位和偶校验位所有位上的 1 相加为偶数。
当包括奇偶校验位在内的奇数个位发生错误时，奇偶校验可以检测到数据传输发生错误。
奇偶校验只需要一位就可以对数据进行校验，但只能发现是否有错误，不能定位错误的具体位。且当有偶数个位发生错误时，无法发现错误，诊断覆盖率为低。
(2) ECC
ECC (Error Correcting Code，纠错码)可检测并在某些情况下纠正受保护的数据中的错误。ECC 使用固定数量的码位。ECC 的位数取决于受保护的数据位数。当数据或其 ECC 码中的特定数量的位损坏时，ECC 可以检测错误。通常，ECC 可以纠正数据或其 ECC 码中的一些错误。 ECC 的诊断覆盖率取决于冗余位数，一般认为 ECC 的诊断覆盖率水平可以达到高。
(3) Checksum
Checksum 是指传输位数的累加。在传输结束时，接收方可以根据该数值判断是否正确接收了数据。如果数值匹配，说明传送正确。校验和一般用于通信中，特别是远距离通信，以保证数据的完整性和准确性。
Checksum 诊断覆盖率与被保护的数据和 Checksum 的长度有关。 一般认为，Checksum 诊断覆盖率水平可达到高。
数据发送方生成 Checksum 的步骤如下。
- 将需要数据中的 Checksum 位设为 0。
- 数据按每 2 Byte 划分开来，每两字节组成一个 16bit 的值，若最后有单字节的数据， 补 1 Byte 的 0 组成 2 Byte。
- 将所有的 16bit 的值累加到一个 32bit 的值中。
- 将 32bit 值的高 16bit 值和低 16bit 值相加，得到一个新的值，若新的值大于 0Xffff，再将新的值的高 16bit 与低 16bit 相加，直到值小于等于 0Xff。
- 将第四步计算得出的 16bit 值按位取反(即取补码)，即可得到 Checksum 值，存入相关字段即可。
数据接收方校验的步骤如下。
- 数据接收方把接收到的数据按发送方的方法进行累加和取反。
- 校验结果为零表示校验通过；否则，校验不通过。
(4) CRC
CRC(Cyclic Redundancy Check，循环冗余校验码)由数据 nbit 和校验码 kbit 构成。n+k 为循环冗余校验码的字长，又被称为“(n+k，n)码”。数据序列之后的 kbit 校验码与 nbit 数据之间存在特定的关系。如果因失效等原因使 nbit 数据中的某一位或多位发生错误，这种关系就会被破坏。因此，通过检查这一关系，可以实现对数据正确性的检验。
CRC 的诊断覆盖率与被保护数据的长度、 CRC 的位数以及多项式种类有关。一般认为，CRC 诊断覆盖率水平可达到高。
(5) Memory Replication
Memory Replication(模块备份)是功能安全中的一种高诊断覆盖率的安全机制，其核心理念是通过对关键或高风险模块进行冗余设计，使两个或多个相同或不同的模块实现同样的功能，并且在运行时进行比较和切换，以防故障发生。
以 Double Memory with Hardware or Software Comparison(通过硬件或软件的双份内存数据比较方法)为例，通常会将地址空间复制到两个不同的内存中，这样就有了两份相同的数据。第一个内存正常工作，第二个内存与第一个内存同时工作，但不影响程序运行。每次访问内存时，都会比较两个内存的输出，如果发现不一致，就说明有错误发生，并且会给出提示。这种方法可以提高诊断覆盖率水平，也就是检测错误的能力，但需要注意考虑共因失效。
但是 ，Memory Replication 会极大地消耗硬件资源，且一般使用三模冗余(Triple Modular Redundancy， 三个模块执行相同的操作)，将多数相同的输出作为整个系统的正确输出。该方法只有在安全性和鲁棒性要求极高的系统中才会使用。 一般认为，Memory Replication 的诊断覆盖率水平可达到高。
(6) Memory BIST(MBIST)(写全 0 和全 1 )
MBIST 是一种结构性 DFT 技术，将芯片的测试结构置于芯片内部。MBIST 电路通常包括测试向量生成电路、BIST 控制电路和响应分析电路三部分。通过系统上/下电运行来检测内存单元中的永久性故障，以防随机故障潜伏在内存单元中。
(7) MMU/MPU
MMU(存储器管理单元)的主要功能是将输入地址转换为输出地址。此转换基于地址映射和内存属性信息，这些信息可从存储在内存中的配置表和转换表中获得。MMU 提供的功能可以帮助软件实现内存分区，即所有对内存地址的访问都需要经过 MMU 中的表格进行检查或转换，使得软件无法直接访问物理地址，而是通过虚拟地址访问。同时，MMU 提供基于硬件的存储器访问授权，从而实现不同进程任务的空间隔离。
MPU(存储器保护单元)是位于存储器内部的一个可编程区域，它将内存划分为具有特定权限和访问规则的多个区域，定义了存储器的属性和存储器的访问权限。
MPU 主要实现的保护如下。
- 可以将内存划分为特权区域和普通区域，普通用户禁止访问特权区域，以此保护特权区域中的数据。
- 设置某区域为只读，可以防止安全相关的数据被篡改。
- 检测堆和栈的溢出以及数组是否越界。
MMU/MPU 对于非法访问相关的失效，诊断覆盖率水平为高。
3. 电源的安全机制
对于电源的安全机制，大家要区分一级电源和二级电源。一级电源就是我们常说的 12V 电源，是整个控制器的输入。二级电源指的是通过 DCDC 或低压差线性稳压器(LDO) 将 12V 电源转化为 5V、3.3V、1.8V 等电源供控制器内部使用。对于一级电源，除了有 EMC 的要求外，通常也要求对电压进行采集监控。比较复杂的是对二级电源进行监控。
(1) PMIC/SBC
对于电源的监控，最常见的安全机制是使用自带安全机制的 PMIC/SBC。一般大家常说的 ASILD 电源芯片就是指这类 PMIC/SBC。图 5-8 所示为英飞凌某款电源芯片架构中体现的安全机制。注意，这里芯片厂商的措辞一般很严谨，一般都不会说这颗芯片是 ASILD 芯片，而是会说 Enables ASILDon System Level 或者 Safety System Basis Chip Fit for ASILD。
其中，比较常见的安全机制如下。
- 对具有独立参考源(额外的 Bandgap) 的所有输出进行 UV (欠压)/OV (过压)监控。
- 内置的自检功能用来确保相关安全机制的正常运行。
- 用于进入安全状态的控制和硬件引脚。
- 其他用来监控 MCU 的安全机制，比如集成外部看门狗。
图 5-8 英飞凌某款电源芯片架构中体现的安全机制
对于满足不同 ASIL 等级要求的 PMIC，它的安全机制也有所差别。比如常见的 FS8400 (ASILB)和 FS8500(ASILD)芯片在安全机制上的差别比较可以参考图 5-9。
(2) ADC (对于非 PMIC 的高精度补充)
如果一些电源的功率/效率要求较高，对 Buck Boost 电源的数量需求较多，设计中可能不会使用 PMIC ( 因为 PMIC 一般会自带较多 LDO 电源 ，这些 LDO 电源就被浪费了)。那么，如果这些电源不是用于 MCU 供电，可以考虑使用 ADC 来监控它们。需要注意的是，对于被检测的电源和参考电源，必须做好共因分析。
(3) 比较器(对于非 PMIC 的低精度补充)
同用 ADC 来做监控的场景类似，一些不适合用 PMIC 的电源如果对于诊断的精度要求比较低，也可以用比较器来监控输出。再将比较器的输出作为 SafetyPin 去执行故障响应。同时，由于不需要软件的逻辑判断，这种纯硬件的安全机制响应速度快，适合用于对于 FTTI “预算紧张”的设计。同 ADC 一样，需要注意的是对于被检测的电源和参考电源一定要做好共因分析。
图 5-9 FS8400(ASILB)和 FS8500(ASILD)芯片在安全机制上的差异比较
4. 处理单元的安全机制
(1)锁步核
锁步核是针对芯片的一种常见的用于实现高诊断覆盖率的安全机制。它的实现方法是：
两个核运行同样的程序，将结果输入一个比较逻辑，周期性地比较两个核的输出结果是否相同。如果相同，则继续运行；否则，可以采取满足安全要求的重启或其他故障恢复机制。如果在一段时间后错误无法恢复，则需要在指定的安全时间内进入故障安全状态。
双核锁步是实现锁步核的一种方法。如图 5-10 所示， 一个芯片中包含两个相同的处理器。一个作为主处理器，一个作为从处理器。它们执行相同的代码并严格同步，主处理器可以访问系统内存并输出指令，而从处理器不断执行主处理器获取的指令。从处理器产生的输出(包括地址位和数据位)发送到比较逻辑模块，由主处理器和从处理器总线接口的比较器组成，检查它们之间的数据、地址和控制线的一致性。 一旦输出不匹配，通常会标记故障并执行重启。需要注意的是，虽然我们可以检测到两个总线的不一致，从而发现其中一个处理器存在故障，但这时候并不能确定是哪一个处理器存在故障。这种架构的好处是使得 CPU 自检独立于应用软件，不需要执行专门的指令集自检，实际运行的软件指令在每个时钟周期都进行比较，只需要测试软件用到的 CPU 资源。然而，这种架构不会对内存和总线进行检测，因此需要增加单独的检测方法，以避免两个处理器的共因故障。
图 5-10 典型双核锁步架构
在实际应用中，延迟锁步是一种实现方法。如图 5-11 所示，与双核锁步不同的是，在芯片设计过程中，其中一路核的输入信号路径上设置了 N 个时钟周期的延迟，而在另一路核的输出信号路径上也延迟 N 个时钟周期，然后在统一的比较逻辑模块上检查它们的数据一致性。 如果发现不一致，通常会标记故障或者重启。除了继承双核锁步的好处外，这种方法还可以大大降低两个 CPU 同时发生共因故障(如噪声脉冲)的概率。当然，从实现难度上来说，延迟锁步比双核锁步更加困难。
(2) 基于软件的指令集测试
STL(Software Test Library)是功能安全相关软件的测试库，通常包含一组测试函数。每个函数针对一个或多个指令集进行测试，并返回测试结果。
图 5-11 延迟锁步架构
STL 可以实现对永久性故障的诊断覆盖，同时最大限度地减小对系统可用性的影响。它的好处一般体现在以下几方面。
- 可通过选择不同的测试集来实现对逻辑模块的诊断，以满足不同的诊断覆盖率要求。
- 可灵活选择测试集及运行时间间隔，以满足不同的应用场景需求。
5. 芯片系统层级安全机制
(1) 测试模式
在图像处理中，测试模式通常指的是用来检测 ISP 是否有故障的一种安全机制。例如在 IP 设计中，ISP 通常会在周期内生成所需的测试图像，通过将测试图像与预设结果进行比较来判断逻辑是否出现问题。如果结果比较没有通过，系统会发送相应的中断以表明逻辑出现问题 。
(2) 系统内测试(In System Test)
系统内测试是指在芯片上电或下电时执行的一系列诊断测试，用于检测硬件和软件的故障模式及影响。对于功能安全而言，进行上电或下电自检通常是为了防止潜伏故障。上电或下电自检有多种方法，根据自检对象和时间，可分为以下几类。
- 软件自检：利用预先设置好的或自动生成的数据或代码，对物理存储、运算器及控制器进行检测。
- 硬件逻辑自检(LBIST):在控制单元内部集成专用自检硬件，最常见的就是内建自测试 (BIST) 。通过在芯片设计中加入额外自测试电路，在测试时从外部施加控制信号，运行内部自测试硬件和软件，以检查电路缺陷或故障。测试模式一般是 DFT 工程师利用自动测试设备(Automatic Test Equipment，ATE)结合失效模型和自动测试模式生成(Automatic Test Pattern Generation，ATPG)技术来满足相应的诊断覆盖率要求。诊断范围根据覆盖的目标、大小等指标来设计。
- 内存自检(MBIST)：MBIST 用于在系统上电或下电时，或系统运行过程中检测内存的硬件故障。对于 ASIL C/D 的系统，除了必要的上电自检外，我们建议在满足 FTTI 的情况下进行周期性自检。对于 ASILB 的系统，通常上电自检即可满足设计要求。
(3) 安全岛
一般在车规级 SoC 中，除了使用 Cortex-A 核、NPU、GPU、数字信号处理器(Digital Signal Processor，DSP)等高性能核处理特定任务外，我们还需要一个高实时性内核。目前，大多数 SoC 安全岛都会集成一组双核锁步的 Arm Cortex R-52 内核。它的主要功能是检测和处理 SoC 内部其他子系统的故障，并将故障上报给控制器。当然，也有部分 SoC 安全岛集成多组 Arm Cortex R 核，直接取代控制器中外挂的安全 MCU。安全岛通常独立于 SoC 中的其他子系统，具有独立的时钟、供电机制优先级较高的中断机制。
(4) 温度和功率监控
功能安全中的温度和功率监控是指对系统的温度和功率进行实时测量和控制，以保证其正常工作，避免过热或过载等危险情况发生。各大车规级芯片公司都有类似功能的芯片。这些芯片可以提供高精度的电流、电压、功率和温度测量，并支持功能安全。对于电池管理系统 (BMS) 来说，热管理主要是管理电芯的化学反应，从而控制相关的电池性能。然而，目前对于 BMS 来说，大多仅仅是传递当前电芯的温度给车辆控制单元(VCU)。
工艺、电压和温度 (PVT)传感器是半导体 IP 电路模块，通常嵌入芯片内部，主要用来感知芯片的动态操作环境(即电压和温度)以及静态条件(即工艺)。
03.执行器的安全机制
执行器的监控通常分为两类。
- 一种是不介入执行器的常规运作，以“旁观者”的角度进行监控。该类监控可实现在线监控(时域表现)和物理参数监测(以“旁观者”的角度进行监控),比如常见的位置传感器，用来监控电机(执行器)是否将目标物推动到相应的位置。
- 一种是以测试模式为主要方式进行监控。该类监控比较适合那些平时不用运动的执行器，比如在车辆启动的时候或者非工作区间周期性地让执行器做特定的动作，以判断其是否正常。
04.线束连接的安全机制
1. HVIL (高压互锁)
对于高压线束来说，如果其高压回路的完整性遭到破坏，容易引发非预期的高压暴露，从而发生电击伤害事故。所谓高压互锁，是指用低压信号来监视高压回路的完整性。典型的 HVIL 连接器结构如图 5-12 所示。通过使用一套比高压先接通、后断开的低压信号来检查所有与高压线束相连的各组件的电气连接完整性，如图 5-13 所示。比如，当高压回路完整时，低压信号读到 12V 的电压值；当高压回路不完整时，低压回路也不完整，电流传递不到被读取的位置，因此读到的电压值为 0V。
图 5-12 典型的 HVIL 连接器结构
2. 接插件在位检测
对于接插件中包含通信信号的，可以通过通信信号适时与否来判断接插件是否有问题。但是，对于某些系统中没有通信信号的接插件，可以通过接插件在位检测来实现诊断需求。一种方法是选取接插件公头或者母头最靠边的两个引脚，分别让它们串联一个电阻到地。然后在对应的母头或者公头的引脚上也串联一个电阻到参考电压，如图 5-14 所示。采集这些引脚的电压值，如果接插件松动，那么被采集的电压会被拉到参考电压。通过电压的变化可以判断接插件是否在位。
图 5-13 HVIL 连接器的互锁方案示意图
图 5-14 接插件在位检测方案
05.通信的安全机制
E2E(End-to-End)保护是一种端到端的通信保护机制。这里的“端到端”既包括控制器与控制器(比如 CAN/Ethernet)之间，也包括控制器内部模块与模块(比如 RTE 模块)之间。
注意，E2E 通常被认为属于功能安全的范畴，而非信息安全的范畴，在传输中不加密，而是明文传输。E2E 主要是保证数据不被破坏，系统正常执行。
AUTOSAR 提供了一系列 E2E 配置文件，每种配置文件都有特定的机制、参数和数据格式。设计人员需要根据信号数量的多少和安全要求的高低进行配置文件的选择。举例来说，对于 ASILD 的长数据，OEM 通常会选择配置文件 4。但无论如何，大家都是在下面这几种机制中进行选择和组合。
- CRC:发送方基于数据计算一组校验码，随数据发送给接收方。
- 计数器：在每次传输请求时，发送方递增计数，接收方检查计数器值是否有递增。
- 超时监控：通过接收方计数器的值是否增加来最终确定。
- 数据 ID：每个发送方及对应的接收方端口都有一个唯一的数据 ID，用于 CRC 计算。
有些初学者可能会以为 CRC 就是 E2E，这里澄清一下，CRC 是一种方法，只是 E2E 保护机制中的一种。
06.非常规硬件器件的安全机制设计
还有一些硬件的功能安全无法套用上面的机制，或者说我们无法在常见的最佳实践中找到答案。这时就需要安全工程师进行以下思考。
- 在硬件正常工作和不正常工作期间，整个电路会出现哪些不同的物理现象。通过监控这些物理现象，可以侧面对硬件器件进行监控。
- 如果缺少硬件分析的能力，可以和硬件工程师一起，用示波器的探头在 PCB 上找一找不同。比如需要对“一排并联的用于产生特殊波形的电路中的输出端电容”进行诊断， 由于这个波形很特别，如果要用高速 ADC 进行监控，代价非常大。但是由于已知：当输出端的电容开路时，每次产生的能量值不变，总容值 C 减小，电压 V 相应升高，这时可以用一个比较器去比对输出端的电压和预设的阈值，从而判断输出端的电容是否有故障。同时，这个比较电路可以诊断许多产生特殊波形电路中的元件。
07.常用的硬件信息安全机制
1. 安全硬件扩展
2006 年，HIS 发布了一份文档，描述了 HIS 安全模块标准的需求。该文档内容包含错误检测、授权和真实性保护机制。ESCRYPT 进一步与奥迪、宝马以及半导体供应商(如飞思卡尔，现在的 NXP) 合作，将其发展成为一个开放标准，即 SHE 标准，并于 2009 年 4 月公开发布。这个规范已被广泛接受，许多针对汽车行业的微处理器都支持这个规范。
SHE(Secure Hardware Extension，安全硬件扩展)是对任何给定微控制器的片上扩展。它倾向于将对加密密钥的控制从软件领域转移到硬件领域，从而保护这些密钥不受软件攻击。 然而，它并不意味着要取代 TPM 芯片或智能卡等高度安全的解决方案。
当前，硬件器件安全机制设计的主要目标如下。
- 保护加密密钥免受软件攻击。
- 提供可信的软件环境。
- 让安全性只取决于底层算法的强度和密钥的机密性。
- 实现分布式密钥。
- 保持高灵活性和低成本。
SHE 基本上由三个构建块组成：一个是加密密钥和其他相应信息的存储模块，一个是块密码的实现模块，一个是将各部分连接到微控制器 CPU 的控制逻辑模块。SHE 可以通过几种方式实现，例如有限状态机或小型专用 CPU 核心。
SHE 支持的功能如下。
- AES:对于数据的加密和解密，SHE 支持 ECB 模式和 CBC 模式，具体参考 NIST800_38A。 数据输入、输出和密钥输入以及任何中间结果可能不能被 CPU 直接访问，但必须由 SHE 的控制器逻辑根据策略授予访问权限。
2) CMAC：MAC 的生成和校验必须按照 NIST800_38B 定义的 AES-128 作为 CMAC 实现。
3) Hash：将 AES 作为分组密码的 Miyaguchi-Preneel 结构用作 SHE 中的压缩函数。
4) PRNG/TRNG：用于生成伪随机数或真实随机数。
5)安全存储如下。
- NVM：证书和密钥存储在应用程序本身无法访问的专用非易失性存储器(NVM) 中，主 ECU 密钥(由 OEM 设置，允许更改其他密钥)、引导 MAC 密钥(启用特定引导请求并建立安全引导)、引导 MAC (用于引导代码的身份验证)和 PRNG 种子(PRNG 的起始值)存储在 NVM 中。一般用途的密钥也可以存储在 NVM 中。
- RAM：RAM 用于存储 RAM 密钥(用于任意操作的临时密钥)、PRNG 密钥和 PRNG 状态(保持 PRNG 的状态)。
ROM：ROM 用于秘密密钥(导入/导出其他密钥的唯一密钥，必须在生产时使用片外 TRNG 创建)存储和唯一密钥(UID，用于验证 MCU 的唯一标识符)存储。这两个密钥必须在生产过程中注入。
6)安全启动：上述功能在启动时提供安全引导，确保程序的完整性和可靠性。
2. 硬件信息安全模块
EVITA 是欧盟在第七个研究和技术开发框架计划内共同资助的一个项目。它的目标是设计、验证和原型构建安全的车载网络，以保护安全相关组件不受篡改和敏感数据不受损害。因此，EVITA 为基于 V2X 通信的电子安全辅助设备的安全部署提供了基础。
EVITA 专注于车载网络保护，侧重于保护车辆与外界的通信。
EVITA 最高层级的安全目标如下。
- 防止未经授权操作车载电子设备。
- 防止未经授权修改车辆应用程序，特别是安全和移动商务应用。
- 保障车辆驾驶者的隐私信息。
- 保护车辆制造商和供应商的知识产权。
- 维持应用程序和安全服务的运作。
为了节约成本和提高灵活性，EVITA 定义的不同等级的 HSM 见表 5-12。它们可以满足不同的成本约束和安全需求。
- 完整 HSM 保护车载域免受 V2X 通信带来的漏洞，这包括用于创建和验证电子签名的非对称加密引擎，通常要求验签能力超过每秒 2000 次。完整 HSM 提供了最高级别的功能、安全性，以及所有不同 HSM 变体的性能保障。
- 中型 HSM 用于保证车载通信安全。中型 HSM 类似完整 HSM，但微处理器性能较差且不包含非对称加密硬件引擎。然而，它能够在软件层面执行一些时间优先级不那么高的非对称加密，例如建立共享秘密。
- 轻型 HSM 用于确保 ECU 与传感器以及执行器之间的通信，仅包含对称加密引擎和 I/ O 组件，以满足成本和效率的需求。
图 5-15 展示了在汽车车载网络中，使用三类 HSM 保护其安全关键组件的示例。仅靠一块 HSM 保护与外界的无线通信是不够的，因为系统的行为还依赖于从车辆内其他组件接收到的消息。如果这些组件没有得到充分保护，攻击者就可能利用这些漏洞进行攻击。
表 5-12 EVITA 定义的不同等级的 HSM
图 5-15 汽车车载网络中不同 HSM 方案的示例
3.可信执行环境
OMTP(Open Mobile Terminal Platform)于 2006 年提出了一种双系统解决方案，即在同一个智能终端下，除了多媒体操作系统外，再提供一个隔离的安全操作系统。这个运行在隔离硬件之上的安全操作系统专门处理敏感信息，以保证信息的安全。该方案即可信执行环境(Trusted Execution Environment，TEE)的前身。
基 于 OMTP 的方案，ARM 公司于 2006 年提出了一种硬件虚拟化技术 TrustZone 及其相关硬件实现方案。TrustZone 是支持 TEE 技术的产品，是通过 ARM 架构安全扩展引入的，而 ARM 也成 了 TEE 技术的主导者之一。
GlobalPlatform(全球最主要的智能卡多应用管理规范的组织，简称 GP) 从 2011 年起开始起草制定相关的 TEE 规范标准，并联合一些公司共同开发基于 GP TEE 标准的可信操作系统，如 图 5-16 所示 。因此，如今大多数基于 TEE 技术的 Trust OS 都遵循了 GP 的标准规范。
图 5-16 基于 TEE 标准的可信操作系统解决方案示意图
TEE 通常用于运行高安全操作、保护敏感数据、保护高价值数据等。
- 高安全操作：如安全键盘密码输入、指纹输入、用户认证、移动支付。
- 保护敏感数据：如用户证书私钥的存储、指纹数据存储。
- 保护高价值数据：如 DRM (数字版权保护)等。
与 TEE 相对应的是 REE(Rich Execution Environment)，一 般称 TE 和 REE 为安全世界和非安全世界。Linux 运行在非安全世界上，但某些对安全性要求较高的操作，例如指纹比对、支付时使用私钥签名等，需要在安全世界中进行。安全世界和非安全世界通过一种被称为 Monitor Mode 的模式进行转换。
4. 可信安全模块
(1) 什么是 TPM
TPM(Trusted Platform Module，受信任的平台模块)是加密协处理器，其中包含随机数生成、加密密钥的安全生成，以及它们的使用限制功能。它还包括诸如远程证明和密封存储等功能。TPM 规范由受信任的计算组 (TCG) 制定并公开发行。最新版本 TPM 2.0(2014 年 10 月发布)主要对规范进行了重新设计。该版本添加了新的功能并修复了 TPM 1.2 版本的缺陷。
(2) 为什么选择 TPM
采用 TPM 的计算机可以创建加密密钥并对其加密。这样，加密密钥只能由 TPM 进行解密。此过程(通常被称为封装或绑定密钥)可以帮助保护密钥，避免泄露。每个 TPM 都有一个主封装密钥(称为“存储根密钥”)，它存储在 TPM 的内部。在 TPM 中创建的密钥的隐私部分从不暴露给其他组件、软件、进程或者人员。
采用 TPM 的计算机还可以创建一个密钥(该密钥不仅可以被封装，还可以绑定到特定平台)。只有当平台度量的值与创建该密钥时的值相同时，才能解锁这种类型的密钥。此过程称为将密钥封装到 TPM。解密过程被称为“解封”。TPM 还可以对在 TPM 外部生成的数据进行封装和解封。使用这种封装的密钥和软件(例如 BitLocker)，可以锁定数据，直到其符合特定的硬件或软件条件为止。
借助 TPM，可保持密钥对的私钥部分独立于操作系统控制的内存。我们可以将密钥封装到 TPM 中，并且在解封并释放该密钥以供使用之前，根据系统的状态提供某些保证。因为 TPM 使用自身的内部固件和逻辑电路来处理指令，所以它不依赖于操作系统，也不会受操作系统或应用程序中可能存在的漏洞影响。
(3) TPM 标准
TPM 规范自推出以来，经过多次版本迭代，中间产生了 ISO/IEC 11889—2009(TCG 1.2)以 及 ISO/IEC 11889—2015(TCG 2.0)两个国际标准。该规范定义了 TPM 的架构、结构、命 令与支持途径等内容。
在 TPM 中，“可信”指的是确定身份的可预期行为。具体来说，TPM 提供的功能包括基于信任的引荐、认证、测试与鉴证、存储空间的加密与保护、完整性测量与报告等。
TPM 规范对加密算法、引擎、随机生成器、管理及授权、远程证明等内容进行了定义，并定义了软件接口 。TPM 典型架构如图 5-17 所示。
● 非易失内存可由系统芯片提供，数据在受保护的情况下来往于非易失内存。此种情况下，TPM 中保护非易失内存数据副本
图 5- 17 TPM 典型架构
TPM1.2 版本主要解决以下问题。
- 设备识别 。
- 密钥安全生成 。
- 密钥安全存储 。
- NVRAM 存储 。
- 设备健康证明 。
TPM 2.0 版本还拓展了以下功能。
- 算法灵活性。
- 增强授权。
- 密钥快速加载。
- 非脆弱性 PCR。
- 灵活管理。
- 按名称识别资源。
车规级 TPM 芯片的应用方案可参考图 5-18。
图 5-18 车规级 TPM 芯片的应用方案
SLI9670 是一款经过质量强化的 TPM，在智能汽车中有特殊用途，基于使用了先进硬件网络安全技术的防篡改安全微控制器。作为交钥匙解决方案，它根据最新的 TCG 系列 2.0 规范，闪存了安全编码的固件，提供丰富的安全功能集，如密钥管理、身份验证、签名功能(签名/验证)、加密/解密、安全日志记录和安全时间。 SLI 9670 符合汽车 AEC-Q100 标准，是远程信息处理、网关、多媒体主机和其他安全要求很高的 ECU 中汽车应用的理想解决方案。 该 TPM 还根据通用标准 EAL4+进行了安全认证。
TPM 就像门卫一样，特别保护车辆的外部接口，例如车载信息娱乐系统或远程信息处理单元中的接口。它可检查数据发送方和接收方的身份，例如制造商的后端服务器，也可对数据进行加密和解密，并帮助确保只有驾驶员或制造商真正想要的数据才能进入汽车。
功能安全所需的加密密钥存储在 TPM 中，就像存储在保险箱中一样。
英飞凌在经过特殊认证的安全环境中导入初始密钥。由于所有其他密钥都可以在 TPM 内生成、使用和存储，因此它们不必离开 TPM，从而可以防止被网络监控。TPM 还可以抵御物理攻击，即使有人从车上取下芯片，这些密钥也不会被读取。
TPM 的优势如下。
- 基于市场领先的安全专业知识的高端防篡改安全解决方案，保护最敏感的资产(密钥、IP、数据和业务案例)。
- 基于经验证的技术降低安全风险(标准化和市场认可的安全解决方案，TPM2.0 预先编程了丰富的安全功能)。
- 由于提供了广泛的集成安全功能(如专用密钥管理)，可随时使用，因此具有高度灵活性。
- 安全环境中的密钥注入实现了物流链的成本节约。
- TPM 固件的可更新性实现了长期的加密灵活性和可持续性。
- 通过可用的开源驱动程序(例如 Linux 驱动程序)，实现了简单且经济高效的系统集成。
未来信息的流动需要交换大量数据。智能汽车将实时交通信息发送到云端，或从制造商 处无线接收更新，以经济有效的方式快速更新软件。无论是汽车制造商还是汽车中的各个组件，它们数据的发送器和接收器都需要使用加密密钥进行身份验证。这些关键密钥在 OPTIGA TPM 中像在保险库里一样受到特别保护，不会受到逻辑和物理攻击。
此外，将初始密钥结合到车辆中对于智能汽车制造商来说是特别敏感的时刻。使用 TPM 时，此步骤可在英飞凌认证的生产环境中执行，之后，密钥被保护，不再需要在全球分布的价值链的各个阶段采取特殊的安全措施。
TPM 同样生成、存储和管理用于车辆内通信的其他安全密钥。它还可用于检测车辆中的故障或被操纵的软件和组件，并在发现问题的情况下由制造商启动故障排除机制。
虽然车辆的平均使用寿命为 12 至 15 年，但安全功能和算法仍在不断开发和增强。TPM 的固件可以通过远程访问进行更新，因此它提供的安全机制(包括加密机制)可以持续更新。
5. 防侧信道攻击
(1) 侧信道攻击概念
侧信道攻击是利用计算机不经意间释放出的信息(如功耗、电磁辐射、电脑硬件运行声等)进行破译的攻击模式。侧信道攻击是一种硬件功能安全攻击类型，主要通过非预期的信息泄漏来间接窃取信息。
图 5-19 展示了一个侧信道攻击的例子。
图 5-19 侧信道攻击的例子
侧信道攻击涉及以下几方面。
- 功耗方面：所有电子设备都通过电源轨供电。在基于功耗的侧信道攻击中，攻击者会在设备运行期间监控其电源轨，以获取电流消耗或电压波动，从而窃取信息。
- 电磁 (EM)辐射方面：正如法拉第定律所定义的，电流会产生相应的磁场。基于 EM 的侧信道攻击是通过监控设备在运行期间发出的 EM 辐射来窃取信息。
- 时序方面：在加密实现中，不同的数学运算可能需要不同的计算时间，具体取决于输入、键值和运算本身。基于时序的侧信道攻击是试图利用这些时序变化来窃取信息。
(2) 侧信道攻击的防御对策
侧信道攻击的本质是利用密码实现过程中产生的依赖于密钥的侧信息来实施密钥恢复攻击。因此，防御对策的核心是减弱甚至消除这种侧信息与密钥之间的直接依赖性。实际上，常见的防御对策可以分为掩码对策和隐藏对策两种。具体来说，掩码对策借助秘密共享和多方安全计算，通过引入随机数将密钥分解为多个分组，从而消除侧信息与密钥的依赖性，增强抵抗侧信道攻击的能力；隐藏对策则采用平均化“0”和“1”对应侧信息的差别，降低通过侧信息区分对应数据的可能性，即降低数据的可区分度，以抵抗侧信道攻击。此外，通过在密码实现中插入随机伪操作或者增加噪声，可以将有用信息“淹没”在噪声中，从而提高密码安全性。
总体而言，两种防御对策适用于不同场景。掩码对策易于在密码算法级进行实现，更易于实现；而隐藏对策通常只能在硬件层进行实现，需要改变硬件实现结构，因而较难实现。此外，两种防御对策可以组合使用，以便最大限度地提高密码安全性。
6.安全启动
安全启动也叫 Verify Boot，就是在软件安全启动过程中，前一个部件验证后一个部件的数字签名，验证通过后，运行后一个部件。
网络设备的安全性严重依赖于设备上运行软件的完整性。通常，我们使用信任链来确保软件的完整性。在安全启动期间，每个阶段实行前都会检查下一个阶段。这个过程中有一个特例，即在这一步之前没有任何东西可以进行任何检查，这一阶段被称为“信任根”。
在可信计算体系中，建议信任先拥有可信根，然后建立一条可信链，再将信任传递到系统的各个模块，从而实现整个系统的可信。
安全启动的原理就是“硬件信任锚+信任链”。
目前，安全启动基本上是对安全要求比较高的场景中芯片的必备功能。
(1) MCU 安全启动
在 MCU 中一般采用 OTP(One Time Programming)的方式去实现信任根。任何软件模块在校验失败后都应该禁止该软件运行。
SHE(Secure Hardware Extension，安全硬件扩展规范)中定义了安全启动流程，如图 5-20 所示。
安全启动流程如下。
- MCU 复位后，CPU 启动并运行安全启动程序。
- 安全启动程序来验证应用程序 A：
① 安全启动程序读取安全启动 MAC 密钥，计算应用程序 A 的 CMAC 值 ；
② 安全启动程序比较确认计算结果和应用的 CMAC 值。
- 如果步骤 2 验证通过，则 CPU 运行用户程序 A, 并接着验证应用程序 B。
- 如果步骤 3 的验证通过，则 CPU 执行应用程序 B。
(2) SoC 安全启动
由于操作系统启动时可能需要多级启动镜像，只要其中任意一级镜像未执行安全启动流程，其后的所有镜像实际上都是不可信的。操作系统安全启动流程示意图如图 5-21。
图 5-20 安全启动流程
图 5-21 操作系统安全启动流程示意图
因此，安全启动需要建立安全启动的信任链。在安全启动流程中，每一级镜像都由其前一级镜像执行合法性验证。这样，只要保证第一级镜像是合法的，那么第二级镜像的合法性就由第一级镜像保证，第三级镜像的合法性由第二级镜像保证。如此，整个启动流程的信任像链条一样连接起来，最终保证整个系统的可信性。
(3) 安全启动的信任根
由于信任链建立流程中，镜像合法性是由其前级镜像验证的，那么第一级镜像的合法性如何保证呢?
我们知道，ROM 是一种只读存储器，它只能被编程一次且内容在编程后不能被再次更改。因此，如果在 SoC 内部集成一片 ROM，并在芯片生产时将第一级启动镜像刷到这块 ROM 中，那么就能保证它是可信的。这也是现代 SoC 的普遍制作方法。
由于 SoC 可能会支持不同的启动方式，如 XIP 启动可以直接从外部的 NOR Flash 开始启动。因此，在 ROM 中集成 BootROM 镜像之后，我们还需要保证芯片每次启动时都必须从 BootROM 开始执行，否则攻击者可能通过 XIP 绕过整个安全启动流程。一般情况下，XIP 启动模式在调试阶段用于问题定位。因此，在产品调试完成、安全启动之前，必须关闭该模式。通常，这可以通过 OTP 或 EFUSE 中的特定位实现。
(4) 镜像签名和验签流程
制作镜像签名的基本流程如图 5-22 所示。
1 )使用 Hash 算法生成镜像的 Hash 值 hash(image)。
2 ) 通过镜像发布者的私钥，使用非对称算法对镜像的 Hash 值执行签名流程，并生成其签名值 sig(hash)。
3 )将镜像的 Hash 值、签名值与镜像一起发布，在芯片启动时可通过图 5-23 所示流程验证镜像合法性。
图 5-22 制作镜像签名的基本流程
图 5-23 验证镜像合法性流程
上述流程过程如下。
- 使用非对称算法的公钥和签名值，对镜像的 Hash 值进行验签。若验签通过，则可进一步校验镜像完整性；否则，启动失败。
- 若验签通过，则重新计算镜像的 Hash 值 hash(image)', 并将其与原始 Hash 值 hash(image) 比较，若相等则表明镜像的完整性验证通过，否则启动失败。
(5) 公钥保护
由于验签操作依赖于公钥，若设备上的公钥被攻击者替换成他们自己的，那么攻击者只需用与其匹配的私钥伪造镜像签名即可。因此，我们必须要保证设备上的公钥不能被替换。
一般，SoC 芯片内部会含有若干 OTP 或 EFUSE 空间，这些空间只能被编程一次，且在编程后不能被再次修改。
将公钥保存到 OTP 或 EFUSE 中，可以很好地保证其不可被修改。由于 OTP 空间一般较小，而像 RSA 之类的公钥长度却较长，例如 RSA 2048 的公钥长度为 2048bit 。为 了 节 约 OTP 资源，通常在 OTP 中只保存公钥的 Hash 值 ( 如 sha256 的 Hash 值长度为 256bit)，而将公钥本身附加到镜像中。
在使用公钥之前，只需使用 OTP 中的公钥 Hash 值验证镜像附带公钥的完整性，即可确定公钥是否合法。
END
作者：SASETECH 社区
文章来源：汽车电子与软件
推荐阅读
更多物联网安全，PSA 等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA 技术交流群，请备注研究方向。
