Secure Boot e flash encryption são controles valiosos, não uma caixa marcada que torna um produto IoT seguro. O primeiro responde “qual código pode executar?”; o segundo reduz o valor da leitura física da flash. NVS encryption pode proteger dados selecionados. A configuração de eFuses, custódia de chaves, fixtures de fabricação, recuperação e assistência define se tudo continua seguro fora do laboratório.
Secure Boot verifica assinaturas na cadeia do bootloader e da aplicação. Não criptografa firmware nem protege automaticamente todos os dados. Flash encryption cifra conteúdo compatível em flash externa, mas sozinha não garante que apenas código confiável execute. NVS encryption pode proteger registros sensíveis; ainda são necessários protocolos autenticados e autorização no servidor.
Chaves de assinatura autorizam código de toda a família de produtos. Gere-as com boa entropia, limite o acesso, não as coloque em repositórios ou logs e planeje backup, rotação e resposta a comprometimento. Uma chave vazada é incidente de produto.
Em produção, use uma chave de flash única por dispositivo. eFuses guardam configuração que pode ser gravada uma única vez; uma opção errada pode desligar debug ou dificultar recuperação. Modos de desenvolvimento e release do ESP-IDF diferem. Teste chip, revisão, SDK, partições e linha de fabricação em unidades sacrificiais antes de gravar configurações irreversíveis.
Defina o fluxo da estação: identificar placa, provisionar material único, gravar imagem assinada aprovada, ativar configurações, verificar o boot e registrar resultado por serial. Restrinja acesso às fixtures e impeça segredos nos logs. Unidades retrabalhadas, devolvidas ou descartadas precisam de processo explícito para que não retornem ao estoque com identidade repetida.
Segurança de produção pode limitar JTAG ou comandos ROM download, afetando diagnóstico e reparo. Defina antes um modo de serviço autorizado, autenticado, restrito e auditável. Reset de fábrica não restaura confiança de fábrica: pode apagar dados do app sem desfazer eFuses nem trocar a identidade.
| Controle | Proteção principal | Risco residual |
|---|---|---|
| Secure Boot | Rejeita imagens executáveis não autorizadas. | Chave comprometida ou vulnerabilidade em código assinado. |
| Flash encryption | Reduz utilidade da leitura física da flash. | Não prova autenticidade sozinha nem protege segredos em runtime. |
| NVS encryption | Protege configurações armazenadas selecionadas. | O app ainda pode expor dados por logs e APIs. |
| Anti-rollback | Rejeita firmware abaixo do piso de segurança. | Restringe recuperação; planeje versões. |
| Limites de debug | Reduz caminhos alternativos de acesso. | Pode impedir reparo legítimo sem processo de serviço. |
Ensaie OTA assinado, assinatura inválida, falta de energia, partição errada, perda de chaves, revogação de firmware e retorno de campo. Verifique logs seriais sem vazar dados. Preserve imagem de recuperação assinada e confirme que rollback continua permitido com anti-rollback ativo. Documente o que é reversível, o que grava eFuse e quem aprova.
Use Secure Boot para autenticidade de código, flash encryption para confidencialidade em repouso e NVS encryption para segredos armazenados selecionados. São camadas de um modelo maior. Chaves por dispositivo, planejamento de eFuses, fabricação controlada e reparo autorizado importam tanto quanto menuconfig. Valide o ciclo completo no chip final.