1. 项目概述为i.MX6ULL构建安全启动的护城河最近在为一个工业网关项目做安全加固客户明确要求启动链必须可信防止固件被恶意篡改。这让我把目光投向了NXP i.MX6ULL这颗经典的工业级处理器并深入折腾了一番它的HABHigh Assurance Boot安全启动与签名机制。这不仅仅是打开一个配置开关那么简单它涉及到从芯片熔丝配置、签名密钥管理到最终镜像生成的一整套流程。如果你也在为产品寻找一个可靠且成本可控的硬件级安全启动方案那么i.MX6ULL的HAB绝对值得你花时间研究。它就像为你的设备构建了一道固若金汤的护城河从芯片上电的第一刻起就确保了运行代码的完整性与真实性。简单来说Secure Boot HAB签名的核心目的就是让i.MX6ULL芯片只执行经过你或你的公司授权签名的固件。任何未经签名或签名验证失败的固件在启动初期就会被芯片内部的ROM代码拦截从而从根本上杜绝了运行恶意代码的可能性。这对于防止产品被克隆、固件被逆向、以及抵御通过固件注入进行的攻击至关重要。整个过程完全在芯片内部完成不依赖操作系统实现了硬件级的安全信任根。2. HAB安全启动原理与架构深度解析要玩转HAB首先得理解它背后的公钥基础设施PKI模型和启动流程。i.MX6ULL芯片内部有一段出厂即固化的ROM代码这段代码是芯片启动后最先执行的其职责之一就是验证后续加载的镜像如Bootloader的签名。这个验证过程依赖于我们预先烧录到芯片OTP熔丝中的公钥哈希即SRK Hash。2.1 信任链的建立从SRK到CSF整个信任链的起点是一组称为“超级根密钥Super Root Key, SRK”的密钥对。在实际应用中我们通常会生成一个包含多个公钥的SRK表比如4对RSA密钥然后取这个表的SHA-256哈希值。这个哈希值就是最终要烧录到芯片熔丝中的“SRK Hash”。一旦烧录就无法更改它定义了芯片所信任的根。当芯片启动时ROM代码会用熔丝中的SRK Hash去验证我们附加在镜像上的“签名块Signature Block”中的SRK表哈希值。如果匹配说明SRK表可信。接着ROM代码会用SRK表中的公钥去验证“命令序列文件Command Sequence File, CSF”的签名。CSF是一个包含了一系列HAB命令的脚本它指导ROM代码如何验证镜像本身如u-boot.bin的签名。CSF本身由SRK表中的某个私钥签名。最后ROM代码执行CSF中的命令使用CSF中指定的公钥来自SRK表去验证实际应用程序镜像即APP如u-boot的签名。只有所有验证步骤都通过芯片才会跳转到APP执行否则将进入安全启动失败状态通常表现为无法启动或进入下载模式。2.2 镜像组成结构IVT、Boot Data、DCD与APP一个完整的、可被HAB验证的镜像文件其结构比普通的二进制文件要复杂。它必须包含以下部分并按固定偏移地址排列镜像向量表Image Vector Table, IVT这是ROM代码寻找的入口点。IVT中包含了其他关键组件的地址指针如程序入口点、DCD地址、Boot Data地址以及最重要的——CSF地址。没有有效的IVTROM代码无法进行后续操作。Boot Data包含镜像的起始地址和长度信息。设备配置数据Device Configuration Data, DCD这是一系列配置命令用于在APP运行前初始化DDR等关键外设。因为ROM代码运行时DDR尚未初始化而验证APP需要将其加载到DDR中所以DCD的初始化必须在验证APP之前完成。DCD本身不需要签名。命令序列文件CSF如前所述包含验证命令的脚本。应用程序APP即我们需要保护的主要固件如U-Boot。这些组件通过一个叫imx-mkimage的工具打包成一个最终的可启动镜像如imx6ull-ahab-spl.bin。签名过程则是在这个打包后的镜像上附加签名块来完成的。注意理解IVT、DCD、CSF和APP在内存中的布局和加载顺序是解决很多签名失败问题的关键。一个常见的错误是DCD初始化不正确导致DDR无法使用进而使得ROM代码无法将镜像加载到预期地址进行验证。3. 密钥生成与证书链准备实操在开始签名之前我们必须准备好一套PKI密钥和证书。NXP提供了用于开发的cstCode Signing Tool工具来协助完成这些工作。这里我强烈建议在Linux环境下操作因为相关脚本和工具链支持最好。3.1 使用cst工具生成密钥对首先需要从NXP官网下载cst工具包。解压后其keys目录下包含示例密钥和配置文件。但为了安全我们必须生成自己的密钥。编辑hab4_pki_tree.sh脚本进入cst的keys目录你会找到hab4_pki_tree.sh脚本。在运行前需要编辑它来定义密钥参数。cd /path/to/cst/keys vi hab4_pki_tree.sh关键参数修改PKI_TREE./hab4_pki_tree # 密钥输出目录 CA_KEYca.key # 可改为自己的文件名 CA_CERTca.crt SRK_COUNT4 # SRK密钥数量通常为4 KEY_LENGTH2048 # RSA密钥长度2048或4096 HASHsha256 # 哈希算法运行脚本生成PKI树执行脚本它会生成一个完整的证书链目录hab4_pki_tree。./hab4_pki_tree.sh执行过程中会要求为CA证书和各个SRK证书输入国家、组织等信息。对于开发和测试可以一路回车使用默认值。但对于生产环境这些信息必须认真填写。获取SRK Hash生成完成后在hab4_pki_tree目录下会有一个SRK_1_2_3_4_table.bin文件。这个文件包含了4个SRK公钥。我们需要它的哈希值来烧录熔丝。cd hab4_pki_tree # 使用cst工具生成哈希 ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e 0x61000000 -d sha256 -c SRK_1_2_3_4_table.crt命令执行后会输出SRK表的SHA-256哈希值这是一个64位的十六进制字符串。请务必妥善保存这个哈希值它就是最终的“熔丝指纹”。3.2 准备cst工具所需的配置文件cst工具需要两个关键的配置文件来执行签名操作hab4_csf_example.cnf用于签名CSF和hab4_imx6ull_example.cnf用于签名APP镜像。我们需要根据实际镜像信息修改它们。以hab4_imx6ull_example.cnf为例关键修改项[Authenticate Data] Verification index 2 # 对应SRK表中的密钥索引0-3 Blocks 0x877ff400 0x0 0x50000 “u-boot.imx” # 这是最易错的部分这里的Blocks参数定义了需要签名的内存区域。格式为起始地址 偏移量 长度 “文件名”。起始地址镜像被加载到DDR中的运行时地址。这必须与U-Boot链接地址CONFIG_SYS_TEXT_BASE以及IVT中指定的入口地址完全一致。偏移量签名数据在文件内的起始偏移。对于完整的u-boot.imx已包含IVT、DCD等通常为0。长度需要签名的数据长度。可以使用0x0让cst自动计算文件长度。文件名待签名的镜像文件。实操心得Blocks参数配置错误是导致“HAB failure: 0x33”等验证错误的最常见原因。务必使用hexdump或objdump工具确认你的u-boot.imx镜像的IVT入口地址和实际代码段地址。一个快速检查方法是用文本编辑器打开u-boot.imx搜索字节序列“D1 00 20 40”IVT头部魔术字其后的4字节就是IVT自身的地址。4. U-Boot与Linux内核的编译与适配要让U-Boot支持HAB需要在编译时开启相关配置并确保链接地址与镜像配置匹配。4.1 配置与编译支持HAB的U-Boot获取U-Boot源码使用NXP官方提供的uboot-imx仓库或确保你使用的版本包含i.MX6ULL的HAB支持。配置编译选项make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- mx6ull_14x14_evk_defconfig # 使用你的板级配置 make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- menuconfig在配置界面中需要确保以下选项被启用ARM architecture - Enable support for i.MX6/7 HAB authentication(CONFIG_IMX_HAB)检查CONFIG_SYS_TEXT_BASE的值它定义了U-Boot的链接地址必须与后续签名配置中的地址一致。编译U-Bootmake ARCHarm CROSS_COMPILEarm-linux-gnueabihf-编译完成后会生成u-boot.bin原始二进制和u-boot.imxi.MX专用格式。我们需要的是u-boot.imx因为它已经由imx-mkimage工具处理包含了IVT、DCD等头部信息。4.2 使用imx-mkimage生成最终镜像有时板级配置可能需要我们手动使用imx-mkimage工具来打包镜像。这个过程需要你的U-Boot源码目录中存在imx-mkimage子目录或单独下载该工具。准备组件将编译好的u-boot.bin、对应的DCD配置文件如mx6ullevk.cfg和IVT模板文件拷贝到imx-mkimage的iMX6ULL目录下。修改配置文件在imx-mkimage的cfg文件或脚本中确保APP_BASE应用程序基址与U-Boot的CONFIG_SYS_TEXT_BASE一致。执行打包cd /path/to/imx-mkimage make SOCiMX6ULL flash_evk # 根据你的板子类型选择target完成后会在当前目录生成imx6ull-ahab-spl.bin或类似名称的文件这个就是等待签名的最终镜像。将其重命名为u-boot.imx以供cst工具使用。5. 执行签名与生成可烧录镜像当密钥、配置文件和待签名镜像都准备好后就可以使用cst工具进行签名了。5.1 使用cst工具进行签名签名CSF区域首先我们需要为CSF本身生成一个签名块。CSF在镜像中是一个预留的空区域。cd /path/to/your/workdir cp /path/to/cst/linux64/bin/cst . cp /path/to/cst/keys/hab4_pki_tree/*.pem . # 拷贝生成的密钥对 cp /path/to/cst/crts/hab4_csf_example.cnf ./csf.cnf # 拷贝并修改好的CSF配置文件 cp u-boot.imx u-boot_unsigned.imx # 备份原始镜像编辑csf.cnf确保[Authenticate Data]部分的Blocks指向你的u-boot_unsigned.imx文件并正确设置CSF在镜像中的偏移地址通常紧跟DCD之后这个偏移地址在imx-mkimage的链接脚本或IVT中有定义。./cst -i csf.cnf -o csf.bin此命令会生成csf.bin即签名后的CSF数据块。将CSF块插入镜像我们需要将csf.bin合并到u-boot_unsigned.imx的指定偏移处。这个偏移地址就是csf.cnf中[Authenticate Data]里Blocks的起始地址。dd ifcsf.bin ofu-boot_unsigned.imx seek$((0xCSF_OFFSET)) bs1 convnotrunc将0xCSF_OFFSET替换为实际的CSF偏移量十进制或十六进制。执行后u-boot_unsigned.imx就变成了一个包含CSF数据的中间镜像。签名应用程序APP现在我们来签名整个镜像包括IVT、DCD、CSF和APP。cp /path/to/cst/crts/hab4_imx6ull_example.cnf ./app.cnf编辑app.cnf确保[Authenticate Data]的Blocks参数正确指向你刚刚插入CSF后的u-boot_unsigned.imx文件并且起始地址是APP的加载地址。./cst -i app.cnf -o app_sign.bin此命令会生成app_sign.bin这是针对APP的签名块。生成最终镜像最后将APP的签名块追加到镜像文件末尾。HAB机制规定签名块位于镜像文件的尾部。cat u-boot_unsigned.imx app_sign.bin u-boot_signed.imx现在u-boot_signed.imx就是一个完整的、经过HAB签名的、可以被i.MX6ULL安全启动验证的U-Boot镜像了。5.2 验证签名镜像的完整性在烧录到设备前可以使用cst工具模拟验证一下./cst -V -i u-boot_signed.imx -o /dev/null如果配置正确这个命令会输出验证成功的信息。但这只是本地文件验证最终验证需要由芯片ROM代码在启动时完成。6. 熔丝烧写与硬件安全配置这是最关键也最危险的一步。熔丝一旦烧写绝大多数都无法逆转。务必在开发阶段使用开放Open配置进行测试即不烧写SRK Hash让HAB处于警告模式但不禁用启动。6.1 理解熔丝位图i.MX6ULL的HAB相关熔丝主要位于银行0Bank0的单词6、7和银行1Bank1的单词3。我们需要关注SRK_HASH[255:0]存储SRK表的SHA-256哈希值。分布在多个熔丝单词中。SEC_CONFIG[1]这是安全配置位。将其烧写为1会使芯片进入“关闭Closed”安全状态。在此状态下如果HAB验证失败芯片将不会启动。DIR_BT_DIS直接启动禁用位。在安全状态关闭时必须将其烧写为1以禁用UART/USB等串行下载模式防止绕过安全启动。6.2 使用U-Boot命令进行熔丝烧写开发测试在开发阶段我们可以先不烧SRK_HASH只将芯片设为“开放”状态进行测试。通过串口下载一个未签名的U-Boot到RAM中运行然后在这个U-Boot环境下操作熔丝。进入U-Boot命令行通过串口工具连接到板子在启动时打断自动引导进入U-Boot命令行。读取当前熔丝值 fuse read 0 6 # 读取Bank0 Word6 fuse read 0 7 # 读取Bank0 Word7 fuse read 1 3 # 读取Bank1 Word3记录下原始值。烧写SRK_HASH生产前最后一步 fuse prog 0 6 0x12345678 # 烧写SRK_HASH[31:0]替换为你的哈希值第一部分 fuse prog 0 7 0x9abcdef0 # 烧写SRK_HASH[63:32]替换为你的哈希值第二部分 # ... 继续烧写剩余部分具体分布在哪些单词需参考芯片参考手册警告此操作不可逆务必先在小批量板卡或评估板上验证签名镜像完全正确后再操作。烧写安全配置位进入“关闭”状态 fuse prog 1 3 0x00000002 # 设置SEC_CONFIG[1]1 (bit1)同时确保DIR_BT_DIS也被设置具体bit位需查手册烧写后芯片重启即进入安全启动强制验证模式。致命注意事项在烧写SEC_CONFIG[1]之前必须确保正确的SRK_HASH已经烧录。你拥有并使用对应的私钥签名的、可启动的完整镜像U-Boot。该镜像已经通过不烧熔丝的方式测试启动成功。 否则芯片将永久变砖无法通过任何常规手段恢复。7. 调试、验证与故障排查实录即使按照步骤操作也难免会遇到HAB验证失败的情况。芯片在上电时会通过状态寄存器记录HAB事件。我们可以通过工具或U-Boot命令来读取这些状态进行诊断。7.1 使用NXP提供的hab_status工具在U-Boot命令行中如果U-Boot已成功启动并支持HAB可以运行hab_status命令具体命令可能为hab_status或通过mxc_hab命令调用。 hab_status该命令会解析芯片内部的HAB状态寄存器并输出人类可读的事件信息。这是最直接的调试手段。7.2 常见HAB故障代码与解决方法以下是一些常见的HAB事件代码及其可能的原因和排查方向事件代码 (HEX)含义可能原因与排查方向0x33“CSF not authenticated”最常见错误。CSF签名验证失败。检查1.csf.cnf中[Authenticate Data]的Blocks地址和文件是否正确。2. 用于签名CSF的私钥是否与烧录的SRK Hash对应的公钥匹配。3. CSF数据在镜像中的偏移地址是否正确。0x35“CSF contains invalid command”CSF命令序列文件本身格式错误或包含ROM代码不支持的命令。检查csf.cnf文件的语法特别是命令参数。0x36“CSF contains unsupported command”同上使用了当前芯片ROM版本不支持的HAB命令。0x3A“SRK not valid”烧录的SRK Hash与镜像中SRK表的哈希值不匹配。检查1. 烧录的熔丝值是否正确。2. 生成SRK Hash的SRK_1_2_3_4_table.bin文件是否与签名时使用的完全一致。0x66“Image authentication failure”APPU-Boot镜像签名验证失败。检查1.app.cnf中Blocks指定的内存地址、文件偏移和长度是否正确。2. 用于签名APP的私钥索引Verification index是否正确。3. 镜像文件在签名后是否被意外修改。0x69“DCD failure”DCD初始化失败。这发生在验证APP之前。检查1. DCD配置数据是否正确特别是DDR参数是否与你的板载内存颗粒完全匹配。2. DCD在镜像中的位置和长度是否正确。7.3 开发阶段的调试流程开放模式测试首先在不烧写任何安全熔丝的情况下测试签名镜像是否能正常启动。使用hab_status查看是否有警告事件警告不会阻止启动。这能验证签名流程本身是否正确。逐步烧写熔丝不要一次性烧写所有熔丝。可以先烧写SRK_HASH但保持SEC_CONFIG[1]为0开放状态。此时如果签名错误芯片仍会启动并报告HAB失败事件但不会变砖。这是安全的测试阶段。对比测试准备一个已知良好的未签名镜像和一个签名镜像在开放模式下交替测试观察hab_status输出的差异。使用仿真器或调试器对于复杂的DCD初始化失败问题可能需要借助JTAG调试器单步跟踪ROM代码的执行查看在DCD执行阶段寄存器的配置值。8. 生产流程与密钥安全管理建议当开发调试完成准备将方案投入生产时密钥的安全管理就成为了重中之重。8.1 建立分级密钥体系绝对不要使用开发测试的密钥对进行生产。建议建立以下分级体系主根密钥Master SRK在高度安全的离线环境中生成和存储。仅用于签署下一级的“生产签发密钥Production Issuing Key, PIK”证书。生产签发密钥PIK由主根密钥签名。可以在相对安全的签名服务器上使用用于签署最终的产品镜像CSF和APP。即使PIK泄露只要主根密钥安全就可以通过撤销PIK证书需要芯片支持并预置吊销列表来应对。镜像签名密钥Image Signing Key对于大型项目甚至可以进一步细分使用不同的密钥对为不同型号、不同版本的产品签名。8.2 安全的签名环境生产环境的签名操作应在专用的、空气隔离的签名服务器上进行。该服务器无网络连接。访问需要多重物理和逻辑认证。操作过程有完整审计日志。私钥以硬件安全模块HSM或智能卡的形式存储确保私钥永不离开安全硬件。8.3 生产烧录流程生成黄金镜像在安全环境中使用生产PIK对最终发布的固件进行签名生成“黄金镜像”。烧录熔丝在生产线上的烧录工站通过专用夹具和烧录器将对应的SRK_HASH来自主根密钥生成的SRK表烧录到每一颗芯片中。此工站必须与互联网物理隔离。烧录镜像将黄金镜像烧录到设备的存储介质eMMC, NAND, SD卡中。功能测试与安全验证设备首次上电应能正常启动。可以通过预留的调试接口在开放了相应权限的情况下读取hab_status确认所有验证事件为“0x00”HAB成功。同时进行基本功能测试。8.4 应对密钥泄露的预案尽管硬件安全模块能极大降低风险但仍需有预案密钥轮换计划为产品规划多个SRK插槽i.MX6ULL支持最多4个。在新批次产品中可以烧录包含新SRK公钥的哈希表旧密钥依然保留但不再使用。这样即使旧密钥泄露新批次产品也不受影响。证书吊销列表CRL更高级的方案是在CSF中引入证书吊销列表。如果某个签名密钥泄露可以将其加入CRL芯片在验证时会检查CRL并拒绝被吊销密钥签名的镜像。但这需要更复杂的PKI管理和镜像设计。为i.MX6ULL实现Secure Boot HAB签名是一个系统工程从密码学原理、工具链使用到硬件操作环环相扣。最大的体会是严谨和测试至关重要。尤其是在熔丝烧写环节一定要遵循“先开放测试再关闭验证”的流程任何一步的疏忽都可能导致硬件报废。另外妥善保管你的私钥其重要性不亚于产品源代码。一旦投入量产这套安全启动机制就将默默守护每一台设备的启动安全成为产品坚固的安全基石。