1. 项目缘起为什么imx6ull的Secure Boot让我折腾了这么久最近在给一个基于NXP i.MX6ULL的工控设备做固件升级方案客户提了一个硬性要求必须启用Secure Boot防止产线或现场被刷入未经授权的固件。这个要求合情合理毕竟设备一旦部署出去物理安全就很难完全保障。Secure Boot安全启动是嵌入式领域尤其是工业物联网设备的一道重要安全防线。它的核心逻辑很简单芯片上电后最先运行的BootROM会去验证接下来要加载的镜像比如U-Boot的数字签名。只有用芯片厂商这里是NXP授权的私钥签过名的镜像才能被信任并执行否则芯片会直接进入下载模式或者干脆“变砖”拒绝启动。听起来很美好对吧但真动手在i.MX6ULL上搞HABHigh Assurance BootNXP对其Secure Boot的实现签名时我才发现这里面的水比想象中深。网上的资料要么是NXP官方晦涩难懂的PDF满篇的寄存器描述和命令行参数要么是些零散的博客只讲了某一步缺了上下文照着做十有八九会卡住。最常见的结局就是你满怀信心地生成了签名烧录进去结果设备亮都不亮串口只输出一句“HAB failure: 0xXX”然后就没了下文让人一头雾水。所以我决定把这次从零开始在i.MX6ULL上成功实现HAB签名的完整过程、踩过的所有坑、以及最终让设备“欢快”跑起来的核心要点系统地梳理出来。这不是一篇照搬官方手册的翻译而是一个一线工程师的实战复盘。你会看到我为什么选择某些工具某个参数填错会导致什么后果以及当遇到那个令人抓狂的“HAB failure”时应该如何一步步抽丝剥茧找到问题根源。无论你是正在面临同样的需求还是想提前了解i.MX系列芯片的安全启动机制这篇长文都应该能给你提供一条清晰的路径。2. 理解HAB的基石公钥基础设施PKI与SRK表在动手敲任何命令之前我们必须先搞清楚HAB签名的底层逻辑否则后面的所有步骤都将是盲人摸象。HAB本质上构建了一套基于公钥密码学的信任链而这条链的起点就是SRKSuper Root Key表。你可以把SRK想象成设备出厂时内置的一把“万能信任锚”。在i.MX6ULL的OTPOne-Time Programmable熔丝中可以烧录一组SRK哈希值Hash。这组哈希值对应着一组公钥。芯片的BootROM在验证镜像时首先会用熔丝里的SRK哈希去核对镜像中附带的SRK表里面包含了完整的公钥是否可信。只有SRK表被信任了才能用SRK表中的公钥去验证后续的镜像签名。那么这套密钥从哪里来答案是我们需要自己搭建一个微型的PKI公钥基础设施。通常我们会生成一个自签名的根证书CA然后用这个CA去签发一系列子证书最终用于签名的私钥就保护在这些证书里。NXP的流程推荐使用OpenSSL命令行工具来生成这些密钥对和证书。注意这里有一个关键选择。NXP的HAB支持两种签名算法RSA2048和RSA4096。i.MX6ULL完全支持这两种。选择RSA2048签名和验证速度更快生成的签名块体积更小选择RSA4096理论上更安全但会占用更多的镜像空间验证时间也稍长。对于大多数工控场景RSA2048已经足够安全。我本次项目就选择了RSA2048。生成密钥和证书的步骤大致如下生成根密钥和证书首先我们生成一个RSA2048的根私钥ca_key.pem然后用它创建一个自签名的根证书ca_crt.pem。这个根证书就代表了我们的“私有CA机构”。# 生成CA私钥 openssl genrsa -out ca_key.pem 2048 # 生成CA自签名证书 openssl req -new -x509 -days 3650 -key ca_key.pem -out ca_crt.pem在执行证书生成命令时会交互式地让你输入国家、组织等信息。这些信息会体现在证书中但对于HAB验证本身不是关键可以按实际情况填写。生成SRK密钥和证书SRK通常不止一个NXP建议使用4个SRK密钥来增强安全性即使其中一个密钥泄露系统仍可运行。我们需要用上面的CA来签发SRK证书。# 为每个SRK生成私钥和证书签名请求CSR for i in {1..4}; do openssl genrsa -out srk${i}_key.pem 2048 openssl req -new -key srk${i}_key.pem -out srk${i}.csr done # 使用CA证书为每个CSR签发证书 for i in {1..4}; do openssl x509 -req -in srk${i}.csr -CA ca_crt.pem -CAkey ca_key.pem -CAcreateserial -out srk${i}_crt.pem -days 3650 done生成SRK表并提取哈希有了4个SRK证书后我们需要用NXP提供的srktool通常位于cst工具包中将它们打包成一个SRK表SRK_1_2_3_4_table.bin并从这个表中提取出SRK哈希。# 假设cst工具在../cst目录下 ../cst/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c srk1_crt.pem,srk2_crt.pem,srk3_crt.pem,srk4_crt.pem这个命令做了几件事-h 4指定SRK数量-t输出SRK表文件-e输出包含SRK哈希的熔丝文件-d指定哈希算法为SHA256-c指定输入的证书列表。生成的SRK_1_2_3_4_fuse.bin文件里就包含了要烧录到OTP熔丝中的那组哈希值。至此我们完成了HAB信任链的“原材料”准备。接下来就需要处理我们要签名的目标——U-Boot镜像了。3. 镜像改造为“裸镜像”穿上签名的“外衣”直接从编译得到的U-Boot二进制文件比如u-boot.imx是不能直接用于HAB签名的。BootROM对镜像的格式有严格的要求它期待一个带有特定头部信息的“封装镜像”。这个头部信息里包含了镜像长度、加载地址、入口地址以及最重要的——签名块和证书链的插入位置描述。我们需要使用NXP提供的imx-mkimage工具套件或者在一些旧SDK里叫mkimage来生成这个符合要求的镜像。这个过程通常被称为“生成IVT/DCD/Bo ot Data”并打包。准备配置文件首先你需要一个.cfg文件用来描述芯片类型、镜像组件等。对于i.MX6ULL通常可以参考imx-mkimage/iMX6ULL/目录下的示例。一个简化的my_uboot.cfg可能长这样[BOOT_FROM sd] [BOOT_OFFSET 0x400] [IVT_OFFSET 0x400] [CSF_OFFSET 0x2000]这里BOOT_OFFSET和IVT_OFFSET通常设为相同值表示IVT在镜像内的偏移。CSF_OFFSET则预留了给签名块CSF插入的位置这个值非常关键必须大于IVT、DCD、Boot Data和应用程序即U-Boot本身的总大小并留有足够余量。生成初始镜像使用mkimage工具注意此mkimage非U-Boot的mkimage是NXP专门的工具处理。# 假设工具在imx-mkimage目录下 cd imx-mkimage ./mkimage -n my_uboot.cfg -T imx6ull -e 0x87800000 -d ../u-boot.bin u-boot-ivt.imx-n指定配置文件-T指定芯片类型-e指定U-Boot的入口地址需要和U-Boot链接脚本一致i.MX6ULL通常为0x87800000-d指定输入的U-Boot二进制文件输出为u-boot-ivt.imx。这个文件已经包含了IVT、DCD等结构但还没有签名块所以还不能用于Secure Boot。现在我们得到了一个“等待签名”的裸镜像。下一步就是为它注入数字签名。4. 核心签名流程使用CST工具生成并注入CSF签名和证书注入是通过NXP的封闭源代码工具cstCode Signing Tool完成的。你需要从NXP官网申请并下载这个工具包通常需要签署NDA。得到cst后最关键的一步是编写一个csf描述文件例如hab4_pki.csf。这个文件是指令脚本告诉cst如何对镜像进行签名。这个文件内容较多但结构清晰主要包含以下几个部分版本与引擎选择指定HAB版本和加密引擎。[Header] Version 4.1 Hash Algorithm sha256 Engine SW安装SRK指定之前生成的SRK表文件并声明其哈希将被烧录到熔丝。[Install SRK] File “../keys/SRK_1_2_3_4_table.bin” Source index 0安装CSFKCSFKCSF Key是用于保护CSF命令序列文件即这个文件本身完整性的密钥。这里我们用第一个SRK证书对应的私钥来签名CSFK证书。[Install CSFK] File “../keys/csfk1_crt.pem”认证CSF用CSFK私钥对整个CSF文件内容进行签名确保CSF指令本身没有被篡改。[Authenticate CSF]安装密钥指定用于签名镜像的密钥证书这里我们使用第二个SRK证书对应的私钥作为签名密钥。[Install Key] Verification index 0 Target index 2 File “../keys/srk2_crt.pem”认证数据这是最核心的指令告诉HAB验证哪段镜像数据。需要指定镜像文件的路径、起始地址即IVT的绝对地址、长度。Blocks字段用于指定要验证的连续数据块。[Authenticate Data] Verification index 2 Blocks 0x877ff400 0x0 0x20000 “u-boot-ivt.imx”这里的Blocks参数是最大的坑点之一。第一个值是Image vector table (IVT)的绝对地址。这个地址怎么算对于从SD卡启动IVT通常位于偏移0x400处而i.MX6ULL的内部RAM起始地址是0x00900000但BootROM在加载时会进行一个重定位。实际上更可靠的计算方法是IVT绝对地址 镜像加载地址 IVT偏移量。而镜像加载地址对于不同的启动设备SD NAND eMMC是不同的。我强烈建议你直接参考你所用BSP包中已有的csf示例文件并仔细阅读NXP应用笔记AN4581。填错这个地址百分百会导致“HAB failure”。编写好csf文件后就可以运行cst进行签名了../cst/cst -i hab4_pki.csf -o u-boot-ivt_signed.imx-i指定输入csf文件-o指定输出已签名的镜像文件。如果一切顺利cst会成功运行并生成最终的u-boot-ivt_signed.imx。这个文件就是可以用于Secure Boot的完整镜像。5. 熔丝烧录将信任锚刻进芯片生成了签名镜像并不意味着设备就能自动启用Secure Boot。我们之前生成的SRK哈希还只是躺在电脑里的一个文件SRK_1_2_3_4_fuse.bin。必须将这个哈希值烧录到芯片的OTP熔丝中BootROM才会在启动时去读取并使用它。i.MX6ULL有一组专用的熔丝位用于HAB。烧录熔丝是一个不可逆的操作一旦烧写对应的熔丝位就无法再改回0。如果烧错了SRK哈希那么所有用之前那套密钥签名的镜像都将无法启动芯片很可能就“变砖”了只能通过JTAG等底层方式尝试恢复非常麻烦。因此烧录熔丝前必须进行充分的测试。标准的测试流程是测试签名镜像在不烧写熔丝的情况下将签名镜像u-boot-ivt_signed.imx烧录到设备的启动介质如SD卡。上电后通过串口观察输出。如果签名验证通过U-Boot应该能正常启动并且在U-Boot启动日志的最开始你会看到类似“HAB Configuration: 0xf0, HAB State: 0x66”的信息。HAB State: 0x66表示“HAB enabled and active (security configuration fused)”的模拟状态即芯片认为熔丝已烧但实际上我们还没烧。这是一个好迹象说明签名本身是正确的镜像格式也是对的。确认测试通过确保设备能稳定地用签名镜像启动多次。备份原始镜像和密钥务必保存好未签名的原始镜像、全套密钥对和证书。这是你未来更新固件的唯一凭证。执行熔丝烧写在U-Boot命令行下使用fuse命令进行烧写。你需要根据SRK_1_2_3_4_fuse.bin文件的内容计算出对应的熔丝地址和值。例如SRK_HASH可能分布在0x6-0x9的多个熔丝字每个字32位上。# 在U-Boot中示例命令格式 fuse prog -y 0 6 0x12345678 fuse prog -y 0 7 0x9abcdef0 ...再次警告请逐字核对烧写的值和地址。一个错误的比特都可能导致灾难性后果。建议先烧写一个SRK_HASH比如4个中的1个进行测试确认系统仍能启动再烧写剩余的。烧录完成后芯片的Secure Boot功能才真正被激活。此时只有用你那套私钥签名的镜像才能启动。尝试烧录一个未签名或错误签名的镜像你会看到启动失败串口输出HAB错误事件。6. 故障排查当遇到“HAB failure”时该怎么办即使你万分小心在第一次尝试HAB时大概率还是会遇到启动失败和“HAB failure”的事件。别慌这是常态。HAB提供了一套相对详细的事件Event报告机制我们需要学会解读它。当启动失败时BootROM会在芯片的某个寄存器对于i.MX6ULL通常是SRC寄存器中留下错误状态并且如果串口初始化得足够早你可能会在串口上看到错误码输出。更通用的方法是在U-Boot中如果你还能进入一个未启用安全启动的U-Boot使用hab_status命令来获取详细的HAB事件日志。HAB事件有一个类型和数值。你需要查阅NXP的官方文档如AN4581的附录来解码这些事件。常见的失败原因和排查思路如下HAB Failure: 0x69这通常是“CSF parse error”或“CSF authentication failed”。意味着CSF命令序列文件本身有问题。检查你的csf文件语法是否有错误括号、引号是否匹配文件路径是否正确cst工具能否找到所有引用的密钥和镜像文件[Authenticate Data]中的地址和长度是否正确计算这是最高频的错误点。HAB Failure: 0x66在未烧熔丝时看到这个是正常的模拟状态。在已烧熔丝后还看到启动失败则可能是SRK哈希不匹配。检查烧录到熔丝的值是否与SRK_1_2_3_4_fuse.bin文件完全一致。检查生成SRK表时使用的证书是否与签名时使用的证书链匹配。签名验证失败如果事件指向具体的签名验证错误检查签名用的私钥是否与证书链匹配镜像在签名后是否被意外修改例如某些烧录工具可能会在镜像头部添加额外信息。是否使用了错误的哈希算法如配置了sha256但实际用了sha1我的一个实际踩坑案例我最初在[Authenticate Data]的Blocks参数中直接使用了从.imx文件头里读出来的IVT自包含的地址结果一直报错。后来才发现对于SD卡启动BootROM在加载镜像到内存时有一个固定的加载地址例如0x877ff400我的IVT地址需要基于这个加载地址来计算而不是镜像内部的相对偏移。修正了这个地址后签名立刻验证通过。7. 构建自动化与持续集成将签名流程脚本化手动执行以上步骤不仅容易出错也无法适应产品迭代的需求。我们必须将整个流程脚本化集成到固件的构建系统如Yocto Buildroot或CI/CD管道如Jenkins GitLab CI中。一个基本的自动化脚本流程如下编译U-Boot由构建系统完成输出u-boot.bin。生成IVT镜像在编译后步骤中调用imx-mkimage工具将u-boot.bin封装成u-boot-ivt.imx。这个步骤可以写成一个Makefile规则或Shell脚本。签名镜像调用cst工具传入预先准备好的csf模板文件和密钥路径对u-boot-ivt.imx进行签名生成u-boot-ivt_signed.imx。打包最终镜像将签名后的镜像与其他组件如Linux内核、设备树、根文件系统一起打包成最终可供烧录的工厂镜像如.sdcard或.ubi映像。这里的关键点是csf文件的模板化。csf文件中的镜像文件名、路径等应该是变量。在CI环境中可以通过脚本替换这些变量。同时私钥必须被安全地管理绝不能硬编码在脚本或仓库中。应该使用CI系统的秘密存储功能如GitLab CI的Variables with Masking Jenkins的Credentials Binding来在运行时注入密钥文件或密码。例如一个简化的CI脚本片段#!/bin/bash # 1. 编译 make u-boot # 2. 生成IVT镜像 ./mkimage -n board/imx6ull/my_uboot.cfg -T imx6ull -e 0x87800000 -d u-boot.bin u-boot-ivt.imx # 3. 签名 (密钥从环境变量或安全存储中获取) cp $CST_CSF_TEMPLATE ./temp.csf sed -i “s|IMAGE_PATH|$(pwd)/u-boot-ivt.imx|g” ./temp.csf $CST_PATH/cst -i ./temp.csf -o u-boot-ivt_signed.imx # 4. 清理临时文件 rm ./temp.csf # 5. 后续打包...通过这样的自动化每次代码提交后CI系统都能自动产生一个已签名的、可直接用于生产的固件镜像极大地提高了开发效率和安全性。8. 进阶考量密钥管理、吊销与固件更新实现了一次性签名和烧录只是开始。在产品生命周期中更严峻的挑战在于密钥的安全管理和固件的后续更新。密钥管理生成密钥的CA根私钥必须离线保存最好放在硬件安全模块HSM或完全断网的电脑上。用于签名的私钥即SRK对应的私钥也需要严格保护。在团队中应遵循最小权限原则只有少数授权人员能访问签名密钥。CI系统中的签名步骤也应配置为仅在发布正式版本时触发并由授权人员审批。密钥吊销如果某个SRK私钥疑似泄露怎么办HAB支持密钥吊销。在OTP熔丝中除了SRK哈希还有对应的吊销位Revoke Fuse。烧写对应的吊销熔丝可以使该SRK失效。这就是为什么建议使用多个SRK如4个的原因。你可以预先烧录4个SRK哈希但只使用其中1个进行当前版本的签名。如果这个密钥泄露你可以通过更新固件使用另一个SRK签名并烧录吊销熔丝来吊销泄露的密钥而无需召回所有设备。安全固件更新启用Secure Boot后U-Boot和内核的更新也必须经过签名验证。通常有两种模式完全信任U-Boot模式U-Boot验证后续的kernel和dtb的签名。你需要扩展你的PKI为内核和设备树创建独立的签名证书并在U-Boot中实现相应的验证逻辑例如通过FIT Image机制。通过U-Boot的ums或fastboot命令更新这些命令在接收新镜像时可以调用相同的HAB库进行验证只有验证通过的镜像才会被写入存储介质。你需要确保更新工具链也集成签名功能。无论哪种方式都意味着你的产品OTA空中下载更新系统必须集成签名生成和验证的能力。这通常需要在服务器端用保护良好的私钥对更新包进行签名设备端的更新程序在U-Boot或内核中用对应的公钥进行验证。最后我个人最大的体会是测试测试再测试。在烧录熔丝之前建立一个完整的测试流程。使用开发板反复测试签名镜像在各种异常情况下的行为如断电、损坏的镜像。准备好一个“逃生”机制比如在板上预留一个测试点或开关可以在必要时强制进入串行下载模式以便在密钥丢失或镜像错误时还能恢复。HAB是一把强大的安全锁但钥匙的管理和应急方案同样重要。