Négociation des clés IKE

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.

Terminologie relative aux clés IKE

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.
Confidentialité de transmission parfaite	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.

Phase 1 d'IKE

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.

Phase 2 d'IKE

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.