À propos des algorithmes et Protocoles IPSec
IPSec est un ensemble de services cryptographiques et de protocoles de sécurité qui protègent les communications entre les périphériques qui envoient du trafic par l'intermédiaire d'un réseau non approuvé. IPSec étant basé sur un ensemble de protocoles et d'algorithmes courants, vous pouvez créer un VPN IPSec entre votre Firebox et de nombreux autres périphériques ou endpoints en nuage prenant en charge ces protocoles standards.
Algorithmes de chiffrement
- AES (norme de chiffrement avancée) — AES est l'algorithme de chiffrement le plus puissant disponible. Fireware peut utiliser les clés de chiffrement AES suivantes : 128, 192 ou 256 bits. AES est plus rapide que 3DES.
- 3DES (Triple DES) — Algorithme de chiffrement basé sur la norme DES utilisant l'algorithme de chiffrement DES pour chiffrer trois fois les données. La clé de chiffrement est de 168 bits. 3DES est plus lent qu'AES.
La faille Sweet32 affecte le 3DES. - DES (norme de chiffrement de données) — Utilise une clé de chiffrement de 56 bits. Le DES est le plus faible des trois algorithmes. Il n'est pas considéré comme étant sûr.
Algorithmes d'authentification
Les algorithmes d'authentification vérifient l'intégrité des données et l'authenticité d'un message. Fireware prend en charge trois algorithmes d'authentification :
HMAC-MD5 (code d'authentification de message de hachage — Message Digest Algorithm 5)
MD5 produit un prétraitement de message de 128 bits (16 octets), ce qui le rend plus rapide que SHA-1 et SHA2. C'est l'algorithme le moins sécurisé.
HMAC-SHA1 (code d'authentification de message de hachage — Secure Hash Algorithm 1)
SHA-1 produit un prétraitement de message de 160 bits (20 octets). Bien qu'il soit plus lent que le MD5, ce prétraitement plus grand offre plus de résistance aux attaques en force. Le SHA-1 est considéré comme peu sécurisé en raison d'une faille.
HMAC-SHA2 (code d'authentification de message de hachage — Secure Hash Algorithm 2)
Le SHA2 est l'algorithme le plus sûr. Fireware v11.8 et ultérieure gère trois variantes de SHA2 avec des longueurs de prétraitement de message différentes.
- SHA2-256 — produit un prétraitement de message de 265 bits (32 octets)
- SHA2-384 — produit un prétraitement de message de 384 bits (48 octets)
- SHA2-512 — produit un prétraitement de message de 512 bits (64 octets)
SHA2 est plus sécurisé que SHA1 ou MD5. Nous vous recommandons de spécifier une variante SHA2.
SHA-2 n'est pas pris en charge sur les périphériques XTM
Galois/Counter Mode (GCM)
GCM (Galois/Counter Mode) est un algorithme de chiffrement authentifié reconnu pour sa sécurité, son efficacité et ses performances. L'authentification et le chiffrement se produisent simultanément. Si vous spécifiez AES-GCM dans la configuration de votre interface virtuelle BOVPN ou BOVPN, vous observerez probablement une augmentation des performances sur les Fireboxes non équipés de puce de chiffrement matérielle. Il s'agit notamment des modèles Firebox T55 et T70.
Fireware v12.2 et les versions ultérieures prennent en charge AES-GCM pour les interfaces virtuelles IPSec BOVPN et BOVPN. Vous pouvez spécifier les options suivantes :
- AES-GCM (128-bit)
- AES-GCM (192-bit)
- AES-GCM (256-bit)
Phase 1
AES-GCM est pris en charge comme transformation de Phase 1 IKEv2. IKEv1 n'est pas pris en charge.
Phase 2
AES-GCM est pris en charge en tant que proposition de Phase 2 ESP (Encapsulating Security Payload). AES-GCM n'est pas pris en charge pour AH (Authentication Header).
AES-GCM utilise une Valeur de Contrôle d'Intégrité (ICV) de manière à vérifier l'intégrité des données. Fireware prend en charge une Valeur de Contrôle d'Intégrité (ICV) de 16 octets. Les ICV présentant d'autres longueurs ne sont pas pris en charge.
GCM est requis par la norme cryptographique NSA Suite B conçue par le gouvernement des États-Unis.
Pour de plus amples informations concernant AES-GCM dans IPSec ESP, consultez la RFC 4106.
AES-GCM n'est pas pris en charge pour Mobile VPN with IPSec.
Protocole IKE
Le protocole IKE (Internet Key Exchange) est un utilisé pour la négociation des associations de sécurité IPSec. Ces associations de sécurité établissent des secrets de session partagée à partir desquels des clés sont dérivées pour le chiffrement de données mises en tunnel. IKE est également utilisé pour authentifier les deux pairs IPSec. Fireware prend en charge IKEv1 et IKEv2 dans la configuration de la passerelle BOVPN ou d'une Interface Virtuelle BOVPN.
- Le protocole IKEv1 est défini dans la RFC 2409.
- Le protocole IKEv2 est défini dans la RFC 7296.
IKEv2 nécessite Fireware v11.11.2 ou une version ultérieure.
Algorithme d'échange de clé Diffie-Hellman
L'algorithme d'échange de clé Diffie-Hellman (DH) est une méthode utilisée pour créer une clé de chiffrement partagée accessible à deux entités sans échange de la clé. La clé de chiffrement pour les deux périphériques est utilisée comme clé symétrique pour le chiffrement de données. Seules les deux parties impliquées dans l'échange de clé DH peuvent déduire la clé partagée, et la clé n'est jamais transférée.
Un groupe de clé Diffie-Hellman est un groupe de nombres entiers utilisé pour l'échange de clé Diffie-Hellman. Fireware peut utiliser les groupes DH 1, 2, 5, 14, 15, 19 et 20.
Pour plus d'informations, consultez À propos des Groupes Diffie-Hellman.
AH
Défini dans RFC 2402, l'en-tête d'authentification (AH) est un protocole que vous pouvez utiliser lors des négociations VPN de phase 2 en BOVPN manuel. Pour permettre la sécurisation, AH ajoute des informations d'authentification au datagramme IP. La plupart des tunnels VPN n'utilisent pas le protocole AH car il ne propose pas le chiffrement.
ESP
Définie dans RFC 2406, la charge utile de sécurité par encapsulage (ESP) permet l'authentification et le chiffrement des données. Le protocole ESP prend la charge utile d'un paquet de données et la remplace par des données chiffrées. Il ajoute des vérifications d'intégrité pour s'assurer que les données ne soient pas modifiées au cours du transfert, et que les données proviennent de la bonne source. Nous vous recommandons d'utiliser l'ESP pour les négociations de phase 2 BOVPN car l'ESP offre plus de sécurité que l'AH. Mobile VPN with IPSec utilise toujours l'ESP.
Paramètres Recommandés
Les paramètres BOVPN par défaut sur le Firebox sont destinés à assurer la compatibilité avec les anciens périphériques WatchGuard et les périphériques tiers. Si le périphérique d'endpoint du pair prend en charge IKEv2 et des paramètres de chiffrement et d'authentification plus puissants, nous vous recommandons de modifier les paramètres par défaut pour une sécurité et des performances accrues.
Pour les paramètres recommandés, consultez Améliorer la disponibilité d'un Tunnel Branch Office VPN (BOVPN).