4、Trusted Board Boot (TBB) 中的回滚保护：TBB框架简介，证书链与版本号绑定，验证流程
好，咱们今天聊聊TBB里的回滚保护。说实话，这个机制是我在ATF移植中觉得最巧妙的设计之一。你想想看，如果没有回滚保护，攻击者完全可以拿一个旧版固件刷进去，利用已知漏洞轻松攻破系统。嗯，我在一个IoT项目里就遇到过这种攻击——设备被降级到三年前的固件版本，然后被轻松拿下。
4.1 TBB框架简介
TBB，全称Trusted Board Boot，是ARM定义的一套安全启动框架。它的核心目标就三个：
- 验证镜像来源——确保固件来自可信的厂商
- 验证镜像完整性——确保固件没有被篡改
- 防止版本回滚——确保固件版本不会降低
我个人习惯把TBB理解成「数字签名链」。从Boot ROM开始，一级验证一级，直到操作系统启动。每一级都检查下一级的签名和版本号，形成一个完整的信任链。
关键点：TBB不是ARM独有的，但ARM把它做成了标准化框架。你在移植ATF时，只需要配置好密钥和证书链，就能获得完整的回滚保护能力。
4.2 证书链与版本号绑定
这里有个核心概念——证书链。说白了，就是一层套一层的数字证书。我画个图帮你理解：
你看这个结构，每个证书里都嵌入了版本号。根证书版本号是1.0，密钥证书是2.1，内容证书是3.2。这些版本号不是随便写的——它们和固件镜像的版本号是绑定的。
我的经验：在项目中，我建议把版本号设计成单调递增的整数。比如BL2版本从100开始，每次升级加1。这样既方便管理，又能防止版本号回绕。
4.3 验证流程
好，现在咱们看看TBB的验证流程。这个过程其实不复杂，但每一步都很关键。
- Boot ROM加载根证书——根证书的哈希值烧死在芯片里，无法修改。这是信任的起点。
- 验证密钥证书——用根证书的公钥验证密钥证书的签名。同时检查密钥证书的版本号是否 >= 当前已安装版本。
- 验证内容证书——用密钥证书的公钥验证内容证书的签名。再次检查版本号。
- 验证固件镜像——用内容证书的公钥验证固件镜像的签名和哈希。最后检查镜像版本号。
这里有个细节——版本号检查是在每一级都做的。为什么？因为攻击者可能只替换中间某个证书，而不动根证书。我曾经在调试一个客户问题时发现，他们只检查了最终镜像的版本号，结果攻击者通过替换中间证书绕过了保护。嗯，这个坑我踩过。
避坑指南：版本号检查必须贯穿整个证书链。不要只检查最后一环。我曾经见过一个方案，只在内容证书里检查版本号，结果攻击者用旧版密钥证书配合新版内容证书，成功绕过了回滚保护。
4.4 版本号存储与比较
版本号存在哪里？这是个好问题。通常有两种做法：
| 存储方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| OTP（一次性可编程） | 硬件保护，无法篡改 | 只能写入一次，升级麻烦 | 根证书版本号 |
| eFuse | 可多次烧写，灵活 | 数量有限，成本高 | 密钥证书版本号 |
| 安全存储区 | 容量大，可更新 | 依赖软件保护 | 内容证书版本号 |
我个人习惯把根证书版本号放在OTP里，密钥证书版本号放在eFuse里，内容证书版本号放在安全存储区。这样既保证了安全性，又兼顾了灵活性。
4.5 实际移植中的注意事项
在ATF移植中，TBB的配置主要在以下几个文件里：
// 证书链定义文件
plat/<platform>/include/platform_def.h
// 密钥配置
plat/<platform>/keys/rotpk_sha256.bin
// 版本号配置
plat/<platform>/include/plat_version.h这里有个容易踩的坑——版本号的初始值。我建议从1开始，而不是0。为什么？因为有些硬件平台把0当作「未初始化」状态，如果你从0开始，可能会和未初始化状态混淆。
核心要点总结：
- TBB通过证书链实现逐级验证
- 每个证书都绑定版本号，防止回滚
- 版本号检查必须贯穿整个证书链
- 版本号存储方式根据安全等级选择
好了，TBB的回滚保护机制就讲到这里。说白了，它就是一套「层层把关」的验证体系。你只要把证书链搭好，版本号配对，就能有效防止固件回滚攻击。我在多个项目里验证过这个方案，效果确实不错。