Un certificat à clé publique est en quelque sorte une carte d’identité numérique: il crée un lien entre une clé de chiffrement publique, l’identité de son propriétaire et l’usage qui peut être fait de cette clé.
Pour assurer la véracité du contenu d’un certificat, celui-ci est signé par une autorité de confiance, appelée autorité de certification. Un certificat possède une durée de vie limitée: il peut soit arriver à sa date d’expiration, soit être révoqué. Plusieurs raisons sont susceptibles d’entraîner une révocation: perte de la clé privée, modification du nom du titulaire du certificat …
Il est alors placé dans une liste de révocation Certification Revocation List (CRL) signée par l’autorité de certification dont elle dépend et où sont stockés les certificats qui ne sont plus de digne de confiance. Il existe plusieurs types de certificats dont le format X509, qui repose entre autres sur la hiérarchisation des autorités de certification.
Public Key Infrastructure (PKI):
Une PKI est un ensemble de moyens (techniques et organisationnels) permettant d’assurer la gestion, l’utilisation et le cycle de vie des certificats électroniques, et d’en assurer la fiabilité. C’est la PKI qui va gérer la relation de confiance en la validité d’une identité. Ceci est rendu possible, d’une part par l’utilisation de clés et de certificats, et d’autre part par une organisation garantissant la délivrance et la gestion de ces éléments.
Une PKI répond aux critères de sécurité informatique suivants:
- L’authentification: elle sert à vérifier l’identité d’une entité (utilisateur, serveur, etc.)
- La non-répudiation: une entité qui émet des données ne pourra nier être l’auteur du message
- L’intégrité: il s’agit ici de s’assurer que les données n’ont pas été modifiées, que ce soit intentionnellement ou accidentellement
- La confidentialité: les informations échangées sont uniquement lisibles par les détenteurs d’un secret partagé, généralement une clé de session.
Une PKI peut se diviser en cinq entités distinctes :
- L’entité Finale (EE): L’entité (utilisateur ou serveur) qui est sujet d’un certificat, mais aussi plus largement l’utilisateur d’une PKI.
- L’autorité de Certification (CA): l’autorité de confiance qui signe les demandes de certificats (CSR : Certificate Signing Request) et les listes de révocation. Comme nous le verrons un peu plus tard, cette entité est la plus critique.
- L’autorité d’enregistrement (RA): c’est elle qui est contactée par l’EE lors d’une demande de certificat. Elle effectue les vérifications d’usage sur l’identité de l’EE, puis génère le certificat, attend sa signature par la CA et pour finir l’envoie à l’EE.
- L’autorité de Dépôt (Repository): elle sauvegarde les listes de révocation et les certificats signés.
- L’autorité de Séquestre (Key Escrow): la loi impose aux PKI de pouvoir déchiffrer des données chiffrées par un utilisateur de PKI. L’autorité de Séquestre a donc pour but de stocker les clés de chiffrement qui ont été générées par la PKI et de les fournir aux autorités si celles-ci le demandent. Par contre, elle ne peut pas connaître les clés privées des certificats qui ne sont pas générés par la RA mais uniquement signés par la CA.
Fonctionnement d’une PKI:
- Le client commence par faire une demande de certificat auprès de l’autorité d’enregistrement RA.
- La RA génère une paire de clés qui seront utilisées par le client et transmet la demande de certificat (CSR pour Certificate Signing Request) à l’autorité de certification.
- L’autorité de certification crée le certificat, à ce moment-là il faut généralement l’accord d’un ou plusieurs managers pour valider l’opération.
- La clé privée est enregistrée dans l’autorité de séquestre.
- L’autorité de certification transmet le certificat à l’autorité d’enregistrement qui en a fait la demande.
- L’autorité d’enregistrement envoie le certificat signé et la clé privée qui a été générée plus tôt.
Autorité de certification:
Il existe à l’heure actuelle un grand nombre (environ 700) de CA et malheureusement les utilisateurs ne peuvent pas toutes les connaître. Le problème est que si un utilisateur veut s’assurer de l’authenticité d’un serveur qui a un certificat signé par une CA qu’il connaît pas est très difficile avec le grand nombre de CA. Donc pour pallier ce genre de problème l’idée est de créer une chaîne, donc de certifier les certificats des CA par d’autres CA et ainsi de suite jusqu’à trouver une CA connue par l’utilisateur.
Les CA ont donc été hiérarchisées de la manière suivante:
- Internet Policy Registrati on Authority (IPRA): ce type d’autorité agit en tant que racine (niveau 1) de la hiérarchie. Il en existe très peu, elles sont gérées par l’ISOC 1 et n’émettent des certificats uniquement pour le niveau suivant d’autorité : les PCA.
- Policy Certification Authority (PCA): chaque PCA est certifiée par une IPRA et se trouve au deuxième niveau de la hiérarchie. Elle doit établir et publier une définition de sa politique de certification des utilisateurs ou des autorités de certification subordonnées.
- Certification Authority (CA): les CA se situent au troisième niveau (donc signées par une PCA) et aux niveaux ultérieurs de la hiérarchie (signées par d’autres CA).
Ainsi, une chaîne d’autorités de certification se crée pour vérifier la validité d’un certificat: une telle chaîne est appelée chemin de certification. Une CA ne peut certifier uniquement les autres CA qui sont au niveau inférieur dans l’arbre hiérarchique des CA.
Certication Revocation List (CRL) et Online Certicate Status Protocol (OCSP):
Une CRL correspond à la liste des identifiants des certificats révoqués par une autorité de certification donnée. Elle est signée par la CA qui la publie afin d’éviter toute modification de celle-ci par une entité non autorisée. En plus des identifiants des certificats, une CRL peut comprendre une date d’émission, une date de mise à jour et le motif éventuel de la révocation. Pour information, il existe deux états de révocation possibles (définis dans la RFC 3280) : revoked (définitif) et hold (temporaire).
Majoritairement utilisées, les CRL possèdent quelques désavantages. Nous pouvons mentionner d’une part, leur taille importante qui peut alourdir le trafic réseau, et d’autre part le fait que la validation d’un certificat s’effectue coté client, ce qui peut être critique en termes de sécurité. Ce dernier point est notamment dû au fait que les navigateurs n’accomplissent pas toujours parfaitement cette vérification. Pour tenter de corriger cela, l’ IETF a standardisé un nouveau protocole, le OCSP, qui permet de centraliser cette tâche au sein même de la PKI.
Le fonctionnement du protocole est plutôt simple puisqu’il s’agit pour le client OCSP d’envoyer une requête au répondeur OCSP (parfois appelé autorité de validation ou VA) qui se charge d’effectuer l’opération de validation et d’émettre une réponse signée qui peut prendre trois états : good, revoked ou unknown.
Certificat X.509:
X509 définit un cadre pour la fourniture de services d’authentification par répertoire X500 qui sert de dépôt de certificats à clés publique. Chaque certificat X509 contient la clé publique de l’utilisateur et est signé par la clé privée de l’autorité de certification
confiance.
La structure d’un certificat X509, présentée ci-dessous sous la forme d’un tableau:
Extensions X509 v.3:
Comme nous pouvons le voir en regardant le tableau précèdent, le champ extensions est défini par la RFC 5280 et il est apparu dans la version 3 de X509. Ces extensions permettent de compléter les certificats en rajoutant des informations supplémentaires. Elles peuvent être reparties en plusieurs grands groupes:
- Contraintes sur la certification: basicConstraints: cette extension contient deux variables, le Pathlen qui correspond au nombre maximal de certificats pouvant apparaître dans le chemin de certification et le booléen cA qui est positionné à TRUE si ce certificat peut servir à délivrer d’autres certificats et à FALSE sinon. Ainsi un Pathlen est pertinent si et seulement si le cA est à TRUE.
- Informations sur les clés: keyUsage , extended keyUsage: comme son nom le laisse supposer, cette extension permet d’indiquer et de contrôler l’usage qui peut être fait de la clé contenue dans le certificat: signature, signature de certificats/CRL, chiffrement de clés ou de données, algorithmes avec lesquels elle peut être utilisée, non répudiation. Si le champ criticality de cette extension est à TRUE, alors la clé ne doit être utilisée que dans le but spécifié, et toute autre utilisation serait contrevenir à la politique de l’AC ou de la PKI.
- Attributs de la CA ou des utilisateurs: Authority Info Access (AIA), Subject Alternative Name (SAN) : l’AIA permet de donner des informations supplémentaires sur la CA par exemple son URL ou bien celle de son répondeur OCSP/CRL. Le champs SAN spécifie un ou plusieurs noms uniques et supplémentaires pour le détenteur du certificat. Ils peuvent être utilisés dans les applications de messagerie, web, réseau où il peut être très utile d’identifier un utilisateur, ou une machine, autrement que par un DN. Les noms autorisés sont: une adresse mail, un nom de domaine, une adresse IP , une URL …
- Information sur l’utilisation du certificat: Certificate Policies: cette extension spécifie la politique de certification qui a présidé à l’émission du certificat. Elle est représentée par des OID (Object Identifier) qui sont des nombres standardisés au niveau international. Ces OID sont enregistrés au niveau international, et leur utilisation est standardisée. Un certificat peut contenir plusieurs OID, pourvu qu’elles ne soient pas incompatibles.