Je faisais IPsec VPN sur ASA 8.0, et je comprends un peu cela. L'initiateur commence par envoyer sa stratégie ISAKMP au répondeur, et ce dernier renvoie la stratégie correspondante. Après cela, la clé Diffie-Hellman obtient l'échange, puis les deux envoient la clé pré-partagée à l'autre pour l'authentification.
Maintenant, nous avons deux clés:
Quelle clé est utilisée pour crypter la clé pré-partagée?
Réponses:
Vous avez posé une excellente question. La question semble très simple, mais en fait la réponse est un peu plus complexe. Je ferai de mon mieux pour y répondre de manière succincte. De plus, puisque vous avez mentionné ISAKMP, je suppose que vous êtes intéressé par IKEv1. Les choses changent un peu pour IKEv2 (enfin, beaucoup), mais je voulais mentionner que la réponse ci-dessous ne correspond qu'à IKEv1.
La phase 1 peut être accomplie dans deux mods différents: le mode principal et le mode agressif. Dans les deux modes, le premier message est envoyé par l'initiateur et le deuxième message est envoyé par le répondeur. Ces deux messages incluent ce qui est connu dans le monde de la cryptographie comme un Nonce . Un Nonce est simplement un nombre généré aléatoirement à utiliser pour la génération de clés. (le terme Nonce vient de _N_umber utilisé _Once_) . Ainsi, après le message 1 et le message 2, les deux parties connaissent les Nonces de l'autre.
Les Nonce sont combinés avec la clé pré-partagée pour créer une valeur de départ pour générer des clés secrètes. La partie relative du IKE RFC est ici:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID est la valeur Seed qui sera utilisée ultérieurement pour générer des clés secrètes supplémentaires. La clé pré-partagée et les deux valeurs de Nonce (Ni_b est le Nonce de l'initiateur et Nr_B est le Nonce du répondeur) sont combinées en utilisant un PRF ou une fonction aléatoire Psuedo. Un PRF est comme un algorithme de hachage, sauf que le résultat peut être autant de bits que nécessaire.
Maintenant, si vous faisiez initialement le mode principal, les messages 3 et 4 partagent les clés publiques Diffie-Hellman de l'initiateur et du répondeur (respectivement). Ils utilisent tous les deux ces valeurs pour générer le secret partagé Diffie-Hellman . Si vous utilisiez le mode agressif, ces valeurs DH publiques sont également incluses dans le message 1 et le message 2 (avec les nonces).
La valeur Seed est ensuite combinée avec le DH Shared Secret (et quelques autres valeurs) pour créer trois clés de session : une clé dérivative, une clé d'authentification et une clé de cryptage. Le RFC le déclare comme tel:
Le résultat du mode principal ou du mode agressif est constitué de trois groupes de matériel de saisie authentifié:
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 et _e sont les trois clés de session mentionnées ci-dessus. SKEYIDest la valeur de départ. g^xyest le DH Shared Secret. CKY-Iet CKI-Rsont les cookies initiateur et répondeur, ce ne sont que des valeurs supplémentaires générées aléatoirement qui sont utilisées plus tard pour identifier cette association d'échange et de sécurité ISAKMP particulière. 0 1 2sont les nombres littéraux 0, 1 et 2. Le symbole Pipe |représente la concaténation.
Dans tous les cas, toutes ces valeurs sont combinées ensemble à l'aide d'un PRF qui crée trois clés de session:
La clé d'authentification et la clé de cryptage sont utilisées pour sécuriser / crypter la négociation Phase2 qui s'ensuit. En mode principal, les messages 5 et 6 de Phase1 sont également protégés par ces touches. De plus, tous les futurs échanges d'informations ISAKMP (DPD, événements Rekey, messages Delete, etc.) sont également protégés par ces deux clés.
La clé dérivée est remise à IPsec et IPsec génère son propre matériel de clé à partir de cette clé. Si vous vous souvenez, IPsec n'inclut pas de manière innée un mécanisme d'échange de clés, donc la seule façon pour lui d'acquérir des clés secrètes est de les définir manuellement (ce qui est archaïque, et plus jamais fait), OU de dépendre d'un service externe pour fournir le matériel de saisie, comme ISAKMP.
Le RFC le dit ainsi:
SKEYID_e est le matériel de saisie utilisé par ISAKMP SA pour protéger la confidentialité de ses messages.
SKEYID_a est le matériel de saisie utilisé par la SA ISAKMP pour authentifier ses messages.
SKEYID_d est le matériau de clé utilisé pour dériver des clés pour les associations de sécurité non ISAKMP.
Cela dit, nous pouvons revenir à votre question: quelle clé est utilisée pour sécuriser la clé pré-partagée?
En mode principal, la clé pré-partagée (PSK) est vérifiée dans les messages 5 et 6. Les messages 5 et 6 sont protégés par les clés de session générées par ISAKMP, décrites ci-dessus.
En mode agressif, aucun des messages de la négociation n'est chiffré. Et le PSK est vérifié dans les messages 2 et 3. Remarquez, j'ai dit dans les deux cas que le PSK est vérifié , et je n'ai jamais dit que le PSK était échangé . De toute évidence, si rien en mode agressif n'est chiffré et que vous avez simplement envoyé la clé pré-partagée sur le câble non chiffrée, il y aurait une énorme vulnérabilité de sécurité béante.
Heureusement pour nous, les écrivains d'ISAKMP y ont déjà pensé. Et en conséquence, ils ont créé une méthode spéciale pour vérifier que chaque partie a le bon PSK, sans le partager réellement à travers le fil. Deux éléments sont utilisés pour valider pour chaque homologue qu'ils ont tous les deux le même PSK: la méthode d'identité et le hachage d'identité .
Les pairs VPN peuvent choisir de s'identifier par diverses méthodes; le plus souvent, les pairs utiliseront simplement leur adresse IP source. Mais ils ont la possibilité d'utiliser un nom de domaine complet ou un nom d'hôte. Chacun de ces éléments, ainsi que la valeur de corrélation pour la méthode choisie, sont ce qui compose la méthode d'identité. Ainsi, par exemple, si j'avais l'IP 5.5.5.5 et que je voulais utiliser mon adresse IP pour m'identifier, ma méthode d'identification serait effectivement [IP Address, 5.5.5.5] . (Remarque: LES DEUX valeurs constituent la méthode d'identification entière)
La méthode ID est ensuite combinée (à l'aide d'un PRF) avec la valeur Seed dont nous avons discuté précédemment (SKEYID), et quelques autres valeurs, pour créer le hachage d'identité . Rappelez-vous, que ce qui a commencé à créer SKEYID était la clé pré-partagée.
La méthode d'ID et le hachage d'ID sont ensuite envoyés sur le câble, et l'autre partie tente de recréer le hachage d'ID en utilisant la même formule. Si le destinataire est capable de recréer le même ID Hash, cela prouve au destinataire que l'expéditeur doit avoir la clé pré-partagée correcte.
Ceci est décrit dans le RFC ici:
Pour authentifier soit l'échange, l'initiateur du protocole génère HASH_I et le répondeur génère HASH_R où:
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 et IDir sont la méthode ID. Et HASH_I et HASH_R sont les hachages de l'initiateur et du répondeur. Ces deux éléments sont partagés dans la phase 1. Du RFC:
Lors d'une authentification par clé pré-partagée, le mode principal est défini comme suit:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RLe mode agressif avec une clé pré-partagée est décrit comme suit:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
Et maintenant, nous pouvons enfin répondre pleinement à votre question:
La clé pré-partagée est combinée à l'aide d'un PRF avec des nonces et d'un tas d'autres valeurs connues de quiconque dans la négociation. Le résultat est une valeur qui ne peut être atteinte par deux parties que si les deux parties ont commencé avec les mêmes valeurs, c'est-à-dire la même clé pré-partagée. La valeur résultante est ce qui est partagé sur le câble, avec permet à deux parties de vérifier qu'elles ont des clés pré-partagées correspondantes sans exposer réellement aucune information sur la clé pré-partagée elle-même.
Le mode principal franchit une étape plus sécurisée en chiffrant également l'échange de la "valeur résultante" décrite ci-dessus, ce qui rend encore plus difficile l'extraction d'informations utiles sur la clé pré-partagée.
(Il semble que j'ai échoué lamentablement à répondre à cette question succinctement)
Votre réponse est dans votre question: l'échange Diffie-Hellman est utilisé pour générer une clé commune pour échanger en toute sécurité une clé commune (c'est-à-dire un pré-partage).
Voir ceci: /security/67953/understanding-diffie-hellman-key-exchange