Passer au contenu

Interopérabilité des PKI : attention chantier !

Longtemps fondées sur des technologies différentes, les infrastructures à clé publique adoptent progressivement des standards émergents. Mais, d’importants problèmes d’interopérabilité subsistent encore.

La montée en puissance de l’e-commerce impose l’interopérabilité des différentes infrastructures à clé publique (PKI), ou celle d’une PKI et des systèmes existants (applications Intranet, grands systèmes ou passerelles VPN). C’est le cas lorsque deux entre prises, ayant chacune déployé sa propre PKI, veulent échanger des messages B to B ou s’offrir mutuellement des portes d’entrée sur leurs systèmes d’information respectifs. Le même problème se pose quand deux sociétés fusionnent. Certes, elles pourraient faire table rase du passé et déployer une PKI commune en attribuant de nouveaux certificats mais, à chaque fusion et pour chaque nouveau partenaire, il faudrait recommencer. À l’évidence, la formule la plus économique consiste à marier les PKI. Cela n’est possible que si les deux autorités de certification peuvent s’authentifier mutuellement et si elles sont capables de dialoguer. Il faut aussi que l’on puisse identifier les certificats révoqués. Il faut encore que les ressources, jusqu’alors chapeautées par une PKI, puissent exploiter les certificats de l’autre. Cette dernière situation se retrouve dans le cas d’une seule PKI, qui doit sécuriser des ressources variées, qui ne sont pas forcément connues à l’avance.

Des standards émergents

Il en va de même quand une banque émet des certificats destinés à ses clients mais dont la valeur sera reconnue par d’autres entreprises dont les applications ciblent la même population. En outre, une entreprise ne connaît pas à l’avance ses futures ressources. La sphère d’influence de toute PKI doit donc rester ouverte à des ressources qui seront déployées dans les années à venir. Enfin, il faut s’assurer de sa compatibilité avec des certificats achetés chez un tiers de confiance, comme Certplus ou VeriSign.Les multiples aspects techniques de l’interopérabilité restent très difficiles à mettre en ?”uvre. On se trouve souvent contraint à un travail d’intégration, voire à l’attente d’une coopération des fournisseurs. Il existe bien des normes et des standards, mais ils sont encore récents, instables, incomplets et pas toujours implémentés de la même façon. La plupart sont placés sous la bannière PKIX, un ensemble de RFC de l’IETF, qui a notamment repris des standards de la série des PKCS (Public key cryptography standards). Les résultats de PKIX sont utilisés par le PKI Forum. Ce dernier regroupe une grande majorité des acteurs de l’industrie, tels Baltimore Technologies, Entrust, RSA Security, ou Tivoli, et s’attache à préciser les détails d’implémentation et à vérifier l’interopérabilité. Ce qui n’empêche pas de nombreux accords de coopération visant à certifier l’interopérabilité des PKI, des applications ou des VPN. PKIX a abouti à la publication du protocole CMP (Certificate management protocol), qui permet aux différentes composantes d’une PKI de se parler. Ce dialogue s’instaure entre deux autorités de certification (pour une certification croisée ou basée sur une hiérarchie d’autorités différentes), entre une autorité de certification et une autorité d’enregistrement (pour la transmission des demandes) et entre une ressource et une autorité de certification ou d’enregistrement (pour demander, mettre à jour, sauvegarder et recouvrir les certificats). CMP V1 est déjà déployé depuis quelques mois, mais les essais d’interopérabilité ont mis en évidence des points d’achoppement que la V2 vient de clarifier. “CMP ne représente que la tuyauterie, et non le contenu”, prévient Yves le Roux, consultant sécurité chez Entrust Technologies. Ce contenu comprend essentiellement le certificat.

Au-delà des aspects techniques

Pour le certificat, il existe bien la norme ISO X509, adoptée par PKIX et mise en ?”uvre par tous. Mais elle n’est pas suffisante : d’abord, parce qu’elle spécifie des champs propriétaires ou optionnels ; ensuite parce que les algorithmes de chiffrement asymétrique doivent être les mêmes. Certes, PKIX définit des profils de certificats stabilisés tels que ceux qui ciblent les protocoles SSL (flux HTTP), S/Mime (messageries) et IPSec (réseau). Mais lorsqu’il s’agit de viser une application, il faut espérer que l’éditeur de la PKI la supporte. Sinon, la compatibilité passe par un travail d’adaptation, éventuellement facilité par le kit de développement fourni par l’éditeur.La gestion standardisée des certificats révoqués représente une autre gageure. Les informations relatives à la publication et à la révocation des certificats sont stockées dans un annuaire. Parmi ses nombreuses fonctions, le protocole CMP permet d’interroger cet annuaire pour vérifier la validité d’un certificat. Mais le groupe PKIX a défini un autre protocole, OCSP (On line certification status protocol), initialement développé par Valicert, un opérateur de révocation.Répondant à des contraintes temps réel plus fortes, OCSP donne la possibilité d’interroger un service de révocation (interne à l’entreprise ou tiers) afin de vérifier le statut d’un certificat et, éventuellement, les raisons de sa révocation. On le voit, il existe de multiples raisons pour que l’interopérabilité ne soit pas au rendez-vous. Mais, dans tout processus de standardisation, l’inévitable Microsoft vient tenter de mettre tout le monde d’accord, avec sa propre solution intégrée. En l’occurrence, l’éditeur a doté Windows 2000 d’un serveur de certification qui mélange standards et technologies propriétaires.D’ores et déjà, toutes les applications Microsoft peuvent s’appuyer sur cette PKI. De plus, un protocole spécifique, déjà adopté par les principaux fabricants, permet le support des cartes à puce. La chaîne complète sera couverte lorsque des éditeurs tiers adhéreront à cette initiative.La standardisation technique n’est pourtant pas tout. Ainsi, les aspects organisationnels doivent garantir un degré de sécurité équivalent et mutuellement reconnu par les prometteurs des PKI. “Les objectifs de deux PKI sont souvent très différents. Une PKI sera, par exemple, dédiée à la signature de messages ; l’autre, à leur chiffrement, ce qui rend parfois impossible leur mariage”, estime même Jean-Lou Cieur, consultant en sécurité informatique chez Algoriel. Des aspects légaux viennent se greffer. “Certaines PKI ciblant les échanges B to B doivent se conformer à des standards juridiques ou liés aux assurances, encore en cours de définition à la Commission européenne et à l’ONU”, affirme ainsi Joël Gasparato, directeur du pôle Sécurité chez Net2S.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Lévy-Abégnoli