Composants PKI dans Junos OS

Gestion et implémentation de l’ICP

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

• Configuration des autorités de certification et des certificats d’AC

• Des certificats locaux comprenant l’identité de l’appareil (par exemple : type et valeur de l’ID IKE)

• Clés privées et publiques

• CRL pour la validation de la certification

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

IKE

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

• Au lieu de faire un résumé à partir du certificat d’AC, 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’AC, les participants utilisent la paire de clés publique-privée de l’expéditeur.

PKI sur HTTPS

La prise en charge de HTTPS pour PKI renforce la sécurité des opérations de gestion des certificats. Le protocole HTTPS sur la PKI établit des canaux de communication sécurisés pour l’inscription aux SCEP et la révocation des CRL, protégeant ainsi les informations sensibles.

Le processus PKI sélectionne dynamiquement HTTP ou HTTPS en fonction des URL configurées, ce qui offre flexibilité et sécurise les transmissions.

• Si vous utilisez une URL HTTP dans le profil AC, le processus PKID utilise le canal de communication HTTP.
• Si vous utilisez une URL HTTPS dans le profil AC, le processus PKID utilise le canal de communication HTTPS.

Trusted AC Group

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

Par exemple, supposons que vous avez 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’AC 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 trusted-ca-group est configuré, l’équipement n’utilisera que les profils d’AC ajoutés dans cet trusted-ca-group article ou le profil d’AC 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 la connexion est rejetée.

Avantages :

• Pour toute demande de connexion entrante, seul le certificat émis par l’AC de confiance de ce point de terminaison respectif est validé. Si ce n’est pas le cas, l’autorisation rejette la connexion.

Gestion des clés cryptographiques

La gestion des clés cryptographiques stocke les clés persistantes dans la mémoire de l’appareil sans les altérer. La mémoire interne n’est pas accessible aux adversaires. Vous pouvez activer le mécanisme de gestion des clés pour les clés cryptographiques afin d’assurer la sécurité.

Lorsque vous activez la gestion des clés cryptographiques :

• La gestion des clés cryptographiques chiffre les clés lorsqu’elles ne sont pas immédiatement utilisées.

• Effectue la détection des erreurs lors de la copie d’une clé d’un emplacement mémoire à un autre.

• Remplace l’emplacement mémoire d’une clé par un modèle binaire aléatoire lorsque la clé n’est plus utilisée.

Un administrateur cryptographique peut activer et désactiver les fonctions d’autotest cryptographique. Toutefois, l’administrateur 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 l’IKE et la PKI :

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

• Clés privées PKI

• Clés VPN manuelles

Signatures et vérification des certificats

Un certificat numérique est un moyen électronique de vérifier votre identité par l’intermédiaire d’un tiers de confiance, appelé AC. Vous pouvez également utiliser un certificat autosigné pour attester de votre identité.

Le serveur d’AC que vous utilisez peut être détenu et exploité par un AC indépendant ou par votre propre organisation, auquel cas vous devenez votre propre AC. Si vous utilisez une AC indépendante, vous devez contacter cette AC pour obtenir les adresses de ses serveurs de l’AC et de la CRL (pour obtenir des certificats et des CRL) et les informations dont elle a besoin lorsqu’elle soumet des demandes de certificats personnels. Lorsque vous êtes votre propre AC, vous déterminez ces informations vous-même.

L’AC qui émet un certificat utilise un algorithme de hachage pour générer un résumé, puis « signe » le certificat en le chiffrant avec sa clé privée. Le résultat est une signature numérique. L’AC met ensuite le certificat signé numériquement à la disposition de la personne qui l’a demandé.

Le destinataire du certificat génère un autre résumé en appliquant le même algorithme de hachage au fichier de certificat, puis utilise la clé publique de l’AC pour déchiffrer la signature numérique. En comparant le résumé déchiffré avec le résumé nouvellement généré, le destinataire peut confirmer l’intégrité de la signature de l’AC et, par extension, l’intégrité du certificat qui l’accompagne. La figure 1 illustre l’ensemble de ce processus.

Un certificat est considéré comme valide si la signature numérique peut être vérifiée et que le numéro de série du certificat n’est pas répertorié dans une liste de révocation de certificats.

Lorsque des signatures DSA sont utilisées, l’algorithme de hachage SHA-1 est utilisé pour générer le digest. Lorsque des signatures Rivest-Shamir-Adleman (RSA) sont utilisées, SHA-1 est l’algorithme de hachage par défaut utilisé pour générer le digest ; vous pouvez spécifier l’algorithme de hachage SHA-256 avec l’option digest des request security pki generate-certificate-request commandes or request security pki local-certificate generate-self-signed . Lorsque des signatures ECDSA sont utilisées, SHA-256 est utilisé pour les signatures ECDSA-256 et SHA-384 est utilisé pour les signatures ECDSA-384.

À partir de la version 18.1R3 de Junos OS, l’algorithme de hachage par défaut utilisé pour valider les certificats PKI auto-signés générés automatiquement et manuellement est SHA-256. Avant la version 18.1R3 de Junos OS, SHA-1 était utilisé comme algorithme de hachage par défaut.

Validation des certificats

Pour vérifier la fiabilité d’un certificat, vous devez être en mesure de suivre le parcours des autorités de certification certifiées, de celle qui émet votre certificat local jusqu’à l’autorité racine d’un domaine d’AC. L’ICP fait référence à la structure hiérarchique de confiance requise pour la mise en œuvre réussie de la cryptographie à clé publique.

La figure 2 illustre la structure d’une AC à domaine unique avec plusieurs niveaux hiérarchiques.

Si les certificats sont utilisés uniquement au sein d’une organisation, cette organisation peut avoir son propre domaine d’AC dans lequel l’AC d’entreprise émet et valide les certificats pour ses employés. Si cette organisation souhaite par la suite que ses employés échangent leurs certificats avec des certificats d’un autre domaine d’AC (par exemple, avec des employés d’une autre organisation qui possède son propre domaine d’AC), les deux autorités de certification peuvent développer une certification croisée en acceptant de faire confiance à l’autorité de l’autre. Dans ce cas, la structure PKI ne s’étend pas verticalement mais s’étend horizontalement. Voir Figure 3.