IPsec

IPsec (abréviation de Internet Protocol security ) est un ensemble de protocoles dont la fonction est de sécuriser les communications sur le protocole Internet (IP) en authentifiant et/ou en chiffrant chaque paquet IP dans un flux de données. IPsec inclut également des protocoles pour établir des clés de cryptage . ^{[ 1} ]

Résumé

Les protocoles IPsec agissent au niveau de la couche réseau, la couche 3 du modèle OSI . D'autres protocoles de sécurité Internet largement utilisés, tels que SSL , TLS et SSH , fonctionnent au niveau de la couche application (couche 7 du modèle OSI). Cela rend IPsec plus flexible, car il peut être utilisé pour protéger les protocoles de couche 4, y compris TCP et UDP .

Architecture de sécurité

IPsec est implémenté par un ensemble de protocoles cryptographiques pour (1) sécuriser le flux de paquets, (2) assurer une authentification mutuelle et (3) établir des paramètres cryptographiques .

L'architecture de sécurité IP utilise le concept d' association de sécurité (SA) comme base pour créer des fonctions de sécurité sur IP . Une association de sécurité est simplement l'ensemble d'algorithmes et de paramètres (tels que des clés) qui est utilisé pour chiffrer et authentifier un flux particulier dans une direction. Par conséquent, dans un trafic bidirectionnel normal, les flux sont sécurisés par une paire d'associations de sécurité. La décision finale sur les algorithmes de chiffrement et d'authentification (à partir d'une liste définie) appartient à l'administrateur IPsec.

Pour décider de la protection à fournir pour un paquet sortant, IPsec utilise l'index des paramètres de sécurité (SPI), un index de la base de données des associations de sécurité (SADB), ainsi que l'adresse de destination dans l'en-tête du paquet, qui ensemble identifient de manière unique une sécurité association pour ce paquet. Une procédure similaire est effectuée pour un paquet entrant ; dans ce cas, IPsec prend les clés de vérification et de déchiffrement de la base de données des associations de sécurité.

Dans le cas de la multidiffusion, une association de sécurité est fournie au groupe et est dupliquée pour tous les récepteurs autorisés du groupe. Il peut y avoir plus d'une association de sécurité pour un groupe, utilisant différents SPI, permettant ainsi plusieurs niveaux et ensembles de sécurité au sein d'un groupe. En fait, chaque expéditeur peut avoir plusieurs associations de sécurité, permettant l'authentification, puisqu'un destinataire ne peut savoir que quelqu'un qui connaît les clés a envoyé les données. Notez que la norme pertinente ne décrit pas comment l'association est choisie et dupliquée dans le groupe ; on suppose qu'une partie responsable aura fait le choix.

État actuel de la norme

IPsec était une partie obligatoire d' IPv6 basée sur la définition de la RFC 4294 , cependant, en 2011, cette RFC a été rendue obsolète par la RFC 6434 qui indique qu'IPsec est recommandé et non obligatoire pour IPv6. Pour IPv4 , son utilisation est facultative. Bien que la norme soit conçue pour être indifférente à la version IP, le déploiement et l'expérience jusqu'en 2007 concernent les implémentations IPv4 .

Les protocoles IPsec ont été initialement définis dans les RFC 1825 et 1829, publiées en 1995. En 1998, ces documents ont été remplacés par les RFC 2401 et 2412, qui ne sont pas compatibles avec 1825 et 1829, bien qu'ils soient conceptuellement identiques. La troisième génération de documents, RFC 4301 et 4309, a été produite en décembre 2005. Ils sont en grande partie un sur-ensemble de 2401 et 2412, mais fournissent une deuxième norme d'échange de clés Internet . Cette troisième génération de documents a normalisé l'abréviation IPsec en majuscule "IP" et minuscule "sec".

Il est rare de voir un produit prenant en charge à la fois RFC1825 et 1829. "ESP" fait généralement référence à 2406, tandis que ESPbis fait référence à 4303.

Objectif de conception

IPsec a été conçu pour fournir une sécurité en mode transport (de bout en bout) du trafic de paquets, dans lequel les ordinateurs terminaux effectuent un traitement de sécurité, ou en mode tunnel (porte à porte) dans lequel la sécurité du trafic des paquets est fournie à plusieurs machines. (voire l'ensemble du réseau local ) par un seul nœud.

IPsec peut être utilisé pour créer des VPN dans les deux modes, et c'est son utilisation principale. Notez cependant que les implications en matière de sécurité sont assez différentes entre les deux modes de fonctionnement.

La sécurité des communications de bout en bout à l'échelle d'Internet s'est développée plus lentement que prévu. Cela s'explique en partie par le fait qu'aucune infrastructure à clé publique universelle ou universellement fiable n'a émergé ( DNSSEC était initialement destiné à cela); Une autre partie est que de nombreux utilisateurs ne comprennent pas suffisamment bien leurs besoins et les options disponibles pour promouvoir leur inclusion dans les produits des fournisseurs.

Étant donné que le protocole Internet ne fournit par nature aucune capacité de sécurité, IPsec a été introduit pour fournir des services de sécurité tels que :

Crypter le trafic (afin qu'il ne puisse être lu par personne d'autre que les parties auxquelles il est destiné)
Validation d'intégrité (s'assurer que le trafic n'a pas été modifié le long de son chemin)
Authentifier les points de terminaison (assurez-vous que le trafic provient d'un point de terminaison de confiance)
Anti-rejeu (protection contre la relecture de session sécurisée).

Modes

Ainsi, et selon le niveau sur lequel il agit, on peut établir deux modes de base de fonctionnement d' IPsec : le mode transport et le mode tunnel .

Mode de transport

En mode transport , seule la charge utile (les données transférées) du paquet IP est cryptée ou authentifiée. Le routage reste intact, puisque l'en-tête IP n'est ni modifié ni chiffré ; cependant, lorsque l' en-tête d'authentification (AH) est utilisé, les adresses IP ne peuvent pas être traduites , car cela invaliderait le hachage . Les couches de transport et d'application sont toujours sécurisées par un hachage, elles ne peuvent donc en aucun cas être modifiées (par exemple en traduisant les numéros de port TCP et UDP ) . Le mode transport est utilisé pour les communications d'ordinateur à ordinateur.

Une façon d'encapsuler les messages IPsec pour traverser NAT a été définie par les RFC qui décrivent le mécanisme de traversée NAT .

Mode tunnel

En mode tunnel , l'ensemble du paquet IP (données plus en-têtes de message) est crypté ou authentifié. Il doit alors être encapsulé dans un nouveau paquet IP pour que le routage fonctionne. Le mode tunnel est utilisé pour les communications de réseau à réseau (tunnels sécurisés entre les routeurs, par exemple pour les VPN ) ou les communications d'ordinateur à réseau ou d'ordinateur à ordinateur sur Internet .

Protocoles

IPsec se compose de trois protocoles qui ont été développés pour fournir une sécurité au niveau des paquets pour IPv4 et IPv6 :

L'en- tête d'authentification (AH) fournit l'intégrité, l'authentification et la non-répudiation si les algorithmes cryptographiques appropriés sont choisis.
Encapsulating Security Payload (ESP) assure la confidentialité et l'option hautement recommandée d'authentification et de protection de l'intégrité.
L'échange de clés Internet ( IKE ) utilise un échange de clés secrètes Diffie-Hellman pour établir le secret partagé de la session . Des systèmes de cryptographie à clé publique ou à clé pré-partagéesont généralement utilisés

Les algorithmes cryptographiques définis pour être utilisés avec IPsec incluent HMAC - SHA-1 pour la protection de l'intégrité, et Triple DES - CBC et AES -CBC pour la confidentialité. Plus de détails dans la RFC 4305 .

En-tête d'authentification (AH)

AH vise à assurer l'intégrité, la non-connexion et l'authentification des données sources des datagrammes IP. Pour ce faire, il calcule un code d'authentification de message de hachage ( HMAC ) grâce à un algorithme de hachage fonctionnant sur une clé secrète, le contenu du paquet IP et les parties immuables du datagramme. Ce processus restreint la possibilité d'utiliser NAT , qui peut être implémenté avec la traversée NAT . D'autre part, AH peut éventuellement se protéger contre les attaques par relecture en utilisant la technique de la fenêtre glissante et en supprimant les anciens paquets. AH protège la charge utile IP et tous les champs de l'en-tête d'un datagramme IP à l'exception des champs mutants, c'est-à-dire ceux qui peuvent être modifiés en transit. Dans IPv4, les champs d'en-tête IP mutants (et donc non authentifiés) incluent TOS , Flags, Fragment Offset, TTL et header checksum . AH fonctionne directement au-dessus d'IP, en utilisant le numéro de protocole IP 51. Un en- tête AH a une longueur de 32 bits, voici un schéma de la façon dont ils sont organisés :

0 - 7 bits	8 - 15 bits	16 - 23 bits
En-tête suivant	Longueur de la charge utile	RÉSERVÉ
Index des paramètres de sécurité (SPI)
numéro de séquence
Code d'authentification de message de hachage (variable)

Signification des champs :

En-tête suivant: Identifie le protocole des données transférées.
Longueur de la charge utile: Taille de l'emballage AH
RÉSERVÉ: Réservé pour une utilisation future (jusque-là tous des zéros).
Index des paramètres de sécurité (SPI): Indique les paramètres de sécurité qui, en combinaison avec l'adresse IP, identifient l'association de sécurité mise en œuvre avec ce paquet.
numéro de séquence: Un nombre toujours croissant, utilisé pour empêcher les attaques par rejeu.
HMAC: Contient la valeur de contrôle d'intégrité (ICV) requise pour authentifier le paquet ; peut contenir des charges.

Encapsulation de la charge utile de sécurité (ESP)

Le protocole ESP assure l'authenticité de l'origine, l'intégrité et la protection de la confidentialité d'un paquet. ESP prend également en charge les configurations de cryptage uniquement et d'authentification uniquement, mais l'utilisation du cryptage sans authentification est fortement déconseillée car elle n'est pas sécurisée ^{[ 2 ]}^[ ³^] . ^{[ 4 ]} Contrairement à AH, l'en-tête du paquet IP n'est pas protégé par ESP (bien qu'en ESP en mode tunnel, la protection soit fournie à l'ensemble du paquet IP interne, y compris l'en-tête interne ; l'en-tête externe reste non protégé). ). ESP fonctionne directement sur IP, en utilisant le numéro de protocole IP 50.

Un diagramme de paquets ESP :

0 - 7 bits	8 - 15 bits	16 - 23 bits	24 - 31 bits
Index des paramètres de sécurité (SPI)
numéro de séquence
Données de charge utile (variables)
	Remplissage (0-255 octets)
		Longueur du tampon	En-tête suivant
Données d'authentification (variable)

Signification des champs

Index des paramètres de sécurité (SPI): Identifie les paramètres de sécurité en combinaison avec l'adresse IP.
numéro de séquence: Un nombre toujours croissant, utilisé pour empêcher les attaques par rejeu.
Données de charge utile: Les données à transférer.
rembourrage: Utilisé par certains algorithmes cryptographiques pour remplir complètement les blocs.
longueur du tampon: Taille de remplissage en octets.
En-tête suivant: Identifie le protocole des données transférées.
Date d'authentification: Contient les données utilisées pour authentifier le paquet.

Implémentations

La prise en charge d'IPsec est normalement implémentée dans le noyau avec la gestion des clés et la négociation ISAKMP / IKE effectuée dans l'espace utilisateur. Les implémentations IPsec existantes incluent généralement les deux fonctionnalités. Cependant, comme il existe une interface standard pour la gestion des clés, il est possible de contrôler une pile IPsec centrale à l'aide des outils de gestion des clés d'une implémentation différente.

Pour cette raison, il existe une confusion sur les origines de l'implémentation IPsec trouvée dans le noyau Linux . Le projet FreeS/WAN a réalisé la première implémentation open source complète d'IPsec pour Linux . Il se compose d'une pile IPsec centrale KLIPS , ainsi que d'un démon (pluto) et de nombreux scripts shell . Le projet FreeS/WAN a été mis hors service en mars 2004. Openswan et strongSwan sont des prolongements de FreeS/WAN. Le projet KAME a également implémenté un support IPsec complet pour NetBSD et FreeBSD . Son démon de gestion de clés s'appelle racoon . OpenBSD a créé son propre démon ISAKMP/IKE, simplement appelé isakmpd (et il a été porté sur d'autres systèmes, y compris Linux ).

Cependant, aucune de ces piles IPsec principales n'a été intégrée à Linux. Alexey Kuznetsov et David S. Miller ont écrit une implémentation IPsec du noyau pour Linux à partir de zéro vers la fin de 2002. Cette pile a ensuite été publiée dans le cadre de Linux 2.6 et est appelée "native" ou "NETKEY" par beaucoup.

Par conséquent, contrairement à la croyance populaire, la pile Linux IPsec n'est pas issue du projet KAME. Parce qu'il prend en charge le protocole standard PF KEY ( RFC 2367 ) et l' interface XFRM native pour la gestion des clés, la pile Linux IPsec peut être utilisée en conjonction avec Openswan / strongSwan 's pluto , OpenBSD project's isakmpd , KAME project 's racoon , ou sans un démon ISAKMP. /IKE (à l'aide de clés manuelles).

Les nouvelles architectures de processeur réseau, y compris les processeurs multicœurs avec des moteurs de chiffrement intégrés, ont changé la façon dont les piles IPsec sont conçues. Un Fast Path dédié est utilisé pour décharger le traitement des tâches IPsec (consultations SA, SP, chiffrement, etc.). Ces piles Fast Path doivent être co-intégrées sur des noyaux dédiés avec Linux ou RTOS s'exécutant sur d'autres noyaux. Ces systèmes d'exploitation constituent le plan de contrôle qui exécute ISAKMP/IKE de la pile IPsec Fast Path.

Il existe de nombreuses implémentations des protocoles IPsec et ISAKMP/IKE. Entre autres:

6WINDGate , pile IPsec Fast Path pour processeur réseau multicœur
NRL [1] IPsec, l'une des sources originales du code IPsec [2]
OpenBSD , avec son propre code dérivé de NRL IPsec
La pile KAME , qui est incluse dans Mac OS X , NetBSD et FreeBSD
"IPsec" dans le logiciel Cisco IOS [3]
"IPsec" dans Microsoft Windows , y compris Windows XP [4] [5] , Windows 2000 [6] et Windows 2003 [7]
Outils SafeNet QuickSec [8]
IPsec sur Solaris [9]
Système d'exploitation AIX d' IBM
IBM z/ OS
IPsec et IKE sur HP-UX (HP-UX IPSec)
"IPsec et IKE" dans VxWorks [10]

Liste des RFC liées à IPsec

RFC 2327 : Interface PF_KEY
RFC 2367 : Interface PF_KEY
RFC 2401 (remplace RFC 1825 et a été remplacée par RFC 4301 ) : architecture de sécurité pour le protocole Internet
RFC 2402 (remplacée par RFC 4302 et RFC 4305 ) : en-tête d'authentification
RFC 2403 : L'utilisation de HMAC-MD5-96 dans ESP et AH
RFC 2404 : L'utilisation de HMAC-SHA-1-96 dans ESP et AH
RFC 2405 : Algorithme de chiffrement ESP DES-CBC avec IV explicite
RFC 2406 (remplacée par RFC 4303 et RFC 4305 ) : Encapsulating Security Payload
RFC 2407 (remplacée par RFC 4306 ) : domaine d'interprétation IPsec pour ISAKMP (IPsec DoI)
RFC 2408 (remplacée par RFC 4306 ) : Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 (remplacée par RFC 4306 ) : Internet Key Exchange (IKE)
RFC 2410 : L'algorithme de chiffrement NULL et son utilisation avec IPsec
RFC 2411 : feuille de route du document de sécurité IP
RFC 2412 : (remplace RFC 1829 ) Le protocole de détermination de clé OAKLEY
RFC 2451 : Algorithmes de chiffrement ESP en mode CBC
RFC 2857 : L'utilisation de HMAC-RIPEMD-160-96 dans ESP et AH
RFC 3526 : Plus de groupes Diffie-Hellman modulaires exponentiels (MODP) pour l'échange de clés Internet (IKE)
RFC 3706 : Une méthode basée sur le trafic pour détecter les pairs IKE (Internet Key Exchange) morts
RFC 3715 : exigences de compatibilité IPsec-traduction d'adresses réseau (NAT)
RFC 3947 : Négociation de NAT-Traversal dans IKE
RFC 3948 : Encapsulation UDP des paquets IPsec ESP
RFC 4106 : L'utilisation du mode Galois/Counter (GCM) dans IPsec Encapsulating Security Payload (ESP)
RFC 4301 (remplace RFC 2401 ): Architecture de sécurité pour le protocole Internet
RFC 4302 (remplace RFC 2402 ): En-tête d'authentification IP
RFC 4303 (remplace RFC 2406 ): IP Encapsulating Security Payload (ESP)
RFC 4304 : Addendum ESN (Extended Sequence Number) au domaine d'interprétation IPsec (DOI) pour Internet Security Association et Key Management Protocol (ISAKMP)
RFC 4305 (remplacée par RFC 4835 ) : Exigences de mise en œuvre de l'algorithme cryptographique pour l'encapsulation de la charge utile de sécurité (ESP) et l'en-tête d'authentification (AH)
RFC 4306 (remplace RFC 2407 , RFC 2408 et RFC 2409 ) : protocole d'échange de clés Internet ( IKEv2 )
RFC 4307 : Algorithmes cryptographiques à utiliser dans l'échange de clés Internet Version 2 ( IKEv2 )
RFC 4308 : suites cryptographiques pour IPsec
RFC 4309 : Utilisation du mode CCM Advanced Encryption Standard (AES) avec IPsec Encapsulating Security Payload (ESP)
RFC 4478 : Authentification répétée dans le protocole d'échange de clés Internet (IKEv2)
RFC 4543 : L'utilisation du code d'authentification de message Galois (GMAC) dans IPsec ESP et AH
RFC 4555 : Protocole de mobilité et de multihébergement IKEv2 (MOBIKE)
RFC 4621 : Conception du protocole IKEv2 Mobility and Multihoming (MOBIKE)
RFC 4718 : Clarifications IKEv2 et instructions de mise en œuvre
RFC 4806 : Extensions OCSP (Online Certificate Status Protocol) à IKEv2
RFC 4809 : Exigences pour un profil de gestion de certificat IPsec
RFC 4835 (remplace RFC 4305 ) : Exigences de mise en œuvre de l'algorithme cryptographique pour l'encapsulation de la charge utile de sécurité (ESP) et l'en-tête d'authentification (AH)
RFC 4945 : Le profil PKI de sécurité IP Internet de IKEv1/ISAKMP, IKEv2 et PKIX

Références

↑ Marquis, William (12 janvier 2016). IPsec et réseaux privés virtuels . Lulu.com. ISBN 978-1-329-82419-5 . Consulté le 3 octobre 2021 .
^ Bellovin, Steven M. (1996). "Zones problématiques pour les protocoles de sécurité IP" . Actes du sixième symposium sur la sécurité Usenix Unix . San José, Californie. pp. 1-16 . Consulté le 13 novembre 2007 .
↑ KG Paterson et A. Yau (2006). "La cryptographie en théorie et en pratique : Le cas du chiffrement dans IPsec" . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 . pp. 12-29 . Consulté le 13 novembre 2007 . Texte « Berlin » ignoré ( aide )
^ JP Degabriele et KG Paterson (2007). "Attaquer les normes IPsec dans les configurations de cryptage uniquement" . Symposium IEEE sur la sécurité et la confidentialité, IEEE Computer Society . pp. 335-349 . Consulté le 13 novembre 2007 . Texte "Oakland, CA" ignoré ( aide )

[1] Marquis, William (12 janvier 2016). IPsec et réseaux privés virtuels . Lulu.com. ISBN 978-1-329-82419-5 . Consulté le 3 octobre 2021 .

[2] Bellovin, Steven M. (1996). "Zones problématiques pour les protocoles de sécurité IP" . Actes du sixième symposium sur la sécurité Usenix Unix . San José, Californie. pp. 1-16 . Consulté le 13 novembre 2007 .

[3] KG Paterson et A. Yau (2006). "La cryptographie en théorie et en pratique : Le cas du chiffrement dans IPsec" . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 . pp. 12-29 . Consulté le 13 novembre 2007 . Texte « Berlin » ignoré ( aide )

[4] JP Degabriele et KG Paterson (2007). "Attaquer les normes IPsec dans les configurations de cryptage uniquement" . Symposium IEEE sur la sécurité et la confidentialité, IEEE Computer Society . pp. 335-349 . Consulté le 13 novembre 2007 . Texte "Oakland, CA" ignoré ( aide )

[ 1

[ 2 ]

[

[ 4 ]