没有 Secure Boot，会带来什么后果？——以 Jetson 为例的完整分析

原创于 2025-12-08 17:43:00 发布 · 618 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#java #数据库 #redis #YOLO #人工智能 #边缘计算 #开发语言

NVIDIA 专栏收录该内容

50 篇文章

订阅专栏

如何让小智AI成为你的第二大脑——“免费”送小智AI智能音箱征文活动 10w+人浏览 252人参与

AI助手已提取文章相关产品：

📺 B站视频讲解（Bilibili）：https://www.bilibili.com/video/BV1k1C9BYEAB/

📘 《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

没有 Secure Boot，会带来什么后果？——以 Jetson 为例的完整分析

在 Jetson 这类高性能 SoC 平台上，Secure Boot 常被视作“高阶选项”：没时间、怕复杂、担心烧坏板子，于是很多项目在量产前都没有真正启用它。然而，从安全和产品化的角度看，不启用 Secure Boot 并不是“少做一步功能”，而是在系统根部留下了一个结构性的安全缺口。

本文以 Jetson（尤其是 Orin 系列）为背景，从整体到局部、从攻击场景到工程实践，系统分析——在没有 Secure Boot 的情况下，会出现哪些具体风险和后果。文中所有讨论都基于公开文档与合理假设，不涉及也不鼓励任何非法、恶意用途。

在这里插入图片描述

一、先搞清楚：Secure Boot 到底保护了什么？

在分析“没有 Secure Boot 会有什么后果”之前，需要先弄清楚一个前提：Secure Boot 保护的是“启动链”（Boot Chain），而不是整个操作系统的所有文件。

在 Jetson Orin 这类 SoC 上，启动链可以简化为：

BootROM → MB1 → MB2 → UEFI → （OP-TEE）→ Kernel → RootFS

BootROM：固化在芯片内部，只读，无法更新，是整个信任链的起点（root of trust）。
MB1 / MB2 / UEFI / OP-TEE：统称为 Boot Chain，它们大多存放在载板上的 SPI NOR Flash 中。
Kernel / RootFS：存放在 eMMC / NVMe 等外部存储上，由 UEFI 或 bootloader 加载。

当 Secure Boot 启用 时，大致会发生以下事情：

BootROM 会使用 eFuse 中的公钥哈希，验证 MB1 的签名；
MB1 验证 MB2；MB2 验证 UEFI；UEFI 验证后续组件（包括 Kernel）；
整条链条中，任何一个环节未经授权修改，启动就会失败或转入安全模式。

而当 Secure Boot 没有启用 时：

BootROM 并不会检查 MB1 是否被篡改；
Boot Chain 的后续阶段也没有“必须通过签名验证才能继续”的强制约束；
任何人只要能写 SPI / eMMC，就可以放上自己的 bootloader 或 kernel，设备照样运行。

这才是问题的起点。

二、没有 Secure Boot：攻击者可以随意替换启动链

2.1 启动链是“系统世界观”的起点

操作系统内部再复杂的权限模型（root / 用户 / SELinux / 容器隔离等），本质上都建立在一个前提上：

启动系统的那段代码是可信的。

如果一开始执行的那段 bootloader 就是别人写的，那么：

/etc/passwd 是否有 root 密码已经不重要；
文件权限、进程隔离都可以被直接绕过；
任何“系统内的安全机制”都只是表面现象。

换句话说，没有 Secure Boot 的启动链，就像是在一栋大楼的地基中预留了一扇暗门——大楼里再怎么装防盗门，都挡不住有人从地基钻进来。

2.2 场景示例：线下获取设备后替换 bootloader

假设你做了一款基于 Jetson Orin 的 AI 摄像机，部署在工厂、医院或者商场里。某一天，攻击者获得了一台实物（可能是废弃设备，也可能是从渠道买来的）。如果没有 Secure Boot，他可以做什么？

一个典型的、完全在“合理假设”范围内的路径是：

将设备切换到 Recovery / RCM 模式；
使用公开的刷机工具，将原厂的 MB2 或 UEFI 替换成自己修改过的版本；
这个修改过的 bootloader 可以在启动时：
- 打开一个隐藏的 debug shell；
- 自动为某个账户添加无密码登录；
- 在用户空间加载一个持久驻留的后门进程；
设备从外观上看仍然“正常工作”，但已经完全受攻击者控制。

整个过程在技术上并不神秘：

Jetson 的 Boot Chain 镜像格式、分区信息、刷写工具都是公开的；
没有 Secure Boot 时，BootROM 不会检查镜像的签名；
只要能将自定义 bootloader 写入 SPI，下一次上电就会执行这段代码。

结果是什么？

你的设备变成了攻击者的“自用开发板”；
设备上存储的数据、传输的图像、运行的 AI 模型都可以被随意读取；
如果攻击者把这套修改过的系统批量部署，甚至可以搭建一个仿冒版产品线。

2.3 对比：启用 Secure Boot 之后

如果在同样的硬件上启用了 Secure Boot：

BootROM 会在执行 MB1 前先验证签名；
MB1 / MB2 / UEFI 都必须由你手上的私钥签名；
攻击者即便能将自定义 bootloader 写入 SPI，由于签名不匹配，设备会拒绝启动。

这并不意味着设备不可能被攻击，但至少可以排除“直接替换 Boot Chain”这条路径。对安全来说，减少一条路径就减少了一类风险。

三、没有 Secure Boot：AI 模型和算法资产很容易被克隆

对于 Jetson 设备而言，最核心的商业价值往往不是硬件，而是：

训练好的 AI 模型（YOLO、分割网络、检测网络等）；
各类 ISP / camera pipeline 的调优参数（诸如 rkaiq / 校准表）；
行业经验沉淀下来的业务规则和算法；
针对特定场景做的性能优化和延迟优化。

如果缺失 Secure Boot，这些资产在工程实践中会面临几类典型风险。

3.1 整盘镜像被复制，产品被“平移式克隆”

很多公司的量产流程大致是：

用 Yocto 或 SDK 生成生产镜像；
用刷机脚本或量产工具将镜像写入 eMMC；
出厂时设备处于“完全可用”的状态。

在没有 Secure Boot 的情况下，如果有人拿到一台成品，只需要：

利用通用工具读取整块 eMMC 或 NVMe 的内容；
再将这份镜像写入另一块相同硬件的板子；

就可以得到一台“功能几乎完全相同”的拷贝设备：

同样的系统版本；
同样的 AI 模型和校准参数；
同样的业务逻辑和 UI；
很可能连序列号、证书都没有区分（如果设计时没做这部分）。

对于攻击者来说，这几乎就是“免费获得一套产品级软件栈”。

对于原厂来说，后果包括但不限于：

市面上出现和你外观类似、功能基本一致、价格却更低的“兼容设备”；
客户无法分辨谁是真正的原厂；
一旦仿冒品出现质量问题，负面口碑很容易被算到你头上；
自己投入的大量算法和模型研发成本，实际上在帮助别人做产品。

3.2 精调的相机/ISP 参数被照搬

对摄像头类产品来说，调好一条 ISP pipeline 需要：

长期的现场测试；
针对不同光照场景的调优；
针对不同镜头/传感器组合的标定；
复杂的 noise reduction / tone mapping / gamma / LSC 等参数。

这些东西最终通常以：

配置文件；
固件二进制 blob；
调优脚本；
JSON / INI 形式的参数文件；

的形式落地到 rootfs 中。

如果没有 Secure Boot：

攻击者可以轻易启动一个修改过的系统，从文件系统中复制这些配置；
或者直接将整套 rootfs 移植到自己的产品中，稍加修改后使用；
对最终用户来说，他看到的是“某某厂商的摄像机效果很好”，并不会知道背后真正的算法来源。

3.3 启用 Secure Boot 能做什么？

Secure Boot 本身并不会加密 rootfs，也不会主动防止文件复制。但它提供了一个关键能力：

你可以基于可信的 Boot Chain，继续叠加如磁盘加密、dm-verity、密钥保护等更高层的安全措施。

例如：

可以将模型文件存放在加密分区，需要通过可信启动链中的服务解密后使用；
可以在 TEE（比如 OP-TEE）中管理密钥，防止简单复制文件就能使用；
可以通过设备唯一身份（如 eFuse、证书）与云端授权系统绑定。

如果启动链一开始就不可信，那么加密和授权机制很容易被“从根部绕过”（比如直接启动一个不会执行授权检查的自定义系统）。

四、没有 Secure Boot：OTA 与远程升级处于“裸奔状态”

现代产品很少一次性烧写好镜像后就永不更新：

Bug 修复；
新功能追加；
安全补丁；
算法更新和模型替换；
适配新的传感器或接口。

这些都可以通过 OTA 或远程升级实现。但如果系统没有 Secure Boot，OTA 的安全性就会大打折扣。

4.1 OTA 升级包可以被中间人篡改

假设你有一套 OTA 流程：

服务器生成新的 rootfs 或容器镜像；
设备定期拉取更新包；
下载完成后重启进入新系统。

在没有 Secure Boot 的情况下，攻击者可以：

替换设备的 bootloader，让它从攻击者指定的位置加载系统；
自己伪造一个“看起来合法”的更新包，但内部是植入后门的版本；
或者直接修改系统逻辑，使其在更新时绕过签名检查。

即使你在应用层对升级包做了签名：

只要攻击者能替换 bootloader 或 kernel，就能修改验证逻辑；
甚至可以跳过整个 OTA 机制，启动一个完全不同的 rootfs。

4.2 没有可信启动链，远程 attestation 失去意义

在很多安全架构中，会希望设备在连接云端时提供一种“自证清白”的能力：

告诉服务器：“我现在运行的是官方的、未被篡改的系统版本。”

如果没有 Secure Boot，这种自证是很难成立的：

设备可以伪装成“官方镜像”，但实际上已经被植入恶意代码；
服务器端看到的是“看起来没问题的版本号”，却无法确认底层系统是否真的没被改动；
整个远程管理体系的信任基础会动摇。

有了 Secure Boot 和可靠的 boot chain 之后，才能在此基础上谈：

远程 attestation（远程证明设备状态）；
设备身份绑定；
安全的 OTA 策略。

五、没有 Secure Boot：合规与责任边界难以界定

在医疗、工业控制、车载、金融等行业中，合规已经成为产品必须面对的一部分。

5.1 合规要求通常包含“固件完整性”

相关标准（例如某些医疗设备软件标准、信息安全标准）常见的要求包括：

设备在运行前应具备验证自身固件完整性的能力；
不能随意执行未授权代码；
一旦检测到固件被篡改，应进入安全状态或拒绝继续运行。

如果没有 Secure Boot：

你无法给出一个可靠的论证：启动时到底有没有验证 bootloader；
更难证明设备在“从上电到应用启动”的全过程中没有被注入其他代码。

在安全审计过程中，这样的系统往往会被认定为：

缺少可信根（root of trust）；
无法保证固件完整性；
需要额外补充安全措施（而这些措施一般都绕不开可信启动）。

5.2 一旦出现事故，责任难以说清

想象这样一个极端但并非不可能的场景：

某类重要设备（如医疗监护设备、工业控制设备）在现场被不当修改；
由于部署环境复杂，设备长期无人值守；
某天设备做出错误决策，造成了实际损失甚至安全事故。

此时如果没有 Secure Boot：

厂商很难证明“设备在出厂时是正常的，故障是因为部署现场被篡改”；
用户也很难判断“问题到底来自原厂设计缺陷还是现场篡改”；
责任边界变得模糊不清。

相反，如果有一套完善的 Secure Boot 和日志体系：

可证明设备启动时的镜像确实是官方签名版本；
如果设备运行的是被篡改版本，很可能早就启动失败或进入安全模式；
一旦发现异常，可通过 attestation 和日志追踪具体问题来源。

六、没有 Secure Boot：文件系统防护手段难以落地

前面提到，Secure Boot 不直接保护文件系统，但它是许多高层安全机制的前置条件。

6.1 dm-verity / 只读 rootfs 需要可信内核

很多系统会采用如下组合来保护文件系统：

使用 只读 rootfs（read-only rootfs）；
使用 dm-verity 或类似机制，确保 rootfs 上每个块的哈希都在预期范围内；
一旦发现根文件系统被修改，就拒绝挂载或进入“安全模式”。

但是，如果没有 Secure Boot：

攻击者可以用自定义 bootloader 加载一个不启用 dm-verity 的 kernel；
或者直接将整个内核替换为“什么验证都不做”的版本；
这样一来，再强的 rootfs 防护都形同虚设。

因此，在工程实践中，通常是这样一个顺序：

利用 Secure Boot 建立可信启动链；
在可信的 kernel 基础上启用 dm-verity / 只读 rootfs；
进一步为敏感数据或模型引入加密存储。

6.2 没有 Secure Boot 时的“虚假安全感”

如果在没启用 Secure Boot 的系统上，仅仅在 rootfs 层面加了一些保护措施（比如加密分区、访问控制），可能产生一种“虚假安全感”：

看起来已经有权限限制；
部分敏感文件也加密了；
OTA 流程也做了升级包签名。

但由于启动链本身不可信：

攻击者可以直接启动一个绕过这些机制的系统；
可以挂载底层分区，绕过应用层逻辑访问数据；
可以在较低层面控制系统行为。

这就像是在没有地基的地面上铺了很坚固的地板——地板再硬，一旦地面被掀起，一切都失去意义。

七、没有 Secure Boot：产品生命周期中的长期隐患

Secure Boot 的价值并不只体现在“防止一次攻击”上，更体现在整个产品生命周期中。

7.1 设备在野外长时间运行，风险累积

工业、交通、城市安防等场景中，设备往往：

部署周期长（3 年、5 年甚至更久）；
多数时间无人值守；
环境复杂（机房、机柜、室外箱体）。

没有 Secure Boot 的设备，在这么长的生命周期内：

可能在维修时被误刷非官方镜像；
可能在回收或转手过程中被人读取全部数据；
可能在某些节点被植入看不见的后门，直到多年后某次升级才被发现。

7.2 维护成本和故障排查难度增加

从维护角度看，没有 Secure Boot 也会增加排障复杂度：

现场一台设备启动异常时，你很难确认它运行的是“官方镜像”还是“被现场人员改动过的版本”；
调试时需要额外排除“是否有人动过 bootloader / kernel”；
当系统表现出怪异行为时，不容易快速定位是软件 bug 还是被篡改导致。

而有了 Secure Boot：

至少可以确定“能正常启动的设备，其 boot chain 一定是经过签名验证的官方版本”；
排查问题时，少了一个巨大不确定因素。

7.3 产品线管理与版本控制更加规范

在有 Secure Boot 的产品线中：

每一个可启动的镜像版本都必须经过签名；
私钥的管理会被纳入公司内部的安全流程（CI/CD、证书管理等）；
开发、测试、量产阶段的镜像边界会更加清晰。

长远来看，这会促进整个团队在版本管理、安全管理上的规范化，对企业而言是正向资产。

八、总结：没有 Secure Boot 的代价，往往是“系统可复制、行为不可控”

综合上面的分析，可以把“没有 Secure Boot 会有什么后果”总结为几条关键结论：

启动链可以随意被替换：
- 攻击者只要能访问 SPI / eMMC，就有机会启动自定义 bootloader 和 kernel；
- 操作系统内部的权限控制会被从根部绕过。
AI 模型和算法资产容易被克隆：
- 整盘镜像复制成本很低；
- 精调的 camera pipeline / ISP 参数可被直接照搬；
- 市场上可能出现功能几乎完全一致的山寨产品。
OTA 和远程管理缺乏可信基础：
- 升级包验证可以被跳过或篡改；
- 设备难以向服务器“证明自己是官方版本”。
合规与审计难以通过：
- 缺少可信根（root of trust）；
- 无法证明固件完整性；
- 一旦发生事故，责任边界模糊。
高层安全机制难以真正落地：
- dm-verity / 只读 rootfs / 加密存储都可能被绕过；
- 在不可信 boot chain 上叠加防护，只能提供有限增益。
产品整个生命周期都在承受隐性风险：
- 在野外运行多年，累积暴露时间长；
- 维护与排障成本增加；
- 版本和镜像的管理难以规范。