1. 安全启动概述：车载MCU面临的威胁、安全启动的定义与目标、TEE与HSM基础概念

1.1 车载MCU面临的安全威胁

说实话，我刚入行做车载嵌入式那会儿，对安全的理解还很浅。总觉得MCU跑在封闭的CAN网络上，能有什么风险？直到有一次，我在做OTA升级测试时，发现一个恶意固件包居然能绕过校验直接刷进Flash里。嗯，那次之后我才真正意识到——车载MCU面临的威胁，远比我们想象的要严重。

车载MCU面临的主要威胁，我归纳为以下几类：

  • 固件篡改攻击：攻击者通过物理访问（如JTAG/SWD接口）或远程漏洞，直接修改Flash中的固件代码。我在项目中就遇到过，有人通过OBD接口注入恶意CAN报文，试图刷写篡改过的固件。
  • 回滚攻击：将固件版本回退到存在已知漏洞的旧版本。我记得有个客户，他们的ECU没有做版本回滚防护，结果被攻击者刷回了三年前的固件，安全机制形同虚设。
  • 侧信道攻击：通过分析功耗、电磁辐射、执行时间等物理特征，窃取密钥或敏感数据。说白了，就是你的芯片在“说话”，攻击者在“偷听”。
  • 调试接口攻击：通过JTAG/SWD等调试接口直接读取内存、寄存器，甚至控制CPU执行流程。我曾经在测试中，用J-Link直接读出了一颗未锁定的MCU的全部固件——整个过程不到30秒。
  • 总线监听攻击：在CAN/CAN-FD、LIN、FlexRay等总线上挂载嗅探设备，窃取通信数据或注入伪造报文。
⚠️ 注意： 很多开发者认为“我的MCU没有联网，所以很安全”。这是典型的误区。车载MCU即使不联网，通过物理接触、CAN总线、甚至无线钥匙（如无钥匙进入系统）都可能被攻击。安全不是选择题，而是必答题。

1.2 安全启动的定义与目标

安全启动（Secure Boot），说白了就是确保MCU上电后，执行的第一段代码是可信的、未被篡改的。它像是一道“安检门”，从芯片复位开始，逐级验证每一段代码的完整性和真实性。

安全启动的核心目标，我总结为三点：

  1. 完整性验证：确保固件在存储或传输过程中没有被篡改。通常使用哈希算法（如SHA-256）计算固件的摘要值，与预期值比对。
  2. 真实性验证：确保固件来自合法的发布者（如OEM或Tier1供应商）。通常使用非对称签名算法（如RSA、ECDSA）进行数字签名验证。
  3. 信任链传递：从芯片内置的不可变信任根（Root of Trust, RoT）开始，逐级验证Bootloader、应用程序固件，形成一条完整的信任链。

我习惯把安全启动比作“洋葱模型”——每一层都包裹着下一层，只有通过验证才能剥开。一旦某一层验证失败，MCU就会进入安全状态（如死循环、复位或报警）。

💡 关键点： 安全启动不是“一次性”的。它需要贯穿整个固件生命周期——从开发、编译、签名、分发、存储到运行时的每次启动。任何一个环节出现漏洞，整个信任链就会崩塌。

1.3 TEE与HSM基础概念

聊完安全启动，我们得说说它的两个“好搭档”——TEE和HSM。这两个概念经常被混淆，我刚开始也傻傻分不清。后来在项目中踩过坑，才真正理解了它们的区别和联系。

1.3.1 TEE（可信执行环境）

TEE，全称Trusted Execution Environment，中文叫可信执行环境。它是在主处理器内部，通过硬件隔离出来的一个安全区域。这个区域与普通的“富执行环境”（REE，如Linux、RTOS）完全隔离。

TEE的特点：

  • 硬件隔离：通过ARM TrustZone、RISC-V物理内存保护（PMP）等硬件机制，实现安全世界与普通世界的隔离。
  • 安全服务：在TEE中运行安全应用（如密钥管理、指纹比对、支付认证），普通世界无法直接访问。
  • 最小化攻击面：TEE中的代码量通常很小（几十KB到几百KB），减少了漏洞出现的概率。

我记得在做一个T-Box项目时，需要将车辆的私钥存储在TEE中。当时我犯了个错误——把私钥直接以明文形式写在了TEE的存储区。后来才发现，TEE虽然隔离了访问，但存储区本身如果没有加密，还是会被物理攻击读取。嗯，这个坑我替你们踩过了。

1.3.2 HSM（硬件安全模块）

HSM，全称Hardware Security Module，中文叫硬件安全模块。它通常是一个独立的硬件芯片（如Infineon SLI系列、NXP S32K的HSE），或者集成在MCU内部的安全协处理器。

HSM的核心功能：

  • 密钥安全存储：密钥存储在HSM内部的非易失性存储器中，外部无法直接读取。
  • 密码学加速：硬件加速执行AES、RSA、ECDSA、SHA等算法，比软件实现快几个数量级。
  • 安全启动加速：HSM可以独立完成固件签名的验证，不占用主CPU资源。
  • 真随机数生成：基于物理噪声源生成高质量的随机数，用于密钥生成和挑战-响应协议。
🔧 实战建议： 在选择HSM时，不要只看算力。我曾经在一个项目中，选了一颗算力很强的HSM，结果发现它的Flash擦写次数只有1万次——根本扛不住OTA频繁升级。一定要关注HSM的耐久性、功耗和温度范围，这些在车载环境下至关重要。

1.3.3 TEE vs HSM：怎么选？

你可能会问：TEE和HSM到底有什么区别？我该用哪个？

我个人的理解是这样的：

维度 TEE HSM
实现方式 软件+硬件隔离（如TrustZone） 独立硬件芯片或协处理器
隔离级别 逻辑隔离（同一CPU核） 物理隔离（独立芯片/核）
性能 依赖主CPU，可能影响实时性 独立硬件加速，性能高
密钥保护 受限于TEE软件实现 硬件级保护，抗物理攻击
典型应用 安全启动、DRM、支付 安全启动、CAN通信加密、V2X
成本 较低（利用现有CPU） 较高（额外硬件）

说白了，如果你的MCU算力够、对实时性要求不高，TEE是个性价比不错的选择。但如果你做的是安全等级极高的域控制器或网关，HSM几乎是必须的——因为它能扛住物理攻击，比如探针直接读Flash。

1.4 安全启动与TEE/HSM的协同

在实际项目中，安全启动往往不是孤立的。它需要和TEE或HSM配合，才能形成完整的安全体系。

我画一个简单的流程，你感受一下：

MCU上电复位
    ↓
BootROM（不可变信任根）执行
    ↓
BootROM验证第一级Bootloader（通过HSM或TEE中的公钥验证签名）
    ↓
第一级Bootloader验证第二级Bootloader或应用程序
    ↓
应用程序启动，同时TEE/HSM提供运行时安全服务（如密钥派生、CAN报文加密）

你看，从复位到应用启动，每一步都离不开TEE或HSM的参与。它们提供了密钥存储、签名验证、随机数生成等基础能力，让安全启动不再是“空中楼阁”。

🎯 核心总结： 安全启动是“骨架”，TEE和HSM是“肌肉”。没有骨架，肌肉无处附着；没有肌肉，骨架只是一堆死物。三者缺一不可。

1.5 避坑指南：我踩过的三个坑

最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路：

  1. 坑一：信任根没锁死。我曾经在一个项目中，BootROM的代码是可以被外部工具擦除的。结果测试时发现，攻击者只要用调试器擦掉BootROM，就能绕过所有安全启动检查。记住：信任根必须是物理不可变的，比如一次性编程（OTP）或掩膜ROM。
  2. 坑二：签名密钥硬编码在固件里。嗯，这个错误我现在想起来都觉得脸红。当时为了调试方便，把私钥直接写在了代码里。结果固件被反编译后，密钥直接暴露。正确的做法是：私钥永远只存储在HSM或安全服务器中，固件里只放公钥。
  3. 坑三：忽略了回滚防护。有一次做OTA升级，只验证了新固件的签名，但没有检查版本号。结果攻击者刷回了一个有漏洞的旧版本，安全机制全部失效。从那以后，我每次做安全启动都会加上版本号检查，并且用HSM的单调计数器来防止回滚。

好了，第一章的内容就到这里。安全启动是个大话题，后面我们会一步步深入。下一章，我会带大家手写一个基于HSM的安全启动流程，从代码层面看看它是怎么工作的。

← 上一章 📖 返回目录 下一章 →