Jetson eFuse 量产烧录实战：Secure Boot 密钥配置与避坑指南

1. 为什么要在量产阶段动 eFuse 这根“保险丝”

很多做 Jetson 边缘设备的团队，在研发阶段用 SDK Manager 刷个机、跑通 demo 就以为万事大吉了，直到产线小批量试产时才被现实教育：设备到了客户手里，固件被人整个读出来、克隆板子满天飞，或者因为安全启动没开，攻击者直接替换了 rootfs 里的关键二进制。这时候才回头补安全，成本已经翻了好几倍。

Jetson 平台上的eFuse就是解决这类问题的硬件级手段。它本质上是一组一次性可编程（OTP）的存储位，烧进去就改不回来，所以业界管它叫“电子保险丝”。在 Jetson 上，eFuse 承担了几件关键的事：写入设备唯一的密钥材料、开启Secure Boot（安全启动）、配置SecurityMode、以及绑定FSKP（Fuse Secure Key Programming，熔丝安全密钥编程）相关的密钥槽。一旦烧录完成，芯片只会用你烧进去的公钥去校验引导链，任何未经签名的固件都别想启动。

但“一次性”这三个字意味着风险极高。我见过不止一个团队，在没搞清楚 PKC（Public Key Cryptography）和 SBK（Secure Boot Key）区别的情况下就贸然烧录，结果板子直接变砖，只能返厂换模组。所以这篇内容不是教你“点一下按钮”，而是把量产预置安全这件事拆开讲透：eFuse 到底烧了什么、为什么这么烧、烧之前必须准备什么、烧的过程中哪些参数会要命、烧完之后怎么验证。

适合读这篇的人有三类：一是正在把 Jetson 产品从样机推向量产的嵌入式工程师；二是负责产线预置流程、需要写烧录 SOP 的测试工程师；三是做边缘 AI 设备、对固件防克隆有实际需求的技术负责人。如果你只是想在开发板上跑个 YOLOv5 或者部署个 Qwen，那这篇内容对你来说偏重了，可以先收藏，等产品要量产时再翻出来。

需要先明确一个前提：不同 Jetson 模组（Nano、Orin NX、Orin Nano、AGX Orin）的 eFuse 布局和烧录工具链有差异，但核心逻辑是一致的。下面我以 Orin 系列为主线索，穿插 Nano 的差异点，把整套流程讲清楚。

2. eFuse 里到底存了什么：PKC、SBK 与 SecurityMode 的分工

2.1 PKC 与 SBK：一个管“验签”，一个管“解密”

很多人第一次接触 Jetson 安全烧录时，会被 PKC、SBK、FSKP 这几个缩写绕晕。我用一个生活化的类比帮你理清：把设备启动想象成进一栋大楼。PKC相当于大楼门口保安手里的“授权名单”，它是一对非对称密钥里的公钥部分，烧进 eFuse 后，芯片用它来验证每一级固件的签名。你签名用的私钥留在自己的服务器上，绝不外泄。保安只认名单上的签名，别人伪造的签名一律拦下。

SBK则是另一回事，它是对称密钥，作用是“加密”。在 Secure Boot 流程里，引导链上的固件可以被 SBK 加密存储，芯片启动时用 eFuse 里的同一把 SBK 解密。这样即使有人把 Flash 里的固件 dump 出来，拿到的也是密文。PKC 管的是“是不是你签的”，SBK 管的是“内容看不看得懂”，两者职责完全不同。

这里有个常见的误区：有人以为烧了 PKC 就万事大吉，结果固件还是明文躺在存储里，被人直接读走逆向。所以如果你的威胁模型里包含“防固件提取”，PKC 和 SBK 要一起上；如果只是防“未授权固件启动”，PKC 单独烧也能满足。

2.2 SecurityMode：决定芯片“认不认”安全策略的总开关

SecurityMode是 eFuse 里的一组配置位，它决定了芯片启动时是否强制走安全校验路径。你可以把它理解成大楼的“门禁模式”：关闭时，谁都能进；开启后，没有授权名单（PKC）的人一律进不来。

在 Jetson 上，SecurityMode 的烧录通常和 PKC 绑定在一起。一旦开启，芯片就只接受用对应私钥签名的固件。这里要特别注意：SecurityMode 一旦烧录不可逆。我见过有团队在调试阶段为了图省事，先把 SecurityMode 烧了，结果后面想换密钥、想改启动配置，发现完全动不了，只能换模组。所以我的建议是：调试阶段绝对不要碰 eFuse，所有安全相关的烧录都放到量产预置环节，且必须经过至少一轮完整的 dry-run 验证。

2.3 FSKP：密钥槽的“分配器”

FSKP在 Jetson 安全体系里负责密钥槽的编程管理。eFuse 空间有限，不同的密钥材料（PKC、SBK、以及可能的其他密钥）要放到指定的槽位里。FSKP 相关的配置决定了这些密钥怎么写入、写到哪个位置。在 Orin 系列上，NVIDIA 提供了fskp相关的工具和配置模板，用来生成密钥编程的 blob。

实际操作用，你不需要手动去算每个 bit 的位置，工具链会帮你处理。但你必须理解：FSKP 配置一旦和实际密钥不匹配，烧录后芯片就找不到正确的密钥，启动直接失败。所以密钥生成、FSKP 配置、烧录这三个环节必须用同一套参数，中间任何一步换了密钥文件，整批都要重来。

提示：研发调试阶段请使用未烧录 eFuse 的模组，所有安全烧录操作只在量产工装和量产模组上进行。一旦烧录，模组无法恢复为“空白”状态。

3. 烧录前的准备工作：密钥、工具链与工装环境

3.1 密钥生成：别在开发机上随手 openssl 一下就完事

密钥是整个安全体系的根，生成环节的规范性直接决定后续能不能量产。Jetson 官方推荐用openssl生成 RSA 密钥对，但有几个细节必须注意。

第一，密钥长度。PKC 通常用 RSA-2048 或 RSA-3072，SBK 是 128 位对称密钥。别为了“更安全”上 RSA-4096，部分 Jetson 模组的 BootROM 对密钥长度有硬性限制，烧进去不认，板子直接起不来。

第二，密钥的存储。私钥绝对不能放在产线工装机器上，更不能进 Git 仓库。我的做法是：私钥生成在一台离线的、有访问审计的签名服务器上，产线只拿到公钥和已经签好名的固件。SBK 因为是对称密钥，产线烧录时需要用到，所以要放在受控的密钥管理系统里，通过安全通道下发到工装，用完即焚。

第三，密钥的备份。eFuse 烧录不可逆，但你的私钥如果丢了，后续就没法给新固件签名，等于整条产品线的固件都无法升级。所以私钥必须有离线冷备份，且备份介质的访问要有双人复核。

生成 PKC 的典型命令如下：

# 生成 RSA 2048 私钥 openssl genrsa -out pkc_private.pem 2048 # 导出公钥 openssl rsa -in pkc_private.pem -pubout -out pkc_public.pem # 查看公钥信息，确认长度 openssl rsa -in pkc_private.pem -text -noout

SBK 的生成可以用openssl rand：

# 生成 16 字节（128 位）SBK openssl rand -hex 16 > sbk.key

生成后务必核对字节数，SBK 必须是 16 字节，多一个少一个都会导致烧录失败。

3.2 工具链版本：jflash、SDK Manager 与 fskp 工具的配合

Jetson 的安全烧录工具链这几年变化不小。早期 Nano 时代主要靠flash.sh加一堆参数，Orin 时代 NVIDIA 推了更规范的流程，涉及fskp工具、odmfuse配置等。热词里出现的jflash烧录程序、jestonsdkmanager烧录纯净系统其实反映了大家在工具选择上的混乱。

我的建议是：安全烧录不要用 SDK Manager 的图形界面。SDK Manager 适合刷纯净系统、做研发调试，但它对 eFuse 烧录的支持是封装过的，出错了你根本不知道哪一步挂了。量产预置要用命令行工具链，把每一步的日志都留下来。

Orin 系列上，核心工具是odmfuse.sh（或对应的 Python 工具）配合fskp配置。你需要准备：

• BSP 包：对应 JetPack 版本的 Linux_for_Tegra 目录
• fskp 配置模板：NVIDIA 在 BSP 里提供了fskp相关的 xml 模板
• 签名后的固件：用私钥签过名的 bootloader、kernel、rootfs 等
• 工装环境：支持 USB 恢复模式的载板，以及稳定的供电

这里有个容易忽略的点：BSP 版本必须和模组的 BootROM 版本匹配。我遇到过用 JetPack 5.x 的 BSP 去烧 JetPack 6.x 模组，fuse 配置对不上，烧录工具直接报错。所以量产前一定要确认模组出厂时的固件版本，拉对应的 BSP。

3.3 工装与供电：别让一次掉电毁掉一批模组

eFuse 烧录过程中如果掉电，后果可能是灾难性的：部分 fuse 位烧进去了，部分没烧，芯片处于一个“半安全”状态，既不能正常启动，也没法重新烧录。所以工装环境必须满足几个条件。

供电要稳。Jetson Orin 系列在恢复模式下的电流波动不小，工装电源要能提供足够余量，最好带 UPS 或者至少是大容量电容缓冲。USB 线要用带屏蔽的优质线，劣质线在烧录大固件时容易断连。

工装要有防呆。产线操作员不应该有机会把模组插反、把恢复模式按键按错。我的做法是做一个专用的烧录夹具，模组放进去就自动接通恢复模式引脚，操作员只需要放料、按开始、取料三个动作。

还要有烧录记录。每一片模组的序列号、烧录时间、使用的密钥版本、烧录结果都要记录到数据库。eFuse 烧录不可逆，出了问题要能追溯到是哪一批密钥、哪一个工装、哪一个操作员。

4. 烧录流程拆解：从恢复模式到 fuse 写入的完整链路

4.1 进入恢复模式与设备识别

Jetson 模组进入恢复模式（Recovery Mode）是烧录的前提。不同载板进入方式不同，常见的是按住 Recovery 按键再上电，或者短接特定引脚。进入后，通过 USB 连接到工装主机，用lsusb应该能看到 NVIDIA 的设备：

lsusb | grep -i nvidia # 正常输出类似：Bus 001 Device 005: ID 0955:7023 NVIDIA Corp. APX

如果看不到设备，先排查 USB 线、驱动、以及模组是否真的进了恢复模式。Orin 系列有时候需要先断电、按住 Recovery、再上电，顺序错了就进不去。

设备识别后，用 BSP 里的flash.sh或者odmfuse工具做一次“探测”，确认工具链能正常和模组通信：

cd Linux_for_Tegra sudo ./flash.sh --no-flash --no-systemimg jetson-orin-nx-devkit mmcblk0p1

这一步不实际烧录，只是生成配置和检查通信。如果这一步就报错，后面的 fuse 烧录想都别想。

4.2 生成 fuse 配置：odmfuse 与 fskp 的配合

fuse 配置的核心是告诉工具：要烧哪些位、烧什么值。Orin 系列上，这个配置通常通过一个 XML 文件描述，里面包含 PKC 公钥的哈希、SBK 的哈希、SecurityMode 的配置等。

NVIDIA 在 BSP 里提供了模板，路径一般在Linux_for_Tegra/bootloader/下，文件名类似fuse_config.xml。你需要根据实际密钥修改模板里的字段。关键字段包括：

• PkcHash：PKC 公钥的 SHA-256 哈希
• SbkHash：SBK 的哈希
• SecurityMode：通常设为1表示开启
• OdmId：可选，用于标识产品线

生成 fuse blob 的命令大致如下：

sudo ./odmfuse.sh -j -i 0x23 -c PKC -p pkc_public.pem -s sbk.key jetson-orin-nx-devkit

这里的-c PKC表示烧录 PKC 相关 fuse，-p指定公钥，-s指定 SBK。实际参数要根据你的模组型号和 BSP 版本调整，不同版本的odmfuse.sh参数名可能有差异，务必用--help确认。

生成过程中，工具会输出一个 fuse blob 文件，这个文件就是最终要写入 eFuse 的数据。在真正烧录前，一定要用--no-flash或者 dry-run 模式跑一遍，确认生成的 blob 内容符合预期。

4.3 实际烧录：一次不可逆的写入

确认 fuse blob 无误后，执行实际烧录：

sudo ./odmfuse.sh -j -i 0x23 -c PKC -p pkc_public.pem -s sbk.key --flash jetson-orin-nx-devkit

烧录过程中，工具会先进入恢复模式，然后逐位写入 eFuse。这个过程通常几十秒到几分钟，取决于 fuse 数量和固件大小。烧录期间绝对不能断电、不能拔 USB、不能中断进程。

烧录完成后，工具会输出成功信息。此时模组会自动重启，如果一切正常，它会用新的安全策略启动。如果启动失败，说明 fuse 配置有问题，这时候模组可能已经变砖，只能返厂。

我强烈建议：第一批量产模组先烧 1-2 片做验证，确认能正常启动、能正常刷入签名固件、能正常跑业务程序，再批量烧。不要一上来就烧一整批，万一配置错了，损失惨重。

4.4 烧录后的验证：确认安全策略真正生效

烧录完成不代表结束，必须验证安全策略真的生效了。验证方法有几个层次。

第一，确认模组能正常启动。烧录后模组应该能进入系统，如果卡在 bootloader 阶段，说明 PKC 或 SecurityMode 配置有问题。

第二，尝试刷入未签名固件。用flash.sh刷一个没有签名的固件，如果安全策略生效，刷入应该失败，模组拒绝启动。这一步是验证“防未授权固件”是否真的起作用。

第三，检查 eFuse 状态。Jetson 提供了一些工具可以读取 eFuse 的烧录状态（注意：只能读状态，不能读密钥内容）。在系统里可以通过tegra-fuse相关命令查看：

# 查看 fuse 状态（具体命令随 BSP 版本变化） sudo cat /sys/devices/platform/tegra-fuse/ecid

ECID 是芯片唯一标识，可以用来确认模组身份。密钥内容本身是读不出来的，这是 eFuse 的设计初衷。

5. 踩过的坑：那些让模组变砖的瞬间

5.1 密钥文件换了但 fuse 配置没更新

这是最典型的事故。团队在调试阶段生成了一套密钥，后来觉得不安全，重新生成了一套，但 fuse 配置 XML 里用的还是旧公钥的哈希。烧录后芯片用旧哈希去校验新固件，当然校验失败，模组直接起不来。

根因在于：fuse 配置和密钥是绑定的，换密钥必须重新生成 fuse blob。我的做法是给密钥和 fuse 配置打上版本号，每次换密钥都走一次完整的 dry-run，确认生成的 blob 哈希和预期一致。

5.2 SBK 长度不对导致烧录中断

SBK 必须是 16 字节。有次同事用openssl rand -hex 16生成，但复制的时候多带了一个换行符，实际写入的是 17 字节。烧录工具在写入 SBK 槽位时报错，但此时 PKC 已经烧进去了，模组处于半烧录状态，既不能用旧固件启动，也不能重新烧录。

这个坑的教训是：所有密钥文件在烧录前都要用脚本校验长度和格式。我后来写了一个检查脚本，在烧录前自动核对 PKC 长度、SBK 长度、文件是否存在、哈希是否匹配，任何一项不过就拒绝开始烧录。

5.3 工装 USB 断连导致 fuse 写入不完整

产线工装用的 USB 线质量参差不齐，有次烧录到一半，USB 突然断连，工具报错退出。检查发现部分 fuse 位已经写入，但 SecurityMode 没烧完，模组处于一个尴尬状态：PKC 有了，但安全启动没开，芯片行为不确定。

这种问题的预防手段是：工装必须用带屏蔽和磁环的优质 USB 线，且烧录过程中工装主机不能跑其他高负载任务。另外，烧录脚本要加超时和重试逻辑，但重试仅限于“还没开始写 fuse”的阶段，一旦开始写 fuse，任何中断都只能报废。

5.4 不同模组型号混用同一套 fuse 配置

Orin NX 和 Orin Nano 的 eFuse 布局不完全一样，有团队为了省事，用同一套 fuse 配置去烧两种模组，结果 Nano 烧完起不来。根因是 fuse 槽位偏移不同，PKC 写到了错误的位置。

正确做法是：每种模组型号维护独立的 fuse 配置和烧录脚本，工装上要有型号识别机制，放错模组直接报警。

6. 量产预置的工程化建议：把一次性操作变成可控流程

6.1 密钥生命周期管理：从生成到销毁的闭环

eFuse 烧录只是密钥生命周期里的一个环节。完整的闭环包括：密钥生成、密钥分发、密钥使用、密钥轮换、密钥销毁。Jetson 的 eFuse 不支持密钥轮换（烧进去就固定了），所以轮换只能通过“换新模组”实现，这意味着密钥的初始生成必须足够慎重。

我的建议是：产品线规划时就确定密钥策略，是“一条产品线一套密钥”还是“一个批次一套密钥”。前者管理简单，但一旦泄露影响面大；后者更安全，但产线要管理多套密钥。对于大多数中小团队，一条产品线一套密钥加严格的离线保管，是性价比最高的方案。

6.2 产线 SOP：让操作员不会犯错

产线操作员不是安全专家，SOP 要简单到“放料、按键、取料”三步。所有复杂的配置、密钥选择、参数校验都在工装脚本里自动完成。工装界面只显示“开始”“成功”“失败”三个状态，失败时给出明确的错误码，由工程师处理。

SOP 里还要包含异常处理流程：烧录失败怎么办、模组变砖怎么标识、怎么隔离不良品。这些流程要贴在工位上，操作员能随时看到。

6.3 追溯与审计：每一片模组都要有“身份证”

每片烧录过的模组都要记录：模组序列号、ECID、烧录时间、密钥版本、fuse 配置版本、工装编号、操作员编号、烧录结果。这些数据存到数据库，支持按批次、按时间、按密钥版本查询。

追溯的价值在出问题时体现。比如某批模组在客户端出现启动异常，你可以快速定位到是哪个密钥版本、哪个工装、哪个时间段烧录的，缩小排查范围。没有追溯，你只能全批次召回。

6.4 小批量验证与灰度：别拿整批货赌一次配置

新配置上线时，先烧 5-10 片做灰度验证。验证内容包括：正常启动、签名固件刷入、未签名固件拒绝、业务程序运行、长时间稳定性。全部通过后，再逐步放大批量。

灰度期间要保留详细的日志和测试记录。如果灰度发现问题，立即停止，分析根因，修正配置后重新灰度。这个过程看起来慢，但比整批报废快得多。

7. 烧录之后：安全启动链的日常维护

eFuse 烧完、安全启动开启，不代表可以高枕无忧。后续的固件升级、OTA、产线返修都会和安全策略打交道。

固件升级时，新固件必须用对应的私钥签名，否则模组拒绝启动。所以签名服务器要一直可用，私钥要一直安全保管。OTA 流程里要加入签名校验环节，确保下发的固件是签过名的。

产线返修时，如果模组已经烧录 eFuse，返修后重新刷固件也必须用签名固件。返修工装要能识别模组的安全状态，避免用未签名固件去刷已烧录模组导致启动失败。

还有一点容易被忽略：开发团队要保留至少一台未烧录 eFuse 的模组，用于日常调试和紧急排查。已烧录模组不能随便刷未签名固件，调试起来束手束脚。这台“调试专用模组”要明确标识，避免误烧。

我个人在实际操作中的体会是，Jetson eFuse 烧录这件事，技术难度不算高，难的是流程规范和风险控制。工具链的命令行参数查文档就能会，但“什么时候烧、烧之前检查什么、烧之后怎么验证、出问题怎么追溯”这些工程化问题，才是决定量产成败的关键。把密钥管理、工装防呆、灰度验证、追溯审计这几件事做扎实，eFuse 烧录就从“高危操作”变成了“标准工序”。