谈谈汽车芯片安全（下篇）
继《谈谈汽车芯片安全-上篇》之后，本文针对芯片安全存储、FOTA、安全诊断、安全运行环境做了进一步阐述。
安全存储
1.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)securedigest 与随机数 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 与 flashencryption 的生效过程如下图所示，图中蓝色框是 secure boot 的步骤，绿色框是 flash encryption 的步骤:
后续 boot 时流程图如下，图中绿色框中的步骤会执行解密，解密是由硬件自动完成：
Source：https://www.cnblogs.com/aaronLinux/p/9198725.html
1.2 Flash 空间保护机制
Flash 空间保护主要是 Flash 某些区域设置只读或者只写，防止非法访问和篡改。Flash 保护区域的数量和大小会根据 Flash 的类型和该 Flash 块的大小而有所不同.主要的应用场景有：
· 保护包含代码的闪存的所有区域，以保护应用程序本身不被覆盖。用于存储数据的闪存区域将不受保护。
· 保护向量表和驻留在闪存中的引导加载程序应用程序，并使其余闪存不受保护。这将防止意外删除引导加载程序，但闪存的其他部分仍未受保护，以允许引导加载程序执行固件更新。
下面以 NXP Flash 的空间保护机制为例做个简要说明:
有个 flash 存储空间保护寄存器，FPROT0–FPROT3,默认值由应用程序 image 根据在 flash 配置字段中编程的值来确定。FPOROTn- 四个寄存器保护 Flash 的 32 区域。 Source: https://www.nxp.com/docs/en/application-note/AN4507.pdf1.3. 内存的保护机制： 目前操作系统也可以设置一些区域的不可读或者写的机制，也有芯片级内存保护机制，下面仍然以 NXP 芯片为例。
安全存储区具备严格的访问控制机制，安全存储区域具备 Domain ID，权限级别（TZ or NS）和权限列表(Permissions)，只有硬件访问时具备这些能力的访问才能访问成功，否则会失败，这个是完全硬件级的访问控制，可以和 Trust Zone 和业务的访问控制权限等配合使用。 Source:i.MX 8Security Overview
FOTA(Firmware over the air)
能够对汽车执行现场软件更新的优势已得到充分确立：它将为制造商节省资金，使关键错误得以立即修复并在其生命周期内随时向汽车添加引人注目的新功能。理想情况下，对车辆操作至关重要的更新应在后台无缝且不可见地进行。
上图显示了关键组件，这些组件将更新文件从 OEM 服务器获取到车辆中的特定 ECU。通过蜂窝网络在单个车辆和服务器之间建立安全连接。这样就可以将新的，更新的固件安全地发送到车辆的 Telematics Unit，然后再发送到 OTA Manager。OTA 管理器管理车辆内所有 ECU 的更新过程。它控制固件更新到 ECU 的分配，并告诉 ECU 何时执行更新。
这在需要同时更新多个 ECU 的情况下非常重要。为涉及多个 ECU 的车辆添加新功能。更新过程完成后，OTA 管理器将向 OEM 发送确认。
可以在运行 OTA Manager 的 ECU 上安装外部 NAND 闪存，以存储固件更新，直到需要它们为止。外部闪存还可以用于存储其他车辆 ECU 的固件备份副本，如果 ECU 更新出现重大故障，则可以调用该备份副本，从而使 ECU 没有任何可用的固件。这些备份副本将通过加密和身份验证保护来保护，以防止在存储在外部存储模块中的同时对固件进行任何篡改。
OTA 管理器包含车辆内每个 ECU 的表格，其中包括序列号和当前固件版本等信息。这样，OTA Manager 可以验证到达的固件更新，并确保已授权将其用于该车辆。如果要更新的 ECU 不具有安全功能，则 OTA 管理器还将负责解密和验证传入的更新。
2.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 方法的增加成本必须与“就地”方法给客户带来的不便之间进行权衡。由于“就地”方法中仅存在固件的一个版本，因此更新过程中的错误或重置可能很难从中恢复，并且如果未仔细处理，则可能导致模块（以及汽车）不再功能正常运行，直到在车库对其进行更新之前，车辆无法使用。
安全诊断（Secure Debug）
现代处理器配备了基于硬件的调试功能，以促进片上调试过程。 -例如，硬件断点和基于硬件的跟踪。 -通常需要电缆连接（例如 JTAG [1]）才能使用这些功能。 如果诊断过程没有合适的安全机制，很容易被黑客利用，如下图所
安全 JTAG 模式通过使用基于挑战/响应的身份验证机制来限制 JTAG 访问。检查对 JTAG 端口的任何访问。只有授权的调试设备（具有正确响应的设备）才能访问 JTAG 端口。未经授权的 JTAG 访问尝试将被拒绝。此功能需要支持基于质询/响应的身份验证机制的外部调试器工具（例如 Lauterbach Trace32，Arm®RVDS / DS5 调试器等）。通常在设备制造期间而不是在开发板上启用安全 JTAG 模式。目前很多芯片厂商都提供自己的安全诊断方案，下面仅以 NXP 为例：
1.用户通过 JTAG 接口请求调试
2.SOC 以芯片唯一 ID 响应
3.服务器找到相应的秘密（TZ 或 normal world）
4.用户通过 JTAG 界面提交秘密
5.安全的 JTAG 模块将密钥与预先配置的密钥进行比较
6.如果匹配，则启用调试（对于 TZ 或 normal world）
注：
这里的安全诊断是针对芯片的调测，不要跟测试设备通过 OBD 口和车内 ECU 进行通讯争端协议（UDS）进行混淆了。
从安全角度通常建议设备真正投入使用时，应关闭芯片的 JTAG 口或者其他类型的调测端口。
安全运行环境
安全运行环境主要是指芯片向 OS 和 APP 提供安全的隔离的计算环境，以及配套的虚拟机管理程序或者 SDK，通常包括芯片计算多分区（Multi Partitions）机制和可信计算环境（Trust zone）
1.ARM Trustzone + 虚拟化
（1）Arm V8.4 架构开始引入了 Secure EL2 扩展，在 Secure 世界中增加了对虚拟化的支持。这使得可以在非安全状态下进行虚拟化的功能进入安全状态。虚拟化的一个关键特性是增加了虚拟机管理程序控制两阶段的地址翻译过程。（2）Secure EL1 中安全分区具有隔离的地址空间，其他安全分区无法访问此空间，是一个沙箱环境。
（3）使用 Secure EL2 安全分区来实现安全世界的虚拟机，安全分区管理器：EL3 和 Secure EL2 中通用的固件负责管理这些安全分区，这里的关键组件是安全分区管理器（SPM）
系统资源隔离（以 NXP 的 XRDC 特性为例）
什么是分区：
· 资源集合（主/从外围设备，内存区域）
· 具有域 ID 和安全属性
· 内核，外围设备和内存可以属于多个分区
分区的工作原理：
· 系统控制器将外围设备和内存区域提交到特定域中（这是客户定义的）
· 域之间的任何通信都必须使用消息传递协议
· 如果某个域外设试图非法访问其他域，则会发生总线错误
分区的好处：
· 非法访问时报告立即的，有助于在投入实际应用之前发现难以追查资源竞争问题（又名沙盒方法）
· 提供成品的安全性：保护系统关键的 SoC 外设免受不太信任的应用程序的攻击
多核虚拟化
目前很多车载 ECU 具有多核，每个核可以根据实际需要运行不同 ASIL 等级的应用程序，也可以把 Security 和 Safety 应用严格隔离开，或者通过虚拟化技术运行不同的操作系统等。因此多核虚拟化技术应用也会越来越多。第一节讲的 ARM Trustzone 最近的架构已经支持虚拟化技术，下面是 NXP 虚拟化技术的一个例子.
总结
最后我们做个总结，给出一个芯片安全的参考的逻辑架构图，不同芯片根据应用场景、成本等，支持的能力是不一样的。
以上就是基于芯片的安全技术下篇，这次我们就先分享到这里了，如果您有更多需要探讨了解的内容，欢迎在下面留言讨论。
——————————————
文章来源：汽车信息安全 原文链接：https://mp.weixin.qq.com/s/VKV3goCA9pTSCjZtPdvs7w
作者：路人甲——青骥小组 版权归原作者所有，如需转载，请联系作者。
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7524
还未添加个人签名 2021.09.06 加入
还未添加个人简介
评论