1 Chapitre 1

Généralité sur les infrastructures à clé publique

1.1 Introduction

Il y a encore quelques années, les systèmes d'information étaient des systèmes fermés. Aujourd'hui, les
informations sont de plus en plus souvent liées et l'entreprise peut être composée de multiples zones de
sécurité. On peut déjà identifier différents types de don- nées situés sur des serveurs intranet, des sites
Internet et d'autres réseaux tels que des extranets.

Il est important de constater qu'aujourd'hui les entreprises ont conscience qu'il est vital de contrôler les
accès aux informations qui constituent le patrimoine de l'entreprise. De nombreuses données sont
potentiellement accessibles à des personnes qui, intentionnellement ou non, peuvent consulter ou
modifier un grand nombre d'informations.

C'est dans ce contexte que la problématique du contrôle d'accès prend tout son sens si l'on tient compte
du fait que sur le réseau, il peut être nécessaire de contrôler des informations telles que des messages
électroniques, des transactions commerciales et des transferts de données vers des destinataires situés
à l'extérieur des périmètres approuvés de l'entreprise.

Par exemple, si l'entreprise fait appel à des partenaires occasionnels, sur des projets à durée limitée ou
encore si vous devez approuver des personnes dont vous ne savez rien mais qui, cependant, doivent
avoir accès à certaines informations, alors la problématique sera certainement complexe et lourde à
gérer.

Finalement, les administrateurs système doivent être sûrs de l'identité de toutes les personnes qui
accéderont au réseau et, à partir de cette identité, contrôler les informations aux- quelles chaque
identité aura droit sur la base de rôles.

Une autre problématique des services informatiques est de distribuer et de gérer les informations
d'identification des utilisateurs au niveau le plus large et ce, avec le maximum de sécurité.

Les points que nous venons brièvement d'évoquer peuvent être pris en charge à l'aide des certificats
X509 Version 3 et d'une infrastructure à clé publique adaptée aux besoins de l'entreprise et de ses
partenaires.[1]
1.2 Définition
Une infrastructure à clé publique est un système logiciel composé de certificats numériques, d'autorités
de certification, d'autorités d'inscription qui utilisent les technologies cryptographiques par clé publique
pour vérifier et authentifier la validité de chacune des parties impliquées dans une transaction
électronique.

Plus encore que cette définition formelle, une PKI - pour Public Key Infrastructure, est un terme
générique qui, en fonction des entreprises, peut avoir une signification bien plus vaste. En effet, une
infrastructure à clé publique pourra devoir décrire les lois, les stratégies, les procédures, les standards
ainsi que les logiciels utilisés pour le con- trôle des certificats numériques, des clés publiques et des clés
privées.[2]

Une infrastructure à clé publique est donc composée des éléments fondamentaux suivants :

1. Les certificats numériques

Il s'agit d'une pièce justificative de l'identité de son détenteur composée d'une clé publique qui pourra
être utilisée pour signer et/ou crypter différents types de données.

2. Les autorités de certification (CA- Certification Authorities)

Il s'agit d'organismes ou de services approuvés habilités à émettre des certificats numériques.

L'architecture d'une PKI pourra être composée d'une seule autorité ou de plusieurs. Les besoins en
matière de sécurité ou de disponibilité des servi- ces de certificats pourront nécessiter plusieurs
autorités de certification. Chaque autorité assurera uniquement certaines tâches spécialisées. Il pourra
par exemple s'agir de l'émission de certificats pour le cryptage IP Sec ou pour la signature d'emails dans
la messagerie électronique. Il pourra aussi s'agir d'une autorité spécialisée pour l'authentification de
certains utilisateurs par cartes à puce.

3. Une stratégie d'utilisation des certificats et des procédures associées

Ces documents doivent formaliser comment l'autorité de certification et les certificats émis sont utilisés
et gérés. Un des points les plus importants sera de quanti- fier le niveau de confiance placé dans certains
certificats ainsi que les éventuelles incidences légales en cas de vol ou de mauvais usage desdits
certificats.

4. Un espace de stockage sécurisé et disponible

Les services d'annuaire sont certainement les mieux adaptés pour stocker et publier des éléments tels
que des certificats numériques. Windows 2000 et Windows Server 2003 permettent une intégration
forte des services de certificats avec l'annuaire Active Directory. De cette manière, tout utilisateur peut
facilement invoquer l'Active Directory pour accéder au certificat d'un autre utilisateur et ainsi utiliser la
clé publique de celui-ci.
 5. Les listes de révocation des certificats

Toute autorité émettrice de certificats doit aussi maintenir et publier régulièrement une liste de
révocation des certificats précédemment émis. Ce sera par exemple le cas de certificats dont la date
d'expiration n'a pas été atteinte, mais qui doivent, pour des raisons exceptionnelles, être supprimés
licenciement, perte de con- fiance, etc.

6. Les listes des autorités de certification approuvées (CTL Certificates Trust Lists)

Il s'agit de listes signées contenant les certificats des autorités de certification approuvées. Ces listes
sont stockées localement sur chaque poste de travail du réseau et peuvent être gérées et publiées de
manière centralisée à l'aide de l'Active Directory et des stratégies de groupe.

7. Les mécanismes d'archivage et de récupération des clés privées

Ces fonctions doivent permettre d'archiver et de récupérer la partie privée de la paire de clés
publique/privée. Cette opération doit pouvoir avoir lieu si un utilisateur perd accidentellement sa clé
privée. Cela peut aussi être le cas s'il est nécessaire à un tiers approuvé de récupérer des données
cryptées à l'origine.

8. Les standards de clés publiques utilisés

Il s'agit de décrire les spécifications des signatures numériques et des messages cryptés et d'être sûr que
chaque utilisateur puisse disposer de "sa clé privée en en garantissant la sécurité maximale. Concernant
Windows 2000 et Windows Server 2003, les services de certificats respectent les spécifications définies
par le groupe PKIX (Public Key Infrastructure X.509) de l'IETF.

1.3 Les différents acteurs pour une PKI :

1.3.1 Autorité de certification

L'autorité de certification est l'entité la plus importante dans l'infrastructure, parce qu'elle est l'entité
responsable de la génération des certificats. Ce dernier contient plusieurs informations telles que, la clé
publique, la durée de validité et les restrictions d'utilisation de la clé publique. Ce certificat est signé
avec la clé privée de l'autorité de certification. Pour vérifier la validité du certificat, il faut envoyer une
requête à l'autorité de certification afin de vérifier s'il est valide ou s'il a été révoqué. [3]

1.3.2 Autorité d'enregistrement

L'autorité d'enregistrement est l'entité qui vérifie les demandes d'enregistrement d'un nouvel utilisateur
dans l 'infrastructure. Elle peut être contenue au sein de l 'autorité de certification, cette répartition a
pour but de séparer les charges de chaque entité. En effet, si l'autorité d'enregistrement valide la
requête d'enregistrement, la demande de certificat passera directement à l'autorité de certification. [3]
1.3.3 3Autorité de dépôt (Repository)
Stocke l'ensemble des certificats valides et révoqués. L'ensemble des certificats des clés publiques émis
par la CA est mis à disposition des utilisateurs par l'autorité de dépôt.

Ce service est contraint par plusieurs exigences telles que, par exemple, le délai de mise à jour des listes
de révocation ou la disponibilité de ces listes. Le dépôt est également responsable de la publication de la
CRL (Liste de Révocation de Certificat). [3]

1.3.4 Annuaires
Pour que les utilisateurs puissent échanger leurs clés publiques, les certificats doivent être disponibles
au public. Pour cela, les certificats sont publiés dans un annuaire d'accès libre. Aussi, l'annuaire peut
stocker les certificats révoqués afin d 'avoir un accès rapide à ces certificats.[3]

Dans le domaine de sécurité, l'annuaire électronique peut être vu comme une base de données
spécifique permettant de sauvegarder les clés publiques (chiffrement asymétrique) de chaque utilisateur
et offrant la possibilité de recherche selon des critères prédéfinis.

L'annuaire permet à stocker et diffuser des certificats dans une PKI. Le point faible de l'annuaire
électronique se représente dans ce qui suit: un pirate peut corrompre la clé publique enregistrée dans
l’annuaire en la remplaçant par sa clé publique. La plupart des annuaires existants au format LDAP
(Lightweight Directory Access Protocol).[4]
Dépôt Certificat

Entité finale (Annnuaire)

Utilisateurs PKI

Composants PKI

Autorité d'enregistrement

Autorité de certification

Figure 1 Vu globale de PKI

1.4 Architectures de l'infrastructure à clés publique

1.4.1 Modèle hiérarchique

Le modèle hiérarchique est basé sur une approche à multiniveaux avec plusieurs niveaux d'autorités de
certification. Dans ce modèle, l'autorité de certification racine est placée au sommet de la hiérarchie et
possède un certificat autosigné. Aussi, dans cette architecture l'autorité de certification ne délivre pas
les certificats aux entités finales, elle délègue cette procédure aux autorités de certifications
intermédiaires. [3]

CA root

CA 1 CA 2

S1 S2 Sn S1 S2 Sn

Figure 2 PKI hiérarchique [3]

1.4.2 Modèle Peer-to-peer

Contrairement à l'architecture hiérarchique, dans cette architecture les autorités de certifications ont le
même niveau, c'est-à-dire les autorités de certification certifient l'une l'autre, ce qui crée une confiance
bidirectionnelle.

En effet, dans cette architecture les certificats sont cosignés. Elle se caractérise par la flexibilité en
rendant l'extension du domaine de confiance plus pratique, mais le problème de cette architecture est
dans la génération des certificats pour les autorités de certification du même niveau, ou chaque autorité
de certification doit échanger ses clés publiques pour pouvoir générer des certificats, ce qui rend la
gestion du système plus difficile.
 CA 1 CA 2

S1 S2 Sn S1 S2 Sn

Figure 3 PKI I Peer-to-pee [3]

1.4.3

1.4.4 Modèle bridge

Pour résoudre le problème de la complexité du processus du chemin de certification des modèles
hiérarchiques et Peer-to-Peer, on peut faire appel au modèle bridge (pont). Ce modèle est une
architecture qui combine les architectures hiérarchiques et Peer-to-Peer. Le modèle consiste à établir
des connexions entre les autorités de certification racine à travers une autorité de certification (autorité
du pont) en émettant des certificats croisés.

Ceci permet d'avoir une architecture stable et de limiter le nombre d'échanges entre les autorités de
certification, car il n'est pas nécessaire d'échanger la clé publique avec toutes les autres autorités, mais
uniquement avec l'autorité du pont.[3]

Bridge CA

Root CA 1 Root CA 2

Intermidiate CA 1 Intermidiate CA 1

End Entity 1 End Entity 1

Figure 4 PKI bridg [3]

1.5 Fonctionnement de PKI
Alice veut certifier que sa clé publique lui appartient. Alice envoie sa clé à un CA, ainsi que différentes
informations la concernant (nom, email, etc. ...).

Cet organisme vérifie toutes les informations de Alice, et ajoute son nom, une date limitée de validité, et
surtout une signature numérique au certificat. Cette signature est réalisée grâce à sa clé privée et à un
algorithme de hachage (ex RSA et le SHA).[4]

• L’CA fournit un certificat tel que: CA = EKRauth [T,IDA ,KUa ]

On va expliquer les éléments de certification de clé:

• EKRauth : signature apposée au certificat,

• T : timestamp,

• IDA : l’ensemble des informations propres à l’entité A

• Kua: la clé publique de A.

• Lorsque Bob veut envoyer un message à Alice, il applique la clé publique de l’autorité de
certification (CA).

• Cette action permet de vérifier que le certificat est bien authentique: DKUauth[CA] =

• [T,IDA ,KUa ]

1.6 Norme X.509 X.509

Est une norme de cryptographie de l'Union internationale des télécommunications pour les
infrastructures à clés publiques (PKI).

1.6.1 Génération de certificat X.509

Un certificat est généré après qu'une demande de certification a été initiée par une entité de
l'infrastructure à clé publique.

La demande est suivie d'un enregistrement, sous la responsabilité de l'AR, qui recueille et vérifie
l'identité du propriétaire du certificat et toutes les autres informations utiles à la délivrance d'un
certificat. Le RA transmet ensuite ces informations à l'autorité de certification qui doit émettre un
certificat. Avec les informations d'enregistrement et la clé publique du propriétaire du certificat,
l'autorité de certification peut émettre le certificat.
Pour ce faire, vous devez signer numériquement le certificat à l’aide de la clé de signature privée de l’AC.
Après que le certificat a été délivré et vérifié comme étant correct par le propriétaire du certificat, il
peut être distribué et utilisé par d'autres entités.[4]

1.6.2 Validation de certificat X.509

Lors de la vérification d'une signature numérique, non seulement la validité de la signature est
importante, mais également celle du certificat correspondant et de toute sa chaîne des certificats.

Les étapes permettant de vérifier une signature numérique (lors de la signature des documents ou lors
de l'authentification) peuvent être résumées comme suit:

1. Vérifiez la signature avec la clé publique dans le certificat.

2. Vérifiez la signature de l'émetteur du certificat.

3. Vérifiez la date de validité du certificat.

4. Vérifiez que le certificat n'a pas été révoqué.

5. Vérifier la validité des certificats d’émission dans la chaîne des certificats (vérifier la signature de [20]
l’émetteur, la validité de la date et le statut de révocation).

6. Vérifiez que l'autorité de certification racine ou une autorité de certification intermédiaire est
approuvée.[4]

1.6.3 Révocation de certificat X.509

La révocation de certificat, l'invalidation de clés publiques, peut être effectuée de différentes manières.
La distribution de listes de révocation de certificats (CRL) et l’offre d’un service en ligne avec le protocole
OCSP (Online Certificat Statu Protocol) sont deux méthodes couramment utilisées.

Une liste de révocation de certificats est une liste d'identifiants de tous les certificats émis par une
autorité de certification qui ont été révoqués . Pour prouver l'authenticité de la liste de révocation des
certificats, celle-ci est numériquement similaire aux certificats X.509. Les listes de révocation des
certificats peuvent être directement signées par l'autorité de certification qui a délivré les certificats
révoqués ou indirectement par un émetteur nommé.

La liste de révocation de certificats doit être mise à la disposition de toutes les entités effectuant
l'authentification et mise à jour périodiquement pour garantir qu'aucune entité ne fait confiance à un
certificat révoqué.

Un vérificateur va télécharger la liste de révocation des certificats, vérifier la signature, puis vérifier si un
certificat spécifique est présent dans la liste de révocation des certificats.

Un inconvénient des listes de révocation des certificats est qu'elles augmentent de taille et peuvent
devenir assez volumineuses si les certificats expirés ne sont pas supprimés.
Une solution à ce problème consiste à utiliser des listes CRL delta, contenant uniquement les identifiants
des certificats révoqués depuis l'émission d'une certaine liste CRL complète, la liste CRL de base. Les
listes CRL delta doivent être signées avec la même clé de signature que celle utilisée pour signer la liste
CRL de base. En émettant des listes de révocation de certificats delta, il est possible d’émettre de plus
Révocation de certificat X.509 La révocation de certificat, l'invalidation de clés publiques, peut être
effectuée de différentes manières.

La distribution de listes de révocation de certificats (CRL) et l’offre d’un service en ligne avec le protocole
OCSP (Online Certificat Statu Protocol) sont deux méthodes couramment utilisées.

Une liste de révocation de certificats est une liste d'identifiants de tous les certificats émis par une
autorité de certification qui ont été révoqués.

Pour prouver l'authenticité de la liste de révocation des certificats, celle-ci est numériquement similaire
aux certificats X.509. Les listes de révocation des certificats peuvent être directement signées par
l'autorité de certification qui a délivré les certificats révoqués ou indirectement par un émetteur
nommé. La liste de révocation de certificats doit être mise à la disposition de toutes les entités
effectuant l'authentification et mise à jour périodiquement pour garantir qu'aucune entité ne fait
confiance à un certificat révoqué. Un vérificateur va télécharger la liste de révocation des certificats,
vérifier la signature, puis vérifier si un certificat spécifique est présent dans la liste de révocation des
certificats.

Un inconvénient des listes de révocation des certificats est qu'elles augmentent de taille et peuvent
devenir assez volumineuses si les certificats expirés ne sont pas supprimés. Une solution à ce problème
consiste à utiliser des listes CRL delta, contenant uniquement les identifiants des certificats révoqués
depuis l'émission d'une certaine liste CRL complète, la liste CRL de base. Les listes CRL delta doivent être
signées avec la même clé de signature que celle utilisée pour signer la liste CRL de base.

En émettant des listes de révocation de certificats delta, il est possible d’émettre de plus petites mises à
jour vers les listes de révocation de certificats avec une fréquence plus élevée. Une autorité de
certification utilisant OCSP disposera d'un service en ligne que les entités peuvent interroger pour
connaître l'état de révocation d'un certificat spécifique. Toutes les réponses OCSP doivent être signées
numériquement.

Un des avantages de l'utilisation d'OCSP est qu'un vérificateur doit seulement extraire des informations
sur le certificat spécifique à vérifier (contrairement aux listes de révocation de certificats qui récupèrent
des informations sur tous les certificats révoqués).

De plus, les informations sur un certificat révoqué peuvent être récupérées presque immédiatement
après sa révocation, au lieu de devoir attendez qu'une nouvelle liste de révocation de certificats soit
publiée. [4]
1.7 Organisation d'une PKI

Figure 1 Organisation d'une PKI

Dans une infrastructure à clé publique ; pour obtenir un certificat numérique, l'utilisateur fait une
demande auprès de l'autorité d'enregistrement.

Celle-ci génère un couple de clé (clé publique, clé privée), envoie la clé privée au client, applique une
procédure et des critères définis par l'autorité de certification qui certifie la clé publique et appose sa
signature sur le certificat, parfois fabriqué par un opérateur de certification.
1.8 Conclusion
Nous avons vu qu’une infrastructure de la gestion des clés publiques se construit, c'est donc une
structure à la fois technique et administrative.

Comme les PKI intègrent la cryptographie à clé publique et certificat numérique, elles peuvent se confier
à des tierces parties de confiance et échanger des données en toute sécurité.

Il existe plusieurs solutions ou produits qui implémentent une PKI et qui offrent la possibilité de
sécuriser les données. Le chapitre suivant sera consacré à la mise en place de l’un de ces produits