IPsec, également connu sous le nom de Internet Protocol Security, définit l’architecture des services de sécurité
IPsec décrit le cadre de travail pour assurer la sécurité de la couche IP, ainsi que la suite de protocoles conçus pour assurer cette sécurité, par l’authentification et le chiffrement des paquets du réseau IP.
IPsec comprend également des protocoles qui définissent les algorithmes cryptographiques utilisés pour chiffrer, déchiffrer et authentifier les paquets, ainsi que les protocoles nécessaires à l’échange sécurisé et à la gestion des clés.
A l’origine, IPsec a défini deux mécanismes pour imposer la sécurité aux paquets IP : le protocole Encapsulating Security Payload (ESP), qui définit une méthode de chiffrement des données dans les paquets IP, et le protocole Authentication Header (AH), qui définit une méthode de signature numérique des paquets IP. Le protocole IKE (Internet Key Exchange) est utilisé pour gérer les clés cryptographiques utilisées par les hôtes pour IPsec.
IPsec peut être utilisé pour protéger les données réseau, par exemple, en mettant en place des circuits utilisant le tunneling IPsec, dans lequel toutes les données envoyées entre deux points finaux sont cryptées, comme avec une connexion VPN (Virtual Private Network), pour crypter les données de la couche application, et assurer la sécurité des routeurs qui envoient les données de routage sur internet (voir notre article : → Qui utilise un VPN ?).
IPsec peut également être utilisé pour fournir une authentification sans chiffrement, par exemple pour authentifier que des données proviennent d’un expéditeur connu.
Le trafic internet peut être sécurisé d’hôte en hôte sans l’utilisation d’IPsec, par exemple par chiffrage au niveau de la couche application (couche 7 du modèle OSI) avec HTTP Secure (HTTPS) ou de la couche transport (couche 4 du modèle OSI) avec le protocole Transport Layer Security (TLS). Toutefois, lorsque le trafic utilise le chiffrement ou l’authentification à ces niveaux supérieurs, les acteurs de menaces peuvent toujours être en mesure d’intercepter des informations de protocole non chiffrées.
Aux origines d’IPsec
IPsec a été développé par l’IETF (Internet Engineering Task Force) pour le transfert sécurisé d’informations à la couche 3 de l’OSI sur un réseau IP public non protégé comme internet.
IPsec permet à un système de sélectionner et de négocier les protocoles de sécurité, les algorithmes et les clés secrètes nécessaires pour les services demandés.
IPsec fournit des services d’authentification de base, d’intégrité des données et de chiffrage pour protéger la consultation et la modification non autorisées des données.
Il utilise deux protocoles de sécurité différents :
- AH (Authentication header)
- et ESP (Encapsulated Security Payload)
Cependant, IPsec est limité à l’envoi de paquets IP.
Les protocoles de sécurité pour la sécurité du trafic
IPsec utilise les protocoles AH et ESP pour fournir des services de sécurité :
- AH (Authentication Header) fournit l’authentification de la source et l’intégrité des paquets IP, mais ne possède pas de cryptage. Un en-tête AH ajouté au paquet IP contient un hachage des données, un numéro de séquence, ainsi que des informations qui peuvent être utilisées pour vérifier l’expéditeur, assurer l’intégrité des données et empêcher la redondance des attaques.
- Le protocole ESP (Encapsulated Security Payload) assure la confidentialité des données, en plus de l’authentification de la source et de l’intégrité. L’ESP utilise des algorithmes de chiffrage symétrique, tels que 3DES, pour assurer la confidentialité des données. L’algorithme doit être le même sur les deux pairs communicants. L’ESP peut également prendre en charge les configurations de chiffrement seul ou d’authentification seule. Cependant, des recherches menées en 2007 ont montré que toute implémentation conforme à la RFC d’IPsec qui n’utilise que l’ESP peut être interrompue (source).
Modes de fonctionnement
Chaque protocole de sécurité prend en charge deux modes de fonctionnement :
- un mode tunnel
- et un mode transport.
Le mode tunnel chiffre et/ou authentifie l’en-tête et les données de chaque paquet. Inversement, le mode transport chiffre et/ou authentifie uniquement les données elles-mêmes.
1. Le mode tunnel de bout en bout
Ici, l’ensemble du paquet est protégé. Le paquet IP d’origine est inséré dans un nouveau paquet IP, tandis que l’AH et l’ESP sont appliqués au nouveau paquet.
Le nouvel en-tête IP pointe vers le point final de la balise tunnel.
A la réception du paquet, le point final du tunnel décryptera le fichier. Le paquet d’origine est ensuite acheminé vers sa destination finale dans le répertoire réseau cible.
2. Le mode transport d’hôte à hôte
Ici, les en-têtes AH et ESP sont appliquées aux données de l’IP d’origine.
Ce mode chiffre et / ou authentifie les données mais pas l’IP en-tête. La surcharge ajoutée est inférieure à celle requise en mode tunnel. Le danger, c’est que les attaquants peuvent effectuer une analyse de trafic basée sur les informations d’en-tête. C’est pourquoi il n’est généralement utilisé que pour les connexions d’hôte à hôte.
Échange et gestion des clés
IPsec supporte deux types de gestion de clés sur internet : automatisée et manuelle.
Gestion automatisée des clés
IKE (Internet Key Exchange) est le protocole par défaut utilisé dans IPsec pour déterminer et négocier des protocoles, des algorithmes et des clés, et pour authentifier les deux parties. Il est utile pour les déploiements à grande échelle de VPN.
Le protocole IKEv2 a été publié en 2005. Il préserve la plupart des fonctionnalités du protocole IKEv1, mais prend également en charge la traversée NAT (Network Address Translation) et offre plus de flexibilité.
IKE soutient également l’utilisation de certificats numériques. Les utilisateurs s’authentifient en signant d’abord les données avec leur clé de signature numérique. L’autre extrémité vérifie ensuite la signature. IKE crée un tunnel authentifié et sécurisé entre deux entités, puis négocie une association de sécurité (AS) entre les deux entités.
L’AS est un ensemble de paramètres utilisés par les pairs négociateurs pour définir les services et les mécanismes de protection du trafic. Ces paramètres comprennent les identificateurs d’algorithme, les modes, les touches, etc.
IKE assure également le suivi des clés et les met à jour entre pairs communicants. IKE utilise des protocoles tels que ISAKMP (Internet Security Association and Key Management Protocol) et Oakley pour définir les procédures de génération, de création et de gestion des clés.
Gestion manuelle des clés
Les clés secrètes et les associations de sécurité sont configurées manuellement dans les deux réseaux VPN communiquants. Seuls l’expéditeur et le destinataire connaissent la clé secrète des services de sécurité concernés.
Si les données d’authentification sont valides, le destinataire sait que la communication provient de l’expéditeur et qu’elle n’a pas été modifiée. Cette approche est facile à utiliser dans de petits environnements statiques, mais il ne s’adapte pas bien à d’autres environnements. Toutes les clés doivent être distribuées aux pairs communiquant à l’avance. Si les clés sont compromises, une autre personne pourrait se faire passer pour l’utilisateur et établir une connexion dans le VPN.
La mise en œuvre d’IPsec
La prise en charge d’IPsec a généralement été incluse dans la plupart des systèmes d’exploitation courants disponibles depuis la fin des années 1990, y compris les systèmes d’exploitation de bureau et de serveur, ainsi que les routeurs et autres dispositifs de sécurité réseau.
Bien que des systèmes plus anciens puissent prendre en charge certaines versions d’IPsec, les entreprises doivent déployer IPsec en utilisant des systèmes d’exploitation qui sont à jour sur les correctifs de sécurité. En effet, les anciens systèmes qui prennent en charge les anciennes versions d’IPsec et semblent permettre des circuits IPsec sécurisés peuvent en réalité ne pas assurer la sécurité des données.
Des Geeks et des lettres – Test et Avis Échange de clés Internet (IKE)
Notre avis: Internet Key Exchange (IKE) est un protocole défini pour permettre aux hôtes de spécifier quels services doivent être incorporés dans les paquets, quels algorithmes cryptographiques seront utilisés pour fournir ces services, et quelles seront les clés utilisées avec ces algorithmes cryptographiques.