Concepts de base des PKI
Le but de ce document est d'introduire les différents concepts des PKI (Public Key Infrastructure).
1. Concepts généraux de sécurité
1.1 Clé publique/clé privée
Anne veut envoyer un message privé à Bernard et elle veut que seul Bernard puisse le lire.
Grâce à la clé publique de Bernard, elle crypte le message et l'envoie. Seul Bernard, qui possède la clé privée correspondante peut décrypter le message.
1.2 Message digest
Bien qu'Anne puisse crypter son message pour assurer sa confidentialité, le risque demeure qu'un intrus disposant lui aussi de la clé publique de Bernard, modifie le message original ou lui substitue un autre message.
Anne crée donc un bref compte-rendu (message digest ou hash) de son message et l'envoie à Bernard avec le message. À la réception du message et du compte-rendu, Bernard calcule son propre compte-rendu. Si les deux compte-rendus correspondent c'est que le message à été reçu intact.
1.3 Signature digitale
Bernard veut s'assurer que le message reçu à bien été envoyé par Anne et non par un intrus. La signature digitale de Anne est donc envoyée avec son message.
Cette signature digitale est créé en cryptant le digest du message et d'autres informations (un numéro d'ordre) avec la clé privée de Anne. N'importe qui possédant la clé publique de Anne peut décoder la signature digitale, mais seule Anne peut l'avoir cryptée. Cela garantit que seule Anne a pu signer le message.
Inclure le digest du message dans la signature signifie que la signature n'est valable que pour ce message particulier. Ceci garantit donc l'intégrité du message, car personne le peut modifier le digest et signer le message à la place de Anne.
Pour ce prémunir contre l'interception et la réutilisation de la signature par un intrus, elle contient un numéro d'ordre séquentiel unique. Ceci garantit également que Anne ne pourra pas nier avoir envoyé le message (non-répudiation).
1.4 Certificats
Bien qu'Anne ait envoyé un message crypté et signé à Bernard, elle veut être certaine que c'est bien avec Bernard qu'elle communique. Elle veut être certaine que la clé publique qu'elle utilise correspond bien à la clé privée de Bernard. De même, Bernard doit vérifier que la signature du message est bien la signature de Anne.
Si chacun dispose d'un certificat validant l'identité de l'autre, confirmant sa clé publique et signé par une tierce personne de confiance (trusted third party) ou autorité de certification, alors chacun est certain de communiquer réellement avec le bon interlocuteur.
Chacun utilise la clé publique de l'autorité de certification pour contrôler le certificat de l'autre et pour s'assurer de l'authenticité de sa clé publique.
1.5 Autorité de certification
L'autorité de certification (CA pour Certification Authority) signe les certificats avec sa clé privée et permet aux interlocuteurs de vérifier les certificats au moyen de sa clé publique. L'autorité de certification ne doit avoir aucun intérêt commun avec les deux parties en présence.
2. Fonctionnalités d'une PKI
2.1 Création d'une paire de clés et demande de certificat
Anne crée une paire clé publique/clé privée avec un algorithme tel que RSA. Elle crée ensuite une demande de certification (un certificat qui n'est pas encore signé). Le certificat contient des informations sur son identité, ainsi que la clé publique de Anne.
2.2 Signature du certificat
Anne envoie son certificat à une autorité d'enregistrement (RA pour Registration Authority). Cette authorité aprouve ou désaprouve la certification. Si elle est aprouvée, le certificat est envoyé à l'autorité de certification (CA). Le résultat — le certificat signé — est retourné à Alice et stockée sur le serveur de la CA.
Anne peut alors annoncer que sa clé publique est certifiée.
2.3 Chaîne de certification
Bernard, qui veut communiquer avec Anne, lui demande son certificat. Afin de vérifier le certificat, Bernard recherche la clé publique de l'autorité qui a signé le certificat de Anne. Si la clé et le certificat sont chez la même autorité, la recherche est terminée. Sinon, Bernard demande à l'autorité de certification de contacter l'autre autorité pour obtenir sa clé publique. Pour chaque autorité de certification interrogée par Bernard, il doit disposer de la clé publique de l'autorité précédente. Si une chaîne peut être trouvée, aboutissant à l'autre autorité de certification, la recherche est terminée.
2.4 Utilisation typique du cryptage par clé publique
Disposant de la clé publique certifiée de l'autre partie, les interlocuteurs peuvent communiquer entre eux en toute sécurité. Ils peuvent crypter des données et utiliser les signatures digitales. Pour la partir cryptage, la cryptographie par clé publique est trop lente pour permettre le transfert de grandes quantités de données. Un cryptage symétrique est plus approprié. Dans ce cas, une clé de cryptage symétrique est cryptée par clé publique et envoyée à l'autre partie. L'échange peut alors se poursuivre en cryptage/décryptage symétrique classique.
3. PKIX
3.1 Infrastructure de gestion de clés publiques (PKI)
Au coeur des efforts actuels pour améliorer la sécurité de l'internet, on trouve des protocoles tels que S/MIME, TLS ou IPSec. Tous ces protocoles sont basés sur l'emploi de clés publiques. Mais ces protocoles ont besoin d'une infrastructure de clés publiques (PKI) pour fonctionner correctement.
Le rôle d'une PKI est d'offrir une gestion efficace et garantie des clés et des certificats.
Pour contrôler qu'une clé publique appartient bien à l'interlocuteur supposé, on utilise un certificat qui lie une clé publique à une personne, ce lien étant garanti par l'autorité de certification.
Les certificats ont une durée de vie limitée, indiquée dans son contenu. Les ceertificats peuvent être envoyés via des liaisons et des systèmes non sécurisés. Ils sont vérifiés de la manière suivante:
- Le destinataire vérifie que l'identité annoncée par son interlocuteur est bien la même que celle contenue dans le certificat;
- Le destinataire contrôle qu'aucun certificat de la chaîne n'est révoqué et que tous les certificats étaient valides au moment ou les données transmises ont été signées;
- Le destinataure vérifie que les données ont bien des valeur pour lesquelles l'expéditeur est autorisé;
- Le destinataire s'assure que les données n'ont pas été altérées en utilisant la clé publique contenue dans le certificat.
Su tous ces tests sont passés avec succès, le destinataire peut considérer que les données reçues sont bien celles signées au départ par l'expéditeur.
3.2 Infrastructure de gestion de privilèges (PMI)
Beaucoup de systèmes se contente de vérifier l'identité de l'interlocuteur au moyen de certificats et cela est suffisant.
Cependant, de plus en plus de systèmes ont besoin d'une gestion plus fine du contrôle d'accès : rule-based, role-based ou rank-based. Pour prendre des décisions, ces systèmes ont besoin d'informations complémentaires qui ne sont pas véhiculées par le certificat. les certificats d'attributs (AC pour Attribute Certificates) ont été crées à cette fin.
Ce sont des structures de données signées qui permettent d'ajouter des références vers un ou plusieurs certificats spécifiques lorsque le sujet dispose de différentes identités sur le même certificat. De plus, un AC peut être créé de telle manière qu'il ne puisse être utilisé que par un destinataire spécifique.
Les utilisateurs de PMI doivent être assurés non seulement que la clé publique est bien celle de l'interlocuteur (gestion normale des certificats), mais ils doivent aussi être sûr que leur interlocuteur à le droit de posséder tel ou tel attribut.
3.3 L'approche de PKIX
PKIX utilise les termes de PKI et de PMI. Les deux peuvent paraître similaires, mais il existe une différence essentielle: une PKI gère des certificats sur des clés publiques, tandis qu'une PMI gère des certificats sur des attributs.
Une bonne métaphore est le cas d'une personne possédant un passeport et un visa: le premier concerne son identité tandis que le second lui accorde des droits.
3.3.1 Organisation de PKIX
Une PKI est composée de 5 types d'entités:
- Les Autorités de Certification (CA) qui accordent et révoquent les certificats;
- Les Autorités Organisationnelles d'Enregistrement (ORA), qui assurent le lien entre les clés publiques et les détenteurs de certificats.
- Les Détenteurs de Certificats qui signent et cryptent les documents digitaux;
- Les Clients qui valident les signatures digitales et la chaîne de certification;
- Les Repositories qui stockent et mettent à disposition les certificats et les listes de révocation de certificats.
une PMI est composée de 5 types d'entités:
- Les Autorités d'Attributs (AA), qui créent et révoquent les certificats d'attributs;
- Les Utilisateurs de Certificats d'Attributs qui contrôlent et traitent les certificats d'attributs;
- Les Vérificateurs de Certificats d'Attributs qui contrôlent la validité des certificats d'attributs et utilisent le résultat;
- Les Clients qui demandent une action pour laquelle un contrôle d'autorisation doit être réalisé;
- Les Repositories qui stockent et mettent à disposition les certificats d'attributs et les listes de révocation de certificats.
4. Implémentations open source de PKIX
4.1 Autorité de Certification pyCA
PyCa [1] est un ensemble de scripts CGI définissant une interface web pour une Autorité de Certification. Les scripts sont écrits en Python et utilisent OpenSSL comme infrastructure de cryptographie.
pyCA est distribué sous licence GPL.
4.2 Le projet OpenCA
OpenCA [2] est un projet collaboratif pour créer une infrastructure de clés publiques. Ce projet ressemble à pyCA, mais les CGI sont écrits en Perl. Il utilise également OpenSSL pour la cryptographie.
OpenCA est distribué sous une licence de type Apache.
4.3 L'infrastructure de clés publiques Oscar Projet de l'Université de Queensland [3] pour créer une infrastructure de clés publiques. La cryptographie est assurée directement par la librairie GMP et le code est en C++.
Oscar est distribué pour une utilisation non commerciale, mais la licence n'est pas compatible GPL ni Apache.
4.4 Jonah: implémentation freeware de PKIX Jonah [4] est une implémentation freeware du standard PKIX. Jonah est écrit en C++ et utilise des applets Java. Ce projet à été développé à l'origine pour les propres besoins d'IBM, Lotus et Iris.
Il n'existe pas encore de portage sous Linux et est distribué sous une licence spéciale.
4.5 projet Open Source Mozilla PKI
Netscape à créé deux librairies [5], NSS (Network Security Services) et PSM (Personal Security Manager) destinées à unifier le support pour la cryptographie et la sécurité, pour les navigateurs web et les serveurs. Pour plus d'informations sur ces librairies, consulter la Crypto FAQ [6] de Mozilla.
PSM est un module de sécurité indépendant du client. Il réalise les opérations de PKI pour le compte des applications clientes (gestion de clés et de certificats, cryptographie SSL S/MIME).
NSS est un ensemble de librairies permettant le développement cross-plateforme de servers sécurisés (SSL v2 v3, TLS, PKCS, S/MIME, etc.)
Ces librairies sont couvertes par la licence Mozilla Public Licence et par la GPL, au choix.
À suivre…