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) de 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.

Introduction à 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 basée sur l’interface de ligne de commande sécurisée [CLI])

  • Ssl (Secure Sockets Layer) (pour une administration Web sécurisée et pour l’authentification utilisateur via https)

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

Remarque :

Notez les points suivants :

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

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

Composants pour l’administration des PKI dans Junos OS

Les composants suivants sont requis pour l’administration de PKI dans Junos OS :

  • Configuration des certificats et des autorités de certification

  • Certificats locaux comprenant l’identité des équipements (par exemple : Type et valeur IKE ID) et clés privées et publiques

  • Validation de certificat via une liste de révocation de certificats (CRL)

Éléments de base de PKI dans Junos OS

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

  • Paire de clés privées/publiques

  • Certificats

    • Certificat local : le certificat local contient la clé publique et les informations d’identité de l’équipement Juniper Networks. L’équipement Juniper Networks est propriétaire de la clé privée associée. Ce certificat est généré à partir d’une demande de certificat émanant de l’équipement Juniper Networks.

    • Certificat en attente : un certificat en instance contient une paire de clés et des informations d’identité générées dans une requête de certificat PKCS10 et envoyées manuellement à une autorité de certification.« Alors que l’équipement Juniper Networks attend le certificat de l’autorité de certification, l’objet existant (paire de clés et la requête de certificat) est balisé comme une demande de certificat ou un certificat en attente.

      Remarque :

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

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

  • Listes d’annulation des certificats (CRL)

Notez les points suivants concernant les certificats :

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

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

  • Chaque objet PKI a un nom ou un ID de certificat unique 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 équipement. La clé privée d’un équipement doit être générée uniquement sur cet équipement et ne doit jamais être consultée ou enregistrée à partir de cet équipement. Les fichiers PKCS12 (qui contiennent un certificat avec la clé publique et la clé privée associée) ne sont donc pas pris en charge sur les équipements Junos OS.

  • Les certificats d’autorité de certification valident les certificats reçus par l’pair IKE. Si le certificat est valide, il est vérifié dans le CRL pour savoir si le certificat 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 électronique pour envoyer les demandes de certificat directement à l’autorité de certification

    • Paramètres d’annulation :

      • Option d’activation/désactivation de la vérification de l’invalidation

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

      • Emplacement du point de distribution CRL (CDP) (pour la définition manuelle des URL)

      • Intervalle d’actualisation CRL

Composants PKI dans Junos OS

Cette rubrique comprend les sections suivantes :

Gestion et implémentation PKI

Les éléments PKI minimum requis pour l’authentification basée sur un certificat dans Junos OS sont les suivants :

  • Configuration des certificats et des autorités de certification.

  • Certificats locaux comprenant l’identité de l’équipement (par exemple : Type et valeur IKE ID) et clés privées et publiques

  • Validation de certificat via une CRL.

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

Internet Key Exchange

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

  • Au lieu de procéder à un digeste à partir du certificat d’autorité de certification, l’expéditeur le transmet à partir des données de la charge utile de paquet IP.

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

Groupe d’autorité 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 profils d’autorité de certification (CA) dans un groupe d’autorité de certification fiable pour une topologie donnée. Ces certificats sont utilisés pour établir la connexion entre deux points d’extrémité. Pour établir IKE ou IPsec, les deux points d’extrémité doivent faire confiance au même centre de données. Si l’un des points d’extrémité n’est pas en mesure de valider le certificat à l’aide de son ca-profile respectif ou de son groupe d’autorité de certification approuvé, la connexion n’est pas établie.

Par exemple, deux points d’extrémité, les points A et B, tentent d’établir une connexion sécurisée. Lorsque le point final B présente son certificat au point A, le point final A vérifie si le certificat est valide. L’autorité de certification du point d’extrémité A vérifie le certificat signé que le point de terminaison B utilise pour obtenir une autorisation. Une fois trusted-ca configuré trusted-ca-group , l’équipement utilise uniquement les profils d’autorité de certification ajoutés dans ce trusted-ca-group profil ou le profil d’autorité configuré en dessous trusted-ca pour valider le certificat provenant du point d’extrémité B. Si le certificat est vérifié comme valide, la connexion est autorisée, sinon la connexion est rejetée.

Avantages :

  • Pour toute demande de connexion entrante, seul le certificat émis par l’autorité d’accès approuvée de ce point d’extrémité est validé. Si ce n’est pas le cas, l’autorisation rejette la connexion.

Présentation du traitement des clés cryptographiques

Avec le traitement des clés cryptographiques, les clés persistantes sont stockées dans la mémoire de l’équipement sans aucune tentative de modification. Bien que l’équipement 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 une gestion spéciale des clés cryptographiques. Lorsqu’elle est activée, la clé cryptographique utilisée chiffre les clés lorsqu’elles ne sont pas immédiatement utilisées, effectue une détection des erreurs lors de la copie d’une clé d’un emplacement mémoire à un autre, et remplace l’emplacement de mémoire d’une clé par un modèle de bit 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’équipement. L’activation de la fonctionnalité de gestion des clés cryptographiques ne provoque aucune modification du comportement de l’équipement observable de l’extérieur, et l’équipement continue d’interagir avec les autres équipements.

Un administrateur cryptographique peut activer et désactiver les fonctions d’autotest cryptographique; cependant, l’administrateur sécurité peut modifier le comportement des fonctions d’autotest cryptographique telles que la configuration d’autotests périodiques ou la sélection d’un sous-ensemble d’autotests cryptographiques.

Les clés persistantes suivantes sont actuellement sous la gestion d’IKE et de PKI :

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

  • Clés privées PKI

  • Clés VPN manuelles