Eu estava fazendo VPN IPsec no ASA 8.0 e entendo um pouco sobre isso. O iniciador inicia enviando sua política ISAKMP para o respondente e o respondente envia de volta a política correspondente. Depois disso, a chave Diffie-Hellman recebe troca e, em seguida, ambas enviam a chave pré-compartilhada à outra para autenticação.
Agora temos duas chaves:
Qual chave é usada para criptografar a chave pré-compartilhada?
Você fez uma ótima pergunta. A pergunta parece muito simples, mas na verdade a resposta é um pouco mais complexa. Eu farei o meu melhor para responder de uma maneira sucinta. Além disso, desde que você mencionou o ISAKMP, assumirei que você está interessado no IKEv1. As coisas mudam um pouco para o IKEv2 (bem, muito), mas eu queria mencionar a resposta abaixo apenas se correlaciona com o IKEv1.
A fase 1 pode ser realizada em dois mods diferentes: modo principal e modo agressivo. Nos dois modos, a primeira mensagem é enviada pelo Iniciador e a segunda mensagem é enviada pelo Respondente. Ambas as mensagens incluem o que é conhecido no mundo da criptografia como um Nonce . Um Nonce é simplesmente um número gerado aleatoriamente para usar na geração de chaves. (o termo Nonce vem de _N_umber usado _Once_) . Assim, após a mensagem 1 e a mensagem 2, os dois lados conhecem os Nonces um do outro.
Os Nonce's são combinados com a Chave pré-compartilhada para criar um valor Seed para gerar chaves secretas. A parte relativa do IKE RFC está aqui:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID é o valor Seed que mais tarde será usado para gerar chaves secretas adicionais. A chave pré-compartilhada e os dois valores de Nonce (Ni_b é o Nonce do iniciador e Nr_B é o Nonce do respondente) são combinados usando uma função aleatória PRF ou Psuedo. Um PRF é como um algoritmo de hash, exceto que o resultado pode ser quantos bits você precisar.
Agora, se você estava inicialmente no Modo Principal, as mensagens 3 e 4 compartilham as chaves públicas Diffie-Hellman do Iniciador e do Respondente (respectivamente). Ambos usam esses valores para gerar o segredo compartilhado Diffie-Hellman . Se você estava usando o modo Agressivo, esses valores do DH Public também estão incluídos na Mensagem 1 e na Mensagem 2 (junto com os Nonces).
O valor de propagação é então combinado com o segredo compartilhado do DH (e alguns outros valores) para criar três chaves de sessão : uma chave derivada, uma chave de autenticação e uma chave de criptografia. A RFC declara assim:
O resultado do modo principal ou do modo agressivo são três grupos de material de chave autenticado:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a e _e são as três chaves de sessão mencionadas acima. SKEYIDé o valor da semente. g^xyé o segredo compartilhado do DH. CKY-Ie CKI-Rsão os Cookies de iniciador e de resposta, são apenas valores adicionais gerados aleatoriamente que são usados posteriormente para identificar essa associação de troca e segurança ISAKMP específica. 0 1 2são os números literais 0, 1 e 2. O símbolo Pipe |representa concatenação.
De qualquer forma, todos esses valores são combinados usando um PRF que cria três chaves de sessão:
A chave de autenticação e a chave de criptografia são usadas para proteger / criptografar a negociação da fase 2 subsequente. No modo principal, as mensagens 5 e 6 da fase 1 também são protegidas por essas teclas. Além disso, quaisquer futuras trocas de informações ISAKMP (DPD, eventos de nova chave, excluir mensagens etc.) também são protegidas por essas duas chaves.
A Chave Derivada é entregue ao IPsec, e o IPsec gera seu próprio material de Chave a partir dessa Chave. Se você se lembra, o IPsec não inclui um mecanismo de troca de chaves de forma inata, portanto, a única maneira de adquirir chaves secretas é defini-las manualmente (o que é arcaico e nunca mais realmente feito), ou depender de um serviço externo para forneça o material de chave, como ISAKMP.
A RFC diz assim:
SKEYID_e é o material de chave usado pelo ISAKMP SA para proteger a confidencialidade de suas mensagens.
SKEYID_a é o material de chave usado pelo ISAKMP SA para autenticar suas mensagens.
SKEYID_d é o material de chave usado para derivar chaves para associações de segurança não-ISAKMP.
Com tudo isso dito, podemos voltar à sua pergunta: Qual chave é usada para proteger a chave pré-compartilhada?
No modo principal, a chave pré-compartilhada (PSK) é verificada nas mensagens 5 e 6. As mensagens 5 e 6 são protegidas pelas teclas de sessão geradas pelo ISAKMP, descritas acima.
No modo agressivo, nenhuma das mensagens na negociação é criptografada. E o PSK é verificado nas mensagens 2 e 3. Observe que nos dois casos o PSK é verificado e nunca disse que o PSK é trocado . Obviamente, se nada no modo Agressivo for Criptografado e você simplesmente enviou a Chave Pré-Compartilhada através da conexão sem criptografia, haveria uma enorme vulnerabilidade de segurança.
Para nossa sorte, os escritores do ISAKMP já pensaram nisso. E, como resultado, eles criaram um método especial para verificar se cada parte tem o PSK correto, sem realmente compartilhá-lo. Existem dois itens usados para validar para cada par que ambos têm o mesmo PSK: o método de identidade e o hash de identidade .
Os pares de VPN podem optar por se identificar por vários métodos; o mais comum é que os colegas simplesmente usem o endereço IP de origem. Mas eles têm a opção de usar um FQDN ou nome de host. Cada um deles, juntamente com o valor correlacionado para o método escolhido, é o que compõe o método de identidade. Por exemplo, se eu tivesse o IP 5.5.5.5 e desejasse usar meu endereço IP para me identificar, meu método de identificação seria efetivamente [Endereço IP, 5.5.5.5] . (Nota: AMBOS os valores compõem todo o método de identificação)
O método ID é então combinado (usando um PRF) com o valor Seed discutido anteriormente (SKEYID) e alguns outros valores, para criar o Identity Hash . Lembre-se de que o que foi criado na criação do SKEYID foi a Chave Pré-Compartilhada.
O método de identificação e o hash de ID são então enviados através da ligação e a outra parte tenta recriar o hash de ID usando a mesma fórmula. Se o destinatário conseguir recriar o mesmo ID Hash, ele prova que o remetente deve ter a chave pré-compartilhada correta.
Isso é descrito na RFC aqui:
Para autenticar, trocar o iniciador do protocolo gera HASH_I e o respondente gera HASH_R em que:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii e IDir são o método de identificação. E HASH_I e HASH_R são os hashs Iniciador e Respondente. Ambos são compartilhados na Fase1. Do RFC:
Ao fazer uma autenticação de chave pré-compartilhada, o Modo Principal é definido da seguinte maneira:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RO modo agressivo com uma chave pré-compartilhada é descrito a seguir:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
E agora, finalmente podemos responder à sua pergunta completamente:
A chave pré-compartilhada é combinada usando um PRF com Nonces e vários outros valores conhecidos por qualquer outra pessoa na negociação. O resultado é um valor que só pode ser alcançado mutuamente por duas partes se ambas começarem com os mesmos valores - ou seja, a mesma chave pré-compartilhada. O valor resultante é o que é compartilhado na conexão, permitindo que duas partes verifiquem se possuem chaves pré-compartilhadas correspondentes, sem expor realmente nenhuma informação sobre a própria chave pré-compartilhada.
O Modo Principal dá um passo mais seguro, também criptografando a troca do "valor resultante" descrito acima, tornando ainda mais difícil extrair qualquer informação útil sobre o que era a Chave Pré-Compartilhada.
(parece que falhei miseravelmente em responder isso de forma sucinta)
Sua resposta está na sua pergunta: A troca Diffie-Hellman é usada para gerar uma chave comum para trocar com segurança uma chave comum (ou seja, pré-compartilhamento).
Veja isto: /security/67953/understanding-diffie-hellman-key-exchange
fonte