ESP-IDF Secure Boot v2 安全启动全指南签名块格式、eFuse 密钥管理、RSA/ECDSA 方案与远程签名实践【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idfSecure Boot v2 是 ESP-IDF 在支持芯片上实现的一级/二级引导链数字签名校验机制用于确保设备只能运行经授权签名方签名的引导程序与应用程序是 Espressif SoC 安全方案的核心组成。本文以 secure-boot-v2.rst 为主线结合 ESP-IDF 仓库中 secure_boot_v2 的源码实现与安全特性示例工程系统讲解 Secure Boot v2 的启动流程、签名块二进制格式、eFuse 用法、启用步骤、密钥生命周期管理以及idf.py secure-*/openssl签名与验证命令。读完本文你将能独立完成 Secure Boot v2 的配置、密钥生成、镜像签名、远程签名与密钥撤销等完整实战流程。背景与设计目标Secure Boot 通过校验每次启动的每一段软件都经过签名保护设备免受运行任何未授权未签名代码的攻击。在 ESP32 系列芯片上这些软件包括第二级引导程序second stage bootloader和每个应用程序二进制application binary。需要注意第一级ROM引导程序属于 ROM 代码本身无法被修改因此无需签名。从 secure-boot-v2.rst 的说明可知Secure Boot v2 在不同芯片上对应不同的芯片版本前提例如 ESP32 从芯片修订版 v3.0 起、ESP32-C3 从 v0.3ECO3起支持。若需在 menuconfig 中启用相应选项需将CONFIG_ESP32_REV_MIN设为v3.0、CONFIG_ESP32C3_REV_MIN设为v0.3 (ECO3)。部分芯片支持 RSA 方案默认 RSA-3072部分芯片仅支持 ECDSA 方案如 ESP32-C2、ESP32-C61、ESP32-H4 支持 ECDSA而 ESP32-C5、ESP32-C6、ESP32-H2、ESP32-P4 等支持在 RSA 与 ECDSA 之间选择。对于 ESP32 v3.0 之前的芯片修订版请参考 secure-boot-v1官方推荐在芯片支持的情况下使用 Secure Boot v2因为它比 V1 更安全、更灵活。安全模型的三大优点文档列出了 Secure Boot v2 相比其他方案的核心优势公钥上设备、私钥保密公钥存储在设备上对应的私钥保存在秘密场所设备永远不会访问私钥。设备上不存任何秘密因此对被动侧信道攻击如时序分析、功耗分析天然免疫。统一镜像格式应用程序与第二级引导程序使用完全相同的镜像格式与签名校验方法。此外支持密钥撤销能力的芯片SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS可以在制造时向芯片中写入最多三把公钥并支持永久吊销单把公钥而 ESP32 与 ESP32-C2 只能生成并存储一把公钥。Secure Boot v2 启动流程Secure Boot v2 使用专门的签名块signature block来校验引导程序镜像与应用二进制镜像。每个镜像都有独立生成的签名块追加在镜像末尾。支持多密钥的芯片可在引导程序或应用镜像上追加最多三个签名块ESP32 v3.0 与 ESP32-C2 只能追加一个。每个签名块包含对前面镜像内容的签名、对应的公钥公钥的摘要digest被存储在 eFuse 中。应用镜像不仅在每次启动时被校验每次 OTA 升级时也会被校验。如果当前选中的 OTA 应用镜像无法通过校验引导程序会回退并查找另一个签名正确的应用镜像。整个启动流程如下启动时ROM 代码检查 eFuse 中的 Secure Boot v2 位。若 Secure Boot 关闭执行正常启动若开启按以下步骤继续。ROM 代码校验引导程序的签名块校验规则见下文验证签名块。失败则终止启动。ROM 代码使用原始镜像数据、对应签名块和 eFuse 校验引导程序镜像见验证镜像。失败则终止启动。ROM 代码执行引导程序。引导程序校验应用镜像的签名块。失败则终止启动。引导程序校验应用镜像。若失败但存在另一个应用镜像则对其重复步骤 5-7直到找到有效镜像或没有其他镜像。引导程序执行通过校验的应用镜像。源码中的实现印证了这一过程在 secure_boot_signatures_bootloader.c 中esp_secure_boot_verify_signature()先将镜像长度向上取整到 4 KB 边界计算镜像摘要再映射签名块所在扇区并调用esp_secure_boot_verify_sbv2_signature_block()完成最终校验其中还通过ESP_FAULT_ASSERT对 eFuse 中读取的公钥摘要进行多次冗余读取比对以抵抗故障注入FI攻击。首次启动时的 eFuse 烧录第一次启动时eFuse 中还没有公钥摘要。此时引导程序从自身签名块和或应用签名块中提取公钥摘要并烧录进 eFuse。这对应 secure_boot.c 中的esp_secure_boot_v2_permanently_enable()它通过check_and_generate_secure_boot_keys()校验引导程序与应用的签名块、计算公钥摘要调用esp_efuse_write_keys()将摘要写入 eFuse最后调用esp_secure_boot_enable_secure_features()并批量提交esp_efuse_batch_write_commit。这也解释了文档中的两条重要说明Secure Boot 只有在有效的分区表和应用镜像都被烧录之后才会被真正启用防止系统尚未配置完整时发生意外如果第一次启动过程中芯片被复位或断电下次启动会重新执行该过程。Secure Boot v2 方案选择RSA 与 ECDSA支持SOC_SECURE_BOOT_V2_RSA与SOC_SECURE_BOOT_V2_ECC的芯片如 ESP32-C5、ESP32-C6、ESP32-H2、ESP32-P4可在 RSA 与 ECDSA 两种方案间选择每台设备只能使用一种方案。文档给出的选择依据ECDSA 在更短的密钥长度下提供与 RSA 相当的安全强度。目前业界估计ECDSA P-256 曲线大致等价于 RSA-3072。但ECDSA 签名验证耗时显著高于 RSA。推荐需要快速启动的场景选择 RSA需要更短密钥的场景选择 ECDSA。ESP32-C5 上则推荐 ECDSA因为其在保证快速启动的同时密钥更短。支持 P-384 曲线的芯片SOC_ECDSA_SUPPORT_CURVE_P384还可使用 ECDSA P-384 签名方案安全强度高于 ECDSA-P256 与 RSA-3072代价是验证时间增加适合对安全强度要求更高的场景。下表对比了各芯片上 ROM 引导程序仅验证引导程序镜像签名所花费的时间来自原文档单位为毫秒。注意这只是 ROM 阶段的签名验证耗时并不代表整体启动时间且表中 CPU 频率是 ROM 引导程序运行时的频率因此较低。验证方案时间CPU 频率ROM 阶段RSA-3072ESP32-C5 约 12.1 ms / ESP32-C6 约 10.2 ms / ESP32-H2 约 18.3 ms / ESP32-P4 约 14.8 ms48 / 40 / 32 / 40 MHzECDSA-P256ESP32-C5 约 5.6 ms / ESP32-C6 约 83.9 ms / ESP32-H2 约 76.2 ms / ESP32-P4 约 61.1 ms48 / 40 / 32 / 40 MHzECDSA-P384ESP32-C5 约 20.6 ms48 MHz注意对于部分芯片ECDSA 方案对某些输入向量存在安全或功能性缺陷原文档明确提示相关芯片上不推荐在生产环境中使用 ECDSA 方案强制启用需打开CONFIG_SECURE_BOOT_INSECURE与CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA详见硬件勘误文档。撰写/配置时请以当前芯片的实际硬件支持为准。签名块格式Signature Block Format签名块从4 KB 对齐边界开始独占一个 flash 扇区。签名覆盖镜像中的所有字节包括填充字节见下文安全填充。RSA 签名块版本号 0x02偏移大小字节说明01魔数Magic byte11版本号当前为 0x020x01 为 Secure Boot V122填充字节保留应为 0432仅镜像内容的 SHA-256 哈希不含签名块36384RSA 公钥模数即 RFC8017 中的值 n4204RSA 公钥指数即 RFC8017 中的值 e424384预计算的 R由 n 导出8084预计算的 M由 n 导出812384镜像内容的 RSA-PSS 签名RFC8017 第 8.1.1 节PSS 参数SHA256 哈希、MGF1 函数、salt 长度 32 字节、默认 trailer 字段 0xBC11964前面 1196 字节的 CRC32120016零填充至 1216 字节R 与 M 用于硬件辅助的 Montgomery 乘法加速。ECDSA-256 签名块版本号 0x03偏移大小字节说明01魔数11版本号当前为 0x0322填充字节保留应为 0432仅镜像内容的 SHA-256 哈希不含签名块361曲线 ID2 表示 NIST256p 曲线3764ECDSA 公钥32 字节 X 坐标 32 字节 Y 坐标10164镜像内容的 ECDSA 签名RFC6090 第 5.3.2 节32 字节 R 分量 32 字节 S 分量1651031保留11964前面 1196 字节的 CRC32120016零填充至 1216 字节ECDSA-384 签名块版本号 0x03支持 P-384 曲线的芯片偏移大小字节说明01魔数11版本号当前为 0x0321生成签名时计算摘要所用的 SHA 版本SHA-384 为 131填充字节保留应为 0448仅镜像内容的 SHA-384 哈希不含签名块521曲线 ID3 表示 NIST384p 曲线5396ECDSA 公钥48 字节 X 坐标 48 字节 Y 坐标14996镜像内容的 ECDSA 签名48 字节 R 分量 48 字节 S 分量245951保留11964前面 1196 字节的 CRC32120016零填充至 1216 字节签名扇区的其余部分为擦除后的 flash0xFF这允许在已有签名块之后写入其他签名块用于多密钥场景。源码侧签名块的合法性判定在 secure_boot_signatures_bootloader.c 的validate_signature_block()中体现检查magic_byte、CRC32对前 1196 字节计算、block-version是否与当前方案匹配并在 ECDSA 方案下进一步核对curve_id。而 RSA 签名验证最终通过 PSA Crypto APIPSA_ALG_RSA_PSS(PSA_ALG_SHA_256)完成见 secure_boot_rsa_signature.cECDSA 验证则在 secure_boot_ecdsa_signature.c 中依据curve_id选择 P-256SHA-256或 P-384SHA-384算法族完成。安全填充Secure PaddingSecure Boot v2 方案中应用镜像被填充到flash MMU 页大小边界确保只有经过校验的内容才会被映射到内部地址空间这就是安全填充。签名在填充之后计算然后签名块4 KB被追加到镜像末尾。默认 flash MMU 页大小为64 KB支持可配置 MMU 页大小的芯片会根据CONFIG_ESPTOOLPY_FLASHSIZE自动设置CONFIG_MMU_PAGE_SIZE。安全填充通过esptool的elf2image转换中的--secure-pad-v2选项完成。以下表展示了带安全填充与签名块的已签名应用布局示例偏移大小KB说明0580未签名应用大小示例值58060安全填充对齐到下一个 64 KB 边界6404签名块应用镜像始终从下一个 flash MMU 页大小边界默认 64 KB开始因此签名块之后剩余的空间可用来存放其他数据分区如nvs。验证签名块与验证镜像验证签名块一个签名块有效的条件为第一个字节为0xe7且偏移 1196 处存放的 CRC32 有效。否则视为无效签名块。验证镜像镜像通过校验的条件为任意签名块中存储的公钥对该设备有效且该签名块中的签名与从 flash 读取的镜像数据计算出的签名一致。具体三步将引导程序签名块中嵌入公钥的SHA-256 哈希摘要与 eFuse 中保存的摘要比较若与任何 eFuse 摘要都不匹配校验失败。生成应用镜像摘要与签名块中的镜像摘要比对不一致则校验失败。使用公钥验证镜像签名RSA 方案采用 RSA-PSSRFC8017 第 8.1.2 节ECDSA 方案采用 ECDSA 签名验证RFC6090 第 5.3.3 节与第 2 步计算出的镜像摘要比对。验证数据分区Secure Boot v2 签名校验还可以在OTA 更新期间校验数据分区镜像。启用CONFIG_SECURE_SIGNED_DATA_PARTITION后可对子类型为ESP_PARTITION_SUBTYPE_DATA_UNDEFINED的数据分区进行校验。数据分区镜像必须使用与应用程序相同的签名密钥通过idf.py secure-sign-data签名并遵循与应用镜像相同的格式。验证过程使用 eFuse 中存储的公钥摘要遵循上文验证镜像的流程。更详细的 OTA 流程与分区配置参见 ESP-IDF 文档中的 secure-signed-data-partition 章节。eFuse 使用Secure Boot v2 依赖以下 eFuse 位与密钥块ESP32 v3.0ABS_DONE_1在启动时启用 Secure Boot 保护。BLK2存储公钥的 SHA-256 摘要。该摘要是公钥模数、指数、预计算 R 与 M 的 SHA-256 哈希对应签名块偏移 36~812 的 776 字节。必须设置写保护位不能设置读保护位。非 ESP32 芯片SECURE_BOOT_EN在启动时启用 Secure Boot 保护。SECURE_BOOT_SHA384_EN支持 ECDSA-P384 的芯片启用 Secure Boot 签名验证的 SHA-384 摘要计算。KEY_PURPOSE_X通过将SECURE_BOOT_DIGESTXX 0, 1, 2写入KEY_PURPOSE_XX 0, 1, 2, 3, 4, 5来设置密钥块用途。例如KEY_PURPOSE_2设为SECURE_BOOT_DIGEST1则BLOCK_KEY2存放 Secure Boot v2 公钥摘要。需设置写保护位该字段无读保护位。BLOCK_KEYX按KEY_PURPOSE_X的功能存放数据存储公钥的 SHA-256 摘要32 字节。该摘要是对 776 字节签名块内容偏移 36~812含公钥模数、指数、预计算 R 与 M计算的。需设置写保护位不能设置读保护位。KEY_REVOKEX对应 3 个密钥块的吊销位。例如设置KEY_REVOKE2会吊销用途为SECURE_BOOT_DIGEST2的密钥块。SECURE_BOOT_AGGRESSIVE_REVOKE启用激进吊销一旦用该密钥验证失败立即吊销该密钥。关键约束密钥必须可读软件才能访问它。若密钥被读保护软件读到的将全为 0签名验证会失败并终止启动。为确保攻击者事后无法添加受信任密钥每个未使用的密钥摘要槽位都应用KEY_REVOKEX吊销应用启动时esp_secure_boot_init_checks会检查这一点除非启用了CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS。如何启用 Secure Boot v2以下为基于idf.py的完整启用步骤命令是espsecure对应命令的封装体验更友好但可能缺少部分高级功能打开工程配置菜单menuconfig在Security features中设置Enable hardware Secure Boot in bootloader启用 Secure Boot。选择签名方案Secure Boot v2选项会被选中App Signing Scheme默认设为芯片对应的默认方案如 RSA 或 ECDSA (v2)。对支持双方案的芯片按需选择 RSA 或 ECDSA对 ESP32需先在Component ConfigESP32- Specific中将Minimum Supported ESP32 Revision设为 v3.0 才能看到Secure Boot v2选项。指定 Secure Boot 签名密钥的路径相对于工程目录。在UART ROM download mode中选择所需的 UART ROM 下载模式。多数芯片默认设为Permanently switch to Secure mode推荐生产设备最安全的选项是Permanently disabled。ESP32 上该选项默认保持启用以避免在开发阶段永久禁用但这是潜在不安全选项建议为更好安全而禁用。按需设置其他 menuconfig 选项退出并保存配置。第一次运行idf.py build时如果签名密钥不存在会打印错误信息并给出通过idf.py secure-generate-signing-key生成签名密钥的命令。这样生成的签名密钥使用操作系统及其 Python 安装可用的最佳随机源OSX/Linux 为/dev/urandomWindows 为CryptGenRandom()。若该随机源较弱私钥也会较弱。 生产环境建议使用 OpenSSL 或其他行业标准加密程序生成密钥对见下文生成 Secure Boot 签名密钥。运行idf.py bootloader构建启用 Secure Boot 的引导程序。构建输出会提示使用esptool write-flash的烧录命令。准备好后自行运行提示中的烧录命令并等待烧录完成。此步骤需要你手动输入构建系统不会代为执行。运行idf.py flash构建并烧录分区表和刚构建的应用镜像。应用镜像会使用第 6 步生成的签名密钥签名。idf.py flash在启用 Secure Boot 时不会烧录引导程序。复位芯片它将启动烧录的第二级引导程序。引导程序会在芯片上启用 Secure Boot然后校验应用镜像签名并启动应用。请观察串口控制台输出确认 Secure Boot 已启用且构建配置无错误。Secure Boot 只有在有效的分区表和应用镜像烧录完成后才会启用若首次启动期间复位或断电下次启动会重新执行该流程。后续每次启动Secure Boot 硬件会校验第二级引导程序未被修改引导程序用其附加签名块中已验证的公钥部分校验签名的应用镜像。完整的综合示例同时启用 Secure Boot v2、Flash 加密与 NVS 加密等安全特性位于 security/security_features_app。启用 Secure Boot 之后的限制任何更新的引导程序或应用都必须使用与 eFuse 中已存摘要匹配的密钥签名。启用 Secure Boot 或 Flash 加密会禁用 ROM 中的 USB-OTG USB 协议栈禁止通过该端口的串口仿真或设备固件升级DFU进行更新。Secure Boot 启用后无法再对 eFuse 密钥进行读保护。这是为了防止攻击者对包含 Secure Boot 公钥摘要的 eFuse 块设置读保护从而造成即时拒绝服务并可能借助故障注入攻击绕过签名验证。烧录读保护密钥必须读保护的密钥硬件直接访问、软件不可读Flash 加密密钥、HMAC 密钥、ECDSA 密钥、Key Manager 密钥。不得读保护的密钥软件需要读取Secure Boot 公钥摘要、用户数据。Secure Boot 启用时会默认禁用继续设置 eFuse 读保护的能力。如果希望在应用后期仍能读保护某个 eFuse如上表中的某类密钥必须在启用 Secure Boot 的同时打开配置CONFIG_SECURE_BOOT_V2_ALLOW_EFUSE_RD_DIS。理想情况下所有此类密钥应在启用 Secure Boot 之前烧录完毕若确实需要打开该配置务必在所有需读保护的 eFuse 密钥编程完成后使用esp_efuse_write_field_bit烧录ESP_EFUSE_WR_DIS_RD_DIS对应芯片的 eFuse 写保护位。若在启用 Secure Boot 时由第二级引导程序启用 Flash 加密它会确保首次启动生成的 Flash 加密密钥已经被读保护。生成 Secure Boot 签名密钥构建系统会提示通过idf.py secure-generate-signing-key生成新签名密钥。参数说明RSA 方案--version 2生成 Secure Boot v2 的 RSA-3072 私钥也可额外传递--scheme rsa3072。ECDSA 方案--version 2 --scheme ecdsa256或支持 P-384 的芯片使用--scheme ecdsa384生成对应 ECDSA 私钥。签名密钥的强度取决于(a) 系统的随机数源质量(b) 所用算法的正确性。生产设备建议在熵源质量良好的系统上生成签名密钥并使用可用的最佳密钥生成工具。使用 OpenSSL 生成密钥的参考命令RSA 3072openssl genrsa -out my_secure_boot_signing_key.pem 3072ECC NIST256p 曲线openssl ecparam -name prime256v1 -genkey -noout -out my_secure_boot_signing_key.pemECC NIST384p 曲线支持 P-384 的芯片openssl ecparam -name secp384r1 -genkey -noout -out my_secure_boot_signing_key.pem切记Secure Boot 系统的强度取决于签名密钥的保密性。远程签名Remote Signing生产构建中良好的实践是使用远程签名服务器而不是将签名密钥放在构建机上构建机上放密钥是 ESP-IDF Secure Boot 的默认配置。espsecure命令行程序可在远程系统上为 Secure Boot 签署应用镜像与分区表数据。远程签名的一般前提禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES后构建固件构建系统上无需存在私钥。使用idf.py签名应用镜像与分区表构建完成后构建系统会打印以下形式的签名步骤idf.py secure-sign-data BINARY_FILE --keyfile PRIVATE_SIGNING_KEY上述命令将镜像签名追加到现有二进制文件。可使用--output参数将签名后的二进制写入单独文件idf.py secure-sign-data --keyfile PRIVATE_SIGNING_KEY --output SIGNED_BINARY_FILE BINARY_FILE使用预计算签名如果你有镜像的有效预计算签名及其对应公钥可以用这些签名生成签名扇区并追加到镜像。注意预计算签名必须覆盖镜像所有字节包括安全填充字节。此场景下固件镜像同样需禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES构建镜像会做安全填充然后用以下命令生成签名二进制idf.py secure-sign-data --pub-key PUBLIC_SIGNING_KEY --signature SIGNATURE_FILE --output SIGNED_BINARY_FILE BINARY_FILE该命令会验证签名、生成签名块格式见上文签名块格式并追加到二进制文件末尾。使用外部硬件安全模块HSM出于安全考虑也可使用外部 HSM 存放私钥无法直接访问但提供对二进制文件生成签名及对应公钥的接口。此时同样禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES构建固件将安全填充后的镜像交给外部 HSM 生成签名参考 espsecure 工具文档中 remote signing using an external HSM 一节生成签名镜像。三种远程签名工作流均将签名后的二进制写入--output参数指定的文件名支持多密钥吊销的芯片上--append-signatures选项允许向镜像追加多个签名最多 3 个。Secure Boot 最佳实践原文档给出如下最佳实践清单在熵源质量良好的系统上生成签名密钥。全程保持签名密钥私密。密钥泄露将危及整个 Secure Boot 系统。不允许任何第三方观察密钥生成或idf.py secure-签名过程两个过程都对时序等侧信道攻击敏感。启用 Secure Boot 配置中的所有安全选项包括 Flash 加密、禁用 JTAG、禁用 BASIC ROM 解释器、禁用 UART 引导程序加密 flash 访问。将 Secure Boot 与 flash-encryption 结合使用防止本地读出 flash 内容。密钥管理支持多密钥的芯片多密钥原则应在制造时独立计算并分别存储 1 到 3 对公钥Key #0、#1、#2。KEY_DIGESTeFuse 编程后应写保护。未使用的KEY_DIGEST槽位必须烧录对应的KEY_REVOKEeFuse 以永久禁用且必须发生在设备出厂前。eFuse 可以在启用Secure Boot v2后由第二级引导程序在首次启动时写入也可以用espefuse通过 ROM 串口引导程序写入。KEY_DIGEST应从摘要 #0 开始顺序编号若使用摘要 #1 则 #0 必须已用若使用摘要 #2 则 #0 与 #1 必须已用。第二级引导程序不可 OTA 升级应使用至少一把可能全部三把私钥签名后在工厂烧录。应用通常只用一把私钥签名其余私钥安全存放若部分密钥正被吊销则可能用多把私钥签名见下文密钥吊销。多密钥签名引导程序应在烧录前用设备生命周期内需要的所有私钥签名。构建系统一次最多只能签署一把私钥必要时用户需手动运行命令追加更多签名。可使用idf.py secure-sign-data的追加功能该命令也会在启用 Secure Boot v2 的引导程序编译结束时打印例如idf.py secure-sign-data -k secure_boot_signing_key2.pem --append-signatures -o signed_bootloader.bin build/bootloader/bootloader.bin多私钥签名时建议各私钥独立签名尽量在不同服务器上并分别存储。检查二进制上附加的签名espsecure signature-info-v2 datafile.bin若 Secure Boot v2 使用 ECDSA P-384 方案所有签名密钥必须都是 ECDSA-P384 密钥混合使用不同椭圆曲线如 P-256 与 P-384不受支持会导致启动时签名验证失败。密钥吊销密钥按线性顺序处理key #0、key #1、key #2。某密钥被吊销后其余未吊销密钥仍可用于签署应用。例如吊销 key #1 后key #0 与 key #2 仍有效。应用应一次只使用一把密钥签名以最大限度减少未使用私钥的暴露。引导程序可从工厂携带多把密钥签名。保守方式Conservative Approach假设受信任私钥 (N-1) 已泄露要升级到新密钥对 (N)服务器发送用新私钥 (#N) 签名的 OTA 更新。新 OTA 更新写入未使用的 OTA 应用分区。校验新应用的签名块公钥与 eFuse 中编程的摘要比对并用验证过的公钥校验应用。将活动分区设为新 OTA 应用分区。设备复位加载用 key #N-1 验证过的引导程序再由其启动用 key #N 验证的新应用。新应用用 key #N 验证引导程序作为最终检查然后运行代码吊销 key #N-1即设置KEY_REVOKEeFuse 位。可调用 APIesp_ota_revoke_secure_boot_public_key吊销 key #N-1该接口实现在 esp_ota_ops.c。类似方法也可用于物理重新烧录新密钥物理重刷时可同时更改引导程序内容。可能需要吊销一把当前未使用的密钥。例如活动应用用 key #0 签名但 key #1 泄露则应继续用 key #0 签署新的 OTA 更新并通过esp_ota_revoke_secure_boot_public_key (SECURE_BOOT_PUBLIC_KEY_INDEX_[N])吊销 key #1。吊销后其余未吊销密钥仍可用于签署未来的应用。激进方式Aggressive ApproachROM 代码额外支持在签名验证失败时自动吊销公钥摘要。启用方式烧录SECURE_BOOT_AGGRESSIVE_REVOKEeFuse或启用CONFIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE。密钥吊销仅在 Secure Boot 成功启用后适用。无效签名块或无效镜像摘要不会触发吊销只有签名验证失败即验证镜像第 3 步失败才吊销密钥。一旦密钥被吊销就永远不能用于验证镜像签名。此特性对物理攻击提供强抵抗但如果所有密钥都因验证失败被吊销设备可能被永久变砖。启用CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS会在运行时应用和首次启动启用 Secure Boot 时引导程序都保持未使用摘要槽位不被吊销。除非调试与下载接口完全禁用且远程接口经过完整安全审计否则留下未吊销的密钥槽位可能带来安全风险。技术细节生成与验证签名Secure Boot 已集成到 ESP-IDF 构建系统中启用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES时idf.py build会签名应用镜像idf.py bootloader会产生已签名引导程序。也可以使用idf.py或openssl独立生成与验证签名。推荐使用idf.py若需在非 ESP-IDF 环境中操作可用openssl命令因为 Secure Boot v2 签名生成与标准签名算法兼容。使用idf.py签名二进制镜像idf.py secure-sign-data --keyfile ./my_signing_key.pem --output ./image_signed.bin image-unsigned.binkeyfile是包含私钥的 PEM 文件。验证签名后的二进制镜像idf.py secure-verify-signature --keyfile ./my_signing_key.pem image_signed.binkeyfile是包含公钥或私钥的 PEM 文件。使用 OpenSSL生成镜像二进制文件的摘要openssl dgst -sha256 -binary BINARY_FILE DIGEST_BINARY_FILEECDSA-P384 方案必须使用 SHA-384openssl dgst -sha384 -binary BINARY_FILE DIGEST_BINARY_FILE用上述摘要生成镜像签名RSA-PSS 签名openssl pkeyutl -sign \ -in DIGEST_BINARY_FILE \ -inkey PRIVATE_SIGNING_KEY \ -out SIGNATURE_FILE \ -pkeyopt digest:sha256 \ -pkeyopt rsa_padding_mode:pss \ -pkeyopt rsa_pss_saltlen:32ECDSA 签名openssl pkeyutl -sign \ -in DIGEST_BINARY_FILE \ -inkey PRIVATE_SIGNING_KEY \ -out SIGNATURE_FILE验证生成的签名RSA-PSSopenssl pkeyutl -verify \ -in DIGEST_BINARY_FILE \ -pubin -inkey PUBLIC_SIGNING_KEY \ -sigfile SIGNATURE_FILE \ -pkeyopt rsa_padding_mode:pss \ -pkeyopt rsa_pss_saltlen:32 \ -pkeyopt digest:sha256ECDSAopenssl pkeyutl -verify \ -in DIGEST_BINARY_FILE \ -pubin -inkey PUBLIC_SIGNING_KEY \ -sigfile SIGNATURE_FILESecure Boot 与 Flash 加密如果 Secure Boot 不与 Flash 加密一起使用攻击者可能发起检查时到使用时time-of-check to time-of-use攻击——在镜像验证并运行之后交换 flash 内容。因此官方强烈建议两者同时启用相关独立文档见 flash-encryption。特殊芯片提醒ESP32-C2它只有一个 eFuse 密钥块同时用于 Secure Boot 与 Flash 加密两个密钥且该密钥块只能烧录一次。因此这两个密钥必须同时烧录无法单独启用 Secure Boot 或 Flash 加密因为后续对 eFuse 密钥块的写入会返回错误。无硬件 Secure Boot 的签名应用验证软件签名验证应用签名也可以在不启用硬件 Secure Boot的情况下在 OTA 更新期间验证对应配置CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT。它使用与 Secure Boot v2 相同的应用签名方案但与硬件 Secure Boot 不同软件签名验证无法抵御对 flash 具有写权限的攻击者攻击者可能绕过签名验证。此模式适用于以下场景启动时 Secure Boot 验证的延迟不可接受且/或威胁模型不包含物理接触或攻击者写入 bootloader/app 分区。工作方式使用当前运行应用签名块中的公钥来验证新更新应用的签名更新过程中不验证运行中应用的签名假定其有效。系统由此建立从运行应用到新更新应用的信任链。因此初始烧录的应用必须签名。应用启动时会检查签名若未找到有效签名则中止且无法进行任何更新防止设备变砖且无法继续更新的情况。应用应在第一位置只放一个有效签名块。与硬件 Secure Boot v2 不同运行中应用的签名在启动时不被验证系统只验证第一位置的签名块并忽略其他追加签名。注意硬件 Secure Boot 支持多受信任密钥但未启用 Secure Boot 的签名检查模式只使用签名块中的第一个公钥验证更新。若需要多把受信任公钥应启用完整 Secure Boot。 除非确定该选项足以满足应用安全需求否则一般建议使用完整的硬件 Secure Boot。如何启用签名应用验证打开 menuconfig Security features。选择App Signing SchemeRSA或芯片默认/支持的 ECDSA (v2)。启用CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT。默认情况下选择Require signed app images选项会启用Sign binaries during build在构建过程中自动签名二进制文件使用Secure Boot private signing key中指定的文件签名。若禁用Sign binaries during build则所有应用二进制必须按远程签名一节的说明手动签名。重要所有烧录的应用都必须签名构建期间或构建后否则无法正常更新。高级特性JTAG 调试默认情况下启用 Secure Boot 时JTAG 调试会通过 eFuse 禁用——引导程序在首次启动时与启用 Secure Boot 同时执行此操作。关于在启用 Secure Boot 或签名应用验证时使用 JTAG 调试的更多信息可参考 ESP-IDF 文档中 jtag-debugging-security-features 章节。小结Secure Boot v2 通过ROM 引导程序 → 第二级引导程序 → 应用镜像的逐级签名校验结合 eFuse 中不可篡改的公钥摘要为 ESP32 系列芯片提供了硬件级代码完整性保护。其核心要点可归纳为理解签名块RSA/ECDSA-256/ECDSA-384的二进制布局与校验规则在首次启动时正确烧录并写保护公钥摘要 eFuse在多密钥芯片上规划密钥轮换与吊销策略保守或激进方式生产环境优先采用远程签名并严格保密私钥最后将 Secure Boot 与 Flash 加密配合使用封堵 TOCTOU 攻击面。以上每一步都可在 secure_boot_v2 源码与 security_features_app 示例工程中找到对应实现与参考配置。【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ESP-IDF Secure Boot v2 安全启动全指南签名块格式、eFuse 密钥管理、RSA/ECDSA 方案与远程签名实践【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idfSecure Boot v2 是 ESP-IDF 在支持芯片上实现的一级/二级引导链数字签名校验机制用于确保设备只能运行经授权签名方签名的引导程序与应用程序是 Espressif SoC 安全方案的核心组成。本文以 secure-boot-v2.rst 为主线结合 ESP-IDF 仓库中 secure_boot_v2 的源码实现与安全特性示例工程系统讲解 Secure Boot v2 的启动流程、签名块二进制格式、eFuse 用法、启用步骤、密钥生命周期管理以及idf.py secure-*/openssl签名与验证命令。读完本文你将能独立完成 Secure Boot v2 的配置、密钥生成、镜像签名、远程签名与密钥撤销等完整实战流程。背景与设计目标Secure Boot 通过校验每次启动的每一段软件都经过签名保护设备免受运行任何未授权未签名代码的攻击。在 ESP32 系列芯片上这些软件包括第二级引导程序second stage bootloader和每个应用程序二进制application binary。需要注意第一级ROM引导程序属于 ROM 代码本身无法被修改因此无需签名。从 secure-boot-v2.rst 的说明可知Secure Boot v2 在不同芯片上对应不同的芯片版本前提例如 ESP32 从芯片修订版 v3.0 起、ESP32-C3 从 v0.3ECO3起支持。若需在 menuconfig 中启用相应选项需将CONFIG_ESP32_REV_MIN设为v3.0、CONFIG_ESP32C3_REV_MIN设为v0.3 (ECO3)。部分芯片支持 RSA 方案默认 RSA-3072部分芯片仅支持 ECDSA 方案如 ESP32-C2、ESP32-C61、ESP32-H4 支持 ECDSA而 ESP32-C5、ESP32-C6、ESP32-H2、ESP32-P4 等支持在 RSA 与 ECDSA 之间选择。对于 ESP32 v3.0 之前的芯片修订版请参考 secure-boot-v1官方推荐在芯片支持的情况下使用 Secure Boot v2因为它比 V1 更安全、更灵活。安全模型的三大优点文档列出了 Secure Boot v2 相比其他方案的核心优势公钥上设备、私钥保密公钥存储在设备上对应的私钥保存在秘密场所设备永远不会访问私钥。设备上不存任何秘密因此对被动侧信道攻击如时序分析、功耗分析天然免疫。统一镜像格式应用程序与第二级引导程序使用完全相同的镜像格式与签名校验方法。此外支持密钥撤销能力的芯片SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS可以在制造时向芯片中写入最多三把公钥并支持永久吊销单把公钥而 ESP32 与 ESP32-C2 只能生成并存储一把公钥。Secure Boot v2 启动流程Secure Boot v2 使用专门的签名块signature block来校验引导程序镜像与应用二进制镜像。每个镜像都有独立生成的签名块追加在镜像末尾。支持多密钥的芯片可在引导程序或应用镜像上追加最多三个签名块ESP32 v3.0 与 ESP32-C2 只能追加一个。每个签名块包含对前面镜像内容的签名、对应的公钥公钥的摘要digest被存储在 eFuse 中。应用镜像不仅在每次启动时被校验每次 OTA 升级时也会被校验。如果当前选中的 OTA 应用镜像无法通过校验引导程序会回退并查找另一个签名正确的应用镜像。整个启动流程如下启动时ROM 代码检查 eFuse 中的 Secure Boot v2 位。若 Secure Boot 关闭执行正常启动若开启按以下步骤继续。ROM 代码校验引导程序的签名块校验规则见下文验证签名块。失败则终止启动。ROM 代码使用原始镜像数据、对应签名块和 eFuse 校验引导程序镜像见验证镜像。失败则终止启动。ROM 代码执行引导程序。引导程序校验应用镜像的签名块。失败则终止启动。引导程序校验应用镜像。若失败但存在另一个应用镜像则对其重复步骤 5-7直到找到有效镜像或没有其他镜像。引导程序执行通过校验的应用镜像。源码中的实现印证了这一过程在 secure_boot_signatures_bootloader.c 中esp_secure_boot_verify_signature()先将镜像长度向上取整到 4 KB 边界计算镜像摘要再映射签名块所在扇区并调用esp_secure_boot_verify_sbv2_signature_block()完成最终校验其中还通过ESP_FAULT_ASSERT对 eFuse 中读取的公钥摘要进行多次冗余读取比对以抵抗故障注入FI攻击。首次启动时的 eFuse 烧录第一次启动时eFuse 中还没有公钥摘要。此时引导程序从自身签名块和或应用签名块中提取公钥摘要并烧录进 eFuse。这对应 secure_boot.c 中的esp_secure_boot_v2_permanently_enable()它通过check_and_generate_secure_boot_keys()校验引导程序与应用的签名块、计算公钥摘要调用esp_efuse_write_keys()将摘要写入 eFuse最后调用esp_secure_boot_enable_secure_features()并批量提交esp_efuse_batch_write_commit。这也解释了文档中的两条重要说明Secure Boot 只有在有效的分区表和应用镜像都被烧录之后才会被真正启用防止系统尚未配置完整时发生意外如果第一次启动过程中芯片被复位或断电下次启动会重新执行该过程。Secure Boot v2 方案选择RSA 与 ECDSA支持SOC_SECURE_BOOT_V2_RSA与SOC_SECURE_BOOT_V2_ECC的芯片如 ESP32-C5、ESP32-C6、ESP32-H2、ESP32-P4可在 RSA 与 ECDSA 两种方案间选择每台设备只能使用一种方案。文档给出的选择依据ECDSA 在更短的密钥长度下提供与 RSA 相当的安全强度。目前业界估计ECDSA P-256 曲线大致等价于 RSA-3072。但ECDSA 签名验证耗时显著高于 RSA。推荐需要快速启动的场景选择 RSA需要更短密钥的场景选择 ECDSA。ESP32-C5 上则推荐 ECDSA因为其在保证快速启动的同时密钥更短。支持 P-384 曲线的芯片SOC_ECDSA_SUPPORT_CURVE_P384还可使用 ECDSA P-384 签名方案安全强度高于 ECDSA-P256 与 RSA-3072代价是验证时间增加适合对安全强度要求更高的场景。下表对比了各芯片上 ROM 引导程序仅验证引导程序镜像签名所花费的时间来自原文档单位为毫秒。注意这只是 ROM 阶段的签名验证耗时并不代表整体启动时间且表中 CPU 频率是 ROM 引导程序运行时的频率因此较低。验证方案时间CPU 频率ROM 阶段RSA-3072ESP32-C5 约 12.1 ms / ESP32-C6 约 10.2 ms / ESP32-H2 约 18.3 ms / ESP32-P4 约 14.8 ms48 / 40 / 32 / 40 MHzECDSA-P256ESP32-C5 约 5.6 ms / ESP32-C6 约 83.9 ms / ESP32-H2 约 76.2 ms / ESP32-P4 约 61.1 ms48 / 40 / 32 / 40 MHzECDSA-P384ESP32-C5 约 20.6 ms48 MHz注意对于部分芯片ECDSA 方案对某些输入向量存在安全或功能性缺陷原文档明确提示相关芯片上不推荐在生产环境中使用 ECDSA 方案强制启用需打开CONFIG_SECURE_BOOT_INSECURE与CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA详见硬件勘误文档。撰写/配置时请以当前芯片的实际硬件支持为准。签名块格式Signature Block Format签名块从4 KB 对齐边界开始独占一个 flash 扇区。签名覆盖镜像中的所有字节包括填充字节见下文安全填充。RSA 签名块版本号 0x02偏移大小字节说明01魔数Magic byte11版本号当前为 0x020x01 为 Secure Boot V122填充字节保留应为 0432仅镜像内容的 SHA-256 哈希不含签名块36384RSA 公钥模数即 RFC8017 中的值 n4204RSA 公钥指数即 RFC8017 中的值 e424384预计算的 R由 n 导出8084预计算的 M由 n 导出812384镜像内容的 RSA-PSS 签名RFC8017 第 8.1.1 节PSS 参数SHA256 哈希、MGF1 函数、salt 长度 32 字节、默认 trailer 字段 0xBC11964前面 1196 字节的 CRC32120016零填充至 1216 字节R 与 M 用于硬件辅助的 Montgomery 乘法加速。ECDSA-256 签名块版本号 0x03偏移大小字节说明01魔数11版本号当前为 0x0322填充字节保留应为 0432仅镜像内容的 SHA-256 哈希不含签名块361曲线 ID2 表示 NIST256p 曲线3764ECDSA 公钥32 字节 X 坐标 32 字节 Y 坐标10164镜像内容的 ECDSA 签名RFC6090 第 5.3.2 节32 字节 R 分量 32 字节 S 分量1651031保留11964前面 1196 字节的 CRC32120016零填充至 1216 字节ECDSA-384 签名块版本号 0x03支持 P-384 曲线的芯片偏移大小字节说明01魔数11版本号当前为 0x0321生成签名时计算摘要所用的 SHA 版本SHA-384 为 131填充字节保留应为 0448仅镜像内容的 SHA-384 哈希不含签名块521曲线 ID3 表示 NIST384p 曲线5396ECDSA 公钥48 字节 X 坐标 48 字节 Y 坐标14996镜像内容的 ECDSA 签名48 字节 R 分量 48 字节 S 分量245951保留11964前面 1196 字节的 CRC32120016零填充至 1216 字节签名扇区的其余部分为擦除后的 flash0xFF这允许在已有签名块之后写入其他签名块用于多密钥场景。源码侧签名块的合法性判定在 secure_boot_signatures_bootloader.c 的validate_signature_block()中体现检查magic_byte、CRC32对前 1196 字节计算、block-version是否与当前方案匹配并在 ECDSA 方案下进一步核对curve_id。而 RSA 签名验证最终通过 PSA Crypto APIPSA_ALG_RSA_PSS(PSA_ALG_SHA_256)完成见 secure_boot_rsa_signature.cECDSA 验证则在 secure_boot_ecdsa_signature.c 中依据curve_id选择 P-256SHA-256或 P-384SHA-384算法族完成。安全填充Secure PaddingSecure Boot v2 方案中应用镜像被填充到flash MMU 页大小边界确保只有经过校验的内容才会被映射到内部地址空间这就是安全填充。签名在填充之后计算然后签名块4 KB被追加到镜像末尾。默认 flash MMU 页大小为64 KB支持可配置 MMU 页大小的芯片会根据CONFIG_ESPTOOLPY_FLASHSIZE自动设置CONFIG_MMU_PAGE_SIZE。安全填充通过esptool的elf2image转换中的--secure-pad-v2选项完成。以下表展示了带安全填充与签名块的已签名应用布局示例偏移大小KB说明0580未签名应用大小示例值58060安全填充对齐到下一个 64 KB 边界6404签名块应用镜像始终从下一个 flash MMU 页大小边界默认 64 KB开始因此签名块之后剩余的空间可用来存放其他数据分区如nvs。验证签名块与验证镜像验证签名块一个签名块有效的条件为第一个字节为0xe7且偏移 1196 处存放的 CRC32 有效。否则视为无效签名块。验证镜像镜像通过校验的条件为任意签名块中存储的公钥对该设备有效且该签名块中的签名与从 flash 读取的镜像数据计算出的签名一致。具体三步将引导程序签名块中嵌入公钥的SHA-256 哈希摘要与 eFuse 中保存的摘要比较若与任何 eFuse 摘要都不匹配校验失败。生成应用镜像摘要与签名块中的镜像摘要比对不一致则校验失败。使用公钥验证镜像签名RSA 方案采用 RSA-PSSRFC8017 第 8.1.2 节ECDSA 方案采用 ECDSA 签名验证RFC6090 第 5.3.3 节与第 2 步计算出的镜像摘要比对。验证数据分区Secure Boot v2 签名校验还可以在OTA 更新期间校验数据分区镜像。启用CONFIG_SECURE_SIGNED_DATA_PARTITION后可对子类型为ESP_PARTITION_SUBTYPE_DATA_UNDEFINED的数据分区进行校验。数据分区镜像必须使用与应用程序相同的签名密钥通过idf.py secure-sign-data签名并遵循与应用镜像相同的格式。验证过程使用 eFuse 中存储的公钥摘要遵循上文验证镜像的流程。更详细的 OTA 流程与分区配置参见 ESP-IDF 文档中的 secure-signed-data-partition 章节。eFuse 使用Secure Boot v2 依赖以下 eFuse 位与密钥块ESP32 v3.0ABS_DONE_1在启动时启用 Secure Boot 保护。BLK2存储公钥的 SHA-256 摘要。该摘要是公钥模数、指数、预计算 R 与 M 的 SHA-256 哈希对应签名块偏移 36~812 的 776 字节。必须设置写保护位不能设置读保护位。非 ESP32 芯片SECURE_BOOT_EN在启动时启用 Secure Boot 保护。SECURE_BOOT_SHA384_EN支持 ECDSA-P384 的芯片启用 Secure Boot 签名验证的 SHA-384 摘要计算。KEY_PURPOSE_X通过将SECURE_BOOT_DIGESTXX 0, 1, 2写入KEY_PURPOSE_XX 0, 1, 2, 3, 4, 5来设置密钥块用途。例如KEY_PURPOSE_2设为SECURE_BOOT_DIGEST1则BLOCK_KEY2存放 Secure Boot v2 公钥摘要。需设置写保护位该字段无读保护位。BLOCK_KEYX按KEY_PURPOSE_X的功能存放数据存储公钥的 SHA-256 摘要32 字节。该摘要是对 776 字节签名块内容偏移 36~812含公钥模数、指数、预计算 R 与 M计算的。需设置写保护位不能设置读保护位。KEY_REVOKEX对应 3 个密钥块的吊销位。例如设置KEY_REVOKE2会吊销用途为SECURE_BOOT_DIGEST2的密钥块。SECURE_BOOT_AGGRESSIVE_REVOKE启用激进吊销一旦用该密钥验证失败立即吊销该密钥。关键约束密钥必须可读软件才能访问它。若密钥被读保护软件读到的将全为 0签名验证会失败并终止启动。为确保攻击者事后无法添加受信任密钥每个未使用的密钥摘要槽位都应用KEY_REVOKEX吊销应用启动时esp_secure_boot_init_checks会检查这一点除非启用了CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS。如何启用 Secure Boot v2以下为基于idf.py的完整启用步骤命令是espsecure对应命令的封装体验更友好但可能缺少部分高级功能打开工程配置菜单menuconfig在Security features中设置Enable hardware Secure Boot in bootloader启用 Secure Boot。选择签名方案Secure Boot v2选项会被选中App Signing Scheme默认设为芯片对应的默认方案如 RSA 或 ECDSA (v2)。对支持双方案的芯片按需选择 RSA 或 ECDSA对 ESP32需先在Component ConfigESP32- Specific中将Minimum Supported ESP32 Revision设为 v3.0 才能看到Secure Boot v2选项。指定 Secure Boot 签名密钥的路径相对于工程目录。在UART ROM download mode中选择所需的 UART ROM 下载模式。多数芯片默认设为Permanently switch to Secure mode推荐生产设备最安全的选项是Permanently disabled。ESP32 上该选项默认保持启用以避免在开发阶段永久禁用但这是潜在不安全选项建议为更好安全而禁用。按需设置其他 menuconfig 选项退出并保存配置。第一次运行idf.py build时如果签名密钥不存在会打印错误信息并给出通过idf.py secure-generate-signing-key生成签名密钥的命令。这样生成的签名密钥使用操作系统及其 Python 安装可用的最佳随机源OSX/Linux 为/dev/urandomWindows 为CryptGenRandom()。若该随机源较弱私钥也会较弱。 生产环境建议使用 OpenSSL 或其他行业标准加密程序生成密钥对见下文生成 Secure Boot 签名密钥。运行idf.py bootloader构建启用 Secure Boot 的引导程序。构建输出会提示使用esptool write-flash的烧录命令。准备好后自行运行提示中的烧录命令并等待烧录完成。此步骤需要你手动输入构建系统不会代为执行。运行idf.py flash构建并烧录分区表和刚构建的应用镜像。应用镜像会使用第 6 步生成的签名密钥签名。idf.py flash在启用 Secure Boot 时不会烧录引导程序。复位芯片它将启动烧录的第二级引导程序。引导程序会在芯片上启用 Secure Boot然后校验应用镜像签名并启动应用。请观察串口控制台输出确认 Secure Boot 已启用且构建配置无错误。Secure Boot 只有在有效的分区表和应用镜像烧录完成后才会启用若首次启动期间复位或断电下次启动会重新执行该流程。后续每次启动Secure Boot 硬件会校验第二级引导程序未被修改引导程序用其附加签名块中已验证的公钥部分校验签名的应用镜像。完整的综合示例同时启用 Secure Boot v2、Flash 加密与 NVS 加密等安全特性位于 security/security_features_app。启用 Secure Boot 之后的限制任何更新的引导程序或应用都必须使用与 eFuse 中已存摘要匹配的密钥签名。启用 Secure Boot 或 Flash 加密会禁用 ROM 中的 USB-OTG USB 协议栈禁止通过该端口的串口仿真或设备固件升级DFU进行更新。Secure Boot 启用后无法再对 eFuse 密钥进行读保护。这是为了防止攻击者对包含 Secure Boot 公钥摘要的 eFuse 块设置读保护从而造成即时拒绝服务并可能借助故障注入攻击绕过签名验证。烧录读保护密钥必须读保护的密钥硬件直接访问、软件不可读Flash 加密密钥、HMAC 密钥、ECDSA 密钥、Key Manager 密钥。不得读保护的密钥软件需要读取Secure Boot 公钥摘要、用户数据。Secure Boot 启用时会默认禁用继续设置 eFuse 读保护的能力。如果希望在应用后期仍能读保护某个 eFuse如上表中的某类密钥必须在启用 Secure Boot 的同时打开配置CONFIG_SECURE_BOOT_V2_ALLOW_EFUSE_RD_DIS。理想情况下所有此类密钥应在启用 Secure Boot 之前烧录完毕若确实需要打开该配置务必在所有需读保护的 eFuse 密钥编程完成后使用esp_efuse_write_field_bit烧录ESP_EFUSE_WR_DIS_RD_DIS对应芯片的 eFuse 写保护位。若在启用 Secure Boot 时由第二级引导程序启用 Flash 加密它会确保首次启动生成的 Flash 加密密钥已经被读保护。生成 Secure Boot 签名密钥构建系统会提示通过idf.py secure-generate-signing-key生成新签名密钥。参数说明RSA 方案--version 2生成 Secure Boot v2 的 RSA-3072 私钥也可额外传递--scheme rsa3072。ECDSA 方案--version 2 --scheme ecdsa256或支持 P-384 的芯片使用--scheme ecdsa384生成对应 ECDSA 私钥。签名密钥的强度取决于(a) 系统的随机数源质量(b) 所用算法的正确性。生产设备建议在熵源质量良好的系统上生成签名密钥并使用可用的最佳密钥生成工具。使用 OpenSSL 生成密钥的参考命令RSA 3072openssl genrsa -out my_secure_boot_signing_key.pem 3072ECC NIST256p 曲线openssl ecparam -name prime256v1 -genkey -noout -out my_secure_boot_signing_key.pemECC NIST384p 曲线支持 P-384 的芯片openssl ecparam -name secp384r1 -genkey -noout -out my_secure_boot_signing_key.pem切记Secure Boot 系统的强度取决于签名密钥的保密性。远程签名Remote Signing生产构建中良好的实践是使用远程签名服务器而不是将签名密钥放在构建机上构建机上放密钥是 ESP-IDF Secure Boot 的默认配置。espsecure命令行程序可在远程系统上为 Secure Boot 签署应用镜像与分区表数据。远程签名的一般前提禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES后构建固件构建系统上无需存在私钥。使用idf.py签名应用镜像与分区表构建完成后构建系统会打印以下形式的签名步骤idf.py secure-sign-data BINARY_FILE --keyfile PRIVATE_SIGNING_KEY上述命令将镜像签名追加到现有二进制文件。可使用--output参数将签名后的二进制写入单独文件idf.py secure-sign-data --keyfile PRIVATE_SIGNING_KEY --output SIGNED_BINARY_FILE BINARY_FILE使用预计算签名如果你有镜像的有效预计算签名及其对应公钥可以用这些签名生成签名扇区并追加到镜像。注意预计算签名必须覆盖镜像所有字节包括安全填充字节。此场景下固件镜像同样需禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES构建镜像会做安全填充然后用以下命令生成签名二进制idf.py secure-sign-data --pub-key PUBLIC_SIGNING_KEY --signature SIGNATURE_FILE --output SIGNED_BINARY_FILE BINARY_FILE该命令会验证签名、生成签名块格式见上文签名块格式并追加到二进制文件末尾。使用外部硬件安全模块HSM出于安全考虑也可使用外部 HSM 存放私钥无法直接访问但提供对二进制文件生成签名及对应公钥的接口。此时同样禁用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES构建固件将安全填充后的镜像交给外部 HSM 生成签名参考 espsecure 工具文档中 remote signing using an external HSM 一节生成签名镜像。三种远程签名工作流均将签名后的二进制写入--output参数指定的文件名支持多密钥吊销的芯片上--append-signatures选项允许向镜像追加多个签名最多 3 个。Secure Boot 最佳实践原文档给出如下最佳实践清单在熵源质量良好的系统上生成签名密钥。全程保持签名密钥私密。密钥泄露将危及整个 Secure Boot 系统。不允许任何第三方观察密钥生成或idf.py secure-签名过程两个过程都对时序等侧信道攻击敏感。启用 Secure Boot 配置中的所有安全选项包括 Flash 加密、禁用 JTAG、禁用 BASIC ROM 解释器、禁用 UART 引导程序加密 flash 访问。将 Secure Boot 与 flash-encryption 结合使用防止本地读出 flash 内容。密钥管理支持多密钥的芯片多密钥原则应在制造时独立计算并分别存储 1 到 3 对公钥Key #0、#1、#2。KEY_DIGESTeFuse 编程后应写保护。未使用的KEY_DIGEST槽位必须烧录对应的KEY_REVOKEeFuse 以永久禁用且必须发生在设备出厂前。eFuse 可以在启用Secure Boot v2后由第二级引导程序在首次启动时写入也可以用espefuse通过 ROM 串口引导程序写入。KEY_DIGEST应从摘要 #0 开始顺序编号若使用摘要 #1 则 #0 必须已用若使用摘要 #2 则 #0 与 #1 必须已用。第二级引导程序不可 OTA 升级应使用至少一把可能全部三把私钥签名后在工厂烧录。应用通常只用一把私钥签名其余私钥安全存放若部分密钥正被吊销则可能用多把私钥签名见下文密钥吊销。多密钥签名引导程序应在烧录前用设备生命周期内需要的所有私钥签名。构建系统一次最多只能签署一把私钥必要时用户需手动运行命令追加更多签名。可使用idf.py secure-sign-data的追加功能该命令也会在启用 Secure Boot v2 的引导程序编译结束时打印例如idf.py secure-sign-data -k secure_boot_signing_key2.pem --append-signatures -o signed_bootloader.bin build/bootloader/bootloader.bin多私钥签名时建议各私钥独立签名尽量在不同服务器上并分别存储。检查二进制上附加的签名espsecure signature-info-v2 datafile.bin若 Secure Boot v2 使用 ECDSA P-384 方案所有签名密钥必须都是 ECDSA-P384 密钥混合使用不同椭圆曲线如 P-256 与 P-384不受支持会导致启动时签名验证失败。密钥吊销密钥按线性顺序处理key #0、key #1、key #2。某密钥被吊销后其余未吊销密钥仍可用于签署应用。例如吊销 key #1 后key #0 与 key #2 仍有效。应用应一次只使用一把密钥签名以最大限度减少未使用私钥的暴露。引导程序可从工厂携带多把密钥签名。保守方式Conservative Approach假设受信任私钥 (N-1) 已泄露要升级到新密钥对 (N)服务器发送用新私钥 (#N) 签名的 OTA 更新。新 OTA 更新写入未使用的 OTA 应用分区。校验新应用的签名块公钥与 eFuse 中编程的摘要比对并用验证过的公钥校验应用。将活动分区设为新 OTA 应用分区。设备复位加载用 key #N-1 验证过的引导程序再由其启动用 key #N 验证的新应用。新应用用 key #N 验证引导程序作为最终检查然后运行代码吊销 key #N-1即设置KEY_REVOKEeFuse 位。可调用 APIesp_ota_revoke_secure_boot_public_key吊销 key #N-1该接口实现在 esp_ota_ops.c。类似方法也可用于物理重新烧录新密钥物理重刷时可同时更改引导程序内容。可能需要吊销一把当前未使用的密钥。例如活动应用用 key #0 签名但 key #1 泄露则应继续用 key #0 签署新的 OTA 更新并通过esp_ota_revoke_secure_boot_public_key (SECURE_BOOT_PUBLIC_KEY_INDEX_[N])吊销 key #1。吊销后其余未吊销密钥仍可用于签署未来的应用。激进方式Aggressive ApproachROM 代码额外支持在签名验证失败时自动吊销公钥摘要。启用方式烧录SECURE_BOOT_AGGRESSIVE_REVOKEeFuse或启用CONFIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE。密钥吊销仅在 Secure Boot 成功启用后适用。无效签名块或无效镜像摘要不会触发吊销只有签名验证失败即验证镜像第 3 步失败才吊销密钥。一旦密钥被吊销就永远不能用于验证镜像签名。此特性对物理攻击提供强抵抗但如果所有密钥都因验证失败被吊销设备可能被永久变砖。启用CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS会在运行时应用和首次启动启用 Secure Boot 时引导程序都保持未使用摘要槽位不被吊销。除非调试与下载接口完全禁用且远程接口经过完整安全审计否则留下未吊销的密钥槽位可能带来安全风险。技术细节生成与验证签名Secure Boot 已集成到 ESP-IDF 构建系统中启用CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES时idf.py build会签名应用镜像idf.py bootloader会产生已签名引导程序。也可以使用idf.py或openssl独立生成与验证签名。推荐使用idf.py若需在非 ESP-IDF 环境中操作可用openssl命令因为 Secure Boot v2 签名生成与标准签名算法兼容。使用idf.py签名二进制镜像idf.py secure-sign-data --keyfile ./my_signing_key.pem --output ./image_signed.bin image-unsigned.binkeyfile是包含私钥的 PEM 文件。验证签名后的二进制镜像idf.py secure-verify-signature --keyfile ./my_signing_key.pem image_signed.binkeyfile是包含公钥或私钥的 PEM 文件。使用 OpenSSL生成镜像二进制文件的摘要openssl dgst -sha256 -binary BINARY_FILE DIGEST_BINARY_FILEECDSA-P384 方案必须使用 SHA-384openssl dgst -sha384 -binary BINARY_FILE DIGEST_BINARY_FILE用上述摘要生成镜像签名RSA-PSS 签名openssl pkeyutl -sign \ -in DIGEST_BINARY_FILE \ -inkey PRIVATE_SIGNING_KEY \ -out SIGNATURE_FILE \ -pkeyopt digest:sha256 \ -pkeyopt rsa_padding_mode:pss \ -pkeyopt rsa_pss_saltlen:32ECDSA 签名openssl pkeyutl -sign \ -in DIGEST_BINARY_FILE \ -inkey PRIVATE_SIGNING_KEY \ -out SIGNATURE_FILE验证生成的签名RSA-PSSopenssl pkeyutl -verify \ -in DIGEST_BINARY_FILE \ -pubin -inkey PUBLIC_SIGNING_KEY \ -sigfile SIGNATURE_FILE \ -pkeyopt rsa_padding_mode:pss \ -pkeyopt rsa_pss_saltlen:32 \ -pkeyopt digest:sha256ECDSAopenssl pkeyutl -verify \ -in DIGEST_BINARY_FILE \ -pubin -inkey PUBLIC_SIGNING_KEY \ -sigfile SIGNATURE_FILESecure Boot 与 Flash 加密如果 Secure Boot 不与 Flash 加密一起使用攻击者可能发起检查时到使用时time-of-check to time-of-use攻击——在镜像验证并运行之后交换 flash 内容。因此官方强烈建议两者同时启用相关独立文档见 flash-encryption。特殊芯片提醒ESP32-C2它只有一个 eFuse 密钥块同时用于 Secure Boot 与 Flash 加密两个密钥且该密钥块只能烧录一次。因此这两个密钥必须同时烧录无法单独启用 Secure Boot 或 Flash 加密因为后续对 eFuse 密钥块的写入会返回错误。无硬件 Secure Boot 的签名应用验证软件签名验证应用签名也可以在不启用硬件 Secure Boot的情况下在 OTA 更新期间验证对应配置CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT。它使用与 Secure Boot v2 相同的应用签名方案但与硬件 Secure Boot 不同软件签名验证无法抵御对 flash 具有写权限的攻击者攻击者可能绕过签名验证。此模式适用于以下场景启动时 Secure Boot 验证的延迟不可接受且/或威胁模型不包含物理接触或攻击者写入 bootloader/app 分区。工作方式使用当前运行应用签名块中的公钥来验证新更新应用的签名更新过程中不验证运行中应用的签名假定其有效。系统由此建立从运行应用到新更新应用的信任链。因此初始烧录的应用必须签名。应用启动时会检查签名若未找到有效签名则中止且无法进行任何更新防止设备变砖且无法继续更新的情况。应用应在第一位置只放一个有效签名块。与硬件 Secure Boot v2 不同运行中应用的签名在启动时不被验证系统只验证第一位置的签名块并忽略其他追加签名。注意硬件 Secure Boot 支持多受信任密钥但未启用 Secure Boot 的签名检查模式只使用签名块中的第一个公钥验证更新。若需要多把受信任公钥应启用完整 Secure Boot。 除非确定该选项足以满足应用安全需求否则一般建议使用完整的硬件 Secure Boot。如何启用签名应用验证打开 menuconfig Security features。选择App Signing SchemeRSA或芯片默认/支持的 ECDSA (v2)。启用CONFIG_SECURE_SIGNED_APPS_NO_SECURE_BOOT。默认情况下选择Require signed app images选项会启用Sign binaries during build在构建过程中自动签名二进制文件使用Secure Boot private signing key中指定的文件签名。若禁用Sign binaries during build则所有应用二进制必须按远程签名一节的说明手动签名。重要所有烧录的应用都必须签名构建期间或构建后否则无法正常更新。高级特性JTAG 调试默认情况下启用 Secure Boot 时JTAG 调试会通过 eFuse 禁用——引导程序在首次启动时与启用 Secure Boot 同时执行此操作。关于在启用 Secure Boot 或签名应用验证时使用 JTAG 调试的更多信息可参考 ESP-IDF 文档中 jtag-debugging-security-features 章节。小结Secure Boot v2 通过ROM 引导程序 → 第二级引导程序 → 应用镜像的逐级签名校验结合 eFuse 中不可篡改的公钥摘要为 ESP32 系列芯片提供了硬件级代码完整性保护。其核心要点可归纳为理解签名块RSA/ECDSA-256/ECDSA-384的二进制布局与校验规则在首次启动时正确烧录并写保护公钥摘要 eFuse在多密钥芯片上规划密钥轮换与吊销策略保守或激进方式生产环境优先采用远程签名并严格保密私钥最后将 Secure Boot 与 Flash 加密配合使用封堵 TOCTOU 攻击面。以上每一步都可在 secure_boot_v2 源码与 security_features_app 示例工程中找到对应实现与参考配置。【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
