4. 安全启动威胁模型与安全需求定义

在RH850平台上做安全启动，第一步不是写代码，而是把“敌人是谁、从哪进来、要防到什么程度”讲清楚。威胁模型的作用，就是把模糊的“要安全”翻译成可验证的工程约束：哪些资产必须保护、攻击者具备什么能力、攻击路径在哪里、失败后果有多严重。只有威胁模型清晰，后续的密钥体系、启动校验点、回滚策略和FOTA签名方案才有依据，否则很容易出现“校验做了但防不住回滚”或“签名验了但密钥本身可被替换”的漏洞。

一、常见攻击面：固件篡改、回滚与克隆

安全启动面对的攻击面，通常围绕“代码从哪里来、是否被改过、是否被换旧、是否被复制到非授权设备”展开。对RH850这类车规MCU，最典型的三类攻击是：

• 固件篡改（Tampering）：攻击者通过调试口、刷写接口、OTA通道或物理拆解，修改Flash中的启动代码、应用代码或配置区。典型手法包括直接改写向量表、替换校验函数、注入恶意跳转。若启动流程只做简单CRC而不做签名验证，篡改后的固件仍可被“合法”加载。
• 回滚攻击（Rollback）：攻击者不修改代码内容，而是把设备降级到存在已知漏洞的旧版本固件。旧版本可能带有已公开的CVE、调试后门或弱密钥。回滚攻击的关键在于：旧固件本身签名有效，若启动流程只验签名不验版本，回滚就会成功。
• 克隆攻击（Cloning）：攻击者把一台合法设备的完整固件镜像复制到另一台设备上，或批量复制含密钥的镜像。克隆不改变固件内容，但破坏了“一机一密”或“设备身份绑定”的信任前提。若密钥在产线被批量写入且未与芯片唯一ID绑定，克隆成本极低。

这三类攻击并非孤立。例如，攻击者可能先通过调试口读出密钥，再篡改固件并重新签名；或者先克隆合法镜像，再在克隆设备上实施回滚。因此威胁模型必须考虑组合路径，而不是只防单点。

二、安全启动目标：完整性、真实性与机密性

安全启动的三大目标，对应三类不同的密码学机制和验证时机：

• 完整性（Integrity）：确保固件在存储和传输过程中未被意外或恶意修改。常用手段是哈希（如SHA-256）或MAC。完整性校验回答“数据有没有变”，但不回答“谁写的”。
• 真实性（Authenticity）：确保固件来自可信的发布者，且未被伪造。常用手段是数字签名（如ECDSA P-256、RSA-2048）或带密钥的MAC。真实性回答“这是不是我们签的”。
• 机密性（Confidentiality）：确保固件中的敏感内容（如标定数据、算法参数、密钥材料）不被未授权读取。常用手段是AES加密或安全存储。机密性回答“别人能不能看懂”。

在RH850安全启动中，完整性和真实性通常由BootROM或安全启动固件在每次上电时验证；机密性则更多体现在FOTA传输和密钥存储环节。需要强调的是：签名验证天然包含完整性验证，因为签名是对哈希值签名，哈希不匹配则签名必然失败。因此工程上常把“验签”作为完整性与真实性的统一入口，但版本号、设备ID等元数据仍需单独校验，以防回滚和克隆。

三、ISO 21434与EVITA对安全启动的要求

ISO 21434是道路车辆网络安全工程标准，它不规定具体算法，而是要求建立“威胁分析—风险评估—安全需求—验证确认”的闭环。对安全启动而言，ISO 21434要求：识别资产（启动代码、密钥、标定区）、识别攻击路径（调试口、OTA、物理访问）、评估影响（安全、财务、隐私）、定义安全目标（如“防止未授权固件执行”），并保留可追溯的验证证据。换句话说，ISO 21434要求你把威胁模型写成文档，并证明安全启动措施覆盖了这些威胁。

EVITA是欧洲车辆入侵保护架构项目，它提出了三类硬件安全模块（HSM）分级：Full、Medium、Light。对安全启动的要求集中在：密钥必须存储在受保护的HSM或安全区中，签名验证应在HSM内完成，启动过程中密钥不可被外部读取。EVITA还强调安全启动应支持“安全状态”输出，即验证失败时MCU应进入受限模式或安全降级模式，而不是继续运行未验证代码。

在RH850平台上，通常结合ICUM（智能密码单元）或CSIH/CSIG等安全外设实现EVITA Medium级别的安全启动：BootROM先验证一级引导程序，一级引导程序再验证应用固件，密钥存放在受保护的OTP或HSM密钥槽中，版本号写入单调计数器或安全Flash区，设备唯一ID参与密钥派生以抵抗克隆。

四、从威胁模型到安全需求：一份可执行的映射

把上述分析落到RH850工程上，安全需求应当写成可验证的条目，而不是“要安全”这种口号。以下是一份示例性的安全需求映射表，参数为教学假设，实际项目需根据OEM要求和芯片型号调整：

这张表的价值在于：每一条安全需求都有明确的威胁来源、密码学机制和可执行的验证方法。在RH850项目中，验证方法通常通过“故意破坏—观察行为”来完成，例如篡改Flash中某个字节后重新上电，观察MCU是否停留在BootROM阶段、是否输出错误码、是否进入安全降级模式。只有验证通过的条目，才能作为ISO 21434要求的“安全证据”归档。

五、工程实践中的关键判断

在RH850上实施安全启动时，有几个容易踩坑的判断点。第一，验签范围：只验应用固件不够，一级引导程序本身也必须被BootROM验证，否则攻击者可以替换引导程序来绕过后续校验。第二，版本号存储位置：单调计数器若放在普通Flash区，可能被回滚攻击一并改写，应放在OTP或受HSM保护的区域。第三，失败行为：验签失败后不能简单跳转到某个“恢复模式”而恢复模式本身未经验证，否则会形成新的攻击面。第四，调试口管理：量产设备应关闭或锁定调试口，否则攻击者可直接读取密钥或改写Flash。

从威胁模型到安全需求，再到验证证据，这条链路是安全启动工程的核心。RH850提供了BootROM、ICUM、OTP等硬件基础，但如何组织校验层级、如何绑定设备身份、如何设计失败降级策略，仍然取决于前期威胁模型是否完整。只有把攻击面、安全目标和标准要求三者对齐，后续的FOTA签名、密钥轮换和生命周期管理才有稳固的起点。