在之前我们讲解基于Tricore的安全启动流程,但是这种流程就是安全可靠的吗?不确定,因此对启动流程基于信息安全的TARA分析基和于功能安全的HARA分析必不可少。
1、安全启动的TARA分析
首先我们来看看什么叫做TARA分析。
在ISO\SAE 21434 中对于TARA描述为threat analysis and risk assessment,即威胁分析和风险评估。这个使用模块化的方法,用于评估信息安全的风险程度,大致可以按以下步骤总结:运行环境描述 -> 风险资产定义及影响分级 -> 危险场景定义 -> 攻击路径分析 -> 攻击可行性分析 -> 风险等级定义 -> 预防机制。
按照上述步骤,要对安全启动进行分析。首先就要确定安全启动的运行环境:在当前多核MCU架构下,HSM充当一个安全岛,运行时相对独立,此外由于HSM自身特性,其BootRom可以作为安全启动的信任根。除了上述环境,我们还要对整个安全启动的流程进一步梳理,分析每一个启动步骤的信息安全风险(这里不考虑OTA/离线升级等情况)。
安全启动具体可以分为以下几个步骤:
对于每个步骤,我们来进行风险资产定义:
很明显,在安全启动中,有几个最为重要的风险资产:启动安全启动的标志位、待认证程序的签名、完成安全启动后应用程序的首地址。
那么在TARA分析中就要围绕着几个资产开始分析攻击场景。
步骤 | 风险资产 | 攻击方式 | 影响 | 受攻击根源 | 降低风险措施 |
硬件初始化 安全启动开始 | 安全启动标志位 | 修改标志位 | 1.跳过安全启动 2.无法预知应用程序的完整性和有效性 | 没有有效的标志位存储保护措施 | 将标志位存放至HSM的NVM或者OTP |
计算签名 | 签名值 | 1.修改预存签名 | 1.安全启动失败,系统无法正常运行 2.伪装有效的应用程序,导致系统处于非安全状态 | 对预存签名没有有效的保护 | 将预存签名存放至HSM的NVM或者OTP |
比对签名 | 签名结果 | 比对失败,但攻击者篡改为比对成果 | 1.伪装有效的应用程序,导致系统处于非安全状态 | 在非安全岛内运行比对代码 | 在HSM内部做比对处理 |
运行应用程序 | 应用程序首地址 | 篡改首地址 | 1.跳转至非安全应用程序,导致系统处于非安全状态 | 没有对启动地址做二次校验 | 1.在跳转前对启动地址做二次校验 2.存放启动地址到HSM的NVM |
基于上述简单的分析,我们大概对TARA分析有了初步的认知。注意,在TARA分析时与功能安全的HARA分析有较大的区别。TARA更注意与外来攻击者对于风险资产的攻击。而功能安全则主要预防MCU内部自身的功能失效。
废话不多说,我们来看看HARA分析
2、安全启动的HARA分析
HARA:Hazard analysis and risk assessment。来源于ISO26262-3
其中最重要的就是失效模式鉴别。老规矩,我们还是沿用上述表格的形式。
步骤 | 失效模式 | 影响 | 失效根源 |
硬件初始化 安全启动开始 | 跳转安全启动直接运行应用程序 | 代码未经验证,系统处于非安全状态 | 在BootRom阶段随机硬件实现 |
计算签名 | 1.错误的输入、得到正确的签名 2.正确的输入、得到错误的签名 | 1.待校验程序错误,安全启动成功 2.待校验程序正确,但安全启动失败 | 在签名计算期间出现了随机硬件失效 |
比对签名 | 1.错误结果,得到正确响应 2.正确结果,得到错误响应 | 1.待校验程序错误,安全启动成功 2.待校验程序正确,但安全启动失败 | 在签名比对期间出现了随机硬件失效 |
运行应用程序 | 1.应用代码被破坏 2.安全启动成功后,代码执行了“启动失败”分支 3.安全启动失败,执行了“启动成功”分支 | 1.执行了错误的应用代码 2.安全启动失败 3.系统处于非安全状态 | 代码执行跳转期间出现随机硬件失效 |
在上述分析里,我没有加入降低失效的措施,毕竟作为软件工程师,对硬件的活还是不敢乱说。
通过上面分析,其实可以发现,TARA和HARA分析是从两个不同的角度去对同一个东西进行风险评估,二者在切入点虽不一致,但分析方法上还是比较雷同。此外,在ISO26262和ISO\SAE21434的文档结构上,我发现这两者也很相似。所以想要摸清信息安全,建议首选掌握功能安全。注意哦,一个系统不是过了功能安全,信息安全就必定能过,信息安全主要还是从外部攻击的角度来对风险资产进行分析。