Em 2016, uma botnet chamada Mirai derrubou parte da internet mundial explorando um problema banal: milhares de câmeras, roteadores e gravadores de vídeo saíam de fábrica com a mesma senha padrão, nunca trocada pelo instalador. Um único conjunto de credenciais, vazado uma vez, comprometeu uma fração significativa dos dispositivos IoT conectados no planeta.
Quase dez anos depois, esse padrão continua comum em equipamentos industriais: certificado TLS único, gravado em fábrica, idêntico em toda a linha de produção. Funciona — até vazar. E quando vaza, não compromete uma unidade. Compromete todo o parque instalado.
O problema técnico, sem exagero
Pensa no que um certificado TLS realmente garante: que o dispositivo do outro lado da conexão é quem diz ser, e que a comunicação está criptografada ponta a ponta. Se todos os dispositivos de uma linha usam o mesmo par de chaves, essas duas garantias colapsam:
- Não dá pra revogar um dispositivo sem quebrar todos os outros. Se uma unidade for comprometida fisicamente (furtada, clonada, invadida), a única forma de reagir é revogar o certificado — e isso derruba a autenticação de toda a frota, inclusive das unidades que nunca foram tocadas.
- Um vazamento único vira um vazamento em massa. Extrair a chave privada de um dispositivo (engenharia reversa de firmware, por exemplo) dá acesso à identidade criptográfica de todos os equipamentos daquele modelo — não só daquele.
- Não existe rastreabilidade por unidade. Do ponto de vista da rede, todo dispositivo “é” o mesmo certificado. Auditoria e resposta a incidente ficam cegas para saber qual unidade física realmente fez o quê.
Como o SIG-1 resolve isso: uma identidade criptográfica por unidade
Cada SIG-1 gera seu próprio par de chaves ECC P-256 (prime256v1) no primeiro boot — não em fábrica, não copiado de um template, gerado ali, naquele hardware específico. O Common Name do certificado é derivado do endereço MAC daquele dispositivo, e a validade é de 10 anos. Isso significa:
- Comprometer uma unidade não compromete as outras. Revogar ou substituir o certificado de um SIG-1 não afeta em nada os demais.
- Cada dispositivo é identificável de forma única na rede — o certificado é a identidade.
- Não existe “chave mestra” armazenada em nenhum lugar central que, se vazada, derruba a segurança de toda a frota.
Escolhemos ECC P-256 em vez de RSA (nossa primeira geração usava RSA 2048 compartilhado) por dois motivos práticos: chaves menores exigem menos memória e CPU no handshake TLS — relevante num microcontrolador, não num servidor — e o processo de geração em runtime fica rápido o suficiente pra rodar no primeiro boot sem atraso perceptível.
E se a geração falhar? A rede de segurança, sem abrir mão da segurança
Hardware embarcado tem um jeito particular de falhar: heap insuficiente num boot ruim, sistema de arquivos corrompido, uma condição de borda rara. Se isso acontecer bem no momento de gerar o certificado, e não houver um certificado já persistido de uma geração anterior, o SIG-1 tem um certificado de emergência gravado no próprio firmware — só pra garantir que a porta HTTPS suba de qualquer jeito, em vez do dispositivo ficar mudo na rede.
É importante ser transparente sobre o que isso é e o que não é: esse certificado de emergência não é o mecanismo normal de operação — é o cinto de segurança que só entra em cena numa falha catastrófica, e mesmo nesse cenário, o dispositivo tenta gerar seu certificado único de novo no próximo boot. A regra de identidade única por unidade continua sendo o comportamento padrão do produto.
Manutenção automática, sem depender de alguém lembrar
Certificado que expira sem ninguém perceber é outro clássico problema de campo — geralmente descoberto quando o sistema já está fora do ar. O SIG-1 roda um monitor em segundo plano que checa a validade do certificado periodicamente (a cada 12 horas, com a primeira verificação ocorrendo pouco depois do boot) e renova automaticamente quando restam 30 dias ou menos, sem intervenção manual.
Defesa em camadas, não só no transporte
O certificado protege a camada de transporte, mas o SIG-1 não para por aí: cada sessão de API usa um token de 128 bits vinculado ao IP de origem, com expiração deslizante de 1 hora — então mesmo que alguém capture um token, ele não funciona de outro endereço IP. E comunicação entre unidades SIG-1 (ações remotas peer-to-peer) usa assinatura HMAC-SHA256 com proteção anti-replay, independente da camada TLS.
O ponto central
Segurança de verdade em IoT industrial não é sobre ter criptografia — quase todo produto no mercado já tem. É sobre cada unidade ter sua própria identidade, de forma que o compromisso de uma nunca vire o compromisso de todas. É uma decisão de arquitetura que não aparece em nenhuma foto de produto, mas é exatamente o tipo de detalhe que separa um dispositivo pronto pra ambiente industrial real de um projeto de prateleira.
Quer entender como a arquitetura de segurança do SIG-1 se encaixa no seu projeto específico? Fale com o time Solinski.
