汽车MCU基于非对称算法的伪安全启动方案

发布者:legend8最新更新时间:2024-06-24 来源: 谈思实验室 手机看文章 扫描二维码
随时随地手机看文章

01


概述


随着软件定义汽车理念的普及,汽车上代码量不断膨胀,功能不断智能化,用户体验不断升级。从传统汽车不需要联网,到职能汽车具有联网功能已是标配,汽车触网必将带来更多信息安全问题。汽车的信息安全问题比IT领域更加重要,因为可能危及生命安全。故国家也出台强标《汽车整车信息安全技术要求》(目前还处于征求意见稿),在强标的的9.1.1条提出“车载软件升级系统应具备安全启动的功能,应保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改,或被篡改后无法正常启动”。


故安全启动功能后续将成为强标的一部分,具有OTA功能的ECU都必须配备。但目前,MCU普遍未实用HSM功能,国内MPU总体支持安全启动。MCU未使用HSM,主要还是出于成本考量,实用HSM将带来物料成本和HSM协议栈成本。因此综合考量后,可以先解决有无问题,后续再解决好坏问题。在不增加额外成本的场景下,先解决有无问题,故提出一个基于非对称加密算法、信任链不完整的安全启动方案。


02


安全启动概念


安全启动是通过一项技术,确保按照固定顺序,运行经过验证后的代码,确保不会存在模块被绕过以及不会运行不合法的代码。通过此技术,可确保攻击者篡改任何ECU代码或者重新刷入非法代码都会被识别,且可以直接限制ECU启动。

安全启动涉及如下概念:


  1. 验证:一个检查过程,检查即将运行的代码是否为官方发布。为实现验证过程,需引入密码学算法,当官方发布软件包时,通过该算法计算出当前软件包的一个特定值,并将该特定值和软件包一起写入到ECU FLASH中。启动时,实时计算出软件包特征值,并和已写入FLASH的特征值对比。若两者一致,则软件包合法,否则不合法安全启动。


  2. 信任根:上述认证过程同样需通过代码实现,若攻击者可修改验证过程代码,则依然可绕过验证过程或篡改验证结果。故此时需要有一个攻击者完全无法修改的代码,来验证上述的认证代码,确保上述验证代码无法被修改。这个攻击者完全无法修改的代码即可理解为信任根,信任根是一致认为无法被篡改的一段代码,通常通过硬件实现,例如芯片的bootROM,bootROM是固化在芯片内的一段代码,芯片一旦制造完成,bootROM就用于无法被更改。


  3. 信任链:一个ECU的软件基本会分为多个部分,例如bootloader,app等,以信任根为起点,通过不断实现一级一级的验证,从而形成信任链,确保各模块认证的有效性。例如bootROM认证bootloader,bootloader认证app。


03


安全启动方案


3.1 根证书


安全启动采用非对称算法,可使用RS或ECC算法,生成一对公私钥。公私钥用途如下:


  • 私钥:用于签名,在刷写前,对即将发布的镜像计算HASH值,并通过私钥对HASH值进行签名,得到签名信息。


  • 公钥:用于验签,当安全启动工作时,通过对签名信息使用公钥验签,还原出发布时镜像的HASH值,用于后续比对HASH值是否正确。


3.2 存储空间


假定一个ECU软件包包括三部分,分别为BootLoader、APP1、APP2,则该软件包刷写到ECU FLASH中应是如下示例:

图片

在原始镜像基础上,增加针对该镜像的签名信息,并将原始镜像和签名信息一同刷写到FLASH中。


3.3 刷写前准备


当进行软件刷写前,需先计算各模块的签名信息。计算签名信息流程如下:


  1. 基于原始镜像,使用HASH算法(例如SHA-256),得到该镜像的HASH值。


  2. 使用之前生成的私钥对HASH值进行签名,输出即为原始镜像的签名信息。


    当进行刷写时,需将原始镜像和签名信息一并刷写到FLASH中。例如参考3.2中示例,将BootLoader原始镜像和Bootloader签名信息刷写到BootLoader区域,将APP1原始镜像和APP1签名信息刷写到APP1区域。签名信息在各自区域存放的位置,可由开发人员自行定义,只需保障启动时,可准确读取到签名信息即可。


    将安全启动证书/公钥刷写到FLASH中,且将证书/公钥的HASH值保存到OTP中。


3.4 安全启动流程


3.4.1 总体安全启动流程


  1. bootrom后跳转到Bootloader,在Bootloader中验证根证书、bootloader自身、下一个启动模块的合法性。


  2. 启动bootloader下一个模块(例如APP1),在此模块中,验证后续启动模块的合法性。按照在当前模块中验证下一模块合法性,验证通过后,则继续启动下一模块的链路验证下去,直到所有模块都验证结束。


  3. 若验证失败,则跳转到启动失败处理流程:记录失败原因和失败次数到FLASH中,进行软件reset。


3.4.2 安全启动流程实例

图片

假定一个ECU软件包包括三部分,分别为BootLoader、APP1、APP2。则启动过程如上图所示,具体流程如下:


  1. 上电后,执行芯片bootrom后,跳转到bootloader。首先读取DFLASH中失败次数,若失败次数大于N此(通常为3),则启动失败,停留在PBL中或提供有限功能(具体应依据项目需求设计)。若小于N,则继续启动流程;


  2. 读取安全启动根证书/公钥,计算HASH值(称为CERT-HASH-1),并读取OTP中保存的HASH值(称为CERT-HASH-2),比较CERT-HASH-1和CERT-HASH-2值是否相等,若相等,则根证书/公钥未被篡改,继续启动流程。若不相等,则启动失败,记录失败原因和次数到FLASH中,并进行reset,跳转到步骤1中;


  3. 随后读取Bootloader镜像并计算镜像的HASH值(称为BOOTLOADER-HASH-1)。读取bootloader的签名信息,并通过根证书/公钥验签bootloader的签名信息,得到签名信息中包含的HASH值(称为BOOTLOADER-HASH-2)。比较BOOTLOADER-HASH-1和BOOTLOADER-HASH-2值是否相等,若相等,则证明Bootloader未被篡改,继续启动流程。若不相等,则启动失败,记录失败原因和次数到FLASH中,并进行reset,跳转到步骤1中;


  4. 读取APP1镜像并计算镜像的HASH值(称为APP1-HASH-1)。读取APP1的签名信息,并通过根证书/公钥验签APP1的签名信息,得到签名信息中包含的HASH值(称为APP1-HASH-2)。比较APP1-HASH-1和APP1-HASH-2值是否相等,若相等,则证明APP1未被篡改,继续启动流程。若不相等,则启动失败,记录失败原因和次数到FLASH中,并进行reset,跳转到步骤1中;


  5. 跳转到APP1中。读取APP2镜像并计算镜像的HASH值(称为APP2-HASH-1)。读取APP2的签名信息,并通过根证书/公钥验签APP2的签名信息,得到签名信息中包含的HASH值(称为APP2-HASH-2)。比较APP2-HASH-1和APP2-HASH-2值是否相等,若相等,则证明APP2未被篡改,继续启动流程。若不相等,则启动失败,记录失败原因和次数到FLASH中,并进行reset,跳转到步骤1中;


  6. 跳转到APP2中。若有其他模块启动,则继续按照信任链一步一步进行验证。若无其他模块,则安全启动完成。


3.5 安全启动耗时


安全启动相较于普通启动,增加相应的流程,必然会带来安全启动时间的增加。基于在infineon TC377和TI AWR 2944经验,不借助硬件加速,耗时估算如下:


  • HASH使用SHA256:4K/1ms


  • 签名验签:9ms


    总体来说,耗时主要在对各模块计算HASH中,如APP有4M,则耗时将达到1S。


优化


针对HASH耗时较大,若芯片支持硬件CRC加速,可先计算镜像的CRC,然后对CRC进行签名。基于目前经验,硬件CRC速度约为70K/s,速度提升快20倍。以4M模块计算,使用硬件CRC耗时约58ms,使用软件HASH则耗时1000ms。


使用CRC碰撞概率远大于HASH(SHA-256)碰撞概率,故使用CRC可提升安全启动速度,但同步会带来安全性减弱。


04


方案总结


4.1 优点


在不大量增加成本的情况下,实现安全启动从无到有。使用当前方案,不需要使用支持HSM的芯片,不需要额外购买HSM协议栈,即可实现具有安全启动。


4.2 缺点


不是完整的安全启动。当前方案以BootLoader为信任根,而不是以不可更改代码为信任根。导致攻击者可修改BootLoader即可绕过安全启动的验证过程。


4.2.1 缺点完善


当前缺点为bootloader不是不可更改的区域,作为信任根强度不够。为提升强度,可限制对Bootloader的修改,例如:不允许刷写bootloader、禁用JTAG等调试口等措施。


05


思考


以上方案因缺少一个不可更改的信任根,总体上仍存在安全缺陷。但有些芯片支持将code Flash的部分区域整个设置成OTP,例如infineon的TC3XX、瑞萨的RH850等。若芯片支持设置code flash为OTP,理论上可以不适用HSM实现一个不可更改的信任根。思路如下:


将Bootloader拆分为2段PBL1和PBL2。其中PBL1校验PBL2,并将PBL1设置为OTP。PBL1验证PBL2通过后,启动PBL2,在PBL2中校验后续APP。因PBL1所在的code Flash在产线会设置成OTP,故PBL1可当做一个不可更改的信任根使用,达到类似Bootrom的效果


引用地址:汽车MCU基于非对称算法的伪安全启动方案

上一篇:汽车大芯片,巨变前夜
下一篇:基于新架构的车身域控制器方案研究与设计

小广播
最新汽车电子文章

 
EEWorld订阅号

 
EEWorld服务号

 
汽车开发圈

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved