Infrastructure à clés publiques

Pour les articles homonymes, voir ICP, IGC et PKI.

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

Description de l'infrastructure à clés publiques

Rôle 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 œuvre, 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.

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 crée les certificats, et 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^[1], 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.

Les certificats numériques

Familles

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.

Nature et composition

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

Gestion

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.

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.

Scénario de fin de vie

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.

Précautions pour le déploiement

Certains experts^[Qui ?] pensent qu'aujourd'hui, dans un monde ouvert, il faut prendre certaines précautions avant de déployer une infrastructure à clés publiques, faute de quoi il y a des risques de pillage. Avant d'aborder les questions techniques, il faut par exemple se demander quels sont les utilisateurs, et si le cadre juridique est prêt.

Lorsque l'entreprise échange beaucoup de données avec des partenaires en extranet, comme c'est le cas des entreprises étendues ou des pôles de compétitivité, la question de la sécurisation de l'interopérabilité se pose.

Dans ces grandes communautés, l'information d'autorité doit être gérée dans des registres de métadonnées publics. Le certificat électronique peut alors être associé, dans le registre, à l'identifiant, afin de circonscrire le patrimoine informationnel partagé par la communauté de pratique^[2]

Par ailleurs, Il est conseillé de déployer les certificats sur support matériel (carte à puce) car le vol de certificat logiciel fait désormais partie des possibilités des maliciels.

Références

Voir aussi

Articles connexes

• Toile de confiance
• Cryptographie
• Signature numérique
• Chiffrement
• Certificat électronique
• Authentification forte
• Identité numérique (Internet)

Liens externes

Cet article ou cette section a trop de liens externes. Les liens externes doivent être des sites de référence dans le domaine du sujet. Il est souhaitable — si cela présente un intérêt — de citer ces liens comme source et de les enlever du corps de l'article ou de la section « Liens externes ».

Généralistes

• (en) IETF - Publications du groupe de travail PKIX
• (en) [PDF] University of Auckland - Tutoriel sur les PKI
• (en) [PDF] Cryptographie et PKI par Cédric Enzler et Sylvain Maret
• (en) [PDF] Training PKI par Cédric Enzler et Sylvain Maret

Autorités de certification

• (fr) Certigna
• (fr) Certigreffe
• (fr) Certinomis (filiale de La Poste)
• (fr) Chambersign France
• (fr) Dhimyotis, opérateur de certification normé
• (fr) Fast, tiers de confiance européen
• (fr) OpenTrust (ex Keynectis)

Solutions applicatives

• (fr) Cryptolog
• (en) EJBCA (Open source) (site officiel)
• (fr) MetaPKI
• (en) NewPKI (Open source)
• (en) OpenCA (Open source)
• (fr) OpenTrust
• (en) openWebPKI
• (en) Projets PKI sur Mozilla.Org (Open source)
• (fr) Rooster (Open source)
• (fr) Vulture-PKI (Open source)

• Portail de la cryptologie
• Portail de la sécurité informatique