完整的 ESP32 物联网设备安全指南
发布: (2026年1月10日 GMT+8 22:37)
12 分钟阅读
原文: Dev.to
Source: Dev.to
请提供您希望翻译的具体文本内容，我将按照要求保留源链接、格式和技术术语，仅翻译正文部分。谢谢！
1. 内置 ESP32 安全特性
| 功能 | 描述 |
|---|---|
| 安全启动（v1 与 v2） | 确保只有签名固件能够运行。 |
| 闪存加密 | 对存储在外部闪存中的所有数据进行加密。 |
| 硬件随机数生成器 | 用于加密的真随机数生成器。 |
| AES / SHA / RSA / ECC 加速器 | 快速的硬件加速密码运算。 |
| 电子熔丝 | 用于永久配置的一次性可编程位。 |
| 内存保护 | 防止未授权的读取/写入。 |
| 安全密钥存储 | 将密钥保存在硅片内部，永不暴露给软件。 |
这些特性协同工作，确保只有受信任的固件在设备上运行，敏感数据保持加密，且密码运算高效安全。
2. 威胁概览
| 威胁 | 典型攻击向量 |
|---|---|
| 物理访问 | 直接探测、闪存提取 |
| 固件提取 | UART、SPI 闪存读取 |
| 恶意 OTA 更新 | 被篡改的固件镜像 |
| Wi‑Fi 中间人攻击 (MITM) | 恶意接入点、数据包嗅探 |
| 凭证泄露 | 硬编码密码、日志 |
| 云 API 滥用 | 被盗令牌、重放攻击 |
| 设备克隆 | 重复 ID、伪造硬件 |
良好的安全设计假设攻击者可能拥有临时物理访问和完整网络可视性。
3. 安全启动
3.1 概述
安全启动保证只有您签名的固件能够运行。如果攻击者修改了固件，设备将拒绝启动。
| 版本 | 要点 |
|---|---|
| Secure Boot v1 | 基于 RSA 的签名验证 |
| Secure Boot v2 | 改进的密钥管理，支持更强的算法（推荐用于新项目） |
3.2 实现步骤
- 在离线安全机器上生成密钥。
- 绝不要在源码仓库中存放私钥。
- 将公钥哈希写入 eFuse（一次性）。
- 使用私钥对固件镜像进行签名。
- 启动时，ROM 引导加载程序 验证签名。
- 若验证失败，启动被中止。
最佳实践
- 在开发早期就 启用安全启动。
- 测试完成后 锁定 eFuse。
4. Flash 加密
Flash 加密可保护存储在外部 flash 中的固件和数据。若未启用加密，任何拥有物理访问权限的人都可以读取固件和机密信息。
4.1 加密内容
- 应用固件
- Wi‑Fi 凭证
- API 令牌
- 证书
- 存储在 flash 中的自定义数据
4.2 工作原理
- ESP32 使用 AES‑XTS 加密。
- flash‑encryption key 安全存放在 eFuse 中。
- 对 flash 的所有读写都是 透明 的——硬件会自动进行加密/解密。
4.3 模式
| 模式 | 描述 |
|---|---|
| Development | 允许重新烧写（适用于原型开发）。 |
| Release | 永久锁定加密（用于量产）。 |
最佳实践
- 在大规模生产前切换到 release 模式。
5. eFuses
eFuses 是 ESP32 内部的一次性可编程位。它们控制关键的安全特性。
5.1 重要的 eFuse 用途
- 安全启动密钥哈希
- Flash 加密密钥
- 禁用 JTAG
- 禁用 UART 下载模式
- 配置调试访问
5.2 建议
- 在量产前规划 eFuse 使用。
- 记录 每个阶段烧录了哪些 eFuse。
- 使用 脚本（或 CI 流水线）以确保编程一致。
- 避免在生产线上手动烧录——一旦烧录，eFuse 无法撤销。
6. 调试接口（UART / JTAG）
调试端口在开发期间很有用，但在生产环境中可能带来风险。
| 操作 | 如何确保安全 |
|---|---|
| 禁用 JTAG | 烧录相应的 eFuse。 |
| 禁用 UART 引导加载程序（如果使用 OTA） | 烧录 UART 禁用 eFuse。 |
| 要求对任何调试接口进行身份验证 | 如有需要，实施自定义引导加载程序逻辑。 |
注意： 保持调试端口开放是最常见的 ESP32 安全错误之一。
7. Wi‑Fi 安全
7.1 网络配置
- 始终使用 WPA2 或 WPA3。
- 绝不在生产设备上使用开放网络。
7.2 凭证配置
| 方法 | 好处 |
|---|---|
| 基于 BLE 的加密配置 | 安全、用户友好。 |
| 临时 AP 模式（一次性密码） | 首次设置简便。 |
| 基于二维码的配置 | 快速、带外。 |
- 绝不要在未加密的通道中泄露 Wi‑Fi 凭证。
8. 安全通信
所有 ESP32 与服务器之间的通信必须加密。
- ESP‑IDF 通过 mbedTLS 并使用硬件加速来支持 TLS。
8.1 关键要点
- 始终使用 HTTPS 或 基于 TLS 的 MQTT。
- 验证服务器证书（不要禁用验证）。
- 在可能的情况下使用证书固定。
- 为了降低内存使用，优先选择 ECC 证书。
8.2 常见陷阱
- 禁用证书验证。
- 使用过时的 TLS 版本（例如 TLS 1.0）。
- 将私钥直接嵌入固件中。
9. 设备身份与认证
每个 ESP32 设备都应拥有 唯一身份。
| 身份类型 | 实现方式 |
|---|---|
| 制造时烧录的设备 UUID | 存储在 eFuse 或 OTP 存储器中。 |
| 每设备证书 | 用于双向 TLS。 |
| 带轮换的基于令牌的认证 | 从安全服务器获取短期令牌。 |
| 硬件支持的密钥 | 利用 ESP32 的安全密钥存储。 |
切勿在所有设备之间共享单一 API 密钥。
10. 空中升级 (OTA) 更新
OTA 更新功能强大，但如果被篡改则非常危险。
10.1 安全 OTA 工作流
- 签署固件镜像（使用与安全启动相同的密钥）。
- 在设备上验证签名，然后再进行安装。
- 通过 TLS 下载。
- 实现回滚保护（防止降级到存在漏洞的固件）。
- 安全存储更新元数据（例如版本号、哈希值）。
ESP32 支持 安全 OTA，并将签名验证与安全启动集成。
11. Secret Management
| Bad Practice | Secure Alternative |
|---|---|
| 在源代码中硬编码 API 密钥 | 存储在加密闪存中或使用安全元件。 |
| 以明文存储密码 | 在运行时派生密钥，使用密钥派生函数。 |
| 在日志中打印机密信息 | 对机密数据进行脱敏或避免记录。 |
| 通过调试命令泄露机密信息 | 限制调试访问，要求身份验证。 |
| 未轮换凭证 | 定期轮换，使用短期令牌。 |
从服务器获取短期令牌并定期轮换凭证。
12. 云端安全
设备安全并不止于硬件。
- 对每个设备进行单独认证（相互 TLS、JWT 等）。
- 实施速率限制以减轻暴力破解攻击。
- 验证负载（模式、大小、内容）。
- 对 API 使用基于角色的访问控制 (RBAC)。
- 记录可疑行为并触发警报。
您的云应 假设某些设备最终可能被攻陷，并设计成能够遏制其影响。
13. 生产检查清单
| 步骤 | 描述 |
|---|---|
| 刷写最小可信引导加载程序 | 降低攻击面。 |
| 烧录安全启动密钥 | 实现固件真实性。 |
| 烧录闪存加密密钥 | 保护静态数据。 |
| 编程设备身份 | 唯一的每台设备 ID 或证书。 |
| 锁定调试接口 | 根据需要禁用 JTAG/UART。 |
| 验证启动和连接 | 自动化健全性测试。 |
| 实现全自动化 | 避免手动步骤；使用 CI/CD 流水线。 |
14. 持续维护
- 安全不是一次性任务。
- 从第一天起支持 OTA 更新，以快速修补漏洞。
- 监控 ESP‑IDF、第三方库以及硬件本身的漏洞。
- 定期审计 你的代码、构建过程和部署流水线。
为构建安全 ESP32‑基物联网解决方案的开发者准备。
P‑IDF 安全检查清单
通用实践
- 在可能的情况下轮换密钥。
- 为设备退役做好规划。
- 提供执行安全擦除的出厂重置。
- 将安全特性视为其他特性——必须 测试。
测试与验证
- 尝试提取固件。
- 尝试无签名固件启动。
- 对 TLS 流量进行中间人攻击。
- 重放指令数据包。
- 进行电源扰动测试（如果需要高安全性）。
- 记录测试结果，并对 每个版本 重复测试。
常见陷阱需避免
- 将安全启动保持为禁用。
- 未使用闪存加密。
- 使用共享凭证。
- 禁用 TLS 验证。
- 暴露调试接口。
- 仅依赖网络安全。
为什么重要
ESP32 提供强大的安全能力，但仅在正确使用时才有效。
许多不安全的物联网设备的出现 并非 因为 ESP32 本身薄弱，而是因为安全性被事后才考虑。
一个安全的 ESP32 设备需要在每一层都加以关注——从硅芯片和引导加载程序到固件、网络、云端以及制造环节。
- 专业/商业物联网产品： 启用安全启动、闪存加密、正确的设备身份以及安全 OTA 更新是 强制性 的。
- 业余项目： 遵循这些实践可为实际部署做好准备并保护用户。
安全是一个过程，而非功能。
及早开始，精心设计，并把每个 ESP32 设备都视作会受到攻击——因为最终，它们一定会被攻击。