Infrastructures de gestion de clefs

Nicole Dausque
Nicole.Dausque@urec.cnrs.fr
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 40 à 128 bits > 128 bits
Aucune formalité Dispense de formalité si à nécessite une autorisation
usage exclusivement privé
ou si déclaration préalable
du fournisseur

Ø 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 à texte en
envoyer Algorithme de Algorithme de clair
chiffrement Emission du texte déchiffrement retrouvé
brouillé

Clef secrète 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 à texte en
Algorithme de Algorithme de clair
envoyer chiffrement déchiffrement
Emission du texte retrouvé
brouillé

Clef publique 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 non-
ré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 non-
ré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 à
algorithme à
émettre
clef
Clef privée asymétrique
émetteur

ð 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 :

hachage empreinte
Message reçu

fonction de
vérification
empreinte
reçue

Signature valide
ou non valide
algorithme à
clef
Clef publique
asymétrique
é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 algorithme à

récepteur clef
asymétrique

document brouillé

Déchiffrement :

algorithme à
document
Clef privée clef
récepteur asymétrique

ð 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 Applications sécurisées https, ssmtp, ssl-ldap

6/5 Session/présentation sécurisées SSL
4 Transport TLS
3 En-têtes IP de sécurité 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 LDAP
certificats
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 autorité de
certification certification
organisationnelle 1 Relations de confiance 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
(vérification et enregistrement des certification (création, gestion 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-GL-
SI/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