IPSec
Généralités :
C’est un protocole développé par l’IETF qui a pour but de sécuriser TCP/IP, de façon standardisée et donc intéropérable (c’est du moins un des buts du standard). Par l’authentification et le chiffrement des paquets IP, IPSec permet de sécuriser toute transmission de données reposant sur TCP/IP (contrairement à SSL, il n’est pas nécessaire de lancer des processus particuliers, sur des ports particuliers... https sur 443 et ftps 990 par exemple, correspondant aux couches supérieures).
IPSec est un protocole particulièrement complexe.
Les principales implémentations d’IPSec se retrouvent dans les logiciels et matériels de VPN (Virtual Private Network).
De plus en plus de logiciels et d’OS commencent cependant à implémenter IPSec comme fonctionnalité de base. La prochaine version d’IP, IPv6, inclura les mécanismes IPSec. Malgré sa complexité, IPSec semble pour l’instant amené à s’imposer pour ce qui relève de la sécurité réseau bas niveau (confidentialité, authentification, intégrité, filtrage...).
Il y a deux types de transformations qui constituent les éléments fondamentaux d’IPSec :
le Authentication header (AH) et l’ESP (Encapsulating Security Payload).
Ces transformations structurent les données IP sécurisées en une Security Association (SA).
Authentification Header (AH) :
Cette transformation authentifie, protège en intégrité les datagrammes IP (y compris les champs des entêtes qui ne varient pas lors de la transmission) et assure une protection " anti-replay " (chaque paquet est numéroté par le champ " Sequence Number " de l’entête AH), et les paquets rejoués ne sont pas pris en compte). Elle n’apporte cependant pas de confidentialité.
Coté expéditeur, cette transformation consiste en un MAC qui est calculé sur l’ensemble du datagramme, et dont le résultat est ensuite joint au datagramme.
Coté destinataire, il suffira de recalculer le MAC afin de vérifier l’authenticité et l’intégrité des données.
Les transformations AH peuvent se faire en mode transport ou en mode tunnel, et obéissent aux spécifications définies dans les Security Association.
En mode transport, l’entête originale du paquet IP sera celle du paquet sécurisé :
En mode tunnel, une nouvelle entête IP est créée pour chaque paquet sécurisé. C’est ce mode qui est typiquement utilisé dans les logiciels ou boîtiers VPN pour connecter deux réseaux par exemple.
Encapsulating Security Payload (ESP) :
La transformation ESP permet d’assurer la confidentialité, l’authentification et l’intégrité des datagrammes IP en les chiffrant conformément à ce qui est défini par les Security Association. ESP assure aussi une protection contre le rejeu des paquets, grâce au champ " Sequence Number " de l’entête ESP.
Les transformations ESP chiffrent des portions des datagrammes, peuvent encapsuler ces portions dans d’autres datagrammes IP et peuvent effectuer des contrôles d’intégrité via un Integrity Check Value (ICV).
Tout comme AH, l’ESP peut se décliner en mode transport. L’entête IP du datagramme original est conservé et les autres champs sont sécurisés et précédés d’une entête ESP :
En mode tunnel, une nouvelle entête IP est générée, précédent le datagramme sécurisé, et ne contenant aucune option IP, même si l’entête initiale en contenait.
Ce mode est typiquement utilisé pour les communications d’hôte à hôte (gateway-to-gateway), où il permet de masquer les adresses IP des expéditeurs et destinataires originaux :
Security Association (SA) :
Une Security Association définit quelles sont les transformations IPSec qui devront être appliquées aux datagrammes, et comment elles devront être faites.
Une SA spécifie :
s’il s’agit d’une protection AH ou ESP l’algorithme d’authentification pour AH et ESP l’algorithme de chiffrement pour ESP les clés d’authentification et de chiffrement la durée de vie des clés de chiffrement la durée de vie de la SA l’authentification des parties la période de modification des clés la séquence des nombres anti-rejeu et la table des bits associée.
La taille et le contenu d’une SA sont spécifiées par les transformations. Une SA peut-être statique ou dynamique. Dans le premier cas elle ne contient que des données qui ne sont pas modifiées pas la transformation. Dans le second cas, les données peuvent être mises à jour par la transformation chaque fois qu’un datagramme est utilisé, comme par exemple dans la protection contre le rejeu par le numérotage des paquets ou les fonctionnalités de compression.
Lors de la négociation d’une SA, un nombre de 32 bits appelé Security Parameters Index (SPI) est attribué pour la désigner. Pour désigner une SA lors des transformations AH ou ESP on utilisera un SPI.
Un exemple typique d’une SA peut être :
SPI : 314159
Encryption algorithm : IDEA
HMAC algorithm : SHA1
Encryption key : 0x56d6eed...
HMAC key : 0xdd36fdd6...
Expiry : 22:22:22 17Aug2000
Algorithmes utilisés :
Pour le chiffrement, les algorithmes valides pour une négociation sont :
- DES CBC
- Triple DES
- RC 5
- IDEA
- Blowfish
- CAST
- NULL (la possibilité de ne spécifier aucun chiffrement peut parfois être utile)
Pour l’authentification et l’intégrité, les algorithmes possibles sont :
- HMAC-MD5
- HMAC-SHA-1
- HMAC-RIPEMD-160
- HMAC-DES
- Keyed MD5
ISAKMP/Oaklay :
Avant qu’une communication sécurisée puisse s’établir, il est nécessaire que les parties en présence en négocient les termes, qui seront définis dans la Security Association (SA). Le protocole utilisé pour négocier (établir, négocier, modifier et effacer) les SA est Internet Key Exchange (IKE).
IKE combine le Internet Security Association et le Key Management Protocol (ISAKMP) avec l’échange de clés Oaklay utilisant Diffie-Hellman.
ISAKMP est un ensemble de règles pour établir, négocier, modifier et effacer les paramètres spécifiques à une connexion (la SA, qui n’est en principe pas limité à IPSec mais c’est pour l’instant son seul domaine d’application).
Oaklay est une application de ISAKMP pour la génération des clés et des SA IPSec.Les modes ISAKMP/Oaklay :
IKE se déroule en deux phases.
Le but de la première phase est d’établir un canal sûr et authentifié entre les parties qui s’apprêtent à négocier. Elle établit une SA pour ISAKMP.
La phase deux est utilisée pour établir une SA pour IPSec.
Elle est effectuée plus rapidement après que la première phase ait été faite, ce qui compense le désavantage d’avoir à effectuer deux phases.
Lors de la première phase, pour établir la SA, il y a deux modes possibles : le mode Général et le mode Agressif.
Ces deux modes font la même chose, le mode Agressif est plus rapide mais ne protège pas l’identité des parties qui négocient.
Le mode rapide est utilisé pour établir la SA de la deuxième phase, et est plus rapide après que la négociation de la phase un ait été faite.Mode général ISAKMP/Oaklay :
Dans le mode général, les parties en présence utilisent les deux premiers messages pour négocier la politique de sécurité qui s’appliquera à l’échange. Les deux messages suivants établissent une clé Diffie-Hellman et échangent des valeurs aléatoires qui serviront à signer et s’authentifier. Les deux derniers messages servent à authentifier les parties grâce à des signatures, des condensâts et éventuellement par transmission de certificats.
Mode agressif ISAKMP/Oaklay :
En gros, ce mode ressemble beaucoup au précédent sauf qu’il y a moins d’échanges. La politique proposée, les données passées pour l’échange de clé et la valeur aléatoire sont passées lors du premier message. Le deuxième message est la réponse qui authentifie le répondeur, conclut la politique et l’échange de clé. Le dernier message authentifie l’initiateur de l’échange.
Mode rapide ISAKMP/Oaklay :
Le mode rapide est utilisé pour négocier les services de sécurité IPSec et générer de nouvelles clés. Un nouvel échange de clés Diffie-Hellman peut être réalisé, mais ce n’est pas obligatoire. Sinon, les parties génèrent simplement de nouvelles clés à l’aide de condensats et s’identifient mutuellement à l’aide de valeurs aléatoires
Les RFC : c’est parfois abscons mais (presque) tout y est spécifié...
RFC 2401 : Security Architecture for the Internet
RFC 2402 : IP Authentication Header
RFC 2403 : The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 : The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 : The ESP DES-CBC Cipher Algorithm
RFC 2406 : IP Encapsulating Security Payload (ESP)
RFC 2407 : The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408 : Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 : The Internet Key Exchange (IKE)
RFC 2410 : The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411 : IP Security
RFC 2412 : The OAKLEY Key Determination Protocol
cryptosec
5 avril 2002
Partager sur Twitter | Partager sur LinkedIn
Tous les textes, images et sons de cryptosec sont publiés selon les termes de la licence Creative Commons - Attribution - Pas d’Utilisation Commerciale - Pas de Modification - 3.0