RK3588+Linux固件签名与系统安全开发全指南

在高端嵌入式场景中，RK3588凭借8nm制程、6TOPS NPU算力及8K多媒体处理能力，成为AIoT、边缘计算的热门选择。而安全启动（Secure Boot）作为设备防护的第一道防线，是保障RK3588平台稳定运行的核心。本文结合瑞芯微官方文档与RK3588实测数据，聚焦官方build.sh指令集，从环境配置、密钥生成、固件签名到第三方系统适配，完整拆解安全开发流程，同时分享实测踩坑经验，确保方案可直接落地。

一、核心认知：RK3588安全启动关键特性

RK3588作为瑞芯微旗舰级芯片，其安全启动机制基于FIT方案（官方推荐，支持灵活镜像校验），核心特性如下：

1.硬件可信根：公钥哈希固化于OTP（不可逆熔断），作为校验起点，防止固件篡改；

2.分层校验链路：Bootrom→Loader→U-Boot→Kernel→系统，任一环节校验失败则终止启动；

3.安全存储支持：默认使用RPMB（eMMC物理安全分区）存储加密密钥，非eMMC设备可启用Security逻辑分区；

4.系统安全增强：支持System-Verity（系统校验）与System-Encryption（系统加密），适配EXT4等主流文件系统。

二、基础准备：环境与指令前置说明

1.环境要求

•硬件：RK3588开发板（如EVB7 V11），确保OTP引脚（VCC_18）供电稳定；

•软件：Linux SDK（本文基于rk3576 linux6.1）、OpenSSL、瑞芯微升级工具（upgrade_tool）；

•系统：目标第三方系统为Debian（本文以debian/linaro-rootfs.img为例）。

2.核心指令约定

本文所有操作基于SDK根目录下的官方build.sh指令，无需额外添加非官方脚本，指令格式及功能以./build.sh -h输出为准，关键指令分类如下：

指令类型	核心指令示例	作用
配置类	./build.sh menuconfig	图形化配置SDK安全参数
密钥生成类	./build.sh security-createkeys	生成安全启动所需RSA密钥对
固件编译类	./build.shuboot./build.sh kernel	编译签名Loader、U-Boot、Kernel
安全系统类	./build.sh security-system	生成加密/校验后的系统镜像
镜像打包类	./build.sh updateimg	打包完整可烧录固件（update.img）
清理类	./build.sh clean:security	清理安全相关编译产物

三、分步实战：基于build.sh的安全开发流程

1.第一步：SDK安全配置（关键前置）

通过menuconfig开启安全功能，确保后续编译指令生效：

# 进入SDK根目录，启动图形化配置界面make menuconfig

在配置菜单中按以下路径勾选关键选项（RK3588默认FIT方案）：

->RK_SECURITY (安全功能总开关) ->[*] security feature (启用安全功能) ->Secureboot Method (FIT) -> 选中FIT（RK3588官方推荐） ->Optee Storage (RPMB) -> 选中RPMB（eMMC设备默认，Flash设备选SECURITY） ->security check method -> 按需选择（system-verity=系统校验，system-encryption=系统加密） ->[ ] burn security key (默认关闭，调试阶段不熔断OTP，量产时再开启) ->RK_SECURITY_INITRD_BASE_CFG (自动勾选，生成安全Ramdisk)

配置完成后保存退出，SDK会自动生成output/.config文件（若提示文件过时，按提示确认更新即可）。

2.第二步：生成安全密钥（仅需执行一次）

使用官方指令生成RSA密钥对（密钥丢失将导致设备变砖，务必备份）：

# 生成签名用密钥（自动存储于u-boot/keys目录）./build.sh security-createkeys

指令执行后，在u-boot/keys目录下生成3个核心文件：

•dev.key：私钥（签名用，需离线备份）；

•dev.pubkey：公钥（验签用，编译时自动嵌入固件）；

•dev.crt：自签名证书（等效于公钥，用于FIT镜像校验）。

踩坑提示：若执行时报错“Can't load ~/.rnd into RNG”，需手动创建随机数文件：

touch~/.rnd

3.第三步：编译签名核心固件（Loader/U-Boot/Kernel）

RK3588的Loader（含SPL）、U-Boot需编译时签名，Kernel需开启安全模块支持，均通过build.sh指令完成：

（1）编译签名Loader与U-Boot

Loader是Bootrom校验的第一个固件，必须签名；U-Boot需关联密钥并支持FIT校验：

# 编译Loader（含SPL）与U-Boot，开启防回滚（版本号1，可自定义）./build.sh loader --spl-new --rollback-index-uboot 1

•--spl-new：使用当前编译的SPL（含公钥）打包Loader，RK3588必须添加（官方SDK无预编译安全SPL）；

•--rollback-index-uboot 1：设置U-Boot防回滚版本号（需与menuconfig中“防回滚”配置匹配，不开启防回滚可省略）。

编译成功后，在output/firmware目录生成已签名的loader.bin、uboot.img。

（2）编译支持安全模块的Kernel

Kernel需开启Device-Mapper（系统校验/加密依赖）与OPTEE（密钥存储依赖），通过指令直接编译：

# 编译Kernel（自动加载menuconfig中配置的安全模块）./build.sh kernel# 编译Kernel模块（若需驱动适配，可选执行）./build.sh modules

关键安全模块（已在menuconfig中开启，无需额外配置）：

•CONFIG_BLK_DEV_DM=y：启用Device-Mapper；

•CONFIG_DM_VERITY=y/CONFIG_DM_CRYPT=y：支持系统校验/加密；

•CONFIG_TEE=y/CONFIG_OPTEE=y：启用OPTEE可信执行环境。

编译完成后，在kernel/arch/arm64/boot/目录生成Image（内核镜像）与dtbs/rockchip/rk3588-evb7-v11.dtb（设备树）。

4.第四步：生成安全Ramdisk（系统启动关键）

Ramdisk是中间小系统，负责启动时解密/校验目标系统，通过官方指令编译：

# 生成适配安全启动的Ramdisk（自动集成veritysetup/dmsetup工具）./build.sh security-ramboot

指令会基于Buildroot生成rootfs.cpio.gz（Ramdisk镜像），存储于buildroot/output/rockchip_rk3588_ramboot/images/目录，且自动关联menuconfig中配置的安全参数（如加密算法、密钥存储路径）。

5.第五步：第三方系统（Debian）安全处理

RK3588官方build.sh支持第三方系统适配，以Debian为例，需先对系统镜像加密/校验，再打包签名：

（1）处理Debian系统镜像

# 进入固件输出目录cdoutput/firmware# 链接加密后的Debian镜像（替换默认rootfs）ln-rsf ../../debian/security_system.img rootfs.img# 打包完整可烧录固件update.imgcd../.../build.sh updateimg

•指令自动生成加密后的debian/security_system.img（密文落盘，需密钥解密）；

•同时生成debian/security.info，记录加密算法（如aes-cbc-plain）、密钥信息（暂存于misc分区，首次开机转存RPMB）。

若需系统校验（仅防篡改，明文落盘），需先在menuconfig中切换“security check method”为system-verity，再执行上述指令。

（2）关联系统镜像与打包固件

将加密后的Debian镜像链接到固件打包目录，生成完整update.img：

# 1. 重新配置SDK，开启密钥烧录./build.sh menuconfig-> RK_SECURITY -> [*] burn security key (勾选，启用OTP熔断)# 2. 重新编译Loader（触发密钥哈希烧录逻辑）./build.sh loader --spl-new --burn-key-hash

6.第六步：密钥烧录与固件刷写（量产关键）

（1）熔断OTP（仅量产执行，不可逆！）

调试阶段无需烧录密钥（避免设备变砖），量产前需开启密钥烧录功能并熔断OTP：

# 1. 重新配置SDK，开启密钥烧录./build.sh menuconfig-> RK_SECURITY -> [*] burn security key (勾选，启用OTP熔断)# 2. 重新编译Loader（触发密钥哈希烧录逻辑）./build.sh loader --spl-new --burn-key-hash

•--burn-key-hash：编译时添加该参数，首次开机时Loader会将公钥哈希写入OTP，完成熔断；

•熔断成功后，串口会打印“RSA: Write key hash successfully”。

（2）烧录固件到开发板

使用瑞芯微upgrade_tool工具烧录update.img：

# 烧录完整固件（开发板进入Maskrom模式）upgrade_tool uf output/firmware/update.img

四、实测验证：安全机制生效测试（基于RK3588）

通过替换未签名固件，验证安全机制是否生效，实测结果如下：

测试场景	操作方式	结果	关键现象
合法固件启动	烧录签名后的update.img	成功	串口打印“EXT4-fs (dm-0): mounted filesystem”，正常进入Debian系统
替换未签名rootfs.img	替换output/firmware/rootfs.img	失败	Kernel panic，提示“Attempted to kill init! exitcode=0x00000100”
替换未签名boot.img	替换output/firmware/boot.img	失败	停留在Loader模式，打印“Failed to verify required signature 'key-dev'”
替换未签名loader.bin	烧录未签名Loader	失败	开发工具不识别设备，无日志输出（OTP已熔断，拒绝未签名固件）
烧录未签名完整系统	烧录未签名update.img	失败	升级工具提示“下载Boot失败”，Maskrom模式下无法识别固件

替换非签名加密的rootfs之后，报错进不了系统

烧录回签名加密钥的之后，又成功进入系统

替换未签名的boot.img，密钥校验失败，进不了kernel，停留在loader模式

更新未签名uboot.img，校验失败，进不了uboot，还是进入maskrom模式

如果是替换没有签名的MiniLoaderAll.bin，烧录不了，芯片不识别，也没有log，因为密钥已经烧录到芯片otp中，固化在芯片了

如果烧录没有完全没有签名的整个系统，根本烧录不进去，根本原因还是MiniLoaderAll.bin没签名并且密钥已经烧录到芯片otp中，固化在芯片了

五、关键指令速查表与注意事项

1.核心指令速查表（官方build.sh指令）

操作目标	指令
开启图形化配置	./build.sh menuconfig
生成安全密钥	./build.sh security-createkeys
编译签名Loader/U-Boot	./build.sh loader --spl-new --rollback-index-uboot 1
编译Kernel	./build.sh kernel
生成安全Ramdisk	./build.sh security-ramboot
处理Debian系统	./build.sh security-system:debian/linaro-rootfs.img
打包完整固件	cd output/firmware && ./build.sh updateimg
熔断OTP（量产）	./build.sh loader --spl-new --burn-key-hash
清理安全编译产物	./build.sh clean:security

2.注意事项（实测踩坑总结）

1.密钥备份：u-boot/keys目录下的dev.key务必离线备份，OTP熔断后密钥丢失将导致设备变砖；

2.调试阶段不熔断OTP：未确认固件稳定性前，不要勾选“burn security key”，避免无法回滚；

3.Ramdisk日志调试：若系统跳转失败，需修改Ramdisk的init脚本，将MSG_OUTPUT=/dev/null改为/dev/kmsg，通过串口查看启动日志（具体修改可私信获取）；

4.RPMB与Security分区：RK3588（eMMC设备）默认用RPMB存储密钥，若为Flash设备，需在menuconfig中切换“Optee Storage”为SECURITY，并添加4M大小的Security分区；

5.指令依赖顺序：必须先执行makemenuconfig配置安全参数，再执行security-createkeys、loader等指令，否则参数不生效。

总结

RK3588的安全开发核心是围绕官方build.sh指令集，构建“配置→密钥→编译→烧录”的完整链路。本文通过实测验证，确认该流程可有效防止未签名固件启动，且适配Debian等第三方系统。需注意，量产前务必完成OTP熔断与密钥备份，同时根据硬件类型（eMMC/Flash）选择合适的安全存储方案。

若需Ramdisk调试脚本、Debian镜像优化等细节，可私信交流，后续将推出专题文章深入讲解。