Jetson Edge AI 实战05：Secure Boot 到底在保护什么？PKC、SBK、Fuse 与可信启动链一次讲清【视频讲解】

做 Jetson 开发时，很多人会把 Secure Boot 简单理解成：

"给 Bootloader 加个密，别人就破解不了了。"

其实这个理解只说对了一小部分。

我更愿意用一句话概括 Secure Boot：

Secure Boot 的核心不是"藏住代码"，而是确保设备从上电开始，只执行我信任的代码。

也就是说，它首先解决的是信任问题，其次才是机密性问题。

对于一块开发板，这件事可能没那么急迫；但设备一旦进入工业现场、机器人、AI 相机或者需要 OTA 的量产产品，Secure Boot 就很难再绕过去。

这一讲，我们把 Jetson Secure Boot 里面最容易混淆的几个东西一次串起来：

BootROM → MB1 → MB2 → UEFI → Kernel

以及：

PKC、SBK、Fuse、EKB 到底分别负责什么。

课程基于 Jetson AGX Orin 64G Kit 展开。

🎬 点击进入 B站观看《Jetson Edge AI 实战05：Jetson Secure Boot》完整视频

为什么 Secure Boot 不是"可有可无"？

先不讲密码学，直接看如果没有 Secure Boot 会发生什么。

一台设备正常启动，本质上是在不断执行下一阶段的软件：

Bootloader → Kernel → RootFS → Application

问题是：

如果 Bootloader 本身已经被人换了呢？

后面的 Kernel、RootFS 再安全，还有多少意义？

没有可信启动机制以后，比较典型的风险包括：

Bootloader 被替换

攻击者可以加载自己修改过的 Kernel，甚至植入 Root 权限后门。

Kernel / DTB / RootFS 被修改

设备表面上仍然能够正常启动，但实际上系统内部已经被动过手脚。

OTA 被伪造

如果设备不能判断固件是否来自可信来源，就可能接受恶意升级包或者被降级到存在已知漏洞的旧版本。

知识产权暴露

Bootloader、Kernel 以及关键算法可能被提取和分析，上层 OP-TEE、密钥保护等安全机制也会失去可靠的启动基础。第5节课-Jetson Secure Boot

所以我觉得 Secure Boot 真正要回答的是：

设备现在运行的，究竟是不是我允许它运行的软件？

这才是问题的核心。

Secure Boot 的本质：建立一条信任链

Jetson Secure Boot 最核心的结构其实并不复杂。

直接看启动链：

可以先把它理解成：

text 复制代码

BootROM
   ↓
  MB1
   ↓
  MB2
   ↓
 UEFI
   ↓
Kernel

真正重要的不是有几个阶段，而是：

前一级在把执行权交给下一级之前，要先验证下一级。

BootROM 固化在 SoC 内部，可以作为整条安全链最底层的 Root of Trust。

BootROM 验证 MB1。

MB1 再继续验证后面的启动组件。

MB2、UEFI 一直到 Kernel，不断把这种"信任"向后传递。

所以 Secure Boot 最核心的逻辑可以写成一句话：

不是存储器里有什么就运行什么，而是只有验证通过的软件才获得执行权。

这就是 Chain of Trust。

PKC 和 SBK，不要再混在一起

理解 Jetson Secure Boot，最关键的两个词就是：

PKC

和

SBK

它们经常一起出现，但解决的根本不是同一个问题。

PKC：回答"这个东西可信不可信？"

PKC 使用非对称密码体系。

基本思路是：

私钥负责签名，设备端根据可信公钥信息完成验签。

如果镜像发生任何修改，签名验证就无法正常通过。

所以 PKC 主要保护的是：

完整性 + 来源可信。

简单一点记：

PKC：防篡改。

或者换一种说法：

PKC 决定这个镜像"能不能信"。

SBK：回答"这个东西能不能被直接看懂？"

SBK 是对称密钥。

它主要用于对 Bootloader 等镜像内容进行加密保护。

即使攻击者把存储中的镜像 dump 出来，也不能直接得到明文内容。

所以 SBK 主要保护的是：

机密性。

简单一点记：

SBK：防泄露。

所以千万不要把 PKC 和 SBK 都简单叫成"Secure Boot 加密"。

它们解决的是两个问题：第5节课-Jetson Secure Boot

机制	核心问题
PKC	镜像有没有被改，来源是否可信
SBK	镜像内容能不能被直接读取

我自己更喜欢记成：

PKC 决定"能不能信"。

SBK 决定"能不能看"。

这句话基本把两者区别讲明白了。

Fuse：真正把 Root of Trust 固化到芯片里

到了这里还有一个关键问题：

设备凭什么永久相信这套公钥和安全策略？

如果所谓的"可信公钥"存在普通 Flash 里，本身也能被随便修改，那整条信任链就没有意义。

这就是 Fuse 出场的地方。

Fuse 可以理解成 SoC 内部的一次性可编程资源：

OTP，One-Time Programmable。

最大的特点就是：

写进去以后不能简单回退。

Jetson 上电以后，BootROM 会读取 Fuse，从而确定设备应该采用什么安全策略。

课程中涉及的典型配置包括：

text 复制代码

PublicKeyHash
SecureBootKey
OemK1 / OemK2
BootSecurityInfo
SecurityMode
ArmJtagDisable

其中比较重要的：

PublicKeyHash

建立 Secure Boot 的根公钥信任。

SecureBootKey

对应 SBK。

SecurityMode

进入生产安全模式。

ArmJtagDisable

用于控制 JTAG 调试能力。

这里必须特别强调一点：

Fuse 不是普通配置文件。

尤其到了量产阶段，一旦真正完成不可逆配置，再想用"重新刷机"的思路恢复，往往已经不是一回事了。

所以 Secure Boot 最容易出大问题的地方，很多时候并不是算法，而是：

密钥管理、Fuse 配置和生产流程本身。

从密钥到真正启用 Secure Boot，要走哪些步骤？

把 PKC、SBK、Fuse 理清以后，整个 Jetson Secure Boot 的实施流程其实就比较自然了。

这套流程可以概括成：

准备密钥

↓

定义 Fuse

↓

烧录硬件信任根

↓

生成签名 / 加密镜像

↓

刷入设备

课程中将它进一步拆成 7 个步骤：第5节课-Jetson Secure Boot

生成 PKC 密钥对
准备 SBK
准备 K1 / K2
构建 EKB
编写 Fuse XML
烧录 Fuse
刷入安全镜像

这几个步骤里，我觉得最重要的不是把命令背下来，而是理解它的先后逻辑。

第一步：先准备自己的密钥体系

PKC 用于签名。

SBK 用于镜像机密性保护。

K1/K2 等密钥可以继续服务于 EKB、RPMB 等后续安全能力。

第二步：Fuse 固化信任根

告诉芯片：

从现在开始，你应该信任谁。

这是整个流程真正发生质变的一步。

第三步：以后刷进去的软件都必须遵守这个规则

固件需要按照对应密钥完成签名，必要时再加密。

最终 Jetson 不再是：

"能刷进去就能启动。"

而变成：

"只有被我的密钥体系认可的软件，才允许进入启动链。"

这才是 Secure Boot 真正建立起来的状态。

EKB 又是干什么的？

Secure Boot 课程里还会碰到 EKB。

这时候不要再把它和 PKC、SBK 混成一团。

EKB 可以用于封装设备后续需要使用的敏感信息，例如：

OTA Key、模型解密 Key，以及其他设备级密钥。

设备端再结合 OP-TEE 等可信执行环境进行安全使用。

所以可以看到，Secure Boot 并不是安全体系的终点。

它更像整个设备安全体系的第一块地基。

后面我们还会继续碰到：

OP-TEE

模型密钥保护

安全 OTA

Anti-Rollback

RootFS 完整性

运行时保护

这些东西都需要建立在一个前提上：

设备最开始启动起来的代码，本身是可信的。

一个非常容易犯的错误：Secure Boot ≠ 整个设备已经安全

这点我觉得必须单独说。

启用了 Secure Boot，不代表：

设备从此绝对安全。

Secure Boot 重点解决的是：

启动阶段的可信。

它证明设备启动的是可信的软件，但系统启动以后仍然存在：

应用漏洞
Root 权限问题
RootFS 保护
密钥泄漏
模型泄漏
网络攻击
OTA 安全
调试接口
运行时攻击

所以我更倾向于把嵌入式设备安全拆成几层：

text 复制代码

启动时安全
    ↓
运行时安全
    ↓
升级时安全
    ↓
数据 / 密钥安全

Secure Boot 是最下面的第一层。

但是这一层特别重要。

因为：

如果设备启动的第一段可变代码都不能相信，上层建立多少安全机制都会缺少一个可信起点。

做量产产品，我真正关心的不是"有没有 Secure Boot"

而是：

这套 Secure Boot 能不能长期管理。

开发阶段烧一块板成功，其实并不难。

真正困难的是量产以后：

PKC 私钥放在哪里？
SBK 谁能够接触？
工厂能不能拿到生产密钥？
Fuse 如何自动烧录？
烧错一台设备怎么办？
不同产品是否共用密钥？
OTA 怎么继续使用同一套信任体系？
密钥轮换怎么处理？
整个过程能不能审计？

到了这个阶段，Secure Boot 就已经不只是一个 Jetson 技术问题。

它会变成：

产品安全 + 密钥管理 + 生产流程 + OTA 架构

共同组成的问题。

这也是为什么我一直觉得：

Secure Boot 不是产品开发最后再"打开一个开关"，而应该从系统设计阶段就考虑进去。

最后把 PKC、SBK、Fuse 再串一次

如果第一次学习 Secure Boot，我觉得整篇文章最终记住下面三个东西就够了。

PKC

解决可信性和完整性。

回答：

这个镜像是不是我们认可的？有没有被改？

SBK

解决机密性。

回答：

别人拿到固件以后，能不能直接读取里面的内容？

Fuse

建立不可轻易改变的硬件信任根。

回答：

这颗芯片到底永久相信哪套安全配置？

最后形成：

text 复制代码

Fuse
建立 Root of Trust
        ↓
PKC
验证软件可信性
        ↓
SBK
保护固件机密性
        ↓
BootROM → MB1 → MB2 → UEFI → Kernel
        ↓
可信系统启动

这就是 Jetson Secure Boot 最值得理解的主线。

完整视频讲解

本文对应：

《Jetson Edge AI 实战》第05讲：Jetson Secure Boot

视频里会结合完整课程图，把：

为什么需要 Secure Boot → Boot Chain → PKC → SBK → Fuse → EKB → 安全镜像刷写

一步步串起来。

文章适合快速建立体系，视频更适合结合启动链真正把 PKC、SBK、Fuse 的关系看明白。

🎬 点击这里直接进入 B站观看完整视频

B站搜索：嵌入式孙老师

觉得内容有帮助，欢迎点赞、收藏。

需要本节课程对应的 PPT、代码以及详细学习资料，也可以联系本人获取。

做了很多年嵌入式之后，我越来越觉得：

设备安全不是产品做完以后再补的一项功能。

真正的安全，从 SoC 上电的第一刻就已经开始。

BootROM 为什么相信 MB1？

MB1 为什么允许 MB2 运行？

UEFI 为什么允许这个 Kernel 获得执行权？

沿着这些问题一直追下去，其实就是 Secure Boot。

而可信设备，也正是从这里开始。

👉 B站观看《Jetson Edge AI 实战05：Jetson Secure Boot》

All in AI，不如走向边缘🌞