L'inscription éclairée : Le livre des cinq protocoles d'inscription par certificat

Dans cet article de blog, Mike Agrenius Kushner, en tant qu'architecte de produits, va présenter un guide du profane sur l'inscription à PKI via API et cinq des protocoles pris en charge aujourd'hui par EJBCA. 

Rappelez-vous, si vous y étiez, votre premier jour à l'université. Le premier acte consistait à s'approcher d'un bureau et à pointer son nom sur un registre, après quoi on vous remettait un bout de papier fragile avec un nom d'utilisateur (basé sur une contraction probablement embarrassante des lettres de votre nom) et un mot de passe généré automatiquement (que vous étiez autorisé à changer quelque temps après avoir réussi le cours sur les transformations différentielles en troisième année). Tout ce processus s'appelait l'inscription.

Cela ressemble beaucoup à la première étape du cycle de vie d'un certificat, lorsque le détenteur d'une clé se présente avec ses informations d'identification à une autorité de certification, qui délivre alors à cette entité un certificat lui permettant d'aller de l'avant et d'être excellente. Nous avons tous procédé à l'inscription en utilisant des demandes de signature de certificat (CSR) et en les soumettant manuellement à divers outils et applications par le biais de lignes command , de scripts ou peut-être même d'une interface utilisateur. La véritable magie s'opère lorsque vous êtes en mesure de laisser votre appareil s'inscrire de lui-même. Si vous avez eu de la chance, vous n'avez jamais su que cela s'était produit.

Dans cet article de blog, nous allons examiner cinq des protocoles d'inscription pris en charge par EJBCA: ACME, SCEP, CMP, EST et notre propre suite d'API REST . Nous allons nous pencher sur l'historique de chaque protocole, les avantages et les inconvénients et les domaines dans lesquels vous êtes susceptibles de les appliquer. Pour ce blog, nous traiterons l'inscription automatique de Microsoft comme un cas d'utilisation complètement différent.

Le protocole de gestion des certificats (CMP) est le plus ancien des protocoles pris en charge par EJBCA. Il a été rédigé pour la première fois en 1996, a obtenu le statut de RFC avec le RFC 2510 en 1999 et a atteint son état actuel avec le CMPv2 avec le RFC 4210 en 2005.

En tant que protocole, le CMP montre certainement son âge, à la fois en termes de conception et de complexité injustifiée, en partie à cause de l'état naissant de PKI à l'époque où il a été conçu. La complexité (et dans certains cas l'ambiguïté) de la RFC signifie que diverses implémentations de serveurs et de clients peuvent s'écarter et s'écartent effectivement des détails les plus fins.

La principale force du CMP est donc aussi sa principale faiblesse : c'est l'un des protocoles les plus complets en termes d'opérations disponibles et de permutations diverses. De ce fait, les clients qui prétendent prendre en charge l'ensemble de la RFC 4210 sont rares.

Cette ancienneté et cette résistance signifient également que le CMP, en tant que protocole, ne dépend pas de nombreuses piles technologiques. Il peut être envoyé via HTTP, TCP ou carrier pigeon.

L'un des principaux aspects qui permet au CMP de rester pertinent aujourd'hui est le cadre 3GPP LTE, développé à l'origine pour et par l'industrie des télécommunications, qui ajoute la prise en charge des certificats des fournisseurs au CMP. Cela permet à un fabricant de fournir à un appareil un certificat signé par sa propre autorité de certification. Ce certificat peut ensuite être présenté par un utilisateur final pour s'inscrire sur son site PKI. Le CMP est également utile dans d'autres secteurs. Un autre exemple est celui des réseaux ferroviaires, où le CMP est défini comme le protocole standard pour les systèmes ERTMS.

Si vous souhaitez commencer à jouer avec EJBCA et CMP, je vous recommande cette section de la vidéo PKI at the Edge pour la communauté Keyfactor .

+ Si vous avez besoin d'un protocole avec une suite complète d'opérations

+ Vous êtes un fabricant de matériel de télécommunication ou quelqu'un d'autre dans une industrie qui dépend du 3GPP.

- Vous n'êtes pas prêt à gérer un client complexe qui pourrait devoir tenir compte des différentes interprétations du RFC par les différents fournisseurs d'autorités de certification.

Presque aussi ancien que le CMP, le Simple Certificate Enrollment Protocol a vu sa première ébauche en 2000. Contrairement au CMP, le SCEP a été conçu pour être aussi léger et simple que possible, sur la base d'un protocole propriétaire développé à l'origine pour Cisco, qui a également soumis le premier projet de SCEP.

Par rapport à CMP, l'ensemble des opérations de SCEP est beaucoup plus limité, avec quelques commandes pour l'enrôlement et la récupération de certificats et de CRLs, avec des versions ultérieures du projet ayant une capacité légèrement oblique à effectuer le renouvellement également. SCEP est resté bloqué dans l'enfer des projets entre la publication de la version 23 du projet original en 2011 et la publication finale du RFC 8894 en 2020, ce qui signifie que la version 23 est toujours la version de facto supportée par la plupart des CA software, y compris EJBCA.

En raison de son héritage et de son utilisation répandue, SCEP reste à ce jour un protocole d'enrôlement populaire, en particulier pour les applications légères telles que l'enrôlement de périphériques. Le choix de Microsoft d'étendre SCEP dans la définition de son service Intune pour l'enrôlement d'appareils dans le nuage Azure a cimenté SCEP en tant que protocole à soutenir pour de nombreuses années à venir.

En raison de l'accent mis sur la légèreté, SCEP ne prend pas en charge plusieurs fonctions qui pourraient être considérées comme essentielles, notamment la révocation et le renouvellement explicite (qui existe dans le RFC, mais pas dans le projet 23). Le chiffrement de la charge utile de SCEP est également l'un de ses principaux inconvénients, car la méthode de chiffrement repose sur la clé publique de l'autorité de certification. Cela signifie que SCEP ne prend en charge que les clés RSA et qu'il est très peu probable qu'il ait une quelconque utilité dans un avenir post-quantique. On peut dire que le processus de cryptage lui-même est suffisamment complexe pour annuler le "S" de SCEP.

+ En tant que protocole hérité, il est encore largement utilisé et soutenu.

+ Une évidence si votre cas d'utilisation implique Microsoft Intune

- L'adoption encore limitée du RFC par rapport au projet peut entraîner des problèmes de compatibilité à l'avenir.

- L'ensemble des opérations ne comprend pas le cycle de vie complet du certificat

- Pas de prise en charge des courbes elliptiques et agilité cryptographique limitée

- Cisco recommande elle-même l'utilisation de l'EST pour les nouvelles applications

Successeur spirituel de SCEP, le protocole Enrollment over Secure Transport (EST) a été écrit par des éléments de Cisco et d'Aruba Networks en tant que protocole d'enrôlement léger avec TLS à l'esprit, ainsi qu'en incorporant les leçons apprises au moment de sa publication en 2013. Comme pour SCEP, EST n'a pas de type de message pour la révocation, mais prend en charge le renouvellement dès le départ. EST est décrit dans le RFC 7030.

L'un des principes de l'EST est en particulier sa dépendance à l'égard de TLS, qui permet de transmettre des données utiles par un canal crypté, ce qui supprime la nécessité de les crypter à l'aide d'un secret partagé. Cela permet à EST de gérer des clés basées sur une courbe elliptique, contrairement à SCEP.

Comme pour SCEP, EST peut utiliser un secret partagé (mot de passe) pour l'authentification du client, mais peut également utiliser un certificat client émis par un tiers de confiance.

Le fait de s'appuyer sur la pile HTTPS conduit à des requêtes plus simples (EST peut être appelé avec curl), ce qui permet des implémentations client légères. En outre, EST peut être utilisé pour que les clés soient générées côté serveur. Ces détails font de EST le choix naturel pour IoT et d'autres cas d'utilisation légers de PKI .

+ Si vous avez besoin d'un protocole avec une suite complète d'opérations

+ Vous êtes un fabricant de matériel de télécommunication ou quelqu'un d'autre dans une industrie qui dépend du 3GPP.

- Vous n'êtes pas prêt à gérer un client complexe qui pourrait devoir tenir compte des différentes interprétations du RFC par les différents fournisseurs d'autorités de certification.

ACME est l'un des rares protocoles développés dans un but très particulier : il a été développé par une société d'utilité publique, l'Internet Security Research Group (ISRG), dans le cadre d'un effort concerté visant à rendre TLS largement disponible et utilisé sur l'ensemble de l'internet. Les autres éléments de cet effort sont l'autorité de certification Let's Encrypt et le client de certificat CertBot qui l'accompagne.

Là où l'ACME se distingue des autres protocoles d'inscription, c'est qu'il est entièrement axé sur l'automatisation, tout au long du cycle de vie du certificat et surtout en permettant au client de fournir une preuve d'identité (propriété d'un nom DNS spécifique) sans aucune interaction ou vérification manuelle de la part de l'autorité de certification.

Pour ce faire, ACME fournit un cadre de défis qui permet à l'autorité de certification de spécifier un certain nombre de moyens pour le client de prouver qu'il est propriétaire de n'importe quelle ressource spécifiée comme identité de ce certificat, qu'il s'agisse d'un nom DNS ou d'une adresse de courrier électronique pour un certificat S/MIME. Théoriquement, un client utilisant ACME est censé pouvoir se passer de tout, s'inscrivant et renouvelant continuellement le certificat tant que l'identité donnée est encore contrôlée.

Bien que cela ressemble à une corne d'abondance de PKI , il convient de garder à l'esprit que l'ACME est écrit en tenant compte principalement du cas d'utilisation du certificat TLS . Bien que les auteurs de la RFC 8555 aient habilement permis des extensions de la RFC pour définir des types de défis supplémentaires (et plusieurs existent en tant que RFC ou projets), le protocole ACME dépend toujours de cette interaction - en fait, le fait de la sauter annule complètement le cas d'utilisation d'ACME.

La complexité de cette interaction met également l'accent sur le soutien du client, car tout défi étendu ou toute variation du RFC hébergé par le serveur n'a de sens que si les clients (dont CertBot fait partie, mais il y en a une pléthore) choisissent de l'honorer. Il faut donc garder à l'esprit que tout cas d'utilisation qui s'écarte du modèle général d'interaction entre l'autorité de certification et le client doit être pris en charge à la fois par le serveur et par le client.

+ Meilleur protocole à utiliser pour l'émission de certificats TLS

+ Fournit un ensemble complet d'opérations et une automatisation intégrée pour l'enrôlement.

+ Le renouvellement automatisé favorise l'utilisation de certificats à courte durée de vie, ce qui permet une certaine souplesse en matière de cryptographie.

+ Le RFC, facilement extensible, offre de nombreuses possibilités de trouver d'autres cas d'utilisation.

- Le RFC Vanilla est optimisé pour les certificats TLS , alors que les autres cas d'utilisation doivent s'assurer qu'il existe un support client^tiers.

- Quel que soit le cas d'utilisation, l'ACME repose sur le traitement d'un défi dans le cadre du flux de travail. Si votre cas d'utilisation n'implique pas que l'autorité de certification vérifie le contrôle d'une ressource, l'ACME n'est peut-être pas le meilleur protocole pour vous.

Enfin, nous allons parler de notre API REST maison, complétée par notre ancienne API WebService. Cette API est naturellement aussi performante que toutes les autres, mais elle offre en plus des capacités de compréhension et de gestion, permettant des flux de travail complexes tels que le travail avec le système d'approbation de EJBCA, la gestion des entités finales, des jetons de crypto-monnaie et des AC.

Comme EST, l'API REST de EJBCAs'appuie sur TLS pour la sécurité et l'intégrité des messages, mais l'authentification peut également être assurée par OAuth ainsi que par un certificat client. Naturellement, notre API REST fait l'objet d'un développement constant, de sorte que lorsque de nouveaux flux de travail apparaissent, ils peuvent être mis en œuvre et déployés beaucoup plus rapidement qu'en attendant qu'une mise à jour de la RFC soit adoptée.

L'inconvénient de s'appuyer sur notre API REST est bien sûr de s'enfermer dans EJBCA en tant que fournisseur unique, comme c'est le cas pour toute API propriétaire. C'est naturellement le cas pour l'ensemble du secteur, étant donné qu'il n'y a eu aucune tentative réussie de créer une API REST normalisée parmi les fournisseurs de PKI .

+ Extensible à l'infini, à la fois sur demande de Keyfactor et de toute personne ayant accès au code source.

+ Fournit des flux de travail plus granulaires en matière d'inscription et de délivrance par rapport à d'autres protocoles

+ Peut être utilisé avec les flux de travail plus complexes de EJBCA, tels que les approbations.

+ Peut également être utilisé pour gérer certains aspects de EJBCA , tels que les jetons cryptographiques, les entités finales et les autorités de certification.

- En tant que protocole propriétaire, la prise en charge de l'API REST de EJBCApar des clients tiers est limitée.

Pour pouvoir couvrir tous vos cas d'utilisation PKI aujourd'hui et à l'avenir, vous aurez probablement besoin de flexibilité pour choisir les protocoles appropriés. EJBCA prend en charge ces protocoles et d'autres, une grande variété de cas d'utilisation de l'infrastructure à clé publique (PKI), des scénarios et des intégrations dans d'autres écosystèmes d'applications - et a fait ses preuves dans de vastes déploiements dans le monde entier. Et comme il est disponible sur open source et en version cloud d'essai gratuit, vous pouvez l'essayer dès aujourd'hui.

Voulez-vous mettre la main à la pâte et l'essayer vous-même ?

• Regardez la deuxième partie de la formation PKI at the Edge pour apprendre à générer des certificats et des CRL en utilisant EJBCA et Bouncy Castle avec CMP ainsi que API REST.
• Pour une spécification détaillée, voir EJBCA Interopérabilité et certifications.
• Si vous avez besoin d'aide pour d'autres protocoles ou cas d'utilisation, n'hésitez pas à nous contacter.