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

 > 

Projet d'une API IPSEC pour la mobilité et le multihoming

( Télécharger le fichier original )
par Xavier FERRER CABALLERO
Supélec - Ingénieur réseau 2008
  

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

Conclusions (0,5 mois)

- Rapport de stage

- Réalisation d'un brevet pour France Télécom R&D

2.4 Planning

Figure 1. Planning du stage

 

Etude d'IPsec
Projet d'une API_IPSEC pour la Mobilite et le Multihoming

 
 

3. Etude Théorique

Cette étude théorique permet, dans un premier temps, d'établir une base de connaissances sur IPsec et ses protocoles associés afin de mieux mesurer les divers composants d'une Architecture de Sécurité basée sur IPsec. Le but n'est pas décrire ici en détail les protocoles avec tous ses "headers", ses "payloads" ou ses messages ; on se réfère au RFCs dans le cas échéant. Par contre, on se concentre sur les différences entre la seconde génération d'IPsec et la première, ainsi que sur les différentes implémentations existantes. Cela permettra de faciliter dans la partie technique l'encadrement de l'API_IPsec dans une architecture IPsec actuelle.

Dans un deuxième temps, on étudie les relations entre IPsec, la mobilité et le multihoming. On commence d'abord par définir ce qu'on entend par mobilité et multihoming, puis un État de l'Art des protocoles actuels ou des dernières ébauches de l'IETF qui traitent des aspects IPsec dans un cadre de mobilité. De manière analogue à l'étude précédente, on ne veut pas décrire de manière détaillée les divers protocoles. On se contente d'en exposer les principes sur le cas qui nous intéresse. Cela permettra de faciliter la définition de l'API_IPsec dans un cadre de mobilité ainsi que de donner des idées ou des méthodes pour manager la mobilité et le multihoming. Cette étude théorique servira également de base pour les développements futurs de l'API_IPsec.

3.1 IPsec

3.1.1 Introduction : besoins de sécurité sur IP

Avec IP sans IPsec, les données IP sont transportées sont contenues en clair dans les paquets. Il est donc possible, en écoutant le trafic réseau, de lire et de modifier les paquets soit le contenu (données) soit l'entête (adresse source, adresse destination ...). IP étant utilisé aussi bien pour les communications d'Internet qu'au sein des réseaux privées, ces faiblesses peuvent avoir de larges répercussions.

Les besoins classiques de sécurité auxquels doit répondre la couche IP sont :

- Confidentialité : les données ne peuvent être compréhensibles que par le destinataire final.

- Authentification : vérification de l'identité de l'émetteur supposé lors des données reçues.

- Intégrité : la modification des données par des intermédiaires ne peut pas être possible.

Les deux grandes classes de solutions cryptographiques d'aujourd'hui sont les systèmes de chiffrement à :

- Clés symétriques : une même clé sert à chiffrer et à déchiffrer. Elle est partagée uniquement par l'émetteur et le récepteur. Les algorithmes utilisés sont DES ou AES, et permettent d'assurer la confidentialité et l'intégrité des paquets.

 

Etude d'IPsec
Projet d'une API_IPSEC pour la Mobilite et le Multihoming

 
 

- Clés asymétriques : qui fait intervenir deux clés, une publique et une autre privée. Entre communicants, chacun garde sa clé privée et distribue aux autres sa clé publique. Deux cas sont à considérer : l'authentification et la confidentialité. Pour authentifier une donnée on chiffrera avec la clé privé, détenue par un noeud unique, et on déchiffrera avec la clé publique associée. On suppose que si l'on déchiffre avec la clé publique, le chiffrement a été effectué avec la clé privée. Pour assurer la confidentialité d'une donnée, c'est-à-dire pour qu'une donnée ne soit lu que par le propriétaire d'une clé privée, on chiffrera avec la clé publique associée. Seul le propriétaire de la clé privée associée pourra déchiffrer la donnée. Les algorithmes, comme RSA ou l'algorithme de Diffie-Hellman, sont basés sur des problèmes mathématiques de factorisation de grands nombres. Les opérations surtout de déchiffrement sont plus coûteuses que dans le cas du chiffrement / déchiffrement symétrique.

En général, pour la communication entre deux entités, on commence par utiliser un système à clés asymétriques pour s'authentifier et s'échanger un secret partagé qui est utilisé comme clé symétrique pour chiffrer les messages.

Pour plus de précision sur les systèmes cryptographiques, leurs types de faiblesses et d'attaques, les possibles scénarios... on se reportera à [1].

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








"I don't believe we shall ever have a good money again before we take the thing out of the hand of governments. We can't take it violently, out of the hands of governments, all we can do is by some sly roundabout way introduce something that they can't stop ..."   Friedrich Hayek (1899-1992) en 1984