📚 课程目录第3章安全启动威胁模型与需求分析

3. 安全启动威胁模型与需求分析

安全启动不是“加一个校验”这么简单，它首先是一套针对具体攻击面的防御设计。对 RA 系列 MCU 而言，攻击者通常不需要物理拆解芯片，也可能通过调试口、通信接口、外部 Flash 或升级通道发起攻击。因此，在写任何一行校验代码之前，必须先回答三个问题：谁在攻击、从哪里进入、成功后会造成什么后果。这就是威胁模型的作用——它把模糊的“不安全”转化为可验证、可分配的安全需求。

四类核心威胁及其攻击路径

针对 RA 设备的固件攻击，最典型的是四类：固件篡改、版本回滚、设备克隆和中间人攻击。它们的目标不同，攻击入口也不同。

固件篡改的目标是让设备运行未经授权的代码。攻击者可能直接改写外部 SPI Flash 中的应用程序镜像，也可能在 OTA 升级过程中替换传输的固件包。如果 Bootloader 只检查“镜像是否存在”而不验证签名，篡改后的固件就会被正常加载。RA 的 TrustZone 或安全 MPU 可以限制对关键区域的写访问，但前提是启动链本身可信。

版本回滚更隐蔽：攻击者不修改固件内容，而是把设备降级到存在已知漏洞的旧版本。例如，某旧版固件存在已公开的通信协议漏洞，攻击者通过升级通道写入旧版签名镜像。由于旧版镜像的签名本身是合法的，仅靠“签名验证”无法阻止。防御回滚必须引入单调递增的版本计数器，并把它与安全存储绑定。

设备克隆针对的是身份与密钥。攻击者从一台设备中读出密钥或证书，复制到另一台设备上，使克隆设备能够通过服务器认证。RA 的 MCU 通常提供唯一 ID、安全密钥存储和加密引擎，但如果密钥在生命周期内可被读出，克隆就不可避免。因此，安全启动需求必须包含“密钥不可导出”和“设备身份绑定”。

中间人攻击发生在升级或远程认证通道上。攻击者拦截设备与服务器之间的通信，替换固件包或重放旧响应。即使固件本身有签名，如果设备不验证服务器身份、不校验会话新鲜度，攻击者仍可能诱导设备接受恶意数据。防御需要双向认证、会话随机数和消息完整性保护。

从威胁到需求：可验证的安全启动需求

威胁模型的价值在于导出可执行、可测试的需求。针对上述四类威胁，RA 安全启动至少应满足以下六项需求，每项都可以在代码或配置中找到对应落点。

编号	安全需求	对应威胁	RA 实现落点
R1	启动链每一级必须验证下一级镜像的数字签名	固件篡改	Boot ROM → Bootloader → App 逐级 ECDSA 验证
R2	固件版本号必须单调递增，且存储于不可回退区域	版本回滚	OTP 或安全 Flash 中的版本计数器
R3	设备私钥和对称密钥不可通过任何接口读出	设备克隆	RA 安全密钥存储 + 加密引擎内部使用
R4	升级通道必须双向认证并抵抗重放	中间人攻击	TLS 双向认证 + 会话随机数 + 时间戳
R5	量产设备必须锁定调试接口	固件篡改/克隆	RA 选项设置存储器中的调试使能位
R6	验证失败必须进入安全状态并记录事件	全部	安全状态机 + 事件日志写入受保护区域

实际攻击场景与防御验证示例

下面以一个具体的 OTA 升级场景说明威胁如何落地，以及需求如何被验证。假设某 RA6M5 设备通过以太网接收固件包，当前运行版本为 v1.3，服务器下发 v1.4。攻击者试图在传输过程中替换为篡改后的 v1.4 镜像。

设备端 Bootloader 的验证流程如下：首先从镜像头读取版本号、签名算法和公钥索引；然后计算镜像体的 SHA-256 摘要；接着用固化在 Boot ROM 中的公钥哈希验证镜像签名；最后检查版本号是否大于等于当前安全存储中的版本计数器。如果签名验证失败，设备拒绝写入并记录事件；如果版本号小于当前值，同样拒绝，防止回滚。

// 示例：RA Bootloader 镜像验证伪代码（参数为教学示例）
#define CURRENT_VERSION  0x00010003  // v1.3，存储于安全 Flash
#define NEW_VERSION      0x00010004  // v1.4，来自镜像头

bool verify_image(image_header_t *hdr, uint8_t *body, uint32_t len) {
    // 1. 版本防回滚检查
    if (hdr->version < CURRENT_VERSION) {
        log_event(EVENT_ROLLBACK_ATTEMPT);
        return false;
    }
    // 2. 计算镜像摘要
    uint8_t digest[32];
    sha256(body, len, digest);
    // 3. 使用 RoT 公钥验证签名
    if (!ecdsa_verify(hdr->pubkey_id, digest, hdr->signature)) {
        log_event(EVENT_SIGNATURE_FAIL);
        return false;
    }
    // 4. 验证通过，更新版本计数器
    secure_flash_write(VERSION_ADDR, hdr->version);
    return true;
}

在这个示例中，攻击者若替换镜像体，SHA-256 摘要改变，签名验证失败；若重放旧版 v1.2 镜像，版本号小于当前 v1.3，防回滚检查拒绝；若试图通过调试口读出密钥，量产锁定后调试接口不可用。三个防御点分别对应 R1、R2、R5，形成交叉覆盖。

判断依据：验证是否通过，不能只看“有没有签名”，而要看三个条件是否同时成立——签名有效、摘要匹配、版本号不低于当前值。任何一项失败都应进入安全状态，而不是继续启动。

需求优先级与裁剪原则

并非所有 RA 设备都需要同等强度的安全启动。对于消费类产品，可能只需 R1 和 R5；对于工业网关或医疗设备，R2、R3、R4 往往不可裁剪。裁剪时必须记录理由：如果省略防回滚，必须说明设备不具备远程升级能力，或旧版本不存在已知漏洞。安全需求不是越多越好，而是每一条都能追溯到具体威胁，并且有明确的验证方法。

常见误区：把“签名验证”等同于“安全启动”。签名只解决完整性和来源认证，无法阻止回滚、克隆和中间人重放。威胁模型要求我们逐条检查：每个威胁是否至少有一个需求覆盖，每个需求是否有可执行的验证点。

总结来说，RA 安全启动的需求分析应围绕“篡改、回滚、克隆、中间人”四条威胁线展开，把每条威胁映射到信任根、镜像验证、防回滚、身份与通道保护、调试锁定和失败响应六个防御面。只有完成这种映射，后续的密钥配置、启动流程实现和测试用例设计才有明确的依据。