Sécurisation de la signalisation avec les noeuds correspondants
From Livre IPv6
| |
Les risques induits par la mobilité et leur limitation | Table des matières | Protection de la signalisation par le protocole IPsec | |
La procédure de test de routage retour
Les mises à jour d'association étant fréquentes, il est important que cette procédure soit la plus légère possible. Un noeud mobile et un noeud correspondant ne se connaissent pas à priori. Ils ne partagent donc pas de secret susceptible de chiffrer leurs échanges lors des différentes mises à jour d'association nécessaires pendant toute la durée de la communication. L'utilisation d'IPsec et d'une procédure d'échange sécurisé des clefs aurait été trop lourde. La procédure choisie a pour premier but de générer ce secret partagé.
Afin d'éviter l'attaque en déni de service à l'encontre d'un noeud tiers, elle garantit au noeud correspondant que, pour une certaine adresse temporaire et pour une certaine adresse mère, il y a effectivement un noeud mobile prêt à recevoir un paquet.
La procédure est conçue de façon à ce que le noeud correspondant ne puisse pas subir lui-même une attaque en déni de service par la simple exécution répétée de la procédure. A cette fin, elle consomme peu de ressources de calcul, et les ressources mémoires nécessaires ne dépendent pas du nombre de demande d'association. Enfin, pour ne pas surcharger le réseau, le noeud correspondant n'émet pas plus de paquets qu'il n'en reçoit.
La procédure est constituée de deux phases préliminaires, dont l'une teste la home address et l'autre teste la care-of address. Ensuite toute demande de mise à jour, ou de destruction d'association sera assujettie à l'exécution correcte des ces deux phases préliminaires.
Les deux phases sont menées parallèlement l'une de l'autre, à l'initiative du noeud mobile. Le noeud correspondant répond à leurs requêtes indépendamment l'une de l'autre. Il demeure sans état jusqu'à ce qu'une association soit établie. Les messages doivent donc être autosuffisants pour que la procédure puisse se dérouler.
La procédure (cf. figure Routage retour) nécessite que le noeud mobile dispose d'un ensemble de nombres aléatoires secrets (nonces), tels que l'index d'un de ces nombres suffise à le retrouver dans cet ensemble. Elle nécessite également que le noeud correspondant dispose d'une clef secrète notée Kcn.
Un message HoTI, émis depuis la home address du noeud mobile vers le noeud correspondant (donc via l'agent mère), contient une valeur aléatoire sur 64 bits, le home init cookie identifiant cette home address.
Un message HoT, émis par le noeud correspondant en réponse au message HoTI à destination de la home address du mobile, donc toujours via l'agent mère contient trois valeurs :
- le home init cookie obtenu dans le message HoTI,
- l'index sur 16 bits d'un nonce, choisi par le noeud correspondant,
- le home keygen token, calculé par le noeud correspondant :
premiers (64, HMAC_SHA1 (Kcn, (home address | nonce | 0 )))
Un message CoTI, émis depuis la care-of address du noeud mobile, directement vers le noeud correspondant, contient une seconde valeur aléatoire sur 64 bits, le care-of init cookie identifiant cette care-of address.
Un message CoT, émis par le noeud correspondant en réponse au message CoTI du noeud mobile, directement vers le noeud mobile contient trois valeurs :
- le care-of init cookie obtenu dans le message CoTI,
- l'index sur 16 bits d'un second nonce, choisi par le noeud correspondant,
- le care-of keygen token, calculé par le noeud correspondant :
premiers (64, HMAC_SHA1 (Kcn, (care-of address| nonce | 1 )))
Lorsque le noeud mobile a reçu les messages HoT et CoT, la procédure de test du routage retour est terminée. Arrivé à ce point, le noeud mobile calcule Kbm, la clef de gestion des associations (key binding management) telle que :
Kbm = SHA1 ( "home keygen token" | "care-of keygen token")
pour la mise à jour d'une association, ou
Kbm = SHA1 ( "home keygen token")
pour sa destruction.
Pour demander une nouvelle association, le noeud mobile envoie, depuis sa care-of address courante, à destination du noeud correspondant, une demande d'association contenant cinq informations :
- Sa home address
- Un numéro de séquence d'association
- Les deux index des home et care-of nonces
- Une valeur chiffrée
- Premier( 96, HMAC_SHA1(Kbm , ("home address" | adresse du noeud correspondant | donnée de la mise jour d'association)))
On notera que puisque les indexes des nombres aléatoires secrets sont fournis par le noeud mobile, le noeud correspondant peut recalculer Kbm. Kbm est donc bien une clef partagée utilisable dans une procédure HMAC_SHA1 pour vérifier la légalité d'une demande de mise à jour d'association.
La correction de la procédure repose sur l'hypothèse qu'aucun intrus ne peut écouter à la fois les messages home test et care-of test ni connaître Kbm. Ces messages utilisant deux chemins différents pour joindre le noeud correspondant (cf. figure Attaque contre le routage retour), il faudrait donc que l'intrus se trouve dans le réseau du noeud correspondant. Dans ce cas, la mobilité n'introduit pas plus de risque que IP fixe lui-même.
Par contre, si un noeud malveillant obtient les deux home et care-of keygen tokens, il pourra par la suite envoyer de fausses demandes de mise à jour d'association. Pour cela, ce noeud doit écouter des données circulant en clair sur les 2 chemins conduisant du noeud mobile au noeud correspondant, directement et via l'agent mère. La probabilité que cette écoute soit possible augmente si le noeud malveillant est proche du noeud correspondant. L'écoute est définitivement possible lorsque l'on est connecté au réseau du noeud correspondant.
Les message HoTI, CoTI, HoT et CoT sont transportés dans des en-têtes d'extension de mobilité (numéro de protocole 135). Chacun possède un numéro de type d'en-tête de message particulier (respectivement 1,2,3,4).
La procédure conduit au partage d'un secret entre les noeuds mobile et correspondant. Il est nécessaire de rafraîchir régulièrement ce secret. Le rafraîchissement est laissé à l'initiative du noeud correspondant. Il est mise en oeuvre en expirant la validité du nonce utilisé dans la clef Kbm. Une demande de modification d'association arrivant avec un nonce expiré sera refusée via le message d'acquittement. Le noeud mobile relancera alors la procédure pour obtenir une nouvelle Kbm basée sur un nonce valide.
La clef Kcn doit elle même être régulièrement régénérée. Elle le sera en particulier à chaque redémarrage du noeud correspondant et préférablement lors de chaque régénération de nonce. Il est en effet nécessaire que chaque nonce soit associé à la bonne Kcn dans la vérification de la clef Kbm d'une demande de mise à jour d'association.
La vérification par le noeud correspondant d'une clef Kbm s'effectue en vérifiant que :
- Les nonces HoA et CoA ne sont pas expirés,
- Le re-calcul de Kbm, sur la base des indices des nonces et de la Kcn associée, est cohérent avec la valeur Kbm contenue dans la demande d'association.
Un message d'erreur est envoyé en cas d'expiration d'une au moins des nonces. Aucun message d'erreur n'est émis dans le cas ou le re-calcul de la Kbm échoue. Dans le cas de nonce expiré, il est nécessaire de procéder au re-calcul sur la base d'une éventuelle ancienne valeur de Kcn pour n'envoyer de message d'expiration que si la Kbm est valide par rapport à l'ancienne Kcn.
Seul le noeud mobile maintient l'état des données de sécurité de chaque association. Les informations home init cookie et care-of init cookie peuvent être supprimées dès réceptions des nonces et keygen tokens. Les demandes de création d'association sont à l'initiative du noeud mobile. Il n'est donc pas sujet à une attaque en déni de service par consommation excessive de ressources mémoire.
Le noeud correspondant maintient un état de sécurité indépendant du nombre d'associations en cours. Il n'est donc pas sujet non plus à une attaque en déni de service par consommation excessive de ressources mémoire.
| |
Les risques induits par la mobilité et leur limitation | Table des matières | Protection de la signalisation par le protocole IPsec | |
