La cryptographie à clé publique, également appelée cryptage asymétrique, est basée sur des calculs qu'il est presque impossible de casser avec les ordinateurs les plus rapides d'aujourd'hui. Cependant, un problème subsiste lorsque l'on utilise le chiffrement avec des clés privées et publiques. On suppose que les clés publiques sont ouvertes, ce qui signifie que tout le monde a accès à ces clés. Rien n'empêche un acteur malveillant de revendiquer une clé publique qui n'est pas la sienne. Cela crée un problème d'intégrité qui peut être résolu par l'utilisation d'une infrastructure à clé publique (PKI).
Avec PKI, les utilisateurs peuvent échanger des informations en toute sécurité et en toute confidentialité sur un réseau non sécurisé tel qu'Internet. Pour ce faire, PKI utilise deux technologies qui se ressemblent : les signatures numériques et les certificats numériques, qui sont tous deux des composants essentiels du modèle de confiance de l'autorité de certification.
Exemple de signature numérique
Examinons un exemple de scénario pour mieux comprendre le déroulement général du processus de cryptage d'un message à l'aide de signatures numériques et de certificats numériques.
Permettez-moi de vous présenter à nouveau nos acteurs communs, Alice et Bob.
- La création d'une signature numérique commence lorsque Alice utilise sa clé privée pour crypter un message.
- Le résultat, également connu sous le nom de valeur de hachage, est ensuite joint au message et envoyé à Bob.
- Lorsque Bob reçoit le message, il le décrypte d'abord à l'aide de la clé publique fournie par Alice, ce qui prouve qu'il provient d'Alice.
- Ensuite, Bob passe le message dans la même fonction de hachage à sens unique et le compare à la valeur de hachage jointe.
- Si les valeurs de hachage sont identiques, le message n'a pas été modifié.
- Bob doit prouver l'authenticité de sa clé publique à Alice. Il doit obtenir un certificat numérique en enregistrant sa clé publique et les informations le concernant auprès d'une autorité de certification. Celle-ci délivre à Bob un certificat contenant sa clé publique et les informations qu'il a fournies. L'autorité de certification utilise ensuite sa clé privée pour signer numériquement le certificat de Bob et attache la clé publique de l'autorité de certification au nouveau certificat de Bob.
- Bob montre à Alice son nouveau certificat numérique. Elle peut prouver que la clé publique de Bob est valide en décryptant et en validant la signature à l'aide de la clé publique de l'autorité de certification.
- Alice passe ensuite le certificat de Bob dans la même fonction de hachage à sens unique que celle utilisée lors de la création du certificat. La clé publique de Bob est authentique si la valeur de hachage correspond à celle fournie dans le certificat.
- Si les valeurs de hachage ne correspondent pas, c'est que quelque chose a été modifié dans le certificat de Bob depuis que l'autorité de certification l'a signé pour la dernière fois. Alice ne peut donc pas faire confiance aux informations contenues dans le certificat, y compris à la clé publique de Bob.
Bob sait maintenant s'il peut faire confiance à Alice pour signer numériquement le message et vérifier s'il a été modifié.
Exemple de certificats numériques
Les certificats X.509 PKI distribuent en toute sécurité les clés publiques afin de garantir qu'elles appartiennent à des propriétaires légitimes et qu'elles ne sont pas forgées par des acteurs malveillants. Les certificats X.509 sont créés et signés par une autorité de certification de confiance.
Alice et Bob sont de retour, et cette fois Alice veut confirmer l'authenticité du certificat signé par Bob.
- Bob doit prouver l'authenticité de sa clé publique à Alice. Il doit obtenir un certificat numérique en enregistrant sa clé publique et les informations le concernant auprès d'une autorité de certification. Celle-ci délivre à Bob un certificat contenant sa clé publique et les informations qu'il a fournies. L'autorité de certification utilise ensuite sa clé privée pour signer numériquement le certificat de Bob et attache la clé publique de l'autorité de certification au nouveau certificat de Bob.
- Bob montre à Alice son nouveau certificat numérique. Elle peut prouver que la clé publique de Bob est valide en décryptant et en validant la signature à l'aide de la clé publique de l'autorité de certification.
- Alice passe ensuite le certificat de Bob dans la même fonction de hachage à sens unique que celle utilisée lors de la création du certificat. La clé publique de Bob est authentique si la valeur de hachage correspond à celle fournie dans le certificat.
- Si les valeurs de hachage ne correspondent pas, c'est que quelque chose a été modifié dans le certificat de Bob depuis que l'autorité de certification l'a signé pour la dernière fois. Alice ne peut donc pas faire confiance aux informations contenues dans le certificat, y compris à la clé publique de Bob.
Types d'autorités
L'autorité d'enregistrement (RA) est un serveur qui attend que les clients envoient leurs demandes de signature de certificat (CSR). En règle générale, la création d'un certificat de clé publique est lancée par le sujet qui émet une demande à l'autorité d'enregistrement. Le sujet génère une paire de clés, qui est ensuite envoyée avec une demande de certificat à l'autorité d'enregistrement.
Lorsque les demandes sont reçues, validées et signées, l'autorité de certification peut créer un certificat à partir de la paire de clés soumise. L'autorité de certification valide et signe alors la RSC, qui est ensuite envoyée à une autorité de certification.
Si la paire de clés générée par le sujet n'est pas valide ou si la demande ne contient pas les informations nécessaires à la création d'un certificat valide, la demande n'est pas transmise à une autorité de certification. La charge de travail des autorités de certification s'en trouve ainsi réduite.
Les autorités de certification sont reconnues par une ou plusieurs entités comme étant responsables de la création et de la signature de certificats à clé publique. En option, une autorité de certification peut délivrer les clés du sujet ou les faire fournir par le sujet par l'intermédiaire d'une autorité d'enregistrement.
Les autorités de certification sont considérées comme fiables parce qu'elles disposent d'un certificat d'autorité de certification signé par une autre autorité de certification fiable ; elles peuvent également être responsables de la révocation de certificats.
L'autorité de certification gère cette tâche en conservant une structure de données appelée liste de révocation des certificats (LRC). Une LCR contient les identifiants de tous les certificats révoqués émis par la même AC. L'authenticité de la LCR elle-même est prouvée par une signature numérique, de la même manière qu'un certificat de clé publique.
Une autorité de validation peut vérifier un certificat en téléchargeant la CRL d'une autorité de certification, en vérifiant la signature, puis en vérifiant si le certificat figure dans la CRL. Si c'est le cas, le certificat n'est pas valide. Dans le cas contraire, il est considéré comme un certificat valide.
Une autre façon de gérer la révocation des certificats est d'utiliser le protocole d'état des certificats en ligne (OSCP). Ce protocole résout le problème de la croissance de la CRL pour chaque certificat révoqué. Chaque fois qu'un certificat doit être vérifié, le client doit télécharger la CRL complète. Le protocole OSCP permet au client de demander si un certificat est valide au lieu de télécharger une CRL. Le rapport indique que chaque réponse à un client doit être signée afin que le client puisse en vérifier l'authenticité.
Types de certificats X.509
X.509 est un protocole largement accepté qui régit le format d'un certificat numérique. Trois versions de la norme x509 ont été définies :
- La version 1 de X.509 a été publiée pour la première fois en 1988 dans le cadre de la norme X.500 de l'UIT sur les services d'annuaire.
- La version 2 de X.509 a ajouté deux nouveaux champs au format en 1993.
- X. 509 version 3 définit le format des extensions de certificat utilisées pour stocker des informations supplémentaires sur le détenteur du certificat et pour réglementer l'utilisation des certificats.
Les certificats X.509 comportent généralement une signature numérique avec une clé publique, une période de validité, un émetteur, un sujet et un ensemble d'extensions. Les extensions décrivent des caractéristiques supplémentaires du certificat, telles que des attributs supplémentaires ou des restrictions sur l'utilisation du certificat.
Les certificats X.509 doivent répondre aux trois exigences suivantes :
1. Il existe un chemin de vérification entre le certificat du serveur et un certificat racine de confiance ;
2. Les attributs du certificat dans le chemin de vérification répondent à des critères spécifiques pour cette vérification ;
3. Le certificat ne figure pas dans le contenu d'une CRL en vigueur ou dans la réponse à une requête OCSP.
X.509 PKI se compose de quatre éléments différents :
- Un serveur d'entité finale qui demande un certificat numérique signé
- Une autorité de certification racine qui peut émettre et vérifier des certificats numériques.
- Une autorité d'enregistrement qui est l'intermédiaire, et
- L'utilisateur final qui souhaite vérifier le certificat de clé publique d'un serveur.
Les certificats racine, souvent appelés racines de confiance, sont à la source des chaînes de confiance dans les certificats X.509 PKI. L'autorité de certification racine peut émettre et signer des certificats de confiance, en externe, et leur attribuer des fonctions et des objectifs spécifiques. Mais comme il est impossible de confirmer l'intégrité d'un certificat auto-signé, une hiérarchie de certificats vérifiable est nécessaire.
Les certificats racine X.509 peuvent être classés en trois catégories différentes :
- Certificats auto-émis - Ces certificats sont des certificats d'autorité de certification dont l'émetteur et le sujet ont les mêmes valeurs.
- Certificats auto-signés - Ces certificats sont un type différent de certificat d'autorité de certification auto-délivré, dans lequel les objets "issuer" et "subject" ont les mêmes valeurs. La différence entre le certificat auto-signé et le certificat auto-délivré est que le certificat auto-signé est signé à l'aide de la clé privée correspondante. Ce type de certificat peut être utilisé par l'autorité de certification pour rendre publiques ses clés publiques.
- Certificats croisés - Il s'agit d'un certificat d'autorité de certification dont l'émetteur et l'objet sont des autorités de certification différentes. Ils sont utilisés pour confirmer et vérifier l'existence de l'autorité de certification concernée.
Les certificats d'entité finale sont des certificats à clé publique délivrés par une autorité de certification. Ces certificats ont la propriété que la clé privée correspondante ne peut pas être utilisée pour signer d'autres certificats à clé publique.
Les certificats de clés publiques d'entités fin ales sont utilisés pour vérifier que les clés publiques correspondantes n'ont pas été falsifiées. Même si tous les certificats émis par un certificat sont intrinsèquement fiables, l'autorité de certification racine n'émet pas directement de certificats d'entités finales. Pour ces raisons, l'autorité de certification racine crée une couche protectrice de certificats subordonnés.
Les certificats subordonnés vivent en ligne, entre le certificat racine et les certificats d'entité finale, et sont reliés en chaîne aux certificats racine. Cela permet aux observateurs publics de valider les certificats d'entités finales, même si le certificat racine est hors ligne dans un module de sécurité Hardware .
Tant qu'elles renvoient à une autorité de certification racine de confiance, il est possible de vérifier l'ensemble de la chaîne de confiance, de la racine au certificat de l'entité finale. Il peut y avoir plus d'une couche d'AC subordonnée. Les certificats qui se trouvent entre les certificats subordonnés et les certificats d'entité finale sont souvent appelés certificats intermédiaires.
Les certificats intermédiaires servent de maillons principaux des chaînes de confiance. Ils ne peuvent effectuer que les tâches autorisées par l'autorité de certification racine. Dans les hiérarchies publiques, une AC intermédiaire est autorisée à délivrer uniquement des certificatsSSL , tandis qu'une autre ne délivre que des certificats S/MIME.
Un autre scénario courant consiste à autoriser différentes autorités de certification intermédiaires à émettre des certificats pour chaque département ou site d'une organisation. En outre, vous pouvez en avoir une pour certifier les clés ECC et une autre pour les clés RSA.
Le site PKI a également besoin d'un répertoire pour émettre, stocker, révoquer et gérer les certificats numériques X.509.
Gestion des certificats numériques
Si vous souhaitez en savoir plus sur la gestion des certificats numériques et sur les meilleures pratiques de PKI , consultez ces ressources supplémentaires :
