Le protocole IKE (Internet Key Exchange, échange de clé Internet) automatise la gestion des clés pour IPsec. Ce chapitre aborde les sujets suivants :
Pour plus d'informations sur l'implémentation du protocole IKE, reportez-vous au Chapitre 23Configuration du protocole IKE (tâches). Pour obtenir des informations de référence, reportez-vous au Chapitre 24Protocole IKE (référence). Pour plus d'informations sur les protocoles IPsec, reportez-vous au Chapitre 19Architecture IPsec (présentation).
Solaris 10 4/09 : À partir de cette version, l'utilitaire de gestion des services (SMF) gère IKE en tant que service. Par défaut, le service svc:/network/ipsec/ike:default est désactivé. Par ailleurs, dans cette version, le profil de droits Network IPsec Management permet d'administrer IPsec et IKE.
Solaris 10 7/07 : à partir de cette version, le protocole IKE peut utiliser l'algorithme AES et être configuré dans la zone globale en vue de son utilisation dans des zones non globales.
L'option de socket SO_ALLZONES permet au protocole IKE de gérer le trafic dans les zones non globales.
Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10.
La gestion des numéros de clé des associations de sécurité (Security Associations, SA) pour IPsec est appelée gestion des clés. La gestion automatique des clés requiert un canal de communication sécurisé pour la création, l'authentification et l'échange des clés. Le Système d'exploitation Solaris utilise IKE pour automatiser la gestion des clés. IKE s'intègre facilement dans les environnement à grande échelle et peut fournir un canal sécurisé pour un grand volume de trafic. Les associations de sécurité IPsec sur paquets IPv4 et IPv6 peuvent utiliser le protocole IKE.
Lorsque IKE est utilisé sur un système équipé d'une carte Sun Crypto Accelerator 1000, 6000 ou Sun Crypto Accelerator 4000, les opérations de clés publiques peuvent être déchargées sur l'accélérateur. Les opérations de clés publiques n'utilisent pas les ressources du système d'exploitation. Lorsque IKE est utilisé sur un système équipé d'une carte Sun Crypto Accelerator 4000 ou Sun Crypto Accelerator 6000, les certificats et les clés publiques et privées peuvent être stockés sur la carte. Le stockage des clés hors du système fournit une couche de protection supplémentaire.
Le démon IKE in.iked négocie et authentifie les numéros de clé des associations de sécurité (SA, security associations) de façon sécurisée. Il utilise des germes de sécurité aléatoires pour les clés des fonctions internes fournies par le Système d'exploitation Solaris. Le protocole IKE assure une confidentialité de transmission parfaite (PFS, perfect forward secrecy). En mode PFS, les clés qui protègent la transmission des données ne sont pas utilisées pour générer des clés complémentaires. Les germes de sécurité employés pour créer des clés de transmission de données ne sont pas réutilisés. Reportez-vous à la page de manuel in.iked(1M).
Lorsque le démon IKE découvre la clé de chiffrement d'un système public distant, le système local peut utiliser cette clé. Il l'emploie pour chiffrer les messages, qui ne peuvent alors être lus que par ce système distant. L'intervention du démon IKE se décompose en deux phases, dites d'échange.
Le tableau ci-dessous répertorie les termes utilisés dans la négociation des clés et les acronymes les plus couramment employés. Vous y trouverez également une définition de chacun de ces termes ainsi que leur contexte d'utilisation.
Tableau 22–1 Terminologie de négociation des clés, acronymes et utilisation
Terminologie de négociation des clés |
Acronymes |
Définition et utilisation |
---|---|---|
Échange de clés |
|
Processus de génération de clés pour les algorithmes cryptographiques asymétriques. Les principales méthodes utilisées sont les protocoles RSA et Diffie-Hellman. |
Protocole Diffie-Hellman |
DH |
Protocole d'échange de clés impliquant la génération et l'authentification de clés et souvent appelé échange de clés authentifiées. |
Protocole RSA |
RSA |
Protocole d'échange de clés impliquant la génération et le transport de clés. Ce protocole porte le nom de ses trois créateurs : Rivest, Shamir et Adleman. |
PFS (perfect forward secrecy) |
Ne s'applique qu'à l'échange de clés authentifiées. Le mode PFS garantit que l'éventuelle découverte de secrets à long terme ne compromet pas les clés des communications précédentes. Perfect Forward Secrecy, secret rigoureux des transmission .Avec la fonction PFS, la clé visant à protéger la transmission des données n'est pas utilisée pour dériver d'autres clés. Il en est de même pour la source de la clé. |
|
Méthode Oakley |
|
Méthode de création sécurisée de clés pour la phase 2. Ce protocole est similaire à l'échange de clés Diffie-Hellman et implique la génération et l'authentification de clés. La méthode Oakley s'emploie pour négocier des PFS. |
La phase 1 est connue sous le nom de Main Mode (mode principal). Pendant la phase 1, IKE utilise des méthodes de chiffrement de clé publique pour s'authentifier auprès d'entités IKE homologues. Il en résulte une association de sécurité (SA, security association) ISAKMP (Internet Security Association and Key Management Protocol). Une SA ISAKMP est un canal sécurisé sur lequel IKE négocie les numéros de clé des datagrammes IP. Contrairement aux SA IPsec, les SA ISAKMP sont bidirectionnelles. Il n'est donc pas nécessaire de disposer de plus d'une association de sécurité.
La façon dont IKE négocie les numéros de clé lors de la phase 1 peut être configurée. IKE lit les informations concernant la configuration dans le fichier /etc/inet/ike/config. Ces informations incluent :
des paramètres généraux tels que le nom des certificats de clés publiques ;
l'activation ou non du mode de confidentialité de transmission parfaite (PFS) ;
les interfaces concernées ;
les protocoles de sécurité et leurs algorithmes ;
la méthode d'authentification.
Les deux méthodes d'authentification utilisent respectivement les clés prépartagées et les certificats de clés publiques. Les certificats de clés publiques peuvent être autosignés ou émis par l'autorité de certification (AC) d'un fournisseur d'infrastructures de clés publiques (PKI). telles que beTrusted, Entrust, GeoTrust, RSA Security et Verisign.
La phase 2 est connue sous le nom de Quick Mode (mode rapide). Lors de la phase 2, IKE crée et gère les SA IPsec entre les systèmes qui exécutent le démon IKE. IKE utilise le canal sécurisé qui a été créé lors de la phase 1 pour protéger la transmission des numéros de clé. Le démon IKE crée les clés à partir d'un générateur de nombres aléatoires à l'aide du périphérique /dev/random. Le démon actualise les clés à une fréquence qui peut être configurée. Les numéros de clé sont accessibles aux algorithmes spécifiés dans le fichier de configuration ipsecinit.conf de la stratégie IPsec.
Le fichier de configuration /etc/inet/ike/config contient des entrées de stratégie IKE. Pour que deux démons IKE puissent s'authentifier mutuellement, les entrées doivent être valides et les numéros de clé doivent être disponibles. Les entrées des fichiers de configuration déterminent la façon dont les numéros de clé seront utilisés pour authentifier l'échange qui a lieu lors de la phase 1. Il y a deux possibilités : les clés prépartagées ou les certificats de clés publiques.
Si l'entrée est auth_method preshared, ce sont les clés prépartagées qui sont utilisées pour authentifier l'échange. Si auth_method possède une valeur autre que preshared, l'authentification s'effectue à l'aide de certificats de clés publiques. Ces certificats peuvent être autosignés ou installés par un fournisseur de PKI. Pour plus d'informations, reportez-vous à la page de manuel ike.config(4).
Les clés prépartagées sont créées par un administrateur sur un système. Elles sont ensuite partagées hors bande avec les administrateurs de systèmes distants. Prenez soin de créer de longues clés aléatoires et de protéger le fichier et la transmission hors bande. Les clés sont placées dans le fichier /etc/inet/secret/ike.preshared de chaque système. Le fichier ike.preshared est réservé à IKE et le fichier ipseckeys à IPsec. Toute compromission des clés du fichier ike.preshared compromet toutes les clés qui en sont dérivées.
Le système de clés prépartagées doit être identique au système distant de clés correspondant. Les clés sont liées à une adresse IP donnée. Elles sont plus sécurisées lorsqu'un administrateur contrôle les systèmes communicants. Pour plus d'informations, reportez-vous à la page de manuel ike.preshared(4).
Grâce aux certificats de clés publiques, les systèmes communicants n'ont plus besoin de partager de numéros de clé secrets hors bande. Les clés publiques utilisent le protocole Diffie-Hellman (DH) pour authentifier et négocier les clés. Les certificats de clés publiques peuvent être soit autosignés, soit certifiés par une autorité de certification (AC).
Les certificats de clés publiques autosignés sont créés par l'administrateur. La commande ikecert certlocal -ks permet de créer la partie privée des biclés du système. Le certificat autosigné est ensuite émis, au format X.509, par le système distant. Le certificat du système distant est entré à l'aide de la commande ikecert certdb pour la partie publique de la clé. Les certificats autosignés résident dans le répertoire /etc/inet/ike/publickeys des systèmes communicants. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté.
Les certificats autosignés sont à mi-chemin entre les clés prépartagées et les AC. Contrairement aux clés prépartagées, les certificats autosignés peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Pour autosigner un certificat pour un système n'ayant pas de numéro fixe, utilisez un nom alternatif de DNS (www.example.org ) ou d'email (root@domain.org).
Les clés publiques peuvent être délivrées par un fournisseur de PKI ou une AC. Elles doivent être installées, avec les certificats AC qui les accompagnent, dans le répertoire /etc/inet/ike/publickeys. Lorsque vous utilisez l'option -T, les certificats résident sur le matériel connecté. Les fournisseurs émettent également des listes de révocation de certificats (LRC). Outre les clés et les certificats AC, vous devez également installer les LRC dans le répertoire /etc/inet/ike/crls.
Les certificats AC présentent l'avantage d'être certifiés par une organisation externe, et non par l'administrateur du site. Il s'agit en quelque sorte de certificats "certifiés". Comme les certificats autosignés, les certificats AC peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté. Contrairement aux certificats autosignés, ils s'intègrent facilement aux environnement à grande échelle afin de protéger un grand nombre de systèmes communicants.
Les algorithmes IKE recoupent de nombreux calculs, notamment lors de la phase 1. Les systèmes qui traitent un grand nombre d'échanges peuvent utiliser une carte Sun Crypto Accelerator 1000 pour traiter les opérations de clés publiques. Les cartes Sun Crypto Accelerator 6000 et Sun Crypto Accelerator 4000 peuvent également être utilisées pour gérer les calculs onéreux relatifs à la phase 1.
Pour plus d'informations sur la manière dont le protocole IKE doit être configuré pour décharger les calculs sur la carte d'accélération, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000 . Pour plus d'informations sur le stockage des clés, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000 et à la page de manuel cryptoadm(1M).
Les certificats de clés publiques, ainsi que les clés privées et publiques peuvent être stockés sur une carte Sun Crypto Accelerator 6000 ou &sca 4;. En chiffrement RSA, la longueur maximale des clés prise en charge par la carte Sun Crypto Accelerator 4000 est de 2 048 bits. En chiffrement DSA, elle est de 1 024 bits. La carte Sun Crypto Accelerator 6000 prend en charge les algorithmes SHA-512 et ECC.
Pour plus d'informations sur la manière dont le protocole IKE doit être configuré pour accéder à la carte, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000 . Pour plus d'informations sur l'ajout de certificats et de clés publiques à la carte, reportez-vous à la section Génération et stockage de certificats de clés publiques sur le matériel.
Vous trouverez, dans le tableau ci-dessous, une liste des fichiers de configuration de la stratégie IKE, les emplacements de stockage des clés IKE et les différentes commandes et divers services permettant d'implémenter IKE. Pour plus d'informations sur ces services, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.
Tableau 22–2 Fichiers de configuration IKE, emplacements de stockage des clés, commandes et services
À partir de Solaris 9, IKE inclut les fonctionnalités suivantes :
IKE peut être utilisé pour automatiser l'échange de clés pour IPsec via des réseaux IPv6. Pour plus d'informations, reportez-vous à la section Gestion des clés avec IKE.
IKE ne peut pas être utilisé pour gérer des clés IPsec dans une zone non globale.
Les opérations IKE relatives aux clés publiques peuvent être accélérées grâce à l'ajout d'une carte Sun Crypto Accelerator 1000 ou Sun Crypto Accelerator 4000 sur laquelle elles sont déchargées. Le déchargement accélère le chiffrement et réduit ainsi l'utilisation des ressources de système d'exploitation. Pour plus d'informations, reportez-vous à la section Protocole IKE et accélération matérielle. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches).
Les certificats de clés publiques, les clés privées et les clés publiques peuvent être stockés sur une carte Sun Crypto Accelerator 4000. Pour plus d'informations sur le stockage des clés, reportez-vous à la section Protocole IKE et stockage matériel.
IKE peut être utilisé pour automatiser l'échange de clés pour IPsec depuis un système situé derrière un boîtier NAT. Le trafic doit emprunter un réseau IPv4 et les clés IPsec de l'ESP traversant le NAT ne peuvent pas être accélérées à l'aide d'un composant matériel. Pour plus d'informations, reportez-vous à la section Passage de la translation d'adresses et IPsec. Pour plus d'informations sur les procédures, reportez-vous à la section Configuration du protocole IKE pour les systèmes portables (liste des tâches).
Des paramètres de retransmission et de délai d'expiration des paquets ont été ajoutés au fichier /etc/inet/ike/config. Ces paramètres ajustent la négociation de la phase 1 d'IKE (Main Mode) afin de traiter les interférences réseau, les augmentations de trafic et l'interopération avec des plates-formes possédant des implémentations du protocole IKE différentes. Pour plus d'informations sur ces paramètres, reportez-vous à la page de manuel ike.config(4) Pour plus d'informations sur les procédures, reportez-vous à la section Modification des paramètres de transmission du protocole IKE (liste des tâches).