1. 项目缘起为什么要在量产前动 eFuse第一次接触 Jetson 的 eFuse 是在一条小批量试产线上。当时整机已经组装完毕系统也烧录好了结果客户那边做安全审计要求设备必须支持安全启动防止固件被替换。我们当时的第一反应是“重新烧一版带签名的固件不就行了”但真正动手才发现Jetson 的安全启动根信任是焊在芯片里的不是软件层面能补的。这个“焊在芯片里”的东西就是 eFuse。eFuse 全称是 electronic fuse中文一般叫电子熔丝。它本质上是芯片内部一组一次性可编程的存储单元每一位出厂时都是未熔断状态你通过特定的烧录流程把它“烧断”这一位就永久变成另一个值而且不可逆。你可以把它理解成芯片出厂时自带的一张白纸你可以在上面写字但写上去就擦不掉。Jetson 系列Nano、TX2、Xavier、Orin 家族都用 eFuse 来存放安全启动相关的密钥哈希、安全模式标志、FSKPFuse Secure Key Programming相关配置等。这件事为什么值得单独写一篇实战总结因为 eFuse 烧录和普通固件烧录完全是两码事。普通固件烧错了重新刷一遍就行eFuse 烧错了这颗芯片基本就废了或者至少安全启动功能再也用不了。我在实际项目里见过有人把 SecurityMode 位烧反了导致整批板子无法进入安全启动最后只能换芯片。所以这篇内容适合两类人看一类是正在做 Jetson 产品安全启动方案、准备上量产的嵌入式工程师另一类是已经拿到 Jetson 板子、想搞清楚 eFuse 到底怎么烧、有哪些坑的开发者。下面我会从整体设计思路讲到具体操作再到踩过的坑尽量把每一步背后的原因说清楚。2. 整体方案设计先想清楚再动手2.1 安全启动的信任链到底长什么样在动手烧 eFuse 之前必须先把 Jetson 的安全启动信任链搞清楚。否则你只是机械地执行命令出了问题根本不知道是哪一环断了。Jetson 的安全启动信任链大致是这样的芯片上电后BootROM 首先运行它是一段固化在芯片里的代码不可修改。BootROM 会去读取 eFuse 里的公钥哈希Public Key Hash简称 PKC hash然后用这个哈希去验证 Bootloader 的公钥是否合法。如果公钥验证通过再用公钥验证 Bootloader 的签名。Bootloader 验证通过后后续的加载流程才继续。也就是说eFuse 里存的不是公钥本身而是公钥的哈希。这样做的好处是节省 eFuse 空间同时哈希不可逆即使 eFuse 内容被读出也无法反推公钥。这里有一个关键点PKC hash 是烧录到 eFuse 里的而对应的私钥必须由你自己保管好。私钥丢了后续就没法签名新的固件私钥泄露了安全启动就形同虚设。我在项目里一般建议客户把私钥放在离线机器上签名操作也在离线环境完成不要图省事放在 CI 流水线里。2.2 为什么选 FSKP 而不是直接烧 PKCJetson 的 eFuse 烧录方式有两种常见路径一种是直接烧 PKC hash 和 SecurityMode 位另一种是走 FSKP 流程。FSKP 是 Fuse Secure Key Programming 的缩写它本质上是一种更安全的密钥烧录机制。直接烧 PKC 的方式比较直接但问题在于烧录过程中密钥材料会以某种形式出现在烧录工具和日志里如果产线环境不够干净存在泄露风险。FSKP 的设计思路是先用一个临时的对称密钥对要烧录的密钥材料进行加密然后通过特定的烧录流程把加密后的材料写进 eFuse芯片内部再解密并熔断。这样即使烧录过程中被截获攻击者也拿不到真正的密钥材料。从实操角度看FSKP 流程比直接烧录多几步但安全性提升明显。对于量产项目我一般推荐走 FSKP。当然如果你的项目对安全要求没那么高或者只是做功能验证直接烧 PKC 也能跑通。但既然都动 eFuse 了多花点时间走 FSKP 是值得的。2.3 烧录前的准备工作清单在真正执行烧录之前有几件事必须提前准备好缺一不可确认芯片型号和对应的 eFuse 布局Jetson Nano、TX2、Xavier NX、Orin Nano、Orin NX、AGX Orin 的 eFuse 地址和位数不完全一样。比如 Orin 系列的 eFuse 空间比 Nano 大很多支持的密钥位数也不同。一定要查对应型号的 Technical Reference Manual。生成密钥对通常使用 RSA 或 ECDSA 密钥。Jetson 安全启动支持 RSA-2048、RSA-3072、ECDSA P-256 等。密钥长度影响安全强度和签名速度量产项目建议至少 RSA-3072。准备烧录环境需要一台 Linux 主机Ubuntu 18.04 或 20.04 比较稳安装 NVIDIA 的 JetPack 和相应的烧录工具。注意eFuse 烧录必须在 Linux 下进行Windows 下没有官方支持。确认板子处于可烧录状态Jetson 需要进入 Recovery 模式通常是通过按住 Recovery 键再上电或者短接特定引脚。不同载板的设计不一样提前查好。备份原始 eFuse 内容在烧录之前先读取并保存当前 eFuse 的值。虽然未烧录的 eFuse 大多是全 0 或全 F但备份一下总没错万一后面要对比排查问题。注意eFuse 烧录是不可逆的。在按下回车之前务必确认密钥、哈希、SecurityMode 位都正确。我见过有人把测试密钥烧进了量产板结果整批板子只能当开发板用。3. 核心细节解析eFuse 里到底烧了什么3.1 PKC Hash 的计算与写入PKC hash 是 eFuse 里最核心的内容之一。它的计算过程是这样的你先用 OpenSSL 生成一对 RSA 密钥然后提取公钥对公钥做 SHA-256 哈希得到的 256 位哈希值就是要烧进 eFuse 的内容。具体命令大概是这样# 生成 RSA 3072 私钥 openssl genrsa -out rsa_priv.pem 3072 # 提取公钥 openssl rsa -in rsa_priv.pem -pubout -out rsa_pub.pem # 对公钥做 SHA-256 哈希 openssl dgst -sha256 -binary rsa_pub.pem | openssl enc -base64得到的 base64 字符串就是 PKC hash。烧录工具会把这个哈希转换成 eFuse 需要的格式然后写入对应的地址。这里有一个容易出错的地方不同 JetPack 版本对公钥格式的要求可能不同。有的版本要求公钥是 DER 格式有的要求 PEM 格式。我在 JetPack 4.x 上遇到过因为公钥格式不对导致哈希计算错误的情况后来统一用 DER 格式才稳定。建议在计算哈希之前先确认你用的 JetPack 版本对应的文档要求。3.2 SecurityMode 位的含义与设置SecurityMode 位是 eFuse 里的一个标志位它决定芯片是否进入安全启动模式。这个位一旦烧录芯片就会强制验证 Bootloader 的签名验证不通过就不启动。SecurityMode 位通常不是单独存在的它和另外几个位配合使用比如 ODM Production Mode 位、Debug Mode 位等。ODM Production Mode 位烧录后芯片会进入量产模式一些调试接口会被关闭。Debug Mode 位则控制是否允许 JTAG 调试。在实际操作中我一般建议分两步走先烧 PKC hash验证安全启动能正常工作确认无误后再烧 SecurityMode 位和 ODM Production Mode 位。这样万一 PKC hash 有问题还有机会补救。如果一次性全烧了出问题就只能换芯片。3.3 FSKP 流程中的密钥加密FSKP 流程的核心是用一个临时密钥通常叫 FSKP key对要烧录的密钥材料进行加密。这个临时密钥本身也需要通过安全渠道传递不能明文放在产线脚本里。具体操作上NVIDIA 提供了一套工具链来支持 FSKP。大致流程是先在离线环境生成 FSKP 加密后的密钥包然后把密钥包传到产线机器上产线机器通过烧录工具把密钥包写入 eFuse。芯片内部会用预先烧录的 FSKP 解密密钥来解密密钥包然后熔断相应的 eFuse 位。这里的关键是 FSKP 解密密钥本身怎么烧进去。通常的做法是先用一个默认的 FSKP 密钥NVIDIA 提供的或者你自己生成的烧录一次然后再用这个密钥来加密后续的密钥材料。这个过程有点像“先用一把钥匙锁住另一把钥匙”逻辑上要理清楚否则容易把自己绕进去。3.4 烧录工具与命令解析Jetson eFuse 烧录主要用 NVIDIA 提供的fuseburn工具它是 JetPack 的一部分。不同版本的命令参数略有差异但核心逻辑差不多。一个典型的烧录命令大概长这样sudo ./fuseburn --chip 0x23 --key rsa_pub.pem --secmode 1 --odm 1其中--chip指定芯片型号--key指定公钥文件--secmode和--odm分别指定 SecurityMode 和 ODM Production Mode 位。实际使用时我建议先用--dry-run或者类似的只读模式跑一遍确认工具能正确识别芯片和 eFuse 布局。确认无误后再去掉 dry-run 参数真正烧录。提示烧录过程中不要断电不要拔线。eFuse 烧录需要稳定的电源电压波动可能导致烧录失败甚至芯片损坏。4. 实操过程从零到安全启动跑通4.1 环境搭建与工具安装我用的环境是 Ubuntu 20.04 LTSJetPack 5.1。安装步骤大致如下从 NVIDIA 官网下载 JetPack SDK Manager安装到主机上。通过 SDK Manager 安装 Jetson 相关的烧录工具和驱动。确认fuseburn工具已经安装通常在/opt/nvidia/或 JetPack 安装目录下。安装 OpenSSL 和其他依赖库。这里有一个坑SDK Manager 默认会下载完整的 JetPack 包体积很大。如果只需要烧录工具可以在 SDK Manager 里只勾选“Flash”相关的组件不勾选 CUDA、cuDNN 等大包。这样能省不少时间和磁盘空间。4.2 生成密钥并计算哈希按照前面说的方法生成 RSA 密钥对然后计算 PKC hash。我一般会把密钥和哈希值放在一个专门的目录里命名清晰比如keys/ rsa_priv.pem rsa_pub.pem pkc_hash.txt计算完哈希后把哈希值保存到pkc_hash.txt后面烧录时直接引用这个文件。4.3 进入 Recovery 模式并连接Jetson 进入 Recovery 模式的方法因载板而异。以 Orin Nano 开发套件为例通常是按住 Recovery 键然后按一下 Reset 键再松开 Recovery 键。连接主机后用lsusb命令应该能看到 NVIDIA 的设备。确认连接成功后用fuseburn的查询命令读取当前 eFuse 状态sudo ./fuseburn --chip 0x23 --read这个命令会输出当前 eFuse 的各个位状态包括 PKC hash 是否已烧录、SecurityMode 位是否已设置等。第一次操作时这些值应该都是未烧录状态。4.4 执行烧录并验证确认一切就绪后执行烧录命令。烧录过程通常很快几秒钟到几十秒不等。烧录完成后再次用--read命令读取 eFuse 状态确认 PKC hash 和 SecurityMode 位已经正确写入。然后重新上电观察启动过程。如果安全启动配置正确芯片会正常启动如果配置有误可能会卡在 BootROM 阶段串口没有任何输出。这时候不要慌先检查 eFuse 读取的值是否和预期一致再检查公钥格式和哈希计算是否正确。4.5 签名固件并烧录eFuse 烧录完成后后续的固件必须用对应的私钥签名才能启动。签名过程通常由 JetPack 的脚本自动完成你只需要在编译固件时指定私钥路径即可。签名后的固件烧录和普通固件烧录流程一样但烧录工具会额外验证签名。如果签名不匹配烧录会失败。5. 常见问题与排查技巧实录5.1 烧录失败工具报错“Chip not found”这是最常见的问题通常是因为板子没有正确进入 Recovery 模式。排查步骤确认 USB 线连接的是正确的接口有些载板有多个 USB 口只有一个是 Recovery 口。确认 Recovery 键的操作顺序正确。用lsusb确认主机能识别到 NVIDIA 设备。如果还是不行尝试换一根 USB 线或换一个主机 USB 口。5.2 烧录后无法启动串口无输出如果烧录后串口没有任何输出可能是 SecurityMode 位烧录了但 PKC hash 不正确导致 BootROM 验证失败。这时候需要用fuseburn --read读取 eFuse确认 PKC hash 的值和预期一致。检查公钥格式是否正确PEM vs DER。检查哈希计算时是否用了正确的哈希算法SHA-256。如果确认 PKC hash 烧错了这颗芯片基本就废了。所以再次强调烧录前一定要反复确认。5.3 签名固件烧录失败签名验证不通过这通常是因为签名用的私钥和 eFuse 里的 PKC hash 不匹配。排查方法确认签名用的私钥和生成 PKC hash 时用的公钥是同一对。确认签名算法和 eFuse 配置一致RSA vs ECDSA。检查签名脚本的参数是否正确。5.4 常见问题速查表问题现象可能原因排查方法工具报错 Chip not found未进入 Recovery 模式检查 USB 连接和按键顺序烧录后串口无输出PKC hash 错误或 SecurityMode 配置错误读取 eFuse 对比预期值签名固件烧录失败私钥与 PKC hash 不匹配确认密钥对和签名算法烧录过程中断电源不稳或 USB 断开检查电源和线缆重新烧录eFuse 读取值全为 0芯片未正确连接或工具版本不匹配确认芯片型号和工具版本5.5 独家避坑技巧先烧测试板量产前一定要用一两块测试板走完整流程确认无误后再上量产。密钥离线保管私钥不要放在产线机器上签名操作在离线环境完成。记录烧录日志每次烧录都保存日志包括 eFuse 读取值、烧录命令、时间戳等方便追溯。不要跳过 dry-run烧录工具的 dry-run 模式能帮你发现很多配置问题不要嫌麻烦。电源要稳eFuse 烧录对电源敏感建议用带稳压的电源适配器不要用劣质 USB 线供电。6. 量产环境下的 eFuse 烧录管理6.1 产线烧录流程设计量产环境下eFuse 烧录不能像实验室里那样手动操作。需要设计一套可重复、可追溯的流程。我一般建议把烧录流程分成几个阶段阶段一芯片预检。读取 eFuse 状态确认芯片是未烧录状态记录芯片序列号。阶段二烧录 PKC hash。用产线工具自动烧录烧录后立即读取验证。阶段三烧录 SecurityMode 和 ODM 位。验证 PKC hash 无误后再烧录这些位。阶段四签名固件烧录。用签名后的固件烧录系统验证启动正常。阶段五记录归档。把烧录日志、芯片序列号、密钥版本等信息归档。每个阶段都要有明确的通过/失败判定标准失败品要隔离处理不能混入良品。6.2 密钥版本管理与轮换量产项目通常会涉及密钥轮换。比如第一批产品用密钥 A第二批用密钥 B。这时候 eFuse 里的 PKC hash 就不一样了产线工具需要支持多密钥版本。管理上我建议给每个密钥版本分配一个唯一的版本号烧录时记录版本号后续固件签名时也带上版本号。这样即使将来需要排查问题也能快速定位到对应的密钥。6.3 烧录设备的维护与校准产线烧录设备需要定期维护。USB 线缆会老化电源会漂移这些都可能影响烧录成功率。建议每周做一次烧录设备自检用已知良好的测试板验证烧录流程。另外烧录工具的版本也要管理。不同版本的fuseburn可能对 eFuse 布局的理解不同升级工具版本前一定要在测试板上验证。7. 个人经验总结与后续扩展我在多个 Jetson 项目上做过 eFuse 烧录踩过的坑不少。最大的体会是这件事急不得。每一步都要确认每一个参数都要核对。我见过太多因为赶进度而跳过验证步骤最后整批板子报废的案例。另一个体会是文档要自己写一遍。NVIDIA 的官方文档很全但有些细节只有自己动手才会发现。比如不同载板的 Recovery 模式操作不一样不同 JetPack 版本的工具参数有差异这些在文档里往往一笔带过但实际操作中很容易卡住。后续如果要做更深入的安全方案可以考虑结合 Secure Boot 和 Trusted Execution EnvironmentTEE在 eFuse 基础上增加运行时安全保护。不过那是另一个话题了先把 eFuse 这一关过好后面的路才走得稳。