Les PKI

Généralités :

Suite à l’invention de la cryptographie à clés publiques, qui permettait de s’affranchir du problème de la distribution et de la gestion des clés symétriques, s’est posé le problème de la gestion des paires de clés.

J’ai des amis qui ont d’énormes trousseaux de clés (des vraies, en métal), et j’ai pu constater que c’est tout un art de bien les gérer : se souvenir laquelle correspond à quelle serrure, faire en sorte que le trousseau ne déchire pas les poches, être en bons termes avec son serrurier, avoir des doubles pour les refaire en cas de perte, ne pas les oublier dans un bar au petit matin... etc.

La notion de PKI (ICP, Infrastructure à Clés Publiques en français) prend tout son sens quand les clés (numériques) sont encapsulées dans des certificats.

Avant de poursuivre, une remarque, mais d’importance :
La mode est à la PKI.
C’était très vrai lorsque j’ai mis cette page en ligne en juillet 2000, ça l’est un peu moins aujourd’hui, en mars 2002. La mode est un peu tombée (je mesure l’intensité de la mode à la fréquence des articles sur le sujet parus dans des revues généralistes et au nombre de pilotes mis en place) ; les solutions ont aussi gagné en maturité et de vrais projets PKI commencent doucement à passer en production.

Pour en revenir aux modes, il en apparaît régulièrement en sécurité logique, dont l’objet est sensé résoudre tout les problèmes (il y eut les firewalls, le single sign-on, l’authentification par calculette, la carte à puce...) et initiées par certaines compagnies ou boites de conseil qui confondent souvent études techniques et marketing.
Il y a deux conclusions à en tirer :
Mettre en place une PKI n’apportera pas LA sécurité idéale.
Une PKI n’est pas forcément LA meilleure solution pour une situation donnée (tout comme la mise en place d’infrastructures de signature électronique sécurisée au sens des décrets n’est pas toujours nécessaire).

Il y a en gros deux modèles de PKI :

Le premier est celui dit ouvert, le plus connu et répandu. Ce sont les AC (Autorité de Certification, ou Emetteurs de Certificats) qui vendent des certificats et en assurent une certaine gestion. Dans ce cas, les clients PKI sont principalement les navigateurs (et serveurs Web associés), et on peut avoir une liste d’AC existantes en allant regarder les clés publiques de ces AC dans nos navigateurs.
Dans ce cas, les principales applications concrètes, pour ne pas dire uniques, des certificats sont SSL et S/MIME (sécurisation des transactions http et des courriels).
Les restrictions à l’export des US en matière de crypto brident les taillent de clés des navigateurs actuels (SSL 40 bits au lieu de 128 par exemple, à moins de l’augmenter sois-même. Ce n’est maintenant plus vrai en 2002), quand il n’y a pas des soupçons sur la conception de certains logiciels ou OS.
A strictement parler, ce modèle n’est en fait qu’une AC (Certification Authority en anglais) et pas vraiment une PKI, puisqu’elle ne prend pas en charge beaucoup des points listés plus bas.

Le deuxième modèle, proposé par quelques éditeurs spécialisés en sécurité et par quelques solutions OpenSource, consiste en un logiciel que l’on installe au centre du réseau d’une communauté d’utilisateurs. Contrairement au cas précédent, les administrateurs ont vraiment la main sur la gestion des clés.
De plus, les clients peuvent avoir dans ce cas beaucoup plus de fonctionnalités PKI que les navigateurs, puisqu’ils sont conçus à cet effet, et l’on peut plus facilement avoir de la crypto fiable... Le fait que les sources de la plupart des logiciels de crypto commerciaux ne soient pas disponibles marque cependant d’une tache d’ombre ce qui devrait être limpide...

Une PKI c’est un service de base, la gestion de certificats, plus un certain nombre d’autres services qui peuvent faciliter la vie des utilisateurs et des administrateurs, leur permettre d’utiliser au mieux les clés contenues dans les certificats et, biensûr, qui augmentent la sécurité du système.
Autrement dit, une PKI, c’est une AC plus d’autres fonctionnalités. Ca ne veut pas dire grand chose, mais c’est normal, c’est un concept :-)

Il y a cependant des RFC qui définissent les protocoles de gestion de certificats dans le cadre d’une PKI (celles du groupe PKIX) : une des plus importantes est la RFC 2510
Ce qui signifie bien que même les PKI sont en voie de standardisation, ce qui pourra à l’avenir améliorer l’interopérabilité entre PKI (quoique entre un standard et son implémentation... mais ceci est une autre histoire).

Quid de ce que fait une PKI :

Les PKI (l’ensemble client/serveur) devraient permettre de traiter les points suivants (d’un point de vue technique et non uniquement marketing) :

Etablissement d’une confiance commune à un groupe d’utilisateurs munis de certificats
Mise en pratique des politiques de certification
Enregistrement des utilisateurs
Génération des clés (optionnel)
Certification des clés publiques
Gestion de la durée de vie des certificats et des clés
Archivage des certificats
Renouvellement des clés et des certificats
Recouvrement des clés de chiffrement (optionnel)
Publication et accessibilité des certificats (ce point ne relève pas à strictement parler de la PKI, et est en général assuré par des annuaires)
Vérification des certificats et des signatures
Révocation des certificats (CRL : Liste de Certificats Révoqués)
Gestion des co-certificats
Horodatage
Journalisation

Selon les modèles de PKI et les implémentations concrètes des logiciels, les points précédents ne seront pas tous pris en charge.

Etablissement d’une confiance commune à un groupe de certificats :

C’est le propre d’une PKI. En signant des certificats qui contiennent une clé publique elle permet d’établir une confiance entre des utilisateurs ne se connaissant pas (en parlant d’utilisateurs, il peut tout aussi bien s’agir de personnes physiques que de dispositifs matériels comme des VPN ou de logiciels comme des firewalls). La signature se fait en passant toutes les données au travers d’une fonction de hachage et en chiffrant le résultat à l’aide de la clé privée de signature de l’AC.

Mise en pratique des politiques de certification :

Les politiques de certification (PC en français définissent les domaines d’application des certificats ainsi que les procédures selon lesquelles les certificats sont générés et gérés. Elle permettent entre autres d’étendre le lien de confiance jusqu’à l’utilisateur final (la procédure de délivrance de tel certificat est digne de confiance, parce que l’émetteur de certificats demande une pièce d’identité pour générer un certificat par exemple).
L’équivalent dans le système PGP, à la différence qu’il n’y a pas de tiers commun à qui l’on fait confiance est : " je fais confiance à telle clef publique parce que telle personne en qui j’ai entièrement confiance lui fait confiance ".
A la PC est en général jointe une DPC (Déclaration des Pratiques de Certification, CPS (Certificate Policy Statement en anglais) qui est un document qui détermine les moyens précis mis en oeuvre pour satisfaire aux exigences définies dans la PC.
Il existe en France deux PC de référence :

— La PC Type du MINEFI (qui en est à la troisième version)
— La PC2 de la DCSSI

Enregistrement des utilisateurs :

Dans une architecture PKI c’est en général un composant logiciel (RA, Registration Authority ou AE, Autorité d’Enregistrement) séparé de celui qui va effectivement faire la génération des certificats. Ce module permet de valider un enregistrement avant de générer le certificat, d’enregistrer les utilisateurs, d’être l’interface de révocation... etc.

Génération des clés :

Il y a en gros deux sous-modèles de PKI : ceux qui utilisent une seule paire de clé pour le chiffrement et la signature, et ceux qui séparent ces deux fonctionnalités en donnant à chaque utilisateur deux paires de clés (ou plus). L’une par exemple pour le chiffrement, l’autre pour la signature. Eventuellement d’autres pour l’authentification (ou des certificats d’attribut, de courte durée de vie).

Une seule paire de clé :
Dans ce cas, celui des simples AC qui vendent des certificats par exemple, la paire de clés est générée sur le poste client de l’utilisateur qui veut un certificat, la clé privée est stockée localement (chiffrée avec une clé dérivée d’un mot de passe) et la clé publique est envoyée au serveur de certificats pour qu’il la certifie.

Deux paires de clés :
C’est dans ce cas que le concept de PKI commence à prendre du sens. S’il y deux paires de clés, c’est parce que celle privée de chiffrement doit éventuellement pouvoir être recouvrée (pour que toutes les données chiffrées d’un utilisateur ne soient pas définitivement perdues suite à un oubli de mot de passe ou une altération de la clé) et donc sauvegardée sur le serveur, et que la clé privée de signature doit, elle, rester rigoureusement en possession de l’utilisateur, ce qui est incompatible.
Voir la section "Recouvrement des clés de chiffrement symétriques" pour plus de précisions et les risques de cette procédure.
La paire de clés de chiffrement peut donc être générée sur le serveur. La clé privée sauvegardée est ensuite envoyée de façon sûre à l’utilisateur, la clé publique certifiée, et envoyée à l’utilisateur. Le certificat est posté dans un annuaire et envoyé à l’utilisateur.
La paire de clés de signature est générée chez le client, la clé publique envoyée au serveur pour certification et la clé privée gardée rigoureusement secrète. Le certificat de signature est ensuite renvoyé à l’utilisateur.

Certification des clés publiques :

Une PKI génère ou reçoit une clé publique et la certifie : elle génère un certificat contenant la clé publique et signe le tout avec sa clé privée de signature. Dans le cas ou elle reçoit la clé de la part de l’utilisateur, il doit exister une procédure pour en assurer l’authenticité et l’intégrité. Ce peut être un secret partagé généré au préalable et envoyé à l’utilisateur par un canal sûr (enveloppe cachetée, de la main à la main, par pigeon voyageur...).
Lorsqu’un utilisateur envoie une clé publique à certifier, c’est en général au format PKCS#10 (format pour la requête de certificats).
La PKI doit assurer que sa clé privée de signature demeure rigoureusement secrète : il existe des dispositifs matériels externes au serveur qui prennent en charge la génération de cette clé et les opérations de signature. Ces dispositifs peuvent en outre offrir la possibilité de sauvegarder la clé racine de l’AC (ou les clés).

Gestion de la durée de vie des certificats et des clés :

Les clés (privées et publiques) doivent avoir une durée de vie limitée, ainsi que les certificats associés. Accorder une durée de vie illimitée à une paire de clés peut permettre à un attaquant de se lancer dans une recherche exhaustive de longue durée, avec une quantité toujours croissante de textes chiffrés à analyser. De plus, si une clé est compromise, ce sont toutes le données chiffrées avec celle-ci depuis des années qui sont compromises, ce qui n’est pas le cas si la paire de clé est renouvelée chaque année par exemple.
Les durée de vie des certificats de chiffrement et de ceux de signature, dans le cas ou il y a deux paires de clés, n’est pas nécessairement la même : on peut par exemple considérer que les applications de signature sont plus critiques que celles de chiffrement et que les certificats associés nécessitent donc une durée de vie plus courte.
Si un certificat de signature, aussi appelé certificat de vérification, est expiré, il doit tout de même être possible de s’en servir, pour vérifier des signatures datant d’avant l’expiration (il faudra dans ce cas s’assurer qu’au moment de la signature le certificat n’étais pas périmé ou révoqué).
Si par contre un certificat de chiffrement est expiré, sont utilisation ne devrait plus être possible.
Une application cliente peut ignorer ou simplement avertir l’utilisateur que le certificat est expiré, sans pour autant en interdire l’utilisation (voir les champs des certificats X509v3).

Archivage des certificats :

Les certificats devraient en principe être sauvegardés ailleurs que dans un annuaire, ce qui doit permettre à un utilisateur les ayant perdu de les récupérer, même s’ils ne sont plus dans l’annuaire. Cette fonctionnalité peut aussi permettre de restaurer les informations dans l’annuaire, le cas échéant.

Renouvellement des clés et des certificats :

Puisque les certificats expirent, il faut pouvoir les renouveler. Pour éviter toute interruption de service, c’est à dire que l’utilisateur n’ait plus pendant une certaine période de certificat valide, le mécanisme de renouvellement doit commencer avant l’expiration.
Une PKI devrait permettre de fixer ces paramètres.
Dans le cas des simples AC, qui utilisent majoritairement les navigateurs comme clients (pour faire du SSL et du S/MIME) cette fonctionnalité n’est pas disponible parce que les clients ne savent pas gérer les requêtes de certificats avant expiration.
Mais ça devrait bientôt changer (c’est promis, ça vient dans la version n en Qn de l’année 200n...).

Recouvrement des clés de chiffrement symétriques :

Comme je l’ai mentionné dans la section " génération des clés ", une PKI peut offrir la possibilité aux utilisateurs de recouvrer leurs documents chiffrés s’ils oublient le mot de passe libérant la clé privée par exemple. Il faut pour cela sauvegarder au niveau du serveur de PKI les clés privées de chiffrement.
Cela introduit biensur une faille, puisque un administrateur est théoriquement en mesure de lire des fichiers chiffrés.
On peut cependant limiter ce risque en mettant en place des systèmes d’autorisation multiples (plusieurs administrateurs doivent donner leur accord) ou d’avertissement de l’utilisateur en cas de recouvrement par exemple.
Ce qui chiffre les documents est une clé symétrique utilisée dans un algorithme de chiffrement par blocs (AES, DES, IDEA, CAST, Twofish...). Cette clé est ensuite chiffrée avec la clé asymétrique du destinataire (la sienne si on chiffre pour soi-même). Dans les cas standard, pour recouvrer un fichier chiffré, il faut donc déchiffrer la clé symétrique, et donc récupérer sa clé privée asymétrique de déchiffrement devenue inaccessible.
La PKI peut alors proposer un moyen sécurisé pour recouvrer cette clé, et en régénérer une paire et le certificat associé si nécessaire.
Il existe une autre possibilité : lors du chiffrement, une copie de la clé symétrique est chiffrée avec une clé (publique) maître de l’AC, qui pourra alors déchiffrer tous les documents sans recouvrer les clés des utilisateurs. Ce procédé, outre qu’il permet plus d’abus, pose en plus un autre problème : si la paire de clé maître est cassée, révélée ou aux mains d’un tiers, ce sont tous les documents de tous les utilisateurs de la PKI qui sont vulnérables.
Avant de décider si l’on va se donner la possibilité de recouvrer les clés privées de chiffrement il faut soigneusement considérer les deux aspects suivants :
Soit on est prêt à gérer et assumer les pertes de données consécutives à des oublis de mot de passe...
Soit on accepte la possibilité de recouvrement, avec les risques pour la confidentialité que cela peut supposer...

Publication et accessibilité des certificats :

Pour que tout utilisateur puisse trouver le certificat d’un correspondant, la PKI doit les rendre publiquement accessibles. Elle les poste pour cela dans des annuaires, X.500 ou simplement " LDAP ".
Lightweight Directory Access Protocol (LDAP) est un protocole de communication avec les annuaires.
Les annuaires possèdent une structure en arbre qui facilite les recherches.
La PKI postera également dans les annuaires les Listes de Certificats Révoqués (CRL), qui permettront aux applications clientes de venir consulter l’état de validité d’un certificat.
Il est à la charge des applications d’implémenter LDAP pour aller chercher les certificats et consulter les CRL.
Un protocole pour consulter les CRL est OCSP (Online Certificate Status Protocol), via un serveur qui prend en charge cette vérification.
La PKI n’a pas à se soucier particulièrement de la sécurisation de ses communications avec l’annuaire : les certificats ne sont pas confidentiels, et ils sont signés (si un faux certificat remplace un vrai, les applications clientes n’en vérifieront pas correctement la signature). Il est cependant important de noter que la structure même de l’annuaire peut être de nature confidentielle.
Un standard, SASL, est pourtant en train d’émerger, qui permettra d’établir des communications sécurisées avec les annuaires.
Pour donner une idée, voici la structure typique d’un annuaire :

Révocation des certificats (CRL) :

Une PKI doit permettre de révoquer des certificats. Chaque certificat possède un champ Serial Number, c’est ce numéro qui est inscrit dans une liste des certificats révoqués (CRL) en cas de révocation. Lorsqu’une application cliente utilise un certificat, elle devrait aller consulter la CRL. Si le numéro de série du certificat n’est pas présent, c’est qu’il est valide.
Les CRL sont signées par l’AC et doivent être accessibles en LDAP dans un annuaire.
S’il n’y a pas de CRL ou qu’il faut faire un telnet sur une machine pour aller ensuite la chercher en FTP dans le 43ème répertoire d’une machine située à Panama, c’est que l’AC (la pseudo-PKI) fait mal son boulot : Panama c’est pas pour les CRL mais pour les pavillons de complaisance. Hélas.
Il faudra aussi prendre soin de bien spécifier les procédures organisationnelles pour procéder à une révocation :

— Qu’aucun certificat ne soit révoqué de façon non légitime,

— Prévoir la méthode d’authentification des requêtes de révocation...

— ...etc

Vérification des certificats et des signatures :

Normalement, lors de chaque utilisation d’un certificat (chiffrement, vérification de signature, authentification...) l’application qui l’utilise devrait en vérifier la validité. Cela consiste en :

Vérifier la signature que le CA y a apposé (intégrité et authenticité)
Vérifier qu’il est valide en vérifiant les dates de validité
Vérifier qu’il n’a pas été révoqué, en allant consulter la CRL correspondante.

Dans le cas des simples AC, les clients étant les navigateurs, ils n’ont pas aujourd’hui de fonctionnalités automatiques de consultation de CRL, elle doit se faire manuellement... et c’est laborieux. OCSP est apparu sur Netscape 6, désactivé par défaut.

Gestion des co-certificats :

Une autorité de certification peut se co-certifier avec une autre. Il peut alors s’établir entre les utilisateurs des deux CA un lien de confiance.
Cette confiance peut être unilatérale.
Techniquement une AC va certifier le certificat d’une autre AC (qui est en fait un certificat auto-émis... il faut bien que ça commence quelque part), et réciproquement.
Il y a plusieurs types d’architectures de co-certification : hiérarchique, à plat, mixte, pont...

Horodatage :

Une PKI devrait offrir des services d’horodatage. Une application cliente doit pouvoir accoler à la signature d’un document un sceau temporel (sic). L’application passe les données au travers d’une fonction de condensation, signe ce résultat et l’envoie à un serveur de temps. Celui-ci, éventuellement relié à une horloge atomique, à un réseau de type GPS ou à un coucou suisse, vérifie la signature et, si elle est bonne, y adjoint une date, signe à nouveau le tout et le renvoie à l’expéditeur. Celui-ci joint ce sceau à ses données.
Le destinataire vérifie la signature sur le sceau et est assuré que la date portée sur la signature est correcte.
Il est à noter que l’horodatage ne certifie que la date et l’heure de la signature, pas celle de l’expédition ou de la réception d’un message ou du pigeon voyageur (s’il est envoyé ou lâché).
Voir la page sur l’horodatage pour plus de détails.

Journalisation :

Une PKI devrait enfin journaliser tous les opérations, en protégeant ces données en intégrité et/ou confidentialité, comme la création d’utilisateurs, leur révocation... etc.

 
 
 
 
 
 
Partager sur Twitter  |  Partager sur LinkedIn