IPsec

En informatique , le protocole IPsec ( Internet Protocol Security ) est une suite de protocoles réseau sécurisés qui authentifie et chiffre les paquets de données afin d'assurer une communication chiffrée et sécurisée entre deux ordinateurs sur un réseau Internet . Il est utilisé dans les réseaux privés virtuels (VPN).

IPsec comprend des protocoles permettant d'établir une authentification mutuelle entre les agents au début d'une session et de négocier les clés cryptographiques à utiliser pendant celle-ci. IPsec protège les flux de données entre deux hôtes ( communications hôte à hôte ), entre deux passerelles de sécurité (communications réseau à réseau ) ou entre une passerelle de sécurité et un hôte ( communications réseau à hôte ). IPsec utilise des services de sécurité cryptographiques pour protéger les communications sur les réseaux IP . Il prend en charge l'authentification des pairs au niveau du réseau, l'authentification de l'origine des données , l'intégrité des données , la confidentialité des données ( chiffrement ) et la protection contre les attaques par rejeu .

Dès le début des années 1970, l' Agence pour les projets de recherche avancée (ARPA) a financé une série de dispositifs de chiffrement ARPANET expérimentaux , initialement pour le chiffrement natif des paquets ARPANET , puis pour le chiffrement des paquets TCP/IP ; certains d'entre eux ont été certifiés et déployés. De 1986 à 1991, la NSA a financé le développement de protocoles de sécurité pour Internet dans le cadre de son programme SDNS (Secure Data Network Systems) . Ce programme a réuni divers fournisseurs, dont Motorola, qui a produit un dispositif de chiffrement réseau en 1988. Les travaux ont été publiés publiquement à partir de 1988 environ par le NIST et, parmi eux, le protocole SP3 (Security Protocol at Layer 3 ) a finalement donné naissance à la norme ISO NLSP (Network Layer Security Protocol)

En 1992, le Laboratoire de recherche navale des États-Unis (NRL) a reçu un financement du DARPA CSTO pour implémenter IPv6 et mener des recherches sur le chiffrement IP sous BSD 4.4 , compatible avec les architectures SPARC et x86. La DARPA a mis son implémentation à disposition gratuitement via le MIT. Dans le cadre de ce projet de recherche financé par la DARPA , le NRL a élaboré les spécifications IPsec (RFC 1825 à RFC 1827) soumises à l'IETF. [ implémentation IPsec du NRL a été décrite dans leur article des actes de la conférence USENIX de 1996. L'implémentation IPsec open source du NRL a été mise en ligne par le MIT et a servi de base à la plupart des premières implémentations commerciales.

L’ Internet Engineering Task Force (IETF) a formé le groupe de travail sur la sécurité IP en 1992 afin de normaliser les extensions de sécurité ouvertement spécifiées pour IP, appelées IPsec . Les normes développées par le NRL ont été publiées par l’IETF sous la référence RFC 1825 à RFC 1827.

La suite IPv4 initiale a été développée avec peu de mesures de sécurité. Dans le cadre de l'amélioration d'IPv4, IPsec est un schéma de sécurité de bout en bout de couche 3 du modèle OSI , ou couche Internet . Contrairement à d'autres systèmes de sécurité Internet largement utilisés qui opèrent au-dessus de la couche réseau , tels que TLS ( Transport Layer Security ) au-dessus de la couche transport et SSH ( Secure Shell ) au niveau de la couche application , IPsec sécurise automatiquement les applications au niveau de la couche Internet .

IPsec est une norme ouverte faisant partie de la suite IPv4 et utilise les protocoles suivants pour effectuer diverses fonctions :

• L'en-tête d'authentification (AH) assure l'intégrité des données sans connexion et l'authentification de l'origine des données pour les datagrammes IP et offre une protection contre les attaques par modification d'en-tête IP et les attaques par rejeu .
• Encapsulating Security Payload (ESP) assure la confidentialité , l'intégrité des données sans connexion, l'authentification de l'origine des données , un service anti-rejeu (une forme d'intégrité de séquence partielle) et une confidentialité limitée du flux de trafic.

• Le protocole ISAKMP ( Internet Security Association and Key Management Protocol ) fournit un cadre pour l'authentification et l'échange de clés , les clés authentifiées étant fournies soit par configuration manuelle avec des clés pré-partagées , soit par Internet Key Exchange (IKE et IKEv2), soit par Kerberized Internet Negotiation of Keys (KINK), soit par des enregistrements DNS IPSECKEY Son objectif est de générer les associations de sécurité (SA) avec l'ensemble des algorithmes et paramètres nécessaires aux opérations AH et/ou ESP.

L'en-tête d'authentification de sécurité (AH) a été développé au Laboratoire de recherche navale des États-Unis au début des années 1990 et s'inspire en partie des travaux antérieurs de l'IETF sur les normes d'authentification du protocole SNMP (Simple Network Management Protocol ) version 2. L'en-tête d'authentification (AH) fait partie de la suite de protocoles IPsec. Il garantit l'intégrité des données sans connexion grâce à une fonction de hachage et une clé secrète partagée. L'AH garantit également l'origine des données en authentifiant les paquets IP . Un numéro de séquence peut, en option, protéger le contenu des paquets IPsec contre les attaques par rejeu grâce à la technique de la fenêtre glissante et à la suppression des paquets anciens.

• En IPv4 , AH empêche les attaques par insertion d'options. En IPv6 , AH protège à la fois contre les attaques par insertion d'en-têtes et les attaques par insertion d'options.
• En IPv4 , l'AH protège la charge utile IP et tous les champs d'en-tête d'un datagramme IP, à l'exception des champs modifiables (c'est-à-dire ceux qui peuvent être altérés en transit), ainsi que des options IP telles que l'option de sécurité IP (IPS). Les champs d'en-tête IPv4 modifiables (et donc non authentifiés) sont DSCP / ToS , ECN , Flags, Fragment Offset , TTL et Header Checksum .
• En IPv6 , l'AH protège la majeure partie de l'en-tête de base IPv6, l'AH lui-même, les en-têtes d'extension non modifiables qui le suivent, ainsi que la charge utile IP. La protection de l'en-tête IPv6 exclut les champs modifiables : DSCP , ECN , étiquette de flux et limite de sauts.

AH fonctionne directement sur IP, en utilisant le numéro protocole IP 51. 20

Le diagramme de paquet AH suivant montre comment un paquet AH est construit et interprété :

En-tête suivant : 8 bits

Type de l'en-tête suivant, indiquant le protocole de couche supérieure protégé. La valeur est extraite de la liste des numéros de protocole IP .

Longueur de la charge utile : 8 bits

La longueur de cet en-tête d'authentification est exprimée en unités de 4 octets, moins 2. Par exemple, une valeur AH de 4 correspond à 3 × (champs AH de longueur fixe de 32 bits) + 3 × (champs ICV de 32 bits) − 2, soit 24 octets. Bien que la taille soit mesurée en unités de 4 octets, la longueur de cet en-tête doit être un multiple de 8 octets s'il est inclus dans un paquet IPv6. Cette restriction ne s'applique pas à un en-tête d'authentification inclus dans un paquet IPv4.

Réservé : 16 bits

Réservé pour un usage futur (que des zéros d'ici là).

Index des paramètres de sécurité : 32 bits

Valeur arbitraire utilisée (avec l'adresse IP de destination) pour identifier l' association de sécurité de la partie réceptrice.

Numéro de séquence : 32 bits

Un numéro de séquence strictement croissant (incrémenté de 1 pour chaque paquet envoyé) est utilisé pour empêcher les attaques par rejeu . Lorsque la détection de rejeu est activée, les numéros de séquence ne sont jamais réutilisés, car une nouvelle association de sécurité doit être renégociée avant toute tentative d'incrémentation du numéro de séquence au-delà de sa valeur maximale.

Valeur de contrôle d'intégrité : multiple de 32 bits

Valeur de contrôle de longueur variable. Elle peut contenir un remplissage pour aligner le champ sur une limite de 8 octets pour IPv6 , ou sur une limite de 4 octets pour IPv4 .

Le protocole ESP (Encapsulating Security Payload) a été développé au Naval Research Laboratory à partir de 1992 dans le cadre d'un projet de recherche financé par la DARPA , puis publié publiquement par le groupe de travail SIPP de l'IETF en décembre 1993 en tant qu'extension de sécurité pour SIPP. Ce protocole ESP est dérivé du protocole SP3D du département de la Défense des États-Unis , et non du protocole NLSP (Network-Layer Security Protocol) de l'ISO. La spécification du protocole SP3D a été publiée par le NIST à la fin des années 1980, mais conçue par le projet Secure Data Network System du département de la Défense des États-Unis . ESP fait partie de la suite de protocoles IPsec. Il garantit l'authenticité de l'origine grâce à l'authentification de la source , l'intégrité des données grâce aux fonctions de hachage et la confidentialité grâce au chiffrement des paquets IP . ESP prend également en charge les configurations avec chiffrement seul et avec authentification seule, mais l'utilisation du chiffrement sans authentification est fortement déconseillée car elle est non sécurisée.

Contrairement à l'en-tête d'authentification (AH) , ESP en mode transport ne garantit pas l'intégrité et l'authentification de l'intégralité du paquet IP . Cependant, en mode tunnel , où le paquet IP d'origine est encapsulé dans un nouvel en-tête, la protection ESP s'étend à l'ensemble du paquet IP interne (y compris son en-tête interne), tandis que l'en-tête externe (y compris les options IPv4 externes et les extensions IPv6) reste vulnérable.

ESP fonctionne directement sur IP, en utilisant le numéro de protocole IP 50.

Le diagramme de paquet ESP suivant montre comment un paquet ESP est construit et interprété :

Index des paramètres de sécurité (SPI) : 32 bits

Valeur arbitraire utilisée (avec l'adresse IP de destination) pour identifier l' association de sécurité de la partie réceptrice.

Numéro de séquence : 32 bits

Un numéro de séquence croissant de manière monotone (incrémenté de 1 pour chaque paquet envoyé) assure la protection contre les attaques par rejeu . Un compteur distinct est conservé pour chaque association de sécurité.

Données utiles : variable

Le contenu protégé du paquet IP d'origine, y compris les données utilisées pour sa protection (par exemple, le vecteur d'initialisation de l'algorithme cryptographique), est indiqué par le champ « En-tête suivant » .

Remplissage : 0 à 255 octets

Facultatif. Remplissage pour le chiffrement, afin d'étendre les données utiles à une taille correspondant à la taille du bloc de chiffrement , et d'aligner le champ suivant.

Longueur du tampon : 8 bits

Taille du remplissage (en octets).

En-tête suivant : 8 bits

Indique le type de protocole des données utiles : par exemple la valeur 6 pour TCP . ESP étant un protocole d’encapsulation, la valeur 4 est également possible, indiquant IPv6 encapsulé dans IPv4 . La valeur 41 indique IPv6 encapsulé dans IPv4 (par exemple, 6to4 ). La valeur 59 (signifiant : pas d’en-tête suivant ) est utilisée pour les paquets factices, qui peuvent être insérés dans le flux et dont le contenu doit être ignoré.

Valeur de contrôle d'intégrité (ICV) : variable

Valeur de contrôle de longueur variable. Elle peut contenir un remplissage pour aligner le champ sur une limite de 8 octets pour IPv6 , ou sur une limite de 4 octets pour IPv4 .

Les protocoles IPsec utilisent une association de sécurité , où les parties communicantes définissent des attributs de sécurité partagés, tels que des algorithmes et des clés. Ainsi, IPsec offre un éventail d'options une fois déterminé le choix entre AH et ESP. Avant l'échange de données, les deux hôtes conviennent de l'algorithme de chiffrement symétrique utilisé pour chiffrer le paquet IP (par exemple , AES ou ChaCha20 ) et de la fonction de hachage employée pour garantir l'intégrité des données (par exemple, BLAKE2 ou SHA256 ). Ces paramètres sont définis pour chaque session, pour laquelle une durée de vie et une clé de session doivent être convenues .

L'algorithme d'authentification est convenu avant le transfert de données et IPsec prend en charge plusieurs méthodes. L'authentification est possible via une clé pré-partagée : une clé symétrique est déjà en possession des deux hôtes, qui s'échangent alors les hachages de cette clé partagée pour prouver qu'ils la possèdent. IPsec prend également en charge le chiffrement à clé publique : chaque hôte possède une clé publique et une clé privée, ils échangent leurs clés publiques et chaque hôte envoie à l'autre un nonce chiffré avec la clé publique de l'autre. Enfin, si les deux hôtes possèdent un certificat de clé publique délivré par une autorité de certification , celui-ci peut être utilisé pour l'authentification IPsec.

Les associations de sécurité d'IPsec sont établies à l'aide du protocole ISAKMP ( Internet Security Association and Key Management Protocol ). ISAKMP est implémenté par configuration manuelle avec des secrets pré-partagés, l'échange de clés Internet (IKE et IKEv2), la négociation de clés Internet Kerberisée (KINK) et l'utilisation d' enregistrements DNS IPSECKEY . La RFC 5386 définit la sécurité « Mieux que rien » (BTNS) comme un mode non authentifié d'IPsec utilisant un protocole IKE étendu. C. Meadows, C. Cremers et d'autres ont utilisé des méthodes formelles pour identifier diverses anomalies présentes dans IKEv1 et IKEv2.

Pour déterminer la protection à appliquer à un paquet sortant, IPsec utilise l' index des paramètres de sécurité (SPI), un index de la base de données d'associations de sécurité (SADB), ainsi que l'adresse de destination figurant dans l'en-tête du paquet. Ces éléments, combinés, identifient de manière unique l'association de sécurité associée à ce paquet. Une procédure similaire est appliquée à un paquet entrant : IPsec récupère alors les clés de déchiffrement et de vérification dans la base de données d'associations de sécurité.

Pour la multidiffusion IP, une association de sécurité est définie pour le groupe et dupliquée pour tous les destinataires autorisés de ce groupe. Un groupe peut avoir plusieurs associations de sécurité, utilisant différentes interfaces de sécurité (SPI), ce qui permet de définir plusieurs niveaux et ensembles de sécurité au sein du groupe. En effet, chaque expéditeur peut avoir plusieurs associations de sécurité, permettant ainsi l'authentification, car le destinataire ne peut savoir que l'expéditeur des données possède les clés appropriées. Il est à noter que la norme applicable ne décrit pas comment l'association est choisie et dupliquée au sein du groupe ; on suppose que ce choix est effectué par une partie responsable.

Pour garantir que la connexion entre deux points d'extrémité n'a pas été interrompue, ces points d'extrémité échangent des messages de maintien de connexion à intervalles réguliers, qui peuvent également être utilisés pour rétablir automatiquement un tunnel perdu en raison d'une interruption de connexion.

La détection des pairs inactifs (DPD) est une méthode permettant de détecter un pair IKE ( Internet Key Exchange ) défaillant. Cette méthode exploite les modèles de trafic IPsec afin de minimiser le nombre de messages nécessaires pour confirmer la disponibilité d'un pair. La DPD sert à récupérer les ressources perdues lorsqu'un pair est déclaré inactif et à assurer le basculement des pairs IKE.

UDP keepalive est une alternative à DPD.

Les protocoles IPsec AH et ESP peuvent être implémentés en mode de transport hôte à hôte, ainsi qu'en mode de tunnelage réseau.

En mode transport, seule la charge utile du paquet IP est généralement chiffrée ou authentifiée. Le routage reste intact, car l'en-tête IP n'est ni modifié ni chiffré ; cependant, lorsque l' en-tête d'authentification est utilisé, les adresses IP ne peuvent être modifiées par traduction d'adresses réseau ( NAT ), car cela invalide systématiquement la valeur de hachage . Les couches transport et application sont toujours sécurisées par un hachage, ce qui les rend inaltérables, même par la traduction des numéros de port .

Un moyen d'encapsuler les messages IPsec pour la traversée NAT (NAT-T) a été défini par les documents RFC décrivant le mécanisme NAT-T.

En mode tunnel, le paquet IP entier est chiffré et authentifié. Il est ensuite encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP. Le mode tunnel est utilisé pour créer des réseaux privés virtuels pour les communications entre réseaux (par exemple, entre routeurs pour relier des sites), entre hôtes et réseaux (par exemple, l'accès d'un utilisateur distant) et entre hôtes (par exemple, les conversations privées).

Le mode tunnel prend en charge la traversée NAT.

Les algorithmes cryptographiques définis pour une utilisation avec IPsec comprennent :

• HMAC - SHA1 / SHA2 pour la protection de l'intégrité et l'authenticité.
• TripleDES - CBC pour la confidentialité
• AES- CBC et AES-CTR pour la confidentialité.
• AES - GCM et ChaCha20-Poly1305 assurent conjointement et efficacement la confidentialité et l'authentification.

Pour plus de détails, veuillez consulter la RFC 8221.

• Diffie–Hellman (RFC 3526)
• ECDH (RFC 4753)

• RSA
• ECDSA (RFC 4754)
• PSK (RFC 6617)
• EdDSA (RFC 8420)

Le protocole IPsec peut être implémenté dans la pile IP d'un système d'exploitation . Cette méthode d'implémentation est utilisée pour les hôtes et les passerelles de sécurité. Différentes piles IP compatibles IPsec sont disponibles auprès d'entreprises telles que HP ou IBM. Une alternative consiste en une implémentation dite « bump-in-the-stack » (BITS), qui ne nécessite aucune modification du code source du système d'exploitation. Dans ce cas, IPsec est installé entre la pile IP et les pilotes réseau . De cette manière, les systèmes d'exploitation peuvent être mis à niveau avec IPsec. Cette méthode d'implémentation est également utilisée pour les hôtes et les passerelles. Cependant, lors de l'ajout d'IPsec ultérieurement, l'encapsulation des paquets IP peut poser problème pour la découverte automatique de l'unité de transmission maximale (MTU) du chemin , qui détermine la taille maximale de la MTU sur le chemin réseau entre deux hôtes IP. Si un hôte ou une passerelle possède un cryptoprocesseur dédié , ce qui est courant dans le secteur militaire et présent également dans les systèmes commerciaux, une implémentation dite « bump-in-the-wire » (BITW) d'IPsec est possible.

Lorsque IPsec est implémenté dans le noyau , la gestion des clés et la négociation ISAKMP / IKE sont effectuées depuis l'espace utilisateur. L'API de gestion de clés « PF_KEY, version 2 », développée par le NRL et spécifiée ouvertement, est souvent utilisée pour permettre à l'application de gestion de clés de l'espace applicatif de mettre à jour les associations de sécurité IPsec stockées dans l'implémentation IPsec de l'espace noyau. Les implémentations IPsec existantes incluent généralement ESP, AH et IKE version 2. Les implémentations IPsec existantes sur les systèmes d'exploitation de type Unix , par exemple Solaris ou Linux , incluent généralement PF_KEY version 2.

L'IPsec embarqué peut être utilisé pour assurer la communication sécurisée entre les applications s'exécutant sur des systèmes aux ressources limitées avec une faible surcharge.

Le protocole IPsec a été développé conjointement avec IPv6 et devait initialement être pris en charge par toutes les implémentations conformes aux normes IPv6 avant que la RFC 6434 n'en fasse une simple recommandation. IPsec est également optionnel pour les implémentations IPv4 . Il est le plus souvent utilisé pour sécuriser le trafic IPv4.

Les protocoles IPsec ont été initialement définis dans les RFC 1825 à 1829, publiés en 1995. En 1998, ces documents ont été remplacés par les RFC 2401 et 2412, présentant quelques incompatibilités techniques, bien que conceptuellement identiques. Par ailleurs, un protocole d'authentification mutuelle et d'échange de clés, Internet Key Exchange (IKE), a été défini pour créer et gérer les associations de sécurité. En décembre 2005, de nouvelles normes ont été définies dans les RFC 4301 et 4309, qui constituent en grande partie un sur-ensemble des éditions précédentes et introduisent une seconde version de la norme Internet Key Exchange, IKEv2 . Ces documents de troisième génération ont normalisé l'abréviation d'IPsec en « IP » majuscule et « sec » minuscule. « ESP » fait généralement référence à la RFC 4303, qui est la version la plus récente de la spécification.

Depuis mi-2008, un groupe de travail sur la maintenance et les extensions d'IPsec (ipsecme) est actif au sein de l'IETF.

En 2013, suite aux révélations de Snowden , il a été démontré que la NSA (Agence nationale de sécurité américaine ) s'efforçait activement d'« insérer des vulnérabilités dans les systèmes de chiffrement commerciaux, les systèmes informatiques, les réseaux et les terminaux de communication utilisés par les cibles » dans le cadre du programme Bullrun . Il est allégué qu'IPsec était un système de chiffrement ciblé.

La pile IPsec d'OpenBSD est apparue plus tard et a également été largement copiée. Dans une lettre que Theo de Raadt , développeur principal d'OpenBSD , a reçue le 11 décembre 2010 de Gregory Perry, il est allégué que Jason Wright et d'autres personnes, travaillant pour le FBI, ont inséré « un certain nombre de portes dérobées et de mécanismes de fuite de clés par canal auxiliaire » dans le code cryptographique d'OpenBSD. Dans le courriel transféré de 2010, Theo de Raadt n'a pas initialement exprimé de position officielle sur la validité de ces allégations, se contentant de les approuver implicitement en les transférant. Réponse de Jason Wright aux allégations : « Toute légende urbaine gagne en crédibilité lorsqu'elle est étayée par des noms, des dates et des heures réelles. Le courriel de Gregory Perry entre dans cette catégorie… Je tiens à affirmer clairement que je n'ai ajouté aucune porte dérobée au système d'exploitation OpenBSD ni au cadre cryptographique OpenBSD (OCF). » Quelques jours plus tard, de Raadt a commenté : « Je pense que NETSEC a probablement été engagée pour écrire des portes dérobées comme cela a été allégué… Si elles ont été écrites, je ne crois pas qu’elles se soient retrouvées dans notre arbre de sécurité. » Ceci a été publié avant les révélations de Snowden.

Une autre explication avancée par les auteurs de l' attaque Logjam suggère que la NSA a compromis les VPN IPsec en sapant l' algorithme Diffie-Hellman utilisé pour l'échange de clés. Dans leur article , ils affirment que la NSA a spécialement conçu un cluster de calcul pour précalculer les sous-groupes multiplicatifs de nombres premiers et de générateurs spécifiques, comme celui du second groupe d'Oakley défini dans la RFC 2409. En mai 2015, 90 % des VPN IPsec adressables prenaient en charge ce second groupe d'Oakley dans le cadre d'IKE. Si une organisation précalculait ce groupe, elle pourrait déduire les clés échangées et déchiffrer le trafic sans insérer de porte dérobée logicielle.

Une seconde explication alternative avancée suggérait que le groupe Equation avait exploité des failles zero-day contre les équipements VPN de plusieurs fabricants. Ces failles ont été validées par Kaspersky Lab comme étant liées au groupe Equation et par les fabricants eux-mêmes comme étant de véritables exploits, dont certains étaient des failles zero-day au moment de leur découverte. Les pare-feu Cisco PIX et ASA présentaient des vulnérabilités exploitées par la NSA pour des écoutes téléphoniques .

De plus, les VPN IPsec utilisant le mode agressif transmettent un hachage de la clé pré-partagée (PSK) en clair. Cette vulnérabilité peut être, et semble être, ciblée par la NSA au moyen d'attaques par dictionnaire hors ligne .