Les PKI : Vers une Infrastructure

Globale de Sécurité ?

LIVRE BLANC

Novembre 2001
Ce document a été rédigé par Laurent Bellefin, Directeur de l’Activité Sécurité et l’ensemble
des consultants Sécurité de SoluCom.

Première publication : Novembre 2001

Date de dernière révision : Novembre 2001

Publié par SoluCom

2, boulevard Vauban
78180 Montigny le Bretonneux
France

Tél : +33 (1) 30 43 35 00

Fax : +33 (1) 30 44 36 40
e-mail pki@solucom.fr
Internet : http://www.solucom.fr

 2001 - SoluCom

Tout droits réservés. Ce document ne peut être reproduit et/ou diffusé en tout ou partie
sans l’autorisation de SoluCom

Les informations contenues dans ce document sont susceptibles d’être modifiées sans
préavis par SoluCom. Elles sont données uniquement à titre indicatif, et SoluCom ne
saurait être tenue pour responsable de l’usage qui en sera fait.

Les marques et noms déposés qui sont cités dans ce document appartiennent à leurs
propriétaires respectifs.

Page 2 LES PKI - LIVRE BLANC

PREAMBULE
Ce livre blanc a pour objectif de présenter les différentes facettes des infrastructures à clé publique
(ICP ou PKI – Public Key Infrastructure). Il est destiné à toute personne désirant avoir une vision sur
les concepts et les technologies utilisées par les PKI, les services offerts, l’utilisation de la PKI par les
applications, les acteurs du marché et la démarche de mise en place.

Il est complété par un document de synthèse (Livre blanc – Synthèse) qui reprend les points clés du
présent document.

Le chapitre 1 est une introduction au livre blanc.

Le chapitre 2 décrit les concepts de base (cryptographie asymétrique, certificats, Autorité de

Certification) sur lesquels reposent les PKI.

Le chapitre 3 présente plus en détail les fonctions et les processus de fonctionnement d’une
PKI (création, gestion et validation des certificats, notariat…)

Le chapitre 4 présente les possibilités de création de vastes domaines de confiance en

« interconnectant » plusieurs PKI.

Le chapitre 5 explique les impacts organisationnels et décrit les documents normatifs servant
de base à toute PKI (politique de certification, déclaration des pratiques de certification). Il présente
aussi les principales notions relatives au cadre juridique actuel dans le domaine de la signature
électronique.

Le chapitre 6 décrit l’utilisation des certificats par les principaux types d’applicatifs et les
initiatives actuelles notamment dans le domaine du commerce électronique et des relations avec
l’administration.

Le chapitre 7 présente le marché actuel des PKI (produits, acteurs…).

Le chapitre 8 traite de la stratégie de mise en œuvre (composantes du projet, démarche de

construction).

Toutes vos remarques seront les bienvenues. Merci de les adresser à pki@solucom.fr .

Page 3 LES PKI - LIVRE BLANC

 TABLE DES MATIERES

PRÉAMBULE 3

1. INTRODUCTION 6

2. CONCEPTS DE BASE DE LA PKI 7

2.1. PRINCIPES DE CRYPTOGRAPHIE 7

2.1.1. CRYPTOGRAPHIE À CLÉ SECRÈTE 7
2.1.2. CRYPTOGRAPHIE À CLÉ PUBLIQUE 8
2.2. CERTIFICATS DE CLÉ PUBLIQUE 10
2.3. GESTION DES CLÉS ET DES CERTIFICATS PAR LA PKI 11

3. FONCTIONNEMENT DE LA PKI 12

3.1. CRÉATION DES CERTIFICATS 12

3.1.1. FONCTIONNALITÉS SOUS LA RESPONSABILITÉ DE LA RA 12
3.1.2. FONCTIONNALITÉS SOUS LA RESPONSABILITÉ DE LA CA 14
3.2. RENOUVELLEMENT ET RÉVOCATION DES CERTIFICATS 16
3.3. VALIDATION DES CERTIFICATS 18
3.4. AUTRES SERVICES (RECOUVREMENT, HORODATAGE ET NOTARIAT) 21
3.5. SYNTHÈSE 22

4. INTERCONNEXION DES PKI 23

5. POLITIQUE DE CERTIFICATION ET CADRE LÉGAL 25

5.1. PROCESSUS ET CLASSES DE CERTIFICATS 25

5.2. PC ET DPC 26
5.3. RECONNAISSANCE LÉGALE DE LA SIGNATURE ÉLECTRONIQUE 27

6. UTILISATION DE LA PKI 29

6.1. PROTOCOLES DE SÉCURISATION DES ÉCHANGES 29

6.1.1. SÉCURITÉ AU NIVEAU RÉSEAU : IPSEC 30
6.1.2. SÉCURITÉ DES ÉCHANGES WEB : SSL ET TLS 30
6.1.3. WTLS POUR LES MOBILES 31
6.1.4. S/MIME POUR LA MESSAGERIE 31
6.1.5. XML-DSIG POUR SÉCURISER XML 31
6.2. INTÉGRATION DANS LES APPLICATIONS 32

Page 4 LES PKI - LIVRE BLANC

6.2.1. INTÉGRATION ACTIVE OU PASSIVE 32
6.2.2. SÉCURISATION DE LA MESSAGERIE 33
6.2.3. SÉCURISATION DES APPLICATIONS WEB 34
6.2.4. GESTION DES HABILITATIONS 35
6.3. APPLICATIONS AU E-COMMERCE (SET, IDENTRUS, GTA) ET AUX TÉLÉPROCÉDURES 36

7. MARCHÉ DE LA PKI 39

7.1. VISION GLOBALE 39

7.2. ACTEURS DU MARCHÉ 40
7.3. MATURITÉ ET ÉVOLUTION DES OFFRES 42
7.4. INSOURCING OU OUTSOURCING ? 43

8. STRATÉGIE DE MISE EN ŒUVRE 45

8.1. POURQUOI ET A QUEL COÛT ? 45

8.2. COMPOSANTES D’UN PROJET PKI 47
8.3. DÉMARCHE DE MISE EN OEUVRE 49

9. CONCLUSION 52

10. INDEX 53

ANNEXE 55
Annexe 1 : Acronymes 56
Annexe 2 : Structure d’un certificat X.509 57
Annexe 3 : Coordonnées des principaux acteurs 60
Annexe 4 : URL Utiles 63

Page 5 LES PKI - LIVRE BLANC

1. INTRODUCTION CHAMPS D’APPLICATION

Les champs d’applications de la technologie PKI

UNE NOUVELLE DONNE POUR LES ECHANGES
ELECTRONIQUES
Le rôle joué par l’Internet dans les échanges
électroniques a considérablement évolué depuis
quelques années, créant de nouvelles
opportunités et également de nouveaux besoins
en termes de sécurité.
De réseau d’informations publiques, l’Internet
est devenu aujourd’hui pour de nombreuses
entreprises un moyen d’accès au Système
d’Information, moyen d’accès offert suivant les
cas aux collaborateurs, partenaires, clients,
grand public ou encore fournisseurs.
Par ailleurs, l’Internet fournit un cadre privilégié
au commerce électronique sous toutes ses
formes : places de marché, échanges
électroniques marchands inter-entreprises (B-
to-B), ou à destination des clients finaux (B-to-
C).
Enfin, la dématérialisation de nombreuses
procédures administratives est envisagée,
donnant ainsi naissance aux téléprocédures
telles que la déclaration et le paiement de la
TVA, ou encore la déclaration d’impôts via
Internet.
Avec l’avènement de telles initiatives, il ne
s’agit plus simplement de vérifier l’identité de
l’individu (authentification) ou de garantir
qu’une information ne peut être accessible
qu’aux personnes habilitées (confidentialité
des échanges). Il convient désormais
également de s’assurer que d’une part les
données n’ont pas été modifiées par un tiers
(intégrité des données échangées), et que
d’autre part une organisation ou un individu
impliqué dans un échange ne puisse pas nier
son rôle dans l’échange (non-répudiation).
Cette « e-sécurité » relative aux échanges sur
l’Internet vient s’ajouter aux besoins plus
classiques de sécurisation d’accès au Système
d’Information de l’entreprise.
couvrent de nombreux besoins :
! Echanges B-to-B, pour le commerce
électronique entre les entreprises.
! Echanges B-to-C, pour le commerce
électronique entre les entreprises et leurs
clients, dans des contextes variés
(« Banque à Domicile », commerce en ligne
de biens de consommations courants…).
! Echanges B-to-A et C-to-A pour les
transferts de données entre les entreprises
et les particuliers d’une part, et
l’administration d’autre part (déclaration de
revenu en ligne par exemple).
! Echanges B-to-E entre les entreprises et
leurs employés, pour les échanges sur le
réseau interne de l’entreprise, ou via des
réseaux ouverts comme Internet.
Dans ce contexte, la PKI promet d’être, dans un
avenir proche, le standard en matière
d’infrastructure de sécurité.
OBJET DU LIVRE BLANC
Ce document a pour but de présenter les
principales facettes du fonctionnement et de
l’utilisation de cette technologie.
Après avoir introduit l’ensemble des concepts
liés aux PKI, nous décrivons le rôle de chacune
des briques qui la compose, et comment elles
permettent de créer de vastes domaines de
confiance.
Les problématiques organisationnelles et les
méthodes d’intégration des applications à la PKI
sont ensuite présentées. Enfin, nous donnons
notre vision du marché actuel de la PKI, et de la
stratégie possible pour mettre en place une PKI.

Une PKI (Public Key Infrastructure), ou

Infrastructure à Clé Publique, fournit un cadre
cohérent et homogène adressant toutes ces
fonctions de sécurité : l’authentification, la
confidentialité, l’intégrité et la non-répudiation.

Page 6 LES PKI – LIVRE BLANC

2. CONCEPTS DE BASE
Elle présente toutefois deux inconvénients
majeurs, qui rendent le système très difficile à
gérer dans de grands réseaux :
DE LA PKI ! Les difficultés liées à la transmission
du secret

Lorsque deux parties ne se connaissant pas

a priori décident d’échanger des données
chiffrées, elles doivent au préalable
2.1. PRINCIPES DE s’échanger une clé secrète via un « canal
sûr ». Ceci impose dans la majeure partie
CRYPTOGRAPHIE des cas un échange « physique » de cette
clé en « face à face ».

La cryptographie, science du chiffrement, ! La multiplication du nombre de clés

distingue traditionnellement deux grandes
familles de techniques : la cryptographie à clé
secrète et la cryptographie à clé publique.
2.1.1. Cryptographie à clé secrète
avec le nombre de correspondants
Pour assurer la confidentialité des échanges
deux à deux parmi N correspondants, il faut
N(N-1)/2 clés. Ainsi lorsque le nombre de
correspondants augmente, le nombre de
clés devient ingérable.

La cryptographie à clé secrète (ou symétrique)

repose sur le chiffrement des données à l’aide Algorithmes de chiffrement à clés secrètes les plus
répandus
d’un algorithme connu et d’une clé, laquelle
constitue le secret partagé par les deux parties
de l’échange. Algorithme Taille de clé

Les opérations de chiffrement et de DES (Data Encryption

56 bits
déchiffrement s’appuient sur la même clé. Cette System)
clé est appelée clé secrète de chiffrement.
Triple DES à 2 clés 112 bits

Secret Triple DES à 3 clés 168 bits

A B
RC 2, RC 4, RC 5 8 à 1024 bits

IDEA (International Data

128 bits
Chiffrement Déchiffrement Encryption Algorithm)
2
1
Cryptogramme
3 128, 192 ou 256
Clair Clair AES (Rijndael)
bits

Des attaques sont parvenues à compromettre des clés de

Figure 1 : Chiffrement symétrique
La cryptographie à clé secrète permet
d’atteindre des vitesses de chiffrement et
déchiffrement satisfaisantes.
taille inférieure ou égale à 56 bits. Il est considéré à l’heure
actuelle que des clés de 80 bits pourront bientôt être
compromises via la mise en place de moyens de calculs
suffisants.
Actuellement les clés de 128 bits minimum sont considérées
comme sûres.

Page 7 LES PKI - LIVRE BLANC

2.1.2. Cryptographie à clé publique
CONCEPT DE BI-CLES
Les inconvénients posés par le chiffrement
symétrique ont ouvert le champ de la
cryptographie à clé publique (ou asymétrique).
Cette dernière repose sur l’utilisation d’une
paire de clés appelée bi-clés. Les 2 clés
constituant le bi-clés sont générées
simultanément et sont intrinsèquement liées
par des algorithmes mathématiques.
L’opération de chiffrement est opérée à l’aide
d’un algorithme connu et de l’une des clés du
bi-clés. Le déchiffrement est opéré à l’aide du
même algorithme et de l’autre clé du bi-clés.
L’une des clés du bi-clés choisie arbitrairement
est dite publique et diffusable à grande
échelle. L’autre clé du bi-clés, appelée clé
privée constitue le secret d’un utilisateur.
La sécurité des techniques cryptographiques à
clé publique repose sur l’impossibilité de
retrouver le secret (clé privée) connaissant la
clé publique, le temps et la puissance de calculs
mis en œuvre étant dans la pratique prohibitifs.
Algorithmes de chiffrement à clé publique
L’algorithme RSA (Rivest Shamir Adleman, du nom de ses
créateurs) est l’algorithme à clé publique de loin le plus utilisé
(dans le domaine public depuis septembre 2000). Il repose
sur la complexité de factorisation des nombres entiers à
plusieurs centaines de chiffres.
Le niveau de sécurisation offert par l’algorithme dépend de la
longueur des clés utilisées et de l’état de l’art des moyens de
décryptage. Actuellement, on considère que :
Une clé de 512 bits peut être compromise.
Une clé de 768 bits est un minimum.
Une clé de 1024 bits est recommandée pour un usage
« normal », c’est à dire pour un usage sur un à deux ans.
Une clé de 2048 bits est recommandée pour les clés utilisées
sur de longues durées.
Comment générer un bi-clés ?
La génération des bi-clés peut être réalisée par une entité
« finale » utilisatrice de la PKI (sur un navigateur, un serveur
Web, une carte à puce ou un token) ou par l’un des
composants de la PKI. Elle peut être réalisée de façon
logicielle ou matérielle.
Une génération logicielle est effectuée à partir d’un
programme utilisant généralement comme « input » des
événements extérieurs : heure de l’ordinateur, clés
précédemment émises, paramètres entrés par l’utilisateur...
Elle est moins sûre dans l’absolu qu’une génération matérielle
car ces inputs peuvent être prédictibles et sont
éventuellement accessibles via un moyen logiciel.
Au contraire, une génération matérielle se base sur un
moyen dédié et physiquement protégé, fonctionnant de
manière totalement autonome.
Page 8
MECANISMES ET SERVICES DE SECURITE
Les mécanismes de base de la cryptographie à
clé publique permettent, lorsqu’ils sont mis en
œuvre et combinés, d’offrir les services de
sécurité suivants :
! L’authentification : l’utilisateur peut
s’assurer que son correspondant est bien
celui qu’il prétend être.
! La confidentialité : l’utilisateur peut
s’assurer que seul son correspondant peut
avoir accès aux informations envoyées.
! L’intégrité : l’utilisateur peut s’assurer que
les données n’ont pas été modifiées
(volontairement ou accidentellement).
Nous verrons aussi plus loin comment ces
services, associés à l’horodatage et à
l’archivage, permettent d’assurer la non-
répudiation : l’utilisateur ou l’organisation
impliqué dans un échange ne peut nier son rôle
dans l’échange et/ou dans la teneur de cet
échange.
Les encarts ci-dessous décrivent comment ces
services sont rendus en cryptographie à clé
publique.
Mise en œuvre de la confidentialité
Pub
B
A B Priv
B
Chiffrement Déchiffrement
1 2 3
Clair Cryptogramme Clair
A veut envoyer un texte à B et ne veut pas qu’un tiers puisse
y accéder durant l’échange.
1. A chiffre le texte à l’aide de la clé publique de B (fournie
par B ou trouvée dans un annuaire) produisant ainsi un
cryptogramme.
2. L’interception du cryptogramme par un tiers est sans
conséquence, car il ne pourra pas obtenir le message en
clair s’il ne possède pas la clé privée de B.
3. B déchiffre le cryptogramme à l’aide de sa clé privée et
obtient le texte en clair que A désirait lui envoyer.
Hash et condensat : fonctions de support
Pour offrir les services d’authentification et d’intégrité, on
utilise, en plus des opérations de chiffrement et de
déchiffrement, une fonction dite de « hachage ». Le hachage
est une fonction mathématique convertissant une chaîne de
caractères quelconque en une chaîne de taille fixe et réduite
appelée condensat (ou hash). Cette fonction est non
réversible (on ne peut pas retrouver le document initial à
partir du condensat car il y a « perte d’information » entre la
source et le condensat). Par ailleurs, il est très difficile de
trouver un autre document source engendrant le même hash.
LES PKI - LIVRE BLANC
 COMBINER LE MEILLEUR DES DEUX
Mise en œuvre de l’authentification
TECHNOLOGIES

Le schéma ci-dessous donne un exemple de mécanisme

possible pour assurer l’authentification d’une entité finale lors L’un des intérêts des algorithmes à clé secrète
d’un échange. par rapport aux algorithmes à clé publique est
Priv A Pub B
leur rapidité d’exécution. Les algorithmes à clé
A A
publique sont environ 1000 fois plus lents que
Condensat 3 4
Condensat les algorithmes à clé secrète, ce qui rend leur
2 Chiffrement Réponse Déchiffrement usage trop lourd pour assurer la confidentialité
Hachage
Hachage
=? d’échanges volumineux.
Défi
1 4’
Condensat
En pratique, l’utilisation des deux technologies
est combinée : la cryptographie à clé publique
B veut vérifier que A est bien « authentique », c’est à dire
sert souvent à échanger une clé secrète,
que A correspond bien à l’identité qu’il prétend avoir.
utilisable uniquement pendant la durée de la
1. B lance un « défi » à A, en lui envoyant un texte de son session entre les deux parties de l’échange. Ce
choix.
mode de fonctionnement correspond par
2. A calcule un condensat à partir du texte reçu. exemple à celui du protocole SSL.
3. A chiffre le condensat à l’aide de sa clé privée et envoie
la réponse à B.

4. B déchiffre le message avec la clé publique de A (fournie

par A ou trouvée dans un annuaire). B compare le
Législation concernant l’utilisation des algorithmes de
message déchiffré et le condensat (4’) du « défi » qu’il
chiffrement
avait envoyé à A. Si les deux coïncident,
l’authentification de A est réalisée.
La fourniture et l’usage des algorithmes de chiffrement sont
réglementés. En France, les textes de lois en vigueur sont les
décrets 99-199, 99-200 et l’arrêté du 17 mars 1999. Ils
Mise en œuvre du contrôle d’intégrité et de la signature
limitent la taille des clés suivant le type d’usage. En France,
c’est le DCSSI qui attribue les autorisations d’utilisation de
Priv
A
A Pub
A
B produits de chiffrement (www.scssi.gouv.fr).

Condensat Condensat
Hachage 2 3
Chiffrement SIGN Déchiffrement Moyens assurant Moyens assurant la confidentialité
1 =? l'authentification et
Hachage l'intégrité
Clair Clair 3 < 40 bits de 40 à 128 bits > 128 bits
Condensat
Libre si utilisation privée ou
Autorisé si le produit utilisé a
si le produit utilisé a déjà fait
fait l'objet d'un autorisation de
B veut vérifier que les données envoyées par A n’ont pas été l'objet d'une déclaration par
fourniture en vue d'une
altérées ou modifiées par un tiers entre l’envoi et la Libre Libre
le producteur, le fournisseur
utilisation générale
ou l'importateur du produit
réception. utilisé
Sinon, demande
d'autorisation à adresser au
sinon déclaration standard à
DCSSI
1. A opère un hachage du texte qu’il désire envoyer à B. adresser au DCSSI

2. A chiffre le condensat ainsi obtenu à l’aide de sa clé

privée et envoie le texte accompagné de ce condensat
chiffré. Ce condensat chiffré est appelé aussi
« signature ».
3. A l’aide de la clé publique de A, B déchiffre le condensat
chiffré. En parallèle, il réalise le hachage du texte. Dans
le cas où le condensat obtenu coïncide avec celui obtenu
par déchiffrement de la signature, les données sont bien
intègres.
Remarque : Dans la mise en œuvre du mécanisme
« d’enveloppe électronique » (par exemple pour le cas de
SSL) une clé secrète de session est chiffrée par une clé
publique. Dans ce cas, la taille à prendre en compte est celle
de la clé secrète (symétrique) qui chiffre les données et non
celle de la clé publique (asymétrique) qui ne chiffre que des
conventions secrètes (ce qui est libre).

Le mécanisme présenté ci-dessus est utilisé pour réaliser la

signature électronique d’un document. Seul le détenteur
de la clé privée de A a pu apposer cette signature
électronique sur le document. Ceci authentifie donc le
signataire, en plus de garantir l’intégrité du document.

Page 9 LES PKI - LIVRE BLANC


LES TYPES DE BI-CLES
En cryptographie à clé publique, on peut
distinguer plusieurs types de bi-clés, en
fonction de l’usage que l’on souhaite en faire. Il
est par exemple possible de définir :
! Des bi-clés de chiffrement
Ils sont utilisés pour assurer les services de
confidentialité, généralement en constituant
une « enveloppe électronique » permettant
l’échange de clés symétriques de
chiffrement.
! Des bi-clés de signature
Ils sont utilisés pour assurer les services
d’intégrité et contribuer à la non-répudiation
en constituant une signature électronique.
! Des bi-clés d’authentification
Ils sont utilisés pour assurer les services
d’authentification pour l’accès à des
données et/ou à des transactions.
Ces distinctions se justifient pour plusieurs
raisons :
! Les clés privées de signature doivent être
conservées uniquement par leur
propriétaire. En revanche, il peut être
nécessaire de confier à un tiers le stockage
des clés privées de chiffrement, pour
assurer leur recouvrement ultérieur. Ceci
est nécessaire par exemple pour déchiffrer
un document en cas de perte de la clé
privée de chiffrement par son propriétaire.
Il est donc préférable de gérer les clés
privées de chiffrement et de signature de
manière distincte.
! Enfin, il existe des failles de sécurité
éventuellement utilisables par des pirates
en cas d’usage d’un bi-clés unique. Par
exemple, un utilisateur B pourrait faire
signer un document à un utilisateur A à son
insu, en lui faisant passer le document pour
un défi dans le cadre d’une
d’authentification.
Le nombre de bi-clés par utilisateur reste
toutefois réduit, ce qui simplifie la gestion des
clés par rapport à la technologie à clé
symétrique.
Page 10
2.2. CERTIFICATS DE CLE
PUBLIQUE
DEFINITION
L’utilisation de bi-clés repose sur le postulat
qu’à tout moment, l’une des parties de
l’échange peut être certaine de la validité du
couple (clé publique/identité de l’utilisateur) de
l’autre partie. Dans le cas contraire, un tiers
pourrait usurper l’identité de l’un des
correspondants et ainsi utiliser sa signature.
Le certificat apporte une réponse à cette
problématique. Un certificat de clé publique
est une « carte d’identité numérique », qui
atteste la validité du couple
clé publique/identité de l’utilisateur1.
Plus précisément, un certificat de clé publique
est une structure de données contenant une clé
publique, des informations sur le propriétaire du
certificat, l’ensemble étant signé par une
autorité tierce appelée Autorité de Certification
(ou Certificate Authority : CA).
LES CERTIFICATS X.509V3
Le format de certificats le plus utilisé dans le
cadre d’une PKI est le standard normalisé
X.509v3. Ce dernier permet l’utilisation des
protocoles normalisés ou des applications tels
que SSL, IPSec, S/MIME ou SET (cf. chapitre
6).
La norme X.509v3 spécifie la nature des
champs de la structure de données constituant
le certificat (cf. annexe 2). Le standard Internet
RFC 2459 décrit une déclinaison du format des
certificats X.509 pour le monde de l’Internet.
1 Il existe aussi des certificats qui ne sont pas des
certificats de clé publique. C’est le cas notamment
des certificats d’attributs (cf. 6.2.4).
LES PKI - LIVRE BLANC
 Format d’un certificat X.509 V3 demande de génération du
authentification
certificat certificat

Version du certificat
Renouvellement
Numéro de série du certificat

Description de l'algorithme de signature de la CA

expiration du exploitation du remise au
Nom de la CA qui a généré le certificat (format X.500)
certificat certificat demandeur
Période de validité

Nom de l'utilisateur auquel appartient le certificat (format X.500)

Clé publique

Description de l'algorithme à utiliser avec la clé publique révocation du suspension du levée de la

Identification alternative de la CA (optionnel) certificat certificat suspension

Identification alternative de l'utilisateur (optionnel)

Extensions (optionnel) Figure 2 : Cycle de vie d’un certificat

Signature de la CA

Une PKI s’articule généralement au moins

Notons que l’un des champs extension sert notamment à autour des trois composants de base suivants :
spécifier l’usage qui va être fait de la clé publique contenue
dans le certificat (signature, chiffrement…). L’annexe 2 donne ! L’Autorité de Certification (CA : Certification
une description plus détaillée de la structure d’un certificat. Authority) qui génère et signe les
certificats.

! Une ou plusieurs Autorités d’Enregistrement

(RA : Registration Authority) qui
LES ENTITES UTILISATRICES DE CERTIFICATS enregistrent et valident les demandes de
certificats.
Les entités utilisatrices de certificats
correspondent aux différentes parties entrant ! Un dépôt qui stocke les certificats et les
en jeu dans le cadre d’un échange listes de certificats révoqués (CRL :
électronique : les entités utilisatrices d’un Certificate Revocation List) .
certificat peuvent donc être de différents
types : des utilisateurs, des serveurs, des
applications, des composants réseaux, etc.
Dépôt Recherche et lecture
de certificats

Certificats Utilisateur

2.3. GESTION DES CLES ET DES

Version
Serial Number
Demande de certificat
Version
Sign Algorithm
Serial Number
Issuer Name
Sign Algorithm
Authentification
Validity Period
Issuer Name
Subject Name Remise du certificat

CERTIFICATS PAR LA PKI

Validity
Subject Public KeyPeriod
ExtensionsSubject Name
Signature Subject Public Key
Demande de révocation
Extensions
Signature

RA
L’Infrastructure à Clé Publique ou PKI CRL
(Public Key Infrastructure) désigne
Clé publique à certifier
Version
Certificat
l’ensemble des moyens et ressources
Serial Number
Sign Algorithm Version

XX
Issuer Name Serial Number
Validity Period Sign Algorithm

nécessaires à la gestion du cycle de vie et à

Subject Name Issuer Name

CA
Validity Period
Subject Public Key
Extensions Subject Name
Signature Subject Public Key

l’exploitation des certificats.

Extensions
Signature
publication des
certificats et des CRL

Une PKI regroupe ainsi les composants

techniques, les ressources, l’organisation et les
politiques de sécurité permettant l’usage de la
cryptographie à clé publique dans un contexte
défini. Figure 3 : Architecture typique d’une PKI

Les fonctionnalités offertes par une PKI via ses

différentes composantes permettent d’assurer
la gestion du cycle de vie d’un certificat, dont Nous allons dans le chapitre suivant détailler le
un exemple est représenté dans le schéma ci- cycle de vie des certificats et les fonctions
dessous. associées de la PKI.

Page 11 LES PKI - LIVRE BLANC

3. FONCTIONNEMENT
Deux scénarios sont envisageables pour la
phase de création du certificat en fonction du
lieu de génération du bi-clés : le bi-clés peut en
DE LA PKI effet être généré localement par l’utilisateur ou
le dispositif utilisateur (serveur, équipement
réseau) ou de manière centralisée au sein de
l’infrastructure PKI.
Les implémentations techniques des PKI varient
Dans le premier cas, l’utilisateur ou le dispositif
beaucoup d’un fournisseur à l’autre, et il est
utilisateur demande uniquement la certification
possible d’envisager de multiples options
(signature) de sa clé publique. Dans le
d’architecture et d’organisation en fonction des
deuxième cas, l’utilisateur demande à la fois la
besoins. Nous décrivons ci-dessous les
génération du bi-clés et du certificat à
principaux concepts associés et les fonctions
l’Infrastructure PKI.
généralement implémentées dans une PKI.

3.1.1. Fonctionnalités sous la

3.1. CREATION DES CERTIFICATS responsabilité de la RA

La création d’un certificat se décompose en

L’Autorité d’Enregistrement (RA) assure la
plusieurs étapes : enregistrement de la
responsabilité des fonctionnalités « de
demande de certificat, vérification des
proximité ». Elle peut elle-même déléguer une
informations relatives à l’utilisateur, génération
partie de ses responsabilités, notamment pour
du certificat puis remise du certificat. En règle
distribuer les fonctions d’enregistrement.
générale, 2 entités se partagent les
responsabilités de ces opérations : l’Autorité
d’Enregistrement (RA) et l’Autorité de ENREGISTREMENT
Certification (CA).
L’enregistrement consiste tout d’abord à
La plupart des architectures PKI s’appuient sur recueillir les informations caractéristiques de
une ou plusieurs Autorités d’Enregistrement. En l’utilisateur : son patronyme, son adresse
effet, dans les environnements distribués, le électronique… Ces informations seront
déploiement de plusieurs Autorités nécessaires à la constitution du certificat et,
d’Enregistrement apporte plus de souplesse et seront ensuite utilisées par les applications lors
permet d’optimiser les processus de gestion des de l’exploitation du certificat.
certificats. Dans ce cas, l’Autorité de
Certification (CA) délègue une partie des En cas de génération du bi-clés par l’utilisateur,
fonctions de gestion, et donc de ses la fonction d’enregistrement a également pour
responsabilités, à l’Autorité d’Enregistrement objectif de s’assurer de la possession effective
(RA). de la clé privée par l’utilisateur.

L’ensemble des étapes constituant la phase de Suivant les implémentations, l’enregistrement

création est présenté sur le schéma suivant : peut être réalisé directement par l’utilisateur
(via une interface Web ou la messagerie) ou par
un opérateur d’enregistrement qui collecte et
utilisateur saisit les informations dans un logiciel prévu à
cet effet.
1 L’utilisateur (ou son Le certificat est remis à
représentant) fait une 7
Des mécanismes plus automatiques peuvent
l’utilisateur
demande de certificat (éventuellement via son

être mis en œuvre pour la création de certificats

représentant)
La RA procède à
2 l’authentification et à la
vérification des attributs du RA pour des entités « non humaines » (par
demandeur
exemple des équipements réseaux, des
3 La demande est
6
Le certificat est transmis
à la RA pour qu’il soit serveurs applicatifs…).
transmise à la CA remis au demandeur

Enfin, il est aussi possible de procéder à des

CA dépôt enregistrements « de masse » (fonction
4 La CA génère
5
Le certificat est placé dans
un dépôt accessible à tous
« bulk ») lors de grands déploiements, sur la
base de fichiers préalablement validés par
le certificat
les utilisateurs
(optionnel)
l’Autorité d’Enregistrement.
Figure 4 : Etapes de la création d’un certificat

Page 12 LES PKI - LIVRE BLANC

 Standards et format des messages transmis
entre une entité finale et les composants RA et
CA
Format des messages
CRMF
RA
CMMF
CEP
KEYGEN tag
PKCS#7
CA
PKCS#10
CRMF (Certificate Request Message Format) et CMMF
(Certificate Management Message Format) sont des standards
issus du PKIX (groupe de travail de l'IETF). Ils définissent le
format des messages d’une requête à une Autorité
d’Enregistrement ou une Autorité de Certification ainsi que le
format des informations retournées aux utilisateurs.
CEP (Certificate Enrollment Protocol) est un protocole
développé conjointement par Cisco Systems et VeriSign qui
permet la communication entre des routeurs ou clients VPN
et une Autorité d’Enregistrement ou Autorité de Certification.
KEYGEN tag est une balise HTML supportée par les
navigateurs Netscape qui génère une paire de clés sur le
poste client et formate une requête HTTP envoyée à l’Autorité
de Certification dans le cadre du processus d’enregistrement.
PKCS#7, développé par RSA Security, définit un format de
message et de chiffrement des données utilisé pour mettre
en œuvre la signature et l’enveloppe numériques. Ce format
est utilisé entre autres pour délivrer des certificats aux
utilisateurs.
PKCS#10, développé par RSA Security, définit un format de
message pour les demandes de certificat. Ce format est
supporté par Internet Explorer et Netscape Communicator.
Lors de l’enregistrement, 2 contrôles capitaux
sont réalisés :
! l’authentification,
! la vérification des attributs.
La qualité de l’authentification est un des
éléments qui détermine le niveau de confiance
à placer dans le certificat. C’est elle qui
garantit, par la vérification de l’identité du
demandeur, la validité du couple
clé publique/identité de l’utilisateur au moment
de l’émission du certificat. En fonction du
niveau de confiance accordé au certificat,
plusieurs modes d’authentification sont
envisageables. Par exemple, on peut envisager
le déplacement physique de l’utilisateur et
l’authentification en personne de ce dernier sur
présentation de plusieurs papiers d’identité
originaux (niveau d’authentification élevé), ou
encore l’authentification par simple envoi de
copies de pièces d’identité.
Page 13
L’authentification peut avoir lieu à plusieurs
moments dans le processus de création du
certificat. Elle peut par exemple avoir lieu lors
de l’enregistrement de la demande et/ou lors de
la remise du certificat.
Comme l’authentification, la vérification des
attributs conditionne le niveau de confiance à
placer dans le certificat. Elle consiste à vérifier
la validité des attributs de l’entité à l’origine de
la demande du certificat (appartenance à une
société, fonction dans l’organisation…).
L’Autorité d’Enregistrement valide enfin que
l’utilisateur est bien habilité à entrer en
possession d’un certificat.
REMISE DU CERTIFICAT ET DE LA CLE PRIVEE
La remise du certificat (ou distribution du
certificat) à l’entité à l’origine de la demande
n’est pas au sens strict obligatoire. En effet,
comme nous allons le voir, à l’issue de sa
génération, le certificat peut être publié dans un
dépôt public afin d’être disponible pour les
autres utilisateurs. Dans la pratique, le certificat
généré est toutefois la plupart du temps remis à
l’utilisateur.
Le mode de remise dépend à la fois de choix
organisationnels ou sécuritaires et d’éléments
techniques tels que le lieu de génération du bi-
clés (génération locale ou génération par
l’infrastructure) ou le support retenu pour
stocker la clé privée et le certificat de l’entité
utilisatrice.
Si le bi-clés est généré localement par l’entité
utilisatrice, la récupération du certificat est
généralement à l’initiative de cette dernière.
Dans ce cas, l’utilisateur peut récupérer son
certificat par exemple sur un site Web, à l’aide
d’un secret (par exemple un PIN-Code ou une
pass-phrase) qui lui a été communiqué lors de
son enregistrement. Cette remise peut aussi
être à l’initiative de l’infrastructure, par
exemple pour une remise du certificat par
messagerie.
Si l’infrastructure prend en charge la génération
du bi-clés, le certificat et la clé privée sont alors
remis à l’utilisateur via l’Autorité
d’Enregistrement. La clé privée doit être remise
par un moyen très sûr.
LES PKI - LIVRE BLANC
 Les supports possibles pour le stockage des clés
privées et des certificats
De nombreuses solutions de stockage des clés, énumérées ci-
dessous, sont disponibles en fonction du niveau de sûreté
désiré et de la nature de l’entité utilisatrice des clés (un
utilisateur, un serveur, une brique de la PKI, etc.)
Disquette
Avantages : Pas d’acquisition de matériel dédié. Mobilité du
support.
Inconvénient : Possibilité de substitution ou de réplication
de la disquette. Fiabilité et pérennité du support.
Disque dur
Avantage : Pas d’acquisition de matériel dédié.
Inconvénient : Le niveau de sécurité dépend de la
protection du poste de travail. Mobilité difficile.
Carte à puce (intégrant généralement un module de calcul
cryptographique)
Avantage : Les calculs sont faits dans la carte, la clé privée
n’est alors pas exposée. Possibilité de lecteurs de cartes
disposant d’un clavier : le code PIN n’est alors pas disponible
en dehors du dispositif.
Inconvénient : Coût assez élevé.
Token sur port USB
Avantage : Dispositif dédié moins coûteux qu’une carte à
puce (pas besoin d’équiper les ressources si elles possèdent
un port USB). Les calculs sont faits dans le token, la clé
privée n’est alors pas exposée.
Inconvénients : Port USB nécessaire. Pas de clavier dédié.
Module HSM (Hardware Security Module)
Avantages : Equipement matériel dédié, protégé
physiquement. Adapté à la génération et au stockage de
données sensibles (par exemple Clé privée de la CA). Les
calculs peuvent être faits dans le dispositif, les clés privées ne
sont alors pas exposées. Calculs cryptographiques accélérés.
Inconvénients : Prix d’acquisition élevé. Dispositif fixe.
Carte PCMCIA
Excepté le fait que ces cartes sont mobiles, elles présentent
les mêmes caractéristiques qu’un module HSM.
Avantage : Adapté au stockage de données sensibles sur
des postes nomades.
Inconvénient : Possibilité de dérober le dispositif.
Le standard PKCS#11 : Cryptographic Token Interface
Standard (Cryptoki)
Afin de s’affranchir de l’hétérogénéité des différents
périphériques contenant des informations cryptographiques,
une interface de programmation (API) a été développée par
les laboratoires RSA. Cette API dénommée PKCS#11 définit
une interface permettant de communiquer avec des
périphériques contenant une information cryptographique et
d’effectuer des opérations cryptographiques.
3.1.2. Fonctionnalités sous la
responsabilité de la CA
L’Autorité de Certification est le tiers de
confiance dont la signature apparaît sur le
certificat. Elle est responsable du processus de
certification dans sa globalité.
Page 14
Elle délègue parfois une partie de ses
responsabilités à un opérateur de certification,
chargé de la réalisation des opérations
techniques liées à la certification. Dans ce cas
l’Autorité de Certification assure un contrôle de
l’opérateur de Certification (cf. chapitre 5).
GENERATION DES CERTIFICATS
La certification consiste à apposer la signature
de l’Autorité de Certification sur le « gabarit »
du certificat du demandeur.
Il faut souligner qu’aucun contrôle n’est
effectué au cours de cette phase, hormis
éventuellement celui du nommage d’entité.
La problématique du nommage d’entité
Le nommage d’entité correspond à la nécessité de garantir
l’unicité du nommage. Théoriquement, définir des noms
uniques pour les entités est possible en utilisant le
mécanisme X.500 Distinguished Name (DN). Ce mécanisme
utilise une structure de nommage hiérarchique avec une
racine et des autorités de nommage à chaque nœud.
Cependant ce mécanisme n’a pas rencontré un succès total,
notamment parce qu’il n’est pas possible de garantir l’unicité
du nommage si l’ensemble des acteurs ne respecte pas les
mêmes règles.
Les solutions mises en place consistent à utiliser
conjointement une stratégie locale de nommage évitant tout
doublon au sein du domaine de sécurité et de déposer les
noms auprès d’un organisme adéquat, qui s’assure qu’il n’y a
aucun certificat similaire en dehors du domaine de sécurité.
L’AFNOR assure cette fonction, en gérant l’attribution d’OID
(Object Identifier) aux organismes qui en font la demande.
La CA possède une base de données interne
dans laquelle elle stocke le statut de l’ensemble
des certificats qu’elle a créé. Cette base locale
est propre à la CA et donc distincte du dépôt de
publication que nous allons décrire par la suite.
PERSONNALISATION DES CARTES A PUCES
Afin de générer et stocker la clé privée en lieu
sûr, il est possible d’utiliser un support matériel,
comme la carte à puce ou le token.
Dans un premier temps, les supports sont
fabriqués de manière industrielle (étape de
production). Le support doit être initialisé, via le
chargement des programmes de bases sur sa
puce électronique. Un fabricant spécialisé est
généralement chargé de cette action en raison
de sa spécificité. Il y a ensuite plusieurs étapes
de personnalisation à réaliser.
LES PKI - LIVRE BLANC
Dans le cas d’une carte à puce, le support doit
aussi être éventuellement personnalisé
« graphiquement » (inscription d’un logo, du
nom du porteur…).
Enfin, les clés peuvent être générées par la
carte ou le token, puis les informations
concernant le demandeur et le certificat émis
par la CA sont inscrites sur la carte ou le token.
SYNTHESE
L’ensemble des fonctionnalités mises en jeu
dans le processus de création de certificats,
leurs statuts (obligatoires ou non) et leurs
responsables respectifs sont représentés sur la
figure suivante.

PUBLICATION DU CERTIFICAT RA CA
Selon l’usage du certificat, il peut être Enregistrement : collecte Certification :
des informations signature
intéressant de le publier ou non.

Par exemple la publication des certificats de Authentification du Production des

supports physiques
signature n’est pas forcément utile : En effet, le demandeur

certificat de signature est toujours joint à la

transaction signée. Vérification des Personnalisation des
attributs supports physiques

En revanche, il est intéressant de publier les

certificats de chiffrement. Lorsqu’un utilisateur Remise du certificat
Publication des
certificats
veut envoyer des données confidentielles à un
autre utilisateur, il lui faut être en possession
de la clé publique de ce dernier. Pour éviter un Obligatoire Propre aux supports Selon le scénario

échange préalable, les certificats doivent donc matériels

être accessibles à tous les utilisateurs.

Figure 5 : Exemple de répartition de
Ainsi, même si la publication n’est pas responsabilités pour la phase de création
obligatoire, elle est souvent réalisée en
pratique.
Nous décrivons ci-dessous deux exemples de
La CA est souvent responsable de la publication scénarios, qui diffèrent selon le lieu de
et du stockage des certificats. Ceux-ci sont génération du bi-clés. Dans chaque scénario, la
placés dans un dépôt (repository). Le format de publication des certificats est optionnelle. Il
certificats X.509 s’adapte naturellement aux existe de multiples autres scénarios possibles :
annuaires X.500. En effet, la norme X.509
prévoit que certains champs du certificat
doivent respecter le nommage X.500.
Scénario 1 : Génération du bi-clés « en
local » par l’entité finale
En pratique, la quasi-totalité des dépôts sont
implémentés sous forme d’annuaires ; ces Demande de
derniers sont naturellement accédés au travers certificat
du standard LDAP (Lightweight Directory
Access Protocol). Enregistrement
de la demande
Vérification des
Génération du bi-clé attributs
A quels utilisateurs faut-il laisser l’accès au dépôt ? en local

Un dépôt totalement libre d’accès peut laisser la possibilité à Génération du

Authentification
un tiers de prendre connaissance de l’organigramme de certificat
l’entreprise. Aussi, dans la pratique, les dépôts sont d’un
accès semi-public.
Remise Publication

Ils sont par exemple ouverts pour les utilisateurs « internes »

de l’entreprise, mais à accès restreint pour les utilisateurs Phase
« externes ». Il est aussi possible de limiter les fonctions de d’exploitation
recherche dans le dépôt en exigeant le nom précis d’une
personne pour donner accès à son certificat.
Figure 6 : Etapes de la création du certificat
lorsque le bi-clés est généré en local

Page 15 LES PKI - LIVRE BLANC

Dans ce scénario, les fonctionnalités de remise
et de publication sont optionnelles, mais au
3.2. RENOUVELLEMENT ET
moins l’une d’entre elles doit être réalisée afin REVOCATION DES
de pouvoir assurer la distribution du certificat.
L’authentification et la vérification des attributs
CERTIFICATS
sont réalisées à l’enregistrement. Lors de la
génération du certificat, la CA peut aussi
authentifier le demandeur en vérifiant qu’il est La CA est donc responsable de la création du
bien en possession de la clé privée certificat. Elle doit également gérer l’ensemble
correspondante à la clé publique à certifier. du cycle de vie du certificat, notamment les
Enfin, à la remise du certificat, l’identité du fonctions de renouvellement, de révocation et
demandeur doit être vérifiée, par exemple en de suspension.
utilisant un mot de passe convenu lors de
l’enregistrement si cette remise est réalisée via Dans ce chapitre, nous traiterons
une connexion Web. principalement des certificats « d’entité
finales ». Les certificats et les clés des
composants de l’infrastructure PKI, et
notamment ceux de la CA, donnent lieu à des
Scénario 2 : Génération du bi-clés au sein dispositions et des procédures de gestion
de l’infrastructure de confiance spécifiques que nous abordons succinctement
en fin de chapitre.

Demande de génération
de bi-clé et de certificat

RENOUVELLEMENT
Enregistrement
Production du support
de la demande
En règle générale, la durée de vie d’un certificat
Génération du bi-clé varie entre un et trois ans pour un certificat
en central
utilisateur et entre quatre et vingt ans pour le
certificat d’une CA.
Génération du Vérification des
Authentification
certificat attributs
Si la demande de renouvellement est effectuée
Personnalisation du alors que la période de validité du certificat
support
précédent est expirée, le processus de
demande est assez souvent identique à celui de
Remise Publication la création d’un certificat. L’utilisateur se doit de
justifier à nouveau son identité et ses attributs.
Phase Ceci n’est toutefois pas obligatoire : il est par
d’exploitation
exemple possible de convenir au moment de
l’enregistrement d’un secret entre l’utilisateur
Figure 7 : Etapes de la création du certificat et la CA, secret qui pourra être utilisé pour
lorsque le bi-clés est généré par l’Infrastructure réaliser le renouvellement du certificat sans
de Confiance réaliser ces vérifications.

Dans ce scénario, la remise du bi-clés au
demandeur est nécessaire. L’authentification et
la vérification des attributs peuvent être
réalisées soit à l’enregistrement, soit à la
remise, soit les deux.
Dans le cas contraire, l’utilisateur peut signer la
demande avec sa clé privée, ce qui garantit son
identité et ses attributs. La CA établit alors un
nouveau certificat avec ou sans période de
recouvrement avec l’ancien certificat.

Les fonction de production et de Ce processus de renouvellement du certificat

personnalisation des supports sont présentes si peut être soit manuel (demande à renouveler
le support de remise est un support matériel par l’utilisateur avant la fin de validité de son
(carte à puce, token…). certificat), soit automatique.

Page 16 LES PKI - LIVRE BLANC

REVOCATION
Des mécanismes doivent être prévus pour
invalider un certificat avant sa date de fin de
validité, c’est à dire pour le révoquer. Plusieurs
causes peuvent déclencher une révocation :
! une suspicion ou une compromission réelle
de la clé privée,
! une modification des informations
contenues dans le certificat (changement
du nom après mariage, évolution de
fonction…),
un dysfonctionnement du support du
! privilèges de révocation
certificat ou une perte des données
d’activation (code PIN pour une carte à
puce).
! un changement de l’état de l’art
cryptographique…
Bien entendu, seules les personnes dûment
habilitées doivent pouvoir révoquer un
certificat. Comme pour la demande de
certification, la demande de révocation est
souvent adressée à la RA. Une fonction dédiée
peut toutefois être mise en place pour gérer les
révocations. Après authentification du
demandeur, la demande est transmise à la CA
qui va entreprendre son traitement.
La CA dispose de plusieurs méthodes pour
répercuter la révocation d’un certificat :
! La révocation par annuaire positif
La CA retire du dépôt, dans lequel elle
publie l’ensemble des certificats émis,
chacun des certificats révoqués. Ainsi,
lorsque les applications accèdent au dépôt,
seuls y figurent les certificats valides. Cette
implémentation est à l’heure actuelle peu
utilisée.
! La révocation par publication de listes
négatives
La CA publie des CRL (Certificate Revocation
List), qui sont des listes contenant les
identifiants de chacun des certificats
révoqués et non expirés. Les CRL sont
généralement publiées dans le dépôt de
certificats, mais elles peuvent également
l’être dans un dépôt dédié (un dépôt de
CRL).
L’application récupère périodiquement une
copie de la dernière CRL émise par la CA.
Lorsqu’elle cherche à vérifier la validité d’un
certificat, elle peut ainsi vérifier si le
certificat en question est dans cette liste (cf.
plus bas le paragraphe portant sur la
validation).
Page 17
La fréquence de publication des CRL doit
être paramétrée en fonction de la politique
de sécurité retenue. En règle générale, la
CRL est publiée à fréquence fixe (une fois
par jour, une fois par heure…) par la CA.
utilisateur
L’utilisateur demande
la révocation du
1
certificat dont il
fournit l’identifiant
La RA procède à
l’authentification du demandeur
2 RA
et vérifie qu’il possède les
3 La demande est
transmise à la CA
dépôt
CA certificats
CRL
4
La CA enregistre la
révocation du A intervalles réguliers, la CA
certificat 5 publie dans le dépôt la CRL,
liste des certificats révoqués
Figure 8 : Exemple de processus de révocation
d’un certificat à l’initiative de l’utilisateur
La CRL devient rapidement un fichier
volumineux et sa manipulation une
opération lourde. Pour pallier ce problème,
la CRL complète n’est pas publiée à chaque
fois qu’un certificat est révoqué. Des
optimisations de la CRL ont été mises au
point :
• Les CRL Distribution Point consistent
à partitionner la CRL de manière à
obtenir des fichiers de taille moindre,
donc plus facilement récupérables.
Pour ce faire, chaque certificat contient
les références de la partition dans
laquelle il se trouve, afin que les
applications puissent récupérer la CRL
de la partition idoine.
• La delta CRL permet de fournir la liste
des certificats dont le statut a changé
depuis l’émission de la dernière CRL.
Dans ce cas, la CA publie également la
CRL à intervalles réguliers, alors que la
publication de la delta CRL est beaucoup
plus fréquente (par exemple dès qu’un
certificat a été révoqué).
Ceci permet d’optimiser le délai de prise
en compte des révocations par les
applications.
Le mécanisme des delta CRL est
toutefois aujourd’hui très peu
implémenté.
LES PKI - LIVRE BLANC
SUSPENSION
La suspension d’un certificat est une fonction
optionnelle qui consiste à révoquer le certificat
de manière temporaire. Le principe consiste à
placer dans la CRL l’identifiant du certificat
révoqué et à le retirer dans le cas où la
suspension est levée.
Comment suspendre un certificat en utilisant
les delta CRL ?
Lorsque la CA utilise les delta CRL pour notifier la révocation
des certificats se pose un problème pour la suspension. En
effet, il n’est pas possible via une delta CRL de notifier qu’un
certificat qui avait été révoqué est à nouveau valide.
Dans ce cas, c’est à la publication de la CRL suivante que
sera rétablie la situation. Pour ce faire, il suffit que le
certificat révoqué n’apparaisse plus dans la CRL et il sera à
nouveau considéré comme valide.
1 2 3 4
Temps de latence
La CRL est publiée à intervalle fixe
1. La CA publie une CRL.
2. La CA publie une delta CRL notifiant la suspension du
certificat.
3. Un utilisateur habilité lève la suspension de ce certificat.
4. Ce n’est qu’avec la publication de la CRL opérée à
fréquence fixe que le certificat est à nouveau considéré
comme valide.
Ce procédé provoque un temps de latence pendant lequel
l’utilisateur ne peut utiliser son certificat, alors que la
suspension a été levée.
D’autres mécanismes, tels que la création de
CSL (Certificate Suspension List) contenant les
identifiants des certificats suspendus, sont aussi
possibles. Mais ils ne sont pas implémentés en
pratique pour le moment.
GESTION DES CERTIFICATS ET DES CLES DES
COMPOSANTS DE L’INFRASTRUCTURE PKI
La spécificité et la criticité des certificats
d’Autorité de Certification (et plus généralement
des certificats de l’ensemble des composants de
l’infrastructure) suppose une organisation
particulière de la gestion de leur cycle de vie.
Page 18
Ainsi, les opérations relatives au cycle de vie
des clés de CA sont usuellement réalisées au
cours de « Key Ceremonies » qui s’apparentent
à des cérémonies notariées (réalisées en
effectifs restreints devant témoins,
éventuellement filmées, etc.). Par exemple la
Key Ceremony associée à la création d’un
certificat de CA regroupera les procédures de
génération du bi-clés, de génération du
certificat correspondant, de clonage éventuel du
bi-clés sur un HSM de sauvegarde mis en
coffre, de génération et de partage des secrets
liés à l’activation de la clé privée, etc.. On
réalisera des Key Ceremonies notamment pour
la création, la révocation, et le renouvellement
d’un certificat de CA racine ou de CA fille.
Les actions associées à la révocation d’un
certificat de CA doivent permettre une prise en
compte rapide par les utilisateurs. Or la
publication d’une ARL (Authority Revocation
List) lors d’une Key Ceremony ne permet pas
de bloquer totalement l’utilisation des certificats
car la plupart des applications standards ne
permettent pas nativement de vérifier la
publication éventuelle d’une ARL. Il est donc en
général nécessaire de notifier l’ensemble des
administrateurs d’application et des porteurs de
certificat. On peut également placer dans la CRL
les références de l’ensemble des certificats émis
par la CA (cette dernière opération peut poser
néanmoins certains problèmes pour la
récupération de la CRL qui atteint alors une
taille largement plus importante qu’à
l’accoutumée).
Le renouvellement d’une clé de CA fait
également l’objet d’une organisation spécifique.
En effet, une clé privée de CA doit rester valide
tant que tous les certificats qu’elle a signés ne
sont pas expirés (dans le cas contraire lesdits
certificats ne pourraient plus être considérés
comme valides). On met alors en œuvre un
processus de renouvellement avec période de
recouvrement (roll-over).
3.3. VALIDATION DES
CERTIFICATS
Lorsqu’un certificat est présenté à une
application (par exemple pour réaliser une
opération de chiffrement, authentifier un
utilisateur, vérifier la signature d’un
document…), l’application doit s’assurer de la
validité de ce certificat.
LES PKI - LIVRE BLANC
 CONTROLE LOCAL
Cette opération englobe plusieurs types de
vérifications qui peuvent être réalisées ou non, Les contrôles réalisables de manière
au choix de l’application. Ces vérifications sont « autonome » par l’application sont
les suivantes : essentiellement la vérification des dates de
validité, la vérification de la signature et dans
! Vérification de la période de validité du certaines limites la vérification du chemin de
certificat telle qu’elle est mentionnée dans certification.
le certificat lui-même.

! Vérification de la signature présente dans le INTERROGATION DE LA PKI

certificat, à l’aide de la clé publique de la CA
émettrice. Ceci implique de détenir au
préalable ou de récupérer par un moyen sûr
le certificat de la CA en question.
! Vérification du chemin de certification :
L’application doit, pour accepter le
certificat, avoir confiance en la CA
émettrice. Si le certificat de la CA émettrice
a été émis lui-même par une autre CA, il
faut remonter la « chaîne de certification »
jusqu’à un certificat de CA « connue » et
« de confiance ». Ceci implique
normalement de vérifier aussi la validité
(date de validité et statut de non
révocation) de chaque certificat de CA se
trouvant dans la « chaîne de certification ».
Au sommet de la chaîne, doit se trouver
une CA dans laquelle l’application place sa
confiance, et dont le certificat auto-signé
aura été remis au préalable à l’application
par un moyen sûr.
! Vérification du statut du certificat. Cette
opération consiste à vérifier que le certificat
n’est ni révoqué ni suspendu.
Identité : Utilisateur Identité : AC 1
Clé publique de chiffrement Clé publique de signature
Usage : Chiffrement Usage : Certification
Identité du signataire : Identité du signataire :
AC 1 AC Racine
Les contrôles décrits plus haut sont
réalisables en interrogeant les services de la
PKI, soit par récupération ou interrogation de
CRL, soit par interrogation d’une brique
supplémentaire dans la PKI : l’Autorité de
validation (VA).
- 1 - Accès aux CRL
Les CRL permettent uniquement d’assurer le
contrôle de non révocation et de non
suspension du certificat. Le principe consiste à
récupérer en local la CRL, ou l’une de ses
variantes, pour opérer cette vérification.
Plusieurs stratégies sont envisageables en
fonction du niveau de sécurité désiré :
! l’application va périodiquement chercher la
dernière CRL publiée (le terme pull est
employé),
! la CA transmet à l’application chaque
nouvelle version de la CRL et des delta CRL
(le terme push est employé).
En fonction de la fréquence de récupération des
CRL, le temps de latence pour la répercussion
des informations sera plus ou moins long et le
Identité : AC Racine service plus ou moins dégradé.
Clé publique de signature
Usage : Certification
Identité du signataire :
AC Racine

Signature réalisée Signature réalisée Signature réalisée

par AC1 par AC Racine par AC Racine L’application récupère
2 périodiquement les CRL
auprès du dépôt de la CA

Application Dépôt
de CRL
Figure 9 : Chaîne de certification
3 L’application vérifie le statut
L'utilisateur présente du certificat présenté
1 son certificat
L’application doit vérifier
le statut du certificat

Ces vérifications peuvent être réalisées de

différentes manières en fonction des services
Utilisateur
offerts par la PKI et de l’implémentation
retenue. Elles peuvent s’appuyer soit sur un
contrôle purement local, soit sur une Figure 10 : Vérification de la validité d’un
« interrogation » de l’infrastructure PKI. certificat par l’application

Page 19 LES PKI - LIVRE BLANC

- 2 - Mise en place d’une Autorité de 2
La base de la VA récupère
périodiquement les CRL

validation (VA) auprès du dépôt de la CA

dépôt
VA certificats
Cette solution consiste à intégrer une brique CRL

technique supplémentaire dans la PKI, la VA. L’application utilisatrice

L’application obtient
3
Les applications vont alors interroger ce
une information sur la
1 demande le statut d’un
validité du certificat
certificat
composant tiers pour connaître le statut d’un
certificat. Par l’envoi d’un message de réponse Application
signé, la VA assure la validité du certificat. utilisatrice

Figure 11 : Vérification de la validité d’un

Le concept d’Autorité de validation est né avec
certificat par une VA avec CRL
l’avènement du protocole OCSP (On-line
Certificate Status Protocol), qui est devenu un ! Consultation directe de la base de
standard. données de la CA

OCSP repose sur un modèle client-serveur. Afin de mettre en place, un véritable service
L’application héberge un client qui interroge le de validation en temps réel du statut des
serveur OCSP, appelé OCSP Responder. A cet certificats, la VA peut directement consulter
effet, la requête OCSP est postée par le client le statut des certificats dans la base de
via un protocole de transport tel que HTTP, données de la CA.
LDAP ou SMTP vers un serveur OCSP (OCSP
Responder). Ce dernier formate une réponse, Base de la CA
signée électroniquement, faisant état du statut
du certificat, à savoir « valide », « révoqué » ou La VA consulte directement la
3 Le statut du certificat
est transmis à la VA
2 base propre de la CA pour
« inconnu ». connaître le statut du certificat
en question

Les différentes versions d’OCSP VA

L’application obtient
OCSP v1 (RFC 2560) travaille uniquement avec l’identifiant L’application utilisatrice
4 une information sur la
du certificat. L’application fournit à l’OCSP Responder 1 demande le statut d’un
validité du certificat
certificat
l’identifiant du certificat. Le seul service assuré est donc en
conséquence la vérification des informations de non-
suspension et de non-révocation.
Application
OCSP v2 (en cours de normalisation) pourra utiliser
utilisatrice
directement le certificat. L’application fournira le certificat lui-
même à l’OCSP Responder, qui sera alors en mesure de Figure 12 : Vérification de la validité d’un
vérifier comme OCSP v1 les informations de non-suspension
et de non-révocation, mais également les dates de validité, le certificat par une VA avec consultation de la
statut de la CA ayant signé le certificat ainsi que la chaîne de base de données de la CA
certification.

L’utilisation d’une VA présente donc les

D’autres évolutions de ce protocole devraient voir le jour,
comme SCVP (Simple Certificate Validation Protocol) qui
principaux intérêts suivants :
utilise XML.
! Les applications sont « déchargées » en
grande partie de la tâche de validation des
certificats.
Deux types d’implémentation sont possibles
pour l’OCSP Responder : ! Les applications sont certaines d’obtenir
une information sur la validité du certificat
! Utilisation des CRL qui soit la plus récente possible.
L’OCSP Responder récupère les CRL, ou ses ! Les applications obtiennent une réponse
dérivés, en local avec la même signée électroniquement par la VA, ce
problématique de stratégie de récupération qui peut constituer un élément de preuve
(pull/push) que dans le cadre de la sur la validité du certificat en cas de
vérification de la validité des certificats par contestation ultérieure sur la validité d’un
les applications. échange.

Le choix de la méthode de validation est à la

charge de l’applicatif et sera fonction du niveau
de criticité de l’application.

Page 20 LES PKI - LIVRE BLANC


3.4. AUTRES SERVICES
(RECOUVREMENT,
HORODATAGE ET NOTARIAT)
Les fonctionnalités et briques techniques
de la PKI que nous venons de présenter
concernent directement la gestion du cycle
de vie et l’exploitation par les applications
des certificats.
D’autres services peuvent être également mis
en place par la PKI, notamment des services de
recouvrement, ou encore des services
d’archivage et d’horodatage nécessaires pour la
non-répudiation.
SERVICE DE RECOUVREMENT
Pour des raisons pratiques (éviter la perte de
données chiffrées) mais aussi juridiques
(nécessité de mettre à disposition de la justice
les données chiffrées), la PKI peut rendre des
services de sauvegarde et de recouvrement des
clés privées de chiffrement, et/ou des services
de séquestre de ces clés.
En revanche, il ne doit jamais être envisagé de
service de recouvrement de clé privée de
signature.
Pour réaliser ce service, une brique hautement
sécurisée placée sous la responsabilité d’une
autorité bien identifiée (qui peut être la CA ou
une tierce partie de confiance dédiée) est en
charge de la sauvegarde des clés privées de
chiffrement et de l’accès à ces données par des
personnes autorisées.
Lorsque le bi-clés est généré au sein de
l’Infrastructure de Confiance, la clé privée est
directement transmise à l’organe prévu à cet
effet. C’est la solution la plus fréquemment
retenue.
Lorsque le bi-clés est généré en local sur le
poste de l’utilisateur, la clé privée doit être
transmise à l’Infrastructure de Confiance pour
pouvoir bénéficier de ce service. Ce transfert se
fait préférablement hors ligne, mais il peut
également se dérouler après la remise du
certificat à l’utilisateur à travers un échange
sécurisé.
Des solutions alternatives peuvent être
utilisées :
! Chaque chiffrement peut être réalisé deux
fois, une fois avec la clé publique du
destinataire, et une fois avec la clé publique
d’une autorité de recouvrement dédiée.
Page 21
L’autorité de recouvrement peut se
!
contenter de sauvegarder de manière
sécurisée les clés symétriques utilisées par
chaque chiffrement.
Les processus organisationnels liés au
recouvrement sont complexes à mettre en
place. Il faut s’assurer de l’habilitation du
demandeur d’un recouvrement, éventuellement
informer le porteur de la clé correspondante…
HORODATAGE
L'horodatage permet d'associer une date /
heure réputée fiable à un document ou à une
transaction électronique.
Il est ainsi souvent utilisé pour prouver
l'antériorité d'un message ou d'une transaction
par rapport à un évènement, par exemple la
révocation d'un certificat.
L'horodatage doit ainsi satisfaire deux
impératifs :
! S'appuyer sur une source de temps
reconnue par tous les acteurs impliqués
dans la transaction :
Une des sources les plus utilisées par les
systèmes d'horodatage est le GPS, précis à
1 µs. D'autres sources peuvent être
utilisées, notamment l'horloge parlante
téléphonique (précise à 20 ms), les stations
LF comme l'émetteur France Inter (précise à
1 ms), le CDMA utilisé dans les réseaux de
téléphones mobiles UHF (précis à 100 µs)
ou le NTP à précision variable.
Le fait que la source de temps soit reconnue
de tous les acteurs concernés est en
pratique souvent plus important que la
précision intrinsèque de cette horloge.
! S'associer de façon irrévocable au
document ou à la transaction :
Cette association, pour être incontestable,
doit s'appuyer sur un mécanisme de
signature par une "Autorité d'Horodatage",
reconnue des différents acteurs, c'est à dire
respectant une politique d'horodatage
conforme à l'état de l'art, utilisant un
certificat contrôlable... Le fichier signé par
cette autorité comprend une trace du
document ou de la transaction visée et le
jeton d'horodatage lui-même. Lorsque la
transaction a déjà été signée par son
"propriétaire", l'autorité d'horodatage vient
ainsi la contre-signer avec sa propre clé de
signature.
LES PKI - LIVRE BLANC
 Les jetons d'horodatage signés par l'autorité
d'horodatage ne peuvent être falsifiés ou
3.5. SYNTHESE
contrefaits sauf dans le cas éventuel de
compromission de sa clé de signature qui
pourrait être utilisée de manière illicite En synthèse, nous avons représenté sur le
avant la révocation du certificat associé. schéma suivant les briques fonctionnelles
présentes dans une architecture PKI offrant un
Les travaux de normalisation, réalisés au sein service très complet, ainsi que les interactions
de l'IETF, ont aboutis en août 2001 à la RFC entre la PKI et les utilisateurs.
3161 "Internet X 509 Public Key Infrastructure
Time Stamp Protocol", décrivant le format
Accès utilisateurs au dépôt
d'échange avec une autorité d'horodatage
(TSA). Demande de
validation de
certificat
HSM
Dépôt (repository )
NOTARIAT OCSP Responder certificats, CRL…
(LDAP ou autre)

Certificat et bi-
Le notariat consiste à archiver des informations, Statut du
Archivage des
clés privées HSM
clés sur suppor
matériel
après les avoir horodatées et signées, dans le
certificat
HSM Autorité de
but de retrouver le séquencement des Synchronisation Serveur de
certification (CA) Génération des bi-clés

échanges, et d’exhiber les preuves de la réalité client Personnalisation des

temps
Autorité Cartes à puce et token
et/ou du contenu de ces échanges. Le notariat d’enregistrement (RA)

permet d’offrir une fonction de non-répudiation Demande de notariat

Notaire hors-ligne Demande de
complète. Récupération d’actes certificat ou
de révocation

L’archivage consiste à stocker des informations

dans un lieu et sur des supports sécurisés, afin
Figure 13 : Exemple d’une architecture PKI
de pouvoir y accéder ultérieurement.

Le notariat peut être réalisé soit au niveau de

chacune des applications, soit au niveau d’un
service d’horodatage et d’archivage, qui stocke
l’ensemble des informations qui lui sont
transmises.

Soulignons le fait que le notariat peut être

réalisé hors ligne (les autres briques demandent
à la brique d’archivage de conserver un
élément) ou en ligne (les éléments transitent
obligatoirement par cette brique qui après
horodatage et archivage les transmet au(x)
destinataire(s)).

Page 22 LES PKI - LIVRE BLANC

 Tous les utilisateurs dépendant de l’une des CA
4. INTERCONNEXION racines reconnaissent ainsi les certificats émis
par l’autre CA racine.
DES PKI

L’établissement d’un lien de confiance entre Domaine

Autorité de Global Autorité de
deux parties repose sur la confiance placée par Certification A A+B Certification B
chaque partie en la signature de la CA figurant Domaine Domaine
A B
sur le certificat de l’autre partie.

Avant qu’une CA puisse générer et signer des

certificats pour le compte d’entités utilisatrices,
elle doit elle-même générer et signer son Figure 15 : Certification croisée
propre certificat pour représenter sa propre
identité.

Une telle CA ayant signé son propre certificat CERTIFICATION HIERARCHIQUE

est appelée Autorité de Certification racine (root
CA). Le modèle de certification croisée trouve ses
limites lorsque le nombre de CA racines croît de
L’ensemble des entités (utilisateurs et façon significative. Dans ce cas, les standards,
applications) reconnaissant l’Autorité de la CA et en particulier la norme X.509, ont proposé le
racine constitue un domaine de sécurité. Un tel concept de hiérarchie de certification. Ce
domaine peut être implémenté pour couvrir une concept s’appuie sur la définition d’une
organisation, une société, une communauté hiérarchie de CA dont le sommet est constituée
d’intérêt… par une unique autorité racine.

Le certificat d’une autorité est signé par

l’autorité hiérarchiquement supérieure, et ainsi
CA Racine de suite jusqu’à l’autorité racine.

Domaine de Le principal intérêt de ce modèle est d’étendre

confiance le domaine de sécurité avec la flexibilité
apportée par la construction arborescente des
Autorités de Certification.

Utilisateurs Dans le cas d’une hiérarchie de certification, la

confiance des deux parties passe donc par la
vérification de la signature de chaque certificat
de CA, jusqu’à un certificat « racine » qui est
Figure 14 : Domaine de confiance signé par son propre propriétaire : la CA racine.

Il est intéressant de souligner que les

navigateurs du marché (Internet Explorer et
Netscape Communicator) intègrent par défaut Autorité de
Certification Racine
un ensemble de certificats de CA racines,
reconnues comme « dignes de confiance » Autorité de Domaine Autorité de
(VeriSign, GTE CyberTrust, Thawte…) Certification A Global Certification B
A+B
Domaine Domaine
A B
CERTIFICATION CROISEE

Deux CA racines peuvent être amenées à se

faire mutuellement confiance, par exemple lors
du rapprochement de deux sociétés. Dans ce
cas, une certification croisée est opérée entre Figure 16 : Certification hiérarchique
les deux entités : chaque autorité racine signe
de façon bi-latérale la clé publique de l’autre
autorité racine, reconnaissant ainsi la confiance
accordée à l’autre autorité racine.

Page 23 LES PKI - LIVRE BLANC

INTERETS ET CONTRAINTES DE
L’INTERCONNEXION DES PKI

La mise en œuvre de ces concepts

d’interconnexion de PKI va permettre de créer
de vastes domaines de confiance sur des
réseaux ouverts comme Internet. Par exemple
dans le domaine du commerce électronique, un
utilisateur détenant un certificat délivré par une
banque pourra commercer avec un vendeur qui
détient un certificat fourni par une autre
banque, pourvu que les banques en questions
aient interconnecté leurs PKI, et en évitant de
diffuser à l’ensemble des utilisateurs les
certificats racines des AC de chaque banque.

Toutefois, la mise en place d’une interconnexion

des PKI n’est pas une simple opération
technique : pour que cette connexion ait un
sens, il faut garantir la compatibilité entre les
politiques de sécurité mises en œuvre par
chaque CA participante.

Pour cette raison, la mise en place en pratique

de la certification hiérarchique ou de la
certification croisée est réalisée dans le cadre
d’initiatives très encadrées, imposant des règles
de fonctionnement strictes : c’est le cas par
exemple d’Identrus ou de GTA, dont nous
décrirons les principes plus loin.

De manière générale, l’interconnexion des PKI

doit reposer sur la compatibilité des politiques
de certification, que nous allons décrire
maintenant.

Page 24 LES PKI - LIVRE BLANC

5. POLITIQUE DE
Principaux processus relatifs au cycle de vie des
certificats destinés aux utilisateurs

CERTIFICATION ET
Phase d’initialisation
- Enregistrer une demande de certificat
- Authentifier une demande de certificat

CADRE LEGAL -
-
Générer le certificat
Distribuer le certificat (et la clé privée dans certains cas)

Phase d’utilisation
- Vérifier le statut d’un certificat
Une PKI ne se limite pas uniquement à des
briques techniques. Elle se compose également Phase de révocation ou de suspension
de règles de sécurité et de processus - Enregistrer une demande de révocation ou de
organisationnels, régissant la fabrication et suspension
l’utilisation des certificats. Ces processus et ces - Révoquer un certificat
règles sont d’une importance cruciale pour - Suspendre un certificat
mesurer la confiance que l’on peut accorder aux - « Revalider » un certificat suspendu
certificats qui seront délivrés par la PKI.
Phase de renouvellement
- Enregistrer une demande de renouvellement
En effet, l’infrastructure technique aura beau
- Renouveler un certificat
être parfaitement sécurisée et protégée, les
- Publier et distribuer le nouveau certificat
certificats n’auront aucune valeur si les
processus organisationnels ne sont pas Gestion du support matériel (carte à puce)
rigoureusement définis et appliqués. A titre - Enregistrer une demande de déblocage du PIN Code
d’exemple, nous pouvons citer l’exemple récent - Débloquer le PIN Code
de certificats délivrés par l’opérateur Verisign à
des employés de Microsoft, qui se sont révélés Principaux processus relatifs au cycle de vie des
être de faux employés : les certificats ont été composants de la PKI
délivrés non pas suite à un problème ou une - Création de l’Autorité de Certification
faille technique, mais parce que les procédures - Création d’Autorité d’Enregistrement centralisée et/ou
de vérification d’identité prévues n’ont pas été déléguées
appliquées complètement par Verisign. - Fin d’activité d’une Autorité de Certification
- Renouvellement des certificats des composantes de
l’infrastructure (CA, RA…)
Nous décrivons ci-dessous les principaux
processus à formaliser et les documents - Compromission des clés des composantes de
l’infrastructure (CA,RA…)…
associés. Ensuite nous décrivons comment la loi
française se propose de fixer un cadre pour la
reconnaissance de la signature électronique,
grâce aux certificats qualifiés et à la signature CLASSES DE CERTIFICATS
avancée.
Une réflexion doit par ailleurs être conduite
pour définir la « gamme » des certificats qui
seront utilisés. En effet une organisation peut
5.1. PROCESSUS ET CLASSES DE décider pour diverses raisons d’émettre
plusieurs types de certificats, avec des
CERTIFICATS caractéristiques différentes. On parle
généralement de classes de certificats. Les
différences entre les classes de certificats
PROCESSUS ORGANISATIONNELS porteront le plus souvent sur :

A l’initialisation de tout projet PKI, une réflexion ! le niveau des contrôles réalisés lors du
doit être menée pour formaliser les processus processus d’enregistrement et de
organisationnels nécessaires à la gestion des distribution des certificats,
certificats, ainsi que des processus nécessaires
! le support utilisé pour stocker ces
à la gestion de la PKI elle-même.
certificats.
Cette réflexion doit permettre de définir les ! les usages possibles du certificat (signature,
responsabilités de chacun des acteurs chiffrement…),
intervenants autour de la PKI (CA, RA, VA,
utilisateur…) ! les populations de porteurs de certificats

! le cas échéant, les applications utilisatrices.

Page 25 LES PKI - LIVRE BLANC

Il est par exemple possible de définir un Traitant de la répartition des responsabilités
certificat de « haute-sécurité », stocké sur une entre les différents composants de
carte à puce, avec deux authentifications de l’Infrastructure de Confiance, la PC est
l’utilisateur en « face à face » physique lors de structurante pour le déploiement et
l’enregistrement et de la remise du certificat. A l’exploitation de la PKI.
l’opposé, un certificat de faible sécurité serait
basé sur un enregistrement et une distribution Plan type d’une Politique de Certification
entièrement automatisés et serait stocké sur le Le RFC 2527 donne une recommandation quant au plan type
disque dur du poste de travail. d’une PC. C’est ce plan que nous décrivons ci-dessous.
1. Introduction
Les résultats de ces réflexions sont notamment 1.1 Présentation générale
consignés dans deux documents qui sont à la 1.2 Identification
1.3 Autorités, applications et groupes d’utilisateurs
base du fonctionnement de la PKI : la Politique
concernés
de Certification (PC ou Certificate Policy en 1.4 Points de contact
anglais) et la Déclaration des Pratiques de 2. Dispositions d’ordre général
Certification (DPC ou Certification Practice 2.1 Obligations
Statement en anglais). 2.2 Responsabilités
2.3 Interprétation de la loi
2.4 Publication et services associés
2.5 Contrôles de conformité

5.2. PC ET DPC 2.6

3.
Politique de confidentialité
Identification et authentification
3.1 Enregistrement initial
3.2 Re-génération de certificats après expiration
3.3 Re-génération de clés après révocation
POLITIQUE DE CERTIFICATION (PC)
3.4 Authentification d’une demande de révocation
4. Besoins opérationnels
La Politique de Certification (PC) est un 4.1 Demande de certificat
ensemble de règles qui indique les conditions 4.2 Génération de certificat
d’applicabilité d’un certificat pour une 4.3 Acceptation de certificat
communauté donnée ou pour des applications 4.4 Révocation et expiration de certificat
ayant des besoins de sécurité communs. Les 4.5 Journalisation des événements
4.6 Archives
principaux rôles de la PC sont donc de :
4.7 Changement de clé d’une composante
4.8 Compromission et plan anti-sinistre
! définir le périmètre d’utilisation des
4.9 Fin de vie de la CA
certificats,
5. Contrôles de sécurité physique, des procédures et
du personnel
! spécifier les obligations et définir les 5.1 Contrôles de sécurité physique
responsabilités des utilisateurs et de 5.2 Contrôles des procédures
chacune des entités composantes de la PKI, 5.3 Contrôles du personnel
6. Contrôles technique de sécurité
! déterminer le niveau des contrôles 6.1 Génération et installation de bi-clés
d’authentification et de vérification des 6.2 Protection des clés privées
attributs. 6.3 Autres aspects de gestion des bi-clés
6.4 Données d’activation
6.5 Contrôles de sécurité des postes de travail
Ainsi, la PC indique les garanties offertes par les
6.6 Contrôles techniques du système durant son cycle de vie
certificats émis par l’Infrastructure de 6.7 Contrôles de sécurité du réseau
Confiance, ainsi que les conditions d’utilisation 6.8 Contrôles techniques du module cryptographique
de ces certificats. Elle ne traite pas des 7. Profil des certificats et des CRL
pratiques mises en œuvre pour atteindre ces 7.1 Profil du certificat
garanties : c’est le rôle de la DPC. 7.2 Profil de CRL
8. Administration des spécifications
La politique de certification est un 8.1 Procédure de modification des spécifications
8.2 Procédure de publication et notification
document de « haut niveau » : elle peut 8.3 Procédures d’approbation de la CPS
être définie indépendamment des
contraintes organisationnelles de
l’environnement de mise en œuvre auquel
elle s’applique. Ainsi, une PC peut être la
Avant sa mise en application effective par la
même pour plusieurs entreprises ayant des PKI, la PC peut être soumise à une validation
exigences de sécurité d’un niveau juridique et à un audit de sécurité qui
semblable. déterminent sa cohérence. Ce type de
validation est fortement conseillé.

Page 26 LES PKI - LIVRE BLANC

Dès lors qu’elle s’applique à un environnement
ouvert, dans lequel une relation contractuelle lie
la CA et les utilisateurs des certificats, la PC
doit être rendue publique : les utilisateurs
peuvent ainsi s’assurer que les politiques mises
en œuvre au sein de la PKI sont dignes de
confiance. Les opérateurs de certification
publient souvent sur leur site Web les politiques
de certification qu’ils appliquent.
Il est aussi possible de référencer la PC auprès
d’un organisme tiers (comme l’AFNOR) : cet
organisme délivre alors un identifiant unique
(OID) qui peut être repris dans un champ du
certificat. Ceci permet à l’utilisateur d’identifier
de manière unique la PC appliquée par la CA
émettrice du certificat, puis de déterminer s’il
lui fait ou non confiance.
La publication des PC est également nécessaire
lorsque deux CA souhaitent se faire confiance
mutuellement, dans le cadre d’une certification
croisée. Par la consultation et la comparaison
de leurs PC respectives, elles peuvent
déterminer les garanties offertes par l’autre
protagoniste et décider de la confiance à lui
accorder.
Contraintes juridiques
Un certain nombre d’aspects juridiques doivent être pris en
considération au moment de la rédaction de la PC, car ils ont
une incidence forte sur les processus organisationnels de
l’entreprise.
En particulier au moment de la demande de certificat par un
utilisateur, l’entreprise récupère un certain nombre
d’informations sur le demandeur. Deux textes régissent la
protection de la vie privée face à la collecte de données
personnelles : la loi informatique et libertés du 6 janvier 1978
et la directive communautaire du 24 octobre 1995.
Aujourd’hui, le droit de collecte et de traitement des données
personnelles est libre pour les organismes privés, à condition
que le fichier soit déclaré à la CNIL (Commission Nationale de
l’Informatique et des Libertés) et que cette commission
n’émette pas de réserve.
Par ailleurs la PC doit préciser les durées de conservation des
données liées au fonctionnement de la PKI (dossiers
d’enregistrement, listes de révocations…). La conservation
sur des périodes très longue pose des problèmes techniques
et organisationnels considérables. Il convient de vérifier
qu’elles sont les durées adéquates d’un point de vue juridique
en fonction de l’usage des certificats.
Page 27
DECLARATION DES PRATIQUES DE
CERTIFICATION (DPC)
La DPC, ou Déclaration des Pratiques de
Certification, décrit les pratiques mises en
œuvre pour atteindre les garanties sur les
certificats, énoncées dans la PC. Ce document
répond à la question du « comment », alors que
la PC répondait plutôt à la question du « quoi ».
La DPC est donc la déclaration de la part des
entités de la PKI (CA, RA…) des détails de leur
système de confiance et des procédures
employées pour réaliser l’ensemble des tâches
dont elles sont responsables : création et
exploitation des certificats, création et
exploitation des listes de révocation...
Ce document, dont la rédaction est placée
généralement sous la responsabilité de la CA,
est donc l’adaptation de la PC aux contraintes
humaines, matérielles et organisationnelles de
l’entreprise. De ce point de vue, il est logique
que la diffusion de ce document soit limitée,
contrairement à la PC qui était diffusée à très
large échelle.
5.3. RECONNAISSANCE LEGALE
DE LA SIGNATURE
ELECTRONIQUE
La cryptographie à clé publique est la
technologie qui va permettre à court terme de
mettre en application la nouvelle législation
dans le domaine de la signature électronique.
La Directive Européenne sur la signature
électronique et son application dans le droit
français apportent les bases juridiques à la
dématérialisation des échanges : une signature
électronique ne pourra plus désormais être
désavouée sous le seul prétexte qu'elle est
électronique et non manuscrite.
En d'autres termes, les parties d'un échange
dématérialisé seront donc affranchies d'un
accord contractuel préalable définissant une
convention de preuve, comme c'était le cas
jusqu'à maintenant.
LES PKI - LIVRE BLANC
 Signature électronique et législation
Le Parlement Européen a adopté une directive sur la
signature électronique le 13 décembre 1999. La loi française
correspondante a été votée le 13 mars 2000, entraînant une
mise à jour du code civil (loi n°2000-230).
Désormais, la signature électronique a la même valeur
juridique que la signature manuscrite et il n’est plus possible
d’invoquer la non-validité de la signature électronique pour
renier une transaction.
Le décret d'application (décret n°2001-272) qui définit
notamment les conditions précises de la validité des
certificats électroniques est paru le 31 mars 2001.
(pour la lecture de ces textes cf. www.legifrance.com).
Les arrêtés correspondants ne sont pas publiés à ce jour.
Dans le décret d’application français paru en
mars 2001, il est indiqué que « La fiabilité d'un
procédé de signature électronique est présumée
jusqu'à preuve contraire lorsque ce procédé
met en œuvre une signature électronique
sécurisée, établie grâce à un dispositif sécurisé
de création de signature électronique et que la
vérification de cette signature repose sur
l'utilisation d'un certificat électronique
qualifié ».
Ce texte fait apparaître trois notions
importantes :
! Le certificat électronique qualifié : un tel
certificat doit être émis par un Prestataire
de Service de Certification (PSC)
préalablement accrédité, et doit comporter
un certain nombre d’éléments (certains
obligatoires, d’autres optionnels), tels que
le nom du signataire ou son pseudonyme,
les données de vérification de signature
électronique, la période de validité du
certificat, les conditions d’utilisation du
certificat, etc. Le certificat qualifié sera,
sauf à apporter la preuve du contraire,
« présumé fiable » par les tribunaux (ce qui
n'en fait pas forcément un certificat
"universel" accepté par tous : son utilisation
peut en effet éventuellement être restreinte
à un cadre contractuel spécifique).
La capacité d'un Prestataire de Service de
Certification à émettre des certificats
qualifiés sera évaluée par des organismes
de qualification, a priori accrédités en
France par la COFRAC. Cet audit sera
réalisé suivant une méthode et par rapport
à un référentiel de bonnes pratiques qui
n’est pas encore complètement défini à
l'heure où nous écrivons ces lignes.

! La signature électronique sécurisée : une

telle signature électronique doit permettre
d’identifier le signataire, doit pouvoir être
réalisée par des moyens que le signataire
puisse garder sous son contrôle exclusif, et
doit garantir avec l’acte auquel elle
s’attache un lien tel que toute modification
ultérieure de l’acte soit détectable. Les
technologies de cryptographie à clé
publique, sous réserve qu’elles soient mises
en œuvre dans un cadre rigoureux,
répondent à ces critères.

! Le dispositif sécurisé de création de

signature électronique : il s’agit d’un
dispositif qui doit faire l’objet d’une
certification par un prestataire agréé par les
services du Premier Ministre.

Page 28 LES PKI - LIVRE BLANC

6. UTILISATION DE
Nous décrivons dans ce chapitre les principaux
protocoles sécurisés par l’utilisation de
certificats et de la cryptographie à clé publique
LA PKI (cf. 6.1), puis les méthodes d’intégration
permettant aux applications d’utiliser les
certificats (cf. 6.2). Nous analysons notamment
les possibilités offertes par les PKI pour assurer
la gestion des habilitations. Enfin, nous
Nous avons vu précédemment comment les présentons les principales initiatives PKI dans le
certificats étaient créés et gérés par domaine du e-commerce et des téléprocédures
l’infrastructure PKI. Nous allons maintenant administratives (cf. 6.3).
examiner comment les applications et les
couches réseaux utilisent ces certificats pour
sécuriser les échanges.
6.1. PROTOCOLES DE
En première approche, quatre mécanismes de
sécurité permettent d’assurer les fonctions de SECURISATION DES
confidentialité, intégrité, authenticité et non-
ECHANGES
répudiation :
! chiffrement/déchiffrement des données,
! signature d’un message, L’implémentation des mécanismes de sécurité
s’appuyant sur les certificats X.509 et la
! vérification de la signature d’un message, cryptographie à clé publique peut être
réalisée à différents niveaux de l’infrastructure :
! vérification de la validité d’un certificat
(incluant la vérification du statut de ! Au niveau de la couche réseau, en utilisant
révocation). par exemple le protocole IPSec.
! Au niveau des couches de transport, en
Les trois premiers mécanismes peuvent être
utilisant par exemple SSL/TLS ou WTLS.
mis en œuvre par un protocole d’échange
sécurisé entre le client et le serveur. Le dernier ! Directement au niveau de certaines
mécanisme fait intervenir d’une part l’un des applications, en utilisant par exemple
acteurs de l’échange et d’autre part, S/MIME pour la messagerie ou XML-DSIG
l’infrastructure PKI. pour les échanges au format XML.

Partie cliente Partie Serveur

Application
Couche de sécuritéapplicative (S/MIME, XML-Dsig...)
Chiffrement/déchiffrement
Chiffrement/déchiffrement Chiffrement/déchiffrement
des données
des données des données

Signature d ’un
Signature ’un message
message Signature d ’un message
HTTP SMTP POP3 FTP IIOP...
c Protocole
Vérification de la
Vérification la signature
signature IPSec Vérification de la signature
SSL/TLS
WTLS
Couche de transport sécurisée (SSL/TLS, WLS...)
S/MIME
Vérification de la validité
d ’un certificat
XML-Dsig Vérification de la validité
d ’un certificat Couche transport (TCP ou UDP)

HTTP
Récupération des
CRL via protocole HTTP
Récupération des Couche réseau sécurisée ( IPSec...)
OCSP OCSP CRL via protocole
LDAP de transport LDAP de transport

RA
Couche réseau (IP)
Infrastructure à clés publiques
CA (PKI)
VA

Réseau physique
Figure 17 : Mécanismes de sécurité et
protocoles
Figure 18 : Sécurisation des couches réseaux,
transport et applicatives

Page 29 LES PKI - LIVRE BLANC


Notons que, par construction, les différentes
couches de sécurité identifiées sont
indépendantes. Il est ainsi possible d’exploiter
ou « d’empiler » l’ensemble des couches de
sécurité, comme l’illustre l’exemple suivant :
Sécurisation de l’application
de messagerie (S/MIME)
Sécurisation
de la couche
transport Couche de sécurité « Plug-in » S/MIME
(SSL)
Application Client de messagerie
utilisant POP3
Couche de transport sécurisée
TCP
Figure 19 : Exemple de la sécurisation de la
messagerie
6.1.1. Sécurité au niveau réseau :
IPSec
Le protocole IPSec, développé sous la conduite
de l’IETF, définit un ensemble de spécifications
permettant la sécurisation (par encapsulation)
des paquets IP.
Au niveau de la couche réseau, IPSec jette ainsi
les bases nécessaires à la mise en œuvre de
tunnels IP sécurisés ou VPN (Virtual Private
Network) :
! entre deux sites distants (VPN Lan-to-Lan),
! entre un réseau externe et le réseau interne
de l’entreprise (VPN Extranet),
! entre un poste nomade et le réseau interne
(VPN d’accès distant).
Dans la pratique, le protocole IPSec est
largement utilisé par les solutions de VPN
logicielles et matérielles, les équipements et
serveurs d’accès distants, les routeurs et les
firewalls.
Pour les applications ou protocoles s’appuyant
sur la pile TCP/IP, le protocole IPSec est
complètement transparent. Certains
mécanismes essentiels à la sécurisation des
applications ne sont donc pas assurés par
IPSEC et en particulier la signature électronique
à des fins de non-répudiation et
l’authentification des utilisateurs finaux : Seuls
les équipements d’extrémité au niveau réseau
sont authentifiés, en plus de garantir la
confidentialité et l’intégrité des échanges entre
ces extrémités.
6.1.2. Sécurité des échanges Web :
SSL et TLS
Le protocole SSL en version 2 ou 3 (Secure
Sockets Layer) est un protocole ouvert
développé par Netscape pour permettre la
sécurisation d’un canal de communication de
type « socket » (couche TCP).
Le protocole TLS v1.0 (Transport Layer
Security) constitue à ce jour la dernière version
de SSL, officiellement standardisée par l’IETF
(RFC 2246). Il faut toutefois noter que les
SSL
protocoles TLS et SSL ne sont pas strictement
interopérables.
Théoriquement, le protocole SSL permet la
sécurisation de tout protocole applicatif
s’appuyant sur la pile TCP/IP, tels que HTTP,
LDAP, NNTP, SMTP, FTP, Telnet ou encore IIOP.
Dans la pratique, les implémentations de SSL
éprouvées s’appliquent surtout à HTTP et LDAP
donnant ainsi naissance aux protocoles biens
connus HTTPS (HTTP sur SSL) et LDAPS (LDAP
sur SSL). SSL offre les services de sécurité
suivants :
! la confidentialité,
! l’intégrité,
! l’authentification du serveur,
! l’authentification du client (par certificat
depuis la version 3).
L’implémentation native de la dernière version
de SSL (version 3) par les navigateurs et
serveurs Web actuels du marché, fait de HTTPS
le standard de facto de sécurisation des
applications Web. Le protocole SSL est en effet
implémenté dans le code du navigateur pour
Internet Explorer et Netscape Communicator et
par tous les principaux serveurs HTTP (Iplanet,
Microsoft IIS, Lotus et Apache). Cette version 3
de SSL prévoit entre autres une authentification
optionnelle du client par certificat.
SSL est aujourd’hui massivement utilisé sur
Internet pour chiffrer les échanges et pour
authentifier les serveurs via l’utilisation de
certificats « serveurs ». En revanche
l’authentification des clients via l’utilisation de
certificats « clients » reste moins répandue.
Page 30 LES PKI - LIVRE BLANC
Il faut par ailleurs noter que les navigateurs et
serveurs Web standards n’intègrent pas toutes
les fonctions nécessaires à la validation des
certificats. Ainsi, l’absence de vérification
complète de la chaîne de certification, et
l’absence de vérification du statut de révocation
justifient l’ajout de composants logiciels
complémentaires (plug-in) sur les navigateur ou
serveurs, voire des développements
complémentaires (cf. chapitre 6.2).
6.1.3. WTLS pour les mobiles
Le protocole WTLS (Wireless Transport Security
Layer) correspond à l’adaptation du standard
TLS au monde WAP (Wireless Application
Protocol). Il permet ainsi d’assurer les mêmes
services que le protocole TLS dans le cadre d’un
échange entre un terminal WAP et une
passerelle WAP.
Toutefois, la sécurité n’est pas assurée « de
bout en bout », la passerelle constituant une
rupture pour l’authentification et le chiffrement
des échanges.
WTLS SSL ou TLS
Internet
Réseau
radio
Passerelle
WAP
Figure 20 : Architecture de sécurité WAP 1.0
A partir de WAP 2.0, il sera possible d’assurer
une sécurisation des échanges de bout en bout,
c’est à dire depuis le terminal mobile jusqu’au
serveur de contenu Web.
6.1.4. S/MIME pour la messagerie
Le protocole S/MIME (Secure Multi-purpose
Internet Mail Extension), actuellement dans sa
version 3.0, définit un protocole ajoutant la
signature numérique et le chiffrement au
format MIME (RFC1847), format structurant le
corps d’un message électronique sur l’Internet.
Le standard S/MIME v3
Le standard S/MIME est constitué de 4 parties :
Cryptographic Message Syntax (RFC 2630)
S/MIME Version 3 Message Specification (RFC 2633)
S/MIME Version 3 Certificate Handling (RFC 2632)
Diffie-Hellman Key Agreement Method (RFC 2631)
L’un des principaux apports de la version 3.0 (via la RFC
2632) de S/MIME réside dans la possibilité de demander au
destinataire un accusé de réception signé. Cet accusé de
réception constitue une preuve de bonne réception par le
destinataire, que l’émetteur du message peut conserver.
S’appuyant sur les notions de signature et
d’enveloppe électronique, S/MIME permet
d’offrir les services d’authentification, de
confidentialité, d’intégrité et de non-répudiation
nécessaires à la sécurisation des applications de
messageries. Plus généralement, S/MIME
sécurise tout échange orienté message, comme
par exemple les échanges de données
informatisés (EDI).
Cette sécurisation des messages peut être mise
en œuvre de bout en bout, c’est-à-dire entre
l’émetteur du message et le destinataire ou
entre 2 serveurs de messagerie d’entreprise.
6.1.5. XML-Dsig pour sécuriser
XML
Serveur
Web
Le langage XML (eXtensible Markup Langage)
désigne un méta-langage à balises permettant
de définir la structure et la grammaire de
document au format XML. Développé sous la
conduite du World Wide Web Consortium (W3C)
pour pallier les lacunes du langage HTML, le
langage XML connaît actuellement un réel
engouement du fait de la simplicité et de la
flexibilité qu’il offre.
Pour répondre aux besoins de sécurisation des
échanges B-to-B sur l’Internet, une initiative
commune de l’IETF et du W3C a donné
naissance aux spécifications XML-Dsig. Ces
dernières définissent à des fins de non-
répudiation, les règles de syntaxe et
d’élaboration de signatures électroniques pour
les documents XML.
Si ces spécifications ne constituent à ce jour
qu’un ensemble de recommandations du W3C,
le consensus d’acteurs majeurs ainsi qu’une
implémentation déjà significative de cette
technologie laisse présager prochainement son
passage au statut de « Draft Internet ».
Page 31 LES PKI - LIVRE BLANC
 de logiciels dédiés à la sécurisation du poste
6.2. INTEGRATION DANS LES !
de travail et des données stockées sur ce
APPLICATIONS dernier,
! de certains progiciels comme les ERP
(SAP…), SGBD (Oracle…).

Si de telles solutions sont par nature des

6.2.1. Intégration active ou
applications PKI-compatibles, il est préférable
passive de bien qualifier techniquement le
fonctionnement de manière très précise, avec
les certificats produits par l’infrastructure PKI
Au-delà de l’exploitation de SSL offerte retenue.
nativement par les navigateurs et serveurs
HTTP, la sécurisation des applications à l’aide INTEGRATION PASSIVE
des mécanismes cryptographiques peut être
menée suivant trois approches. L’intégration passive consiste à intégrer les
mécanismes de sécurité cryptographiques sans
La première consiste à utiliser une solution modification du code applicatif. Elle peut être
applicative « clé en main » proposée par les mise en œuvre :
différents éditeurs de logiciels généralistes ou
spécialisés dans le domaine de la PKI. ! par l’intégration, au sein des applications ou
des serveurs, de composants logiciels
La seconde approche consiste à ajouter à complémentaires appelés « plug-in » ou
l’applicatif un module complémentaire « snap-in »,
permettant, sans modifier le code de
l’application, d’utiliser les fonctions ! par insertion d’un serveurs-relais (approche
cryptographique et les services de la PKI. Une « reverse proxy ») entre le client et le
telle approche est qualifiée d’intégration serveur.
« passive ».
Les solutions techniques dans ce domaine sont
La dernière consiste à intégrer les fonctions proposées soit par les éditeurs de produits PKI
cryptographiques et d’accès à la PKI au sein comme Baltimore ou Entrust, ou bien par des
même de l’application, lors de son éditeurs très spécialisés comme Secude ou
développement. Il s’agit dans ce dernier cas Netegrity.
d’une intégration « active » de la sécurité,
directement au sein du code de l’application. INTEGRATION ACTIVE

Nous décrivons ci-dessous ces trois approches L’intégration active des mécanismes de sécurité
plus en détail. au sein des applications s’appuie sur des kit de
développement ou SDK (Software Development
Kit) généralement disponibles pour les langages
SOLUTIONS APPLICATIVES « CLE EN MAIN » C/C++ et/ou Java. Ces kits fournissent aux
développeurs différents niveaux d’interface de
Dans cette approche, on utilise une application programmation (API), que l’on peut classer en
qui intègre déjà les fonctions nécessaires à la trois types :
manipulation des certificats et des fonctions
! Des API orientées application : il s’agit de
cryptographiques, et qui permet
kits de développement permettant
éventuellement d’accéder aux services de la PKI
l’implémentation des protocoles normalisés
pour assurer la validation des certificats (accès
comme SSL, TLS, S/MIME ou encore la
aux CRL notamment).
sécurisation des documents au format XML.

Certains produits du marché intègrent en effet ! Des API de bas niveau fournissant des
nativement les fonctions les plus simples de fonctions cryptographiques élémentaires
manipulation des certificats. C’est le cas : comme le chiffrement, le hachage ou
! de certains clients de messagerie, l’encodage.

! de la plupart des serveurs Web du marché ! Des API « PKI » intermédiaires permettant
dans leurs dernières versions, de rendre PKI-compatible une application.

! de certains logiciels de type portails ou

serveurs d’autorisation,

Page 32 LES PKI - LIVRE BLANC

Ces dernières API permettent d’une part à
l’application d’exploiter l’infrastructure de
confiance pour valider les certificats : elles
offrent ainsi les librairies clientes permettant
par exemple de développer un client OCSP,
d’accéder à l’annuaire, de récupérer et traiter
les listes de révocation des certificats ou encore
de vérifier la chaîne complète de certification.
Ces API permettent d’autre part à une
application de définir elle-même son propre
protocole de sécurisation des échanges. Ce
dernier s’appuie sur des fonctions ou classes
mettant par exemple en œuvre les mécanismes
de signature électronique / vérification de la
signature ou de transport sécurisé des données.
API
API SSL/TLS API S/MIME applicative
Toolkit Toolkit
« SSL/TLS » « S/MIME »
API PKI
Toolkit « PKI » API
Cryptographie
Toolkit « Cryptographie »
Figure 21 : API d’intégration « active »
L’intégration active permet à l’application
d’avoir un contrôle total des mécanismes de
sécurité (instauration d’une session SSL, type
des algorithmes de chiffrement, taille des clés,
etc.). Cependant, cette approche peut s’avérer
d’une part coûteuse en temps et en hommes ;
elle induit d’autre part une certaine adhérence
entre les applications développées et le kit de
développement utilisé.
Nous décrivons ci-dessous deux exemples de
sécurisation d’application (sécurisation de la
messagerie et sécurisation d’application Web
sur HTTP).
6.2.2. Sécurisation de la
messagerie
Une première solution de sécurisation de la
messagerie consiste à chiffrer les échanges
SMTP établis entre 2 serveurs SMTP, en
s’appuyant sur la couche de transport sécurisée
TLS (RFC 2487). Cette solution présente
l’avantage d’être sans impact sur le routage de
la messagerie ; cependant la non-répudiation
des messages et l’authentification des
utilisateurs finaux ne peuvent être assurés.
Page 33
Une seconde solution, éventuellement
complémentaire à la première, passe par l’ajout
d'un plug-in sur le client de messagerie de
l’émetteur et du destinataire.
Cet ajout s’avère nécessaire pour les clients ne
disposant pas de client S/MIME intégré, tels que
MS-Outlook 97, ou pour implémenter la version
3.0 de S/MIME dans le cas de clients S/MIME
version 2.0. De tels plug-in sont actuellement
disponibles pour les systèmes de messagerie
MS-Outlook 97/98, Outlook Express et Lotus-
Notes.
Ils permettent ainsi de chiffrer et signer un
message à l’aide du protocole standardisé
S/MIME v2 ou v3 suivant les offres, avec
consultation, dans le cas de S/MIME v3, d’une
liste de révocation locale (via mécanismes de
cache) ou distante (via interrogation de
l’infrastructure de confiance).
Message chiffré et signé
Plug-in S/MIME A XXXX
DE: Utilisateur
Client messagerie
Serveur de messagerie
3. Application possible d ’une
politique de sécurité basée
sur les champs A et DE
Utilisateur de l ’entreprise
1. Création d’un message
2. Signature et chiffrement du message
Passerelle SMTP / Internet
Plug-in S/MIME
4. Résolution
Client messagerie des adresses
Message chiffré et signé et relais des
messages
A XXXX
Destinataire DE: Utilisateur
Limite du
5. Déchiffrement réseau interne
6. Validation de la signature
Figure 22 : Sécurisation de la messagerie de
bout en bout
Si dans ce cas les messages sont signés et
chiffrés de bout en bout, interdisant ainsi toute
lecture par les administrateurs, elle présente
néanmoins un désavantage : elle s’oppose à la
mise en œuvre des solutions de filtrage du
contenu des messages ou de détection des
virus.
Pour pallier cette difficulté, la mise en place
d’une passerelle S/MIME en coupure est
envisageable : le principe consiste à chiffrer
et/ou signer les messages sortants au niveau
de la passerelle. Cette approche évite le
déploiement de clients S/MIME sur chaque
poste de travail en centralisant la gestion des
clés S/MIME au niveau de la passerelle.
LES PKI - LIVRE BLANC
 Ces différentes vérifications peuvent être
Message non chiffré Message non chiffré

effectuée via des échanges :

A XXXX A XXXX
Utilisateur de DE: Utilisateur
DE: Utilisateur Serveur de messagerie
l ’entreprise
2. Application possible d’une
! en mode « synchrone » : utilisation du
1. Création d’un
message politique de sécurité basée
sur les champs A et De +
Stockage des clés
protocole OCSP (On-line Certificate Status
Contrôle de contenu
Protocol)
Passerelle S/MIME
3. Signature et/ou
chiffrement du
message
Plug-in S/MIME Authentification Contrôle d’accès applicatif
Message chiffré et signé
Client messagerie
Message chiffré et signé Transmission de
A XXXX l’identité de
Serveur HTTP l’utilisateur Serveur d’application
DE: Utilisateur Certificat client SSL v3
A XXXX Limite du INTERNET

API

API
Destinataire DE: Utilisateur réseau interne Passerelle SMTP / Internet Plug-in de Application
validation
5. Déchiffrement 4. Résolution des
6. Validation de la signature adresses et relais des HTTP sur SSL (HTTPS)
messages
Requête Réponse
Navigateur Web
OCSP OCSP

Échange Serveur LDAP

OCSP
des CRL
Responder

Figure 23 : Sécurisation de la messagerie par CRL

une passerelle S/MIME

Figure 24 : Exemple de validation en mode
« synchrone »

6.2.3. Sécurisation des

applications Web ! en mode « asynchrone » : récupération
de CRL via un protocole de transport
comme HTTP ou LDAP

SECURISATION PAR AJOUT DE PLUG-IN

(INTEGRATION PASSIVE) Authentification Contrôle d’accès applicatif

Dans le cas d’une application Web, l’intégration Transmission de

l’identité de
de « plug-in » au sein du serveur HTTP et du Certificat client
Serveur HTTP
SSL v3
l’utilisateur Serveur d’application

navigateur permet de pallier les lacunes

INTERNET
API

API
Plug-in de Application
validation
actuelles des implémentations natives de SSL. HTTP sur SSL (HTTPS)
Cache

Les modules logiciels ajoutés peuvent suivant

CRL de CRL

Navigateur Web
les offres assurer eux-mêmes des vérifications CRL sur
complémentaires ou bien les déléguer à un LDAP
ou HTTP

serveur central de sécurité. LDAP HTTP

Dans le premier cas, le « plug-in » ajouté sur le

CRL

serveur Web joue le rôle d’un filtre d’accès au

serveur HTTP et donc le cas échéant au serveur Figure 25 : Validation en mode
d’application cible dans une architecture 3-tiers. « asynchrone »
Ce plug-in « serveur » peut permettre, avant
d’accéder à l’application, de valider la chaîne de
Ainsi, le processus complet d’authentification
certification et le statut de révocation du
est délégué au serveur Web. Pour effectuer ses
certificat client.
contrôles d’accès, l’application se contente de
récupérer certaines données relatives à
l’identité de l’utilisateur ou au certificat à l’aide
d’API.

Les offres du marché proposent ce type de

plug-in pour les principaux serveurs HTTP du
marché : Microsoft IIS, Iplanet Entreprise
Server et Apache. Le fonctionnement du plug-in
client (pour navigateur) est similaire et étend
donc les mécanismes de sécurité natifs des
navigateurs standards (Microsoft Internet
Explorer et Netscape Communicator).

Page 34 LES PKI - LIVRE BLANC

SECURISATION PAR DEVELOPPEMENT 6.2.4. Gestion des habilitations
SPECIFIQUE (INTEGRATION ACTIVE)

Des développements spécifiques au sein de En théorie, il est possible, grâce aux champs
l’application permettent de remplir les mêmes « extensions » du certificat X.509 v3, d’intégrer
fonctions qu’un plug-in implanté sur le serveur dans les certificats des informations concernant
Web. Dans ce cas, l’application peut assurer le profil du porteur du certificat (fonction dans
elle-même la gestion complète de la session l’entreprise, rôle vis à vis de telle ou telle
sécurisée ou effectuer exclusivement les application, pouvoir en terme de passage de
contrôles de sécurité non pris en charge commande ou de transaction…). En interprétant
nativement par le serveur HTTP. ces informations, les applications ont la
possibilité d’accorder ou non le droit d’accéder
aux données et aux transactions associées.
SECURISATION PAR INSERTION D’UN
SERVEUR-RELAIS (INTEGRATION PASSIVE) En pratique, il est pourtant peu recommandé
d’utiliser ces méthodes pour gérer les
L’approche « Reverse-proxy » permet de habilitations applicatives. En effet, le profil
sécuriser sans modification de code de applicatif d’un utilisateur est appelé à évoluer
nombreuses applications, dont les applications fréquemment (changement de fonction, accès à
Web. Néanmoins, l’ajout de composants une nouvelle application…), ce qui impliquerait :
complémentaires (généralement des agents) se
révèle dans la pratique souvent inévitable. ! soit de révoquer et recréer fréquemment
des certificats pour chaque utilisateur et de
Par construction, ce serveur-relais constitue un les mettre à disposition sur un serveur de
point de passage obligé : il centralise ainsi un gestion des habilitations centralisé,
certain nombre de vérifications concernant le
certificat présenté par le client (vérification de ! soit de diffuser à chaque utilisateur, en plus
la signature du certificat, du statut de de son certificat « d’identité », des
révocation…), avant de relayer les flux certificats « d’attributs » pour chaque
applicatifs vers des application ou serveurs application ou pour chaque groupe
cibles. d’utilisateur.

distincts. Dans les deux cas, les opérations

Serveur d’application

Serveur HTTP
SSL v3 d’enregistrement seraient multipliées et la
gestion des certificats deviendrait très
HTTPS contraignante pour les utilisateurs.

Les certificats sont donc aujourd’hui

Serveur d’application
Certificat client Serveur Relais
INTERNET HTTPS
Serveur HTTP
SSL v3 essentiellement utilisables pour assurer
HTTP sur SSL (HTTPS) l’authentification des utilisateurs, c’est à dire
Navigateur Web pour garantir l’identité d’un utilisateur qui se
connecte à une application. La gestion des
HTTPS
Serveur d’application

Serveur HTTP
droits applicatifs et des fonctions de contrôle
SSL v3
d’accès reste du ressort des applications et/ou
de systèmes logiciels dédiés, de plus en plus
souvent basés sur des annuaires LDAP.
Figure 26 : Validation via un serveur relais
Certains éditeurs de solutions PKI comme
Baltimore ou Entrust disposent de solutions de
gestion des habilitations couplées à leur PKI,
Ce serveur relais peut selon les cas et les offres mais ces solutions sont basés sur des produits
assurer, au-delà du service d’authentification,
de SSO (authentification une seule fois pour Les acteurs du marché des PKI réfléchissent
l’accès à de multiples applications), voire de actuellement au développement de solutions de
gestion centralisée des habilitations des gestion des habilitations basés sur l’utilisation
utilisateurs. de certificats, mais ces solutions ne sont pour
l’instant pas opérationnelles.

Page 35 LES PKI - LIVRE BLANC

 Cependant, il faut noter que le protocole SET ne
6.3. APPLICATIONS AU permet pas de sécuriser tout type de
E-COMMERCE (SET, transaction financière, mais uniquement celles
mettant en œuvre les cartes de crédit.
IDENTRUS, GTA) ET AUX
TELEPROCEDURES Un dérivé du protocole SET, le protocole C-SET
a été développé pour prendre en compte les
cartes bancaires à microcircuit.
Face à l’explosion du commerce électronique se
pose le problème majeur de sécurisation des Le protocole SET a été retenu par CyberCom
transactions financières. Les banques ont comme base de son offre de sécurisation des
cherché à mettre en place un standard qui paiements. Mais cette initiative a connu un
permette une sécurisation absolue des succès tout relatif.
échanges B-to-B et B-to-C.

Trois principaux standards ont ainsi émergé au MODELE IDENTRUS

cours des dernières années :
La société américaine Identrus
! le protocole SET, (www.identrus.com) a été fondée en avril 1999
par des banques américaines, européennes et
! le modèle Identrus, asiatiques dans le but de fournir une
infrastructure permettant le commerce
! le modèle GTA.
électronique B-to-B en toute sécurité, entre des
parties ne se connaissant pas a priori.

Identrus est une autorité racine de certification,

SET (SECURE ELECTRONIC TRANSACTION)
Les spécifications du protocole SET ont été
élaborées par VISA et MasterCard et publiées
en mai 1997. SET permet d’implémenter les
fonctions de sécurité nécessaires à la
sécurisation d’une transaction financière entre
un internaute, possesseur d’une carte de crédit,
et un site Web de commerce électronique :
! intégrité des données et non-répudiation,
à laquelle les autorités de certification des
banques adhérentes vont se raccorder dans un
modèle hiérarchique. L’autorité racine
IDENTRUS a pour rôle de garantir la conformité
des PKI de chaque banque aux spécifications
techniques et juridiques très strictes qu’elle
impose.
Identrus assure un audit des PKI des banques
participantes avant d’accorder son label.

! authentification du titulaire de la carte et

authentification du commerçant,
6. Réponse sur le
Racine statut de la
Identrus
! confidentialité des données.
banque A

5. Demande d’état
du certificat

Le protocole SET possède un certain nombre de

de la banque A
Relying
Banque A 4. Réponse à la demande Banque B
similitudes avec le protocole SSLv3 dans la
Issuing Participant
Participant

mise en œuvre des mécanismes de vérification

3. Demande de validation du PKI de la
PKI de la certificat de l'entreprise A Banque B

de l’identité des parties en présence.

Banque A
2. Demande de 7. Réponse sur
statut du le statut du
certificat certificat

La vérification des identités ne se fait pas Entreprise Entreprise B

uniquement de façon réciproque entre
1. Transmission
A cliente de électronique du certificat cliente de la
la Banque A de l'entrepriseA Banque B
l’acheteur et le commerçant, mais également
par une tierce partie, à savoir la passerelle de
Subscribing Relying
Customer Customer

paiement SET.
Figure 27 : Schéma simplifié de validation d’un
Chaque information est fournie uniquement à la certificat dans le modèle hiérarchique Identrus
partie concernée : les données de la commande
sont cachées à la banque pour protéger la vie
privée du client et les données de paiement
sont cachées au commerçant pour sécuriser la
transaction.

Page 36 LES PKI - LIVRE BLANC

Ce modèle est appelé modèle à quatre coins. En
effet, il réunit quatre acteurs, en plus de la
racine Identrus :
! Le Subscribing Customer (acheteur) désire
réaliser une transaction financière avec le
Relying Customer (vendeur).
! Le Subscribing Customer est client du
Issuing Participant, établissement bancaire.
Il détient des certificats délivrés par cet
établissement.
! Le Relying Customer est client du Relying
Participant, établissement bancaire. Il
détient des certificats délivrés par cet
établissement.
! Le Issuing Participant et le Relying
Participant possèdent des PKI conformes au
MODELE GTA (GLOBAL TRUST AUTHORITY)
GTA (www.gta.multicert.org) est une initiative
d’origine européenne, qui a vocation à s’élargir
aux autres continents. Là encore les banques
sont les principaux acteurs, mais le modèle
proposé, plus ouvert que celui d’Identrus, doit
pouvoir intégrer d’autres partenaires.
GTA est conçu pour fournir des services PKI à
toutes les applications (« schemes »), dont les
utilisateurs ne relèvent pas d'une Autorité de
Certification unique.
Racine
Racine
GTA
GTA

standard Identrus qui appartiennent à la

hiérarchie Identrus.
Master Trust Master Trust
Master Trust Master Trust
Authority Authority
Authority
Les certificats Identrus peuvent aussi être Authority
(MTA)
(MTA)
(MTA)
(MTA)
utilisés par des applications internes aux
banques, ou bien pour des applications
« banque à entreprise cliente».
Scheme Trust Scheme Trust
Scheme Trust Scheme Trust
Authority Authority
Authority Authority
L’utilisation des certificats Identrus est soumise (STA)
(STA)
(STA)
(STA)
à une redevance versée par les banques à la
société Identrus.

Environ cinquante banques internationales ont

adhéré à Identrus. Toutes devraient mettre en
place une PKI conforme au modèle Identrus.
End - user
Elles tardent pour la plupart à le faire, du fait End - user End - user End - user

du manque d’application candidates à

l’utilisation du modèle, et du fait de la Figure 28 : Architecture du modèle GTA
complexité des spécifications Identrus.

En effet, ces spécifications imposent des

contraintes élevées. La validation des certificats
doit être réalisée en ligne à chaque transaction
(utilisation d’OCSP), les transactions doivent
être horodatées et archivées, les certificats
doivent être stockés sur carte à puce, la
disponibilité de l’infrastructure doit être très
élevée…
Les éditeurs de logiciels de PKI proposent déjà
les premières solutions conformes aux
standards Identrus. Par ailleurs, Identrus
travaille en étroite collaboration avec d’autres
acteurs du monde bancaire, comme Swift, pour
développer des services applicatifs et/ou pour
définir des offres packagées qui vont simplifier
les déploiements pour les banques.
Swift doit notamment proposer une offre
dénommée TrustAct, qui va assurer le routage
des échanges, mais aussi l’horodatage et
l’archivage des transactions entre les clients et
les banques utilisant des certificats Identrus.
Tout comme Identrus, GTA souffre pour
l’instant du manque d’applications concrètes.
LES TELEPROCEDURES
Le Ministère de l’Economie, des Finances et de
l’Industrie (MINEFI) a entamé un vaste
programme de dématérialisation progressive
des échanges entre l’administration fiscale et
les administrés. Dans le cadre de cette
initiative, le projet « Téléprocédures » a eu
pour première étape visible la déclaration en
ligne de la TVA par les entreprises de plus de
15 Millions d’Euros de chiffre d’affaire. L’un des
moyens proposés pour la déclaration en ligne
consiste schématiquement à remplir un
formulaire électronique et à le déposer sur le
site Internet du MINEFI accompagné de la
signature électronique du représentant de
l’entreprise déclarante.

Page 37 LES PKI - LIVRE BLANC

Pour cela, ce représentant doit disposer d’une
clé privée et d’un certificat de la clé publique
correspondante. Ce certificat aura été délivré
au préalable par une Autorité de Certification
(CA) agréée par le MINEFI. Cet agrément, qui
est délivré à l’issue d’un audit de la CA par le
MINEFI, permet de vérifier que la PC appliquée
par la CA répond bien au niveau de sécurité et
de qualité de service souhaité par le MINEFI.

Le MINEFI a par ailleurs édité une Politique de

Certification « de référence » qui définit les
minima à respecter.

Actuellement, une dizaine d’Autorités de

Certification sont référencées. Il s’agit
principalement d’institutions bancaires, qui
s’appuient sur leur réseau d’agences pour
réaliser l’enregistrement des représentants
d’entreprise. Certaines de ces banques ont
élargi le cadre d’application de leur PC, pour
permettre à leurs clients d’utiliser les certificats
ainsi délivrés pour les téléprocédures, mais
aussi pour accéder à certaines applications
« bancaires ».

Très prochainement, la PC de référence du

MINEFI va être revue pour prendre en compte
les décrets d’application et les futurs arrêtés
publiés pour la mise en œuvre de la loi sur la
signature électronique.

Page 38 LES PKI - LIVRE BLANC

7. MARCHE DE LA PKI
Une entreprise désirant faire du e-
commerce fait certifier son serveur par un
tiers, reconnu digne de confiance par les
internautes (typiquement Verisign ou son
représentant en France Certplus, GTE
CyberTrust, Thawte, dont les certificats sont
par défaut présents dans les navigateurs),
7.1. VISION GLOBALE afin que les internautes puissent
authentifier ce serveur et réaliser des
achats en ligne. Il s’agit alors simplement
d’acheter un certificat « serveur » à l’un de
MARCHE GLOBAL ces acteurs.

La plupart des études de marché réalisées ! Le déploiement d’une PKI à usage

avant l’année 2000 prévoyaient un interne et à périmètre limité
développement rapide du domaine des PKI.
De nombreuses grandes entreprises ont
! Selon les prévisions d’IDC, le marché de la mené ou mènent actuellement des
PKI passerait de 281 millions de dollars en déploiements PKI pilotes sur des
1999 à 3 milliards de dollars en 2004. applications précises (sécurisation de la
messagerie par exemple), afin d’évaluer les
! Datamonitor annonçait pour sa part un impacts de la mise en place d’une PKI.
marché atteignant les 3,5 milliards de
dollars pour 2003.
Peu d’entreprises se sont actuellement lancées
dans le déploiement d’une PKI à grande échelle.
Dans les faits, selon une étude plus récente
d’Arthur Andersen, 89 % des grandes
entreprises pensent mettre en œuvre une PKI,
mais seulement 6 % l’ont déjà fait et 32 % sont PROJETS CONNUS EN MATIERE DE PKI
en train de le faire ou de concevoir une
maquette. Il existe néanmoins quelques projets de
déploiement de PKI de grande envergure,
Le graphique ci-dessous montre l’évolution même s’ils sont essentiellement réalisés à
prévue du marché pour les années à venir : l’étranger.

Le secteur des banques et assurances,

$4 000 souhaitant favoriser les échanges marchands
CA services sur l’Internet, est le principal moteur du
marché. Citons quelques exemples
$3 500
Maintenance

$3 000 Professional Services d’établissements ayant lancé des projets PKI :

ABN AMRO Bank, Bank of Ireland, Bank of
System Integration
$2 500 America, Bank of Bermuda, Deutsche Bank,
Revenues
Dresdner Bank, Rabobank International.
Products
$M
$2 000

$1 500 En France, la plupart des grandes banques ont

mis en place une infrastructure dans le cadre du
$1 000
projet TéléTVA : c’est le cas de BNP Paribas,
$500
des Banques Populaires, du Crédit Agricole, du
CCF, du Crédit Lyonnais, de la Société Générale
$0 et de la Poste via sa filiale Certinomis. Pour ces
2000 2001 2002 2003 2004 2005 2006
institutions, se pose la question de développer
une activité de certification et de se positionner
Figure 29 : Prévisions du marché de la PKI pour comme Autorité de Certification vis à vis de
2000-2006 par catégorie de revenus leurs clients.
(Source RSA Security)
Les administrations et institutions sont
également en phase de réflexion avancée voire
de déploiement de solutions PKI. Nous pouvons
TYPES DE MISES EN ŒUVRE ACTUELLES citer : UK Ministry of Defence, Australian Tax
Office, Quebec Ministry of Justice, et en France
A l’heure actuelle, les usages de certificats sont le Ministère de l’Education Nationale, le
concentrés essentiellement sur deux grands Ministère des Finances, le Ministère de la
types de besoin : Culture, le Ministère de l’Agriculture, la CNAV.

! La certification des serveurs Web

Page 39 LES PKI - LIVRE BLANC

En fait, de tels projets PKI commencent à
toucher la grande majorité des secteurs
d’activité :
! Industrie (Aérospatiale Matra, France
Télécom, PSA, Renault),
! Poste (Royal Mail, Uruguay Post, PTT Post,
La Poste),
! Santé (initiatives du GIP CPS et GIP MDS),
! Transport et tourisme (Amadeus).
(Sources : Cigref et éditeurs)
7.2. ACTEURS DU MARCHE
Le marché de la PKI regroupe un grand nombre
d’acteurs de tous types :
! des éditeurs de logiciels proposant des
solutions à divers niveaux (CA, RA, VA…)
d’une PKI interne,
! les fournisseurs de modules
cryptographiques pour serveurs,
! les fournisseurs de support de clés privées
pour utilisateur final (principalement carte à
puce ou token),
! les fournisseurs de services : opérateurs de
confiance ou « vendeurs » de certificats,
! les « promoteurs de standards », c’est à
dire les groupes de travail qui interviennent
à différents niveaux pour élaborer des
normes et standards.
EDITEURS DE LOGICIELS « CŒUR DE PKI »
(CA, RA…)
Cette première catégorie d’éditeurs fournit les
logiciels nécessaires à la mise en place des
briques de base d’une PKI (CA et RA
principalement).
Citons les offres :
! Baltimore Technologies - UniCERT,
! CertCo - CertCo Trust Solutions,
! Computer Associates - eTrust PKI,
! Entrust Technologies - Entrust/PKI,
! iPlanet, alliance Sun Netscape - Certificate
Management System,
! Microsoft - Windows 2000 PKI,
! RSA Security - RSA Keon Advanced PKI,
Page 40
! Sagem - PKI Confidence,
! Sonera - SmartTrust (ex solution ID2),
! Utimaco - SafeGuard PKI.
Les acteurs majeurs dans ce domaine sont
Baltimore, Entrust, iPlanet et RSA. Parmi les
solutions françaises, ce sont les industriels
comme Sagem qui se positionnent.
Citons enfin quelques initiatives qui
commencent à se développer dans le monde du
logiciel libre à partir de briques telles que
OpenCA, OpenSSL, OpenLDAP… : des sociétés
comme IDEALX proposent des solutions PKI
packagées, en mettant en avant un coût logiciel
nul.
EDITEURS DE LOGICIEL SPECIALISES (VA,
SOURCE DE TEMPS, KITS CLIENTS ET
SERVEURS…)
Quelques éditeurs fournissent des logiciels
dédiés au rôle d’Autorité de validation. Le
leader dans ce domaine est ValiCert. Les autres
acteurs sont par exemple Computer Associates
(avec son offre eTrust OCSPro), ou encore
CertCo, Sagem, Kyberpass ou SmartTrust.
Les briques de type « serveurs de temps » sont
proposées par Datum, Time Proof, TimeCertain,
Certified Time, TrueTime ou encore Baltimore.
Les modules kit clients et kit serveurs sont
proposés, en plus des fournisseurs classiques
comme Baltimore ou Entrust, par des acteurs
tels que Celo (filiale de Gemplus), Secude,
Entegrity ou Phaos Technology.
FOURNISSEURS DE MODULES
CRYPTOGRAPHIQUES
Certaines sociétés sont spécialisées dans la
fourniture de modules cryptographiques : les
HSM (Hardware Security Module). Ceux-ci
permettent notamment le stockage de données
sensibles.
Les principaux acteurs sont :
! Bull (TrustWay Crypto),
! Chrysalis (Luna CA3),
! NCipher (nForce et nShield),
! Rainbow Technologies (CryptoSwift HSM),
! Sagem Confidence.
Baltimore a aussi une offre dans ce domaine.
(SureWare).
LES PKI - LIVRE BLANC
FOURNISSEURS DE CARTES A PUCE
Pour offrir le meilleur niveau de sécurité, les
supports des clés privées sont les cartes à puce.
Les cartes peuvent être personnalisées par
l’entreprise utilisatrice : il est alors nécessaire
de se doter des matériels adéquats (imprimante
spécialisée, station de personnalisation…). Il est
aussi possible de faire personnaliser les cartes
par un acteur externe, spécialiste du domaine.
Les solutions dans ce domaine sont proposées
notamment par :
! ActivCard,
! Gemplus,
Le marché principal des vendeurs de certificats
est le commerce électronique. Par exemple, une
société désirant réaliser du commerce en ligne
va acheter un certificat pour son serveur, afin
que l’ensemble des internautes l’authentifie de
manière sûre, et pour servir de base à
l’établissement de sessions SSL chiffrées.
Citons les offres :
! Certinomis - Societis et Mercatis,
! Certplus - Certificats Serveur,
! GlobalSign - PersonalSign, ServerSign et
HyperSign,
! Thawte racheté par Verisign - Server
Certificates et 128-bit SuperCerts,

! Oberthur, ! Verisign - OnSite for Server IDs (représenté

par Certplus en France).
! Sagem,
! Schlumberger,
PROMOTEURS DE STANDARDS
! Utimaco.
Le groupe de travail PKIX (Public-Key
Infrastructure X.509), a été fondé durant
OPERATEURS DE CERTIFICATION l’automne 1995 au sein de l’IETF (www.ietf.org)
pour développer les standards nécessaires pour
Les opérateurs de certification proposent une supporter une PKI basée sur les certificats
gestion globale de la mise en place et de X.509. De nombreux RFC ont été publiés
l’exploitation des PKI. Le socle de spécifiant notamment le protocole OCSP, le
l’Infrastructure de Confiance de l’entreprise est stockage des CRL…
donc dans ce cas hébergé chez un tiers, et ce (cf. www.ietf.org/html.charters/pkix-
de manière souvent irrévocable. Les offres charter.html)
disponibles en France sont :
! Certplus (affilié au réseau Verisign, filiale de Le PKI Forum (www.pkiforum.org et
Gemplus, Verisign, France Telecom, EADS www.pkiforum.com), une alliance internationale
et CIBP), à but non lucratif entre fournisseurs de PKI, a
été créé en décembre 1999 pour accélérer
! Cashware (spin-off du groupe Thales), l’adoption des PKI et des services associés. Les
! Certinomis (filiale de Sagem et La Poste), membres fondateurs sont Baltimore
Technologies, Entrust Technologies, IBM,
! MediaCert (ATOS et Baltimore). Microsoft et RSA Security. La grande majorité
des acteurs du marché y sont présents (Cisco,
Ces sociétés proposent classiquement Hewlett-Packard, Oracle…).
l’hébergement des fonctions de CA, RA… Elles
étendent progressivement leurs offres, et La société RSA Security
travaillent actuellement notamment pour (www.rsasecurity.com) publie depuis 1990
développer la validation « en ligne » via OCSP, des spécifications destinées à promouvoir
ou encore la fourniture de services
la cryptographie asymétrique, les
d’horodatage, voire de notarisation.
standards PKCS (Public Key Cryptography
Standards). Ainsi la proposition PKCS#6 a
VENDEURS DE CERTIFICATS été retenue pour constituer la troisième
version de la norme X.509. La proposition
Les vendeurs de certificats proposent PKCS#10 est désormais la syntaxe
directement des certificats. Ces certificats standard pour une demande de
s’inscrivent dans l’architecture de confiance du certification.
vendeur de certificats et sont donc
« reconnus » par l’ensemble des utilisateurs Entrent également dans cette catégorie les
reconnaissant la validité de sa CA racine. sociétés SETCo et Identrus chargées de la
promotion des standards SET et Identrus, ou
encore l’organisme GTA, dont nous avons parlé
plus haut.

Page 41 LES PKI - LIVRE BLANC


7.3. MATURITE ET EVOLUTION
DES OFFRES
Lorsque nous analysons les offres du marché,
nous pouvons faire les constats suivants :
! Les composants logiciels « classiques » de
la PKI (CA, RA, Annuaire) sont relativement
bien maîtrisés. Il manque souvent à ces
produits les fonctions d’administration
permettant la gestion de grands volumes.
Leur diffusion encore limitée implique
souvent des problèmes techniques à chaque
mise à disposition de nouvelles versions.
! Les composants logiciels « nouveaux » de la
PKI (OCSP Responder…) sont eux très peu
diffusés. Les éditeurs de ces solutions sont
par ailleurs peu présents en France.
! Les produits (lecteurs, cartes à puce,
token…) et les services (personnalisation,
distribution…) dans le domaine des cartes à
puce pour PKI sont prêts, mais pas encore
utilisés à grande échelle.
! Les offres d’outsourcing et d’hébergement
sont récentes et peu éprouvées. La qualité
de service et la rigueur des procédures ne
pas toujours au rendez vous, ce qui est
pourtant crucial pour le positionnement
« sécuritaire » de ces offres.
! Il est peu évident, lorsque l’on intègre tous
les postes de coût d’une infrastructure,
d’avoir une bonne prévision des coûts à
moyen terme. Vu le peu de recul sur ce
marché, il n’est pas non plus évident de
valider l’intérêt économique d’une approche
externalisation, même si cette approche
peut être intéressante pour d’autres raisons
(cf. chapitre 7.4).
De l’observation des acteurs et des offres de
PKI se dégagent trois grandes tendances :
! une volonté de la part des acteurs d’élargir
leur offre pour offrir des solutions
complètes,
! l’émergence de nouveaux types d’offres de
service pour répondre à la demande,
! un attrait croissant des acteurs
« classiques » (IBM, Computer Associates,
Microsoft, iPlanet …).
GLOBALISATION DES ACTEURS DU MARCHE
Les principaux acteurs du marché de la PKI
cherchent à élargir le panel de fonctions qu’ils
adressent en étoffant leur offre.
Page 42
Cet élargissement est réalisé via le rachat de
sociétés ou par l’établissement de partenariats
forts. Ainsi, Entrust propose dans son catalogue
le serveur d’autorisation GetAccess développé
par Encommerce. IPlanet fait de même avec
Siteminder de Netegrity.
Ces rachats ou partenariats ont aussi pour
objectif pour certains éditeurs de trouver des
sources de revenus complémentaires et une
surface financière plus large en attendant un
développement plus important du marché de la
PKI : c’est le cas par exemple du rachat
« raté » de Content Technology par Baltimore.
Les éditeurs de logiciels cherchent par ailleurs à
pénétrer le marché de la fourniture de service,
comme le prouve le rachat de GTE CyberTrust,
vendeur de certificats, par Baltimore, ou la
création de l’offre Entrust@YourService par
Entrust.
Enfin, la mise en place de PKI nécessitant une
forte expertise, les fournisseurs proposent
également des services de conseil et
d’intégration de leurs produits.
EMERGENCE NOUVELLES OFFRES DE SERVICE
Un problème récurrent dans la mise en place de
solutions PKI est le manque d’infrastructures et
de compétences au sein des entreprises pour
l’installation puis l’exploitation de la PKI.
Pour répondre à ce problème, certains éditeurs
de logiciels se positionnent désormais
également sur le marché du service en
proposant des solutions d’hébergement. La
société cliente achète donc de la même façon
les logiciels, mais elle délègue entièrement ou
en partie la gestion de l’Infrastructure de
Confiance. Celle-ci est exploitée par les équipes
spécialisées et dans les locaux mutualisés du
fournisseur. Pour proposer ce type d’offre en
France, les éditeurs américains s’allient à des
sociétés de services françaises (exemple de
l’accord ATOS Origin / Baltimore).
PRESENCE CROISSANTE DES ACTEURS
« CLASSIQUES »
Les perspectives de croissance du marché de la
PKI ne laissent pas indifférents les acteurs
habituels du logiciel, de l’informatique et des
réseaux d’entreprise.
Ainsi Sagem, iPlanet (alliance Sun-Netscape)
Microsoft sont présents sur le marché de la PKI,
par la commercialisation de leurs logiciels
respectifs PKI Confidence, iPlanet Certificate
Management System et Windows 2000 PKI.
LES PKI - LIVRE BLANC
Les opérateurs de télécommunications ont
également fait leur apparition dans le domaine
des PKI, par l’acquisition de SmartTrust (ex
ID2) par Sonera (opérateur historique
finlandais). En France, le groupe France
Télécom dispose d’une part du capital de
Certplus.
Même si elles sont plus en retrait, des sociétés
comme Cisco, Hewlett-Packard et Oracle
prouvent néanmoins leur intérêt pour les
solutions PKI par leur présence dans le
PKIForum.
Enfin des acteurs tels que La Poste (à travers sa
filiale Certinomis, et les autres services qu’elle
prévoit de commercialiser pour sécuriser les
échanges électroniques) ou la Caisse des
Dépôts et Consignations (à travers CDC Zantas
qui commercialisera des services dans le
domaine de l’archivage) s’intéressent de très
près à ce marché.
7.4. INSOURCING OU
OUTSOURCING ?
Pour une entreprise souhaitant mettre en place
une PKI à usage interne ou externe, plusieurs
solutions alternatives se présentent :
! L’insourcing ou développement en interne
L’entreprise utilisatrice est seule
responsable de l’exploitation des
composantes de la PKI (logiciels, matériels,
ressources humaines et financières).
! L’outsourcing ou externalisation
L’entreprise utilisatrice délègue à une tierce
partie externe la mise en place et
l’exploitation des briques techniques et des
processus de la PKI. Ces briques sont dans
ce cas souvent partiellement mutualisées
avec d’autres clients.
! Solution d’hébergement, dite hybride
L’entreprise utilisatrice, propriétaire de tout
ou partie des logiciels et matériels PKI,
décide de les faire héberger par une société
tierce, sur une infrastructure qui lui est
dédiée.
Page 43
Plusieurs éléments doivent être pris en
considération pour le choix de l’une ou l’autre
de ces solutions :
! la délégation de la confiance à un tiers,
! le niveau de sécurisation,
! les investissements initiaux,
! les ressources humaines et les coûts
d’exploitation,
! les délais de mise en œuvre,
! la flexibilité de l’architecture.
Ces éléments doivent être parties prenantes
dans la réflexion, mais leur impact varie
énormément suivant les entreprises et leurs
objectifs.
LA DELEGATION DE LA CONFIANCE A UN TIERS
L’aspect principal à considérer en terme de
confiance est la vision que la société veut
donner de ses services à ses utilisateurs
internes et/ou à ses clients.
Une solution d’internalisation démontre une
volonté de maîtrise complète du risque par
l’entreprise. La sécurité est, à part entière, un
des services rendus par l’entreprise à ses
clients. Une telle volonté politique se fait
généralement au détriment des coûts
d’investissement initiaux même si sur le moyen
terme, la solution interne est souvent moins
onéreuse à exploiter.
Au contraire, dans une solution hybride ou une
solution d’externalisation, le certificat est
considéré simplement comme un moyen
d’accès à des services à valeur ajoutée.
L’hébergement du socle de l’Infrastructure de
Confiance (et notamment de la clé privée de la
CA) chez un tiers permet à l’entreprise de se
décharger d’une partie des processus de
gestion de la PKI et donc de se concentrer
davantage sur son cœur de métier.
LE NIVEAU DE SECURISATION
Du point de vue du niveau de sécurisation, une
externalisation ou une solution hybride peuvent
paraître préférables, car plus sûres. En effet,
des sociétés spécialisées offriront souvent une
meilleure protection des secrets par des
procédures d’une qualité supérieure à celles qui
peuvent être mises en place dans une
entreprise.
LES PKI - LIVRE BLANC
De même, il est plus aisé, par l’intermédiaire de
ces types de solutions, de mettre en place une
PKI conforme aux référentiels de sécurité
spécialisés. Encore faut-il que le prestataire
retenu applique effectivement une politique
sécurité très stricte et très bien formalisée.
LES INVESTISSEMENTS INITIAUX
Au niveau des coûts initiaux, l’internalisation et
l’hébergement sont plus onéreux que
l’externalisation. En effet, l’ensemble des coûts
matériels, logiciels et d’intégration sont alors à
la charge de la société. De plus, dans le cas de
l’internalisation, il faut encore ajouter les coûts
de construction du centre d’exploitation qui doit
être hautement sécurisé si l’entreprise n’en
dispose pas.
LES RESSOURCES HUMAINES ET LES COUTS
D’EXPLOITATION
En ce qui concerne les coûts d’exploitation, la
charge liée au personnel est élevée en raison
des exigences de séparation des responsabilités
et de la nécessité de l’assurance d’une haute
qualité de service, 24h/24 et 7j/7 pour les
applications à périmètre international. Les
solutions d’hébergement et d’externalisation
permettent a priori, par une mutualisation des
ressources, de réduire les coûts d’exploitation.
Mais il faut aussi considérer la manière dont les
coûts d’exploitation vont évoluer en fonction
des volumes de certificats gérés, et des
nouvelles fonctionnalités à intégrer. Sur le long
terme, les coûts d’exploitation de solution
externalisée et/ou hébergées s’avèrent souvent
plus élevés que les coûts d’exploitation
internes.
Sur ce point, il faut aussi considérer la
disponibilité de ressources compétentes en
interne pour le déploiement et la gestion de la
PKI (cf. chapitre 8.2).
LES DELAIS DE MISE EN ŒUVRE
Les solutions d’externalisation et
d’hébergement permettent généralement de
raccourcir les délais de mise en œuvre et de
déploiement. Néanmoins, quel que soit le type
de solution mis en place, les phases de
conception de l’architecture et d’élaboration des
processus organisationnels sont
incompressibles.
Page 44
LA FLEXIBILITE DE L’ARCHITECTURE
Du point de vue de la flexibilité de l’architecture
et de l’intégration de la PKI au Système
d’Information existant, la solution
d’internalisation est clairement à privilégier. En
effet, dès que l’entreprise demande une
modification sur un composant géré par un
tiers, il peut y avoir des impacts contractuels,
avec les lourdeurs que cela implique, ainsi que
les incertitudes sur les coûts d’évolution.
SYNTHESE DE L’ARGUMENTATION
L’ensemble des avantages et inconvénients de
chacun des types d’implémentation sont
récapitulés dans le tableau suivant.
Type de Avantages Inconvénients
solution
• Image de marque • Très importants investissements
initiaux
Internalisation • Pas de délégation de la confiance
à un tiers • Difficultés de posséder les
• Flexibilité de l'architecture
ressources humaines nécessaires
• Possibilité d'internaliser la PKI à • Image de marque
terme (développement parallèle
• Délégation de la confiance à un
des compétences)
tiers
Hébergement
• Plus d'aisance pour l'évaluation
par rapport aux référentiels de
• Moins de flexibilité de
l'architecture
sécurité
• Moins de mobilisation de
ressources humaines
• Réduction des délais de mise en
œuvre
• Retour d'expérience du tiers de
confiance dont c'est le métier
• Possibilité pour l'entreprise de se
concentrer sur son cœur de
métier
• Possibilité d'internaliser la PKI à • Image de marque
terme (développement parallèle
• Délégation de la confiance à un
des compétences)
tiers
Externalisation
• Plus d'aisance pour l'évaluation
par rapport aux référentiels de
• Architecture peu flexible
sécurité
• Pas de mobilisation de ressources
humaines
• Réduction des délais de mise en
œuvre
• Retour d'expérience du tiers de
confiance dont c'est le métier
• Possibilité pour l'entreprise de se
concentrer sur son cœur de
métier
C’est en considérant l’ensemble des arguments
évoqués ci-dessus que l’on pourra décider entre
les différentes stratégies possibles.
Sur le plan des coûts, nous constatons en règle
générale que les solutions externes et/ou
hébergées permettent de réduire les coûts
d’investissement initiaux, mais ne permettent
pas une bonne prévision des coûts
d’exploitation et d’évolution. Sur le moyen
terme, ces solutions s’avèrent souvent plus
onéreuses que des solutions construites en
interne.
LES PKI - LIVRE BLANC
8. STRATEGIE DE
En effet, dans ces contextes, la part
communication et marketing, la part juridique
et les travaux liés au déploiement dans
MISE EN ŒUVRE l’organisation « commerciale » de l’entreprise
sont plus lourds. De même, la construction
d’une structure back-office (hot-line, support,
gestion des dossiers d’enregistrement, gestion
des révocations…) augmente les coûts du
projet.
8.1. POURQUOI ET A QUEL
COUT ? POSTES DE COUTS

Le tableau ci-dessous donne une liste des

Plusieurs critères plaident en faveur de la mise
en place d’une infrastructure de confiance PKI :
! Elle permet de disposer d’un cadre de
standardisation pour les principaux services
de sécurité, assurant l’interopérabilité.
! Elle fournit le moyen de "fédérer" des
services de sécurité, et d’en simplifier
l’exploitation.
! Elle constitue une solution aux problèmes
d'enregistrement et de gestion des "objets"
de sécurité.
! Elle va véritablement permettre de
développer la dématérialisation des
échanges sur la base d’une solution
reconnue sur le plan légal.
De plus les PKI sont considérées comme une
solution d’avenir par de multiples organismes et
communautés d'intérêt :
! Loi sur la signature numérique,
! Relation entreprises / administration et
particuliers /administration
(Téléprocédures),
! Professionnels de santé / Experts
comptables (CPS, Sésame Vitale…),
! Initiatives Identrus, GTA…
Toutefois le coût de mise en œuvre (interne ou
externe) d’une telle infrastructure est
important.
Pour un projet interne « ciblé » dans une
grande entreprise (plusieurs milliers
d’utilisateurs), l’investissement nécessaire peut
varier entre 500 K€ à 1 800 K€ suivants les
services mis en place.
Pour un projet de type « e-Business » de
construction d’une infrastructure « complète »
(plusieurs dizaines de milliers d’utilisateurs,
services étendus, haute-disponibilité, vente des
certificats à des clients et partenaires
externes), l’enveloppe à considérer se situe
plutôt entre 2 500 K€ et 8 000 K€.
postes de coûts à prendre en compte :
Coûts de • Matériels (serveurs, HSM, cartes à
puces et/ou token)
construction
• Logiciels (pour les fonctions AC,
AE, Annuaire, OCSP, horodatage,
archivage…)
- de 40 K€ à 120 K€ pour les
briques principales (AC, AE,
annuaire) et pour 1000 certificats
environ.
• Sécurité physique (sécurisation
des locaux si nécessaire)
• Etudes amonts (lancement, études
préalable)
• Intégration de l’infrastructure
• Mise en place du back-office et des
procédures organisationnelles
• Mise en place des outils de
développements et d’intégration
des applications
• Audit de sécurité et certification
• Test en pilote et mise en
production
Coûts de • Maintenance matérielle et
fonctionnement fixes logicielle
• Exploitation de l’infrastructure
(supervision, sauvegardes, mises
à jour…)
• Gestion des relations avec les
principaux fournisseurs
Coûts de • Usage des logiciels (fonction du
fonctionnement nombre d’utilisateurs et/ou de du
variables nombre de transactions).
• Achat, personnalisation et
(fonction du nombre renouvellement des cartes à puce
de certificats gérés) et/ou token
- Carte : 9 à 18 € par carte,
- Lecteur et logiciel : 25 à 50 €
- Personnalisation carte : 10 €.
• Fonctionnement des processus
(enregistrement, révocations,
renouvellement…).
• Support aux utilisateurs et aux
développeurs.
• Intégration des applications.
Figure 30 : Postes de coût d’un projet PKI

Page 45 LES PKI - LIVRE BLANC

La ventilation des coûts de construction peut se ! Processus d’enregistrement et de remise
décomposer comme représenté sur le schéma des certificats :
suivant, dans le cas d’un projet pour lequel la
carte à puce est utilisé (dans le cas contraire, la • Si les processus impliquent une saisie
part matériels et logiciels est plus réduite) : centralisée des demandes
d’enregistrement à partir de « dossiers
papiers », la structure back-office va
être considérablement alourdie.
40 %
Pilotage et insertion
40 % • Si les processus sont fortement
Matériels et Logiciels PKI
dans l'organisation automatisés, avec une saisie
20 % décentralisée des demandes, les coûts
Ingénierie
sont mieux répartis. La structure projet
ne supporte pas les coûts
d’enregistrement.

Figure 31 : Ventilation du budget OPTIMISER LES COUTS DE CONSTRUCTION

d’investissement d’un projet PKI
Il est possible d’agir sur plusieurs axes pour
maîtriser et rationaliser les coûts de
Les options les plus structurantes en terme de construction de l’infrastructure PKI :
coût vont porter sur les éléments suivants :
! Adopter une stratégie de mise en place
! Type de services offerts (mise en œuvre progressive des services : Dans une
des services avancés ou non). première phase, il est souvent pertinent de
! Niveau de qualité de service et de sécurité mettre en place les services de bases :
(haute-disponibilité, site de backup…). L’intégration des applications pourra ainsi
débuter, ainsi que la phase « d’éducation »
! Externalisation ou hébergement en interne : des développeurs et des utilisateurs.
• L’externalisation offre en théorie les Viendront ensuite les besoins plus poussés,
avantages d’une construction plus impliquant l’ouverture des services plus
rapide et moins onéreuse. En pratique, complexes comme l’horodatage et
les offres d’hébergement sont encore l’archivage.
rares et peu éprouvées.
! Garantir la pérennité des
• L’hébergement en interne permet de investissements réalisés. Si les services
conserver la maîtrise de la Qualité de sont mis en œuvre progressivement, il est
Service et du niveau de Sécurité. Il nécessaire de pouvoir conserver les
permet aussi une meilleure maîtrise des premières briques mises en place pour les
plannings et des coûts d’évolutions pour étapes suivantes. Les travaux menés lors
la mise en place de nouveau services. de l’étude préalable sont cruciaux sur ce
point.
Quelle que soit l’option retenue, une partie
de l’infrastructure, notamment les moyens ! Définir une stratégie fournisseur
techniques du back-office, est hébergée en adaptée. Le choix de la stratégie
interne. fournisseur (construction interne ou
hébergement externe, sélection des
! Tarification des logiciels : les logiciels de
produits pertinents…) est crucial pour
type PKI présentent encore des coûts
assurer la maîtrise des coûts de
élevés, avec une répartition variable entre
construction initiaux puis du coût des
le coût de licence initial, et le coût de
évolutions. Le mode de tarification et les
licence complémentaire par utilisateur.
engagements des fournisseurs sur des tarifs
! Support des certificats et des clés (logiciel stables sont très importants. Les coûts des
ou cartes à puces…) : le coût de logiciels ont globalement tendance à baisser
déploiement est augmenté de manière actuellement, et il convient de réaliser une
significative si les certificats et les clés sont véritable mise en concurrence sur ce
stockés sur des cartes à puces. thème.

Page 46 LES PKI - LIVRE BLANC

OPTIMISER LES COUTS DE FONCTIONNEMENT 8.2. COMPOSANTES D’UN PROJET
L’examen des coûts de fonctionnement montre PKI
que le fonctionnement du back-office
représente de loin la charge la plus importante.
Le back-office réalise la saisie des demandes Comme nous l’avons souligné dans les chapitres
d’enregistrement (dans le cas de processus précédents, un projet PKI ne se limite pas au
prévoyant une saisie centralisée), la prise en déploiement de composants techniques, mais
compte des renouvellements et des adresse de nombreux domaines.
révocations, la facturation des services, le
reporting… Le schéma ci-dessous représente de manière
synthétique les différentes fonctions techniques
Pour maîtriser ces coûts, les processus de et organisationnelles qu’il faut mettre en place
gestion du cycle de vie des certificats doivent pour assurer le fonctionnement de
être étudiés avec soin, afin de trouver le bon l’infrastructure PKI.
compromis entre le niveau de sécurité et de
garantie souhaité pour chaque gamme de Archivage de clés
certificat, et le coût de fonctionnement des
Horodatage
Recouvrement de clés

processus. Personnalisation
des cartes
Autorité
de
Autorité de
Notariat
Annuaire Validation
à puce Certification

Centre de
Centre de
STRATEGIE DE MISE EN PLACE
production
production
AE de backup
nominal Autorité
AE
Back-Office Exploitation
d’Enregistrement technique

Ces coûts élevés freinent aujourd’hui le Support

déploiement des PKI au sein des entreprises. Marketing et Juridique

communication

Ces déploiements sont envisagés le plus Infrastructure

Support aux
utilisateurs
Support aux
développeurs
souvent dans les cas suivants : PKI

Utilisateurs
Clients
! Le niveau de sécurité souhaité est élevé, Kit Kit
Serveur
voire très élevé.
poste de
travail applicatif

! Le périmètre de déploiement est significatif,

et permet d’amortir l’investissement initial Figure 32 : Composantes de l’infrastructure PKI
sur un nombre important d’utilisateurs.

! Il s’agit d’une initiative stratégique liée au

métier de l’entreprise.
Il montre bien que la mise en œuvre d’une PKI
recouvre de multiples aspects, qui sont
Pour assurer son succès, le déploiement de la
présentés ci-dessous :
PKI doit de préférence être associé au
déploiement d’une application phare ou d’une
nouvelle architecture technique au niveau des
postes de travail de l’entreprise. Juridique

Par ailleurs, même si le premier déploiement Marketing et communication

est ciblé sur un périmètre limité, il est crucial Direction
de mener des études préalables assez de projet
Exploitation et support
approfondies pour garantir la capacité de
l’infrastructure mise en place à évoluer sans Planification Organisation et processus
remise en cause des investissements déjà Sécurité
consentis. Qualité...
Intégration des applications

Dans le cas contraire, on peut s’attendre au Infrastructure technique

déploiement de multiples « petites PKI » au
sein de l’entreprise, alors qu’il y a bien
possibilité d’optimiser largement les coûts en Figure 33 : Composantes d’un projet PKI
gérant le projet de manière globale, pour
mettre en place une infrastructure d’entreprise.

Page 47 LES PKI - LIVRE BLANC

INFRASTRUCTURE TECHNIQUE
L’un des éléments clés d’un projet PKI est bien
entendu la conception de l’architecture
technique, qui doit tenir compte des contraintes
fortes d’interopérabilité, d’insertion dans
l’existant et de sécurité (notamment les
contraintes de sécurité physique et de haute
disponibilité).
Des solutions techniques pertinentes et
pérennes doivent être choisies dans un domaine
qui est encore peu stabilisé et où les retours
d’expériences sont rares. La compétence
d’architecte se révèle cruciale puisque ce type
de projet fait intervenir nécessairement de
multiples briques matérielles et logicielles
d’origines diverses.
INTEGRATION DES APPLICATIONS
Le déploiement de l’Infrastructure de Confiance
s’accompagne d’une « PKIsation » des
applications à sécuriser, afin qu’elles puissent
être en mesure d’utiliser les certificats. Cette
intégration implique la mise à disposition
d’outils de développement, ainsi que des
actions de formation et de communication vis-
à-vis des équipes de développement. La mise
en place d’une plate-forme de test et
d’homologation des applications est souvent
préconisée, ainsi qu’une structure de support
aux développeurs.
ORGANISATION ET PROCESSUS
Le fonctionnement de la PKI est rendu possible
par l’application de processus organisationnels,
qui régissent la fabrication, la diffusion et
l’utilisation des certificats. Plus largement il faut
définir des processus pour décrire :
! la gestion du cycle de vie des certificats
(enregistrement, création, renouvellement,
révocation…),
! la gestion du cycle de vie des composants
de la PKI (création d’Autorité
d’Enregistrement, création d’opérateurs de
certification ou d’opérateurs
d’enregistrement, création d’Autorité de
Certification et Key Ceremony, révocation
de clé d’AC…),
! la gestion du cycle de vie des applications,
! les processus de support aux utilisateurs et
de gestion des incident,
! les processus d’évolution des politiques de
certifications,
! les processus de suivi de la QoS, processus
de facturation…
Page 48
Ces processus ne doivent pas seulement être
définis, décrits et documentés. Il faut aussi les
mettre en place concrètement au sein de
l’organisation de l’entreprise.
La réflexion sur les processus vient alimenter la
rédaction de la Politique de Certification et de la
Déclaration des Pratiques de Certification.
EXPLOITATION ET SUPPORT
Les composants techniques de la PKI doivent
être supervisés et exploités. Des services
techniques doivent être mis en place pour
assurer le suivi de la Qualité de Service, la
facturation, la gestion des évolutions
matérielles et logicielles…
Par ailleurs, le fonctionnement de la PKI
implique la création d’une structure de support
aux utilisateurs, qui assure le suivi des
incidents et qui est en mesure d’informer et
d’apporter de l’assistance aux utilisateurs des
certificats.
MARKETING ET COMMUNICATION
Les volets marketing et communication sont
extrêmement importants dans un projet PKI. La
communication tout d’abord est essentielle. Elle
a deux objectifs principaux :
! Un objectif d’explication. En effet, les
certificats sont manipulés par les
utilisateurs finaux : ils sont associés à des
concepts nouveaux qu’il est nécessaire
d’expliquer soigneusement. Le déploiement
des certificats s’appuie sur des processus
qu’il faut aussi expliquer.
! Un objectif de « vente ». La
communication est aussi un support
essentiel à la promotion des services de la
PKI. Cette communication est tournée vers
les « clients », c’est à dire les utilisateurs
finaux, mais aussi vers les directions
métiers et les équipes de développement à
l’intérieur de l’entreprise.
Le volet marketing est lui aussi très structurant.
Il a pour but de définir un « packaging » clair
de l’offre de service proposée par la PKI, et la
tarification associée. Là encore le lien avec les
directions métiers, qui vont « intégrer » les
services de sécurité de la PKI dans des services
applicatifs plus globaux, est essentiel.
LES PKI - LIVRE BLANC
JURIDIQUE ET LEGAL Lancement
Cadrage
Étude préalable
Avant-projet / Conception générale
Réalisation

Politique de
Les aspects légaux ont eux aussi une grande Périmètre
du projet
Définition des services
offerts par la PKI
certification

importance, en particulier pour les projets Cadre juridique

tournés vers la fourniture de certificats à des Contraintes

Processus
organisationnels
Architecture Choix des
Intégration
clients ou à des partenaires externes à
Technique fournisseurs
de planning et orientations
Générale
d'organisation Plan Pilote
l’entreprise. Il faut tenir compte des contraintes projet
détaillé Mise en
Contraintes
juridiques pour un certain nombre de points : le
Plan d'action Spécifications
organisation Stratégie fournisseur marketing et production
détaillées
et budget communication
stockage de données nominatives, l’horodatage
et l’archivage nécessaires pour la non- Business Exigences spécifiques
Planification et
organisation
répudiation, la définition des contrats Plan général (Identrus, TéléTVA)
du projet

d’utilisation des certificats, la définition des

responsabilités des différentes parties… Ces
réflexions donnent lieu à la rédaction de
différents documents clés : Figure 34 : Démarche d’un projet PKI
! politique de certification,

! contrats d’utilisation des certificats, Le contenu de ces différentes phases est

présenté ci-dessous.
! contrats de service vis-à-vis des
applications,
PHASE DE LANCEMENT
! politique d’archivage…
Ses objectifs sont les suivants :
Elles sont plus complexes dans des contextes
de projets internationaux, pour lesquels il est ! identifier et formaliser le périmètre
nécessaire de tenir compte des législations des (utilisateurs et applications cibles), les
différents pays concernés. contraintes et les orientations structurantes
du projet,
! analyser les risques projet,

8.3. DEMARCHE DE MISE EN ! recenser les contraintes liées à l’existant :

architecture réseaux, politique de sécurité,
OEUVRE locaux d’exploitation potentiels, annuaires
existants,
! identifier les principales contraintes légales
Un projet PKI peut être découpé en trois phases
à prendre en compte,
principales :
! définir l’organisation dans laquelle s’inscrit
! Une phase de cadrage ou de lancement le projet et répartir les rôles entre les
dont l’objectif est de valider l’opportunité et différents contributeurs,
de définir les objectifs et le contexte de
déroulement du projet ! définir le cadre budgétaire et les moyens de
financement pour l’ensemble du projet,
! Une phase d’avant projet ou d’étude
! aboutir dans les meilleurs délais au plan de
préalable qui doit permettre de préciser
travail pour l’étude préalable (travaux,
les contours techniques et organisationnels
moyens, budget et planning prévisionnels).
de la solution à mettre en place
(architecture technique, processus
organisationnels, services offerts…).

! Une phase de réalisation qui va permettre

le déploiement de la solution, déploiement
qui peut être réalisé à travers plusieurs
paliers fonctionnels et techniques si
nécessaire.

CADRAGE PREALABLE REALISATION

Page 49 LES PKI - LIVRE BLANC


PHASE D’ETUDE PREALABLE
Nous décrivons ci-dessous quelques uns des
points étudiés lors de la phase d’étude
préalable.
Définition des services offerts
Cette définition des services devra permettre :
! De synthétiser et valider les besoins de
façon à définir une solution homogène et
cohérente.
! De préciser les contours fonctionnels et
techniques de la future infrastructure de
confiance :
• types de certificats gérés (gamme de
certificats, supports utilisés),
• types de procédures d’enregistrement
et de diffusion des certificats,
• services avancés proposés
(recouvrement, horodatage /
archivage…),
• niveau de qualité de service à fournir…
! De déterminer le plan de mise en place des
différents services : plusieurs paliers
fonctionnels avec des échéances différentes
pourront être définis.
Définition des processus organisationnels
Les processus peuvent être classés par grands
types, les principaux étant les suivants :
! gestion du cycle de vie des certificats,
! gestion des composants de la PKI,
! administration des services et suivi de la
qualité de service,
! intégration des applications dans la PKI,
! gestion des changements (technique,
politiques ou organisationnels).
Stratégie de consultation et
fournisseur
Cette étape a pour objectif de définir la
stratégie de consultation en cohérence avec la
stratégie de mise en œuvre.
Plusieurs approches sont envisageables :
! Pour un projet réalisée « en interne » :
• consultations orientées produits : dans
ce cas, plusieurs éditeurs et
constructeurs devront être consultés
(logiciels PKI de base, Autorité de
validation, annuaires, cartes à puce,
HSM…). Cette approche permet de
garantir un choix de produit optimal par
rapport aux besoins, mais les risques
liés à l’intégration des différentes
briques sont à la charge de l’entreprise.
• consultation orientée intégrateur :
L’intégrateur propose une solution
complète sur la base des produits qu’il
maîtrise.
Une solution mixte peut également être
envisagée.
! Pour un projet outsourcing la consultation
sera orientée vers la fourniture de services
de construction et d’exploitation.
Dans tous les cas, il convient d’être très attentif
à la pérennité et la « solidité » des fournisseurs
des produits et services retenus, et à la
disponibilité de compétences techniques les
maîtrisant.
Exigences spécifiques
Cette étape a pour but, en fonction du contexte
du projet, d’étudier les exigences spécifiques à
ce contexte. Par exemple dans le cas d’un
projet bancaire Identrus, il est nécessaire
d’analyser l’ensemble des spécifications
Identrus.
Cette étape a aussi pour but de recenser les
exigences telles que les règles établies en
terme de politique et d’organisation de la
sécurité au sein de l’entreprise.
Politique de Certification / Cadre juridique
choix
La rédaction de la ou des Politiques de
Certification est à réaliser lors de l’étude
préalable. Les PC sont des éléments de
référence pour la phase de réalisation. La
rédaction des PC est menée avec la
collaboration de juristes afin de valider les
engagements de responsabilité de chaque
acteur, et la conformité avec la législation.
Page 50 LES PKI - LIVRE BLANC
Architecture technique générale
L’objectif de cette étape est d’établir les
spécifications générales de la solution en
termes :
! d’architecture logique de certification
(nombre d’AC, hiérarchie des AC...),
! le cas échéant, d’infrastructure technique :
• architecture matérielle et logicielle
• dimensionnement
• ressources réseaux nécessaires
• sécurisation de l’architecture
• mécanismes de haute disponibilité et de
montée en charge
! d’outils d'administration,
! de packaging des kits clients,
! d’interfaces à mettre en œuvre (vis-à-vis
des applications et entre les briques).
Plan d’action marketing et communication
L’objet de cette étape est :
! d’identifier les différentes cibles en terme
de communication (clients, utilisateurs
internes, équipes de développement, réseau
de commercialisation, DRH...),
! de définir pour chaque cible les outils de
communication qui seront utilisés
(plaquettes, messages d’information, site
Web…)
! de définir les étapes du projet pendant
lesquelles la communication sera réalisée.
Planification et organisation de la phase
réalisation
Cette étape a pour objectif de structurer la
démarche pour la phase de réalisation. Un
planning détaillé est élaboré et les structures de
conduite du projet de réalisation sont mises en
place.
Elle doit aboutir à la formalisation du plan
projet.
Page 51
PHASE DE REALISATION
Le déroulement de la phase de réalisation d’un
projet PKI est assez proche d’un projet
d’intégration « classique ». Les spécificités
portent essentiellement sur les points suivants :
! L’intégration reste délicate, du fait de
l’instabilité et des difficultés
d’interopérabilité entre les produits. Elle fait
intervenir de multiples produits provenant
généralement de sources différentes. Le
prototypage est à conseiller pour garantir le
bon fonctionnement final.
! La sécurité doit être une préoccupation
permanente et majeure du projet. Il est en
particulier recommandé de programmer des
audits lors de certaines phases clés.
! Le volet organisationnel et communication
revêt une importance particulière, puisque
l’utilisateur final, les développeurs, ainsi
que tous les acteurs qui seront chargés de
l’enregistrement des utilisateurs et du
support, seront touchés.
! Même s’il s’agit d’un projet d’infrastructure,
il comporte un volet important lié à
l’intégration des applications : en dehors
des composants de l’infrastructure PKI elle-
même, il faut prévoir l’intégration de « kits
clients » sur les postes de travail (lecteur
de carte à puce et logiciel associé, plug-in
pour la sécurisation de la messagerie…), et
de « kits serveurs » pour gérer la validation
des certificats au niveau de chaque
application.
PLANNING DU PROJET
Le délai moyen de mise en place d’une PKI
varie de 8 à 24 mois, en fonction de l’ampleur
du périmètre concerné et des services mis en
œuvre.
LES PKI - LIVRE BLANC
9. CONCLUSION
La technologie des PKI est une innovation
capitale pour gérer la sécurité dans les grands
réseaux Intranet et surtout pour permettre le
développement des échanges électroniques sur
Internet :
! Elle permet à un utilisateur, grâce à son
architecture originale, de réaliser des
échanges sécurisés avec un grand
nombre de serveurs sans que ceux-ci
aient besoin de connaître l’utilisateur au
préalable. Seule l’Autorité d’Enregistrement
aura vérifié une fois pour toute l’identité de
l’utilisateur pour le compte de toute la
communauté.
! Elle offre, sous la forme d’une solution
de sécurité unique, une panoplie de
fonctions répondant à tous les besoins de
sécurité des échanges électroniques
(authentification, confidentialité, intégrité,
non-répudiation).
! Grâce à l’utilisation de standards et aux
mécanismes de certification croisée ou
hiérarchiques, il est possible de créer des
domaines de sécurité de très grande
taille sur Internet, domaines de sécurité
ingérables en pratique avec des solutions
traditionnelles.
! Elle permet d’envisager la
dématérialisation des échanges et des
processus de l’entreprise dans un contexte
légal approprié.
Une large utilisation des PKI paraît maintenant
inéluctable. La principale question qui reste
posée est le planning dans lequel cette
généralisation aura lieu.
La technologie des PKI est toutefois déjà
disponible et opérationnelle : il est donc
possible dès maintenant de déclencher le
déploiement de ces solutions.
Pour leurs besoins internes, les entreprises
sont dès aujourd’hui en train de mettre en
œuvre une infrastructure PKI destinée à couvrir
un besoin de sécurité ciblé sur une population
particulière ou sur un besoin applicatif précis
(par exemple authentification et confidentialité
des flux pour une population d’utilisateurs
nomades, ou confidentialité de la messagerie
interne).
Page 52
Elles envisagent d’étendre progressivement la
solution ainsi construite pour prendre en
compte des besoins plus larges, et aboutir par
exemple à une solution de d’authentification
unique pour l’ensemble des applications. Elles
seront dans certains cas amenées à mettre en
place plusieurs PKI, qui devront ensuite être
interconnectées via la certification croisée ou la
certification hiérarchique.
Les enjeux liés à la mise en place de ces PKI
sont multiples :
! Capacité à engager une démarche de
dématérialisation progressive d’un grand
nombre de processus, qui va
immédiatement apporter des gains de
productivité.
! Possibilité de simplifier une partie
significative de la gestion de la sécurité
réalisée aujourd’hui au niveau de chaque
application, tout en augmentant le niveau
de sécurité pour l’authentification et la
confidentialité.
! Possibilité de mieux formaliser,
d’homogénéiser et de rationaliser tous les
processus d’enregistrement des utilisateurs
du système d’information.
Pour leurs besoins e-Business, certaines
entreprises ou communautés d’intérêt ont par
ailleurs entamé la mise en œuvre
d’infrastructures complètes, intégrant tous les
services d’une PKI, et qui seront en mesure de
gérer plusieurs dizaines ou plusieurs centaines
de milliers de certificats. Ces projets font
généralement suite à une initiative stratégique
de la Direction Générale.
Les banques et de manière plus générale les
institutions financières sont appelées à figurer
parmi les premières à prendre ce type
d’initiative. En effet, il est crucial pour elles
d’occuper une position incontournable dans la
gestion des échanges commerciaux sur
Internet. Elles disposent pour cela d’atouts
importants, du fait de leur expérience dans le
domaine de la gestion des cartes bancaires, et
de leurs réseaux d’agences qui permettront de
faciliter l’enregistrement des demandes et la
distribution des certificats.
Les premiers investissements PKI sont en
priorité consacrés aux applications B-to-B, et
aux applications internes de l’entreprise.
Viendront ensuite les applications B-to-C, en
débutant par les échanges avec les clients
« connus » (par exemple échange entre une
banque et ses clients) puis en généralisant
progressivement la PKI.
LES PKI - LIVRE BLANC
10.INDEX
A
algorithmes........................................ 9
annuaire positif..................................17
API ..................................................32
arrêté..................................... 9, 28, 38
authentification .................................. 8
autorité de certification .......................10
autorité de validation..........................19
autorité racine ...................................23
B
bi-clés ........... 8, 9, 12, 13, 15, 16, 18, 21
B-to-B ..............................................36
B-to-C ..............................................36
C
CA10, 11, 12, 14, 15, 16, 17, 18, 19, 20,
21, 23, 24, 25, 27, 38, 40, 41, 42, 43
CA racine...............................18, 23, 41
carte à puce .......8, 14, 17, 37, 40, 41, 46
CEP..................................................13
certificat ...........................................10
certification croisée .................23, 24, 27
certification hiérarchique ............... 23, 24
chaîne de confiance............................23
chiffrement ........................................ 7
clé privée8, 10, 12, 13, 16, 17, 18, 21,
38, 43
clé publique ....................................7, 8
clé secrète ......................................... 7
clé symétrique.................................... 7
confidentialité........................ 7, 8, 9, 29
CRL ...........11, 17, 18, 19, 20, 32, 34, 41
CRL Distribution Point.........................17
CRMF ...............................................13
cryptogramme.................................... 8
cryptographie ..................................... 7
D
décret .................................... 9, 28, 38
delta CRL...............................17, 18, 19
DES .................................................. 7
Directive Européenne .........................27
DPC .................................................27
E
EDI ..................................................31
éditeurs de logiciels............................40
externalisation...................................43
F
fournisseurs de services......................40
fournisseurs de support ......................40
Page 53
FTP ................................................. 30
G
GTA ................................................ 37
H
hachage ............................................ 8
hébergement.................................... 44
hiérarchie de certification ................... 23
horodatage ............. 8, 21, 22, 37, 41, 49
HSM........................................... 14, 40
HTTP ............................................... 30
HTTPS ............................................. 30
hybride............................................ 43
I
Identrus ................................36, 37, 41
IIOP ................................................ 30
insourcing ........................................ 43
intégration active ....................32, 33, 35
intégration passive ............................ 35
intégration passive ....................... 32, 34
intégrité......................... 8, 9, 10, 29, 30
IPSec .............................................. 30
K
KEYGEN tag ..................................... 13
L
LDAP .......................................... 15, 30
LDAPS ............................................. 30
législation ........................................ 28
M
modules cryptographiques.................. 40
N
NNTP............................................... 30
nommage d’entité ............................. 14
non-répudiation ....... 8, 10, 21, 22, 29, 49
notariat ........................................... 22
O
OCSP .........................20, 33, 34, 37, 41
OCSP Responder ............................... 20
outsourcing ...................................... 43
P
PC .................................. 26, 27, 38, 50
PCMCIA ........................................... 14
PKCS#10 ......................................... 13
PKCS#7........................................... 13
PKIForum......................................... 41
PKIX ............................................... 41
LES PKI – LIVRE BLANC
plug-in.................................. 34, 35, 51 T
Politique de certification .....26, 38, 48, 49
Telnet .............................................. 30
R TLS ................................................. 30
token ................................ 8, 14, 16, 40
RA............. 11, 12, 17, 25, 27, 40, 41, 42
RC4/5 ................................................7 U
recouvrement ..............................10, 21
USB................................................. 14
reverse proxy ................................... 32
révocation ............. 16, 17, 18, 19, 21, 27 V
root CA ............................................ 23
VA ........................................ 19, 20, 40
RSA.................................. 8, 13, 40, 41
VPN ................................................. 30
S
W
S/MIME.......................................31, 33
WAP ................................................ 31
SCVP ............................................... 20
Windows 2000 .................................. 40
SDK ................................................ 32
WTLS............................................... 31
SET ............................................36, 41
signature9, 10, 12, 13, 14, 15, 19, 21, X
23, 25, 27, 28, 29, 31, 33, 35, 37, 38,
X.500 .............................................. 14
45
X.509 .............................................. 15
SMTP ..........................................30, 33
X.509v3 ........................................... 10
socket.............................................. 30
XML ................................................. 31
SSL ............................................. 9, 30
XML-Dsig.......................................... 31
SSO ................................................ 35
suspension ............................ 16, 18, 19

Page 54 LES PKI - LIVRE BLANC

ANNEXE

Page 55 LES PKI - LIVRE BLANC

ANNEXE 1 : ACRONYMES

API Application Program Interface

CA Certificate Authority
CP Certificate Policy
CPS Certification Practice Statement
CRL Certificate Revocation List
HSM Hardware Security Module
EDI Echange de Données Informatisé
LDAP Lightweight Directory Access Protocol
LRA Local Registery Authority
OCSP On-line Certificate Status Protocol
OID Object Identifier
PC Politique de Certification
PKCS Public Key Cryptography Standard
PKI Public Key Infrastructure
RA Registery Authority
S/MIME Secure Multi-purpose Internet Mail Extension
SCVP Simple Certificat Validation Protocol
SDK Software Development Kit
SSL Secure Sockets Layer
SSO Single Sign On
TLS Transport Layer Security
VA Validation Authority
VPN Virtual Private Network
WAP Wireless Application Protocol
WTLS Wireless Transport Layer Security

Page 56 LES PKI - LIVRE BLANC

ANNEXE 2 : STRUCTURE D’UN CERTIFICAT X.509
Un certificat X509v3 contient les données suivantes :

Version du certificat
Numéro de série du certificat
Description de l'algorithme de signature de la CA
Nom de la CA qui a généré le certificat
Période de validité
Nom de l'utilisateur auquel appartient le certificat
Clé publique
Description de l'algorithme à utiliser avec la clé publique
Identification alternative de la CA (optionnel)
Identification alternative de l'utilisateur (optionnel)
Extensions (optionnel)
Signature de la CA

Les significations des champs « standards » des certificats X.509v3 sont les suivantes.

Intitulé des champs Usage

Certificate format version
Certificate serial number
Signature algorithm
identifier for CA
Issuer X.500 name
Validity period
Subject X.500 name
Subject public key
information
Issuer unique identifier
(Optionnel)
Subject unique identifier
(Optionnel)
Extensions (optionnel)
CA signature
Ce champ donne la version du format du certificat (version 1, 2 ou
3 pour l’instant).
Numéro de série unique du certificat dans le domaine de confiance
auquel il appartient. C'est ce numéro de série qui sera utilisé dans
les CRL en cas de révocation.
Désigne le procédé utilisé par la CA pour signer le certificat (norme
ISO). Il s'agit d'un algorithme asymétrique et d'une fonction de
hachage. (Exemple: RSA avec SHA-1.)
Spécifie le DN (Distinguished Name) dans la norme X.500 du CA qui
a généré le certificat.
Un exemple est: c=FR, o=SOLUCOM
Donne les dates de début et de fin de validité du certificat.
Un logiciel client utilisant les certificats doit impérativement vérifier
ces dates avant utilisation et rejeter le certificat s'il est expiré.
Spécifie le DN (norme X.500) du propriétaire du certificat.
Un exemple est: c=FR, o= SOLUCOM, cn=Jean Dupont
C'est le cœur du certificat. Ce champ contient la clé publique du
détenteur du certificat ainsi que les algorithmes avec lesquels elle
doit être utilisée. (Exemple : RSA et MD5.)
Ce champ optionnel permet de donner une seconde identification au
Issuer X.500 name (la CA) dans le cas où celui-ci à un DN commun
avec une autre CA.
Ce champ optionnel permet de donner une seconde identification au
Subject X.500 name (l'utilisateur) dans le cas où celui-ci à un DN en
commun avec un ou plusieurs autres utilisateurs.
Cf. description page suivante
C'est la signature de l'Autorité de Certification (CA). Cette signature
est effectuée en passant l'ensemble du certificat au travers d'une
fonction de hachage puis en chiffrant le résultat à l'aide de la clé
privée de l'Autorité de Certification.

Page 57 LES PKI - LIVRE BLANC

Les champs extensions, qui sont optionnels, ont une structure et une forme différentes.
Les extensions sont soit standardisées (voir ci-dessous une description de certaines d’entre-elles), soit
à la discrétion de la CA. En tout état de cause ces extensions doivent posséder trois champs définis ci-
dessous :

! Type : décrit le format du champ Value. Ce peut être un nombre, une chaîne de caractères, des
données complexes...

! Criticality : c'est un flag d'un bit. Si une extension est marquée comme étant critique, une
application qui ne saurait pas l’interpréter devrait en principe rejeter le certificat.
Ceci peut générer des problèmes d'interopérabilité.

! Value : contient la valeur des données de l'extension. Celle-ci peut être un texte, une date ou
même une photo.

Les extensions sont très importantes dans les certificats, puisqu'elles les rendent flexibles et
paramétrables : par exemple un certificat ne peut servir que pour telle application. Mais elles sont
aussi source d'incompatibilité car une application va rejeter un certificat si elle n'y trouve pas
l'extension qu'elle attend. Dans cette optique, la politique peut spécifier que tel certificat ne pourra
être utilisé qu'à cet usage ou définir toute autre contrainte qui rendront incompatibles des certificats
émis par d'autres CA.
Les extensions standards peuvent être regroupées en quatre types:
1) Informations sur les clés
2) Informations sur l'utilisation du certificat
3) Attributs des utilisateurs et des CA
4) Contraintes sur la co-certification

1) Informations sur les clés

Ce groupe d'extensions, qui renseigne sur l'utilisation qui doit être faite de la clé publique et du
certificat, est constitué des champs suivants:

Intitulé des champs Usage

Authority Key Identifier
Subject Key Identifier
Key Usage
Private Key Usage Period
CRL Distribution Point
Ce champ identifie de façon unique la paire de clés utilisée par la CA
pour signer le certificat. Il est utilisé pour faciliter le processus de
vérification de la signature du certificat dans le cas où la CA a utilisé
plusieurs clés depuis sa mise en œuvre.
Ce champ identifie de façon unique la clé publique qui est contenue
dans le certificat. Ceci est utilisé lorsqu’un utilisateur possède un
historique de clés de chiffrement.
Ce champ permet par exemple de retrouver rapidement la bonne
clé privée pour déchiffrer un document qui a été chiffré avec une clé
privée qui n’est plus en cours de validité.
Ce champ renseigne sur l'utilisation qui doit être faite de la clé.
Le champs Key usage peut avoir les valeurs:
- non-repudiation
- certificate signing
- CRL signing
- digital signature
- data signature
- symetric key encryption for key transfer
- Diffie-Hellman key agreement
Ce champ donne la date d'expiration de la clé privée associée à la
clé publique contenue dans le certificat. Il est généralement utilisé
pour la clé privée de signature dans le cas où sa période d’utilisation
est différente de la période de validité du certificat.
Cette extension définit l’emplacement des CRL.

Page 58 LES PKI - LIVRE BLANC

2) Informations sur l'utilisation du certificat
Ce groupe d'extensions permet de spécifier l’utilisation des certificats en accord avec la politique
définie dans la PKI.

Intitulé des champs Usage

Certificate Policies
Policy Mappings
Ce champ spécifie la politique de certification qui a présidé à
l'émission du certificat. Les politiques de certification sont
représentées par des Object Identifier (OID). Ces OID sont
enregistrés au niveau international, et leurs utilisations sont
standardisées.
Si ce champ est marqué comme étant critique, la PKI impose que le
certificat soit utilisé conformément à la politique de certification.
Dans le cas contraire, l'information est indicative. Ensuite libre à
l'application cliente de respecter ou pas la criticité.
Ce champ ne concerne que les co-certificats (le certificat émis par
une CA pour certifier la clé publique d'une autre CA). Il permet
d'associer la politique de certification d’une CA qui émet le certificat
à la politique de certification indiquée dans le co-certificat. S'il est
défini comme critique, il permet aux applications qui vérifient un
certificat appartenant à une chaîne de certification de s'assurer
qu'une politique de certification acceptable s'applique à tous les
certificats.

3) Attributs des utilisateurs et des CA

Ce groupe d'extensions permet de mieux spécifier l'identification des utilisateurs et des certificats.

Intitulé des champs Usage

Subject Alternative Name
Issuer Alternative Name
Ce champ spécifie une ou plusieurs informations sur le propriétaire
du certificat, les valeurs autorisées sont une adresse mail, un nom
de domaine, une adresse IP, une adresse mail X.400, un nom EDI,
une URL, un nom défini par un OID.
Ce champ permet de donner un nom spécifique à une CA.

4) Contraintes sur la co-certification

Les extensions de ce groupe permettent de limiter et contrôler la confiance envers d'autres CA en cas
de co-certification.

Intitulé des champs Usage

Basic Constraints
Name Constraints
Policy Constraints
Ce champ indique si l'utilisateur est un utilisateur final ou si c’est
une CA, dans ce cas le certificat est alors un co-certificat. On définit
alors une « distance de certification » qui spécifie jusqu'où doit
remonter une application qui veut vérifier un certificat en consultant
sa CRL, et jusqu'où est étendue la confiance dans la chaîne. Si cette
distance est par exemple à 1, les utilisateurs ne peuvent que vérifier
les certificats émis par la CA définie dans le co-certificat.
Ce champs n'est utilisé que dans les co-certificats, et permet aux
administrateurs de restreindre les domaines de confiance dans un
domaine de co-certification.
Ce champ s'applique aux co-certificats, et permet de spécifier les
politiques de certifications acceptables pour les certificats
dépendants du co-certificat.

Page 59 LES PKI - LIVRE BLANC

ANNEXE 3 : COORDONNEES DES PRINCIPAUX ACTEURS
CERTINOMIS
www.certinomis.com
20-22 rue Louis Armand
ALIROO 75015 Paris
www.aliroo.com tél : 01 58 09 80 60
International Headquarters
10 Yad Harutzim Street,
Kefar-Sava 44641 – Israël CERTPLUS
tél: + 972-9-767-7732 www.certplus.com
fax: + 972-9-767-7739 36, rue Guynemer
92447 Issy les Moulineaux Cedex
ACTIVCARD tél : 01 46 48 20 80
www.activcard.com fax : 01 46 48 20 84
ActivCard Europe S.A.
24-28, avenue du Général de Gaulle CHRYSALIS
92156 SURESNES Cedex www.chrysalis-its.com
tél : 01 42 04 84 00 Europe - England Office
fax : 01 42 04 84 84 The Atrium Court Apex Plaza
Reading Berkshire - RG1 1AX
BALTIMORE TECHNOLOGIES United Kingdom
www.baltimore.com tél : +44 (0) 1189 254 212 x 335
92, avenue de Wagram fax : +44 (0) 1189 560 380
75017 PARIS
tél : 01 72 74 63 27 COMPUTER ASSOCIATES
fax : 01 72 74 63 01 www.cai.com
14, avenue François Arago – BP 313
BETRUSTED
92003 NANTERRE
www.betrusted.com tél : 01 40 97 50 50
5, New Square, Bedfort Lakes fax : 01 40 97 51 51
Feltham, Middlesex TW14 8HA
United Kingdom CRITICAL PATH
fax : + 44 (0) 20 8831 2900 www.cp.net
Le Sari
CASHWARE 2, Avenue du Levant
www.cashware.com 93167 Noisy le Grand Cedex
56-58, rue de Ponthieu tél : 01 48 15 05 70
75008 PARIS fax : 01 48 15 05 80
tél : 01 56 59 69 59
fax : 01 56 59 69 40 DATUM
www.datum.com
CELO COMMUNICATIONS (racheté par Gemplus) 9975 Toledo Way
www.celocom.com Irvine, California 92630-1819 - USA
De Waal 36b tél : 949-598-7543
5684 PH Best fax: 213-330-0243
The Netherlands
tél : +31 499 37 7777 ENTEGRITY
fax: +31 499 37 8850 www.entegrity.com
European Headquarters
CERTCO Kingswick House - Sunninghill
www.certco.com Berkshire SL5 7BH - United Kingdom
Corporate Headquarters tél : +44 1344 290 900
55 Broad Street, Suite 22 fax: +44 1344 292 309
New York, NY 10004 - USA
tél : 212.709.8900 ENTRUST TECHNOLOGIES
fax : 212.709.6754 www.entrust.com
90, avenue des Champs Elysées
75008 PARIS
tél : 01 56 43 50 00 / fax : 01 56 43 50 57

Page 60 LES PKI - LIVRE BLANC

 UK Offices - Allagraf Ltd.
7 Holyrood Street - London Bridge
EVIDIAN London - SE1 2EL
www.evidian.com United Kingdom
Rue Jean Jaurès - BP 68 tél : +44 (0) 20 7367 4000
78340 Les Clayes-sous-Bois fax : +44 (0) 20 7367 4001
tél : 01 39 66 71 78
INTRALINKS
GEMPLUS www.intralinks.com
www.gemplus.com 60 Lombard Street
34 rue Guynemer London EC3V 9EA
92447 Issy-Les-Moulineaux Cedex United Kingdom
tél: 01 46 48 20 00 tél : +44 (0)20 7464 8460
fax: 01 46 48 20 01 fax : +44 (0)20 7464 8741

GLOBAL COMMERCE IPLANET (SUN-NETSCAPE ALLIANCE)

www.commerce.com www.iplanet.com
12303 Airport Way CNIT, B.P. 370
Broomfield, CO 80021-2583 - USA 2, Place de La Défense
tél : (303) 583-5000 92053 Paris-La-Défense
fax : (303) 583-5100 tél : 01 41 97 55 55
fax : 01 41 97 55 00
GLOBALSIGN
www.globalsign.com KYBERPASS
Haachtsesteenweg 1426, Chaussée de Haecht www.kyberpass.com
B-1130 Bruxelles - Belgique World Headquarters
tél : +32 2 724 36 36 1111 Prince of Wales Drive
fax : +32 2 724 36 37 Ottawa, ON Canada - K2C 3T2
tél : +1-416-234-2080
GTE CYBERTRUST fax : +1-613-727-5414
Racheté par Baltimore
MICROSOFT
IBM www.microsoft.com
www.ibm.com 18, avenue du Québec
40, avenue Terroirs de France 91957 Villebon sur Yvette cedex
75012 PARIS tél : 0 825 827 829
tél : 01 40 01 50 00 fax : 01 64 46 06 60

ID2 NCIPHER
Racheté par SmartTrust www.ncipher.com
UK, Europe & International
ID CERTIFY Jupiter House - Station Road
www.idcertify.com
Cambridge - CB1 2JD
United Kingdom RAINBOW TECHNOLOGIES
tél : +44 1223 723600 www.rainbow.com
fax: +44 1223 723601 50 Technology Drive
Irvine, California 92618 - USA
OBERTHUR tél : 949-450-7300
www.oberthur.com
12bis, rue des Pavillons RSA SECURITY
92800 - Puteaux www.rsasecurity.com
tél : 01 41 25 28 28 Europe, Middle East and Africa Headquarters
fax : 01 40 90 99 70 RSA House, Western Road,
Bracknell, Berks RG12 1RT - United Kingdom
PHAOS TECHNOLOGY tél : +44 (0) 134 478 1000
www.phaos.com fax: +44 (0) 134 478 1010
10th Floor - 11 Broadway
New York, NY 10004 - USA SAGEM
tél : (212) 514-6515 www.sagem.com
fax : (44) 171-681-3103 61, rue Salvador Allende
92571 Nanterre Cedex
tél : 01 40 70 63 63 / fax : 01 47 20 39 46

Page 61 LES PKI - LIVRE BLANC

SCHLUMBERGER TRUSTCENTER
www.schlumberger.com www.trustcenter.com
50, avenue Jean Jaurès - BP 620-12 Schloß Kellenberg
92542 Montrouge D-52428 Jülich-Barmen - Deutschland
tél : 01 47 46 66 67 tél : +49 (0)2461 – 9774-0
fax : 01 47 46 63 67
UNISYS
SECUDE www.unisys.com
www.secude.com 7 Boulevard des Bouvets
Informationssysteme GmbH 92027 Nanterre Cedex
Dolivostrasse 11 tél : 01 46 69 55 55
D-64293 Darmstadt - Deutschland fax : 01 47 24 74 22
tél : +49 61 51 - 8 28 97-0
fax : +49 61 51 - 8 28 97-26
UTIMACO
SIGNONLINE www.utimaco.com
www.signonline.com 8, place Boulnois
Corporate Headquarters 75017 PARIS
19900 MacArthur Boulevard - Suite 720 tél : 01 56 21 25 25
Irvine, CA 92612 - USA fax : 01 42 67 30 20
tél : (949) 608-1600
fax : (949) 752-7329 VALICERT
www.valicert.com
SMARTTRUST (GROUPE SONERA) European Headquarters
www.smarttrust.com Hoogoorddreef 9, Suite 212
The Atrium Court - Apex Plaza 1101 BA, Amsterdam, Z.O.
Reading - RG1 1Ax Netherlands
United Kingdom tél : +31 20 312 0543
tél : +44 1189 254 265 fax : +31 20 312 0643
fax : +44 1189 573 902
VERISIGN
SPYRUS www.verisign.com
www.spyrus.com 1350 Charleston Road
338 Euston Road, Suite 310 Mountain View, CA 94043
Regent's Place USA
London NW1 3BT tél : (650) 961-7500
United Kingdom fax : (650) 961-7300
tél : +44 (0) 171 544 8408
fax : +44 (0) 171 544 8401

THAWTE
www.thawte.com
142 rue Saint Jean, Suite 214
BP 237
14012 CAEN cedex 1
tél : 02 31 84 45 77
fax : 01 53 01 31 14

TIME PROOF GMBH

www.timeproof.de
Harburger Schloßstraße 6-12
D-21079 Hamburg - Deutschland
Tel.: +49-40-7 66 29-13 06
Fax: +49-40-7 66 29-551

TRUETIME
www.truetime.com
3750 Westwind Blvd.
Santa Rosa, CA 95403 - USA
Tél : 707-528-1230
Fax: 707-527-6640

Page 62 LES PKI - LIVRE BLANC

ANNEXE 4 : URL UTILES

Informations juridiques

www.legifrance.com

http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm

Normes et standards

PKI Forum :

www.pkiforum.com

www.pkiforum.org

IETF - groupe de travail PKIX :

www.ietf.org

www.ietf.org/html.charters/pkix-charter.html

W3C - groupe de travail Signature :

www.w3.org

www.w3.org/Signature

Standards PKCS :

http://www.rsasecurity.com/rsalabs/pkcs

GTA :

www.gta.multicert.org

Identrus :

www.identrus.com

Ministère des Finances – Téléprocédures

http://www.minefi.gouv.fr/dematerialisation_icp/dematerialisation_declar.htm

http://www.minefi.gouv.fr/DGI/somteleprocedures.htm

Page 63 LES PKI – LIVRE BLANC