IKEv1 e IKEv2 com chave pré-compartilhada: o que muda na autenticação

Dois gateways configurados com a mesma chave pré-compartilhada concluem um handshake, e uma captura de pacotes não mostra segredo algum cruzando o fio. Essa é a parte de que as pessoas se lembram. A parte interessante é o que cada versão realmente calcula para provar que o segredo é conhecido, porque IKEv1 e IKEv2 constroem essa prova a partir de entradas diferentes e expõem informações diferentes ao fazê-lo. Leia os dois traces lado a lado e a diferença deixa de ser cosmética.

O que a prova precisa alcançar

O Diffie-Hellman dá aos dois pares um valor compartilhado cujas metades públicas qualquer observador também pode calcular. Por si só, isso não prova nada sobre identidade: um atacante que conclui uma troca de chaves tem o mesmo valor compartilhado do seu gateway. A etapa de autenticação existe para amarrar essa troca a um segredo que só os pares pretendidos possuem, e às identidades e aos parâmetros acordados entre eles.

É essa amarração que faz o hash cobrir mais do que a chave. Se cobrisse apenas o segredo, um atacante poderia reexecutá-lo numa troca diferente, com identidades ou propostas diferentes.

IKEv1 no Main Mode: derivar o SKEYID e depois prová-lo

O Main Mode executa seis mensagens. O primeiro par negocia a associação de segurança, o segundo troca valores públicos Diffie-Hellman e nonces, e o terceiro leva identidades mais hashes de autenticação sob a criptografia recém-estabelecida. A RFC 2409 define a construção: com autenticação por chave pré-compartilhada, o SKEYID é derivado do segredo e dos dois nonces, e o material de chave posterior vem do SKEYID, do valor compartilhado Diffie-Hellman, dos cookies e de constantes.

O hash nas mensagens cinco e seis é calculado sobre o valor Diffie-Hellman, os dois cookies, a proposta e a identidade do remetente, com o SKEYID como chave. O receptor o recalcula com o segredo configurado nele. Uma divergência encerra a troca, e em momento algum o segredo em si é um payload.

O Aggressive Mode comprime o mesmo trabalho em três mensagens, o que significa que identidades e hash de autenticação viajam antes de existir um canal criptografado. Isso é uma exposição real para um segredo adivinhável, e é uma questão separada de o segredo ter sido transmitido ou não. O IKEv1 está obsoleto pela RFC 9395, então um trace legado é exercício de diagnóstico, não alvo de implantação.

IKEv2: outra derivação e outro payload AUTH

O IKEv2 não reutiliza o key schedule do IKEv1. As chaves IKE iniciais vêm de uma semente construída com os nonces e o valor compartilhado Diffie-Hellman, e as associações de segurança filhas derivam disso. A chave pré-compartilhada não alimenta a semente de forma alguma.

A autenticação então aparece como payload AUTH. Para autenticação por chave compartilhada, a RFC 7296 especifica uma forma do segredo com preenchimento, obtida ao aplicar hash ao segredo com a string fixa Key Pad for IKEv2, e depois aplicar hash aos dados de troca assinados e à identidade com essa chave com preenchimento. O verificador consegue reconstruir o mesmo valor; um observador não, sem o segredo.

Repare no que mudou. No IKEv1 o segredo é embutido no key schedule antes de o hash de autenticação existir; no IKEv2 o key schedule é independente do segredo e a prova é um payload distinto, ligado aos octetos assinados. Mesma garantia conceitual, maquinário diferente, e é por isso que nomes de parâmetros e capturas não se mapeiam um a um.

O que um observador realmente descobre

Valores públicos Diffie-Hellman, propostas, nonces e cookies são visíveis nas duas versões. Identidades são visíveis no IKEv1 Aggressive Mode e protegidas nos demais casos. O segredo nunca é visível.

Essa última frase tem um limite que vale declarar. Um segredo fraco, escolhido por uma pessoa, pode ser atacado por adivinhação: o atacante calcula qual seria o valor de autenticação para um segredo candidato e compara. O IKEv1 Aggressive Mode torna isso mais barato porque a evidência está em claro, e os padrões alertam sobre segredos de baixa entropia em geral. Nunca transmitir o segredo não é o mesmo que tornar um segredo ruim seguro.

O que fazer com a comparação

Use um segredo único por par de pares, gere-o de uma fonte aleatória e gire-o pelo mesmo caminho de provisionamento que o distribuiu. Se o segredo fica num modelo de configuração que vai para todas as filiais, um comprometimento num site é um comprometimento em todos.

Prefira autenticação baseada em certificados onde o custo operacional for aceitável, pois ela elimina o problema de adivinhar o segredo compartilhado e dá a cada par uma identidade distinta. Onde uma chave pré-compartilhada permanecer, mantenha-a longa, limite seu escopo e trate a versão do IKE como decisão de segurança, não como detalhe de interoperabilidade.