O que uma chave pré-compartilhada faz em IPsec, OpenVPN e WireGuard

As palavras chave pré-compartilhada aparecem na documentação de IPsec, OpenVPN e WireGuard, e descrevem três objetos diferentes. Um é um segredo de autenticação, outro protege um canal de controle e o terceiro adiciona material a um handshake que já tem identidades. Tratá-los como intercambiáveis produz uma conexão que falha em uma etapa que ninguém esperava. Leia o que o campo faz naquele protocolo antes de copiar um valor para ele.

Três protocolos, três significados

Cada protocolo define a tarefa da chave na sua própria especificação, e as tarefas não se sobrepõem. Um segredo de autenticação prova que dois pares conhecem o mesmo valor. Uma chave de canal de controle protege a negociação que vem depois. Um complemento de handshake muda o cronograma de chaves sem mudar quem são os pares.

Nenhum desses papéis autentica um usuário humano, e é essa confusão que custa mais tempo. Uma chave pré-compartilhada é provisionada em dispositivos ou gateways antes da troca, então todo portador parece idêntico para o outro lado. Essa propriedade é uma vantagem para um link site a site entre dois roteadores e um risco para um serviço de acesso remoto com funcionários nomeados. Mantenha a credencial da conta e o segredo criptográfico em colunas separadas do documento que descreve a implantação.

IPsec e OpenVPN usam a palavra de modo diferente

O IKEv2 pode autenticar um par com um segredo pré-compartilhado em vez de certificados, e o valor deve coincidir nas duas pontas. Como o mesmo segredo costuma ser configurado para um grupo de pares, qualquer portador pode se passar pelos outros, e a troca não ganha sigilo futuro a partir de chaves de identidade que nunca teve.

As opções tls-auth e tls-crypt do OpenVPN anexam uma chave estática ao canal de controle, acrescentando uma assinatura HMAC ou cifrando a própria negociação. Essa chave não é uma senha de usuário e não substitui o certificado do cliente. Distinguir as duas coisas importa na hora da renovação, quando uma troca de senha deixa a chave do canal de controle intacta.

A PSK do WireGuard acrescenta, não identifica

Os pares do WireGuard já têm chaves públicas e privadas Curve25519, e o handshake autentica essas identidades. Uma chave pré-compartilhada opcional é misturada à chave de encadeamento, contribuindo com material simétrico por cima da troca de chaves públicas.

Ela não fornece identidade própria nem conta de usuário, então um operador não consegue distinguir dois portadores pela PSK. As duas pontas precisam carregar o mesmo valor, senão o handshake falha sem uma mensagem de erro útil. É por isso que a rotação tem de ser planejada dos dois lados ao mesmo tempo, e não como a edição de um único arquivo.

Verifique distribuição, rotação e remoção

A distribuição é o ponto fraco de todo projeto que usa um segredo em muitos lugares. Um valor colado em uma janela de chat, guardado em um repositório ou reutilizado entre ambientes acumula cópias que ninguém consegue enumerar, e cada cópia amplia silenciosamente o raio de dano.

Texto Base64 não é criptografia. Um segredo guardado ao lado de um certificado público no mesmo diretório continua sendo um segredo em texto claro.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Faça a rotação em um calendário e depois de qualquer exposição suspeita, atualizando cada par previsto antes de revogar o valor antigo. Em seguida, teste o link pelas duas pontas, porque uma chave que não coincide falha no handshake e parece exatamente um problema de firewall.

Documente qual segredo protege qual etapa, para que um reset de senha nunca seja confundido com a renovação de uma chave criptográfica. Essa linha economiza uma hora toda vez que alguém audita a implantação.