Infrastructure à clés publiques

Une infrastructure à clés publiques (en anglais Public Key Infrastructure, abrégé PKI) est un ensemble de composants matériels, logiciels, procédures et politiques permettant de créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques fondés sur la cryptographie asymétrique. Elle constitue le socle technique de la confiance numérique, en liant de façon vérifiable une identité à une paire de clés cryptographiques, l'une publique et librement distribuée, l'autre privée et gardée secrète par son titulaire. Introduite dans ses fondements théoriques par Whitfield Diffie et Martin Hellman en 1976, puis industrialisée à partir des années 1990 avec la standardisation du format X.509 et le déploiement du Web, la PKI est aujourd'hui le mécanisme de confiance numérique le plus largement déployé dans les réseaux mondiaux.

Principes fondamentaux

Cryptographie asymétrique

Une PKI repose sur la cryptographie asymétrique, où chaque entité dispose d'une paire de clés mathématiquement liées. Un message chiffré avec la clé publique d'un destinataire ne peut être déchiffré qu'avec sa clé privée correspondante ; inversement, une Signature numérique produite avec une clé privée peut être vérifiée par quiconque possède la clé publique associée.

Ce mécanisme résout le problème de l'échange de clés en milieu non sécurisé : deux parties n'ayant jamais communiqué peuvent établir un canal chiffré sans partager préalablement un secret commun. Les algorithmes les plus utilisés sont RSA (clés de 2 048 à 4 096 bits), l'algorithme de signature sur courbes elliptiques ECDSA, et Ed25519, ce dernier offrant un niveau de sécurité équivalent à RSA-3072 pour des clés de seulement 256 bits. Le Hachage cryptographique est également central : les signatures numériques portent sur l'empreinte du message plutôt que sur son contenu brut, ce qui garantit à la fois l'intégrité et la non-répudiation.

Liaison identité-clé

La valeur d'une PKI réside dans sa capacité à garantir qu'une clé publique appartient bien à l'entité qui prétend la détenir. Un Certificat numérique est un document électronique signé par une Autorité de certification qui atteste formellement de cette liaison. Sans ce mécanisme, rien n'empêche une attaque par interposition (man-in-the-middle) : un attaquant pourrait substituer sa propre clé publique à celle du correspondant légitime, déchiffrant silencieusement les communications sans qu'aucune des deux parties ne le détecte.

Composants d'une PKI

Autorité de certification

L'Autorité de certification (AC, ou CA pour Certification Authority) est la pièce centrale d'une PKI. Elle signe les certificats numériques après avoir vérifié l'identité du demandeur, engageant ainsi sa crédibilité sur la validité de la liaison clé-identité. On distingue :

les AC racines (root CA), dont les certificats auto-signés sont préinstallés dans les navigateurs et systèmes d'exploitation ;
les AC intermédiaires (intermediate CA), subordonnées à une AC racine, utilisées pour émettre les certificats d'entité finale, limitant l'exposition de la clé racine.

Les principales AC commerciales mondiales — IdenTrust, DigiCert, Sectigo, GlobalSign et Let's Encrypt — représentent ensemble plus de 90 % des certificats TLS actifs sur Internet selon les données SSL Pulse (2024). Let's Encrypt, opérée par l'Internet Security Research Group (ISRG) depuis 2016, avait émis plus de 4 milliards de certificats cumulés en 2024, rendant le déploiement HTTPS accessible gratuitement et par automatisation complète.

Autorité d'enregistrement

L'autorité d'enregistrement (AE, ou RA pour Registration Authority) est l'entité chargée de vérifier l'identité des demandeurs avant de transmettre la demande de certification à l'AC. Cette séparation des responsabilités permet une délégation géographique ou organisationnelle de la vérification d'identité tout en maintenant la signature centralisée auprès de l'AC. Dans les PKI d'entreprise, la RA est souvent intégrée à l'annuaire Active Directory ou au système de Gestion des identités et des accès.

Référentiel et distribution des certificats

Les certificats émis sont publiés dans un référentiel accessible publiquement, historiquement via des annuaires LDAP (port 389) ou des serveurs HTTP. Ce référentiel permet à quiconque de récupérer la clé publique d'une entité et de vérifier la chaîne de certification jusqu'à une AC racine de confiance. Les standards modernes privilégient la distribution par URI intégrée dans les certificats eux-mêmes via le champ AIA (Authority Information Access).

Révocation des certificats

Un certificat peut être révoqué avant son expiration en cas de compromission de la clé privée, de changement d'identité ou de cessation d'activité. Deux mécanismes coexistent :

la Liste de révocation de certificats (CRL, Certificate Revocation List) : liste signée publiée périodiquement par l'AC, contenant les numéros de série des certificats révoqués et le motif de révocation ;
l'OCSP (Online Certificate Status Protocol, RFC 6960) : service en temps réel permettant de vérifier le statut d'un certificat individuel sans télécharger la CRL complète.

L'extension OCSP Stapling (RFC 6066) permet au serveur TLS d'intégrer directement la réponse OCSP dans le handshake, améliorant les performances et évitant la fuite d'informations de navigation vers l'AC.

Certificats numériques

Standard X.509

Le format de référence des certificats PKI est X.509, défini par l'UIT-T et précisé pour les PKI Internet dans la RFC 5280. Un certificat X.509 version 3 contient les champs suivants :

Champ	Contenu
Version	Numéro de version X.509 (v1, v2, v3)
Numéro de série	Identifiant unique attribué par l'AC (entier de 20 octets maximum selon RFC 5280)
Algorithme de signature	Exemple : sha256WithRSAEncryption, ecdsa-with-SHA384
Émetteur (Issuer)	Nom distingué (DN) de l'AC signataire
Validité	Dates NotBefore et NotAfter (format UTCTime ou GeneralizedTime)
Sujet (Subject)	Nom distingué de l'entité certifiée
Clé publique	Algorithme et valeur de la clé publique du sujet
Extensions	Usages de clé, Subject Alternative Names (SAN), contraintes de base, AIA

La version 3 (1996) introduit les extensions, permettant de définir les usages autorisés d'un certificat (signature de code, authentification client/serveur, chiffrement de messagerie) et les noms alternatifs du sujet (SAN), qui ont remplacé le champ CommonName pour l'identification des domaines depuis 2017.

Types de certificats TLS

Les certificats TLS/SSL se déclinent en trois niveaux de validation définis par le CA/Browser Forum :

DV (Domain Validation) : vérification automatisée du contrôle du domaine uniquement, délivré en quelques secondes à quelques minutes ;
OV (Organization Validation) : vérification supplémentaire de l'existence juridique de l'organisation, délai de 1 à 3 jours ouvrés ;
EV (Extended Validation) : vérification approfondie selon les Baseline Requirements du CA/Browser Forum, avec contrôle physique, légal et opérationnel de l'organisation ; les navigateurs ont progressivement supprimé l'affichage visuel distinctif entre 2019 et 2021.

D'autres catégories existent selon les usages : certificats S/MIME pour la messagerie chiffrée, certificats de signature de code, certificats d'authentification client, et certificats qualifiés au sens du règlement eIDAS.

Cycle de vie

Le cycle de vie d'un certificat comprend : la génération de la paire de clés (idéalement dans un HSM), la création d'une demande de signature de certificat (CSR, format PKCS#10), la vérification d'identité par l'AC ou l'AE, l'émission du certificat, son déploiement, son renouvellement avant expiration, et sa révocation le cas échéant. Le CA/Browser Forum a voté en 2023 une réduction progressive des durées maximales de validité des certificats TLS publics à 47 jours d'ici 2027, contre 398 jours actuellement, rendant l'automatisation du renouvellement quasi-obligatoire.

Hiérarchie et modèles de confiance

Modèle hiérarchique

Le modèle le plus répandu est hiérarchique : une AC racine signe des AC intermédiaires, qui signent les certificats d'entité finale. La chaîne de certification (certificate chain) permet à un vérificateur de remonter jusqu'à une AC racine dont il accepte le certificat auto-signé. Les magasins de certificats racines (trust stores) maintenus par Mozilla, Microsoft, Apple et Google contenaient entre 130 et 200 AC racines reconnues en 2024.

Modèle en toile de confiance

Le modèle Web of Trust, popularisé par PGP (Pretty Good Privacy) depuis 1991, fonctionne sans AC centrale : les utilisateurs signent mutuellement leurs clés, créant un réseau décentralisé de certifications. Ce modèle, adapté aux communautés techniques resserrées (développeurs OpenPGP, communauté Debian), ne convient pas aux déploiements à grande échelle nécessitant une confiance institutionnelle formalisée.

PKI d'État et PKI d'entreprise

Les États déploient leurs propres PKI pour les besoins régaliens : cartes d'identité électroniques, passeports biométriques, signatures qualifiées et communications gouvernementales sécurisées. En France, l'ANSSI (Agence nationale de la sécurité des systèmes d'information) gère l'IGC/A (Infrastructure de Gestion de Clés / Authentification), AC racine de la PKI de l'État français, dont les certificats sont utilisés dans le cadre du RGS (Référentiel Général de Sécurité).

Les entreprises déploient des PKI internes (enterprise PKI ou private PKI) pour l'authentification des postes de travail (802.1X), des VPN, des serveurs internes et des appareils mobiles sous gestion MDM. Les solutions courantes incluent Microsoft Active Directory Certificate Services (AD CS), HashiCorp Vault PKI Secrets Engine et Smallstep CA.

Standards et protocoles associés

PKCS

Les Public Key Cryptography Standards (PKCS), publiés par RSA Laboratories à partir de 1991 et repris par l'IETF sous forme de RFC, définissent des formats interopérables pour les opérations PKI :

Standard	Description
PKCS#1 (RFC 8017)	Format des clés RSA et des opérations de chiffrement/signature RSA
PKCS#7 / CMS (RFC 5652)	Format des données signées et enveloppées ; utilisé par S/MIME
PKCS#10 (RFC 2986)	Format des demandes de signature de certificat (CSR)
PKCS#11	Interface API standard pour les modules cryptographiques matériels (HSM, cartes à puce)
PKCS#12 (RFC 7292)	Format de transport d'une paire clé privée + certificat (extensions .p12 / .pfx)

Protocole TLS

Le Protocole TLS (Transport Layer Security) est le principal consommateur de PKI sur Internet. Lors d'un handshake TLS 1.3 (RFC 8446, publié en 2018), le serveur présente son certificat, le client vérifie la chaîne de certification grâce à la PKI, puis les deux parties dérivent des clés de session éphémères via un échange Diffie-Hellman sur courbes elliptiques. La PKI assure uniquement l'authentification initiale ; le chiffrement des données de session repose sur des algorithmes symétriques (AES-128-GCM, ChaCha20-Poly1305).

Modules de sécurité matériels

Les HSM (Hardware Security Modules) sont des dispositifs certifiés (FIPS 140-2/3 niveau 3 ou 4, Common Criteria EAL4+) conçus pour générer et stocker les clés privées des AC dans un environnement inviolable. Leur utilisation est obligatoire pour les AC émettrices de certificats qualifiés au sens d'eIDAS. Les principaux fabricants sont Thales (anciennement Gemalto/SafeNet), Entrust nShield, Utimaco et Yubico. Un HSM de classe opérateur coûte entre 10 000 et 80 000 euros selon le niveau de certification et le débit cryptographique requis.

Applications et cas d'usage

Communications HTTPS

Le déploiement HTTPS repose intégralement sur la PKI publique. En 2024, Firefox enregistrait plus de 90 % du trafic web chiffré via HTTPS, contre moins de 40 % en 2015. Chaque connexion HTTPS implique une vérification automatique de la chaîne de certificats du serveur contre les AC racines du navigateur, un processus qui s'effectue en quelques millisecondes grâce aux optimisations OCSP Stapling et Certificate Transparency.

Messagerie sécurisée S/MIME

Le standard S/MIME (Secure/Multipurpose Internet Mail Extensions, RFC 8551) utilise des certificats X.509 pour la signature et le chiffrement des courriels. Il est déployé dans les environnements d'entreprise et les administrations pour garantir la confidentialité des échanges et la non-répudiation des messages signés, notamment dans les workflows contractuels et réglementés.

Authentification forte

La PKI est au cœur de mécanismes d'Authentification multifacteur et de Gestion des identités et des accès : cartes à puce conformes PIV (Personal Identity Verification, FIPS 201), passeports biométriques (ICAO 9303), et tokens FIDO2 avec resident keys basés sur des paires de clés asymétriques. Dans les architectures Modèle Zero Trust, chaque dispositif doit présenter un certificat valide émis par une PKI d'entreprise pour accéder aux ressources, complétant le contrôle d'identité de l'utilisateur.

Signature de code

Les éditeurs de logiciels signent leurs exécutables et packages avec des certificats de signature de code, permettant aux systèmes d'exploitation (Windows Authenticode, macOS Gatekeeper, Android APK signing v2/v3) de vérifier l'intégrité et l'origine du code avant son exécution. Cette pratique prévient la distribution de logiciels malveillants se faisant passer pour des logiciels légitimes, bien qu'elle ne soit pas infaillible en cas de vol ou de compromission d'un certificat de signature.

VPN et accès distant

Les solutions VPN d'entreprise — OpenVPN et WireGuard en mode mTLS, notamment — utilisent des certificats PKI pour l'authentification mutuelle (mTLS, mutual TLS) des clients et des serveurs, remplaçant les mots de passe partagés. La PKI permet une gestion centralisée et fine des accès : révoquer un certificat suffit à couper immédiatement l'accès d'un utilisateur ou d'un appareil compromis, sans modifier la configuration de chaque point de terminaison. Le Zero Trust Network Access généralise ce principe en exigeant un certificat client valide pour toute session réseau, indépendamment de la localisation.

Cadre réglementaire

eIDAS et eIDAS 2.0

Le règlement européen eIDAS (n° 910/2014, entré en vigueur le 1er juillet 2016) établit un cadre juridique harmonisé pour les signatures électroniques, les cachets électroniques, les horodatages et l'authentification des sites web dans les 27 États membres de l'Union européenne. Il définit trois niveaux de signature électronique :

Simple : données électroniques jointes à d'autres données à des fins d'authentification ;
Avancée : liée de manière unique au signataire, créée avec des données sous son contrôle exclusif, permettant d'identifier toute modification ultérieure ;
Qualifiée : signature avancée créée par un dispositif qualifié (QSCD, Qualified Signature Creation Device), reposant sur un certificat qualifié délivré par un prestataire de services de confiance qualifié (QTSP) inscrit sur la liste de confiance nationale.

La révision eIDAS 2.0 (règlement 2024/1183, adopté le 11 avril 2024) introduit le portefeuille européen d'identité numérique (EUDIW, European Digital Identity Wallet), reposant sur une PKI étendue qui permettra à chaque citoyen européen de disposer d'une identité numérique interopérable reconnue dans l'ensemble de l'Union. Le déploiement est prévu pour 2026.

RGS

En France, le RGS définit les exigences applicables aux téléservices des administrations françaises. Il prescrit les niveaux de signature électronique (RGS *1, *2, **) et les caractéristiques des certificats associés, en qualifiant les prestataires autorisés figurant sur la liste ANSSI des prestataires de certification électronique qualifiés. Les certificats RGS ** sont requis pour les actes administratifs les plus sensibles, notamment les marchés publics et les actes notariés dématérialisés.

RGPD, NIS2 et DORA

La conformité au RGPD (règlement 2016/679) impose de mettre en œuvre des mesures techniques appropriées pour protéger les données personnelles. La PKI contribue directement à cette obligation en garantissant la confidentialité des données en transit (TLS) et la non-répudiation des traitements (Signature numérique). Les clés privées constituent elles-mêmes des données sensibles : leur compromission peut constituer une violation à notifier à l'autorité de contrôle compétente dans les 72 heures.

La Directive NIS2 (2022/2555, transposée en droit français par la loi n° 2024-1334 du 20 décembre 2024) et le règlement DORA (2022/2554) imposent aux opérateurs de services essentiels et aux entités financières une Gestion des risques informatiques structurée, incluant le déploiement de PKI robustes pour sécuriser leurs communications et systèmes critiques. NIS2 prévoit des sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial annuel.

Gestion opérationnelle

Politique de certification

Toute PKI s'appuie sur deux documents de gouvernance fondamentaux :

la PC (Politique de Certification) : document public décrivant les pratiques, les obligations des parties, les niveaux de garantie offerts et les conditions d'utilisation des certificats ;
la DPC (Déclaration des Pratiques de Certification) : description technique et opérationnelle de l'implémentation — procédures de vérification d'identité, modes de stockage des clés, plans de continuité — souvent partiellement confidentielle.

Ces documents, publiés dans le référentiel de l'AC et structurés selon le cadre RFC 3647, font l'objet d'audits annuels (WebTrust pour les AC publiques, audits ISO/IEC 27001 pour les PKI d'entreprise).

Sécurité opérationnelle

La sécurité d'une PKI repose sur plusieurs couches complémentaires : cérémonie de clé filmée et notariée pour la génération des clés racines, stockage dans des HSM certifiés FIPS 140-3 niveau 3 minimum, contrôle d'accès physique aux locaux hébergeant l'AC racine (cage de Faraday, biométrie, règle des deux personnes), audits annuels WebTrust ou ETSI EN 319 411, et plans de reprise d'activité incluant des sauvegardes des clés privées dans des coffres géographiquement distribués, scellés par partage de secret selon le schéma de Shamir.

Le Système de management de la sécurité de l'information selon ISO/IEC 27001 constitue le cadre organisationnel naturel pour la gestion d'une PKI, via le contrôle A.8.24 (utilisation de la cryptographie) de l'annexe A de la version 2022.

Automatisation et DevOps

Le protocole ACME (Automatic Certificate Management Environment, RFC 8555), popularisé par Let's Encrypt, automatise l'émission et le renouvellement des certificats TLS par validation de domaine. Des outils comme Certbot, acme.sh ou cert-manager (Kubernetes) permettent un renouvellement sans intervention humaine. Cette automatisation devient critique avec la réduction des durées de validité : à 47 jours (horizon 2027), un certificat géré manuellement nécessiterait environ 8 interventions par an et par domaine, contre 1 à 2 actuellement.

Limites et risques

Compromission d'une autorité de certification

La compromission d'une AC peut avoir des conséquences systémiques : un attaquant maîtrisant la clé privée d'une AC peut émettre des certificats frauduleux pour n'importe quelle entité couverte par cette AC. Les incidents historiques notables incluent :

DigiNotar (août 2011) : compromission totale de l'AC néerlandaise, détection d'un certificat wildcard frauduleux pour *.google.com utilisé pour intercepter des communications en Iran, retrait de tous les trust stores en moins d'une semaine, faillite de l'entreprise en septembre 2011 ;
Comodo (mars 2011) : émission frauduleuse de 9 certificats, dont un pour mail.google.com, consécutive à la compromission d'un partenaire RA en Italie ;
ANSSI (décembre 2013) : utilisation abusive d'un certificat intermédiaire pour générer de faux certificats dans le cadre d'une inspection HTTPS d'entreprise.

Ces incidents ont conduit au développement de mécanismes de surveillance :

Certificate Transparency (CT, RFC 9162) : journalisation publique et auditée de tous les certificats émis dans des journaux immuables (logs), permettant de détecter les émissions frauduleuses ; obligatoire pour les certificats TLS publics depuis 2018 (Google Chrome) ;
CAA (Certification Authority Authorization, RFC 8659) : enregistrement DNS autorisant explicitement quelles AC peuvent émettre des certificats pour un domaine donné.

Menace post-quantique

Les algorithmes asymétriques actuels (RSA, ECDSA) reposent sur des problèmes mathématiques résolubles théoriquement par un ordinateur quantique suffisamment puissant via l'algorithme de Shor. La Gestion des vulnérabilités post-quantique constitue un défi structurel : le NIST a finalisé en août 2024 les premiers standards de cryptographie post-quantique (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). Les PKI devront migrer leurs infrastructures dans un horizon estimé à 5 à 15 ans, une migration d'une complexité comparable au passage à l'an 2000 ou à l'IPv6, nécessitant la mise à jour simultanée des AC, des clients, des applications et des HSM.

Gouvernance et concentration du marché

La sécurité d'une PKI est conditionnée à la fiabilité de l'ensemble des AC de la chaîne. La concentration du marché des AC publiques — les 5 premières contrôlent plus de 80 % des certificats TLS actifs — crée un risque systémique. Le CA/Browser Forum (CABF), réunissant navigateurs et AC, constitue le principal organe de gouvernance : il édicte les Baseline Requirements auxquels toutes les AC publiques doivent se conformer sous peine d'exclusion des trust stores. La durée de révocation d'une AC compromise, de quelques jours à une semaine, illustre la dépendance des infrastructures numériques mondiales envers ce mécanisme centralisé.

Formation et compétences

Les professionnels de la Cybersécurité amenés à déployer, exploiter ou auditer des PKI doivent maîtriser plusieurs domaines : cryptographie appliquée (algorithmes asymétriques, fonctions de hachage, courbes elliptiques), protocoles réseau (TLS, LDAP, OCSP), administration système (Windows Server AD CS, OpenSSL, HashiCorp Vault), et cadres réglementaires (eIDAS, RGS, RGPD).

Les certifications professionnelles reconnues dans ce domaine incluent le CISSP (ISC², domaine Cryptography), le CISM (ISACA), et les qualifications ANSSI : PASSI (Prestataires d'Audit de la Sécurité des Systèmes d'Information) pour les auditeurs, et PSCE (Prestataires de Services de Confiance Électronique) pour les opérateurs de PKI qualifiés au sens d'eIDAS.

Le Responsable de la sécurité des systèmes d'information (RSSI) d'une organisation est généralement responsable de la politique de certification et de la supervision des opérations PKI, en lien avec les équipes infrastructure et les auditeurs internes. Dans les organisations certifiées ISO/IEC 27001, la gestion de la PKI s'inscrit dans le périmètre du Système de management de la sécurité de l'information et fait l'objet d'une revue lors des audits de surveillance annuels.

Voir aussi