📚 课程目录第3章安全启动概述

3. 安全启动概述

安全启动，说白了就是给ECU的启动过程装上一把“信任锁”。

你想想看，如果攻击者往你的Flash里塞了一段恶意代码，ECU启动时直接跑起来，那后果不堪设想。我早年做T-Box项目时就遇到过类似的事——一台样机莫名其妙在夜间自唤醒发数据，查了三天才发现是Bootloader被篡改过。从那以后，我对安全启动的敬畏心就刻进骨子里了。

3.1 信任链：从“根”开始

安全启动的核心逻辑，是逐级验证、链式传递。ECU上电后，第一个执行的代码必须是绝对可信的。这个“绝对可信”的起点，我们叫它信任根（Root of Trust, RoT）。

在AUTOSAR架构里，信任根通常固化在Bootloader的第一阶段（BLS1），或者直接放在HSM（硬件安全模块）的ROM里。硬件一上电，HSM先跑，它用自己的公钥去验Bootloader的签名。验过了，才把执行权交给Bootloader。Bootloader再验Application。一环扣一环，任何一环断了，系统就卡住——这叫安全锁死。

  关键原则：信任链的长度越短越好。每多一级验证，就多一个攻击面。我个人习惯把信任链控制在3级以内：HSM → Bootloader → Application。

3.2 签名验证：不是“验一下”那么简单

签名验证听起来简单——拿公钥解签名，算哈希，比对。但实际落地时，坑不少。

3.2.1 验签流程

读取镜像头：Bootloader先读Application镜像的头部，里面包含了签名值、算法标识、镜像版本号。
计算哈希：对镜像的代码段+数据段做SHA-256（或更高强度）哈希计算。
公钥解密：用存储在HSM或OTP区域的公钥，解密签名值，得到原始哈希。
比对：两个哈希一致，验证通过；不一致，直接跳转失败处理流程。

这里有个细节——公钥存在哪？我见过不少方案把公钥直接写在Bootloader的常量区。这其实不安全，因为如果攻击者能改Bootloader，就能换公钥。正确的做法是：公钥的哈希存在HSM的OTP（一次性可编程）区域，Bootloader启动时先验公钥的完整性，再用公钥验镜像。

我的经验：验签时一定要加“防重放”机制。我曾经遇到一个案例，攻击者把旧版本的合法镜像刷进去，虽然签名是对的，但版本里有已知漏洞。所以验签通过后，必须检查版本号是否大于等于当前版本。

3.2.2 签名算法选型

算法	密钥长度	安全性	计算开销	我的建议
RSA	2048/4096	高	高（指数运算）	适合资源充足的MCU
ECDSA	256/384	高	中（椭圆曲线）	我优先推荐，性能好
Ed25519	256	极高	低（固定时间）	新项目首选，抗侧信道

我个人习惯用ECDSA P-256。它在安全性和性能之间平衡得最好。如果你用的MCU带硬件加速（比如Infineon TC3xx的HSM支持ECC），那验签时间可以压到毫秒级。

3.3 Bootloader与App的签名验证实战

我们来看一个实际的代码片段。这是Bootloader验签Application的核心逻辑，我用伪代码风格写，方便你理解流程。

/* Bootloader 验签 Application 镜像 */
status_t verify_application_image(void) {
    image_header_t *hdr = (image_header_t *)APP_BASE_ADDR;
    
    // 1. 检查镜像魔数，防止刷错区域
    if (hdr->magic != APP_MAGIC) {
        return STATUS_ERR_MAGIC;
    }
    
    // 2. 检查版本号，防止回滚
    if (hdr->version <= current_version) {
        return STATUS_ERR_ROLLBACK;
    }
    
    // 3. 计算镜像哈希
    uint8_t hash[SHA256_DIGEST_SIZE];
    sha256_calc((uint8_t*)(APP_BASE_ADDR + sizeof(image_header_t)),
                hdr->image_size, hash);
    
    // 4. 从HSM获取公钥并验签
    hsm_public_key_t pub_key;
    hsm_read_otp_key(&pub_key);
    
    if (ecdsa_verify(hash, hdr->signature, &pub_key) != 0) {
        return STATUS_ERR_SIGNATURE;
    }
    
    // 5. 更新版本号，写入备份区
    current_version = hdr->version;
    save_version_to_backup(current_version);
    
    return STATUS_OK;
}

注意：验签失败后，千万不要直接跳转App！我见过一个设计，验签失败后Bootloader打印了错误日志就继续启动App，结果被攻击者利用这个“宽容”特性绕过了安全启动。正确的做法是：验签失败后，进入安全恢复模式（比如等待CAN刷写指令），或者直接锁死ECU。

3.4 回滚保护机制：防“降级攻击”

回滚保护，说白了就是不让旧版本（有漏洞的）的镜像跑起来。攻击者经常干的事就是：拿到一个旧版本的合法签名镜像，刷进ECU，利用旧版本的已知漏洞搞破坏。

3.4.1 版本号管理

最直接的做法是维护一个单调递增的版本号。Bootloader里存一个“最小允许版本号”，每次刷写时检查新镜像的版本号必须大于等于这个值。

但这里有个坑——版本号存哪？

存Flash里：容易被改，攻击者可以把版本号改小。
存HSM的NVM里：相对安全，但HSM的NVM有擦写寿命限制。
存OTP区域：最安全，但只能写一次，适合量产时固化最低版本。

我个人的做法是组合使用：OTP里存一个“硬地板版本号”（比如V1.0），HSM的NVM里存“当前版本号”。Bootloader启动时，取两者中的最大值作为实际允许的最低版本。这样既保证了安全性，又保留了升级灵活性。

3.4.2 回滚计数器

除了版本号，还可以用回滚计数器。每次成功刷写新镜像，计数器加1。Bootloader启动时检查计数器是否与镜像头里的计数器值一致。如果不一致，说明镜像被替换过。

这个方法的好处是：即使攻击者拿到了旧镜像，也无法伪造计数器值。缺点是：计数器需要额外的存储空间，而且如果刷写过程中断电，计数器可能不一致——需要做原子写入保护。

避坑指南：我曾经在一个项目里只用了版本号做回滚保护，结果发现攻击者可以通过修改Flash里的版本号存储区来绕过。后来我加了HSM的CMAC（消息认证码）对版本号做完整性保护，才堵住这个漏洞。记住：任何存储在Flash里的安全关键数据，都必须有完整性保护。

3.5 安全启动流程图

下面这张图展示了完整的信任链传递过程。我把它画成SVG，方便你直接用在文档或PPT里。

3.6 安全启动的“最后一公里”

嗯，这里要注意一个容易被忽略的点——安全启动的日志输出。调试阶段，我们习惯把验签结果通过UART打印出来。但量产时，这些日志必须关掉，否则攻击者可以通过日志信息推断你的验签流程和密钥存储位置。

我见过一个产品，量产固件里还留着“Signature verification passed”的打印语句。攻击者通过分析日志，定位到了验签函数入口，然后尝试了缓冲区溢出攻击。虽然最后没成功，但这个风险本可以避免。

所以我的习惯是：调试版和量产版用不同的编译配置。调试版开日志，量产版全关。而且量产版的错误处理要模糊化——不要告诉攻击者“验签失败”还是“版本号过低”，统一返回“启动失败”就行。

  总结一下安全启动的三个核心点：
  信任链：从HSM到Bootloader到App，逐级验证，不可跳过。
签名验证：用强算法（推荐ECDSA P-256），公钥存HSM OTP，验签后必须查版本号。
回滚保护：单调递增版本号 + 完整性保护（CMAC），必要时加回滚计数器。

安全启动不是“加上就完事”的功能。它需要和硬件、HSM固件、刷写流程深度配合。我建议你在项目初期就把安全启动的验证逻辑写进测试用例，每次刷写后自动跑一遍验签流程，确保整个链条没断。否则等到量产了才发现问题，那代价就大了。