Chapitre 23 Configuration du protocole IKE (tâches)

Ce chapitre décrit la procédure de configuration du protocole Internet Key Exchange (IKE) sur vos systèmes. Une fois configuré, ce protocole génère automatiquement les numéros de clé IPsec sur votre réseau. Le présent chapitre contient les informations suivantes :

• Configuration du protocole IKE (liste des tâches)

• Configuration du protocole IKE avec des clés prépartagées (liste des tâches)

• Configuration du protocole IKE avec des certificats de clés publiques (liste des tâches)

• Configuration du protocole IKE pour les systèmes portables (liste des tâches)

• Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches)

• Modification des paramètres de transmission du protocole IKE (liste des tâches)

Pour voir une présentation du protocole IKE, reportez-vous au Chapitre 22Protocole IKE (présentation). Pour obtenir des informations de référence sur le protocole IKE, reportez-vous au Chapitre 24Protocole IKE (référence). Pour consulter d'autres procédures, reportez-vous aux sections Exemples des pages de manuel ikeadm(1M), ikecert(1M) et ike.config(4).

Configuration du protocole IKE (liste des tâches)

L'authentification du protocole IKE peut s'effectuer à l'aide de clés prépartagées ou de certificats autosignés ou émanant d'autorités de certifications (AC). Les méthodes d'authentification IKE sont liées par une règle aux points d'extrémité protégés. Vous pouvez donc utiliser toutes les méthodes d'authentification IKE ou une seule d'entre elles sur un système. Un pointeur menant à une bibliothèque PKCS #11 permet aux certificats d'utiliser un accélérateur matériel connecté.

Une fois le protocole IKE configuré, vous devez effectuer les tâches IPsec qui utilisent cette configuration. Le tableau ci-dessous répertorie les tâches correspondant aux différentes configurations IKE.

Configuration du protocole IKE avec des clés prépartagées (liste des tâches)

Le tableau ci-dessous répertorie les procédures de configuration et de maintenance du protocole IKE avec des clés prépartagées.

Configuration du protocole IKE avec des clés prépartagées

Les clés prépartagées sont la méthode d'authentification la plus simple pour IKE. Elles s'utilisent notamment lors de la configuration du protocole IKE sur deux systèmes gérés par le même administrateur. N'oubliez cependant pas que, contrairement aux certificats de clés publiques, les clés prépartagées sont liées à une adresse IP donnée et ne peuvent pas s'utiliser avec des systèmes portables ou des systèmes susceptibles d'être renumérotés. Tenez également compte du fait que, si vous utilisez des clés prépartagées, vous ne pourrez pas décharger de calculs IKE sur le matériel connecté.

Configuration du protocole IKE avec des clés prépartagées

La longueur des clés des algorithmes d'implémentation du protocole IKE est variable. Elle dépend du niveau de sécurité dont vous souhaitez doter le site. En règle générale, la longueur des clés est proportionnelle au niveau de sécurité.

Les noms de systèmes choisis pour illustrer cette procédure sont : enigma et partym. Remplacez enigma et partym par les noms de vos systèmes.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Copiez le fichier /etc/inet/ike/config.sample dans le fichier /etc/inet/ike/config sur chacun des systèmes.

3. Entrez les règles et paramètres globaux dans le fichier ike/config sur chacun des systèmes.

   Les règles et paramètres globaux de ce fichier doivent garantir le fonctionnement de la stratégie IPsec du fichier ipsecinit.conf. Les exemples ike/config ci-dessous vont de pair avec les exemples ipsecinit.conf de la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec.

   1. Modifiez par exemple le fichier /etc/inet/ike/config sur le système enigma :

      ### ike/config file on enigma, 192.168.116.16 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }

      ---

      Remarque –

      Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.

      ---

   2. Modifiez le fichier /etc/inet/ike/config sur le système partym :

      ### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }

4. Vérifiez la syntaxe du fichier sur chacun des systèmes.

   # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

5. Générez des nombres aléatoires que vous utiliserez comme numéros de clé.

   Si votre site possède un générateur de nombres aléatoires, utilisez-le. Sur un système Solaris, vous pouvez utiliser la commande od. La commande suivante vous permet par exemple d'imprimer deux lignes de nombres hexadécimaux :

   % od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d

   Pour plus de détails sur la commande od, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris et à la page de manuel od(1).

   ---

   Remarque –

   D'autres systèmes d'exploitation peuvent nécessiter des numéros de clé au format ASCII. Pour générer une clé identique dans les deux formats, hexadécimal et ASCII, reportez-vous à l'Exemple 23–1.

   ---

6. Créez une clé à partir du résultat de l'Étape 5.

   f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

   Pour cette procédure, l'algorithme d'authentification est SHA–1, comme indiqué à l'Étape 3. La taille du hachage, c'est-à-dire la taille de la sortie de l'algorithme d'authentification, détermine la taille minimale recommandée pour une clé prépartagée. La taille de la sortie de l'algorithme SHA–1 est de 160 bits ou 40 caractères. Dans cet exemple, la clé possède 56 caractères, ce qui permet au protocole IKE de disposer de numéros de clé supplémentaires.

7. Créez un fichier /etc/inet/secret/ike.preshare sur chacun des systèmes.

   Placez la clé prépartagée dans chacun des fichiers.

   1. Sur le système enigma par exemple, le fichier ike.preshared se présente comme suit :

      # ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   2. Sur le système partym, le fichier ike.preshared se présente comme suit :

      # ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   ---

   Remarque –

   Les clés prépartagées doivent être identiques sur chacun des systèmes.

   ---

Exemple 23–1 Génération de numéros de clé identiques pour deux systèmes dotés de systèmes d'exploitation différents

Le protocole IPsec de Solaris fonctionne avec d'autres systèmes d'exploitation. Si votre système communique avec un système qui requiert des clés prépartagées ASCII, vous devez générer une clé dans les deux formats, hexadécimal et ASCII.

Dans cet exemple, l'administrateur système de Solaris veut générer une clé de 56 caractères. Il utilise la commande ci-dessous pour générer une clé hexadécimale à partir d'une phrase de passe ASCII. L'option -tx1 imprime les octets un par un sur tous les systèmes Solaris.

# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

Après suppression des décalages et concaténation de la sortie hexadécimale, la clé hexadécimale pour le système Solaris est 7061706965726d616368652077697468206361736865777320616e64. L'administrateur place cette valeur dans le fichier ike.preshared sur le système Solaris.

# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

Sur le système qui requiert des clés prépartagées ASCII, la phrase de passe correspond à la clé prépartagée. L'administrateur Solaris communique la phrase de passe papiermache with cashews and à l'autre administrateur par téléphone.

Actualisation des clés IKE prépartagées

Cette procédure permet de remplacer une clé prépartagée existante à intervalles réguliers.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Générez des nombres aléatoires et créez une clé possédant une longueur appropriée.

   Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.

3. Remplacez la clé actuelle par une nouvelle clé.

   À titre d'exemple, sur les hôtes enigma et partym, cela revient à remplacer la valeur de key stockée dans le fichier /etc/inet/secret/ike.preshared par un nouveau nombre possédant la même longueur.

4. Lisez la nouvelle clé dans le noyau.

   • À partir de la version Solaris 10 4/09 actualisez le service ike.

     # svcadm refresh ike

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, arrêtez et redémarrez le démon in.iked.

     1. Vérifiez le niveau de privilège du démon in.iked.

        # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled

        Vous pouvez modifier les numéros de clé si la commande renvoie un niveau de privilège 0x1 ou 0x2. Si le niveau renvoyé est 0x0, vous ne pouvez ni modifier ni afficher les numéros de clé. Par défaut, le démon in.iked s'exécute au niveau de privilège 0x0.

     2. Si le niveau de privilège est 0x0, arrêtez le démon et redémarrez-le.

        Lorsque le démon redémarre, il lit la nouvelle version du fichier ike.preshared.

        # pkill in.iked # /usr/lib/inet/in.iked

     3. Si le niveau de privilège est 0x1 ou 0x2, lisez la nouvelle version du fichier ike.preshared.

        # ikeadm read preshared

Affichage des clés IKE prépartagées

Par défaut, la commande ikeadm vous empêche de consulter les clés réelles dans le fichier de vidage d'une SA phase 1. L'affichage des clés est utile lors du débogage.

Pour afficher les clés réelles, vous devez augmenter le niveau de privilège du démon. Pour obtenir une description des niveaux de privilège, reportez-vous à la section Commande d'administration du protocole IKE .

Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.

Avant de commencer

IKE est configuré et le service ike est en cours d'exécution.

1. Affichez les clés IKE prépartagées.

   # ikeadm ikeadm> dump preshared

2. Si une erreur se produit, vous devez augmenter le niveau de privilège du démon in.iked.

   1. Augmentez le niveau de privilège du démon in.iked dans le référentiel SMF.

      # svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat

   2. Augmentez le niveau de privilège du démon in.iked en cours d'exécution.

      # svcadm refresh ike ; svcadm restart ike

   3. (Facultatif) Confirmez que le niveau de privilège est keymat.

      # svcprop -p config/admin_privilege ike keymat

   4. Affichez les clés en exécutant de nouveau l'Étape 1.

3. Réappliquez le niveau de privilège de base au démon IKE.

   1. Après l'affichage des clés, rétablissez le niveau de privilège à sa valeur par défaut.

      # svccfg -s ike setprop config/admin_privilege=base

   2. Actualisez, puis redémarrez IKE.

      # svcadm refresh ike ; svcadm restart ike

Exemple 23–2 Vérification des clés IKE prépartagées dans une version antérieure à la version Solaris 10 4/09

Dans l'exemple suivant, l'administrateur affiche les clés sur un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur souhaite vérifier que les clés de ce système sont identiques aux clés du système communicant. Après avoir vérifié que les clés sont identiques sur les deux systèmes, l'administrateur rétablit le niveau de privilège sur 0.

• Tout d'abord, l'administrateur détermine le niveau de privilège du démon in.iked.

  adm1 # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled

• Le niveau de privilège n'étant pas 0x1 ni 0x2, l'administrateur arrête le démon in.iked, puis augmente le niveau de privilège sur 2.

  adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

• L'administrateur affiche les clés.

  adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1).

• L'administrateur se connecte à distance au système communicant et détermine si les clés sont identiques.

• L'administrateur rétablit ensuite le niveau de privilège de base.

  # ikeadm set priv base

Ajout d'une clé IKE prépartagée pour une nouvelle entrée de stratégie dans ipsecinit.conf

Si vous ajoutez des entrées de stratégie IPsec pendant que IPsec and IKE sont en cours d'exécution, vous devez lire la nouvelle stratégie et les règles IKE dans le noyau. À partir de la version Solaris 10 4/09, redémarrez le service policy et actualisez le service ike une fois les nouvelles clés ajoutées.

Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–3.

Avant de commencer

L'exécution de cette procédure nécessite le respect des conditions suivantes :

• Le système enigma est paramétré selon la procédure décrite à la section Configuration du protocole IKE avec des clés prépartagées.

• Le système enigma protégera son trafic avec un nouveau système, ada.

• Le démon in.iked est exécuté sur les deux systèmes.

• Les interfaces des systèmes figurent en tant qu'entrées dans le fichier /etc/hosts sur les deux systèmes. Ci-dessous un exemple d'entrée :

  192.168.15.7 ada 192.168.116.16 enigma

  Cette procédure fonctionne également avec une adresse IPv6 du fichier /etc/inet/ipnodes. À partir de la version Solaris 10 6/07, les entrées IPv6 sont placées dans le fichier /etc/hosts.

• Vous avez ajouté une nouvelle entrée de stratégie au fichier /etc/inet/ipsecinit.conf sur les deux systèmes. Ces entrées se présentent de la manière suivante :

  # ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}

  # ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

• Dans la version actuelle, vous avez vérifié la syntaxe du fichier /etc/inet/ipsecinit.conf sur les deux systèmes à l'aide de :

  # ipsecconf -c -f /etc/inet/ipsecinit.conf

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Sur ce système, générez des nombres aléatoires et construisez une clé de 64 ou 448 bits.

   Pour plus d'informations, reportez-vous à la section Génération de numéros aléatoires sur un système Solaris. Si vous générez une clé prépartagée pour un système Solaris qui communique avec un système d'exploitation nécessitant une clé ASCII, reportez-vous à l'Exemple 23–1.

3. Transmettez la clé à l'administrateur du système distant.

   Vous devez tous deux ajouter simultanément la même clé prépartagée. La sécurité de cette clé est directement liée à celle du moyen de transmission. Utilisez donc de préférence un moyen hors bande de type courrier recommandé ou fax protégé. Vous pouvez également utiliser une session ssh pour administrer les deux systèmes.

4. Créez une règle pour la gestion des clés de enigma et ada par IKE.

   1. Sur le système enigma, ajoutez la règle suivante au fichier /etc/inet/ike/config :

      ### ike/config file on enigma, 192.168.116.16   ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }

   2. Sur le système ada, ajoutez la règle suivante :

      ### ike/config file on ada, 192.168.15.7   ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }

5. Assurez-vous que les clés IKE prépartagées sont disponibles lors de la réinitialisation.

   1. Sur le système enigma, ajoutez les informations suivantes au fichier /etc/inet/secret/ike.preshared :

      # ike.preshared on enigma for the ada interface #  { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

   2. Sur le système ada, ajoutez les informations suivantes au fichier ike.preshared :

      # ike.preshared on ada for the enigma interface #  { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

6. Sur chaque système, redémarrez le service de stratégie IPsec afin de sécuriser l'interface ajoutée.

   # svcadm restart policy

7. Sur chaque système, actualisez le service ike.

   # svcadm refresh ike

8. Assurez-vous que les systèmes peuvent communiquer entre eux.

   Reportez-vous à la section Méthode de vérification de la concordance des clés prépartagées IKE.

Exemple 23–3 Ajout d'une clé IKE prépartagée pour une nouvelle entrée de stratégie IPsec

Dans l'exemple suivant, l'administrateur ajoute une clé prépartagée à un système Solaris n'exécutant pas la version actuelle de Solaris. L'administrateur suit la procédure précédente pour modifier les fichiers ike/config et ike.preshared et pour générer des clés et contacter le système distant. L'administrateur utilise différentes commandes pour lire la nouvelle stratégie IPsec et les nouvelles règles IKE dans le noyau.

• Avant de générer une nouvelle clé, l'administrateur définit le niveau de privilège du démon in.iked sur 2.

  # pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

• Après l'envoi de la clé à l'autre système et l'ajout d'une nouvelle clé au système, l'administrateur réduit le niveau de privilège.

  # ikeadm set priv base

• Ensuite, l'administrateur lit la nouvelle stratégie IPsec dans le noyau.

  # ipsecconf -a /etc/inet/ipsecinit.conf

• Enfin, l'administrateur lit les nouvelles règles IKE dans le noyau.

  # ikeadm read rules

Méthode de vérification de la concordance des clés prépartagées IKE

La concordance clés prépartagées des systèmes communicants est nécessaire à l'authentification.

Avant de commencer

IPsec est configuré et a été activé entre les deux systèmes sur lesquels vous travaillez. Vous exécutez la version actuelle Solaris10.

Pour effectuer cette procédure sur une version antérieure à la version Solaris 10 4/09, voir l'Exemple 23–2.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Sur chaque système, vérifiez le niveau de privilège du démon in.iked.

   # svcprop -p config/admin_privilege ike base

   • Si le niveau de privilège est keymat, passez à l'Étape 3.

   • Si le niveau de privilège est base ou modkeys, augmentez le niveau de privilège.

     Effectuez une actualisation, puis redémarrez le service ike.

     # svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat

3. Affichez, sur chacun des systèmes, les informations concernant les clés prépartagées.

   # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym).

4. Comparez les résultats obtenus.

   Si les clés prépartagées ne sont pas identiques, remplacez l'une d'entre elles dans le fichier /etc/inet/secret/ike.preshared.

5. Lorsque la vérification est terminée, rétablissez le niveau de privilège par défaut sur chacun des systèmes.

   # svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike

Configuration du protocole IKE avec des certificats de clés publiques (liste des tâches)

Le tableau ci-dessous répertorie les procédures de création de certificats de clés publiques pour IKE. Ces procédures incluent l'accélération et le stockage de certificats sur le matériel connecté.

Configuration du protocole IKE avec des certificats de clés publiques

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. Contrairement aux clés prépartagées, les certificats de clés publiques peuvent être utilisés sur une machine portable ou sur un système susceptible d'être renuméroté.

Les certificats de clés publiques peuvent également être stockés sur le matériel connecté. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches).

Configuration du protocole IKE avec des certificats de clés publiques autosignés

Les certificats autosignés nécessitent un temps système inférieur à celui des certificats publics émanant d'une AC, mais s'intègrent plus difficilement dans un environnement à grande échelle.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Ajoutez un certificat autosigné à la base de données ike.privatekeys.

   # ikecert certlocal -ks|-kc -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]

   -ks

   Crée un certificat autosigné.

   -kc

   Crée une demande de certificat. Pour plus d'informations sur cette procédure, reportez-vous à la section Configuration du protocole IKE avec des certificats signés par une AC.

   -m taille de clé

   Taille de la clé. La taille de clé peut être 512, 1 024, 2 048, 3 072 ou 4 096.

   -t type de clé

   Spécifie le type d'algorithme à utiliser. Le type de clé peut être rsa-sha1, rsa-md5 ou dsa-sha1.

   -D nom distinctif

   Nom distinctif X.509 de l'objet du certificat. Le nom distinctif se présente de la manière suivante : C=pays, O=organisation, OU=unité d'organisation, CN=nom commun. Les balises valides sont C, O, OU et CN.

   -A nom alternatif

   Nom alternatif du certificat. Le nom alternatif se présente de la manière suivante : tag=value. Les balises valides sont IP, DNS, email et DN.

   -S, début de validité

   Indique la date de début de validité absolue ou relative du certificat.

   -F, fin de validité

   Indique la date de fin de validité absolue ou relative du certificat.

   -T ID de jeton

   Permet à un jeton matériel PKCS #11 de générer les clés. Les certificats sont alors stockés sur le matériel.

   1. Exécutée par exemple sur le système partym, la commande se présente comme suit :

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ -A IP=192.168.13.213 Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/0. Enabling external key providers - done. Acquiring private keys for signing - done. Certificate: Proceeding with the signing operation. Certificate generated successfully (…/publickeys/0) Finished successfully. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. Exécutée sur le système enigma, elle se présente de la manière suivante :

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \ -A IP=192.168.116.16 Creating software private keys. … Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

3. Enregistrez le certificat et envoyez-le au système distant.

   Vous pouvez le coller dans un e-mail.

   1. Transmettez le certificat de partym à l'administrateur de enigma :

      To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. L'administrateur de enigma vous envoie le certificat enigma suivant :

      To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

4. Sur chaque système, ajoutez le certificat que vous avez reçu.

   1. Copiez la clé publique que l'administrateur vous a envoyée par e-mail.

   2. Saisissez la commande ikecert certdb -a et appuyez sur la touche Retour.

      Aucune invite ne s'affiche lorsque vous appuyez sur la touche Retour.

      # ikecert certdb -a Press the Return key

   3. Collez la clé publique, puis appuyez sur la touche Retour. Pour clore l'entrée, appuyez sur Ctrl-D.

      -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D

5. Vérifiez auprès de l'autre administrateur que ce certificat est bien de lui.

   Vous pouvez par exemple lui téléphoner et comparer la valeur de hachage de la clé publique. La valeur de hachage de clé publique du certificat partagé doit être identique pour les deux systèmes.

   1. Répertoriez les certificats stockés sur votre système.

      Par exemple, sur le système partym, le certificat public se trouve à l'emplacement 1 et le certificat privé à l'emplacement 0.

      partym # ikecert certdb -l Certificate Slot Name: 0 Type: rsa-md5 Private Key Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2 Certificate Slot Name: 1 Type: rsa-md5 Public Certificate (Private key in certlocal slot 0) Points to certificate's private key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

   2. Comparez cette valeur avec le hachage de la clé publique sur le système enigma.

      Vous pouvez communiquer la valeur de hachage par téléphone.

      enigma # ikecert certdb -l Certificate Slot Name: 4 Type: rsa-md5 Private Key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0 Certificate Slot Name: 5 Type: rsa-md5 Public Certificate (Private key in certlocal slot 4) Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

6. Approuvez les deux certificats sur chacun des systèmes.

   Éditez le fichier /etc/inet/ike/config pour reconnaître les certificats.

   L'administrateur du système distant fournit la valeur des paramètres cert_trust, remote_addr et remote_id.

   1. Sur le système partym par exemple, le fichier ike/config se présente de la manière suivante :

      # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert # Verified remote address and remote ID # Verified public key hash per telephone call from administrator cert_trust "192.168.13.213" Local system's certificate Subject Alt Name cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 5 { label "US-partym to JA-enigmax" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

   2. Sur le système enigma, ajoutez les valeurs de enigma des paramètres locaux dans le fichier ike/config.

      Pour les paramètres distants, utilisez les valeurs de partym. Assurez-vous que la valeur du mot-clé label est unique. Elle doit différer de la valeur label du système distant.

      … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

Exemple 23–4 Vérification de la validité du certificat d'un autre administrateur

Dans cet exemple, les administrateurs vérifient la concordance des certificats à l'aide de l'attribut Subject Name.

Le premier administrateur enregistre la sortie de la génération et du listage du certificat dans un fichier. La sortie de la commande ikecert s'imprimant en erreur standard, l'administrateur redirige l'erreur standard vers le fichier.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

L'administrateur vérifie le contenu du fichier.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Ensuite, l'administrateur envoie le fichier par courrier électronique au deuxième administrateur.

Celui-ci place le fichier dans un répertoire sécurisé, puis importe le certificat à partir du fichier.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

La commande ikecert importe uniquement le texte entre les lignes -----BEGIN et -----END. L'administrateur vérifie que le certificat local possède une clé de hachage publique identique à celle du fichier co2sys.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Le deuxième administrateur s'assure par téléphone que le premier administrateur a bien envoyé ce message électronique et vérifie l'attribut Subject Name du certificat.

Exemple 23–5 Spécification de dates de début et de fin de validité de certificat.

Dans cet exemple, l'administrateur du système partym définit la période de validité du certificat. Le certificat est antidaté de 2,5 jours et sa période de validité est de 4 ans et 6 mois à compter de la date de création.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

L'administrateur du système enigma définit la période de validité du certificat. Le certificat est antidaté de 2 jours et sa période de validité s'étend jusqu'au 31 décembre 2010, minuit.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

Configuration du protocole IKE avec des certificats signés par une AC

Les certificats publics émanant d'autorités de certification (AC) requièrent une négociation avec une organisation externe. Ces certificats s'intègrent très facilement dans les environnements à grande échelle afin protéger un grand nombre de systèmes communicants.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. La commande ikecert certlocal -kc permet de créer une demande de certificat.

   Pour consulter la description des arguments de cette commande, reportez-vous à l'Étape 2 de la section Configuration du protocole IKE avec des certificats de clés publiques autosignés.

   # ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname

   1. La commande suivante permet par exemple de créer une demande de certificats sur le système partym :

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \ > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym" Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/2. Enabling external key providers - done. Certificate Request: Proceeding with the signing operation. Certificate request generated successfully (…/publickeys/0) Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----

   2. La commande suivante permet de créer une demande de certificat sur le système enigma :

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \ > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax" Creating software private keys. … Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … 8qlqdjaStLGfhDOO -----END CERTIFICATE REQUEST-----

3. Soumettez la demande de certificat à un fournisseur de PKI.

   Le fournisseur de PKI vous indiquera la procédure de soumission des demandes de certificat. Dans la plupart des cas, celle-ci s'effectue en remplissant un formulaire directement sur le site Web du fournisseur. Dans ce formulaire, vous devrez notamment indiquer la preuve de la légitimité de votre demande. Il suffit généralement de coller votre certificat dans le formulaire. Après avoir vérifié votre demande, le fournisseur émet les deux objets de certificats suivants et une liste des certificats révoqués :

   • Votre certificat de clé publique – Ce certificat est basé sur la demande que vous avez envoyée au fournisseur. Cette demande est intégrée au certificat, qui vous identifie de manière unique.

   • Un certificat AC – La signature du fournisseur. L'AC vérifie que votre certificat de clé publique est légitime.

   • Une liste de révocation de certificats (LRC) – La liste la plus récente des certificats révoqués par le fournisseur. Cette liste n'est pas expédiée sous la forme d'un objet de certificat séparé si l'accès à la LRC est intégré au certificat de clé publique.

     Si un URI de LRC est intégré au certificat de clé publique, IKE peut récupérer automatiquement la LRC. De la même façon, si une entrée de DN (nom de répertoire sur un serveur LDAP) est intégrée au certificat de clé publique, IKE peut récupérer la LRC sur un serveur LDAP que vous avez spécifié et la mettre en cache.

     Pour consulter un exemple d'URI et d'entrée de DN intégrés à un certificat de clé publique, reportez-vous à la section Traitement des listes de révocation de certificats.

4. Ajoutez tous les certificats sur votre système.

   L'option -a de la commande ikecert certdb -a ajoute l'objet collé à la base de données de certificats correspondante de votre système. Pour plus d'informations, reportez-vous à la section IKE avec certificats de clés publiques.

   1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   2. Ajoutez le certificat de clé publique que vous avez reçu du fournisseur de PKI.

      # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   3. Ajoutez le certificat AC émanant du fournisseur de PKI.

      # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   4. Si le fournisseur de PKI vous a envoyé une liste de révocation de certificats, ajoutez-la à la base de données certrldb :

      # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

5. Le mot-clé cert_root permet d'identifier le fournisseur de PKI dans le fichier /etc/inet/ike/config.

   Utilisez le nom que le fournisseur de PKI vous a indiqué.

   1. Sur le système partym, par exemple, le fichier ike/config peut se présenter de la manière suivante :

      # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des } p2_pfs 2 { label "US-partym to JA-enigmax - Example PKI" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

      ---

      Remarque –

      Tous les arguments du paramètre auth_method doivent se trouver sur la même ligne.

      ---

   2. Créez un fichier similaire sur le système enigma.

      Le fichier enigma ike/config doit :

      • inclure la même valeur cert_root ;

      • utiliser les valeurs de enigma pour les paramètres locaux ;

      • utiliser les valeurs de partym pour les paramètres distants ;

      • créer une valeur unique pour le mot-clé label. Elle doit différer de la valeur label du système distant.

      … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

6. Spécifiez le mode de traitement des LRC par le protocole IKE.

   Choisissez l'option appropriée :

   • Pas de LRC disponible

     Si le fournisseur de PKI ne fournit pas de LRC, ajoutez le mot-clé ignore_crls au fichier ike/config.

     # Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …

     Le mot-clé ignore_crls indique au protocole IKE de ne pas chercher de LRC.

   • LRC disponible

     Si le fournisseur de PKI vous communique un point de distribution central pour les LRC, vous pouvez modifier le fichier ike/config de manière à ce qu'il pointe sur cet emplacement.

     Pour consulter des exemples de ce type de configuration, reportez-vous à la section Traitement des listes de révocation de certificats.

Exemple 23–6 Utilisation de rsa_encrypt lors de la configuration du protocole IKE

Lorsque vous utilisez auth_method rsa_encrypt dans le fichier ike/config, vous devez ajouter le certificat homologue à la base de données publickeys.

1. Envoyez ce certificat à l'administrateur du système distant.

   Vous pouvez le coller dans un e-mail.

   L'administrateur de partym envoie le message suivant :

   To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----

   L'administrateur de enigma envoie l'e-mail suivant :

   To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----

2. Sur chacun des systèmes, ajoutez à la base de données publickeys locale le certificat envoyé par e-mail.

   # ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D

En cachant les identités à l'aide du protocole IKE, la méthode d'authentification utilisée en chiffrement RSA prévient les risques d'écoute électronique. Étant donné que la méthode rsa_encrypt cache l'identité de l'homologue, le protocole IKE ne peut récupérer son certificat. La méthode rsa_encrypt requiert donc que les homologues IKE connaissent leurs clés publiques respectives.

C'est pourquoi vous devez ajouter le certificat de l'homologue à la base de données publickeys lorsque vous utilisez la méthode auth_method de rsa_encrypt dans le fichier /etc/inet/ike/config. La base de données publickeys détient alors trois certificats pour chaque couple de systèmes communicants :

• votre certificat de clé publique ;

• le certificat AC ;

• le certificat de clé publique de l'homologue.

Dépannage – La charge du protocole IKE, qui inclut les trois certificats, peut s'avérer trop importante pour le chiffrement via rsa_encrypt. L'apparition d'erreurs indiquant que l'autorisation a échoué ou que la charge n'est pas conforme peut signifier que la méthode rsa_encrypt est incapable de chiffrer la totalité de la charge. Pour réduire la charge, utilisez une autre méthode (par exemple, rsa_sig, qui ne requiert que deux certificats).

Génération et stockage de certificats de clés publiques sur le matériel

Le processus de génération et de stockage de certificats de clés publiques sur du matériel est similaire au processus de génération et de stockage de certificats de clés publiques sur un système. Dans le premier cas, il convient d'identifier le matériel à l'aide des commandes ikecert certlocal et ikecert certdb, accompagnées de l'option -T et de l'ID de jeton.

Avant de commencer

• Le matériel doit être configuré.

• Excepté si le mot-clé pkcs11_path du fichier /etc/inet/ike/config pointe sur une autre bibliothèque, le matériel utilise /usr/lib/libpkcs11.so. Cette bibliothèque doit être implémentée conformément aux standards suivants : RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), c'est-à-dire une bibliothèque PKCS #11.

  Pour consulter les instructions de paramétrage, reportez-vous à la section Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000 .

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Générez un certificat autosigné ou une demande de certificat et spécifiez l'ID de jeton.

   Procédez de l'une des manières suivantes :

   ---

   Remarque –

   Pour RSA, la carte Sun Crypto Accelerator 4000 prend en charge des clés d'une longueur maximum de 2 048 bits. Pour DSA, la longueur maximum des clés est de 1 024 bits.

   ---

   • Pour un certificat autosigné, utilisez la syntaxe suivante :

     # ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

     L'argument de l'option -T est l'ID de jeton de la carte Sun Crypto Accelerator 4000 connectée.

   • Pour une demande de certificat, utilisez la syntaxe suivante :

     # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

   Pour obtenir une description des arguments de la commande ikecert, reportez-vous à la page de manuel ikecert(1M).

3. Lorsque l'invite demandant le PIN s'affiche, entrez le nom de l'utilisateur de la carte Sun Crypto Accelerator 4000 suivi de deux points et du mot de passe de l'utilisateur.

   Si la carte Sun Crypto Accelerator 4000 possède un utilisateur ikemgr dont le mot de passe est rgm4tigt, entrez :

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

   ---

   Remarque –

   La réponse est stockée en texte en clair sur le disque.

   ---

   Après entrée du mot de passe, le certificat s'imprime :

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----

4. Envoyez votre certificat aux personnes concernées.

   Procédez de l'une des manières suivantes :

   • Envoyez le certificat autosigné au système distant.

     Vous pouvez le coller dans un e-mail.

   • Envoyez la demande de certificat à un fournisseur de PKI.

     Pour ce faire, suivez les instructions du fournisseur de PKI. Pour plus d'informations, reportez-vous à l'Étape 3 de la section Configuration du protocole IKE avec des certificats signés par une AC.

5. Éditez le fichier /etc/inet/ike/config sur votre système pour reconnaître les certificats.

   Procédez de l'une des manières suivantes :

   • Certificat autosigné

     Utilisez les valeurs fournies par l'administrateur du système distant pour les paramètres cert_trust, remote_id et remote_addr. Sur le système enigma par exemple, le fichier ike/config se présente comme suit :

     # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.116.16" Local system's certificate Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

   • Demande de certificat

     Entrez le nom que le fournisseur de PKI vous a communiqué comme valeur du mot-clé cert_root. Sur le système enigma par exemple, le fichier ike/config peut se présenter comme suit :

     # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

6. Placez les certificats de l'autre partie sur le matériel.

   Répondez à la demande de PIN comme lors de l'Étape 3.

   ---

   Remarque –

   Vous devez ajouter les certificats de clés publiques au matériel connecté qui a généré votre clé privée.

   ---

   • Certificat autosigné.

     Ajoutez le certificat autosigné du système distant. Dans cet exemple, il est stocké dans le fichier DCA.ACCEL.STOR.CERT.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     Si le certificat autosigné a utilisé rsa_encrypt comme valeur du paramètre auth_method, ajoutez le certificat de l'homologue au magasin du matériel.

   • Certificats émanant d'un fournisseur de PKI.

     Ajoutez le certificat généré par le fournisseur suite à votre demande et ajoutez l'AC.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password

     Pour ajouter une liste de révocation de certificats (LRC) communiquée par un fournisseur de PKI, reportez-vous à la section Traitement des listes de révocation de certificats.

Traitement des listes de révocation de certificats

Les listes de révocation de certificats (LRC) sont émises par une AC et contiennent les certificats périmés ou compromis. Vous pouvez traiter les LRC de quatre façons :

• Vous devez faire en sorte que le protocole IKE ignore les listes de révocation de certificats si votre AC n'en émet pas. Pour plus d'informations, reportez-vous à l'Étape 6 de la section Configuration du protocole IKE avec des certificats signés par une AC.

• Vous pouvez faire en sorte que le protocole IKE accède aux LRC à partir d'un URI (uniform resource indicator, identificateur universel de ressources) dont l'adresse est intégrée au certificat de clé publique de l'AC.

• Vous pouvez faire en sorte que le protocole IKE accède aux LRC à partir d'un serveur LDAP dont l'entrée de nom de répertoire (DN, directory name) est intégrée au certificat de clé publique de l'AC.

• Vous pouvez traiter les LRC comme des arguments de la commande ikecert certrldb. Voir l'Exemple 23–7.

La section ci-dessous décrit la procédure permettant de paramétrer l'utilisation des LRC à partir d'un point de distribution central dans le protocole IKE.

1. Affichez le certificat que vous avez reçu de l'AC.

   # ikecert certdb -lv certspec

   -l

   Liste les certificats dans la base de données de certificats IKE.

   -v

   Liste les certificats en mode détaillé. Utilisez cette option avec précaution.

   spécification de certificat

   Modèle permettant de rechercher les certificats correspondants dans la base de données de certificats IKE.

   Par exemple, le certificat ci-dessous a été émis par Sun Microsystems (les détails ont été modifiés).

   # ikecert certdb -lv example-protect.sun.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com> Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> SerialNumber: 14000D93 Validity: Not Valid Before: 2002 Jul 19th, 21:11:11 GMT Not Valid After: 2005 Jul 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.sun.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.sun.com/pki/pkismica.crl#i DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access

   Notez l'entrée CRL Distribution Points. L'entrée URI indique que la LRC de cette organisation est disponible sur le Web. L'entrée DN indique que la LRC est disponible sur un serveur LDAP. Après que le protocole IKE a accédé à la LRC, celle-ci est mise en cache en vue de futures utilisations.

   Pour accéder à la LRC, vous devez tout d'abord accéder à un point de distribution.

2. Choisissez l'une des méthodes suivantes pour accéder à la LRC depuis un point de distribution central.

   • Utilisez l'URI.

     Ajoutez le mot-clé use_http au fichier /etc/inet/ike/config de l'hôte. Le fichier ike/config se présente comme suit :

     # Use CRL from organization's URI use_http …

   • Utilisez un proxy Web.

     Ajoutez le mot-clé proxy au fichier ike/config. Le mot-clé proxy adopte un URL comme argument, comme indiqué ci-dessous :

     # Use own web proxy proxy "http://proxy1:8080"

   • Utilisez un serveur LDAP.

     Utilisez le nom du serveur LDAP comme argument du mot-clé ldap-list dans le fichier /etc/inet/ike/config de l'hôte. Le nom du serveur LDAP est fourni par votre organisation. L'entrée dans le fichier ike/config se présente comme suit :

     # Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …

   Le protocole IKE récupère la LRC et la met en cache jusqu'à ce que le certificat expire.

Exemple 23–7 Ajout d'une LRC à la base de données certrldb locale

Si la LRC du fournisseur de PKI n'est pas disponible à partir d'un point de distribution central, vous pouvez ajouter cette liste manuellement à la base de données certrldb locale. Pour extraire la LRC dans un fichier, suivez les instructions du fournisseur de PKI, puis ajoutez la LRC à la base de données à l'aide de la commande ikecert certrldb -a.

# ikecert certrldb -a < Sun.Cert.CRL

Configuration du protocole IKE pour les systèmes portables (liste des tâches)

Le tableau ci-dessous décrit les procédures permettant de configurer le protocole IKE pour gérer des systèmes qui se connectent à distance à un site central.

Configuration du protocole IKE pour les systèmes portables

Lorsqu'ils sont configurés correctement, les ordinateurs portables peuvent communiquer avec les ordinateurs centraux de l'entreprise via IPsec et IKE. L'utilisation combinée d'une stratégie IPsec globale et d'une méthode d'authentification de clé publique permet de protéger le trafic des systèmes hors site avec le système central.

Configuration du protocole IKE pour les systèmes hors site

Les protocoles IPsec et IKE requièrent un ID unique pour identifier la source et la destination. Pour les systèmes portables hors site ne possédant pas d'adresse IP unique, vous devez utiliser un autre type d'ID permettant d'identifier un système de manière unique (par exemple, DNS, DN ou email).

Il est toujours préférable de configurer les systèmes portables ou hors site possédant une adresse IP unique avec un autre type d'ID. Par exemple, si ces systèmes tentent de se connecter à un site central par l'intermédiaire d'un boîtier NAT, leur adresse unique n'est pas utilisée. Le boîtier NAT leur assigne une adresse IP arbitraire que le système central ne reconnaît pas.

Les clés prépartagées ne sont pas, elles non plus, un moyen d'authentification approprié pour les systèmes portables, car elles requièrent une adresse IP fixe. Les certificats autosignés ou les certificats PKI permettent par contre aux systèmes portables de communiquer avec le site central.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Configurez le système central de manière à ce qu'il reconnaisse les systèmes portables.

   1. Paramétrez le fichier /etc/hosts.

      Il n'est pas nécessaire que le système central reconnaisse des adresses spécifiques de systèmes portables.

      # /etc/hosts on central central 192.xxx.xxx.x

   2. Paramétrez le fichier ipsecinit.conf.

      Le système central nécessite une stratégie autorisant une plage étendue d'adresses IP. Les certificats de la stratégie IKE garantissent ultérieurement la légitimité des systèmes connectés.

      # /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Paramétrez le fichier ike.config.

      Le DNS identifie le système central et les certificats permettent d'authentifier le système.

      ## /etc/inet/ike/ike.config on central # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # List self-signed certificates - trust server and enumerated others #cert_trust "DNS=central.domain.org" #cert_trust "DNS=mobile.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=root@central.domain.org" #cert_trust "email=user1@mobile.domain.org" # # Rule for mobile systems with certificate { label "Mobile systems with certificate" local_id_type DNS # Any mobile system who knows my DNS or IP can find me. local_id "central.domain.org" local_addr 192.xxx.xxx.x # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

3. Connectez-vous à chacun des systèmes portables et configurez-les de manière à ce qu'ils trouvent le système central.

   1. Paramétrez le fichier /etc/hosts.

      Le fichier /etc/hosts n'a pas besoin d'une adresse pour le système portable, mais peut en fournir une. Il doit contenir une adresse IP publique pour le système central.

      # /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x

   2. Paramétrez le fichier ipsecinit.conf.

      Le système portable doit être capable de trouver le système central à partir de son adresse IP publique. Les deux systèmes doivent avoir la même stratégie IPsec.

      # /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Paramétrez le fichier ike.config.

      L'identificateur ne peut pas être une adresse IP. Pour les systèmes portables, les identificateurs valides sont les suivants :

      • DN=nom-répertoire-ldap

      • DNS=adresse-DNS

      • email=adresse-e-mail

      Les certificats permettent d'authentifier le système portable.

      ## /etc/inet/ike/ike.config on mobile # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # Self-signed certificates - trust me and enumerated others #cert_trust "DNS=mobile.domain.org" #cert_trust "DNS=central.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=user1@domain.org" #cert_trust "email=root@central.domain.org" # # Rule for off-site systems with root certificate { label "Off-site mobile with certificate" local_id_type DNS # NAT-T can translate local_addr into any public IP address # central knows me by my DNS local_id "mobile.domain.org" local_addr 0.0.0.0/0 # Find central and trust the root certificate remote_id "central.domain.org" remote_addr 192.xxx.xxx.x p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

4. Lisez la configuration IKE dans le noyau.

   • À partir de la version Solaris 10 4/09, activez le service ike.

     # svcadm enable svc:/network/ipsec/ike

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, réinitialisez le système.

     # init 6

     Vous pouvez également arrêter et relancer le démon in.iked.

Exemple 23–8 Configuration d'un ordinateur central pour qu'il accepte le trafic IPsec d'un système portable

Le protocole IKE peut commencer les négociations derrière un boîtier NAT, mais il est préférable de ne pas faire intervenir de boîtier de ce type. Dans l'exemple ci-dessous, les certificats racine ont été émis par une AC. Ils ont été placés sur les deux systèmes (un système portable et un système central). Le système central accepte les négociations IPsec émanant d'un système situé derrière un boîtier NAT. main1 est le système acceptant les connexions de systèmes hors site. Pour paramétrer les systèmes hors site, reportez-vous à l'Exemple 23–9.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}

Exemple 23–9 Configuration d'un système situé derrière un boîtier NAT avec IPsec

Dans l'exemple ci-dessous, les certificats racine ont été émis par une AC et placés sur le système portable et sur le système central. mobile1 se connecte au siège de l'entreprise depuis un domicile privé. Le réseau du FAI (fournisseur d'accès Internet) utilise un boîtier NAT pour pouvoir assigner une adresse privée à mobile1. Le boîtier NAT convertit l'adresse privée en une adresse IP publique partagée par d'autres nœuds du réseau du FAI. Le siège de l'entreprise ne se trouve pas derrière un boîtier NAT. Pour paramétrer l'ordinateur du siège de l'entreprise, reportez-vous à l'Exemple 23–8.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Exemple 23–10 Acceptation de certificats autosignés émanant d'un système portable

Dans l'exemple ci-dessous, les certificats autosignés ont été émis par le système portable et le système central, et ont été placés sur les deux systèmes. main1 est le système acceptant les connexions de systèmes hors site. Pour paramétrer les systèmes hors site, reportez-vous à l'Exemple 23–11.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Exemple 23–11 Utilisation de certificats autosignés pour contacter un système central

Dans l'exemple ci-dessous, mobile1 se connecte au siège de l'entreprise depuis un domicile privé. Les certificats ont été émis par le système portable et le système central, et ont été placés sur les deux systèmes. Le réseau du FAI utilise un boîtier NAT pour assigner une adresse privée à mobile1. Le boîtier NAT convertit l'adresse privée en une adresse IP publique partagée par d'autres nœuds du réseau du FAI. Le siège de l'entreprise ne se trouve pas derrière un boîtier NAT. Pour paramétrer l'ordinateur du siège de l'entreprise, reportez-vous à l'Exemple 23–10.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Configuration du protocole IKE en vue de l'utilisation du matériel connecté (liste des tâches)

Le tableau ci-dessous répertorie les procédures permettant de signaler au protocole IKE la connexion des composants matériels. Pour que le protocole IKE puisse utiliser un composant matériel connecté, vous devez préalablement l'informer de l'existence de ce composant. Pour utiliser le composant matériel, suivez les procédures décrites à la section Configuration du protocole IKE avec des certificats de clés publiques.

Vous n'avez pas besoin de renseigner l'IKE sur le matériel sur puce. Par exemple, le processeur UltraSPARC® T2 offre l'accélération cryptographique. Vous n'avez pas besoin de configurer IKE pour qu'il recherche les accélérateurs sur puce.

Configuration du protocole IKE en vue de l'utilisation du matériel connecté

Les certificats des clés publiques peuvent également être stockés sur un matériel connecté. La carte Sun Crypto Accelerator 1000 est destinée uniquement au stockage. Les cartes Sun Crypto Accelerator 4000 et Sun Crypto Accelerator 6000 permettent le stockage, ainsi que le déchargement d'opérations de clés publiques du système vers la carte.

Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 1000

Avant de commencer

La procédure ci-dessous suppose que la carte Sun Crypto Accelerator 1000 est connectée au système et que le ou les logiciels correspondants ont été installés et configurés. Pour obtenir des instructions, reportez-vous au Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Assurez-vous que la bibliothèque PKCS #11 est liée.

   Entrez la commande suivante pour déterminer si la bibliothèque PKCS #11 est liée :

   # ikeadm get stats Phase 1 SA counts: Current: initiator: 0 responder: 0 Total: initiator: 0 responder: 0 Attempted: initiator: 0 responder: 0 Failed: initiator: 0 responder: 0 initiator fails include 0 time-out(s) PKCS#11 library linked in from /usr/lib/libpkcs11.so #

3. Solaris10 1/06 : à partir de cette version, vous pouvez stocker des clés dans le fichier keystore de clés softtoken.

   Pour plus d'informations sur le keystore fourni par la structure cryptographique de Solaris, reportez-vous à la page de manuel cryptoadm(1M). Pour plus d'informations sur l'utilisation du keystore, reportez-vous à l'Example 23–12.

Configuration du protocole IKE en vue de l'utilisation d'une carte Sun Crypto Accelerator 4000

Avant de commencer

La procédure ci-dessous suppose que la carte Sun Crypto Accelerator 4000 est connectée au système et que le ou les logiciels correspondants ont été installés et configurés. Pour obtenir des instructions, reportez-vous au Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

Si vous utilisez une carte Sun Crypto Accelerator 6000, reportez-vous au Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide.

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Assurez-vous que la bibliothèque PKCS #11 est liée.

   IKE utilise les routines de la bibliothèque pour gérer la génération des clés et leur stockage sur la carte Sun Crypto Accelerator 4000. Entrez la commande suivante pour déterminer si une bibliothèque PKCS #11 a été liée :

   $ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $

   ---

   Remarque –

   Pour RSA, la carte Sun Crypto Accelerator 4000 prend en charge des clés d'une longueur maximum de 2 048 bits. Pour DSA, la longueur maximum des clés est de 1 024 bits.

   ---

3. Déterminez l'ID de jeton de la carte Sun Crypto Accelerator 4000.

   $ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot "

   La bibliothèque renvoie un ID de jeton, également appelé nom du keystore, de 32 caractères. Dans l'exemple ci-dessous, vous pouvez utiliser le jeton Sun Metaslot avec la commande ikecert pour stocker et accélérer les clés IKE.

   Pour plus d'informations sur l'utilisation du jeton, reportez-vous à la section Génération et stockage de certificats de clés publiques sur le matériel.

   Les espaces situés à la fin sont automatiquement remplis par la commande ikecert.

Exemple 23–12 Découverte et utilisation de jetons metaslot

Les jetons peuvent être stockés sur un disque, sur une carte connectée ou dans le fichier keystore de clés softtoken fourni par la structure de chiffrement de Solaris. L'ID de jeton du keystore de softtoken peut se présenter comme suit :

$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

Pour créer une phrase de passe pour un keystore de softtoken, reportez-vous à la page de manuel pktool(1).

La commande ci-dessous permet d'ajouter un certificat au keystore de softtoken. Sun.Metaslot.cert est le fichier contenant le certificat AC.

# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Modification des paramètres de transmission du protocole IKE (liste des tâches)

Le tableau ci-dessous répertorie les procédures permettant de configurer les paramètres de transmission du protocole IKE.

Modification des paramètres de transmission du protocole IKE

Lorsque le protocole IKE négocie les clés, la vitesse de transmission risque de compromettre la réussite de l'opération. En temps normal, il n'est pas nécessaire de modifier les valeurs par défaut des paramètres de transmission du protocole IKE. Dans certains cas (par exemple, optimisation de la négociation sur des lignes surchargées ou pour la reproduction d'un problème), vous pouvez toutefois juger utile de le faire.

Le fait de prolonger la durée de négociation permet à IKE de négocier les clés sur les lignes de transmission problématiques. Vous pouvez augmenter certains paramètres pour que la négociation réussisse dès la première tentative. Si elle échoue, vous pouvez espacer les tentatives suivantes pour optimiser les chances de succès.

Le fait de réduire la durée de négociation permet d'utiliser des lignes fiables. Vous pouvez relancer plus rapidement toute négociation ayant échoué. La réduction de la durée de négociation permet également d'accélérer le processus de reproduction d'un problème afin d'établir un diagnostic. Elle permet également d'utiliser les associations de sécurité (SA, security associations) de la phase 1 pendant toute leur durée de vie.

Modification de la durée de la phase 1 de la négociation des clés IKE

1. Sur la console du système, connectez-vous en tant qu'administrateur principal ou superutilisateur.

   Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

   ---

   Remarque –

   En vous connectant à distance, vous exposez le trafic de données confidentielles à des risques d'écoute électronique. Même si vous protégez la connexion à distance d'une manière ou d'une autre, la sécurité du système se limite à celle de la session à distance. Utilisez la commande ssh pour une connexion à distance sécurisée.

   ---

2. Modifiez la valeur par défaut des paramètres globaux de transmission sur chacun des systèmes.

   Sur chacun des systèmes, modifiez les paramètres de durée de la phase 1 dans le fichier /etc/inet/ike/config.

   ### ike/config file on system ## Global parameters # ## Phase 1 transform defaults # #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float)

   expire_timer

   Délai de suppression d'une tentative de négociation IKE de phase 1 en attente (en secondes). Par défaut, la tentative reste active pendant 30 secondes.

   retry_limit

   Nombre de retransmissions avant abandon de toute négociation IKE. Par défaut, IKE essaie cinq fois.

   retry_timer_init

   Intervalle initial entre les retransmissions. Cet intervalle est doublé jusqu'à ce que la valeur retry_timer_max soit atteinte. L'intervalle initial est de 0,5 secondes.

   retry_timer_max

   Intervalle maximum (en secondes) entre les retransmissions. L'intervalle de retransmission cesse d'augmenter lorsque cette limite est atteinte. Par défaut, cette limite est de 30 secondes.

3. Lisez la configuration modifiée dans le noyau.

   • À partir de la version Solaris 10 4/09, actualisez le service ike.

     # svcadm refresh svc:/network/ipsec/ike

   • Si vous exécutez une version antérieure à la version Solaris 10 4/09, réinitialisez le système.

     # init 6

     Vous pouvez également arrêter et relancer le démon in.iked.

Exemple 23–13 Augmentation de la durée de négociation de la phase 1 du protocole IKE

Dans l'exemple ci-dessous, un système est connecté à son homologue IKE via une ligne encombrée. Les paramètres d'origine figurent en commentaires dans le fichier. Les nouveaux paramètres augmentent la durée de négociation.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180

Exemple 23–14 Réduction de la durée de négociation de la phase 1 du protocole IKE

Dans l'exemple ci-dessous, un système est connecté à son homologue IKE via une ligne à haut débit peu encombrée. Les paramètres d'origine figurent en commentaires dans le fichier. Les nouveaux paramètres diminuent la durée de négociation.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20