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

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

III.2. INTEGRATION D'ISAKMP DANS SSL/TLS 7

III.2.1. Contraintes de base

Après la définition des principales motivations de notre architecture, nous citons trois contraintes inhérentes à sa conception globale. Les trois conditions pour réaliser un déploiement simple et efficace d'ISAKMP avec SSL/TLS sont :

1. Utilisation des échanges et des blocs standards ISAKMP afin de faciliter le déploiement de notre architecture et afin de minimiser les tâches de développement de nouveaux blocs ou échanges ISAKMP, nous avons essayé d'utiliser les blocs et les échanges ISAKMP existants. Avec SSL/TLS, nous nous intéressons surtout a l'échange de protection d'identité pour établir la première association de sécurité ISAKMP. Nous nous s'intéressons également a l'échange Quick Mode de Oakley pour établir la deuxième association de sécurité propre à SSL/TLS ;

2. Transparence par rapport à la couche Record de SSL/TLS Puisque le changement dans SSL/TLS est au niveau Handshake, les résultats d'échange (clé de chiffrement, d'authentification, etc.) doivent être transparents au protocole Record de SSL/TLS. C'est-à-dire, le mécanisme de dérivation des clés à partir de la clé matérielle générée avec ISAKMP doit ressembler à celui utilisé par le protocole Handshake de SSL/TLS ;

3. Interopérabilité avec le protocole SSL/TLS existant. En plus de l'interopérabilité avec le protocole Record de SSL/TLS, notre approche doit permettre à des clients SSL/TLS qui supportent notre proposition et à des serveurs qui ne la supportent pas de se communiquer et vice versa.

III.2.2. Architecture

ISAKMP est un protocole de couche application placé au-dessus de la couche transport. Selon la spécification de ce protocole, il doit offrir ses services au dessus du protocole de transport UDP mais il peut être utilisé directement au-dessus d'IP. Actuellement et avec IKEv1, l'IANA lui a attribué le port 500 d'UDP. La figure III.1 illustre l'intégration d'ISAKMP dans SSL/TLS.

Fig. III.1 Intégration d'ISAKMP dans SSL/TLS

Avec SSL/TLS, ISAKMP peut fonctionner toujours sur le port 500 d'UDP. En effet, a la fin des deux phases ISAKMP, chaque protocole de sécurité doit chiffrer et/ou authentifier son propre tunnel indépendamment du protocole ISAKMP.

La figure III.2 illustre l'établissement de différentes sessions pour ISAKMP et SSL/TLS.

Fig. III.2. Etablissement de différentes sessions pour ISAKMP et SSL/TLS

Les quatre étapes nécessaires pour établir une session SSL/TLS avec ISAKMP sont les suivantes :

1. Négociation d'ISAKMP SA. Durant la première phase, un ensemble d'attributs relatifs à la sécurité est négocié. Les identités des tiers sont authentifiées et les clés sont générées. Ces éléments constituent une première association de sécurité que nous appelons ISAKMP SA ;

2. Négociation de TLS SA. La seconde phase permet de négocier les paramètres de sécurité relatifs à une SA (Security Associations) pour le compte d'un protocole de sécurité donné. Dans notre cas, c'est le protocole SSL/TLS. Les échanges de cette phase sont sécurisés (confidentialité, authenticité, etc.) grâce a l'association de sécurité déjà établie. Celle-ci peut être utilisée pour négocier plusieurs SA « fils » destinées à d'autres mécanismes de sécurité définis a travers des domaines d'interprétations (DOI) ;

3. Ouverture d'une session TCP. A ce point, ISAKMP a établi tous les paramètres de sécurité (algorithme de chiffrement, clés session, etc.) nécessaires au chiffrement de tout type de données (page Web, fichier, vidéo, etc.) avec la couche Record de SSL/TLS. Maintenant, c'est a l'application qui souhaite utiliser SSL/TLS d'établir une première connexion TCP vers le port défini par chaque application ;

4. Echange des messages CCS et des données chiffrées. Dans la dernière partie (étape 4 et 5), les clés de chiffrement sont activées avec le module CCS (ChangeCipherSpec) de SSL/TLS. Les messages CCS qui ne font pas partie du protocole Handshake, sont envoyés au début du premier échange de données chiffrées. De plus, afin de protéger ces messages contre l'attaque homme du milieu, nous proposons de les ajouter dans le premier échange chiffré des données.

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