Principes de base d’IPsec

Associations de sécurité

Une association de sécurité (AS) est un accord unidirectionnel entre les participants au VPN concernant les méthodes et les paramètres à utiliser pour sécuriser un canal de communication. Une communication bidirectionnelle complète nécessite au moins deux SA, un pour chaque direction. Par le biais de la SA, un tunnel IPsec peut fournir les fonctions de sécurité suivantes :

• Protection de la vie privée (par cryptage)

• Intégrité du contenu (grâce à l’authentification des données)

• Authentification de l’expéditeur et, en cas d’utilisation de certificats, non-répudiation (via l’authentification de l’origine des données)

Les fonctions de sécurité que vous utilisez dépendent de vos besoins. Si vous avez uniquement besoin d’authentifier la source du paquet IP et l’intégrité du contenu, vous pouvez authentifier le paquet sans appliquer de chiffrement. D’autre part, si vous ne vous souciez que de préserver la confidentialité, vous pouvez chiffrer le paquet sans appliquer de mécanismes d’authentification. Si vous le souhaitez, vous pouvez à la fois chiffrer et authentifier le paquet. La plupart des concepteurs de sécurité réseau choisissent de chiffrer, d’authentifier et de protéger leur trafic VPN contre la relecture.

Un tunnel IPsec se compose d’une paire de SA unidirectionnelles (une SA pour chaque direction du tunnel) qui spécifient l’indice des paramètres de sécurité (SPI), l’adresse IP de destination et le protocole de sécurité (en-tête d’authentification [AH] ou charge utile de sécurité d’encapsulation [ESP] utilisé). Une SA regroupe les éléments suivants pour la sécurisation des communications :

• Algorithmes et clés de sécurité.

• Mode protocole, transport ou tunnel. Les équipements Junos OS utilisent toujours le mode tunnel. (Voir Traitement des paquets en mode tunnel.)

• Méthode de gestion des clés, soit à clé manuelle, soit à clé automatique IKE.

• SA à vie.

Pour le trafic entrant, Junos OS recherche la SA à l’aide du triplet suivant :

• Adresse IP de destination.

• Protocole de sécurité, AH ou ESP.

• Valeur de l’indice des paramètres de sécurité (SPI).

Pour le trafic VPN sortant, la stratégie appelle la SA associée au tunnel VPN.

Clé manuelle

Avec les clés manuelles, les administrateurs aux deux extrémités d’un tunnel configurent tous les paramètres de sécurité. Il s’agit d’une technique viable pour les petits réseaux statiques où la distribution, la maintenance et le suivi des clés ne sont pas difficiles. Cependant, la distribution en toute sécurité de configurations de clés manuelles sur de longues distances pose des problèmes de sécurité. Mis à part le fait de passer les clés face à face, vous ne pouvez pas être totalement sûr que les clés n’ont pas été compromises pendant le transport. De plus, chaque fois que vous souhaitez modifier la clé, vous êtes confronté aux mêmes problèmes de sécurité que lorsque vous l’avez initialement distribuée.

Clé automatique IKE

Lorsque vous devez créer et gérer de nombreux tunnels, vous avez besoin d’une méthode qui ne vous oblige pas à configurer chaque élément manuellement. IPsec prend en charge la génération et la négociation automatisées de clés et d’associations de sécurité à l’aide du protocole Internet Key Exchange (IKE). Junos OS fait référence à la négociation de tunnel automatisée comme AutoKey IKE et prend en charge AutoKey IKE avec des clés prépartagées et AutoKey IKE avec des certificats.

• IKE AutoKey avec des clés prépartagées : en utilisant l’IKE AutoKey avec des clés prépartagées pour authentifier les participants à une session IKE, chaque partie doit configurer et échanger la clé prépartagée en toute sécurité à l’avance. À cet égard, la question de la distribution sécurisée des clés est la même que celle des clés manuelles. Cependant, une fois distribuée, une clé automatique, contrairement à une clé manuelle, peut automatiquement modifier ses clés à des intervalles prédéterminés à l’aide du protocole IKE. Le changement fréquent des clés améliore considérablement la sécurité, et le fait de le faire automatiquement réduit considérablement les responsabilités en matière de gestion des clés. Toutefois, la modification des clés augmente les coûts de trafic. Par conséquent, changer de clé trop souvent peut réduire l’efficacité de la transmission des données.

  Une clé pré-partagée est une clé de chiffrement et de déchiffrement, que les deux participants doivent avoir avant d’initier la communication.

• IKE AutoKey avec certificats : lors de l’utilisation de certificats pour authentifier les participants lors d’une négociation IKE AutoKey, chaque partie génère une paire de clés publique-privée et acquiert un certificat. Tant que l’autorité de certification émettrice est approuvée par les deux parties, les participants peuvent récupérer la clé publique de l’homologue et vérifier sa signature. Il n’est pas nécessaire de garder une trace des clés et des SA ; IKE le fait automatiquement.

Échange Diffie-Hellman

Un échange Diffie-Hellman (DH) permet aux participants de produire une valeur secrète partagée. La force de la technique est qu’elle permet aux participants de créer la valeur secrète sur un support non sécurisé sans faire passer la valeur secrète à travers le fil. La taille du module d’amorçage utilisé dans le calcul de chaque groupe diffère, comme indiqué dans le tableau ci-dessous. Les opérations d’échange Diffie Hellman (DH) peuvent être effectuées soit dans le logiciel, soit dans le matériel. La liste suivante Tableau 1 répertorie les différents groupes Diffie Hellman (DH) et spécifie si l’opération effectuée pour ce groupe se trouve dans le matériel ou dans le logiciel.

Tableau 1 : Groupes Diffie Hellman (DH) et leurs opérations d’échange effectuées

Groupe Diffie-Hellman (DH)	Taille du module principal
DH Groupe 1	768 bits
DH Groupe 2	102 bits
DH Groupe 5	1536 bits
DH Groupe 14	2048 bits
DH Groupe 15	3072 bits
DH Groupe 16	4096 bits
DH Groupe 19	Courbe elliptique 256 bits
DH Groupe 20	Courbe elliptique 384 bits
DH Groupe 21	Courbe elliptique 521 bits
DH Groupe 24	2048 bits avec sous-groupe d’ordre premier 256 bits

À partir de Junos OS version 19.1R1, les pare-feu SRX Series prennent en charge les groupes DH 15, 16 et 21.

À partir de Junos OS version 20.3R1, les instances de pare-feu virtuel vSRX avec le package junos-ike installé prennent en charge les groupes DH 15, 16 et 21.

Nous ne recommandons pas l’utilisation des groupes DH 1, 2 et 5.

Étant donné que le module de chaque groupe DH est d’une taille différente, les participants doivent accepter d’utiliser le même groupe.

Algorithmes d’authentification IPsec (protocole AH)

Le protocole AH (Authentication Header) permet de vérifier l’authenticité et l’intégrité du contenu et de l’origine d’un paquet. Vous pouvez authentifier le paquet à l’aide de la somme de contrôle calculée via un code d’authentification de message de hachage (HMAC) à l’aide d’une clé secrète et de fonctions de hachage MD5 ou SHA.

• Message Digest 5 (MD5) : algorithme qui produit un hachage de 128 bits (également appelé signature numérique ou condensé de message) à partir d’un message de longueur arbitraire et d’une clé de 16 octets. Le hachage résultant est utilisé, comme une empreinte digitale de l’entrée, pour vérifier l’authenticité et l’intégrité du contenu et de la source.

• Algorithme de hachage sécurisé (SHA) : algorithme qui produit un hachage de 160 bits à partir d’un message de longueur arbitraire et d’une clé de 20 octets. Il est généralement considéré comme plus sûr que MD5 en raison des hachages plus importants qu’il produit. Le traitement informatique étant effectué dans l’ASIC, le coût en performances est négligeable.

Pour plus d’informations sur les algorithmes de hachage MD5, consultez RFC 1321 et RFC 2403. Pour plus d’informations sur les algorithmes de hachage SHA, consultez RFC 2404. Pour plus d’informations sur HMAC, reportez-vous à la RFC 2104.

Algorithmes de chiffrement IPsec (protocole ESP)

Le protocole ESP (Encapsulating Security Payload) permet d’assurer la confidentialité (chiffrement), l’authentification de la source et l’intégrité du contenu (authentification). L’ESP en mode tunnel encapsule l’intégralité du paquet IP (en-tête et charge utile), puis ajoute un nouvel en-tête IP au paquet désormais chiffré. Ce nouvel en-tête IP contient l’adresse de destination nécessaire pour acheminer les données protégées à travers le réseau. (Voir Traitement des paquets en mode tunnel.)

Avec ESP, vous pouvez à la fois chiffrer et authentifier, chiffrer uniquement ou authentifier uniquement. Pour le chiffrement, vous pouvez choisir l’un des algorithmes de chiffrement suivants :

• Data Encryption Standard (DES) : algorithme de bloc cryptographique avec une clé de 56 bits.

• Triple DES (3DES) : version plus puissante de DES dans laquelle l’algorithme DES d’origine est appliqué en trois tours, à l’aide d’une clé de 168 bits. Le DES permet de réaliser d’importantes économies de performance, mais il est considéré comme inacceptable pour de nombreux transferts de matériaux classifiés ou sensibles.

• Advanced Encryption Standard (AES) : norme de chiffrement qui offre une plus grande interopérabilité avec d’autres périphériques. Junos OS prend en charge AES avec des clés 128 bits, 192 bits et 256 bits.

Pour l’authentification, vous pouvez utiliser les algorithmes MD5 ou SHA.

Même s’il est possible de sélectionner NULL pour le chiffrement, il a été démontré qu’IPsec peut être vulnérable aux attaques dans de telles circonstances. Par conséquent, nous vous suggérons de choisir un algorithme de cryptage pour une sécurité maximale.