ISCP

Une infrastructure à clé publique (PKI) est un ensemble de rôles, de politiques, de matériel, de logiciels et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques et gérer le chiffrement à clé publique.

L'objectif d'une PKI est de faciliter le transfert électronique sécurisé d'informations pour une gamme d'activités réseau telles que le commerce électronique, les services bancaires en ligne et les e-mails confidentiels. Elle est requise pour des activités où les simples mots de passe constituent une méthode d'authentification inadéquate et où des preuves plus rigoureuses sont nécessaires pour confirmer l'identité des parties impliquées dans la communication et pour valider les informations transférées.

Image : “ Public-Key-Infrastructure.svg ”, créée par Chris (Chrkl), sous licence Creative Commons Attribution–Partage dans les mêmes conditions 3.0 Unported (CC BY-SA 3.0). Source : https://commons.wikimedia.org/wiki/File:Public-Key-Infrastructure.svg(commons.wikimedia.org dans Bing)

En cryptographie, un PKI est un arrangement qui lie les clés publiques aux identités respectives des entités (comme les personnes et les organisations). La liaison est établie par un processus d'enregistrement et d'émission de certificats à et par une autorité de certification (AC). Selon le niveau d'assurance de la liaison, celle-ci peut être réalisée par un processus automatisé ou sous supervision humaine. Lorsqu'elle est effectuée sur un réseau, elle nécessite l'utilisation d'un protocole sécurisé d'inscription ou de gestion de certificats tel que le CMP.

Le rôle de l'ICP qui peut être délégué par une AC pour garantir un enregistrement valide et correct est appelé autorité d'enregistrement (AE). Une autorité d'enregistrement est chargée d'accepter les demandes de certificats numériques et d'authentifier l'entité qui fait la demande. Le RFC 3647 de l'Internet Engineering Task Force définit une AE comme “une entité responsable d'une ou de plusieurs des fonctions suivantes : l'identification et l'authentification des demandeurs de certificats, l'approbation ou le rejet des demandes de certificats, la révocation ou la suspension de certificats dans certaines circonstances, le traitement des demandes des abonnés visant à révoquer ou à suspendre leurs certificats, et l'approbation ou le rejet des demandes des abonnés visant à renouveler ou à recoder leurs certificats”. Les AE, cependant, ne signent ni ne délivrent de certificats (c'est-à-dire qu'une AE se voit déléguer certaines tâches au nom d'une AC)" Si Microsoft a pu désigner une AC subordonnée comme étant une AE, cela est incorrect selon les normes X.509 de l'ICP. Les AE n'ont pas le pouvoir de signature d'une AC et ne gèrent que l'approbation et l'approvisionnement des certificats. Ainsi, dans le cas de l'ICP Microsoft, la fonctionnalité d'AE est fournie soit par le site web Microsoft Certificate Services, soit par Active Directory Certificate Services, qui applique la politique de l'AC Microsoft Enterprise et des certificats par le biais de modèles de certificats et gère l'inscription des certificats (manuelle ou automatique). Dans le cas des AC autonomes de Microsoft, la fonction d'AE n'existe pas puisque toutes les procédures de contrôle de l'AC sont basées sur la procédure d'administration et d'accès associée au système hébergeant l'AC et à l'AC elle-même plutôt qu'à Active Directory. La plupart des solutions PKI commerciales non Microsoft offrent un composant RA autonome.

Une entité doit être identifiable de manière unique dans chaque domaine de CA sur la base d'informations relatives à cette entité. Une autorité de validation (VA) tierce peut fournir ces informations sur l'entité au nom de la CA.

La norme X.509 définit le format le plus couramment utilisé pour les certificats de clé publique.

Capacités

La PKI fournit des “ services de confiance ” – en termes simples, la confiance accordée aux actions ou aux résultats d'entités, qu'il s'agisse de personnes ou d'ordinateurs. Les objectifs des services de confiance respectent une ou plusieurs des capacités suivantes : Confidentialité, Intégrité et Authenticité (CIA).

Confidentialité : Garantie qu'aucune entité ne peut consulter malicieusement ou involontairement une charge utile en texte clair. Les données sont chiffrées pour les rendre secrètes, de sorte que même si elles sont lues, elles apparaissent comme du charabia. Le cas d'usage le plus courant de l'ICP à des fins de confidentialité est probablement dans le contexte de la sécurité de la couche de transport (TLS). Le TLS est une capacité qui sous-tend la sécurité des données en transit, c'est-à-dire pendant la transmission. Un exemple classique de TLS pour la confidentialité est l'utilisation d'un navigateur Web pour se connecter à un service hébergé sur un site Web sur Internet en entrant un mot de passe.

Intégrité : Assurance que si une entité modifiait (falsifiait) les données transmises de la moindre manière, il serait évident que cela s'est produit car son intégrité aurait été compromise. Souvent, il n'est pas de la plus haute importance d'empêcher la compromission de l'intégrité (inviolabilité), cependant, il est de la plus haute importance que si l'intégrité est compromise, il y ait des preuves claires que cela s'est produit (vraisemblance d'altération).

Authenticité : Garantie qu'une entité a : i) la certitude de ce à quoi elle se connecte ; et/ou ii) peut prouver sa propre légitimité lors de la connexion à un service protégé. Le premier est désigné comme authentification par certificat serveur, généralement utilisé lors de la connexion à un serveur web. Le second est désigné comme authentification par certificat client, par exemple utilisé lors de la connexion avec une carte à puce hébergeant un certificat numérique et une clé privée.

Conception

La cryptographie à clé publique est une technique cryptographique qui permet aux entités de communiquer en toute sécurité sur un réseau public non sécurisé, et de vérifier de manière fiable l'identité d'une entité via des signatures numériques.

Une infrastructure à clé publique (ICP) est un système pour la création, le stockage et la distribution de certificats numériques, qui sont utilisés pour vérifier qu'une clé publique particulière appartient à une certaine entité. L'ICP crée des certificats numériques qui associent des clés publiques à des entités, stocke ces certificats en toute sécurité dans un répertoire central et les révoque si nécessaire.

Une PKI se compose de :

• Une autorité de certification (AC), qui stocke, délivre et signe les certificats numériques ;

• Une autorité d'enregistrement (AE), qui vérifie l'identité des entités demandant que leurs certificats numériques soient stockés auprès de l'AC ;

• Un répertoire central, un emplacement sécurisé dans lequel sont stockées et indexées les clés ;

• Un système de gestion de certificats, qui gère des aspects tels que l'accès aux certificats stockés ou la délivrance des certificats à émettre ;

• Une politique de certificat, qui énonce les exigences de l'IS P concernant ses procédures. Son but est de permettre à des tiers d'analyser la trustworthiness de l'IS P.

Méthodes de certification

Autorités de certification

Article principal : Autorité de certification

Le rôle principal de l'AC est de signer numériquement et de publier la clé publique associée à un utilisateur donné. Ceci est fait en utilisant la propre clé privée de l'AC, de sorte que la confiance dans la clé de l'utilisateur repose sur la confiance dans la validité de la clé de l'AC. Lorsque l'AC est une tierce partie distincte de l'utilisateur et du système, elle est alors appelée l'Autorité d'Enregistrement (AR), qui peut ou non être distincte de l'AC. La liaison clé-utilisateur est établie, en fonction du niveau d'assurance de cette liaison, par logiciel ou sous supervision humaine.

Le terme tiers de confiance (TTP) peut également être utilisé pour autorité de certification (AC). De plus, l'infrastructure à clé publique (PKI) est souvent utilisée elle-même comme synonyme d'implémentation d'une AC.

Révocation du certificat

Article principal : Révocation de certificat

Un certificat peut être révoqué avant son expiration, ce qui indique qu'il n'est plus valide. Sans révocation, un attaquant pourrait exploiter un tel certificat compromis ou mal émis jusqu'à son expiration. Par conséquent, la révocation est une partie importante d'une infrastructure à clé publique. La révocation est effectuée par l'autorité de certification émettrice, qui produit une déclaration de révocation authentifiée cryptographiquement.

Pour distribuer les informations de révocation aux clients, la rapidité de la découverte de la révocation (et donc la fenêtre de tir permettant à un attaquant d'exploiter un certificat compromis) est en compromis avec les ressources nécessaires pour interroger les statuts de révocation et les préoccupations relatives à la vie privée. Si les informations de révocation ne sont pas disponibles (soit en raison d'un accident, soit d'une attaque), les clients doivent décider s'ils doivent être rigoureusement failsafe et traiter un certificat comme s'il était révoqué (diminuant ainsi la disponibilité) ou s'ils doivent être souples et le traiter comme non révoqué (permettant aux attaquants de contourner la révocation).

En raison du coût des vérifications de révocation et de l'impact sur la disponibilité des services distants potentiellement peu fiables, les navigateurs Web limitent les vérifications de révocation qu'ils effectuent et agissent avec flexibilité en cas d'échec. Les listes de révocation de certificats sont trop coûteuses en bande passante pour une utilisation routinière, et le protocole de statut de certificat en ligne présente des problèmes de latence de connexion et de confidentialité. D'autres méthodes ont été proposées mais n'ont pas encore été déployées avec succès pour permettre une vérification stricte en cas d'échec.

Part de marché de l'émetteur

Dans ce modèle de relations de confiance, une AC est une tierce partie de confiance – de confiance à la fois pour le sujet (propriétaire) du certificat et pour la partie qui s'appuie sur le certificat.

Selon le rapport NetCraft de 2015, la norme de l'industrie pour la surveillance des certificats TLS (Transport Layer Security) actifs, indique que “ Bien que l'écosystème mondial [TLS] soit concurrentiel, il est dominé par une poignée de grandes AC — trois autorités de certification (Symantec, Sectigo, GoDaddy) représentent les trois quarts de tous les certificats [TLS] émis sur les serveurs web publics. La première place a été occupée par Symantec (ou VeriSign avant son rachat par Symantec) depuis le début de [notre] enquête, car elle représente actuellement un peu moins d'un tiers de tous les certificats. Pour illustrer l'effet des différentes méthodologies, parmi le million de sites les plus fréquentés, Symantec a émis 44% des certificats valides et approuvés en usage — nettement plus que sa part de marché globale. ”

Suite à des problèmes majeurs dans la gestion de l'émission de certificats, tous les acteurs majeurs se sont progressivement méfiés des certificats émis par Symantec, à partir de 2017 et ce, jusqu'en 2021.

Certificats temporaires et authentification unique

Cette approche implique un serveur qui agit comme une autorité de certification hors ligne dans un système d'authentification unique. Un serveur d'authentification unique émettra des certificats numériques dans le système client, mais ne les stockera jamais. Les utilisateurs peuvent exécuter des programmes, etc. avec le certificat temporaire. Il est courant de trouver cette variante de solution avec des certificats basés sur X.509.

À partir de septembre 2020, la validité des certificats TLS a été réduite à 13 mois.

Web de confiance

Article principal : Web de confiance

Une approche alternative au problème de l'authentification publique des informations de clé publique est le système de “toile de confiance” (web-of-trust), qui utilise des certificats auto-signés et des attestations par des tiers de ces certificats. Le terme singulier “toile de confiance” n'implique pas l'existence d'une seule toile de confiance, ou d'un point de confiance commun, mais plutôt une parmi un nombre quelconque de "toiles de confiance" potentiellement disjointes. Des exemples d'implémentations de cette approche sont PGP (Pretty Good Privacy) et GnuPG (une implémentation d'OpenPGP, la spécification standardisée de PGP). Parce que PGP et ses implémentations permettent l'utilisation de signatures numériques par e-mail pour la publication automatique d'informations de clé publique, il est relativement facile de mettre en œuvre sa propre toile de confiance.

L'un des avantages du web de confiance, comme dans PGP, est qu'il peut interopérer avec une PKI gérée par une autorité de certification (AC) entièrement approuvée par toutes les parties d'un domaine (comme une AC interne d'une entreprise) et prête à garantir les certificats, en tant qu'introducteur de confiance. Si le “web de confiance” est entièrement approuvé, alors, en raison de la nature d'un web de confiance, approuver un certificat revient à approuver tous les certificats de ce web. Une PKI n'a de valeur que par les normes et les pratiques qui régissent l'émission des certificats, et l'inclusion de PGP ou d'un web de confiance personnel pourrait considérablement réduire la fiabilité de la mise en œuvre de la PKI de cette entreprise ou de ce domaine.

Le concept de toile de confiance a été proposé pour la première fois par le créateur de PGP, Phil Zimmermann, en 1992 dans le manuel de PGP version 2.0 :

Au fil du temps, vous accumulerez des clés d'autres personnes que vous pourriez vouloir désigner comme introducteurs de confiance. Tous les autres choisiront leurs propres introducteurs de confiance. Et chacun accumulera et distribuera progressivement avec sa clé une collection de signatures certifiées d'autres personnes, avec l'attente que quiconque la recevra fera confiance à au moins une ou deux des signatures. Cela provoquera l'émergence d'une toile de confiance décentralisée et tolérante aux pannes pour toutes les clés publiques.

Infrastructure à clé publique simple

Article principal : Infrastructure à clé publique simple

Une autre alternative, qui ne traite pas de l'authentification publique des informations de clé publique, est l'infrastructure à clé publique simple (SPKI), qui est née de trois efforts indépendents pour surmonter la complexité de X.509 et du web de confiance de PGP. La SPKI n'associe pas les utilisateurs à des personnes, car c'est la clé qui est fiable, plutôt que la personne. La SPKI n'utilise aucune notion de confiance, car le vérificateur est aussi l'émetteur. Ceci est appelé une “boucle d'autorisation” dans la terminologie SPKI, où l'autorisation fait partie intégrante de sa conception. Ce type d'ICP est particulièrement utile pour réaliser des intégrations d'ICP qui ne dépendent pas de tiers pour l'autorisation des certificats, les informations sur les certificats, etc. ; un bon exemple est un réseau isolé dans un bureau.

Infrastructure à clés publiques décentralisée

Les identifiants décentralisés (DID) éliminent la dépendance vis-à-vis des registres centralisés pour les identifiants ainsi que des autorités de certification centralisées pour la gestion des clés, ce qui est la norme en PKI hiérarchique. Dans les cas où le registre de DID est un grand livre distribué, chaque entité peut servir sa propre autorité racine. Cette architecture est appelée PKI décentralisée (DPKI).

Histoire

Les développements en matière d'ICP ont eu lieu au début des années 1970 au sein de l'agence de renseignement britannique GCHQ, où James Ellis, Clifford Cocks et d'autres ont fait des découvertes importantes liées aux algorithmes de chiffrement et à la distribution de clés. Étant donné que les développements au GCHQ sont hautement classifiés, les résultats de ces travaux ont été gardés secrets et n'ont été reconnus publiquement que vers le milieu des années 1990.

La divulgation publique des algorithmes d'échange de clés sécurisé et de clés asymétriques en 1976 par Diffie, Hellman, Rivest, Shamir et Adleman a radicalement changé les communications sécurisées. Avec le développement continu des communications électroniques numériques à haute vitesse (Internet et ses prédécesseurs), un besoin est apparu pour des moyens par lesquels les utilisateurs pourraient communiquer de manière sécurisée entre eux, et par conséquent, pour des moyens par lesquels les utilisateurs pourraient s'assurer de l'identité de la personne avec qui ils interagissaient réellement.

Divers protocoles cryptographiques ont été inventés et analysés dans lesquels de nouvelles primitives cryptographiques pouvaient être utilisées efficacement. Avec l'invention du World Wide Web et sa diffusion rapide, le besoin d'authentification et de communication sécurisée est devenu encore plus aigu. Les raisons commerciales seules (par exemple, le commerce électronique, l'accès en ligne à des bases de données propriétaires depuis des navigateurs Web) étaient suffisantes. Taher Elgamal et d'autres chez Netscape ont développé le protocole SSL (‘ https ’ dans les URL Web) ; il comprenait l'établissement de clés, l'authentification du serveur (avant la v3, unidirectionnelle uniquement), etc. Une structure PKI a ainsi été créée pour les utilisateurs/sites Web souhaitant des communications sécurisées.

Les fournisseurs et les entrepreneurs ont vu la possibilité d'un vaste marché, ont créé des entreprises (ou de nouveaux projets au sein d'entreprises existantes) et ont commencé à demander une reconnaissance légale et une protection contre la responsabilité. Un projet technologique de l'American Bar Association a publié une analyse approfondie de certains aspects juridiques prévisibles des opérations de PKI (voir les directives de l'ABA sur la signature numérique) et peu de temps après, plusieurs États américains (l'Utah étant le premier en 1995) et d'autres juridictions dans le monde ont commencé à promulguer des lois et à adopter des réglementations. Les groupes de consommateurs ont soulevé des questions concernant la vie privée, l'accès et la responsabilité, qui ont été davantage prises en compte dans certaines juridictions que dans d'autres.

Les lois et réglementations promulguées différaient, il y avait des problèmes techniques et opérationnels dans la conversion des systèmes d'infrastructure à clé publique (ICP) en opérations commerciales réussies, et les progrès ont été beaucoup plus lents que ce qu'avaient imaginé les pionniers.

Au cours des premières années du 21e siècle, il était clairement difficile de déployer correctement l'ingénierie cryptographique sous-jacente. Les procédures d'exploitation (manuelles ou automatiques) n'étaient pas faciles à concevoir correctement (ni, même si elles étaient conçues ainsi, à exécuter parfaitement, ce que nécessitait l'ingénierie). Les normes existantes étaient insuffisantes.

Les fournisseurs de PKI ont trouvé un marché, mais ce n'est pas tout à fait le marché envisagé au milieu des années 1990, et il s'est développé plus lentement et d'une manière quelque peu différente de ce qui était anticipé. Les PKI n'ont pas résolu certains des problèmes attendus, et plusieurs fournisseurs majeurs ont cessé leurs activités ou ont été rachetés par d'autres. La PKI a connu le plus de succès dans les implémentations gouvernementales ; la plus grande implémentation PKI à ce jour est l'infrastructure PKI de la Defense Information Systems Agency (DISA) pour le programme de cartes d'accès communes.

Utilisations

Les PKI d'un type ou d'un autre, et provenant de plusieurs fournisseurs, ont de nombreuses utilisations, notamment la fourniture de clés publiques et de liens avec les identités des utilisateurs, qui sont utilisés pour :

Chiffrement et/ou authentification de l'expéditeur des messages électroniques (par exemple, en utilisant OpenPGP ou S/MIME) ;

Chiffrement et/ou authentification de documents (par exemple, les normes de signature XML ou de chiffrement XML si les documents sont encodés en XML) ;

Authentification des utilisateurs aux applications (par exemple, connexion par carte à puce, authentification client avec SSL/TLS). Il existe une utilisation expérimentale pour l'authentification HTTP signée numériquement dans les projets Enigform et mod_openpgp ;

Démarrage de protocoles de communication sécurisée, tels que Internet Key Exchange (IKE) et SSL/TLS. Dans les deux cas, la configuration initiale d'un canal sécurisé (une “ association de sécurité ”) utilise des méthodes à clé asymétrique, c'est-à-dire à clé publique, tandis que la communication réelle utilise des méthodes plus rapides à clé symétrique, c'est-à-dire à clé secrète ;

Les signatures mobiles sont des signatures électroniques créées à l'aide d'un appareil mobile et qui reposent sur des services de signature ou de certification dans un environnement de télécommunication indépendant de la localisation ;

L'Internet des objets nécessite une communication sécurisée entre des appareils mutuellement fiables. Une infrastructure à clé publique permet aux appareils d'obtenir et de renouveler des certificats X.509, qui sont utilisés pour établir la confiance entre les appareils et chiffrer les communications à l'aide de TLS.

Implémentations open source

OpenSSL est la forme la plus simple de CA et un outil pour l'infrastructure à clé publique (PKI). C'est une boîte à outils, développée en C, qui est incluse dans toutes les principales distributions Linux et peut être utilisée à la fois pour construire votre propre CA (simple) et pour activer la PKI pour les applications. (Licence Apache)

EJBCA est une implémentation de CA complète, de qualité professionnelle, développée en Java. Elle peut être utilisée pour mettre en place une CA aussi bien pour un usage interne que comme service. (Licence LGPL)

XiPKI, CA et répondant OCSP. Avec prise en charge de SHA-3, implémenté en Java. (Licence Apache)

XCA est une interface graphique et une base de données. XCA utilise OpenSSL pour les opérations PKI sous-jacentes.

DogTag est une CA complète, développée et maintenue dans le cadre du projet Fedora.

CFSSL, une boîte à outils open source développée par CloudFlare pour signer, vérifier et regrouper des certificats TLS. (Licence BSD 2-clause)

Vault, outil de gestion sécurisée des secrets (y compris les certificats TLS) développé par HashiCorp. (Licence Mozilla Public License 2.0)

Boulder, une ACME CA écrite en Go. Boulder est le logiciel qui fait fonctionner Let’s Encrypt.

Critique

Voir aussi : X.509 § Sécurité, Comodo Group § Incident de violation de données de 2011, et Diginotar § Émission de certificats frauduleux

Certains soutiennent que l'achat de certificats pour sécuriser les sites web par SSL/TLS et les logiciels par signature de code est une entreprise coûteuse pour les petites entreprises. Cependant, l'émergence d'alternatives gratuites, telles que Let's Encrypt, a changé la donne. HTTP/2, la dernière version du protocole HTTP, permet en théorie des connexions non sécurisées ; en pratique, les principales sociétés de navigateurs ont clairement indiqué qu'elles ne prendraient en charge ce protocole qu'en connexion TLS sécurisée par PKI. L'implémentation du protocole HTTP/2 dans les navigateurs web, y compris Chrome, Firefox, Opera et Edge, ne prend en charge HTTP/2 qu'en TLS en utilisant l'extension ALPN du protocole TLS. Cela signifierait que, pour bénéficier des avantages de vitesse de HTTP/2, les propriétaires de sites web seraient contraints d'acheter des certificats SSL/TLS contrôlés par des entreprises.

Actuellement, la majorité des navigateurs web sont livrés avec des certificats intermédiaires préinstallés, émis et signés par une autorité de certification, par des clés publiques certifiées par des certificats dits racines. Cela signifie que les navigateurs doivent contenir un grand nombre de fournisseurs de certificats différents, augmentant ainsi le risque de compromission d'une clé.

Lorsqu'une clé est connue pour être compromise, elle peut être corrigée en révoquant le certificat, mais une telle compromission n'est pas facilement détectable et peut constituer une faille de sécurité majeure. Les navigateurs doivent publier un correctif de sécurité pour révoquer les certificats intermédiaires émis par une autorité de certification racine compromise.

Basé sur l'article Wikipédia “ Infrastructure à clé publique ”, disponible sous la licence Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). Source : https://en.wikipedia.org/wiki/Public_key_infrastructure