生产预置安全：Jetson eFuse 烧录实战

---

📺 B站 嵌入式孙老师：博主个人介绍
📘 博主书籍-京东购买链接：Yocto项目实战教程
📘 加博主微信，进技术交流群：jerrydev

---

在嵌入式产品量产过程中，eFuse 烧录是一个非常特殊的安全步骤。

它不是普通的软件配置，也不是一次常规刷机，而是在设备出厂前，将根信任、关键密钥和安全策略固化到 SoC 内部。其中很多配置具有一次性、不可逆的特点，一旦进入正式生产状态，后续软件无法随意修改。

从生产预置的角度看，eFuse 的核心作用可以概括为：

在设备离开研发环境之前，把以后不能被软件重新定义的安全基础固化下来。

对于 Jetson AGX Orin，这些配置会进一步影响 Secure Boot、密钥派生、调试权限、固件升级以及设备后续整个生命周期。

---

1. eFuse 在生产预置中的位置

1.1 为什么需要生产预置

设备安全通常不是从 Linux 启动以后才开始，而是在产品生产阶段就已经建立。

整个生命周期可以简单理解为：

生产预置
   ↓
启动安全
   ↓
运行时安全
   ↓
升级安全
   ↓
数据安全

其中，生产预置发生得最早。

后续 Secure Boot、TEE、安全存储、磁盘加密以及 OTA 等机制虽然运行在不同阶段，但其中部分机制需要依赖提前建立好的硬件 Root of Trust。

eFuse 正是承担这一角色的重要载体之一。

---

1.2 eFuse 中通常固化什么

在 Jetson 平台上，典型安全 Fuse 包括：

PublicKeyHash
SecureBootKey
OemK1 / OemK2
BootSecurityInfo
ArmJtagDisable
SecurityMode

这些 Fuse 的具体作用不同，但本质上都在确定几个问题。

1.2.1 设备信任谁

例如：

PublicKeyHash

用于建立与 PKC 公钥相关的硬件信任基础。

设备启动时，BootROM 根据已经烧入芯片的安全信息判断后续启动对象是否可信。

---

1.2.2 设备使用什么根密钥

例如：

SecureBootKey
OemK1
OemK2

可以参与启动镜像保护、密钥派生以及其他安全机制。

这些 Key 一旦作为硬件 Root Key 使用，后续的软件密钥体系都可能建立在它们之上。

---

1.2.3 设备允许哪些调试能力

例如：

ArmJtagDisable

可以限制量产设备的硬件调试能力。

关闭调试接口能够提高物理攻击门槛，但同样会影响后续返修和故障分析，因此不能孤立考虑。

---

1.2.4 设备是否进入生产安全状态

其中最重要的状态之一是：

SecurityMode

它代表设备安全配置开始进入更加严格的生产状态。

因此，eFuse 并不是简单保存几个参数，而是在硬件层面回答：

设备信任谁？
根密钥是什么？
允许怎样调试？
设备处于什么安全状态？

---

1.3 eFuse 与后续安全机制的关系

eFuse 本身并不等于 Secure Boot。

更合理的关系是：

        eFuse / OTP
            │
            ▼
       Root of Trust
            │
     ┌──────┼──────┐
     │      │      │
     ▼      ▼      ▼
Secure   Key     Debug
 Boot   Derive   Policy
     │      │
     ▼      ▼
   UEFI   EKB / TEE
     │
     ▼
   Linux

因此，eFuse 更像整个设备安全体系中的硬件配置锚点。

后面的安全机制可以继续变化和升级，但最底层的信任基础在生产阶段就已经确定。

---

2. 生产预置方案设计

真正开始烧 Fuse 之前，最重要的工作并不是学习烧录命令，而是设计生产安全边界。

2.1 谁应该掌握根密钥

研发阶段很容易形成这样的流程：

准备 fuse.xml
      ↓
运行烧录工具
      ↓
完成

但正式量产时，真正需要关注的是：

谁能够看到 Root Key？

Fuse 配置可能涉及：

PKC PublicKeyHash
SBK
OEM Root Key
其他敏感安全参数

如果直接把原始 Key、Fuse XML 和生成工具全部交给生产线，那么代工厂实际上可能获得产品最核心的安全资产。

因此应该把生产职责拆开。

2.1.1 安全团队负责

Root Key
PKC Key
Fuse Policy
Fuse Configuration
Production Blob 生成

2.1.2 工厂负责

识别设备
加载生产 Blob
执行烧录
验证结果
记录生产数据

也就是：

安全团队决定烧什么，生产线只负责按照已经批准的策略执行。

---

2.2 FSKP 建立生产安全边界

NVIDIA 为 Jetson 提供：

FSKP
Factory Secure Key Provisioning

其核心目的就是减少敏感 Fuse 数据直接暴露给生产环境。

整个流程可以理解为：

      企业安全环境

 Root Key / PKC Key
          │
          ▼
 Fuse Configuration
          │
          ▼
     FSKP Generate
          │
          ▼
 Encrypted Fuse Blob
          │
──────────┼──────────
          │
        Factory
          │
          ▼
        Jetson
          │
          ▼
        eFuse

生产线主要接触：

Encrypted Fuse Blob

而不应该直接接触：

PKC Private Key
SBK
OEM Root Key
原始 Fuse Key

这就是生产预置中非常重要的一道安全边界。

---

2.3 Fuse Configuration 的管理

Jetson 使用 XML 文件描述需要烧录的 Fuse。

基本结构如下：

<genericfuse MagicId="0x45535546" version="1.0.0">

    <fuse
        name="<fuse-name>"
        size="<size>"
        value="<value>"/>

</genericfuse>

例如：

<genericfuse MagicId="0x45535546" version="1.0.0">

    <fuse
        name="PublicKeyHash"
        size="64"
        value="0x<YOUR_PUBLIC_KEY_HASH>"/>

    <fuse
        name="BootSecurityInfo"
        size="4"
        value="0x1"/>

    <fuse
        name="SecurityMode"
        size="4"
        value="0x1"/>

</genericfuse>

这里真正重要的并不是 XML 语法。

Fuse Configuration 本质上已经属于：

产品硬件安全策略。

因此不应该由某个工程师临时修改后直接投入量产。

2.3.1 建议进行版本管理

例如：

security/
└── fuse/
    ├── orin_prod_v1.xml
    ├── orin_prod_v2.xml
    └── README.md

每个 Fuse Profile 至少应该明确：

产品型号
Board ID
Board SKU
Fuse Profile Version
Key Version
配置文件 Hash
发布日期

例如：

Product: Jetson-AGX-Orin
Board-SKU: xxxx
Fuse-Profile: PROD-V1.2
PKC-Key-Version: V3
SHA256: xxxxxxxxx

这样生产线上才能明确：

当前设备到底使用了哪一版安全配置。

---

2.4 Fuse 烧录顺序

eFuse 与普通 Flash 最大的不同在于：

不可逆

很多 Fuse bit 一旦从：

0 → 1

就无法恢复成：

1 → 0

因此烧录顺序非常重要。

一个比较容易理解的顺序是：

Root Key / Hash
       ↓
Security Parameter
       ↓
Debug Policy
       ↓
其他生产配置
       ↓
SecurityMode

2.4.1 为什么 SecurityMode 应放在最后

SecurityMode 不应该被理解成普通参数。

更合理的理解是：

安全配置完成后的封口动作。

进入最终生产状态之前，应该已经完成：

Root Key 确认
PKC Hash 确认
安全参数确认
Debug Policy 确认
启动验证
生产配置验证

然后再完成生产状态切换。

整个状态变化更接近：

Engineering State
       │
       ▼
Security Provisioning
       │
       ▼
Security Verification
       │
       ▼
SecurityMode
       │
       ▼
Production State

这样理解，比单纯把它看成“再烧一个 Fuse”更加符合实际产品流程。

---

3. Jetson eFuse 烧录实战

下面进入真正的烧录流程。

整体可以压缩为：

Fuse Configuration
        ↓
Dry Run
        ↓
Production Blob
        ↓
Factory Burn
        ↓
Read Back
        ↓
Security Verification

---

3.1 准备烧录环境

本文以：

Target:
Jetson AGX Orin

SoC:
T234

Chip ID:
0x23

BSP:
Jetson Linux R39.2.x

为例。

进入 BSP：

cd Linux_for_Tegra

FSKP 相关工具位于：

cd l4t/tools/flashtools/fuseburn

其中核心工具为：

fskp_fuseburn.py

整个工具链负责完成：

Fuse XML
   ↓
Fuse 数据处理
   ↓
Fuse Blob
   ↓
FSKP 保护
   ↓
Recovery / RCM
   ↓
Target
   ↓
eFuse Program

---

3.2 正式烧录前执行 Dry Run

所有不可逆安全操作都应该先完成测试。

FSKP 提供：

--test

模式。

例如：

sudo ./fskp_fuseburn.py \
    --board-spec orin-agx-board-spec.txt \
    -f fuse.xml \
    --test \
    --key-exp fskp_ak.bin fskp_ek.bin \
    --fskpcfg fskp_conf.txt \
    -g out_test/ \
    -c 0x23 \
    -B <top>/jetson-agx-orin-devkit.conf

3.2.1 Dry Run 需要确认什么

至少包括：

Fuse XML 是否正确
Board Spec 是否正确
Board ID / SKU 是否匹配
Key 是否正确
Fuse Blob 是否能够生成
Recovery Mode 是否正常
USB / RCM 通信是否正常
Target 是否能够正确解析配置

Dry Run 的目的并不是简单确认：

命令能不能运行

真正需要避免的是：

Fuse 烧录成功，但是内容错误

对于不可逆配置而言，这比直接烧录失败更加危险。

---

3.3 生成 Production Fuse Blob

测试完全通过以后，再生成正式 Production Blob。

例如：

sudo ./fskp_fuseburn.py \
    --board-spec orin-agx-board-spec.txt \
    -f fuse.xml \
    -i 62 \
    -b \
    --key-exp fskp_ak.bin fskp_ek.bin \
    --fskpcfg fskp_conf.txt \
    -g out_prod/ \
    -c 0x23 \
    -B <top>/jetson-agx-orin-devkit.conf

随后可以将正式输出打包：

tar cf orin_fuse_prod_v1.tar out_prod/

此时真正交给生产线的是：

orin_fuse_prod_v1.tar

而不是：

PKC Private Key
SBK
OEM Root Key
FSKP Expansion Key
原始安全配置材料

这样就形成：

Security Team
     │
     ▼
Production Fuse Blob
     │
─────┼─────
     │
 Factory

安全资产和生产动作实现分离。

---

3.4 生产线执行 Fuse Burn

生产设备首先进入 Recovery Mode。

生产线解压已经生成好的 Blob：

tar xpf orin_fuse_prod_v1.tar

然后执行：

sudo ./fskp_fuseburn.py \
    --board-spec orin-agx-board-spec.txt \
    -P ./out_prod \
    -c 0x23 \
    -B <top>/jetson-agx-orin-devkit.conf

这里：

-P

表示直接使用已经生成好的 Fuse Blob。

3.4.1 工厂侧的标准动作

生产端流程应该尽量简单和固定：

扫描 SN
   ↓
读取 Board 信息
   ↓
确认设备型号
   ↓
进入 Recovery
   ↓
加载 Production Blob
   ↓
eFuse Burn
   ↓
读取结果

工厂执行的是：

已经审核过的安全策略

而不是在生产线上重新生成安全策略。

---

3.5 烧录后的验证

Fuse Burn 返回成功并不代表生产预置流程结束。

完整流程应该是：

Fuse Burn
   ↓
Fuse Read Back
   ↓
Secure Boot Test
   ↓
Functional Test
   ↓
Production Record

3.5.1 Fuse Read Back

可以使用：

sudo nv_fuse_read.sh

或者读取指定 Fuse：

sudo nv_fuse_read.sh boot_security_info

读取结果用于确认实际 Fuse 状态是否符合预期。

---

3.5.2 验证真实安全行为

单纯读取 Fuse 值还不够。

真正需要验证：

合法签名镜像可以启动
错误签名镜像不能启动
设备能够正常进入系统
基础外设功能正常
升级和恢复路径正常

这一步能够发现：

Fuse 值正确

但：

整个安全系统配置错误

的情况。

---

3.5.3 建立生产记录

每台设备建议至少保存：

SN
ECID
Board ID
Board SKU
Fuse Profile
Key Version
Fuse Blob Hash
Burn Time
Burn Station
Burn Result
Verification Result

例如：

SN: JETSON000123

ECID:
xxxxxxxxxxxx

Fuse Profile:
PROD-V1.2

PKC Key Version:
V3

Station:
FUSE-02

Burn Result:
PASS

Verification:
PASS

这样以后出现：

Secure Boot Failure
OTA Failure
Key Version Error
Return / Repair

都可以追溯到具体生产配置。

---

4. eFuse 对设备生命周期的影响

eFuse Burn 通常只发生一次，但其影响会持续整个设备生命周期。

因此生产预置不能只考虑“今天能不能启动”。

---

4.1 对 Secure Boot 的影响

例如：

PublicKeyHash

一旦烧入，就建立了设备启动信任的重要硬件基础。

后续：

MB1
MB2
UEFI
Kernel

相关启动对象都需要按照已经建立的安全体系进行签名和验证。

4.1.1 Root Signing Key 必须长期保存

真正需要长期保护的不是：

fskp_fuseburn.py

而是：

Root Signing Key

如果根签名密钥丢失或者管理混乱，可能直接影响：

未来 Bootloader 更新
Kernel 更新
安全补丁
OTA
设备恢复

因此密钥生命周期往往比 Fuse Burn 本身更加重要。

---

4.2 对密钥派生的影响

如果使用：

OemK1
OemK2

作为硬件 Root Key，后续安全体系可能形成：

OEM Root Key
     ↓
Derived Key
     ↓
EKB
     ↓
OP-TEE
     ↓
Secure Application

一旦最底层 Root Key 固化，后续软件必须围绕这套密钥体系进行设计。

所以应该：

先设计 Key Hierarchy
         ↓
再确定 Fuse Key
         ↓
最后执行 Provisioning

而不是反过来。

---

4.3 对调试和返修的影响

生产设备通常需要限制：

JTAG
Debug Interface
Engineering Access

但安全和维修天然存在一定冲突。

如果过早关闭调试能力：

PCBA Failure
DDR Failure
Peripheral Failure
System Failure

都会变得更加难以定位。

因此更合理的生产顺序是：

PCBA Test
   ↓
DDR Test
   ↓
Peripheral Test
   ↓
Burn-in Test
   ↓
System Test
   ↓
Security Provisioning
   ↓
Debug Restriction
   ↓
Final Test

也就是说：

先完成需要强调试能力的测试，再进入最终安全状态。

---

4.4 对 OTA 和长期维护的影响

设备烧入 Root of Trust 以后，未来所有升级都必须考虑：

设备到底信任谁？

因此生产阶段至少需要提前规划：

4.4.1 Root Key

负责建立最底层长期信任。

4.4.2 Production Signing Key

负责日常发布和生产固件签名。

4.4.3 Key Rotation

密钥达到生命周期后如何更新。

4.4.4 Key Revocation

某把 Key 泄漏以后如何停止信任。

4.4.5 Recovery

出现严重软件故障以后，设备如何安全恢复。

因此成熟的安全产品不是简单：

把设备锁死

而应该做到：

外部未经授权的软件不能运行，而厂商仍然保留受控升级和维护能力。

---

4.5 推荐的完整生产流程

最终，可以把整个生产预置流程统一为：

             Security Team

          Key Generation
                │
                ▼
       Fuse Policy Design
                │
                ▼
       Fuse Configuration
                │
                ▼
        FSKP / Secure Tool
                │
                ▼
      Production Fuse Blob
                │
────────────────┼────────────────
                │
              Factory
                │
                ▼
         Hardware Test
                ↓
          System Test
                ↓
         Recovery Mode
                ↓
           eFuse Burn
                ↓
          Fuse Readback
                ↓
      Signed Firmware Flash
                ↓
        Secure Boot Test
                ↓
         Functional Test
                ↓
       Production Record
                ↓
            Shipment

这样，eFuse Burn 就不再是一个孤立命令，而成为整个生产安全流水线中的关键节点。

---

4.6 生产预置最重要的几个原则

最终可以归纳成七条：

1. 先设计安全体系，再决定烧哪些 Fuse。
2. Root Key 和私钥不进入普通生产线。
3. Fuse Configuration 必须进行正式版本管理。
4. 所有正式烧录之前必须完成 Dry Run。
5. SecurityMode 放在最终阶段处理。
6. 关闭调试能力之前先完成生产测试。
7. Fuse Burn、验证结果和设备身份必须能够追溯。

---

总结

从工具角度看，eFuse 烧录流程很简单：

Fuse XML
   ↓
Fuse Blob
   ↓
Burn

但从生产预置角度看，它真正完成的是：

Root Key 固化
      +
硬件根信任建立
      +
安全策略固化
      +
生产状态切换

因此 eFuse 不应该仅仅被理解为 Secure Boot 中的一个配置动作。

更准确地说，它是设备在出厂之前的一次：

安全定型。

设备在这个阶段确定：

信任谁
根密钥是什么
允许哪些调试能力
以后接受什么固件
最终进入什么安全状态

这些条件一旦进入 eFuse，后续的 Secure Boot、TEE、磁盘加密、OTA 和设备维护，都必须建立在已经确定的硬件安全基础之上。

所以生产预置真正需要回答的问题不是：

“eFuse 怎么烧？”

而是：

“哪些安全决策需要在产品离开生产线之前永久固化？”

这才是 eFuse 烧录真正的工程意义。