Public Key Infrastructure (PKI)
La PKI
Définition
L’utilisation massive de messages électroniques et l’expansion du commerce électronique est devenu une opération de plus en plus courante. En effet, les données qui transitent sur Internet, sont sujettes à diverses attaques comme l'attaque man in the middle lorsque les entités échangent leurs clefs publiques. Dans une petite structure, il pourrait être envisageable de générer sa paire de clefs localement et d’échanger les clefs publiques hors ligne (en main propre par exemple), mais cette solution est inimaginable pour une structure internationale. Dans ce cas de figure, une authentification automatique des clefs publiques est indispensable.
C’est dans ce contexte que la NIST (National Institute of Stantards and Technology) s’est vu imposer en 1994 la tâche d’étudier et de définir un standard afin de gérer l’authentification dans un environnement international. Ce projet avait pour but de permettre l’interopérabilité des différents systèmes électroniques opérant dans le commerce électronique. L’étude était porté sur la manière de générer les clefs, de les distribuer, d’obtenir les clefs publiques au moyen de certificats, et la publication des certificats obsolètes. L’étude visait à définir des recommandations techniques pour définir une architecture PKI au travers de divers composants.
A la même façon qu’un passeport ou d’une carte d’identité, la PKI va fournir une garantie d’identité numérique aux utilisateurs. Cette pièce d’identité numérique, appelée certificat numérique, contient la clef publique de l’utilisateur, mais également des informations personnelles sur l’utilisateur. Comme tout document formel, le certificat numérique est signé par l’autorité de certification et c’est cette signature qui lui donnera toute crédibilité aux yeux des utilisateurs. Le certificat numérique est largement publié, il n’a pas à être tenu secret, il est consultable via un annuaire.
Pour obtenir un certificat numérique, le client doit effectuer une requête auprès d’un organisme reconnu. Il transmet avec sa requête sa clef publique. L’organisme construit un certificat incorporant la clef publique du client, il signe le certificat à l’aide de sa clef privée. L’autorité de certification publiera le certificat signé comportant la clef publique et l’identité précise du propriétaire, quiconque consultera ce certificat aura l’assurance dans l’authenticité de la clef publique contenue dans celui-ci car il a confiance dans l’autorité de certification qui a délivré ce certificat.
La gestion des clefs
La gestion des clefs de l'infrastructure doit être rigoureuse. En effet, il a été démontré dans les faits qu'il est beaucoup plus facile de s'introduire dans un système et de se procurer illicitement les clefs plutôt que de casser un algorithme. Et le moment le plus propice pour espérer se procurer les clefs est sans conteste le moment où l’échange des clefs a lieu. C'est pourquoi, l'échange des clefs doit être fait avec la plus grande prudence car il représente le point de vulnérabilité de tout le système.
La gestion des clés proprement dite se compose des opérations suivantes :
- Génération : Les clefs doivent être générées de manière aléatoirement, de manière à ce qu'elles soient non prédictibles. La prédictibilité dans le processus de création de clef peut compromettre tout le système de sécurité.
- Distribution : La distribution est l’action de déplacer une clef de cryptage. Un exemple de distribution est la clef de session, on va créer une clef qui va permettre le transport d'une autre clef.
- Stockage : La clef doit être protégée et doit garder à tout prix son intégrité et sa confidentialité. Le contrôle d’accès peut assurer l’intégrité et l’authenticité, mais seul un stockage sur support hardware peut assurer la confidentialité de la clef.
- Suppression : La suppression de clefs intervient quand la clef à atteint sa fin de validité ou lorsqu'un doute subsiste sur sa confidentialité. La suppression signifie la destruction des toutes les copies de la clef symétrique ou de la clef publique. Cependant, si le système permet l'archivage des clefs, alors celles-ci seront archivées plutôt que supprimer.
- Archivage : L’archivage des clefs permet de conserver une copie des clefs même si elles ne sont plus utilisées, le but est de pouvoir valider des données qui ont été précédemment protégées par cette clef. Dans tous les cas, une clef archivée ne peut pas être remise en service dans un environnement d’application.
- Recouvrement : Le recouvrement des clefs est une procédure délicate qui permet de retrouver la clef privée d’un client. Par exemple lorsqu'un utilisateur a perdu sa clef privée. Ce principe permet aussi le recouvrement des données chiffrées par cette clef. En effet, si cette clef est perdue, alors toutes les données seront perdues par la même occasion. C'est pourquoi, le recouvrement des clefs peut être une solution pour permettre le recouvrement des données.
Les composants d'une PKI
Une PKI contient plusieurs composants principaux essentiels à son bon fonctionnement :
- Une Autorité d'enregistrement : (Registration Authority - RA) Son principal rôle est de vérifier la demande d'enregistrement (Certificate Signing Request - CSR) d'un nouvel utilisateur dans l'infrastructure. Les méthodes de vérification de cette étape sont définies en fonction de la politique de certification choisie pour l'infrastructure. En effet, cela peut aller du simple échange de courriel pour valider la demande ou à une vérification de l'identité de la personne (carte d'identité, passeport, etc.). Si l'autorité d'enregistrement valide la demande d'enregistrement, alors la requête de certificat passera entre les mains de l'autorité de certification (cette requête est transmise au format standard PCKS#10). L'autorité d'enregistrement peut être contenue dans l'autorité de certification. Cependant, l'avantage de séparer ces deux entités de la répartition de charge de chaque entité.
- Une Autorité de Certification : (Certificate Authority - CA) Son principal rôle est de générer un certificat pour l'utilisateur. Le certificat contiendra des informations personnelles sur l'utilisateur mais surtout sa clef publique et la date de validité. L'autorité de certification signera ce certificat avec sa clef privée, ainsi ce certificat sera certifié authentique par lui même. C'est pourquoi on parle de chaîne de confiance dans une PKI car il s'agit de faire confiance à cette autorité de certification qui sera lui même certifié par une autorité supérieure et ainsi de suite. L'autorité de certification aura aussi le rôle de mettre à jour la liste des certificats qu'il a signé afin de connaître les dates de validité de ses certificats. En effet, pour vérifier si un certificat est valide, il faudra demander à l'autorité de certification qu'il l'a généré si le certificat en question est toujours valide ou s'il a été révoqué.
- Un Annuaire : L'annuaire est indépendant de la PKI cependant la PKI en a besoin. Les seules contraintes de l'annuaire sont qu'il doit accepter le protocole X.509 pour le stockage des certificats révoqués et le protocole LDAP (je vous invite à aller voir l'exposé de Vivien BOISTUAUD). Son rôle est comme dit précédemment de stocker les certificats révoqués et par la même occasion, les certificats en cours de validité afin d'avoir un accès rapide à ces certificats. De plus, l'annuaire peut stocker les clefs privées des utilisateurs dans le cadre du recouvrement de clef. Sachant que les certificats sont largement distribués, l'annuaire est une solution pour les mettre à disposition.
Un autre point important est la répartition des autorités des certifications. En effet, les autorités de certifications fonctionnent par une chaîne de confiance. Quelles seraient donc les conséquences si une chaîne venait à se briser. Toutes les autorités de certifications certifiées par l'autorité de certification supérieure seront donc remises en cause car elles n'auraient plus aucun moyen de pour prouver ses certificats car la communication entre ellses serait brisée (figure 1).
Pour parer à ce problème, il existe plusieurs modèles pour structurer les autorités de certifications:
- Modèle hiérarchique : Les autorités CA1 et CA2 ont soumis leurs clefs publiques à un CARoot qui leur a généré un certificat. L’autorité CARoot peut être défini comme le plus haut niveau d’autorité. C’est le seul composant qui ait un certificat auto-signé. Un certificat auto-signé est le seul certificat qui permette d’assurer l’intégrité et non l’authenticité, d'où la chaîne de confiance. Par conséquence, CA1 et CA2 deviennent des CA subordonnées de CARoot (figure 2).
- Modèle Peer-to-Peer : Le modèle hiérarchique ne règle pas notre problème, c'est pourquoi, il existe le modèle Peer-to-Peer qui permet que différentes autorités de certification soient au même niveau. Si des autorités de certifications sont au même niveau, les certificats qu'elles génèrent sont co-signé, autrement dit, que CA1 peut signer des certificats pour CA2 et vice-versa. Ils sont responsables mutuellement des certificats de leur homologue (figure 3). Le problème de ce modèle est que toutes les autorités de certifications de même niveau doivent s'échanger leur clef publique pour pouvoir générer des certificats pour leur homologue, de ce fait, plus il y a d'autorités de certification, plus il y aura d'échange de clef publique (pour N autorités de certification il faut générer N²-N/2 certificats pour certifier toutes les autorités).
- Modèle Bridge : Le modèle en pont ou Bridge est une alternative aux deux autres modèles. En effet, le modèle hiérarchique ne permet pas d'avoir une structure stable et le modèle Peer-to-Peer nécessite un nombre important d'échange entre les autorités. Le modèle en pont ressemble fortement au modèle Peer-to-Peer sauf qu'il permet de limiter les échanges entres les autorités. Le nombre d'échange entre les autorités est réduit car il ne faut plus échanger la clef publique avec toutes les autres autorités mais uniquement avec l'autorité pont (figure 4).
Les politiques de la PKI
La politique d'une PKI se définit à deux niveaux:
- La politique de certification : Une politique de certification est un ensemble de règles, qui fournit un renseignement sur la possibilité d’utiliser un certificat pour une communauté particulière ou des applications ayant des besoins de sécurité communs. Elle spécifie entre autre les conditions et les caractéristiques de délivrance du certificat. Dans le cas général, un certificat est utilisable par n’importe quelle application pour autant que ces conditions et ces caractéristiques sont jugées satisfaisantes. Cependant, une politique de certification peut éventuellement restreindre l’usage du certificat à un ensemble données d’applications, voir même à une seule application.
-
La politique de sécurité : est la partie juridique de la PKI. En effet, lorsqu'on met en place une PKI, il faut fournir trois documents :
- Rapport pratique de certification : qui spécifie les critères de certification et la politique de révocation des certificats,
- Politique du certificat : qui explique et limite l'utilisation du certificat numérique,
- Considérations légales : qui permet de responsabiliser les utilisateurs en cas de perte ou de fraude à l'intérieur même de la PKI.
Un exemple d'utilisation de la PKI
Voici un exemple qui illustre la demande de certification d'un utilisateur lambda dans une entreprise qui utilise le principe de la PKI :
L'utilisateur demande à l'autorité d'enregistrement, une demande de certificat. Lorsque l'autorité d'enregistrement reçoit la demande de l'utilisateur, il vérifie l'identité de l'utilisateur et valide sa demande s'il est apte à recevoir un certificat. Par la suite, il passe cette demande à l'autorité de certification qui va appliquer les procédures. Une fois que ces procédures sont faites, l'autorité de certification va générer une paire de clef. Dans notre exemple, le support du certificat est une carte à puce (d'autre cas d'utilisations comme une clef USB, la biométrie, etc. sont possibles). L'autorité de certification va signer un certificat contenant la clef publique de l'utilisateur avec sa clef privée. Par la suite, le certificat et la clef privée de l'utilisateur seront insérés dans la carte à puce. De plus, le certificat sera ajouté dans l'annuaire étant été signé par l'autorité de certification (la clef privée pourrait aussi être ajoutée dans l'annuaire dans le cadre du recouvrement de clef). La carte à puce sera remise à l'utilisateur.
Lorsque l'utilisateur voudra s'authentifier dans le système, il insèrera sa carte à puce dans un lecteur. Le lecteur générera un nombre aléatoire à chaque fois. Ce nombre aléatoire devra être le plus grand possible afin d'éviter les redondances. La carte chiffrera ce nombre aléatoire avec la clef privée qu'il contient. Ensuite, le système va vérifier les informations du certificat contenue dans la carte à puce afin de vérifier l'identité de l'utilisateur et du certificat (on pourra aussi ajouter des contrôles d'accès en fonction du certificat). Une fois que la vérification est faite, on déchiffre le nombre chiffré avec la clef publique. Si le nombre déchiffré est identique au nombre généré, alors l'authentification s'est bien déroulée (dans le cas de la biométrie, la clef privée de l'utilisateur est une partie de son corps: yeux, doigt, etc.).