La cryptographie a vécu récemment la révolution de la clé publique. Cette innovation a conduit à l'émergence de la notion d'infrastructure de clés publiques (en anglais Public Key Infrastructure (PKI)). Le but de cette page est de familiariser le profane avec cette nouvelle technologie qui risque bien d'envahir notre quotidien.

1. Introduction

Des nouvelles technologies découle un besoin de sécurité chaque jour plus pressant. Plus que la confidentialité, c'est le besoin d'authentification des données qui est prépondérant. De même qu'un client dépose sa signature pour authentifier ses chèques, les infrastructures de clés publiques permettent d'enregistrer une clé publique qui servira par la suite à authentifier des transactions.

En effet la particularité des transmissions numériques est qu'elles sont constituées de chaînes de bits valant 0 ou 1. Or rien ne permet intrinsèquement de garantir qu'une information représentée par une chaîne de cette nature est authentique. En effet, contrairement à un document papier signé qui présente des altérations physiques décelables si une modification malveillante a été effectuée, une information numérique peut être modifiée sans aucune trace. Le seul moyen pour protéger une information numérique est de lui adjoindre une donnée complémentaire mathématiquement liée, qui prouve la possession d'une donnée numérique secrète appelée clé.

2. Clés secrètes vs. clés publiques

2.1. Une notion nouvelle : la cryptographie à clé publique

La cryptographie existe depuis toujours mais elle reposait, jusqu'à un passé récent, sur l'idée qu'un échange protégé d'informations ne pouvait se baser que sur le partage d'une clé secrète commune (voir la figure 1).

Récemment, la cryptographie à clés publiques a montré comment partager une information secrète sur la base de clés non confidentielles, par exemple par le protocole de Diffie-Hellman. Sur la figure 2 on remarque en effet qu'un bi-clé est constitué d'une partie privée (la clé) et d'une partie publique (le cadenas). Très schématiquement un système à clé publique permet de fabriquer des cadenas et des clés numériques : n'importe qui peut fermer un cadenas mais seul celui qui dispose de sa clé peut l'ouvrir.

Plus exactement, la sécurité du protocole repose sur la difficulté de résoudre un problème mathématique, celui du logarithme discret. Bien qu'il soit facile de calculer une instance du problème y=g^x mod p, remonter à x en fonction de y et p est difficile.

Cette idée d'utiliser des problèmes mathématiques réputés difficiles a permis le développement d'un grand nombre d'algorithmes à clés publiques (RSA, DSA, PKP,...). Le problème de la factorisation d'entiers, connu depuis les mathématiciens grecs, a ainsi été remis à l'honneur du fait de l'invention de l'algorithme RSA, qui permet d'effectuer un chiffrement sur la base de la clé publique du destinataire (voir figure 3).

Le fait d'utiliser des problèmes mathématiques connus pour asseoir la sécurité des algorithmes cryptographiques n'est pas le moindre des avantages de la clé publique. En effet, les algorithmes symétriques de la cryptographie classique sont de conception difficile et la sécurité qu'ils apportent reste empirique. Ils sont sûrs tant qu'une attaque n'a pas été trouvée. Ceci est aussi vrai pour la cryptographie à clé publique, sauf que l'attaque en question implique une avancée des mathématiques très significative, sur des problèmes qui sont à l'étude depuis près de 3000 ans.

Figure 1 : Principe de chiffrement à clé secrète

Figure 2 : Protocole d'échange de clés de Diffie-Hellman

Figure 3 : Protocole de chiffrement RSA

2.2. Gestion de clés

Les systèmes à clés secrètes posent problème en matière de gestion de clés. En effet, si n personnes veulent communiquer, le nombre de clés secrètes à gérer est ½n(n-1), soit 124.750 clés pour 500 utilisateurs (voir figure 4) !

En outre, un algorithme symétrique ne peut être parfait : le chiffré n'est jamais aléatoire. Il contient une certaine quantité d'information sur la clé utilisée. Cette information sur la clé croît donc à chaque utilisation. Un bon algorithme limite suffisamment cette quantité d'information pour que le nombre maximal d'utilisations d'une clé ne soit jamais atteint. Néanmoins, il est recommandé de changer sa clé selon une crypto-période définie en fonction de l'algorithme. La gestion des clés symétriques devient donc vite inextricable quand plusieurs centaines d'utilisateurs sont en correspondance.

Au contraire, dans un système à clés publiques, l'utilisation de la clé ne fournit pas plus d'information à un attaquant potentiel, que celle dont il dispose déjà par la simple connaissance de la clé publique. Comme les algorithmes à clés publiques sont trop lents pour chiffrer des quantités importantes de données, ils vont seulement protéger le transfert d'une clé symétrique à usage unique entre les deux parties (voir la figure 5), et ainsi résoudre le problème de gestion des clés symétriques.

De cette façon, un système à clés publiques est aussi rapide qu'un système à clés secrètes et il n'a à gérer qu'un couple de clés privée et publique par utilisateur (voir figure 6).

Figure 4 : Exemple de système à clés secrètes à 6 utilisateurs

Figure 5 : Principe des systèmes mixtes

Figure 6 : Exemple de système à clés publiques à 6 utilisateurs

2.3. Clé publique et signature électronique

Enfin, la cryptographie à clés publiques rend facile une opération très difficile à réaliser avec des clés secrètes : la signature. Chaque utilisateur disposant d'une clé privée personnelle, il devient possible de prouver l'authenticité d'un message et d'empêcher sa répudiation. Ceci à deux conditions :

1. La clé privée de l'auteur doit avoir été conservée de manière sûre. Ce point peut être de la responsabilité de l'auteur, moyennant la mise à disposition d'une ressource cryptographique adéquate.
2. La clé publique doit être intègre et associée à l'identité de la personne possédant la clé privée correspondante. Cette association ne doit pas pouvoir être mise en doute et c'est la raison d'être des infrastructures de clés publiques.

Ces différents avantages des systèmes à clés publiques les rendent aujourd'hui incontournables. Cependant, ces systèmes nécessitent des infrastructures de clés publiques permettant de tirer parti de ces avantages.

3. Infrastructures de clés publiques

3.1. Principes

Nous avons vu les avantages d'un système à clés publiques. Toutefois, sa sécurité repose sur l'authenticité des clés publiques utilisées, qui doit être garantie pour éviter une attaque par le milieu (voir figure 7). Pour résoudre ce problème, les systèmes à clés publiques utilisent une signature, apposée par une autorité de certification (AC), qui garantit l'association entre la clé publique et l'identité de la personne possédant la clé privée associée.

Figure 7 : Principe d'une attaque par le milieu en l'absence d'autorité de certification

3.2. Certificats de clés publiques

Une clé publique protégée par une signature d'AC est stockée dans un « certificat de clé publique », car la vérification de la signature suppose un format de données strict.

Ainsi, l'utilisateur n'a plus à protéger que ses clés privées et la clé publique de l'AC. Toutes les autres clés publiques dont il peut avoir besoin sont vérifiées par le biais des certificats de clés publiques émis par son AC. L'AC est ainsi le premier élément d'une infrastructure de clés publiques ou ICP (voir figure 8).

Les certificats sont donc propres à une ICP, mais les efforts de normalisation convergent vers le standard X.509-v3. Cette norme définit le format de codage des données, ainsi que celles obligatoirement présentes, par exemple la clé publique, un identifiant de l'entité qui possède la clé privée correspondante, la période de validité de la clé, etc. Toutefois, chaque ICP peut ajouter des informations, par exemple la fonction de l'entité, l'usage de la clé, etc. La vérification d'un certificat consiste donc non seulement à vérifier sa signature, mais aussi à interprêter les données présentes pour vérifier que la clé certifiée est bien valide. Une ICP renseigne aussi des listes de certificats révoqués (CRL) qui doivent être vérifiées.

Figure 8 : Principe d'une autorité de certification

3.3. Autorité de certification et politique de certification

L'AC signe les certificats et possède donc la clé privée correspondant à la clé publique conservée par les utilisateurs de l'ICP. L'AC est le point de confiance des utilisateurs du système. Elle engage sa responsabilité quand elle signe un certificat, mais selon les termes de la politique de certification qu'elle a définie. Par exemple, si la politique d'une ICP précise que seule l'adresse électronique de l'utilisateur est vérifiée, ceci signifie qu'aucun contrôle de l'identité réelle de la personne n'a été effectué. Un certificat valide dans cette politique peut donc indiquer l'identité Jacques.Chirac@free.fr ! Par contre, si la politique de l'ICP prévoit qu'avant toute émission de certificat, l'utilisateur se présente à un guichet avec une pièce d'identité, alors le certificat émis aura une valeur bien plus grande.

Plus que la certification, c'est donc l'enregistrement de l'entité utilisatrice qui est fondamental. De la rigueur apportée à cette opération dépend le niveau de confiance des certificats de l'ICP. Cette opération peut être déléguée à une autorité d'enregistrement (AE). Dans ce cas, l'AC doit vérifier que les règles d'enregistrement de sa politique sont bien respectées par chaque AE.

3.4. Certification croisée et certification hiérarchique

L'interconnexion des systèmes rend inévitable le besoin de communication entre utilisateurs d'ICP différentes. Pour résoudre ce problème, des ICP peuvent décider d'une certification croisée : chaque AC va émettre un certificat pour la clé publique de certification de son homologue. Ainsi, les utilisateurs finaux peuvent établir un chemin de confiance pour les certificats des deux ICP (voir figure 9).

Dans cet exemple, chaque AC encadrée est le « point de confiance » de son ICP. Un utilisateur peut être certifié soit par cette AC, soit par une AC subordonnée, elle-même certifiée par l'AC « point de confiance ». Toute la zone B a confiance dans les certificats des zones A et B. Par contre, les utilisateurs de la zone A n'ont pas confiance dans les certificats de la zone B'. Une telle situation peut intervenir si, par exemple, les règles d'enregistrement de la zone B' ne sont pas compatibles avec le niveau de confiance de l'ICP-A.

Avant d'établir une certification croisée, les deux ICP doivent comparer leurs politiques pour assumer l'équivalence du niveau de confiance entre les deux ICP. Une ICP peut utiliser plusieurs niveaux de politiques de certification. Il n'est ainsi possible d'effectuer des certifications croisées que pour un niveau donné.

Figure 9 : Principe de certification hiérarchique et croisée

4. Nécessité des IGC

Malgré tout, une ICP n'est d'aucun secours si les clés privées de ses utilisateurs sont mal générées, ou mal protégées. Pour pallier ce problème, une infrastructure de gestion de clés (IGC) allie aux services d'une ICP des fonctions de génération de clés et de distribution sécurisée de ressources cryptographiques. Le but d'une IGC est donc de fournit à l'utilisateur des moyens cryptographiques dont la sécurité est cohérente avec le niveau de confiance recherché par l'ICP.

5. Conclusion

La cryptologie à clés publiques est une nouveauté incontournable des systèmes d'information sécurisés. Elle permet non seulement de sécuriser les transmissions individuelles d'un grand nombre d'utilisateurs, mais aussi d'authentifier ces transactions de telle façon qu'une signature électronique ne puisse pas être répudiée.

Comme nous l'avons dit, la sécurité d'un système à clés publiques repose sur l'authenticité des certificats de clés publiques, mais aussi sur la bonne protection des clés privées correspondantes. Pour ce faire, une infrastructure de gestion de clés (IGC) fournit à l'utilisateur des moyens cryptographiques dont le niveau de confiance est cohérent avec celui de l'ICP.