Jetson Secure Boot 全面实战：原理、价值、风险与落地步骤（以 AGX Orin 为例）

Jetson AGX Orin安全启动实战

最新推荐文章于 2025-11-25 18:01:44 发布

原创最新推荐文章于 2025-11-25 18:01:44 发布 · 1k 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #人工智能 #android #redis #架构

NVIDIA 专栏收录该内容

30 篇文章

订阅专栏

作者书籍推荐：
⚡ 内地版本：电子工业出版社已出版，并在大陆热销。Yocto项目实战教程:高效定制嵌入式Linux系统
⚡ 海外版本：繁体中文版支持全球华人购买，让更多开发者轻松掌握嵌入式系统核心技能。金石堂购买链接
🎥 更多学习视频请关注 B 站：嵌入式Jerry

Jetson Secure Boot 全面实战：原理、价值、风险与落地步骤（以 AGX Orin 为例）

适用对象：正在基于 NVIDIA Jetson（特别是 AGX Orin / Orin NX / Orin Nano）做量产交付、需要从“能跑”进阶到“可信可控”的团队。本文覆盖 原理 → 价值 → 风险 → 实施 → 验证 → 量产运维 的完整闭环，并给出可直接落地的脚本与配置示例。

在这里插入图片描述

1. 为什么需要 Secure Boot？

1.1 威胁模型（Threat Model）

恶意固件/内核：供应链或现场被替换为带后门的 Bootloader/Kernel。
未授权模块/驱动：通过 insmod 植入提权 Rootkit。
调试口滥用：利用 /dev/mem、MSR、kexec、kdump 越权访问。
OTA 篡改：更新包被中间人替换。

1.2 Secure Boot 解决什么？

从 BootROM 起的链式信任（Chain of Trust）：每一级只在上一层签名验证通过时才加载下一层镜像。
内核态完整性防护：只允许加载签名模块，开启 Lockdown 限制高危接口。
OTA 的可信根：结合镜像签名/仓库签名，保证“谁发的，没被改”。

1.3 有它的好处

遏制最关键的“执行面”风险（Boot/Kernel/Driver）。
合规模块（车规/工控/医疗）基本都需要可信启动与固件签名。
降低“人肉运维”成本：一套密钥与流程，贯穿开发、产测、交付与售后。

1.4 没它的风险

设备一旦被刷入恶意 Boot/Kernel，将无法通过系统层补救。
未签名模块可被随意加载，Root 权限 == 全设备失陷。
现场被“好心人”帮忙调试，反而引入后门与合规风险。

2. Jetson 的两条安全主线

Jetson（Orin 世代）同时存在 NVIDIA SoC 级 Secure Boot 和 UEFI Secure Boot（可选） 两条主线。建议理解并按需组合。

2.1 SoC 级 Secure Boot（PKC，强烈推荐）

根在硬件熔丝：将公钥哈希（PKC Hash）烧入 SoC eFUSE。
签名对象：早期引导组件（MB1/MB2/UEFI/恢复镜像等）以及 Kernel、DTB 等。
工具链：odmfuse（烧录公钥哈希） + tegrasign（签名镜像） + SDK Flash 工具。
价值：就算把 eMMC 全抹了，也无法让 SoC 运行未签名的引导链。

2.2 UEFI Secure Boot（可选增强）

根在 UEFI 的 DB/KEK/PK：可用 MOK 等机制将你自己的证书加入允许列表。
联动 Linux Lockdown：在 UEFI Secure Boot 模式中，Linux 会自动进入 Lockdown（密级可选）。
价值：补齐用户态/内核态的策略联动（如模块签名链，kexec 验签等）。

实务经验：量产首选 SoC 级 Secure Boot（PKC） 兜底可信启动；如需更精细到 OS 层策略，再叠加 UEFI Secure Boot 与内核 Lockdown/IMA。

3. 内核侧需要开启的关键能力

Secure Boot 不等于“仅签了 Bootloader”。要想把攻击面真正收紧，内核侧至少要具备以下能力：

模块签名：

CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA256=y
CONFIG_SYSTEM_TRUSTED_KEYRING=y
# 将构建时的内核公钥编进镜像
CONFIG_SYSTEM_TRUSTED_KEYS="certs/signing_key.pem"

二次内核加载验签（kexec）：
```
CONFIG_KEXEC_VERIFY_SIG=y
```

Lockdown（内核自我保护）：

CONFIG_SECURITY_LOCKDOWN_LSM=y
# 量产建议：
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y
# 启动参数也可控制：lockdown=integrity | confidentiality

（可选）完整性度量/保护：

CONFIG_INTEGRITY=y
CONFIG_IMA=y
CONFIG_EVM=y

提示：开发期可以先不强制 Lockdown，待驱动/应用稳定后在量产配置中开启并固定。

4. 从 0 到 1：Jetson AGX Orin Secure Boot 实施分步

以下流程在安全实验机上演练，请勿直接对量产硬件熔丝。一旦烧写 eFUSE，将不可逆！

4.1 资产与环境

一台 AGX Orin 开发套件 + Host（Ubuntu）
L4T/JetPack 对应的 BSP/Flash 工具
私钥管理环境（离线机/内网 HSM 更佳）

4.2 生成密钥（PKC）

# 生成 3072 或 4096 位 RSA 私钥（建议 4096）
openssl genrsa -out pkc_privkey.pem 4096
# 导出公钥
openssl rsa -in pkc_privkey.pem -pubout -out pkc_pubkey.pem
# 计算公钥哈希（供烧写 eFUSE）
openssl dgst -sha256 pkc_pubkey.pem > pkc_pubkey.sha256

产线做法：私钥长期离线保管，Flash 机只持有公钥哈希和签名后的镜像。

4.3 预演：不烧熔丝，先“签 + 启动”

使用 tegrasign 对关键镜像签名（Bootloader/Kernel/DTB/Recovery 等）。
使用 SDK 提供的 Flash 命令，将签名镜像写入设备。
反复重启验证：在未烧 eFUSE 的情况下，SoC 仍可跑“未签名”的镜像，这一步只是检查签名链是否正确工作。

目的：确保签名/打包/Flash 的自动化流程可靠，再考虑熔丝不可逆步骤。

4.4 烧录 eFUSE（绑定信任根）

用 odmfuse 工具将 公钥哈希 写入 SoC。
烧写后，SoC 将只接受由对应私钥签发的引导链。
立刻验证：改用“未签名”或“他钥签名”的镜像应当无法启动。

强烈建议：双人复核 + 变更单，并在设备可追溯系统记录每一次熔丝操作。

4.5 内核与模块签名集成（Yocto/L4T）

在内核配方中开启上节的 CONFIG_*。
构建阶段使用固定的 certs/signing_key.pem 生成体内公钥；模块在 do_install 末尾统一签名。
建议把“模块签名 + 验证”做成 CI 检查，防止遗漏。

示例：签名模块小脚本（开发/回归用）

#!/usr/bin/env bash
# sign_module.sh <private_key.pem> <module.ko>
set -e
KEY=$1
KO=$2
[[ -f $KEY && -f $KO ]] || { echo "Usage: $0 key.pem mod.ko"; exit 1; }
/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 "$KEY" \
  $(dirname "$KEY")/signing_key.x509 "$KO"
echo "Signed: $KO"

5. 验证与日常检查

5.1 启动/引导链

断电上电，自检引导日志中应出现“签名验证通过”的痕迹。
使用错误签名镜像应无法启动（黑屏或进入恢复）。

5.2 内核态

# Lockdown 状态
cat /sys/kernel/security/lockdown
# 预期：integrity 或 confidentiality

# 模块签名检查（示例）
dmesg | grep -i 'module verification'
# 插入未签名模块，预期被拒绝
insmod foo.ko  # 应失败

5.3 OTA 与回滚

OTA 包必须由镜像签名（与 Secure Boot 链一致）与包级签名（更新系统/仓库签名）双保险。
失败回滚策略：Bootloader 配置 A/B 分区与健康检查，确保下次启动切换到可用镜像。

6. 量产工程建议

6.1 密钥与分级

Root Key（离线保管）：用来签发“发布用子钥”或熔丝公钥；仅极少数人掌握。
Release Key（构建机可用）：用于日常构建签名；泄露时可由 Root Key 轮换。
调试 Key（研发/FAE）：
- 允许仅在“研发机”熔丝调试公钥；量产机一律不用。
- 可设置更高的日志/解锁，但严禁流入外部/客户。

6.2 产测/返修

产测镜像也必须签名；若需额外工具，使用独立调试 Key 并严格回收。
返修流程需提供“可换板/重写存储但不可绕过熔丝”的 SOP。

6.3 开发与量产差异

项	开发	量产
Lockdown	可关闭或设为 `integrity`	建议 `confidentiality` 并固定
模块签名	可选	强制，CI 校验
UEFI SB	可选	与策略联动更佳
调试接口	适度开启	全关闭（JTAG/UART 受控）

7. 常见问题（FAQ）

Q1：只签了 Kernel/DTB，不烧 eFUSE，可以吗？
A：开发期可以，但不能称为 Secure Boot。一旦攻击者刷入未签名 Bootloader，后续验证形同虚设。

Q2：Lockdown 开了，某些调试工具不能用了怎么办？
A：这是预期行为。请在“研发专用硬件”上使用调试 Key；量产机不要尝试规避。

Q3：模块很多，签名很麻烦？
A：把“签名 + 校验”并入 Yocto/CI，强制构建失败即可。并尽量减少 out-of-tree 模块数量。

Q4：UEFI Secure Boot 一定要吗？
A：不一定。SoC 级 PKC 已覆盖“能起机”的下限；UEFI SB 适合做 OS 层策略联动与生态兼容。

Q5：OTA 怎么与 Secure Boot 协同？
A：更新的目标镜像必须与 Secure Boot 的密钥链匹配；更新包本身也需签名。失败回滚靠 A/B 与健康检查。

8. 最小落地清单（可抄作业）

建立密钥体系：Root/Release/Debug 分级，离线保管 Root Key。
签名链打通：tegrasign 全镜像签名 → SDK Flash 验证启动。
熔丝演练：在样机上烧 eFUSE（公钥哈希），验证错误签名镜像无法启动。
内核策略：开启 CONFIG_MODULE_SIG*、CONFIG_SECURITY_LOCKDOWN_LSM、CONFIG_KEXEC_VERIFY_SIG。
CI 集成：构建阶段自动签名模块；对未签名模块一票否决。
运维闭环：OTA 包签名、A/B 回滚、返修 SOP、密钥轮换预案。

9. 参考脚手架

9.1 Yocto 片段（内核配置 + 模块签名）

# linux-jetson-secureboot.cfg（随配方追加）
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA256=y
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS="certs/signing_key.pem"
CONFIG_KEXEC_VERIFY_SIG=y
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y

# recipe.bbappend（简化示意）
do_install:append() {
    # 对 ${D}/lib/modules 下的 *.ko 逐个签名
    for m in $(find ${D}/lib/modules -name '*.ko'); do
        ${KERNEL_SRC}/scripts/sign-file sha256 \
          ${THISDIR}/files/keys/signing_key.pem \
          ${THISDIR}/files/keys/signing_key.x509 \
          $m || bbfatal "Sign failed: $m"
    done
}

9.2 开机自检脚本（现场巡检用）

#!/usr/bin/env bash
set -e
err() { echo "[FAIL] $1"; exit 1; }
ok() { echo "[ OK ] $1"; }

# 1) Lockdown
LD=$(cat /sys/kernel/security/lockdown 2>/dev/null || true)
[[ "$LD" == *"integrity"* || "$LD" == *"confidentiality"* ]] && \
  ok "Lockdown: $LD" || err "Lockdown disabled"

# 2) 模块验签日志
if dmesg | grep -qi "module verification"; then
  ok "Module verification present"
else
  err "No module verification message"
fi

# 3) 关键模块抽检
for k in bcmdhd nvgpu; do
  modinfo $k >/dev/null 2>&1 && ok "Module present: $k" || err "Missing: $k"
done

# 4) kexec 验签支持
zcat /proc/config.gz 2>/dev/null | grep -q CONFIG_KEXEC_VERIFY_SIG=y && \
  ok "Kexec signature verify: ON" || err "Kexec verify: OFF"

echo "All checks passed."