Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PKI dans Junos OS

SUMMARY Cette rubrique décrit les éléments de base de l’infrastructure à clé publique (PKI) dans Junos OS.

Une infrastructure à clé publique (PKI) prend en charge la distribution et l’identification des clés de chiffrement publiques, ce qui permet aux utilisateurs d’échanger des données en toute sécurité sur des réseaux tels qu’Internet et de vérifier l’identité de l’autre partie.

Présentation de la PKI dans Junos OS

Présentation des applications PKI

Junos OS utilise des clés publiques/privées dans les domaines suivants :

  • SSH/SCP (pour une administration sécurisée basée sur l’interface de ligne de commande [CLI])

  • Secure Sockets Layer (SSL) (pour une administration Web sécurisée et pour un webauth basé sur https pour l’authentification des utilisateurs)

  • Internet Key Exchange (IKE) (pour les tunnels VPN IPsec)

REMARQUE :

Notez les points suivants :

  • Actuellement, Junos OS prend uniquement en charge IKE (en utilisant des certificats d’infrastructure à clé publique (PKI) pour la validation des clés publiques).

  • Le SSH et le SCP sont utilisés exclusivement pour l’administration du système et dépendent de l’utilisation d’empreintes digitales hors bande pour la liaison et la validation de l’identité de clé publique. Les détails sur SSH ne sont pas abordés dans cette rubrique.

Composants pour l’administration de PKI dans Junos OS

Les composants suivants sont requis pour administrer PKI dans Junos OS :

  • Certificats d’autorité de certification et configuration des autorités

  • Certificats locaux incluant l’identité de l’appareil (exemple : type et valeur de l’ID IKE) et les clés privées et publiques

  • Validation des certificats par le biais d’une liste de révocation de certificats (CRL)

Éléments de base de la PKI dans Junos OS

Junos OS prend en charge trois types spécifiques d’objets PKI :

  • Paire de clés privée/publique

  • Certificats

    • Certificat local : le certificat local contient la clé publique et les informations d’identité du périphérique Juniper Networks. L’équipement Juniper Networks possède la clé privée associée. Ce certificat est généré à partir d’une demande de certificat provenant de l’équipement Juniper Networks.

    • Certificat en attente : un certificat en attente contient une paire de clés et des informations d’identité qui sont générées dans une demande de certificat PKCS10 et envoyées manuellement à une autorité de certification (CA). Pendant que l’équipement Juniper Networks attend le certificat de l’autorité de certification, l’objet existant (paire de clés et demande de certificat) est marqué comme demande de certificat ou certificat en attente.

      REMARQUE :

      Junos OS version 9.0 et ultérieures prend en charge l’envoi automatique de demandes de certificat via SCEP.

    • Certificat d’autorité de certification : lorsque le certificat est émis par l’autorité de certification et chargé dans le périphérique Junos OS, le certificat en attente est remplacé par le certificat local nouvellement généré. Tous les autres certificats chargés dans l’appareil sont considérés comme des certificats d’autorité de certification.

  • Listes de révocation de certificats (CRL)

Notez les points suivants concernant les certificats :

  • Les certificats locaux sont généralement utilisés lorsqu’un périphérique Junos OS possède des VPN dans plusieurs domaines administratifs.

  • Tous les objets PKI sont stockés dans une partition distincte de mémoire persistante, à l’exception de l’image Junos OS et de la configuration générale du système.

  • Chaque objet PKI a un nom unique ou un ID de certificat qui lui est attribué lors de sa création et conserve cet ID jusqu’à sa suppression. Vous pouvez afficher l’ID de certificat à l’aide de la show security pki local-certificate commande.

  • Dans la plupart des cas, un certificat ne peut pas être copié à partir d’un appareil. La clé privée d’un appareil doit être générée uniquement sur cet appareil, et elle ne doit jamais être affichée ou enregistrée à partir de cet appareil. Par conséquent, les fichiers PKCS12 (qui contiennent un certificat avec la clé publique et la clé privée associée) ne sont pas pris en charge sur les équipements Junos OS.

  • Les certificats d’autorité de certification valident les certificats reçus par l’homologue IKE. Si le certificat est valide, il est vérifié dans la CRL pour voir s’il a été révoqué.

    Chaque certificat d’autorité de certification inclut une configuration de profil d’autorité de certification qui stocke les informations suivantes :

    • l’identité de l’autorité de certification, qui est généralement le nom de domaine de l’autorité de certification

    • Adresse e-mail pour l’envoi des demandes de certificat directement à l’autorité de certification

    • Paramètres de révocation :

      • Option d’activation/désactivation de la vérification de la révocation

      • Désactivation de la vérification de la révocation en cas d’échec du téléchargement de la CRL.

      • Emplacement du point de distribution CRL (CDP) (pour la configuration manuelle de l’URL)

      • Intervalle d’actualisation de la liste de révocation de certificats

Composants PKI dans Junos OS

Cette rubrique comprend les sections suivantes :

Gestion et mise en uvre d’une PKI

Les éléments PKI minimaux requis pour l’authentification basée sur les certificats dans Junos OS sont les suivants :

  • Certificats d’autorité de certification et configuration des autorités.

  • Certificats locaux incluant l’identité de l’appareil (exemple : type et valeur de l’ID IKE) et les clés privées et publiques

  • Validation du certificat par le biais d’une CRL.

Junos OS prend en charge trois types différents d’objets PKI :

Internet Key Exchange

La procédure de signature numérique des messages envoyés entre deux participants à une session IKE (Internet Key Exchange) est similaire à la vérification de certificat numérique, avec les différences suivantes :

  • Au lieu d’effectuer un résumé à partir du certificat de l’autorité de certification, l’expéditeur le fait à partir des données de la charge utile du paquet IP.

  • Au lieu d’utiliser la paire de clés publique-privée de l’autorité de certification, les participants utilisent la paire de clés publique-privée de l’expéditeur.

Groupe d’autorités de certification de confiance

Une autorité de certification (CA) est un tiers de confiance responsable de l’émission et de la révocation des certificats. Vous pouvez regrouper plusieurs autorités de certification (profils d’autorités de certification) dans un groupe d’autorités de certification de confiance pour une topologie donnée. Ces certificats permettent d’établir une connexion entre deux points de terminaison. Pour établir IKE ou IPsec, les deux points de terminaison doivent faire confiance à la même autorité de certification. Si l’un des points de terminaison n’est pas en mesure de valider le certificat à l’aide de son autorité de certification approuvée (profil ca) ou de son groupe d’autorités de certification approuvées respectifs, la connexion n’est pas établie.

Par exemple, il y a deux points de terminaison, le point de terminaison A et le point de terminaison B qui tentent d’établir une connexion sécurisée. Lorsque le point de terminaison B présente son certificat au point de terminaison A, le point de terminaison A vérifie si le certificat est valide. L’autorité de certification du point de terminaison A vérifie le certificat signé que le point de terminaison B utilise pour obtenir l’autorisation. Lorsque trusted-ca ou est configuré, l’appareil n’utilisera que les profils d’autorité de certification ajoutés dans celui-ci trusted-ca-group ou trusted-ca-group le profil d’autorité de certification configuré sous trusted-ca pour valider le certificat provenant du point de terminaison B. Si la validité du certificat est vérifiée, la connexion est autorisée, sinon elle est rejetée.

Avantages:

  • Pour toute demande de connexion entrante, seul le certificat émis par l’autorité de certification approuvée de ce point de terminaison est validé. Si ce n’est pas le cas, l’autorisation rejettera l’établissement de la connexion.

Présentation de la gestion des clés cryptographiques

Grâce à la gestion des clés cryptographiques, les clés persistantes sont stockées dans la mémoire de l’appareil sans aucune tentative de les modifier. Bien que le périphérique de mémoire interne ne soit pas directement accessible à un adversaire potentiel, ceux qui ont besoin d’une deuxième couche de défense peuvent activer un traitement spécial pour les clés cryptographiques. Lorsqu’elle est activée, la gestion des clés cryptographiques chiffre les clés lorsqu’elles ne sont pas immédiatement utilisées, effectue une détection d’erreur lors de la copie d’une clé d’un emplacement mémoire à un autre et écrase l’emplacement mémoire d’une clé avec un modèle de bits aléatoire lorsque la clé n’est plus utilisée. Les clés sont également protégées lorsqu’elles sont stockées dans la mémoire flash de l’appareil. L’activation de la fonctionnalité de gestion des clés cryptographiques n’entraîne aucun changement observable de l’extérieur dans le comportement de l’appareil, et l’appareil continue d’interagir avec les autres appareils.

Un administrateur cryptographique peut activer et désactiver les fonctions d’autotest cryptographique ; Toutefois, l’administrateur de sécurité peut modifier le comportement des fonctions d’autotest cryptographique, par exemple en configurant des autotests périodiques ou en sélectionnant un sous-ensemble d’autotests cryptographiques.

Les clés persistantes suivantes sont actuellement gérées par IKE et PKI :

  • Clés IKE prépartagées (PSK IKE)

  • Clés privées PKI

  • Clés VPN manuelles