Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs approches :
- niveau applicatif (PGP) ;
- niveau transport (protocoles TLS/SSL, SSH) ;
- niveau physique (boîtiers chiffrants).
IPsec vise à sécuriser les échanges au niveau de la couche réseau. Le réseau IPv4 étant largement déployé et la migration complète vers IPv6 nécessitant encore beaucoup de temps, il est vite apparu intéressant de définir des mécanismes de sécurité qui soient communs à la fois à IPv4 et IPv6. Ces mécanismes sont couramment désignés par le terme IPSec pour IP Security Protocols.
Le protocole IPSec fournit ainsi :
- des mécanismes de confidentialité et de protection contre l'analyse du trafic ;
- des mécanismes d’authentification des données (et de leur origine) ;
- des mécanismes garantissant l’intégrité des données (en mode non connecté) ;
- des mécanismes de protection contre le rejeu ;
- des mécanismes de contrôle d'accès.
IPsec est une extension de sécurité pour le protocole IP.
Le fonctionnement des implémentations IPSec peut être résumé par le schéma suivant :
Figure 27 : Le mode de fonctionnement du protocole IPSec
Les implémentations IPSec s’appuient ainsi sur les composants suivants :
- SA (Security Association) : l’association de sécurité IPsec est une connexion qui fournit des services de sécurité au trafic qu’elle transporte. Il s’agit d’une structure de données servant à stocker l’ensemble des paramètres associés à une communication donnée. Une SA est unidirectionnelle ; en conséquence, protéger les deux sens d’une communication classique requiert deux associations, une dans chaque sens. Le rôle d’une SA est de consigner, pour chaque adresse IP avec laquelle l’implémentation IPsec peut communiquer, les informations suivantes :
ð index de la SA appelé SPI (pour Security Parameter Index) choisi par le récepteur ;
ð un numéro de séquence, indicateur utilisé pour le service d’anti-rejeu ;
ð une fenêtre d’anti-rejeu : compteur 32 bits ;
ð dépassement de séquence ;
ð paramètres d’authentification (algorithmes et clés) ;
ð paramètres de chiffrement (idem) ;
ð temps de vie de la SA ;
ð mode du protocole IPsec (tunnel ou transport).
Chaque association est identifiée de manière unique à l’aide d’un triplet composé de :
ð l’adresse de destination des paquets ;
ð l’identifiant du protocole de sécurité (AH ou ESP) ;
ð le SPI.
- SPD (Security Policy Database) : les protections offertes par IPSec sont basées sur des choix définis dans une base de données de politique de sécurité. Cette base de données est établie et maintenue par un administrateur. Elle permet de décider, pour chaque paquet, s’il se verra apporter des services de sécurité, s’il sera autorisé à passer outre ou sera rejeté ;
- SAD (Security Association Database) : de manière à pouvoir gérer les associations de sécurité actives, on utilise une base de données des associations de sécurité. Elle contient tous les paramètres relatifs à chacune des SA et sera consultée pour savoir comment traiter chaque paquet reçu ou à émettre.
Les services IPSec sont basés sur des mécanismes cryptographiques. Pour cela, IPsec fait appel à deux protocoles de sécurité qui viennent s'ajouter au protocole IP classique : il s'agit des protocoles AH et ESP. IPsec offre ainsi deux possibilités d'encapsulation distinctes. Toutefois, l'évolution de ce protocole fait que ESP assure désormais l'ensemble des fonctionnalités des deux mécanismes.
Au-delà de AH et ESP, l'IETF a jugé judicieux d'offrir un service supplémentaire appelé chiffrement en mode Fast Forward qui conserve la même taille de datagrammes et ainsi des performances optimales. Cependant, il protège en confidentialité uniquement. L'en-tête IP et la longueur du datagramme restent inchangés (sauf éventuellement le champ d'options IP qui peut être chiffré).
Les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clés utilisées. La gestion des clés pour IPsec n’est liée aux autres mécanismes de sécurité de IPsec que par le biais des SA. Une SA peut être configurée manuellement dans le cas d’une situation simple, mais la règle générale consiste à utiliser un protocole spécifique qui permet la négociation dynamique des SA et notamment l’échange des clés de session.
Le protocole de négociation des SA, développé pour Ipsec, est le protocole de gestion des clés et des associations de sécurité pour Internet (Internet Security Association and Key Management Protocol, ISAKMP). ISAKMP est en fait inutilisable seul (il s’agit d’un cadre générique qui permet l’utilisation de plusieurs protocoles d’échange de clé). Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une partie des protocoles SKEME et Oakley pour donner un protocole final du nom de Internet Key Exchange, IKE.
Le mode transport prend un flux de niveau transport (couche de niveau 4 du modèle OSI) et réalise les mécanismes de signature et de chiffrement puis transmet les données à la couche IP. Dans ce mode, l'insertion de la couche IPsec est transparente entre TCP et IP. TCP envoie ses données vers IPsec comme il les enverrait vers IPv4.
L'inconvénient de ce mode réside dans le fait que l'en-tête extérieur est produit par la couche IP c'est-à-dire sans masquage d'adresse. De plus, le fait de terminer les traitements par la couche IP ne permet pas de garantir la non-utilisation des options IP potentiellement dangereuses. L'intérêt de ce mode réside dans une relative facilité de mise en œuvre.
Dans le mode tunnel, les données envoyées par l'application traversent la pile de protocole jusqu'à la couche IP incluse, puis sont envoyées vers le module IPsec. L'encapsulation IPsec en mode tunnel permet le masquage d'adresses.
Le mode tunnel est généralement utilisé entre deux passerelles de sécurité (routeur, firewall, …) alors que le mode transport se situe entre deux hôtes.
Les deux modes de fonctionnement peuvent être résumés par le schéma suivant :
Figure 28 : Les deux modes de fonctionnement IPSec
Le protocole AH est conçu pour assurer l'intégrité en mode non connecté et l'authentification de l'origine des datagrammes IP sans chiffrement des données (pas de confidentialité).
Son principe est d'adjoindre au datagramme IP classique un champ supplémentaire permettant à la réception de vérifier l'authenticité des données incluses dans le datagramme. Ce bloc de données est appelé « valeur de vérification d'intégrité » (Intégrity Check Value, ICV). La protection contre le rejeu se fait grâce à un numéro de séquence.
Le protocole AH peut être représenté par le schéma suivant :
Figure 29 : Principe de fonctionnement du protocole AH
Il est à noter que l’utilisation du protocole AH interdit l’utilisation des mécanismes de translation d’adresses. En effet, le contenu de la trame n’étant pas chiffré, le protocole AH ajoute une signature numérique au paquet IP sortant : un mécanisme de translation d’adresses réécrivant l’adresse source fausse systématiquement le calcul de vérification de la signature numérique effectuée à l’autre bout du tunnel VPN.
Le protocole ESP peut assurer, au choix, un ou plusieurs des services suivants :
- confidentialité des données et protection partielle contre l'analyse du trafic si l'on utilise le mode tunnel ;
- intégrité des données en mode non connecté et authentification de l'origine des données, protection partielle contre le rejeu.
Contrairement au protocole AH, où l'on se contentait d'ajouter un en-tête supplémentaire au paquet IP, le protocole ESP fonctionne suivant le principe de l'encapsulation : les données originales sont chiffrées puis encapsulées.
Le protocole ESP peut être représenté par le schéma suivant :
Figure 30 : Principe de fonctionnement du protocole ESP