• 问题总结

攻击者可能通过故障注入在 ESP32 芯片的启动阶段绕过安全启动的摘要验证，并从 Flash 启动未经验证的代码，给 ESP32 CPU 的安全带来隐患。

故障注入攻击无法禁用 Flash 加密功能，因此如果 ESP32 已启用安全启动和 Flash 加密的推荐配置，则影响可降至最低；但如果 ESP32 未启用 Flash 加密功能，则芯片可能在遭受故障注入攻击后执行任何代码。

为了保护已启用了 Flash 加密和安全启动功能的设备能够抵挡此类攻击，如果该设备尚未永久启用 Flash 加密，则必须修改固件使已出厂设备永久启用 Flash 加密（具体信息请参阅下文“ 给 ESP32 用户的建议 ” ）。

Riscure 的两位安全分析师 Yashin Mehaboobe 和 Santiago Cordoba Pellicer 发现并向乐鑫披露了这个问题。同时，这个问题也由 LimitedResults 独立发现并披露。乐鑫感谢这两家公司负责任地披露了这个问题。

• 什么是故障注入？

故障注入是一种通过物理方式注入故障来破坏硬件系统行为的技术，这些方式通常是通过精准定时的电压或时钟波动。要实现故障注入，攻击者必须具有对硬件的物理访问权限才能对其进行修改并注入故障。

故障注入后，系统通常会崩溃。但是，有时一个精准定时的故障可能会导致 CPU 跳过特定指令或者破坏特定计算结果。通过大量重复故障注入的过程，攻击者最终可能会绕过安全措施。

尽管引发故障的难度各不相同，但所有电子设备都容易受到某些类型的物理故障注入的影响。

• 进一步的工作

2019 年 5 月，乐鑫与 Riscure 的安全分析师合作，审查了 ESP32 ROM 中的引导代码，包括为防止故障注入而进行的强化修改。带有更新了 ROM 中 Secure Boot 代码的 ESP32 芯片将于今年第 4 季度发布。

相比于 ESP32，乐鑫即将推出的 ESP32-S2 芯片增加了防御故障注入的额外措施，以增强它对故障注入的防御能力，在 2019 年 4 月，某外部安全分析师也对 ESP32-S2 ROM 中 Secure Boot 代码进行了审查。

• 披露历史

4 月 8 日：Riscure 的安全分析师联系乐鑫，报告了在 ROM 中使用针对 ESP32 安全启动的故障注入后的结果。

5 月 14 日：Riscure 开始审查现有的 ESP32 ROM 中的引导代码和安全启动功能。

6 月 5 日：乐鑫收到来自 LimitedResults 的视频，演示了针对 ESP32 安全启动的故障注入。

8 月 2 日：LimitedResults 提供了一份概念验证报告，论证了针对 ESP32 安全启动的故障注入。

• 给 ESP32 用户的建议

现在所有使用 ESP32 上的安全启动和 Flash 加密功能的用户都应尽快将 ESP-IDF 升级到 3.0.9，3.1.6，3.2.3，3.3.1 版本。这些版本以及 ESP-IDF v4.0 和继它之后的更新版本都将包含一个补丁，该补丁会使安全启动在使用时，永久启用 Flash 加密，阻止 Flash 加密被暂时禁用。

更新后的应用程序可以通过 OTA 方式升级到已出厂设备，不需要更新任何 ESP-IDF 引导加载程序。

不想等待新的 ESP-IDF 版本的用户可以修补 ESP-IDF V3.2.x 应用程序，在 app_main() 函数或类似的启动过程中调用以下 API：

#include <esp_flash_encrypt.h>

void app_main()

{

   if (esp_flash_encryption_enabled()) {

       esp_flash_write_protect_crypt_cnt();

   }

   // continue normal startup

}

使用 v3.2 之前的 ESP-IDF 版本的用户可以选择更新或将 esp_flash_write_protect_crypt_cnt() 函数从新的 ESP-IDF 版本复制到固件应用程序代码中，然后通过如上所示的 API 调用它。如果您在此过程中需要技术帮助，请联系乐鑫的技术支持。