设备开机那一秒，谁在“验明正身”？——聊聊安全启动（Secure Boot）到底在防什么

大家好，我是 Echo_Wish。
混鸿蒙、嵌入式、系统这条线久了，你会发现一个很有意思的现象：

很多安全事故，不是系统“跑着跑着”出问题，而是“一开始就不干净”。

木马不是运行时注入的，
Root 权限不是后面提权的，
系统在你按下电源键那一刻，就已经“站错队”了。

这时候你再谈权限、沙箱、加密存储，
说句不好听的——都晚了。

所以今天咱们就从一个“很底层、但极其重要”的话题聊起：
👉 安全启动（Secure Boot）原理
尤其结合 鸿蒙 / 设备系统 的真实工程视角，聊清楚它到底在“防谁”。

一、引子：为什么很多系统“天生不安全”？

我先问你一个问题，很真实的那种：

你怎么确定，现在跑在设备上的系统，
真的是你当初烧进去的那个系统？

很多人第一反应是：

“当然是啊，不然还能是谁？”

但在真实世界里，攻击路径是这样的：

• 替换 Bootloader
• 篡改内核
• 插入恶意 init 代码
• 系统启动后“一切看起来都很正常”

你看到的是“正常启动”，
攻击者看到的是“完美潜伏”。

这类攻击有个共同点：

它们发生在系统“启动之前”。

而 Secure Boot，
防的正是这一类“你还没醒，它已经动手”的问题。

二、原理讲解：安全启动，其实就一句话

我用一句人话总结 Secure Boot：

系统不是谁都能启动，必须“验明正身、逐级放行”。

它的核心思想非常朴素：

• 不信任任何“后来加载的东西”
• 每一步，都由上一步“签字背书”
• 一旦校验失败，直接拒绝启动

启动链（Chain of Trust）

安全启动不是一个点，而是一条链：

ROM → Bootloader → Kernel → System → App

关键逻辑是：

• ROM 是唯一的“天生可信”
• 后面的每一段代码，都必须被前一段验证

只要链条中断一次：

系统宁可不开机，也不能乱开机

三、鸿蒙 / 设备里的 Secure Boot 是怎么落地的？

在鸿蒙设备（尤其是 IoT、终端、车机）里，
安全启动通常基于这几个核心组件：

1️⃣ Root of Trust（信任根）

• 固化在 ROM 或安全芯片里
• 包含公钥（或公钥 Hash）
• 代码不可修改

这一步的逻辑是：

世界上只能有一个“我绝对信的东西”

2️⃣ 签名 + 校验（这是灵魂）

以 Bootloader 为例，流程大概是：

读取 Bootloader → 校验签名 → 校验通过才执行

伪代码我给你写个“工程师版”的：

bool verify_image(uint8_t* image, uint8_t* signature) {
    uint8_t hash[32];
    sha256(image, image_len, hash);
    return rsa_verify(hash, signature, public_key);
}

void boot() {
    if (!verify_image(bootloader, boot_sig)) {
        halt(); // 不启动，直接趴窝
    }
    jump_to(bootloader);
}

注意这点：

不是“启动了再校验”，而是“校验通过才有资格启动”。

3️⃣ 一层校一层，谁也别想越级

Bootloader 启动 Kernel 前，再校一次：

Bootloader → 校验 Kernel → 校验 System Image

这就是所谓的：

Chain of Trust（信任链）

四、实战代码：一个“极简安全启动校验”示例

我们用一个偏通用的例子，模拟“校验系统镜像签名”。

镜像签名（构建阶段）

openssl dgst -sha256 -sign private.pem kernel.img > kernel.sig

启动阶段校验（伪代码）

bool secure_boot_check() {
    uint8_t hash[32];
    sha256(kernel_img, kernel_len, hash);

    if (!rsa_verify(hash, kernel_sig, public_key)) {
        log("Secure Boot Failed!");
        return false;
    }
    return true;
}

只要签名不对：

• 镜像被篡改
• 版本非法
• 来源不可信

统统过不了这一关。

五、场景应用：Secure Boot 到底解决了哪些现实问题？

场景 1：防刷机、防山寨

很多设备厂最头疼的是什么？

第三方刷系统，功能正常，安全失控。

有 Secure Boot：

• 非官方签名的系统无法启动
• 破解成本大幅提升

场景 2：防底层 Rootkit

Rootkit 最喜欢干的事是：

• 改 Kernel
• 改 init
• 改启动脚本

Secure Boot 直接一句话解决：

你改可以，但你得有私钥。

场景 3：车机 / IoT 的“物理攻击”

设备被拆、被接 JTAG、被 dump flash？

Secure Boot 的态度是：

我不怕你看，我怕你改。

六、Echo_Wish 式思考：为什么我越来越看重 Secure Boot？

说点掏心窝子的。

我以前也觉得：

“安全启动太底层了，
应用安全、系统权限才重要。”

但越做系统，越发现一个事实：

启动阶段不安全，后面所有安全都是“表演”。

Secure Boot 有几个非常现实的价值：

1️⃣ 它是“零信任”的起点
2️⃣ 它决定了系统有没有资格谈安全
3️⃣ 它把攻击成本，直接拉到“硬件级”

当然，它也不是银弹：

• 私钥管理一塌糊涂，一样翻车
• 供应链被攻破，也挡不住
• Debug 版本忘关，一样被绕

但即便如此，我依然认为：

没有 Secure Boot 的系统，
就像没锁门的金库。

写在最后

安全启动这东西，平时你几乎“感觉不到它的存在”，
但一旦出事，你会发现：

它是唯一还能救场的那道防线。

在鸿蒙、终端、IoT 这类“长期运行、不可随便升级”的系统里，
Secure Boot 不是加分项，
而是入场券。