1. 项目概述为什么NPU固件开发绕不开安全启动最近在折腾一个基于Linux的NPU神经网络处理单元固件开发项目当我把编译好的固件镜像烧录到板子上准备启动测试时系统直接给我弹了个“Verification Failed”的错误启动流程直接卡死。那一刻我才深刻体会到在嵌入式系统尤其是涉及AI算力的NPU设备上“安全启动”不是一个可选项而是保障设备从第一行代码开始就值得信赖的生命线。这不仅仅是防止恶意固件刷入那么简单它关乎整个设备的数据安全、模型隐私和系统完整性。简单来说安全启动是一套在设备上电后、执行主程序之前对即将运行的每一段代码包括Bootloader、操作系统内核、驱动模块乃至我们开发的NPU固件进行密码学验证的机制。它的核心目标是建立一个从硬件信任根开始的、不可篡改的信任链。对于NPU设备而言这意味着你训练好的AI模型、处理的敏感数据如人脸、语音其运行环境从启动瞬间就是经过认证的有效抵御了固件层面的攻击比如植入后门、窃取模型权重等。本讲作为“手把手教你学基于Linux的NPU固件开发”系列的延续将深入剖析安全启动的原理并聚焦于最让开发者头疼的环节——密钥管理。我会结合在ARM架构常见于NPU SoC上的实操经验带你理解从原理到落地的完整流程包括如何生成密钥、部署密钥到硬件、签名固件镜像以及处理那些令人抓狂的“安全启动失败”问题。2. 安全启动核心原理与信任链构建安全启动并非一个单一的功能而是一个环环相扣的信任传递过程我们称之为“信任链”。理解这条链是如何工作的是进行任何相关开发的基础。2.1 信任根一切安全的起点信任链的源头必须是绝对可信的这就是“硬件信任根”。它通常是一段被固化在芯片ROM中的、出厂后无法修改的代码也称为ROM Bootloader。这段代码的唯一职责就是验证下一级引导程序通常是Flash中的Bootloader的签名。它的工作流程芯片上电后首先执行ROM代码。ROM代码会从指定的存储介质如eMMC、SPI NOR Flash中读取第一阶段Bootloader的镜像。在读取之后、跳转执行之前ROM代码会使用其内部预置的公钥或公钥哈希值去验证Bootloader镜像的数字签名。如果验证通过说明该Bootloader镜像来自合法的发布者且未被篡改ROM代码才会将控制权移交给它。如果验证失败则启动过程终止设备进入安全恢复模式或直接变砖。注意这个预置在ROM中的公钥或哈希值是芯片制造商在流片时烧录进去的一旦芯片出厂就无法更改。因此选择哪家芯片某种程度上也选择了你信任的根证书颁发者。在自研高端设备时可能需要与芯片原厂合作定制化烧录自己的根密钥哈希。2.2 信任传递链式验证的延伸当第一阶段Bootloader获得执行权后它便成为了“被信任的代码”。它的任务之一就是延续这个信任过程。验证第二阶段Bootloader或设备树一个复杂的系统可能有多个阶段的Bootloader如U-Boot的SPL和U-Boot Proper。第一阶段Bootloader在加载下一阶段程序时同样需要先验证其签名。验证Linux内核与Initramfs最终Bootloader会加载Linux内核镜像和可选的初始内存文件系统。在启动内核前Bootloader会调用其内部的验证程序使用约定的公钥去验证这些镜像的签名。只有签名有效的内核才会被启动。内核模块验证Linux内核本身也可以开启模块签名验证功能。这意味着不仅内核本身所有后续动态加载的内核模块比如NPU驱动模块也需要经过签名验证否则将被拒绝加载。这对于防止通过加载恶意驱动来攻击系统至关重要。对于NPU固件其验证点可能位于两个环节作为内核模块如果NPU固件以.ko驱动模块形式存在则受内核模块签名验证机制保护。作为独立的固件镜像如果NPU有独立的协处理器其固件可能由Bootloader或内核中的某个守护进程在加载前进行验证。2.3 密码学基础签名与验证整个过程依赖于非对称加密技术主要是RSA或ECC算法。密钥对开发方生成一对密钥一个私钥和一个公钥。私钥必须绝对保密存放在安全的离线环境中用于对固件镜像进行签名。公钥则可以公开需要被写入到设备的可信存储区如efuse或OTP中供验证方使用。签名过程对固件镜像计算一个哈希值如SHA256得到唯一的“数字指纹”。然后用私钥对这个指纹进行加密生成的结果就是“数字签名”。签名会附加在原始镜像的末尾或单独存放。验证过程验证方ROM或Bootloader拥有公钥。它首先计算接收到镜像的哈希值然后用公钥去解密附带的签名得到原始的哈希值。最后对比两个哈希值是否一致。如果一致则证明1. 镜像在签名后未被修改2. 该签名是由持有对应私钥的实体生成的。这种机制的精妙之处在于公钥无法推导出私钥因此即使攻击者拿到了设备中的公钥也无法伪造出能通过验证的签名。3. 密钥管理安全启动中最关键的实践原理清晰后最大的挑战来自于工程实践而密钥管理是核心中的核心。管理不当轻则导致开发不便重则造成密钥泄露或设备无法启动的灾难性后果。3.1 密钥的生成与分类在开发初期我们就需要规划好密钥体系。一个典型的项目至少需要两套密钥PKPlatform Key平台密钥这是最高级别的密钥用于签名KEK密钥加密密钥和吊销证书。在UEFI Secure Boot规范中常见在一些嵌入式场景中它可能直接就是被烧录到硬件中的根密钥。KEKKey Exchange Key密钥加密密钥用于签名下一级的签名密钥如db密钥。它提供了密钥更新的灵活性。DBSignature Database签名数据库密钥这是直接用于签名可执行代码如Bootloader、内核的密钥。我们开发中打交道最多的就是它。DBXRevoked Signature Database吊销签名数据库用于吊销已被破解或泄露的密钥对应的签名。对于许多嵌入式Linux项目特别是使用U-Boot和内核的fitImage格式的场景我们通常简化处理一个“签名密钥”用于对所有需要验证的镜像U-Boot、内核、设备树进行签名。一个“加密密钥”如果镜像需要加密较少用则会用到。生成密钥可以使用OpenSSL工具链。例如生成一个RSA-2048的密钥对和自签名证书# 生成一个2048位的RSA私钥 openssl genrsa -out private_key.pem 2048 # 从私钥中提取出公钥 openssl rsa -in private_key.pem -pubout -out public_key.pem # 可选生成一个包含公钥的X509证书可用于更规范的管理 openssl req -new -x509 -key private_key.pem -out cert.pem -days 36503.2 密钥的安全存储策略私钥的安全是生命线。绝对不要将私钥放入代码仓库或随镜像一起分发。开发环境硬件安全模块最安全的方式是使用HSM但成本高。离线机器准备一台永不联网的物理机专门用于签名操作。所有私钥仅存放在这台机器的加密磁盘上。加密存储如果必须在开发机上存储使用gpg等工具对私钥文件进行强密码加密。生产环境密钥注入在生产线上需要将公钥或公钥哈希烧录到设备的OTP或efuse中。这个过程通常由产线工具配合芯片厂商的烧录工具完成。烧录后该硬件位置即被锁定无法再次写入。私钥保管用于发布生产固件的私钥应遵循最高级别的安全协议可能由多个负责人分段保管Shamir‘s Secret Sharing或使用专业的密钥管理服务。3.3 密钥轮换与吊销预案密钥不可能永久使用需要考虑泄露或到期后的轮换。设计多套密钥在硬件efuse中可以设计为支持存储多个公钥哈希如PK1 PK2。当前使用PK1当需要轮换时用PK2签名的新固件同样可以被接受。这需要Bootloader支持多密钥验证。吊销机制通过DBX吊销列表。如果某个签名密钥如DB1泄露可以用更高级别的密钥KEK签发一个包含DB1标识的吊销证书并将其更新到设备的DBX中。此后所有用DB1签名的镜像将无法通过验证。关键在于吊销列表本身也需要被签名。重要原则在烧录第一个根公钥哈希到硬件之前必须完成整个密钥生命周期管理的设计否则后期将无法更新和吊销留下永久性风险。4. 基于U-Boot与Linux内核的实操流程下面我们以一个典型的ARM NPU开发板为例展示如何为U-Boot和Linux内核启用安全启动并进行签名。4.1 配置与编译支持安全启动的U-Boot首先需要确保U-Boot配置了相关选项。# 进入U-Boot源码目录 cd u-boot # 使用你的板级配置文件这里以my_npu_board为例 make my_npu_board_defconfig # 进入菜单配置界面开启关键选项 make menuconfig在menuconfig中需要找到并开启ARM architecture-Enable ARM Trusted Firmware (ATF)如果SoC使用了ATF作为安全世界固件Boot images-Enable signature verification of FIT uImagesFIT是U-Boot常用的镜像封装格式Boot images-Enable signature verification of configuration nodes验证FIT内的配置节点Security support-Enable RSA library/Enable RSA verification提供RSA算法支持可能还需要开启SHA256、SHA512等哈希算法支持。配置完成后编译U-Bootmake -j$(nproc)编译产物中我们主要关注u-boot.bin原始二进制和u-boot.dtb设备树。4.2 创建FIT镜像并签名U-Boot通常不直接验证原始的u-boot.bin或Image而是验证一个叫做FITFlattened uImage Tree的容器镜像它内部可以封装多个组件内核、设备树、ramdisk等及其描述信息。编写FIT描述文件创建一个.its文件例如image.its。/dts-v1/; / { description NPU Board FIT Image; #address-cells 1; images { kernel1 { description Linux Kernel; data /incbin/(./arch/arm64/boot/Image); type kernel; arch arm64; os linux; compression none; load 0x80080000; entry 0x80080000; hash1 { algo sha256; }; }; fdt1 { description Device Tree Blob; data /incbin/(./arch/arm64/boot/dts/my_npu_board.dtb); type flat_dt; arch arm64; compression none; hash1 { algo sha256; }; }; }; configurations { default conf1; conf1 { description Standard Boot; kernel kernel1; fdt fdt1; signature1 { algo sha256,rsa2048; key-name-hint dev_key; }; }; }; };使用mkimage工具打包并签名假设你的私钥文件是dev_key.pem私钥和dev_key.crt证书。# 首先将编译好的内核Image和设备树dtb文件放到当前目录 cp ../linux/arch/arm64/boot/Image ./ cp ../linux/arch/arm64/boot/dts/my_npu_board.dtb ./ # 使用mkimage生成FIT镜像并进行签名 mkimage -f image.its -k ./keys -K u-boot.dtb -r image.fit-f image.its: 指定输入描述文件。-k ./keys: 指定存放密钥的目录包含dev_key.pem和dev_key.crt。-K u-boot.dtb:这是一个关键步骤。它会在U-Boot的设备树u-boot.dtb中自动追加一个包含公钥的节点/signature这样U-Boot在编译时就内置了公钥信息。-r: 表示创建可重定位的镜像适合某些加载地址不固定的场景。image.fit: 输出的已签名FIT镜像。4.3 配置Linux内核以验证模块签名为了让内核也能验证NPU驱动等模块的签名需要配置内核。cd linux-kernel make menuconfig在配置中开启Enable loadable module support-Module signature verification在Module signature verification子菜单下选择使用的哈希算法如SHA256和加密算法如RSA。可以配置Require modules to be validly signed强制要求所有模块必须签名或Allow modules with missing signatures仅警告。还需要指定内核编译使用的公钥。这通常通过CONFIG_SYSTEM_TRUSTED_KEYS配置项指定一个包含PEM格式公钥的文件路径。编译内核后使用相同的私钥对模块进行签名# 假设私钥为 signing_key.pem 证书为 signing_key.x509 # 首先编译模块 make modules # 安装模块到临时目录 make INSTALL_MOD_PATH/tmp/myroot modules_install # 使用内核脚本签名所有模块 perl ./scripts/sign-file sha256 ./signing_key.pem ./signing_key.x509 /tmp/myroot/lib/modules/$(uname -r)/kernel/drivers/npu/npu_driver.ko4.4 烧录与启动测试更新U-Boot将嵌入了公钥的u-boot.dtb与u-boot.bin合并或分别烧录到Flash的指定位置。烧录FIT镜像将image.fit烧录到Flash中内核所在的区域如0x80000偏移处。上电启动观察串口日志。如果配置正确U-Boot在加载FIT镜像时会打印验证信息Loading Kernel Image Verifying Hash Integrity ... sha256,rsa2048:dev_key OK“OK”字样表示签名验证通过。如果失败则会打印错误并停止启动。5. 常见问题排查与调试技巧实录在实际开发中安全启动失败是家常便饭。下面是一些典型问题及排查思路。5.1 签名验证失败现象U-Boot提示Bad Data Hash或Bad Signature。排查步骤确认密钥匹配检查烧录到设备efuse/OTP中的公钥哈希是否与用于签名的私钥对应的公钥哈希完全一致。使用openssl rsa -in private_key.pem -pubout -outform der | sha256sum计算公钥哈希与烧录值比对。检查签名算法确保U-Boot配置开启的算法如sha256,rsa2048与mkimage签名时使用的算法、以及.its文件中signature节点指定的算法三者完全一致。检查FIT镜像结构使用mkimage -l image.fit命令列出FIT镜像内容确认签名节点是否存在且信息正确。检查镜像完整性在.its文件中每个镜像kernel,fdt都必须有hash1节点。确保mkimage能正确读取到这些镜像文件并计算哈希。5.2 设备无法进入烧录模式变砖风险现象启用安全启动后由于Bootloader损坏或签名错误设备无法启动也无法通过常规方式如USB OTG进入烧录模式。预防与解决保留恢复机制在设计Bootloader时务必保留一个不受安全启动验证的恢复模式入口。例如通过检测某个GPIO引脚的电平如Recovery键或串口发送特定字符在启动初期跳过验证进入可重新烧录的恢复模式。使用JTAG这是最后的救命稻草。通过JTAG接口可以直接连接芯片擦除Flash或重新烧录Bootloader。但这需要硬件接口和专业的调试器。分阶段启用在开发调试阶段可以先在软件中启用验证并打印日志但不要真正烧录efuse锁定。等所有流程稳定后再最后一步烧录efuse。5.3 内核模块加载失败现象insmod加载NPU驱动时提示Required key not available或module verification failed。排查步骤查看内核日志dmesg | grep -i module查看具体错误。确认内核公钥检查编译内核时配置的公钥文件是否与签名模块使用的私钥配对。内核启动日志中通常会打印加载的公钥信息。检查模块签名使用modinfo npu_driver.ko查看模块的签名信息。使用hexdump -C npu_driver.ko | tail -50可以粗略看到模块尾部的签名数据是否存在。检查内核配置确认没有错误地配置为CONFIG_MODULE_SIG_FORCE强制验证而公钥又不对。5.4 性能影响考量启用安全启动特别是验证大型内核镜像时会带来一定的启动时间延迟。主要耗时在哈希计算和RSA解密验证上。优化建议使用更强的硬件选择带有密码学硬件加速引擎的SoC如ARM的CryptoCell可以极大提升验证速度。镜像压缩与哈希对镜像进行压缩如gzip验证前先解压。虽然增加了压缩/解压时间但减少了需要计算哈希的数据量有时整体更快。信任链缓存对于已验证过的、静态的镜像可以将验证结果缓存起来下次启动时跳过验证需谨慎评估安全风险。安全启动是NPU乃至所有嵌入式设备迈向安全可信的基石。它把安全防线提到了固件层让攻击者难以在系统底层植入恶意代码。整个过程就像建造一座城堡信任根是地基签名验证是每一块砖的质检报告而密钥管理则是保管城堡设计图和钥匙的绝密室。虽然初上手会觉得繁琐但一旦流程跑通并将其集成到CI/CD管道中它就会成为固件发布中坚实而自动化的一环。在AIoT时代数据与模型的安全价值日益凸显在NPU固件开发中打好安全启动这根桩无疑是给整个产品系上了第一道安全带。