WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Etude des protocoles de sécurité dans le réseau internet

( Télécharger le fichier original )
par Fils NZALANKUMBU DIALEMBA
Institut supérieur de techniques appliquées Kinshasa - Ingénieur en informatique appliquée 2007
  

précédent sommaire suivant

III.2.3.2. Négociation de TLS SA

Après l'établissement de la première association de sécurité, les deux entités commencent à négocier les paramètres de sécurité de SSL/TLS.

Dans cette deuxième phase, l'initiateur (le client SSL/TLS) indique dans l'en-tête ISAKMP, «TLS Quick Mode> comme type d'échange. Il spécifie un identificateur du message (message_ID) non nul, ajoute les deux cookies de la phase 1 et met le champ « flag » à 1 pour indiquer que les messages sont chiffrés. Le premier message comprend aussi :

1' Un Bloc HASH qui suit l'en-tête ISAKMP. Ce bloc contient le résultat de hachage pour toute ou une partie de ce message ISAKMP ;

1' Un bloc SA, précisant « TLS10 » comme protocole de sécurité utilisé dans cette phase ;

1' Un bloc Proposal qui se rapporte au protocole TLS10 auquel est associé un

SPI (Security Parameter Index) choisi aléatoirement par l'initiateur ;

1' Un ou plusieurs blocs Transform pour le bloc Proposal. Ceux-ci définissent

les différents attributs proposés par l'initiateur ;

V' Un bloc NONCE (NONCEi, NONCEr) qui sert à transporter de nouveaux aléas ;

V' Un bloc Key Exchange (KE) qui sert à transporter les données nécessaires à la génération d'une nouvelle clé DH partagée. Ce bloc contient aussi le champ group qui indique le nombre premier utilisé pour la génération des clés. Ce champ prend par défaut la valeur « Modular Exponentiation » avec 768 bits pour le nombre premier et 2 pour le générateur DH ;

1' Deux blocs d'identification (IDi, IDr). Le premier sert (IDi) à identifier le client. Il contient l'adresse 0.0.0.0/0. Le deuxième (IDr) sert à identifier un serveur parmi le rang d'adresse envoyé dans le même bloc (IDr) pendant la première phase. Le mécanisme que nous proposons ici permet aux clients de préciser depuis leur premier message, le serveur auquel ils souhaitent accéder ;

V' Un bloc de demande de certificat (Certificate Request).

L'emploi des blocs KE, HASH, ID et CERTReq est optionnel. Le bloc KE est utilisé si les deux communicateurs veulent assurer la propriété de PFS (Perfect Forward Secrecy) dans la génération des secrets partagés. Comme expliqué dans le RFC 2409, la présence du bloc HASH après les blocs SAs est explicite dans chaque message. Par contre dans notre échange, ce bloc est optionnel si les deux communicateurs utilisent un mécanisme d'authentification forte tel que la signature RSA (RSA_SIG).

III.2.3.2. Générations des clés (phase 1 et 2)

En utilisant une fonction perf (clé, message), les deux entités vont générer un ensemble de clés pour le chiffrement des messages ISAKMP et la dérivation de nouvelles clés. L'intégration d'ISAKMP dans SSL/TLS nécessite un mécanisme de génération des clés qui respecte le mécanisme de dérivation des clés produit par le protocole Handshake de SSL/TLS, défini dans le RFC 2246. Ceci, afin d'obtenir les mêmes paramètres de sécurité utilisés par le protocole Record de SSL/TLS.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy