Infrastructures De Gestion De Clefs(igc)

Infrastructures de gestion de clefs Nicole Dausque [email protected] 09/05/2000 Public Key Infrastructure (PKI) que l’on peut traduire par Infrastructures à Clefs Publiques (ICP) ou encore Infrastructures de Gestion de Clefs (IGC) : que se cache-t-il derrière ces trois sigles ? L’article qui suit tente de lever le voile sur les différents éléments sur lesquels s’appuient les IGC (c’est cet acronyme qui sera retenu tout au long de l’article). Mais cet article ne se veut en aucun cas un exposé sur la législation actuelle, un cours sur la cryptographie ou une étude comparative sur les organismes de certification ; les références citées permettront d’obtenir des informations précises sur ces différents sujets. On pourra également se reporter à l’article de Jean-Luc Archimbaud traitant des raisons qui ont conduit l’UREC [REFurec] à la mise en service d’une plate-forme de test d’une autorité de certification pour le CNRS (http://www.urec.cnrs.fr/securite/articles/CA.CNRS-Test.pdf).

Un nouveau cadre réglementaire Depuis deux ans on assiste à une évolution, presque une révolution, dans l’environnement législatif [REFlegi] sur la réglementation en matière de cryptographie (« art de produire des messages secrets »), donc a fortiori tout le contexte authentification et confidentialité. Un premier élargissement est apparu suite aux deux Décrets du 24 février 1998 : • N°98-101 définissant les conditions dans lesquelles sont souscrites les déclarations et accordées les autorisations concernant les moyens et prestations de cryptologie («art des messages secrets»). Trois régimes étaient alors mis en place en fonction de l’usage et de la provenance des moyens ou des prestations de cryptologie : libre d’utilisation, assujetti à déclaration et assujetti à autorisation. • N°98-102 définissant les conditions dans lesquelles sont agréés les organismes gérant pour le compte d’autrui des conventions secrètes de cryptologie. Il précise également les obligations auxquelles sont soumis les organismes agréés (ou «tiers de confiance» ou «tiers de séquestre»). Les derniers Décrets du 17 mars 1999 assouplissent les régimes de déclaration et d’autorisation et surtout donne dans certains cas une totale liberté d’utilisation des moyens de cryptologie : • N°99-199 définissant les catégories de moyens et de prestations de cryptologie pour lesquelles la procédure de déclaration préalable est substituée à celle d’autorisation. • N°99-200 définissant les catégories de moyens et de prestations de cryptologie dispensées de toute formalité préalable Gobalement on peut résumer les possibilités ainsi : Ø liberté d’utilisation pour authentification, intégrité et non-répudiation (applicable à la signature électronique) Ø liberté, déclaration ou autorisation pour utilisation dans le cadre de la confidentialité (applicable au chiffrement) suivant la longueur des clefs :

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

1

< 40 bits Aucune formalité

40 à 128 bits Dispense de formalité si à usage exclusivement privé ou si déclaration préalable du fournisseur

> 128 bits nécessite une autorisation

Ø dans le cas de la fourniture : clefs ≤ 128 bits à déclaration clefs> 128 bits à autorisation Enfin à ces décrets s’ajoute l’Arrêté du 17 mars 1999 définissant la forme et le contenu du dossier concernant les déclarations ou demandes d’autorisation relatives aux moyens et prestations de cryptologie [REFchif]. Dans un domaine d’application de la cryptologie, qui aura une grande influence dans l’évolution de la communication de documents électroniques, un projet de loi, annoncé le 1er septembre 1999, « portant adaptation du droit de la preuve aux technologies de l’information et relatif à la signature électronique » est passé en première lecture au Sénat le 08 février 2000 et a été adopté définitivement, par l’Assemblée Nationale le 29 février 2000 [REFjust]. Il est à noter également une Directive Européenne sur la valeur légale de la signature électronique qui a été adoptée le 13 décembre 1999 [REFeuro]. Pour le futur la tendance est d’une part une libéralisation complète de l’utilisation de la cryptologie, d’autre part la suppression à terme de l’obligation de recourir à des organismes agréés de séquestre de clefs mais avec obligation, sur demande des autorités judiciaires, de remise des textes en clair. On voit donc qu’actuellement la législation évolue rapidement (l’enjeu étant bien sûr le commerce électronique). On peut donc penser que cela influencera beaucoup les développements technologiques de l’outil informatique du chercheur.

Les bases de la cryptographie Les techniques de la cryptographie [REFtech] sont déjà éprouvées, les premiers algorithmes sur lesquels elle repose étant apparus dans les années soixante dix. Ces algorithmes sont basés sur des mécanismes de transposition et/ou de rotation de blocs de caractères de longueur fixes avec application de fonctions mathématiques et utilisation d’opérateurs logiques de type « ou exclusif ». Ces algorithmes sont publics, la validité de la technique repose sur l’utilisation de clefs secrètes. Les algorithmes les plus utilisés actuellement sont : ü DES (« Data Encryption Standard » 1974) [REFnist], triple-DES (1985) à clefs symétriques ü RSA (Rivest, Shamir, Adleman 1978) (RFC2437) [REFrfcs] à clefs asymétriques ü RC4, RC5 (« Rivest's Code #4, #5 » 1987) à clefs symétriques ü IDEA (« International Data Encryption Algorithm » 1992) [REFidea] à clefs symétriques ü Blowfish (1993) [REFblow] à clefs symétriques ü AES (« Advanced Encryption Standard » 1997 en cours de développement et qui correspond à une standardisation) [REFnist, REFaes.] à clefs symétriques ü MD5 (« Message Digest#5 » 1992) (RFC1321) [REFrfcs], SHA-1 (« Secure Hash Algorithm » 1993) [REFnist] pour les fonctions de hachage.

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

2

Ces algorithmes mettent en jeu des mécanismes de clefs, celles-ci sont soit symétrique soit asymétrique. Dans le premier cas l’utilisation entraîne la notion de « sphère de confiance pour leur partage », dans le second cas on a la notion de bi-clef (couple de clef privée/clef publique) il y a alors nécessité de « certification et gestion de clefs publiques ». Clef symétrique : texte en clair à envoyer

Algorithme de chiffrement

Algorithme de déchiffrement

Emission du texte brouillé

Clef secrète

texte en clair retrouvé

Clef secrète Echange = « Sphère de confiance »

ð il y a partage d’un secret entre les protagonistes : la clef secrète

Clef asymétrique : texte en clair à envoyer

Algorithme de chiffrement

Emission du texte brouillé

Clef publique

Algorithme de déchiffrement

texte en clair retrouvé

Clef privée Bi-clef

Publication de clefs publiques

ð il n’y a pas partage d’un secret entre les protagonistes : la clef privée n’est connue que de son propriétaire, la clef publique est accessible à tous mais il n’y a pas de technique simple permettant de retrouver la clef privée à partir de la clef publique. Actuellement dans l’utilisation courante, la clef peut s’apparenter à un mot de passe qui ne circule pas sur le réseau. Au futur la carte magnétique style « vitale » et les équipements de lecture adéquats se généralisant, ils seront le support des clefs. Les algorithmes et les clefs sont utilisés pour produire la signature électronique et le chiffrement de messages ou de données.

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

3

L’action de signer assure : identification, authentification, intégrité et nonrépudiation : Ø identification et authentification : afin de prouver que la provenance de l’information est bien celle qu’elle dit être ; Ø intégrité : afin de s’assurer qu’il n’y a pas eu altération et falsification de l’objet émis ; Ø non-répudiation (ou non-désaveu) : afin qu’émetteur et récepteur de l’objet ne puissent nier l’émission et la réception de l’objet. L’action de chiffrer assure la confidentialité. Cela consiste à transformer un texte en clair en un texte brouillé qui sera dit chiffré.

Mécanismes utilisés En utilisant les bases exposées précédemment, les mécanismes de signature et de chiffrement permettent d’assurer les fonctions : d’authentification, de scellement, de nonrépudiation, de confidentialité. Signature : La signature est une empreinte chiffrée que l’on ajoute au message. Il existe une relation biunivoque entre l’objet signé et la signature qui l’accompagne. La fonction de hachage utilisée pour réaliser ce scellement, est telle qu’il est impossible de reconstruire l’objet initial à partir de son empreinte, et d’obtenir une empreinte équivalente pour deux objets initialement différents :

Création de la signature :

hachage

empreinte

Message à émettre Clef privée émetteur

algorithme à clef asymétrique

ð la signature numérique est obtenue en chiffrant l’empreinte du message avec la clef privée de l’émetteur ; pour un bi-clef donné, seule la personne possédant la clef privée pourra signer le message.

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

4

Vérification de signature :

empreinte

hachage

Message reçu

fonction de vérification empreinte reçue

Signature valide ou non valide

algorithme à clef asymétrique

Clef publique émetteur

ð la clef publique de l’émetteur appliquée à la signature accompagnant le message restituera l’empreinte réalisée à l’envoi du message qui sera comparée à l’empreinte du message reçu. Si la clef publique n’est pas celle qui correspond au bi-clef de l’émetteur, l’empreinte ne pourra être restituée et la signature sera reconnue comme invalide. Si le message reçu a été altéré, l’empreinte sera différente. Ces diverses opérations permettent authentification de l’auteur du message, non-répudiation et vérification de l’intégrité du message. Chiffrement : document

Clef publique récepteur

algorithme à clef asymétrique

document brouillé

Déchiffrement : Clef privée récepteur

algorithme à clef asymétrique

document

ð seul le destinataire du document sera en mesure de déchiffrer le document puisque lui seul possède la clef privée appartement au même bi-clef. La confidentialité est respectée. Les extensions :

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

5

Elles consistent à utiliser les mécanismes signature et/ou chiffrement de façon récursive. ü signatures multiples La fonction signature appliquée récursivement est un mécanisme qui est utilisé dans les IGC (notion de « contre-signature ») : Message

Signature1 Signature2 …

ü chiffrement et signature Afin d’assurer la confidentialité d’un message signé, la fonction chiffrement est alors appliquée, et ceci récursivement : Message

Signature1 chiffrement…

ü utilisation de clefs de session Les algorithmes à clefs asymétriques sont plus lents que les algorithmes à clefs symétriques, aussi lorsque l’on veut chiffrer un message long on a plutôt recours à des algorithmes symétriques utilisant des clefs de sessions symétriques à durée de vie limitée. L’envoi de la clef de session se fait chiffrer à l’aide de la clef publique du destinataire, afin d’assurer sa confidentialité.

Les standards L’évolution de l’utilisation de la cryptographie est également liée aux développements de plusieurs standards (ou standards de fait…) : ü PKCS « Public-Key Cryptography Standards » [REFpkcs, REFrfcs] est un ensemble de standards pour la mise en place des IGC, coordonné par RSA [REFrsa.] ; ces standards définissent les formats des éléments de cryptographie : o PKCS#1 : RSA Cryptography Specifications Version 2 (RFC 2437) o PKCS#2 : inclus dans PKCS#1 o PKCS#3 : Diffie-Hellman Key Agreement Standard Version 1.4 o PKCS#4 : inclus dans PKCS#1 o PKCS#5 : Password-Based Cryptography Standard Version 2 o PKCS#6 : Extended-Certificate Syntax Standard Version 1.5 o PKCS#7 : Cryptographic Message Syntax Standard Version 1.5 (RFC2315) o PKCS#8 : Private-Key Information Syntax Standard Version 1.2 o PKCS#9 : Selected Attribute Types Version 2.0 o PKCS#10 : Certification Request Syntax Version 1.7 or Certificate Signing Request (CSR) (RFC 2314) o PKCS#11 : Cryptographic Token Interface Standard Version 2.10 o PKCS#12 : Personnal Information Exchange Syntax Standard Version 1.0 o PKCS#13 : Elliptic Curve Cryptography Standard Version 1.0 o PKCS#14 : Pseudorandom Number Generation Standard Version 1.0 o PKCS#15 : Cryptographic Token Information Format Standard Version 1.1

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

6

ü IPSEC « IP SECurity protocol » (1995) (RFC2401, RFC2402, RFC2406…) [REFipsk, REFipsc, REFrfcs] offre les possibilités d’authentification des intervenants et de chiffrement, dans la communication entre routeurs ou stations IP ; le protocole supporte les VPNs « Virtual Private Network » ; mais les implantations sont propriétaires, ce qui nuit à l’interopérabilité. ü SSL « Secure Socket Layer » (V3 – 1996) [REFssl.] développé par Netscape, permet l’authentification par certificat du serveur et du client lors de la transaction ; il offre la possibilité de génération de clefs, chiffrement et fonction de hachage ; le transport des données de l’application se fait via un canal sécurisé ; les applications Web (HTTPS), ftp, telnet et messagerie sécurisée (S/SMTP) peuvent implémenter ce standard ; l’extension TLS « Transport Layer Security » (1997) [REFtls.] offre directement au niveau de la couche transport les fonctionnalités authentification, intégrité et confidentialité. ü ISAKMP « Internet Security Association and Key Management Protocol » (1998) [REFisak] (RFC2407, RFC2408, RFC2409) [REFrfcs] est un protocole qui offre la possibilité de réaliser la négociation des algorithmes et des clefs avant la transaction proprement dite des données ; il permet l’échange des clefs et l’authentification des intervenants via le protocole Oakley (RFC2412) [REFrfcs]. L’ensemble donne IKE « Internet Key Exchange ». ü S-MIME « Multi purpose Internet Mail Extensions » (V3 – 1999) [REFmime] (RFC2633) [REFrfcs] offre authentification, intégrité, et non-répudiation de l’origine ainsi que la confidentialité de messages électroniques ; il est supporté par Netscape, Lotus, Microsoft. ü SET « Secure Electronic Transaction » (V1 – 1997) [REFset.] est orienté commerce électronique mais les applications sont propriétaires ; c’est un standard qui entre dans le projet Cybercom (projet commun entre les principales banques françaises, La Poste, carte Visa, Certplus). Ces standards affectent les différentes couches du modèle OSI. Certains peuvent se situer à différents niveaux (exemple : ISAKMP avec les fonctionnalités IKE en « couche basse » de la couche application) : 7 6/5 4 3

Applications sécurisées Session/présentation sécurisées Transport En-têtes IP de sécurité

https, ssmtp, ssl-ldap SSL TLS IPsec

Tous ces standards, associés aux possibilités offertes par la législation et la cryptographie peuvent être mis en jeu dans le déploiement des IGC.

Gestion des clefs L’utilisation de bi-clef entraîne la nécessité de publication, en toute confiance, de la clef publique. Cette publication doit offrir l’assurance que : • la clef est bien celle appartenant à la personne avec qui les échanges sont envisagés ; • le possesseur de cette clef est « digne de confiance » ; • la clef est toujours valide. La confiance est obtenue en associant au bi-clef un certificat délivré et géré par une entité elle-même de confiance : l’Infrastructure de Gestion de Clefs. Une IGC [REFpkix, REFpkis] (RFC1422, RFC2459, RFC2510, RFC2527, RFC2559, RFC2560, RFC2585,…) [REFrfcs] est donc une structure à la fois technique et administrative permettant une mise en

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

7

place, lors de l’échange de clef, de relations de confiance entre des entités morales et/ou physiques et/ou logiques. Le certificat est un document électronique, résultat d’un traitement fixant les relations qui existent entre une clef publique, son propriétaire (une personne, une application, un site) et l’application pour laquelle il est émis : • pour une personne il prouve l’identité de la personne au même titre qu’une carte d’identité, à la différence que celui ci n’est pas national mais à hauteur de l’autorité de certification qui l’a validé ; • pour une application il assure que celle-ci n’a pas été détournée de ses fonctions ; • pour un site il offre la garantie lors d’un accès vers celui-ci que l’on est bien sur le site auquel on veut accéder. Le certificat s’appuie sur un protocole normalisé X509 (ITU-T X.509 international standard V3 - 1996) (RFC2459) [REFrfcs, REFuitt] qui permet d’associer à la clef des informations spécifiques à l’entité (physique ou morale) à laquelle elle se rapporte (informations s’ajoutant aux informations de bases que sont : numéro de version, numéro de série, algorithme de signature, période de validité… contenues dans un certificat X509). La publication des certificats (donc a fortiori des clefs publiques) est faite en utilisant des structures d’annuaires [REFannu] de type LDAP « lightweight Directory Access Protocol » (RFC2251) [REFldap]. Les certificats révoqués sont regroupés dans des listes (CRL « Certificate Revocation List ») qui sont des structures de données signées et dont le format est défini par le protocole X509 V2 CRL (RFC2459) [REFrfcs] ; ce format peut permettre une distribution des CRL via les annuaires LDAP. Certaines implantations, celle de Netscape par exemple [REFnets] font également apparaître la notion de « fingerprint » de certificat ; c’est une empreinte MD5 du certificat, qui permet de vérifier que celui-ci est le bon.

Gestion des clefs

APPLICATIONS

Annuaires SERVEURS

Gestion des certificats

LDAP CLIENTS messagerie, www…

Les informations spécifiques minimales entrant dans la composition du certificat : nom du propriétaire, durée de validité du certificat sont complétées par celles relatives à l’autorité qui les a validées. Cette autorité, offrant toute confiance, et ayant elle-même un certificat (par auto-certification ou cautionnée par une autre autorité) se nomme Autorité de Certification. La crédibilité (garantie) est assurée par le mécanisme de signature. La signature du certificat est calculée par l’autorité de certification en prenant en compte la clef publique du demandeur, son identification et des informations complémentaires ; celle-ci génère ce certificat en signant avec sa clef privée. Le mécanisme de vérification du certificat est

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

8

identique à celui utilisé pour vérifier une signature, c’est la clef publique de l’autorité de certification qui sera ensuite utilisée par le destinataire. Cependant cette vérification de certificat dépend de la connaissance que l’on a de l’autorité de certification qui l’a émis : la confiance est absolue si on a accès directement à la clef publique de l’autorité, sinon il faut accepter de passer par une autre autorité ayant elle-même certifié la clef publique de l’autorité émettrice du certificat. Le problème réside en la confiance que l’on peut apporter à une autorité de certification disjointe ; en effet la confiance est matérialisée par le certificat or s’il est construit sur des informations subjectives la certification croisée peut être compromise. De plus il existe rarement une interopérabilité entre les annuaires. L’autorité de certification peut se situer à différents niveaux, elle peut être organisationnelle (exemple : CNRS) ou spécifique à un corps de métiers (exemple : notaire) ou encore institutionnelle et dans ce cas pouvoir cautionner au niveau national des autorités subalternes ; elle est alors nommée autorité racine.

autorité de certification organisationnelle 1

Relations de confiance

autorité de certification organisationnelle 2

Si interopérabilité

Relations hiérarchiques

Autorité subalterne

Autorité subalterne

Autorité subalterne

Autorité subalterne

Il n’est pas obligatoire que les certificats émis par ces différentes entités soient construits avec les mêmes informations. L’autorité de certification s’appuie généralement sur deux autres entités qui travaillent par délégations : l’Autorité d’Enregistrement et l’Opérateur de Certification. Cependant elle garde la responsabilité des procédures et des principes de certification ; c’est elle qui fait appliquer la politique de certification et elle est responsable pour ses utilisateurs du niveau de confiance fourni par l’IGC. L’autorité d’enregistrement assure le contrôle des données identifiant le demandeur de certificat ; c’est elle qui authentifie une demande de révocation qui sera ensuite exécutée par l’autorité de certification ; elle assure lors de la délivrance d’un nouveau certificat (sur date de péremption atteinte) un recouvrement des certificats afin d’assurer la continuité pour la fonctionnalité signature et/ou chiffrement ; elle travaille en étroite collaboration avec l’opérateur de certification ; elle possède un bi-clef certifié pour s’authentifier auprès de l’autorité de certification et pour accomplir les tâches qui lui incombent. L’opérateur de certification réalise la distribution sécurisée des certificats ; il gère en collaboration avec l’autorité d’enregistrement les cycles de vie des certificats ; en fonction de la politique de certification ce peut être lui qui génère les bi-clefs pour le compte des utilisateurs ; il possède un bi-clef certifié pour s’authentifier auprès de l’autorité de certification et pour accomplir les tâches qui lui incombent.

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

9

…

AE : Autorité d’enregistrement

OC : Opérateur de certification (création, gestion des

(vérification et enregistrement des demandes…)

certificats et des clefs associées…)

Certificat pour une application spécifique

AC : Autorité de certification (responsabilité, reconnaissance globale…)

Les principales fonctions réalisées par les IGC pour la gestion des certificats se résument ainsi : Ø enregistrement de demande et vérification des critères pour attribution d’un certificat : l’identité du demandeur est vérifiée ainsi que le fait qu’il soit bien en possession de la clef privée associée Ø création des certificats Ø diffusion des certificats entraînant publication des clefs publiques Ø archivage des certificats pour assurer la sécurité et la pérennité Ø renouvellement des certificats en fin de période de validité Ø suspension de certificats : elle peut être utile si le propriétaire estime ne pas avoir besoin temporairement de son certificat ; cependant cette fonction n’est pas aisée à mettre en œuvre ; elle est essentiellement administrative et il n’existe pas de standard d’implémentation Ø révocation de certificats : sur date de péremption, perte, vol ou compromission de clefs Ø création et publication (au sens gestion) des listes de révocation des certificats ; il y aura révocation du certificat dans les cas suivants : date de fin de validité atteinte, clef privée divulguée, perdue (donc impossibilité de lire les objets rendus confidentiels) ou compromise. Il n’existe aucun protocole standard qui permette de faire la révocation automatiquement, on a donc forcément recours à des moyens administratifs. Ceux-ci doivent être implantés avec un maximum de sécurité (le demandeur de la révocation doit en particulier prouver qu’il est bien le propriétaire de la clef publique ou privée devenue inutilisable). Les listes de révocation doivent d’une part être protégées pour éviter toute corruption, d’autre part être accessibles en permanence et le plus à jour possible (notion de temps réel). Pour un fonctionnement correct, cette fonction nécessite une synchronisation des horloges de tous les acteurs concernés par les listes de révocation. Infrastructures de gestion de clefs

ND ~ CNRS/UREC

10

Ø délégation de pouvoir à d’autres entités reconnues de confiance Toute communauté peut créer sa propre IGC, dans ce cas une étude de faisabilité est nécessaire en s’appuyant sur de nombreux critères.

Critères pour construire une IGC De même que la sécurité se met en place en suivant une politique de sécurité définie préalablement, la mise en place d’une IGC oblige à une définition de politiques de certification : « un ensemble de règles indiquant, ce pour quoi le certificat est applicable et par qui, et quelles sont les conditions de leur mise en œuvre au sens juridique administratif et technique ». La règle de base étant avant tout que les certificats et les moyens de mise en œuvre soient définis en fonction de l’utilisation que l’on veut en faire. Les facteurs principaux à prendre en compte sont : • Étude de la population/des utilisateurs à qui est destiné le certificat en tenant compte à la fois des caractéristiques des utilisateurs, de l’utilisation qui sera faite du certificat (signature, chiffrement entre entités morales et/ou physiques, accès à des applications sécurisées) et de la mise en place des critères d’attribution. • Étude des moyens de collecte des informations, de leur validation et de la création des certificats. • Définition de la durée de vie des clefs (privée, publique et/ou de session), des certificats, de la consolidation de ceux-ci, de la gestion des listes de révocations. • Étude des moyens de distribution des certificats via des communications sécurisées de type « VPN » ou sur un support style « carte de crédit » avec récupération en main propre ou par un agent de sécurité sur site. • Sécurité des IGC au sens implantation physique, et sécurité des annuaires supports des informations publiques en tenant compte de l’infrastructure, de l’administration et du coût de gestion. • Définition des services nécessitant une haute disponibilité (exemple : gestion des listes de révocation). • Prise en compte de la nécessité d’un recouvrement des clefs privées et de l’interaction avec l’autorité suprême et/ou avec d’autres communautés (interopérabilité pour certifications croisées). • Étude du support matériel/logiciel du certificat chez l’utilisateur en tenant compte de la vétusté des postes de travail et en prévoyant des évolutions aisées. • Prise en compte de l’impact sur les structures existantes : physiques et organisationnelles. • Définition de la formation/information des acteurs. Tous ces critères sont normalement pris en compte dans les offres commerciales existant à ce jour, cependant celles-ci restent très orientées commerce électronique.

Offres commerciales en France A ce jour, plusieurs offres commerciales existent : • Certplus [REFcerp] regroupe Verisign, Matra, France Telecom, Gemplus. • MATRAnet [REFmatr] qui s’appuie sur des routeurs chiffrants, garde-barrière et VPN et qui a également une offre logicielle.

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

11

• Atos France [REFatos] sur la base de la carte « Securicam » à microprocesseur propose une offre qui ne nécessite pas de tiers de confiance ni d’annuaire et qui s’appuie sur l’auto certification au sein d’une communauté. • Thomson offre des solutions de mise en place d’IGC autour d’une architecture sécurisée (VPN, messagerie, accès sécurisé aux postes de travail). • Gemplus [REFgemp] est très orienté personnalisation des cartes à puce à microprocesseur, avec à l’avenir la carte à puce utilisable pour tout et par tous mais obligeant cependant à de nouveaux équipements (lecteur) et à des ajouts de code dans les applications. L’offre « GemSAFE » est une solution complète de déploiement d’IGC. • Certinomis [REFceti] regroupant La Poste, les chambres de commerce et SAGEM.

En conclusion Dans l’article il n’est fait mention que d’un seul bi-clef utilisable pour toutes les fonctions à réaliser. Cependant il s’avère que si l’on veut être plus rigoureux dans la gestion des clefs, il sera nécessaire de différencier les bi-clefs en fonction de leur utilisation : ü Pour le chiffrement, la perte ou la compromission ou toute autre indisponibilité de la clef privée entraîne une indisponibilité de l’objet chiffré. Il est nécessaire de prévoir des moyens de recouvrement de clefs afin d’assurer la récupération des objets chiffrés. ü Pour la signature, la perte de la clef privée n’entraîne pas une indisponibilité de l’objet qui a été signé, de plus il ne faut pas qu’une signature puisse être générée au nom d’une autre personne ; il ne doit donc pas y avoir de recouvrement de la clef privée pour un bi-clef de signature. ü Pour échanger des clefs on peut être amené à les chiffrer à l’aide de bi-clefs d’échange de clef afin de les protéger. Le recouvrement de ce bi-clef est nécessaire au même titre que celui du bi-clef de chiffrement. Nous avons donc vu que L’IGC intègre cryptographie à clef publique et certificat numérique, elle peut s’apparenter à des tiers de confiance ou tiers de séquestre et doit recevoir l’agrément du SCSSI [REFscss, REFigcs] pour avoir une portée nationale. On parlera alors d’habilitation ou « labellisation » des IGC mais aussi des produits de chiffrement, si on veut avoir une confiance réelle en ces produits. Le support des clefs et des certificats de l’utilisateur final devra également être reconnu « de qualité » au sens sécurité pour une mise en place de la reconnaissance de la signature électronique comme « droit à la preuve ». Actuellement l’absence de standards pour l’implantation des listes de révocation est un frein à l’utilisation aisée des certificats et à la mise en œuvre d’IGC ; le seul protocole existant : OCSP « Online Certificate Status Protocol » (RFC2560) [REFrfcs] ne possède à ce jour aucune implémentation. L’obligation de remise « du clair » d’un document, aux autorités nationales soulève le problème de la mise en place d’organismes « d’extrême confiance » gardant sous haute protection un double des clefs privées. Cette nouvelle organisation nécessite de gérer dans le temps les certificats. L’évolution des IGC suivra donc la législation, ainsi lorsque la signature électronique sera admise comme « droit à la preuve » dans tous les domaines, toute la chaîne menant à la fabrication d’un certificat et tout le processus conduisant à signer devra être reconnu comme « infaillible » ; se posera alors le problème de conservation de la signature prouvant la validité d’un document pendant toute sa durée de vie ; il y aura nécessité de conserver une référence « temps » au moment de la signature afin que la validation soit possible à tout moment. La

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

12

fonction « horodatage » doit d’ores et déjà est incluse dans les fonctionnalités supportées par les IGC. La fonction signature se traduira alors par le triplet : {message,signature,date}. Même si tous les ingrédients sont là pour construire une IGC, il faut être prudent car d’une part cela ne s’improvise pas, d’autre part les technologies sont loin d’être mûres et rodées [REFetat]. Une IGC c’est 70% d’organisationnel, 20% de technique et 10% d’aléatoire… et pour que l’échange en mode sécurisé fonctionne il semble nécessaire d’empiler toutes ces couches :

gestion des structures gérant les certificats gestion des certificats certificats clefs et algorithmes scellement, chiffrement, … échange en mode sécurisé

Plus d’informations [REFurec] http://www.urec.cnrs.fr/securite/ [REFlegi] http://www.legifrance.gouv.fr/ [REFchif] http://www.scssi.gouv.fr/present/chiffre/liste.html [REFjust] http://www.justice.gouv.fr/publicat/signelec.htm [REFeuro] http://europa.eu.int/comm/internal_market/fr/media/sign/index.htm [REFtech] http://www.cnam.fr/www2/cours/crypto/cryptographie.html http://www.ens.fr/~wwwgrecc/Recherche/Crypto/ http://ballesta.inrialpes.fr/~riveill/cours/ensimag3-GLSI/cryptographie/cryptographie.html [REFnist] http://csrc.nist.gov/pki/nist_crypto/welcome.html [REFrfcs] http://www.ietf.org/rfc.html http://www.pasteur.fr/infosci/RFC/ http://www-lor.int-evry.fr/~pascal/RFC/index.html ftp://ftp.ietf.org/rfc/ [REFidea] http://www.egr.msu.edu/~qinyong/ece813/IDEA.htm [REFblow] http://www.counterpane.com/blowfish.html [REFaes.] http://csrc.nist.gov/encryption/aes/ [REFpkcs] http://www.rsasecurity.com/rsalabs/pkcs/ [REFrsa.] http://www.rsasecurity.com/rsalabs/ [REFipsk] http://www.ietf.org/html.charters/ipsec-charter.html [REFipsc] http://www.hsc.fr/ressources/veille/ipsec/index.html.fr [REFssl.] http://developer.netscape.com/tech/security/ssl/howitworks.html Infrastructures de gestion de clefs

ND ~ CNRS/UREC

13

http://home.netscape.com/eng/ssl3/ssl-toc.html http://www.counterpane.com/ssl.html [REFtls.] http://www.ietf.org/html.charters/tls-charter.html [REFisak] http://www.ietf.org/internet-drafts/ [REFmime] http://www.imc.org/ietf-smime/ [REFset.] http://www.setco.org/ [REFpkix] http://csrc.ncsl.nist.gov/pki/ http://csrc.ncsl.nist.gov/pki/documents/welcome.html [REFpkis] http://www.hsc.fr/ressources/presentations/pki/index.html.fr [REFuitt] UIT-T X509, ISO9594-8, OSI, ANNUAIRES, cadre général d’authentification http://www.itu.int/ http://www.itu.int/search/wais/Macbeth/#HowtoSearch [REFannu] http://www.mtic.pm.gouv.fr/dossiers/documents/lat/annuaires.shtml [REFldap] http://www.ietf.org/rfc/rfc2251.txt [REFnets] http://home.netscape.com/eng/security/ssl_2.0_certificate.html [REFcerp] http://www.certplus.com/ REFmatr] http://www.matranet.com/products/index.html [REFatos] http://www.ii.atos-group.com/francais/ [REFgemp] http://www.gemplus.com/french/index.htm [REFceti] http://www.certificat.com/ [REFscss] http://www.scssi.gouv.fr/ [REFigcs] http://www.scssi.gouv.fr/document/igc.html [REFetat] http://www.mtic.pm.gouv.fr/dossiers/documents/MTIC_certification_et_icp.pdf à lire également : Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier http://www.counterpane.com/pki-risks.html

Infrastructures de gestion de clefs

ND ~ CNRS/UREC

14