安全启动过程及时间
在任何安全启动策略中，一个关键因素是应用程序启动前可以检查多少代码。例如，ECU必须能够在上电后短时间内在CAN或CAN FD总线上进行通信；行业要求的时间范围从50毫秒到200毫秒不等。根据这个范围，可以认证的代码长度将变化几倍。
假设典型ECU的代码大小，基于测试的CMAC吞吐量为69 MB/s，HSM核心频率为100 MHz，下面是官方给出的测试结果。
如表所示，AURIX HSM可以在50毫秒内验证多达2 MB的数据。在分阶段启动（Staged Boot）场景下，AURIX HSM通常会在这个时间限制内验证CAN通信堆栈，并允许主处理器在HSM完成其余验证的同时运行它。
安全启动失败的情形
FM1
失败效果：模块的所有后续启动将失败，造成可用性问题。
失败原因：在初始CMAC计算过程中可能发生随机硬件故障（如电压波动或电磁干扰），或者由于软件故障（bug）导致CMAC计算失败。
FM2
失败效果：模块的所有后续启动将失败，造成可用性问题。
失败原因：NVM存储中的随机硬件故障或软件故障（bug）可能导致启动失败。
FM3
失败效果：代码未被验证，从而不安全。
失败原因：在初始化代码的读取或执行过程中发生随机硬件故障。
FM4
失败效果：当前安全启动失败，造成可用性问题。
失败原因：CMAC计算过程中的随机硬件故障导致安全启动失败。
FM5
失败效果：执行了不正确的代码（被破坏或被篡改）。
失败原因：CMAC计算过程中发生随机硬件故障，导致验证失败，从而执行了不正确的代码。
FM6
失败效果：当前安全启动失败，造成可用性问题。
失败原因：CMAC验证过程中的随机硬件故障（如两个值的比较）导致安全启动失败。
FM7
失败效果：执行了不正确的代码（被破坏或被篡改）。
失败原因：CMAC验证过程中的随机硬件故障（如两个值的比较）导致验证失败，从而执行了不正确的代码。
FM8
失败效果：执行了不正确的代码（被破坏或被篡改）。
失败原因：HSM代码执行过程中的随机硬件故障导致安全启动失败或代码被篡改。
FM9
失败效果：当前安全启动失败，造成可用性问题。
失败原因：HSM代码执行过程中的随机硬件故障导致安全启动失败。
安全启动失败的分析
TM1
安全属性：完整性、真实性、可用性
效果：所有后续的安全启动（使用合法过程）可能失败，这可能会启用更严重的攻击。
脆弱性（原因）：非安全的软件下载过程允许攻击者更新NVM并生成包含非合法代码的新CMAC。未加防篡改保护的芯片在初始CMAC计算过程中可能被篡改（例如电压扰动）。
TM2
安全属性：完整性、真实性、可用性
效果：所有后续的安全启动（使用合法过程）可能失败，这可能会启用更严重的攻击。
脆弱性（原因）：对NVM写入的保护不足，或特权升级不足。
TM3
安全属性：完整性、真实性
效果：安全启动过程的目标失败。如果应用代码被攻击者修改，则可能导致系统完全崩溃。
脆弱性（原因）：对初始化代码写入的保护不足。未加防篡改保护的芯片在芯片初始化过程中可能被篡改。
TM4
安全属性：完整性
效果：ECU功能减少。这可能会启用更严重的攻击。
脆弱性（原因）：对初始化代码写入的保护不足。未加防篡改保护的芯片在芯片初始化过程中可能被篡改。
TM5
安全属性：完整性、真实性、可用性
效果：当前安全启动失败（可用性问题）。当与TM1/TM2结合时可能导致系统完全崩溃。
脆弱性（原因）：对NVM写入代码的保护不足，或特权升级不足（非合法代码被写入NVM）。
TM6
安全属性：可用性
效果：当前安全启动失败。非安全CMAC代码可能被攻击者干扰（例如被中断）。
脆弱性（原因）：未加防篡改保护的芯片在CMAC计算过程中可能被篡改。
TM7
安全属性：完整性、真实性
效果：系统完全崩溃。
脆弱性（原因）：对“已知良好”CMAC的读取保护不足，以及对用于CMAC验证的寄存器/内存写入的保护不足（例如攻击者读取“已知良好”CMAC然后在启动时将其写入正确的寄存器）。
TM8
安全属性：可用性
效果：当前安全启动失败。非安全CMAC比较代码可能被攻击者干扰（例如被中断）。
脆弱性（原因）：未加防篡改保护的芯片在比较过程中可能被篡改（例如故障注入）。
TM9
安全属性：完整性、真实性
效果：系统完全崩溃。非安全CMAC比较代码可能被攻击者干扰（例如被中断）。
脆弱性（原因）：未加防篡改保护的芯片在比较过程中可能被篡改（例如故障注入）。
TM10
安全属性：完整性、真实性
效果：系统完全崩溃。非安全代码可能被攻击者干扰（例如被中断）。
脆弱性（原因）：未加防篡改保护的芯片在启动的最后阶段可能被篡改。
TM11
安全属性：可用性
效果：当前安全启动失败。非安全代码可能被攻击者干扰（例如被中断）。
脆弱性（原因）：未加防篡改保护的芯片在启动的最后阶段可能被篡改。
安全启动失败的应对策略
1. 利用AURIX™微控制器硬件特性
错误更正码（ECC）：AURIX 中的内存和总线实现了ECC，用于减轻位翻转的风险。
HSM的特权操作：HSM在最高权限下操作，保护对某些内存区域（如用户配置块UCBs）的访问，同时其他区域即使是HSM也无法读取。
一次性可编程（OTP）闪存：HSM使用的闪存可以设置为一次性可编程（OTP），之后不能再写入，从而防止篡改。
支持功能安全：AURIX 设计支持高达ASIL D的功能安全目标，包含冗余、自检等安全特性，以减轻随机硬件故障的影响。
2. 编程策略和对策
引入冗余：在哈希计算、存储和验证操作中引入冗余，以提高系统的可靠性。
安全编码实践：使用安全编码实践可以减少软件和硬件攻击的可能性和影响，这些实践在嵌入式安全和智能卡领域得到了广泛应用。
环境监控：AURIX 配备温度和电压传感器，用于监测环境条件，确保微控制器在不超出界限的条件下操作，从而减少故障的可能性。
安全启动故障策略
在安全启动过程中，如果发生故障，可以采取以下策略和措施来处理和恢复：
1. 错误检查和诊断
检查错误更正码（ECC）：故障可能是由位翻转引起的，通过ECC检查来验证错误。
检查擦除计数器：如果擦除计数器已增加，说明微控制器可能被重新编程。
检查安全管理单元（SMU）：SMU可以设置警报来捕捉不可纠正的多位错误和/或已纠正的错误。
重新运行代码检查：对CMAC、哈希、签名等进行全面检查，确保初始计算没有被随机硬件故障干扰。
发送诊断故障码（DTC）：通过CAN发送DTC，以便更精确地诊断故障。
进入安全模式：执行“临时运行模式”程序，确保系统在出现故障时能够保持基本操作。
执行恢复程序：可以是本地恢复或远程恢复，ECU可能在外部闪存中有备份代码，或者车辆的中央存储库中有加密的ECU代码备份。
2. “临时运行模式”的实施
“临时运行模式”的具体格式会因应用而异。一些ECU可能需要大量的代码，而另一些（非关键的）可能可以安全地保持在复位状态。通常可以采取以下措施：
备份代码的OTP保护：后备代码应该设置为一次性可编程（OTP），并经过广泛验证以防止漏洞。
确保安全性：后备代码在攻击者强制ECU进入“临时运行模式”时应保持安全。
最小化总线通信：后备代码应尽量减少总线上的通信需求。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/qq_36750998/article/details/140798801
|
楼主
标题置顶
标题高亮
