Chaves WireGuard no ESP32: por dispositivo ou uma só integrada?

O esboço coloca a chave privada do WireGuard numa matriz de caracteres, e o túnel funciona, por isso a pergunta volta sempre. A decisão que realmente tem de tomar não é «isto é seguro» mas «qual de três condições se aplica a esta implementação». São: quem pode segurar fisicamente o dispositivo, o que uma leitura da flash revela na sua peça, e se a frota partilha uma chave ou cada unidade leva a sua. Responda a isso e o desenho decorre, porque cada condição altera o custo de uma chave exposta, não o facto de poder ser exposta.

O que a chave autoriza

O WireGuard autentica os pares com a chave pública. O servidor associa a chave pública de cada par a um endereço e a uma AllowedIPs lista, pelo que é a chave privada que permite a um cliente enviar tráfego a partir desse endereço.

A mesma entrada decide que destinos o dispositivo pode alcançar, pelo que uma chave exposta revela a rede atrás do túnel e também o endereço do túnel.

Condição um: quem pode segurar o dispositivo

Se a unidade vive num armário fechado e ninguém fora da sua equipa lhe toca, a exposição é sobretudo uma questão de distribuição de firmware. Se é enviada para clientes, fica num veículo ou regressa ao abrigo da garantia, a posse física é a credencial e o sigilo do binário é secundário. Quem tem o dispositivo na mão não precisa de ler a chave, porque o firmware em execução abrirá o túnel por ele. Por isso a resposta do lado do servidor tem de incluir revogação e um tempo de vida limitado, não apenas uma imagem protegida.

Decida esta condição antes das outras duas, porque define o orçamento de ambas.

Condição dois: o que uma leitura da flash revela

Quem consiga ler a imagem da flash recupera uma chave guardada como literal, seja por uma ligação de depuração, um ficheiro de atualização, uma cópia de segurança ou uma unidade devolvida. A cifragem da flash encarece um dump direto, e a documentação do ESP-IDF descreve o que a funcionalidade cobre para uma peça e configuração dadas. Não impede a extração da chave em todos os modelos de ataque e não faz nada para o caso de o dispositivo estar na mão. Trate-a como uma camada que muda o custo, não como a resposta.

Leia a documentação da plataforma para o seu chip e configuração exatos antes de afirmar uma propriedade numa revisão de projeto.

Condição três: reutilização em toda a frota

Uma chave para uma série de produção significa que cada unidade partilha uma identidade. O servidor não consegue distingui-las nos registos, não consegue revogar uma sem revogar todas, e não consegue distinguir um clone de um original. Chaves por dispositivo resolvem as três, ao custo de um passo de registo e de um mapeamento do número de série para a chave pública. Esse mapeamento é o ativo que transforma a revogação numa alteração de uma linha em vez de um reflash de toda a frota.

Se a frota são cinco unidades numa bancada, partilhar uma chave pode ser uma troca razoável. Se são quinhentas no terreno, não é troca nenhuma.

O padrão de registo que torna as chaves por dispositivo práticas

Gere o par de chaves no dispositivo no primeiro arranque, guarde a metade privada em armazenamento não volátil protegido e envie apenas a chave pública para um serviço de registo que atribua um endereço e escreva a entrada de par. Autentique a resposta de registo, senão um atacante na rede local pode registar a própria chave na sua conta. Nunca imprima a chave privada na consola série durante o aprovisionamento. Registe o número de série do dispositivo ao lado da chave pública, para que uma unidade perdida corresponda exatamente a uma entrada de par.

É um serviço pequeno, e é a diferença entre uma frota que pode auditar e uma frota que só pode reflashar.

Tempo, extremos e a decisão

O exemplo sincroniza o tempo antes de iniciar o túnel, e isso conta para além do TLS: os apertos de mão do WireGuard transportam um carimbo temporal para proteção contra repetição, pelo que um dispositivo que arranque com o relógio errado pode ver apertos rejeitados. O extremo é um nome de anfitrião, o que coloca o DNS no caminho de confiança ainda que a chave pública do servidor continue a autenticar o par. Um endereço errado desperdiça tentativas e revela quando o dispositivo está online. Resolva ambos antes de discutir a chave.

Depois decida: uma chave partilhada apenas enquanto a posse estiver controlada e a frota for pequena, chaves por dispositivo assim que uma das duas deixar de ser verdade.