一种基于HSM双摘要延迟提交的安全启动方法及系统与流程

本发明属于车载控制器信息安全与功能安全交叉，尤其涉及一种基于hsm双摘要延迟提交的安全启动方法及系统。

背景技术：

1、随着智能驾驶、智能座舱的不断发展，车内ecu越来越集中化、网络化，ecu之间不仅可以直接通过以太网通信，还可以通过v2x技术与车外进行通信，无形中为外界开辟了诸多与车辆通信的渠道。如果在行车过程中，ecu中运行的软件突然被黑客进行篡改或者控制，将会大大影响行车安全。为此，unece r155、iso/sae 21434等法规标准已明确将固件完整性保护作为网络安全管理体系的基础要素，要求ecu在启动阶段即建立完整的信任链，将黑客造成的篡改尽早扼杀在摇篮中。

2、安全启动（secure boot）技术的核心思想是：以硬件安全模块（hsm）作为信任根（root of trust），利用hsm内独立的密码学加速引擎（aes-cmac、rsa/ecc、sha等）对bootloader及应用程序（app）进行逐级完整性校验，形成rom → bootloader → app的信任链。hsm作为与主核物理隔离的安全岛，其密钥存储与密码运算均对外不可见，一方面保证了密码存储的安全性，另一方面通过硬件加速保障了启动时效。安全启动通常包括bootloader的安全启动与app的安全启动两部分。

3、传统的bootloader安全启动方案通常采用如下机制：ecu首次上电后首先执行bootloader代码，在接收刷新工具命令进行刷新前，先进行bootloader的安全启动校验，确认当前bootloader可靠受信任后才运行刷新，否则执行复位。信任锚是根据首次烧录的bootloader代码及校验范围在hsm中通过aes-cmac校验产生的cmac值建立的，该值由hsm安全防护和存储，不能通过烧录设备擦除或改写。

4、上述方案在安全性与生产便利性之间存在难以调和的矛盾：由于在出厂最后环节安全启动功能生效后，hsm中存储的cmac值只在首次烧录时产生，后续烧录不会根据再次烧入的bootloader重新计算生成，导致若发现bootloader功能有缺陷需要再次烧录时，升级后的bootloader因安全启动校验不过而无法启动，只能烧回原有代码。这就是本技术领域长期存在的安全性与生产便利性无法平衡的问题。

5、对于app的安全启动，业内常用方案是在生产阶段通过执行信息安全刷新流程刷入app，成功刷入后由bootloader调用aes-cmac或hash算法对整个app代码区域数据运算得到校验值，存储于非易失数据内存（nvm）或安全模块（如icu-s）中。后续每次重上电或复位后，跳转app前再次计算当前app的校验值与之前存储值比对，一致才运行，否则停留在bootloader下仅运行刷新功能。

6、该方案存在以下突出问题：app的hash计算若通过软件实现，运算速度慢、耗时长（根据代码大小长达数十秒），严重影响整体刷新效率；若将hash值存储在nvm中，安全性较低，易被擦除，不符合信息安全要求；若通过安全模块icu-s存储，每次更新hash值需传入更新计数器（update counter），而该计数器依赖主核累加到nvm，易被擦除从而导致整个安全启动功能失效。

7、针对前述bootloader自更新与app安全启动的缺陷，相关现有技术提出了一种基于hsm安全硬件支撑的安全启动方法，其改进思路包括：

8、在bootloader代码侧拷贝一份重定位到app代码区间、删减hsm交互的bootloader2搬运代码，并在原bootloader中新增boot manager模块；将待更新的bootloader'编译偏移后与bootloader2合并为自更新刷新文件；自更新文件经证书链校验及签名校验后写入app的code flash区，复位后通过bootloader2擦除原bootloader区除boot manager以外的部分，再将bootloader'写入，完成后通过hsm重设安全启动表并重新计算cmac；对于app安全启动，则在刷新完成后由hsm计算app的hash1存储到hsm专用dataflash，后续每次启动由hsm计算hash2与之比对。

9、该方案虽然在一定程度上解决了bootloader自更新的安全校验问题，但其技术路线仍存在以下局限性：

10、信任锚更新时机前置，缺乏容错缓冲，若新bootloader在后续运行中暴露缺陷或因环境异常导致启动失败，此时原bootloader的cmac已被覆盖，旧版本无法回退启动，存在"双向锁死"的风险。

11、未充分利用物理双bank flash的硬件特性，并未利用mcu物理双bank flash的硬件bank swap机制，使得升级过程中的新旧版本无法在物理上并行共存，回滚路径完全依赖主核软件的续搬逻辑，鲁棒性不足。

12、缺乏防降级机制，在面对攻击者刷回存在已知漏洞的旧版本固件时，无法从信任链层面予以拒绝，不符合unece r155等法规对防回滚的强制要求。

13、状态一致性保障不足，在意外断电场景下易发生状态丢失，导致系统状态机进入未知态，缺乏hsm dataflash与retain ram的镜像冗余机制。

技术实现思路

1、基于此，有必要针对上述技术问题，提供一种基于hsm双摘要延迟提交的安全启动方法及系统，以在保证bootloader升级灵活性的同时，消除双向锁死风险，提升车载控制器的信息安全防护能力与升级鲁棒性。

2、第一方面，本技术提供一种基于hsm双摘要延迟提交的安全启动方法，应用于具有硬件安全模块hsm和物理双bank flash的车载控制器，包括：

3、在hsm的隔离安全非易失存储器中逻辑划分两个独立摘要槽：活跃摘要区active_mac和候选摘要区candidate_mac；

4、当执行bootloader自更新时，将新版本bootloader写入备用bank，并将其认证摘要写入所述candidate_mac，而不修改所述active_mac；

5、置位一次性试启动标记，并触发硬件bank swap使备用bank成为当前映射bank；

6、系统复位后，hsm检测到所述试启动标记有效，进入双摘要校验模式：同时用active_mac和candidate_mac对当前映射bank的bootloader进行校验，任一匹配即通过；

7、若新版本bootloader在备用bank启动成功并通过自检，则由新版本bootloader主动调用hsm接口执行延迟提交：将candidate_mac覆盖至active_mac，并清除试启动标记和candidate_mac；

8、若新版本bootloader启动失败，则触发复位，系统自动回退至原bank，hsm恢复单摘要校验模式，仅用原active_mac进行校验，旧版bootloader正常启动。

9、在其中的一个实施例中，所述触发复位由看门狗溢出、硬件错误检测或软件自检失败中的至少一种触发。

10、在其中的一个实施例中，进一步包括防降级机制：在hsm的安全nvm中固化单调递增的版本计数器，每个合法bootloader版本对应唯一计数值；在将新版本bootloader的认证摘要写入candidate_mac之前，hsm校验其携带的目标版本号是否大于当前active_mac绑定的版本号，若是则允许写入，否则拒绝写入candidate_mac。

11、在其中的一个实施例中，主核向hsm发起的校验请求封装为结构化参数，至少包括：代码区起始地址、校验长度、目标bank标识、版本号、摘要槽选择器；hsm收到请求后，先校验地址范围是否在预设的白名单内，再调用硬件加速引擎计算认证码，并返回三态结果：match_active、match_candidate或mismatch，供主核boot manager决策跳转目标bank。

12、在其中的一个实施例中，自更新刷新文件内部按code flash擦写粒度构建分块哈希链，整体数字签名覆盖根哈希；bootloader2在搬运写入每一块时，实时计算该块哈希并沿哈希链向上校验，任一块校验失败立即中止搬运并回退至原bank启动。

13、在其中的一个实施例中，关键状态标志包括自更新阶段标识、延迟提交完成标识、当前版本号，同时在retain ram与hsm的dataflash中各存储一份形成镜像冗余；每次上电后boot manager首先比对两份镜像，若一致则以该状态推进，若不一致则以hsm dataflash中的数据为准并对retain ram进行修复。

14、在其中的一个实施例中，hsm在每次安全启动校验失败时，向hsm dataflash中的安全日志循环缓冲区写入失败分类码，所述分类码包括：mac_mismatch、version_rollback、candidate_corrupt、bank_swap_abort；主核可通过诊断服务读取该分类码以区分攻击事件与升级异常。

15、在其中的一个实施例中，所述一次性试启动标记在复位后由hsm自动清除，以确保后续启动仅使用单摘要校验模式，除非再次收到自更新指令并重新置位。

16、在其中的一个实施例中，所述延迟提交由新版本bootloader在备用bank完成自身健康自检后，主动调用hsm的专用接口执行，提交完成后hsm自动清空candidate_mac槽位以防止重复使用。

17、在其中的一个实施例中，在延迟提交尚未执行之前，若发生意外断电或复位，hsm在上电后检测到candidate_mac存在且active_mac未被更新，则自动判定升级未完成，强制回退至原bank启动，并保持active_mac不变。

18、在其中的一个实施例中，所述双摘要校验模式下，hsm对当前映射bank的bootloader计算临时认证码，分别与active_mac和candidate_mac进行比对，只要与其中一个匹配即视为校验通过，允许主核继续执行。

19、第二方面，本技术还提供一种基于hsm双摘要延迟提交的安全启动系统，应用于具有硬件安全模块hsm和物理双bank flash的车载控制器，包括：

20、hsm安全存储模块，配置为在hsm的隔离安全非易失存储器中逻辑划分两个独立摘要槽：活跃摘要区active_mac和候选摘要区candidate_mac；

21、自更新触发模块，配置为当执行bootloader自更新时，将新版本bootloader写入备用bank，并将其认证摘要写入所述candidate_mac，而不修改所述active_mac，同时置位一次性试启动标记并触发硬件bank swap使备用bank成为当前映射bank；

22、双摘要校验模块，配置为在系统复位后检测到所述试启动标记有效时，进入双摘要校验模式：同时用active_mac和candidate_mac对当前映射bank的bootloader进行校验，任一匹配即通过；

23、延迟提交模块，配置为在新版本bootloader于备用bank启动成功并通过自检后，由新版本bootloader主动调用hsm接口将candidate_mac覆盖至active_mac，并清除试启动标记和candidate_mac；

24、自动回退模块，配置为在新版本bootloader启动失败时，由看门狗溢出触发复位，系统自动回退至原bank，hsm恢复单摘要校验模式，仅用原active_mac进行校验，使旧版bootloader正常启动。

25、在其中的一个实施例中，所述hsm安全存储模块还配置有单调递增的版本计数器，每个合法bootloader版本对应唯一计数值；所述自更新触发模块在写入candidate_mac之前，调用hsm校验目标版本号是否大于当前active_mac绑定的版本号，若是则允许写入，否则拒绝写入candidate_mac。

26、在其中的一个实施例中，所述双摘要校验模块配置为接收主核发送的结构化校验请求，所述结构化校验请求至少包括代码区起始地址、校验长度、目标bank标识、版本号、摘要槽选择器；所述双摘要校验模块先校验地址范围是否在预设的白名单内，再调用硬件加速引擎计算认证码，并返回三态结果：match_active、match_candidate或mismatch。

27、在其中的一个实施例中，所述自更新触发模块进一步配置为：自更新刷新文件内部按code flash擦写粒度构建分块哈希链，整体数字签名覆盖根哈希；在搬运写入每一块时，实时计算该块哈希并沿哈希链向上校验，任一块校验失败立即中止搬运并触发所述自动回退模块。

28、在其中的一个实施例中，还包括状态镜像模块，配置为将关键状态标志包括自更新阶段标识、延迟提交完成标识、当前版本号同时在retain ram与hsm的dataflash中各存储一份；每次上电后boot manager首先比对两份镜像，若一致则以该状态推进，若不一致则以hsm dataflash中的数据为准并对retain ram进行修复。

29、上述基于hsm双摘要延迟提交的安全启动方法、系统及车载控制器，通过物理双bank flash与hsm双摘要槽的硬件联动、两段提交的延迟信任锚更新机制、版本计数器防降级校验以及状态镜像冗余保障，在保证bootloader升级灵活性的同时，显著提升了车载控制器的信息安全防护能力与升级鲁棒性。通过在hsm中独立维护活跃摘要区（active_mac）与候选摘要区（candidate_mac），升级阶段仅将新版本认证摘要写入候选区而不修改活跃区，使得新旧版本在物理上并行共存。即使新版本bootloader在备用bank启动失败，系统亦可自动回退至原bank，原活跃摘要与原版本完全匹配，旧版bootloader正常启动，从根本上杜绝了因信任链不可逆更新导致的控制器永久失效问题。正常运行时采用单摘要校验模式，仅允许活跃摘要对应的授权版本启动，严格防范降级攻击；升级阶段临时切换为双摘要校验模式，为新旧版本提供短暂的共存窗口，实现了“试启动—验证—提交/回滚”的平滑过渡，解决了行业内长期存在的安全性与升级灵活性之间的矛盾。hsm在写入候选摘要前强制校验目标版本号大于当前活跃版本号，从信任链层面拒绝攻击者刷回存在已知漏洞的旧版本固件。