芯片安全知识图谱

01

背景简介

汽车芯片信息安全的必要性：1. 早期由于ECU本身设计的资源有限，信息安全考虑的也比较少，导致自身的防护能力很弱，容易导致黑客攻击。随着智能汽车技术的发展，虽然芯片的数据处理能力不断提升，但如果芯片自身的安全防护能力过于薄弱，将导致芯片运行的固件也很容易受到攻击，比如固件篡改，敏感信息（如密钥等）泄露。 2. 随着智能汽车技术的不断发展，越来越多的政府、行业组织的实践也明确提出智能汽车的安全需要构建在安全的芯片基础上，比如EVITA、HSM已成为智能汽车的安全基础，成为行业默认的标准。

3. 智能汽车功能安全（Safety）和信息安全（Security）在设计阶段也有冲突的地方，比如过度基于软件实现的安全特性，会导致控制指令的延时，影响功能安全特性的实现。因此为了提升产品的性能，以及Safety和Secuirty的强隔离，也必然会要求将更多的信息安全特性集成到芯片里，或者基于芯片的能力来实现。

02

芯片安全知识图谱

芯片安全图谱的两个维度：

1. 一个维度是芯片自身的安全防护能力，比如能抵抗物理侵入式、半侵入式物理攻击；能检测和防御故障注入攻击；以及耳濡目染的侧信道攻击。这就像是一辆坦克自身厚重的钢板，能抵挡普通子弹和炸弹的攻击。物理攻击需要较强的专业能力，比如借助专用的测试仪器，以及可以近距离接触的物理设备。

2. 另外一个维度是基于芯片的安全服务，比如芯片直接固化的密码类算法，密钥管理机制，真随机数生成器，PUF等机制。  

图1：汽车芯片信息安全知识图谱V1.0

 

03

常见的芯片攻击手段

3.1 侧信道攻击

a）概念：利用设备的接口对芯片进行电磁和功耗的分析，无需对芯片进行破坏

b）常见测评、攻击类型：时间分析、功耗分析、电磁辐射分析、光子分析

c）适用对象：集成电路/芯片、智能卡、智能门锁、物联网终端、车载电子等产品

下面是一个针对手机的侧信道攻击（电磁分析攻击），作为一个简单的样例。

图3（图源：https://www.sohu.com/a/165330167_99909589）

d）防护原理：消除和降低侧信道信息与密钥的相关性，常用手段：

掩码技术：引入随机掩码，平衡“0”和“1”分布。

隐藏技术：平均化侧信道信息，降低数据的可区分度。

混淆技术：降低信噪比（有效侧信道信息），如使用随机时钟等，增加侧信道分析难度。

3.2 故障注入攻击

利用故障（电压、时钟等）引起电路出现异常，根据异常信息分析芯片内部的敏感信息；或者直接利用引起电路的异常来改变程序运行等。

常用测评/攻击类型：电压注入、时钟注入、电磁注入、温度注入，激光注入。 案例：故障注入攻击导致安全启动被成功绕开

（信息来源：乐鑫发布关于故障注入和安全启动的安全性公告（CVE-2019-15894)）

故障注入攻击的防护技术：

传感器：专用传感器（电压、频率、温度等）对电压、时钟故障可以起到检测和告警作用

逻辑&时钟冗余：逻辑冗余分为面积冗余和时间冗余。面积冗余是指多分计算逻辑各计算一次，最终对比各个计算逻辑的结果来检查是否有故障注入；时间冗余是指一份计算逻辑计算多次，比较多次的结果来检查是否有故障注入。

金属外壳&特殊封装：通过金属外壳，可以对激光故障注入，电磁故障注入等手段具有一定的抑制作用

逻辑深埋：将关键电路逻辑部署在芯片内层，而不是直接部署在芯片表层，使得故障注入的难度增加

CRC校验

3.3 物理攻击

a）概念：去除芯片封装，对内部电路进行电接触，结合其他攻击手段获取保存在芯片内部的敏感信息

b）常见攻击类型：FIB电路修改/探针攻击、单板级走线篡改/探听、整机攻击。

c）防护技术：

Passive shield：被动屏蔽层，例如在芯片表面构建钝化层，金属屏蔽层，增加攻击者解封装难度

Active shield：主动屏蔽层会构建一个电路检测网，覆盖在关键电路表面检测电路，一旦有损坏，就会发出告警

特殊封装：对电路（芯片）采用特殊封装

信号完整性、机密性保护等：针对单板走线篡改&窃听、总线探针窃听&篡改等，通过对信号完整性和机密性进行保护来应对此类攻击

04

验证辅助的安全特性

1. Hardware Trust Anchor（HTA） - 以软件无法操作的方式保护敏感数据

- 提供加解密功能

2. HTA不同标准：

- SHE

- HSM

- TPM

3. Evita Full-Medium-Light与SHE差异

以下为详细的案例介绍。

4.1 NXP高级加解密引擎1）架构与功能描述：

图4

2）核心能力：

满足HSM Full等级；

芯片内支持4个并发加解密任务（job），每个任务带有资源ID、TZ（Trustzone标记）和任务ID，并能和Trustzone机制配合使用，具有很强的权限控制能力。

4.2 专用算法密码引擎

1）NXP针对Flash读写直接加解密引擎-Bus Encryption Engine，BEE  

图5：BEE 逻辑架构图

总线加密引擎（BEE）被实现为实时解密引擎，用于CPU直接读取并同时解密Flash（FlexSPI接口）中的数据。BEE的主要功能是：

即时AES-128解密，支持ECB和CTR模式

别名内存空间支持，重新映射最多两个单独的区域

针对这两个区域的独立AES密钥管理

基于安全标签的非安全访问的过滤

非法访问检查和过滤

2）NXP针对RAM在线加解密引擎-Inline Encryption Engine

图6 支持的功能：

AES-XTS模式下的DDR加密和解密

QSPI闪存解密，在AES-CTR模式下

I/O DMA直接加密的存储和检索（AES CTR 128）

多核资源域分离

使用专用总线安全地加载片上密钥

差分功率分析（DPA）电阻

检测物理篡改并响应

4.3 小结

1. SHE规范奠定了汽车安全基础，引入了汽车可配置的安全子系统概念

2. EVITA的HSM规范扩展了SHE，并采用了Full，Medium、Light三种规格，从而满足更多场景的要求

3. 如今，OEM正在创建自己的技术规范，包括SHE、EVITA和FIPS 140-2的某些方面，以及区域/行业性特殊要求（比如支持国密算法）

4. 还有一些厂商定义特定的轻量级加密引擎，比如NXP的IEE、BEE、PRINCE算法等

05

启动安全

先讲一个概念：信任链（chain of trust）

在可信计算体系中，建议信任需要先拥有可信根（Root of Trust），然后建立一条可信链（chain of Trust），再将信任传递到系统的各个模块，之后就能建立整个系统的可信链。

安全启动的原理就是硬件信任锚+信任链。

网络设备的安全性严重依赖设备上运行软件的完整性，通常使用信任链确保软件完整性，启动期间每个阶段在执行前检查下一个阶段，如下图所示，这个过程有一个特例，这一步之前没有任何东西可以进行任何检查，此阶段称为信任根（Root of Trust）。

5.1 安全启动

安全启动（Secure Boot）：安全启动也叫Verify boot，就是在启动过程中，前一个部件验证后一个部件的数字签名，验证通过后，运行后一个部件。

图7

目前安全启动基本上是对安全要求比较高的场景下，芯片必备功能。

5.2 可信启动可信启动（Trusted Boot）：也称为Measure boot,就是在启动过程中，前一个部件度量（计算HASH）后一个部件，然后把度量值安全保存下来，比如放到一个集中的部件（或云端），设备启动后的一致性（完整性）的校验由集中的部件负责完成。

图8  

扩展：在IoT领域，以微软为主推出了轻量级的类TPM技术-DICE，就使用了基于硬件信任锚的可信启动方式。

5.3 加密启动

顾名思义，就是存储在flash中的image是密文，启动过程中会先解密再启动，下图是NXP加密启动的流程图：

图9

注： 1.加密启动过程本身没有信任链的构建过程 2.安全启动（Secure boot）、可信启动（Trusted boot）和加密启动（Encryptedboot）三种启动方式并不是互斥的，可以把实际应用场景、性能要求结合起来使用。比如安全启动（Secure Boot）和加密启动（Encrypted boot）相结合，既可以确保启动过程系统软件的一致性（没有加载被篡改过的软件系统），又能确保Flash中的软件image不被逆向破解（因为image已被加密） 3.需要注意的是，如采用加密启动，可以借助前面讲的IEE硬件加密引擎，就可以显著提升解密性能，从而提升启动。    

06

安全存储

6.1 OTP存储器

一次性可编程存储器（On Chip One Time Programmable ROM, On-Chip OTP ROM）：OTP存储器，也称为eFuse，是芯片中特殊存储模块；字段中的任何eFuse位都只能从0编程为1（融合），但是读取操作没有限制。OTP在安全中的应用一般可以存放一些固定不变的值，比如：

每个设备唯一的根密钥（Master Key）

设备唯一ID（Device Unique ID）或者MAC地址

一些安全配置或者秘密值（软件的Hash值，启动模式等）

下面简单介绍一下OTP和Secure Boot的配合案例，在一些低端设备，限于成本和性能等原因，会采用对称加密的方式来验证启动过程bootloader image合法性，那又是如何做到的呢？

芯片第一次boot时，软件bootloader根据以下步骤使能Secure boot：

1）硬件产生一个secure boot key，将这个key保存在efuse中，利用这个key、一个随机数IV和bootloader image计算出secure digest。

2）secure digest与随机数IV保存在flash的0x0地址，用于在后续boot时验证bootloader image是否被篡改。

3）bootloader通过烧写efuse中的ABS_DONE_0永久使能secure boot。

4）芯片在后面的boot中，ROM bootloader发现efuse中的ABS_DONE_0被烧写，于是从flash的地址0x0读取第一次boot时保存的secure digest和随机数IV，硬件使用efuse中的secure boot key 、随机数IV与当前的bootloader image计算当前的secure digest，若与flash中的secure digest不同，则boot不会继续，否则就执行软件bootloader。

5）软件bootloader使用bootloader image中保存的公钥对flash中的partition table和app images签字进行验证，验证成功之后才会boot到app代码中。

第一次boot时secure boot与flash encryption的生效过程如下图所示，图中蓝色框是 secure boot的步骤，绿色框是flash encryption的步骤：

图10

后续boot时流程图如下，图中绿色框中的步骤会执行解密，解密是由硬件自动完成：  

图11（图源：https://www.cnblogs.com/aaronLinux/p/9198725.html）

6.2 Flash空间保护机制

Flash空间保护主要是Flash某些区域设置只读或者只写，防止非法访问和篡改。Flash保护区域的数量和大小会根据Flash的类型和该Flash块的大小而有所不同。主要的应用场景有：

保护包含代码的闪存的所有区域，以保护应用程序本身不被覆盖。用于存储数据的闪存区域将不受保护。

保护向量表和驻留在闪存中的引导加载程序，并使其余闪存不受保护。这将防止意外删除引导加载程序，但闪存的其他部分仍未受保护，以允许引导加载程序执行固件更新。

下面以NXP Flash的空间保护机制为例做个简要说明：  

图12   有个flash存储空间保护寄存器，FPROT0–FPROT3,默认值由应用程序image根据在flash配置字段中编程的值来确定。FPOROTn-四个寄存器保护Flash的32区域。 Source：https://www.nxp.com/docs/en/application-note/AN4507.pdf

6.3. 内存的保护机制

目前操作系统也可以设置一些区域的不可读或者写的机制，也有芯片级内存保护机制，下面仍然以NXP芯片为例。

图13：i.MX 8安全性概述

安全存储区具备严格的访问控制机制，安全存储区域具备Domain ID，权限级别（TZ或NS）和权限列表（Permissions），只有硬件访问时具备这些能力的访问才能访问成功，否则会失败，这个是完全硬件级的访问控制，可以与Trust Zone和业务的访问控制权限等配合使用。  

07

FOTA（Firmware over the air）

能够对汽车执行现场软件更新的优势已得到充分确立：它将为制造商节省资金，使关键错误得以立即修复并在其生命周期内随时向汽车添加引人注目的新功能。理想情况下，对车辆操作至关重要的更新应在后台无缝且不可见地进行。

图14

上图显示了关键组件，这些组件将更新文件从OEM服务器获取到车辆中的特定ECU。通过蜂窝网络在单个车辆和服务器之间建立安全连接。这样就可以将新的固件更新安全地发送到车辆的Telematics Unit，然后再发送到OTA Manager。OTA Manager管理车辆内所有ECU的更新过程。它控制固件更新到ECU的分配，并告诉ECU何时执行更新。

这在需要同时更新多个ECU的情况下非常重要。为涉及多个ECU的车辆添加新功能。更新过程完成后，OTA Manager将向OEM发送确认。

可以在运行OTA Manager的ECU上安装外部NAND闪存，以存储固件更新，直到需要它们为止。外部闪存还可以用于存储其他车辆ECU的固件备份副本，如果ECU更新出现重大故障，则可以调用该备份副本，从而使ECU没有任何可用的固件。这些备份副本将通过加密和身份验证来提供保护，以防止存储在外部存储模块中的同时对固件进行任何篡改。

OTA Manager包含车辆内每个ECU的表格，其中包括序列号和当前固件版本等信息。这样，OTA Manager可以验证到达的固件更新，并确保已授权将其用于该车辆。如果要更新的ECU不具有安全功能，则OTA Manager还将负责解密和验证传入的更新。7.1 ECU的更新过程

完整二进制文件：新固件完整发送。这具有不依赖于先前固件的优点，从而即使先前版本已损坏也可以进行更新。该方法的两个缺点是传输二进制文件所花费的时间以及在接收方ECU中存储二进制文件所需的空间。许多传统的ECU在CAN总线上的典型速度为500kbit/s。

差异文件：在服务器上，OEM将新固件与以前的版本进行比较，并创建一个“差异”文件，其中包含它们之间的差异列表。

根据更改的数量，此文件通常是：

“A/B”方法（“A/B” approach）：这会使每个ECU上的闪存数量增加一倍，以便它可以在“主”闪存中包含当前固件，并在“第二”闪存中具有用于全新版本的空间。从最终用户的角度来看，这种方法是理想的，因为ECU可以使用主存储器保持正常运行，而新固件可以在后台写入辅助存储器。更新完成后，ECU在方便的时间使用新更新的固件（在辅助闪存块中）（例如，在下次启动时，也可以等待将开关与要更新的其他ECU进行同步）。由于始终有可用的固件，因此没有将ECU置于不可操作状态的危险，因为始终可以立即“回滚”到先前的可用固件。一个明显的缺点是在MCU上实现两倍于执行闪存的成本。

“就地”方法（“In place” approach）：在这种情况下，设备上仅存在固件的一个版本，并且作为更新的一部分擦除并编程了各个块。当ECU处于正常运行状态时，更新无法运行——这意味着车辆将在一段时间内无法运行。该时间段主要由重新编程ECU Flash所需的时间决定。车辆中的主要ECU（如发动机控制器）将具有数MB的闪存，如果需要对完整的固件进行重新编程，则可能需要数十秒的时间才能完成。对于OEM厂商来说，这是一个挑战——客户是否会接受这样的事实，即他们无法在长达一分钟的时间内启动引擎。A/B方法的增加成本必须与“就地”方法给客户带来的不便之间进行权衡。由于“就地”方法中仅存在固件的一个版本，因此更新过程中发生错误或重置可能很难从中恢复，并且如果未仔细处理，则可能导致模块（以及汽车）功能无法正常运行，因此在车库对其进行更新之前，车辆将一直无法使用。

08

安全诊断（Secure Debug）

现代处理器配备了基于硬件的调试功能，以促进片上调试过程。

例如，硬件断点和基于硬件的跟踪。

通常需要电缆连接（例如JTAG [1]）才能使用这些功能。

如果诊断过程没有合适的安全机制，很容易被黑客利用，如下图所示：

图15

安全JTAG模式通过使用基于挑战/响应的身份验证机制来限制JTAG访问。检查对JTAG端口的任何访问。只有授权的调试设备（具有正确响应的设备）才能访问JTAG端口。未经授权的JTAG访问尝试将被拒绝。此功能需要支持基于质询/响应的身份验证机制的外部调试器工具（例如Lauterbach Trace32，ArmRVDS/DS5调试器等）。通常在设备制造期间而不是在开发板上启用安全JTAG模式。目前很多芯片厂商都提供自己的安全诊断方案，下面仅以NXP为例：

图16

1.用户通过JTAG接口请求调试

2.SOC以芯片唯一ID响应

3.服务器找到相应的密钥（TZ或normal world）

4.用户通过JTAG界面提交密钥

5.安全的JTAG模块将密钥与预先配置的密钥进行比较

6.如果匹配，则启用调试（对于TZ或normal world）

注：

1. 这里的安全诊断是针对芯片的调测，不要跟测试设备通过OBD口和车内ECU进行通讯争端协议（UDS）进行混淆了。

2. 从安全角度通常建议设备真正投入使用时，应关闭芯片的JTAG口或者其他类型的调测端口。

09

安全运行环境

安全运行环境主要是指芯片向OS和APP提供安全隔离的计算环境，以及配套的虚拟机管理程序或者SDK，通常包括芯片计算多分区（Multi Partitions）机制和可信计算环境（Trust zone）。

1.ARM Trustzone+虚拟化1）Arm V8.4架构开始引入Secure EL2扩展，在Secure世界中增加了对虚拟化的支持。这使得可以在非安全状态下进行虚拟化的功能进入安全状态。虚拟化的一个关键特性是增加了虚拟机管理程序控制两阶段的地址翻译过程（如图17）。  

图17  

2）Secure EL1中安全分区具有隔离的地址空间，其他安全分区无法访问此空间，是一个沙箱环境。

3）使用Secure EL2安全分区来实现安全世界的虚拟机，安全分区管理器：EL3和Secure EL2中通用的固件负责管理这些安全分区，这里的关键组件是安全分区管理器（SPM）  

图18  

2. 系统资源隔离（以NXP的XRDC特性为例）

1）什么是分区：

资源集合（主/从外围设备，内存区域）

具有域ID和安全属性

内核，外围设备和内存可以属于多个分区

2）分区的工作原理：

系统控制器将外围设备和内存区域提交到特定域中（这是客户定义的）

域之间的任何通信都必须使用消息传递协议

如果某个域外设试图非法访问其他域，则会发生总线错误

3）分区的好处：

非法访问时会立即报告，有助于在投入实际应用之前发现难以追查的资源竞争问题 （又名沙盒方法）

提供成品的安全性：保护系统关键的SoC外设免受不太信任的应用程序的攻击

图19

注：限于篇幅，本文没有讲述Trustzone技术本身，这方面的技术在网上有大量的论述，本文不再重复。

3. 多核虚拟化

目前很多车载ECU具有多核，每个核可以根据实际需要运行不同ASIL等级的应用程序，也可以把Security和Safety应用严格隔离开，或者通过虚拟化技术运行不同的操作系统等。因此多核虚拟化技术应用也会越来越多。第一节讲的ARM Trustzone最近的架构已经支持虚拟化技术，下面是NXP虚拟化技术的一个例子：  

图20    

10

总结

1.芯片的安全为什么这么重要？

最重要原因是汽车容易进行近距离和物理接触，所以黑客可以较容易实施物理攻击，如果没有安全的芯片设计，很难保障整车的安全。比如密钥和隐私数据的盗取，篡改等；同时行业标准，整车性能要求也促使大家不得不把更多安全功能建立在芯片安全辅助的基础之上。

2.汽车芯片级安全技术层次以及各技术之间的关系

2.1首先要关注芯片自身的物理安全能力，汽车芯片必须能抵抗一定级别的物理攻击，比如黑客可以利用侧信道攻击获取芯片内部的密钥信息，一旦获取密钥，就可以成功突破车内其他部件，甚至突破一批汽车的安全控制措施，因为目前很多车型是使用相同密钥的，安全强度低。

2.2 汽车智能化和网联化的加强，从封闭的安全世界走向了一个相对开放的危险世界。那么整车的信任源在哪里？因为没有信任源，整车的信任体系就无法建立起来。这个时候我们就要求车内核心的芯片自身必须嵌入信任根或者引入第三方TPM芯片，确保上电的“第一行代码就是完全可信的”，由此通过安全启动，构建整车的信任链。

2.3 有个信任根，就需要关注安全存储。汽车的密钥，设备的唯一身份，以及一些特殊的安全度量值（比如软件hash），安全配置等，都需要安全的存储机制，确保黑客看不见，拿不走，改不了，这类安全技术比如OTP、PUP、芯片级访问控制等。

2.4. 有个硬件层面的安全底座，就要考虑上层应用的安全机制，尤其是安全隔离。随着现在ECU计算能力的增强，运行的功能越来越集中，就需要考虑功能之间的隔离，确保一个功能被黑客攻破，让攻击不能蔓延开，从而不会影响其他功能的正常运行，因此就出现了各种安全运行的机制，比如trust zone，虚拟化技术，运行期内存一致性检查技术，控制流一致性（CFI）技术等。

2.5.另外还有一些特殊场景的安全，比如内置数字版权技术，芯片安全调测技术，固件安全刷写等场景，都需要考虑安全性，否则都会带来严重后果。

最后，我们需要强调的是，没有一个单点安全技术可以包治百病，安全没有“银弹”，必须确保各个芯片设计，软件设计，系统设计各环节的安全。从威胁分析入手，再基于成本、功耗、基础设施配套情况等来综合设计系统的安全机制。  

   责任编辑：lq