第1章安全启动概述

一、安全启动概述：基站安全威胁模型、安全启动的定义与目标、信任根（RoT）概念

各位同学，咱们今天正式开讲基站安全启动的第一课。说实话，我做了十几年基站固件防护，见过太多因为启动阶段被攻破而全盘皆输的案例。安全启动这事儿，说白了就是给基站装上一把从娘胎里就带出来的锁——你想想看，如果连最开始的启动代码都不安全，后面再强的防护都是白搭。

先聊聊威胁模型。我习惯把基站的敌人分成三类：

物理攻击者：能直接接触基站硬件的人。比如运维人员被收买、设备运输途中被动手脚。我记得有一次，客户发现某基站启动异常，最后查出来是有人在JTAG接口上焊了个小模块——嗯，这种事儿在野外基站并不罕见。
网络攻击者：通过回传网络或空口发起攻击。他们可能试图注入恶意固件、篡改启动参数。说白了，只要基站连着网，就有人想钻空子。
供应链攻击者：在固件编译、打包、分发过程中动手脚。这最隐蔽，也最致命。我曾经参与过一个事故分析，发现攻击者在固件镜像里嵌入了后门，而那个镜像居然通过了所有常规测试——因为后门只在特定条件下激活。

核心观点：基站的攻击面从硬件上电那一刻就打开了。安全启动要防的，就是任何未经授权的代码在启动阶段被执行。

安全启动，简单说就是「只运行可信的代码」。但这句话背后藏着不少门道。

我个人的理解是：安全启动要保证从第一行代码开始，整个启动链路上的每一个组件都是经过验证的、未被篡改的。它不是一个单一的技术，而是一套机制的组合。

具体目标有三个：

你可能会问：「那用哈希校验不就行了？」嗯，这里要注意——哈希只能保证完整性，不能保证来源。攻击者完全可以替换掉整个固件，然后重新计算哈希。所以安全启动必须结合数字签名。

实战经验：我在项目中遇到过一种情况：某厂商只做了CRC校验，觉得够用了。结果攻击者逆向出CRC算法后，直接修改固件并重新计算CRC，系统毫无察觉地加载了恶意代码。所以记住：CRC是检错用的，不是安全用的。

信任根，英文叫Root of Trust，简称RoT。这个概念是整个安全启动的基石。

说白了，信任根就是一个「绝对可信」的实体。它通常是一段不可修改的代码或硬件模块，位于芯片内部。所有后续的信任都建立在这个根之上。

为什么需要信任根？因为信任必须有个起点。你不能无限追溯下去——「这个代码是谁验证的？是上一个代码。那上一个代码又是谁验证的？再上一个...」这样会形成无限循环。信任根就是打破这个循环的锚点。

常见的信任根实现方式：

我个人更倾向于硬件信任根。为什么？因为不可修改。你想想看，如果信任根本身可以被篡改，那整个信任链就崩塌了。我曾经见过一个设计，把信任根放在Flash里——结果攻击者通过电压故障注入，让Flash读取出了错，绕过了验证。从那以后，我对「可修改的信任根」一直持保留态度。

重要提醒：信任根必须满足三个条件：
1. 不可绕过——启动路径必须经过它
2. 不可篡改——至少要有篡改检测机制
3. 行为可预测——每次启动行为一致

有了信任根，接下来就是建立信任链。这个过程有点像接力赛：

每一棒都只信任上一棒传递过来的东西。如果任何一环验证失败，系统就应该停止启动，或者进入安全恢复模式。

这里有个细节要注意：信任链的每一级都要有「前向安全」的考虑。什么意思？就是即使某一级被攻破了，也不能让攻击者逆向去伪造更早的签名。我在设计时通常会要求：每一级的公钥都存储在上一级的信任存储中，且私钥只在安全的签名服务器上使用。

一句话总结：信任根是「我是谁」的证明，信任链是「我带来的东西都是可信的」的传递过程。两者缺一不可。

最后分享几个实战中容易忽略的点：

坑一：信任根存储位置不当。我曾经见过把公钥放在可写Flash里的设计——那等于没锁门。公钥必须存储在一次性可编程（OTP）区域或硬件安全模块（HSM）中。
坑二：忽略回滚攻击。攻击者可能不篡改固件，而是把固件回滚到有漏洞的旧版本。所以安全启动必须包含版本号检查，只允许升级，不允许降级。
坑三：验证顺序错误。有些设计先加载固件到内存，再验证——这给了攻击者在验证前篡改内存的机会。正确的做法是：先验证，再加载执行。

好了，第一章的内容就到这里。安全启动听起来简单，但真正做好需要把每个细节都抠死。下一章我们会深入BootROM的设计，看看信任根到底是怎么在芯片层面实现的。