摘要本文以 NVIDIA DRIVE OS 6.0.9/6.0.10 的公开文档为主要基线梳理 DRIVE Orin 的安全启动信任关系、NVIDIA 与 OEM 双重签名权限、OEM 密钥治理、量产启用和验证测试。本文不使用 Jetson Orin 的烧录步骤替代 DRIVE Orin 工程流程也不披露或猜测授权文档中的平台细节。关键词NVIDIA DRIVE Orin、DRIVE OS、车载 ECU、安全启动、Secure Boot、OEM PKC、密钥管理、量产测试1. 阅读前先明确平台边界“Orin”是 SoC 架构/产品家族名称公开资料中至少会看到 DRIVE、Jetson 和 IGX 等不同平台。它们可能共享部分底层概念但软件栈、产品定位、启动配置、工具、生命周期管理和文档权限并不相同。本文讨论的是面向汽车开发的NVIDIA DRIVE Orin / DRIVE OS。以下做法并不严谨把 Jetson Linux 的 UEFI Secure Boot 教程直接称为 DRIVE Orin 量产方案把 Jetson 的刷写脚本、板卡名称或熔丝示例复制到 DRIVE 项目看到同为 T23x/Orin就假设所有启动阶段和密钥策略完全一致用开发套件的测试流程替代整车 OEM 的产线安全配置和证据要求。本文的 Orin 专有事实来自文末列出的 NVIDIA DRIVE OS 公开版本文档。具体项目仍须匹配实际 DRIVE OS/PDK 版本、板卡配置、OEM 安全需求和 NVIDIA 授权资料。2. DRIVE Orin 安全启动的公开信任基础2.1 制造阶段建立信任而不是后装一个软件开关NVIDIA DRIVE OS 6.0.9.1 的公开文档明确指出DRIVE Orin 安全启动必须在制造阶段实现并启用不能在设备已经以非安全状态出货后再通过 OTA 在现场补开。这是因为 OEM 信任材料和安全模式依赖一次性可编程熔丝等硬件状态。相关操作具有不可逆性必须纳入样件、试生产和量产配置管理而不是让普通软件升级流程随意改变。2.2 BootROM 与 PSC-ROMDRIVE OS 的公开 Boot ROM 文档说明Orin 芯片中的 BootROM 是硬连线代码用于执行最初的介质访问和启动组件加载PSC-ROM 也位于芯片中负责把 OEM 熔丝信任材料和 NVIDIA 信任材料安全加载到 Security Engine并对 BootROM 加载的二进制执行认证以及按配置进行解密。这构成了芯片早期启动的信任基础。但“存在硬件信任根”不代表后续所有软件自动可信后面的 Bootloader 和加载器仍必须按设计继续延伸信任链。2.3 NVIDIA authority 与 OEM authorityDRIVE Orin 的一个重要特点是存在NVIDIA signing authority和OEM signing authority。NVIDIA 的信任权限固化在芯片设计和 ROM 信任关系中不能由 OEM 覆盖。OEM 可以通过制造阶段配置的熔丝信任材料在 NVIDIA 权限之上建立自己的签名权限。DRIVE OS 公开文档说明部分由 NVIDIA 交付的固件需要经过 OEM 和 NVIDIA 两步认证。这不是简单的“车厂公钥替换 NVIDIA 公钥”而是两套权限共同参与平台信任链。文章中的“OEM 可控制”也不应被理解为“OEM 可以替换芯片内全部 NVIDIA 信任材料”。图 1DRIVE Orin 安全启动的公开信任关系为避免误导图中没有把所有内部固件画成固定顺序3. BCT、BCH 和启动载荷认证根据 DRIVE OS 6.0.9/6.0.10 公开文档BCT 是启动配置相关数据结构BCHBoot Component Header保存一个或一组二进制的大小、版本和哈希等信息平台验证受签名保护的 BCH再把其中记录的摘要与实际加载内容的计算结果比较BootROM、MB1、MB2、Partition Loader 等加载阶段会对相应固件、校准数据、设备树或 Guest OS 载荷执行验证、认证并可按配置解密。这里需要纠正一句常见但过于简化的话“芯片直接对整个固件文件做一次签名验证。”公开实现实际上可能由签名头、组件分组、摘要验证和多阶段加载共同完成。理解原理时可以概括为“验证镜像”但落地和测试必须以平台规定的签名容器及受保护对象为准。DRIVE OS 6.0.10 公开文档还列出了 OEM 可选的认证算法组合例如 RSA 3072/RSASSA-PSS 与 SHA-512或平台文档定义的 EdDSA 方案。算法选择由平台能力、熔丝配置和项目要求共同决定不能在量产后随意切换。4. 认证、加密、防回滚与密钥吊销这四项能力经常被打包成一句“安全启动”但它们解决的问题不同。能力解决的问题不自动解决的问题签名认证镜像是否来自被信任的签名者内容是否保持完整镜像内容是否保密镜像加密降低固件明文泄露风险发布者是否合法、版本是否允许防回滚阻止重新安装仍有合法签名但已被禁用的旧版本新版本自身是否没有漏洞密钥吊销停止信任已泄露或退役的签名密钥自动生成替代密钥和更新全部设备DRIVE OS 公开资料显示OEM 可配置多个公钥摘要其中包含可吊销项。但具体项目是否启用、吊销位如何管理、哪些载荷接受哪些签名者以及安全版本如何存储都必须以对应版本的 PDK、产品设计和量产策略为准。不要把“平台具备能力”写成“所有 DRIVE Orin 产品默认启用”。安全能力只有在密钥、熔丝、签名、启动加载器和生命周期策略正确衔接时才成立。5. OEM 推荐落地架构以下内容是基于通用汽车网络安全工程实践提出的参考设计不是 NVIDIA 硬件的固定要求。5.1 密钥分层建议至少区分离线根信任极少使用只用于授权下级签名身份、灾难恢复或信任体系变更量产代码签名密钥在受控 HSM 或等效系统中使用负责量产启动镜像OTA/发布签名身份按平台支持和组织职责设计可与启动签名流程隔离开发与测试密钥仅用于开发板和测试设备不得被量产设备信任应急替代密钥在平台支持的密钥槽和吊销机制内预先规划而不是泄露后临时寻找空槽。私钥不应进入普通开发电脑、构建服务器镜像、源代码仓库或产线共享目录。构建系统生成待签名内容或摘要通过经过认证的接口向签名服务发起请求由签名服务执行权限校验、审批、签名和审计。图 2一种推荐的职责分离方式。图示是 OEM 参考方案不是 DRIVE Orin 强制拓扑。5.2 环境和设备生命周期隔离开发、验证、试生产和量产环境应使用不同的信任材料和访问权限。设备也应有可识别的生命周期状态例如研发样件、生产配置中、量产锁定和维修状态。安全目标包括测试密钥签名的镜像不能在量产设备启动量产私钥不能被开发或产线操作人员直接导出设备进入量产安全状态前完成全部不可逆配置核验安全模式等会限制后续熔丝配置的状态最后设置并执行双人复核量产记录可以追溯设备、配置版本、签名版本、操作工位和结果但日志中不泄露密钥。5.3 推荐的发布数据流构建系统生成确定版本的启动组件和软件物料清单安全流水线检查来源、评审状态、版本号、漏洞门禁和目标硬件签名服务验证请求并在 HSM 内完成签名发布系统校验签名产物、哈希、版本映射和发布审批产线只接收受控发布包不接触量产私钥设备配置完成后读取并记录可核验的安全状态OTA 平台只分发符合目标 ECU、版本和升级策略的发布包车辆端验证下载包和启动载荷成功后再按设计推进防回滚状态。6. A/B 升级与受控恢复安全启动负责判断镜像是否满足认证策略可用性设计则要解决“新镜像损坏或升级中断以后如何继续服务”。常见方案是 A/B 槽位或等效的主备启动机制。设计时需要同时回答新槽位在首次启动前是否已经完成完整认证启动失败多少次后允许回退计数如何防止断电破坏回退目标是否仍满足最低安全版本恢复镜像和恢复工具是否也经过认证恢复接口能否被未授权人员用于加载任意代码OTA 成功确认与安全版本推进的顺序是否能承受断电“能回退”与“防回滚”并不矛盾系统可以回退到仍在策略允许范围内的已签名版本但不能回到已经被安全策略淘汰的易受攻击版本。7. 安全启动测试方法测试不能只做“合法镜像可以启动”的正向用例。真正能证明防护有效的是错误镜像、错误密钥、旧版本和异常恢复路径都无法绕过认证。图 3建议同时覆盖正向、反向、生命周期和恢复测试。7.1 测试通用前置条件固定硬件型号、板卡版本、DRIVE OS/PDK 版本和启动介质明确设备生命周期状态及已配置的信任材料准备一套合法镜像、独立测试密钥、篡改工具和可重复刷写的测试环境确认日志、串口或诊断信息不会暴露密钥及敏感内部状态记录镜像哈希、签名者、版本、槽位和预期启动路径对不可逆配置使用专用测试样件并先执行平台提供的非破坏性检查流程。7.2 用例与判定方法编号测试目标操作思路预期行为关键证据与通过判据SB-01验证合法发布链部署受信任密钥签名、版本允许的完整镜像按设计启动到目标系统启动阶段、版本和签名产物一致无验证错误SB-02验证内容完整性分别修改受保护 Bootloader、内核、设备树或配置中的少量数据不重新签名被修改对象不得执行按产品策略停止或恢复日志指向相应验证失败未进入被篡改镜像SB-03验证签名强制性去除签名、破坏签名数据或头部镜像被拒绝不存在“缺少签名则降级为非安全启动”的路径SB-04验证信任锚使用未被设备信任的测试私钥重新签名合法内容镜像被拒绝验证结果与设备信任配置一致SB-05验证防回滚安装签名有效但低于最低允许安全版本的镜像按版本策略拒绝设备安全版本状态没有倒退旧镜像未执行SB-06验证密钥轮换分别使用当前、替代和已经吊销的签名身份制作镜像只接受策略允许的签名者各密钥状态与启动结果一一对应SB-07验证升级原子性在下载、写入、切槽、首次启动确认等阶段分别断电不执行不完整镜像进入允许的旧槽或恢复路径最终运行版本合法启动计数和槽位状态一致SB-08验证恢复安全损坏主镜像并触发恢复再尝试加载未授权恢复载荷合法恢复可用非法恢复载荷被拒绝恢复路径同样执行认证没有通用绕过接口SB-09验证生命周期隔离在量产状态设备上尝试测试密钥镜像和受限调试方式均按量产策略被拒绝量产设备不信任测试身份调试状态符合配置SB-10验证配置一致性对设备安全状态、信任摘要和生产记录进行只读核验实际状态与生产清单一致可追溯无遗漏设备和错误密钥批次上述“停止或恢复”必须由产品安全需求预先定义不能为了让测试通过而临时接受任何一种结果。测试通过的共同底线是未授权镜像没有获得执行权且证据能够证明失败发生在哪个阶段。7.3 还应关注的故障与攻击组合单一篡改测试之外还应组合验证镜像正确但启动元数据、分区表或版本字段异常主槽验证失败且备用槽版本过旧连续断电导致启动尝试计数或升级状态异常已吊销密钥与缓存发布包组合维修模式、工厂模式、USB/网络恢复模式下的未授权载荷日志过度详细导致密钥标识、内存地址或安全配置泄露。具体故障注入方法需要遵守实验室安全规则和 NVIDIA 对目标硬件的操作要求。不要在量产 ECU 上直接试验不可逆熔丝操作。8. 与 ISO/SAE 21434、UN R155 的关系ISO/SAE 21434:2021 是道路车辆网络安全工程标准覆盖概念、开发、生产、运行维护和退役等生命周期活动。UN R155 要求适用车辆制造商建立网络安全管理体系并在车型层面处理网络安全风险。安全启动可以为以下工作提供技术措施和证据针对启动镜像篡改、非授权软件和降级攻击的风险处置网络安全需求、架构设计和验证确认生产阶段信任材料配置与一致性控制软件更新、事件响应、密钥泄露和漏洞修复流程。但标准和法规并不等同于某一项芯片功能。是否需要安全启动、保护哪些对象、失败后进入什么状态都应来自项目的资产识别、攻击路径分析、风险评估和网络安全目标。启用安全启动不能替代组织流程、供应链管理、漏洞管理和持续监控。9. 量产前检查清单使用的是目标 DRIVE OS/PDK 版本对应的签名与熔丝文档DRIVE、Jetson、IGX 的工具和字段没有混用受保护启动对象清单完整包括关键配置和恢复载荷开发、测试和量产密钥完全隔离量产私钥由 HSM 或等效受控环境保护不可逆配置经过样件验证、双人复核和产线防错安全模式等限制后续配置的状态按规定最后设置防回滚、A/B、恢复和 OTA 断电时序已经联合验证密钥轮换、吊销和应急发布有演练记录调试、诊断、维修和恢复接口不存在认证绕过每台设备的可核验安全状态能够与生产记录对应正向与反向测试均保存了可审计证据。结语DRIVE Orin 安全启动不是“烧一把密钥、给镜像签个名”这么简单。它是一条从芯片内 ROM 和硬件信任材料开始经 NVIDIA 与 OEM 权限、启动组件认证、Bootloader 信任延伸一直到 Guest OS 和恢复路径的工程链条。真正决定量产安全性的往往不是密码算法名称而是密钥是否隔离、不可逆配置是否防错、全部启动路径是否纳入认证、防回滚与 A/B 是否协调以及密钥泄露后是否仍有可执行的轮换和吊销方案。参考资料与版本基线NVIDIA DRIVE OS 6.0.9.1 — Secure BootNVIDIA DRIVE OS 6.0.10 — Secure Boot Details with PKC ProtectionNVIDIA DRIVE OS 6.0.9 — Authentication and Validation of BinariesNVIDIA DRIVE OS 6.0.6 — Boot ROMNVIDIA DRIVE OS 6.0.7 — Fuse Burning ResponsibilitiesISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineeringUNECE — UN Regulation No. 155重要说明NVIDIA DRIVE OS 的公开网页带有版本号并可能标注“Subject to Change”。本文只概括上述版本公开可确认的机制不应作为量产熔丝参数、签名命令或安全认证的唯一依据。实际项目必须以目标版本正式 PDK、硬件资料、OEM 网络安全需求和 NVIDIA 授权支持结论为准。