Infrastructure à clé publique
1. Les certificats numériques
Un certificat électronique (aussi appelé certificat numérique ou certificat de clé publique) peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, mais aussi pour chiffrer des échanges.
Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique (virtuelle).
Le standard le plus utilisé pour la création des certificats numériques est le X.509.
2. Définition d’un certificat numérique
Un certificat électronique est un ensemble de données contenant :
- au moins une clé publique ;
- des informations d’identification, par exemple : nom, localisation, adresse électronique ;
- au moins une signature (clé privée) ; de fait quand il n’y en a qu’une, l’entité signataire est la seule autorité permettant de prêter confiance (ou non) à l’exactitude des informations du certificat.
Les certificats électroniques et leur cycle de vie (voir liste de révocation de certificats et protocole de vérification de certificat en ligne) peuvent être gérés au sein d’infrastructures à clés publiques.
3. Formats de certificats numériques
Les certificats électroniques respectent des standards spécifiant leur contenu de façon rigoureuse. Les deux formats les plus utilisés aujourd’hui sont :
- X.509, défini dans la RFC 5280 ;
- OpenPGP, défini dans la RFC 4880.
La différence notable entre ces deux formats est qu’un certificat X.509 ne peut contenir qu’un seul identifiant, que cet identifiant doit contenir de nombreux champs prédéfinis, et ne peut être signé que par une seule autorité de certification. Un certificat OpenPGP peut contenir plusieurs identifiants, lesquels autorisent une certaine souplesse sur leur contenu, et peuvent être signés par une multitude d’autres certificats OpenPGP, ce qui permet alors de construire des toiles de confiance.
4. Utilité des certificats électroniques
Les certificats électroniques sont utilisés dans différentes applications informatiques dans le cadre de la sécurité des systèmes d’information pour garantir :
- la non-répudiation et l’intégrité des données avec la signature numérique ;
- la confidentialité des données grâce au chiffrement des données ;
- l’authentification ou l’authentification forte d’un individu ou d’une identité numérique.
5. Familles de certificats numériques
Usuellement, on distingue deux familles de certificats numériques :
- les certificats de signature, utilisés pour signer des documents ou s’authentifier sur un site web, et
- les certificats de chiffrement (les gens qui vous envoient des courriels utilisent la partie publique de votre certificat pour chiffrer le contenu que vous serez seul à pouvoir déchiffrer)
Mais cette typologie n’est pas exhaustive ; un découpage plus orienté applicatif pourrait être envisagé. L’intérêt de la séparation des usages découle notamment des problématiques de séquestre de clés et de recouvrement. En effet, lorsqu’il y a chiffrement, il peut y avoir nécessité de recouvrer les informations chiffrées. Alors que lorsqu’il y a signature, il est indispensable de s’assurer que la clé privée n’est possédée que par une seule partie.
6. Exemples d’utilisation de certificats électroniques
- Serveur web (voir TLS et X.509) ;
- Courrier électronique (voir OpenPGP) ;
- Poste de travail (voir IEEE 802.1X) ;
- Réseau privé virtuel (VPN, voir IPsec) ;
- Secure Shell (SSH), TLS ;
- Documents électroniques.
7. Structure d’un certificat
La définition originale est disponible dans la RFC 2459 (section 4) ou dans la dernière version (RFC 5280), qui contient une spécialisation de X.509 pour les applications Internet. La partie authentifiée contient les champs suivants :
- Version
- Numéro de série
- Algorithme de signature du certificat
- DN (Distinguished Name) du délivreur (autorité de certification)
- Validité (dates limites)
- Pas avant
- Pas après
- DN de l’objet du certificat
- Informations sur la clé publique
- Algorithme de la clé publique
- Clé publique proprement dite
- Identifiant unique du signataire (optionnel, X.509v2)
- Identifiant unique du détenteur du certificat (optionnel, X.509v2)
- Extensions (optionnel, à partir de X.509v3)
- Liste des extensions
- Signature des informations ci-dessus par l’autorité de certification
Extensions à la norme et usage spécifique d’un certificat : Le RFC 5280 définit une somme d’extensions indiquant l’usage auquel est destiné le certificat.
8. Encodage des certificats
On trouve plusiseurs types d’encodage, parmi d’autres.
- PEM : (Privacy-enhancedElectronic Mail) certificat DER encodé en Base64, encadré par les mentions “
-----BEGIN CERTIFICATE-----” et “-----END CERTIFICATE-----” - DER : certificat encodé DER au format binaire
9. Infrastructure à clé publique
Une infrastructure à clés publiques (ICP) ou infrastructure de gestion de clés (IGC) ou encore Public Key Infrastructure (PKI), est un ensemble de composants physiques (des ordinateurs, des équipements cryptographiques logiciels ou matériel type HSM ou encore des cartes à puces), de procédures humaines (vérifications, validation) et de logiciels (système et application) en vue de gérer le cycle de vie des certificats numériques ou certificats électroniques.
Une infrastructure à clés publiques fournit des garanties permettant de faire a priori confiance à un certificat signé par une autorité de certification grâce à un ensemble de services.
Ces services sont les suivants :
- enregistrement des utilisateurs (ou équipement informatique) ;
- génération de certificats ;
- renouvellement de certificats ;
- révocation de certificats ;
- publication de certificats ;
- publication des listes de révocation (comprenant la liste des certificats révoqués) ;
- identification et authentification des utilisateurs (administrateurs ou utilisateurs qui accèdent à l’ICP) ;
- archivage, séquestre et recouvrement des certificats (option).
10. Rôles d’une infrastructure à clés publiques
Une infrastructure à clés publiques (ICP) délivre des certificats numériques. Ces certificats permettent d’effectuer des opérations cryptographiques, comme le chiffrement et la signature numérique qui offrent les garanties suivantes lors des transactions électroniques :
- confidentialité : elle garantit que seul le destinataire (ou le possesseur) légitime d’un bloc de données ou d’un message peut en avoir une vision intelligible ;
- authentification : elle garantit à tout destinataire d’un bloc de données ou d’un message ou à tout système auquel tente de se connecter un utilisateur l’identité de l’expéditeur ou de l’utilisateur en question ;
- intégrité : elle garantit qu’un bloc de données ou qu’un message n’a pas été altéré, accidentellement ou intentionnellement ;
- non-répudiation : elle garantit à quiconque que l’auteur d’un bloc de données ou d’un message ne peut renier son oeuvre, c’est-à-dire prétendre ne pas en être l’auteur.
Les ICP permettent l’obtention de ces garanties par l’application de processus de vérification d’identité rigoureux et par la mise en œuvre de solutions cryptographiques fiables (éventuellement évaluées), conditions indispensables à la production et à la gestion des certificats électroniques.
11. Composants de l’infrastructure à clés publiques
L’IETF distingue 4 catégories d’ICP :
- l’autorité de certification (AC ou CA) qui signe les demandes de certificat (CSR : Certificate Signing Request) et les listes de révocation (CRL : Certificate Revocation List). Cette autorité est la plus critique ;
- l’autorité d’enregistrement (AE ou RA) qui effectue les vérifications d’usage sur l’identité de l’utilisateur final (les certificats numériques sont nominatifs et uniques pour l’ensemble de l’ICP) ;
- l’autorité de dépôt (Repository) qui stocke les certificats numériques ainsi que les listes de révocation (CRL) ;
- l’entité finale (EE : End Entity) qui utilise le certificat (en général, le terme « entité d’extrémité » (EE) est préféré au terme « sujet » afin d’éviter la confusion avec le champ Subject).
En complément, on pourra ajouter une cinquième catégorie, non définie par l’IETF :
- l’autorité de séquestre (Key Escrow) qui stocke de façon sécurisée les clés de chiffrement créées par les autorités d’enregistrement, pour pouvoir, le cas échéant, les restaurer. Les raisons à cela en sont multiples. La perte de la clef privée par son détenteur ne doit pas être définitive. Toute organisation doit être en mesure de déchiffrer les documents de travail d’un de ses membres si, par exemple, celui-ci n’en fait plus partie. Enfin, dans certains pays, en France en particulier, la loi exige que les données chiffrées puissent être déchiffrées à la demande des autorités nationales. La mise en œuvre d’un séquestre répond à cette exigence.
12. Certificats numériques dans une PKI
Un certificat électronique est une donnée publique. Suivant la technique des clés asymétriques, à chaque certificat électronique correspond une clé privée, qui doit être soigneusement protégée.
Un certificat numérique porte les caractéristiques de son titulaire : si le porteur est un être humain, cela peut être son nom et son prénom, le nom de sa structure (par exemple, son entreprise ou son… État !) et de son entité d’appartenance. Si c’est un équipement informatique (comme une passerelle d’accès ou un serveur d’application sécurisé), le nom est remplacé par l’URI du service. À ces informations d’identification s’ajoute la partie publique du bi-clé.
L’ensemble de ces informations (comprenant la clé publique) est signé par l’autorité de certification de l’organisation émettrice. Cette autorité a la charge de :
- s’assurer que les informations portées par le certificat numérique sont correctes ;
- s’assurer qu’il n’existe, pour une personne et pour une même fonction, qu’un et un seul certificat valide à un moment donné.
Le certificat numérique est donc, à l’échelle d’une organisation, un outil pour témoigner, de façon électroniquement sûre, d’une identité.
L’usage conjoint des clés cryptographiques publiques (contenue dans le certificat) et privée (protégée par l’utilisateur, par exemple au sein d’une carte à puce), permet de disposer de fonctions de sécurité importante (cf. infra).
13. Gestion des certificats
Un certificat numérique naît après qu’une demande de certificat a abouti.
Une demande de certificat est un fichier numérique (appelé soit par son format, PKCS#10, soit par son équivalent fonctionnel, CSR pour Certificate Signing Request) qui est soumis à une autorité d’enregistrement par un utilisateur final ou par un administrateur pour le compte d’un utilisateur final.
Cette demande de certificat est examinée par un Opérateur d’Autorité d’Enregistrement. Cette position est une responsabilité clé : c’est lui qui doit juger de la légitimité de la demande de l’utilisateur et accorder, ou non, la confiance de l’organisation. Pour se forger une opinion, l’Opérateur doit suivre une série de procédures, plus ou moins complètes, consignées dans deux documents de référence qui vont de pair avec la création d’une ICP qui sont la Politique de Certification (PC) et la Déclaration des Pratiques de Certification (DPC). Ces documents peuvent exiger, en fonction des enjeux de la certification, des vérifications plus ou moins poussées : rencontre en face-à-face, validation hiérarchique, etc. L’objectif de l’Opérateur d’AE est d’assurer que les informations fournies par l’utilisateur sont exactes et que ce dernier est bien autorisé à solliciter la création d’un certificat.
Une fois son opinion formée, l’Opérateur de l’AE valide la demande ou la rejette. S’il la valide, la demande de certificat est alors adressée à l’Autorité de Certification (AC). L’AC vérifie que la demande a bien été validée par un Opérateur d’AE digne de confiance et, si c’est le cas, signe la CSR. Une fois signée, une CSR devient… un certificat.
Le certificat, qui ne contient aucune information confidentielle, peut par exemple être publié dans un annuaire d’entreprise : c’est la tâche du Module de Publication, souvent proche de l’AC.
14. Modes de création
Il existe deux façons distinctes de créer des certificats électroniques : le mode centralisé et le mode décentralisé.
- le mode décentralisé est le mode le plus courant : il consiste à faire créer, par l’utilisateur (ou, plus exactement par son logiciel ou carte à puce) le biclé cryptographique et de joindre la partie publique de la clef dans la CSR. L’Infrastructure n’a donc jamais connaissance de la clé privée de l’utilisateur, qui reste confinée sur son poste de travail ou dans sa carte à puce.
- le mode centralisé consiste en la création du biclé par l’AC : au début du cycle de la demande, la CSR ne contient pas la clé publique, c’est l’AC qui la produit. Elle peut ainsi avoir de bonnes garanties sur la qualité de la clé (aléa) et peut… en détenir une copie protégée. En revanche, il faut transmettre à l’utilisateur certes son certificat (qui ne contient que des données publiques) mais aussi sa clé privée ! L’ensemble de ces deux données est un fichier créé sous le format PKCS#12. Son acheminement vers l’utilisateur doit être entrepris avec beaucoup de précaution et de sécurité, car toute personne mettant la main sur un fichier PKCS#12 peut détenir la clé de l’utilisateur.
Le mode décentralisé est préconisé pour les certificats d’authentification (pour des questions de coût, parce qu’il est plus simple de refaire un certificat en décentralisé qu’à recouvrer une clé) et de signature (parce que les conditions d’exercice d’une signature juridiquement valide prévoit que le signataire doit être le seul possesseur de la clé : en mode décentralisé, l’ICP n’a jamais accès à la clé privée).
Le mode centralisé est préconisé pour les certificats de chiffrement, car, lorsqu’un utilisateur a perdu sa clé (par exemple, sa carte est perdue ou dysfonctionne), un opérateur peut, au terme d’une procédure de recouvrement, récupérer la clé de chiffrement et la lui remettre. Chose qui est impossible à faire avec des clés qui n’ont pas été séquestrées.
15. Scénario de fin de vie / CRL
Il existe deux scénarios possibles de fin de vie d’un certificat numérique :
le certificat numérique expire (chaque certificat numérique contient une date de « naissance » et une date de « péremption »). le certificat est révoqué, pour quelque raison que ce soit (perte de la clé privée associée, etc.) et dans ce cas, l’identifiant du certificat numérique est ajouté à une liste de certificats révoqués (CRL pour Certificate Revocation List) pour informer les applications qu’elles ne doivent plus faire confiance à ce certificat. Il est aussi possible que les applications s’informent en quasi temps réel de l’état du certificat avec le protocole OCSP.
Un certificat peut devenir invalide pour de nombreuses raisons telles que l’expiration naturelle (dépassement de la date de validité), la perte ou la compromission de la clé privée associée au certificat, le changement d’au moins un champ inclus dans le nom du titulaire / détenteur du certificat et cas extrême la perte ou la compromission de la clé privée de l’autorité de certification ayant signé le certificat en question.
C’est pourquoi la norme définit le format d’une liste indiquant les certificats devenus invalides pour une autorité de certification donnée. Cette liste est signée par l’autorité de certification pour en empêcher toute modification par une personne non autorisée.
Elle comprend une date d’émission, une date de mise à jour (toutes deux optionnelles) et la liste proprement dite sous la forme de paires (numéro de série du certificat révoqué ; motif éventuel de révocation). Le motif ne peut être présent que dans les CRL au format version 2.
Une limitation parfois gênante des CRL est le délai de propagation des informations de révocation. Pour le réduire, le protocole OCSP de validation de certificat a été développé. Défini initialement dans la RFC 2560 puis de nouveau dans la RFC 6960, ce protocole donne à peu près les mêmes informations que les CRL, mais potentiellement plus à jour.
16. Autorité de certification
En cryptographie, une Autorité de Certification (AC ou CA pour Certificate Authority en anglais) est un tiers de confiance permettant d’authentifier l’identité des correspondants. Une autorité de certification délivre des certificats décrivant des identités numériques et met à disposition les moyens de vérifier la validité des certificats qu’elle a fourni.
Les services des autorités de certification sont principalement utilisés dans le cadre de la sécurisation des communications numériques via protocole Transport Layer Security (TLS) utilisé par exemple pour sécuriser les communications web (HTTPS) ou email (SMTP, POP3, IMAP… sur TLS), ainsi que pour la sécurisation des documents numériques (par exemple au moyen de signatures électroniques avancées telles que PAdES pour des documents PDF, ou via le protocole S/MIME pour les emails).
17. Utilisation dans le domaine des communications web
Les navigateurs web modernes intègrent nativement une liste de certificats provenant de différentes Autorités de Certification choisies selon des règles internes définies par les développeurs du navigateur.
Lorsqu’une personne physique ou morale souhaite mettre en place un serveur web utilisant une communication HTTPS sécurisée par TLS, elle génère une clé publique, une clé privée puis envoie à l’une de ces Autorité de Certification une demande de signature de certificat (en anglais CSR : Certificate Signing Request) contenant sa clé publique ainsi que des informations sur son identité (coordonnées postales, téléphoniques, email…).
Après vérification de l’identité du demandeur du certificat par une autorité d’enregistrement (RA), l’Autorité de Certification signe le CSR grâce à sa propre clé privée (et non pas avec la clé privée de la personne donc) qui devient alors un certificat puis le transmet en retour à la personne qui en a fait la demande.
Le certificat ainsi retourné sous forme de fichier informatique est intégré dans le serveur web du demandeur. Lorsqu’un utilisateur se connecte à ce serveur web, celui-ci lui transmet à son tour le certificat fourni précédemment par l’Autorité de Certification.
Le navigateur web du client authentifie le certificat du serveur grâce au certificat de l’Autorité de Certification (intégré nativement dans le navigateur, cf. ci-dessus) qui l’a signé précédemment. L’identité du serveur est ainsi confirmée à l’utilisateur par l’Autorité de Certification.
Le navigateur web contacte ensuite l’Autorité de Certification concernée pour savoir si le certificat du serveur n’a pas été révoqué (= invalidé) depuis qu’il a été émis par l’Autorité de Certification via une demande OCSP.
Auparavant, les navigateurs téléchargeaient régulièrement des listes de révocation (CRL : Certificate Revocation List) de la part des Autorités de Certification au lieu de contacter directement celles-ci par des demandes OCSP. Ce processus a été abandonné depuis car utilisant inutilement beaucoup de bande passante.
Sur le plan technique, cette infrastructure de gestion des clés permet ainsi d’assurer que :
- les données transmises entre le serveur web et le client n’ont pas été modifiées durant le transfert : intégrité par hachage des données.
- les données proviennent bien du serveur web connu et qu’il ne s’agit pas d’un serveur web tiers tentant d’usurper l’identité de celui-ci.
- les données ne peuvent pas être interceptées par un tiers car elles sont chiffrées.
18. Fonctionnement interne
L’autorité de certification (AC) opère elle-même ou peut déléguer l’hébergement de la clé privée du certificat à un opérateur de certification (OC) ou autorité de dépôt. L’AC contrôle et audite l’opérateur de certification sur la base des procédures établies dans la Déclaration des Pratiques de Certification. L’AC est accréditée par une autorité de gestion de la politique qui lui permet d’utiliser un certificat renforcé utilisé par l’OC pour signer la clé publique selon le principe de la signature numérique.
19. Serveur de clés
Les certificats peuvent être stockés par des serveurs de clés, qui peuvent aussi faire office d’autorité d’enregistrement et de certification (repère A).
Ils recensent et contrôlent les certificats. Ils possèdent souvent une liste (repère B) des certificats révoqués.
20. Synthèse sur infrastructure à clé publique.
Terminologie
- PKI : Infrastructure à clé publique. Ceci décrit la collection de fichiers et les associations entre l’AC, les paires de clés, les demandes et les certificats.
- AC : Autorité de certification. Il s’agit du “ certificat maître “ à la racine d’une PKI.
- cert : Certificat. Un certificat est une demande qui a été signée par une AC. Le certificat contient la clé publique, certains détails décrivant le certificat lui-même et une signature numérique de l’autorité de certification.
- request : Certificate Request (également “req”.) Il s’agit d’une demande de certificat qui est ensuite envoyée à une autorité de certification pour signature. Une demande contient les informations souhaitées sur le certificat ainsi qu’une signature numérique de la clé privée.
- keypair : Une paire de clés est une paire de clés cryptographiques asymétriques. Ces clés sont divisées en deux parties : la clé publique et la clé privée. La clé publique est incluse dans une demande et un certificat.
L’Autorité de certification (AC)
Le coeur d’une PKI est l’AC, ou autorité de certification, et c’est également l’élément le plus sensible en matière de sécurité. La clé privée de l’AC est utilisée pour signer tous les certificats émis, sa sécurité est donc essentielle pour assurer la sécurité de l’ensemble de la PKI. C’est pourquoi il est fortement recommandé de conserver la structure de la PKI de l’AC sur un système dédié à cette utilisation sécurisée. Il n’est pas recommandé de mélanger la PKI de l’AC avec un système utilisé pour générer des certificats d’entités finales, comme des clients ou des serveurs (VPN ou serveurs Web).
Pour démarrer une nouvelle PKI, l’AC est d’abord créée dans l’environnement sécurisé. En fonction des besoins de sécurité, cela peut être géré sous un compte verrouillé, un système dédié, voire un système complètement hors ligne ou utilisant des supports amovibles pour améliorer la sécurité (après tout, vous ne pouvez pas subir une effraction en ligne si votre système ou votre PKI n’est pas en ligne). Les étapes exactes de la création d’une AC sont décrites dans une section distincte. Lors de la création d’une nouvelle AC, la paire de clés de l’AC (clés privées et publiques) est créée, ainsi que la structure de fichiers nécessaire pour prendre en charge la signature des certificats émis.
Une fois qu’une AC a été créée, elle peut recevoir des demandes de certificats de la part d’entités finales. Ces certificats d’entité sont délivrés aux consommateurs de certificats X509, tels qu’un client ou un serveur d’un système VPN, Web ou de messagerie. Les demandes de certificats et les certificats ne sont pas sensibles à la sécurité et peuvent être transférés par le moyen qui vous convient le mieux, comme le courrier électronique, la clé USB, etc. Pour une meilleure sécurité, il est conseillé de vérifier que la demande reçue correspond à la copie de l’expéditeur, par exemple en vérifiant la somme de contrôle attendue par rapport à l’original de l’expéditeur.
Paires de clés et demandes
Les entités finales individuelles n’ont pas besoin d’une configuration complète de l’AC et devront seulement créer une paire de clés et une demande de certificat associée. La clé privée n’est utilisée nulle part ailleurs que sur cette entité, et ne doit jamais quitter ce système. Il est sage de sécuriser cette clé privée avec une phrase de passe forte, car en cas de perte ou de vol, le détenteur de la clé privée peut établir des connexions en se faisant passer pour le détenteur du certificat.
Une fois la paire de clés générée, la demande de certificat est créée et signée numériquement à l’aide de la clé privée. Cette demande est envoyée à une autorité de certification pour être signée, et un certificat signé est renvoyé.
Comment les demandes deviennent des certificats
Une fois qu’une autorité de certification a signé la demande de certificat, un certificat signé est produit. À cette étape, la clé privée de l’autorité de certification est utilisée pour signer numériquement la clé publique de l’entité, de sorte que tout système faisant confiance au certificat de l’autorité de certification peut implicitement faire confiance au certificat nouvellement émis. Ce certificat signé est ensuite renvoyé à l’entité requérante. Le certificat émis n’est pas sensible à la sécurité et peut être envoyé par des méthodes de transmission en clair.
Vérification d’un certificat émis
Après que deux entités aient créé des paires de clés, envoyé leurs demandes à l’AC et reçu une copie de leurs certificats signés et du certificat de l’AC, elles peuvent s’authentifier mutuellement. Ce processus ne nécessite pas que les deux entités aient préalablement échangé directement des informations de sécurité.
Au cours d’une poignée de main TLS, chaque partie de la connexion présente sa propre chaîne de certificats à l’extrémité distante. Chaque partie vérifie la validité du certificat reçu par rapport à sa propre copie du certificat de l’autorité de certification. En faisant confiance au certificat racine de l’autorité de certification, l’homologue auquel ils parlent peut être authentifié.
L’extrémité distante prouve qu’elle est “réellement” l’entité identifiée par le certificat en signant un bit de données à l’aide de sa propre clé privée. Seul le détenteur de la clé privée est en mesure de le faire, ce qui permet à l’extrémité distante de vérifier l’authenticité du système auquel elle est connectée.
