Part I 

Rappels sur la Cryptologie

1
 Chapitre 1
La Cryptologie 
1. Introduction générale :

Des traces d'écritures secrètes se rencontrent dans l'étude de toutes les civilisations, même
les plus reculées, ce qui nous enseigne que la discipline qui en traite, la Cryptologie, a eu à
toutes les époques des adeptes plus ou moins géniaux.

En effet, c'est au troisième millénaire avant J.C. que naquirent, à peu près, en même temps
que les différentes civilisations chinoises, égyptiennes, phéniciennes, sumériennes - des
écritures symboliques, alphabétiques ou hiéroglyphiques. Ces écritures permettaient à ceux
qui en étaient initiés d'emmagasiner leurs connaissances et de correspondre.

Par la suite, la disposition naturelle des hommes à espionner les paroles ou les écrits de leurs
semblables, imposa l'usage de moyens divers destinés à en assurer le secret.

Les moyens les plus répandus étaient les écritures secrètes :

- le sens, par exemple, de certains dessins primitifs - objets ou animaux - n'était connu que
des seuls utilisateurs.
- les écritures invisibles obtenues par l'emploi d'encres sympathiques.

- les écritures dissimulées qui camouflent le secret dans des textes anodins.

- les écritures conventionnelles

2
 Dès l’antiquité, PLUTARQUE (écrivain grec 360-390 avant J.C) nous a signalé dans la vie
de LYSANDRE (général spartiate 39 av. J.C) des documents concernant l’utilisation d’un
moyen de chiffrement : la scytale des LECEDEMONIENS ;

De là naquit le premier principe de chiffrement : le principe de la Transposition.

Peu après, SUETONE (historien 69 av. JC) faisant remarquer qu’en 56 av. J.C, JULES
CÉSAR correspondait avec CICERON par un moyen de chiffrement simple qui consistait
en un décalage constant des lettres de l’alphabet normal. Il est à l’origine du 2 -ème
principe de chiffrement : celui de la substitution.

Exemple : “J U L E S C E S A R” est chiffré par -----

---> « P A R K Y I K Y G X », en utilisant la clef de
substitution

(a b c d e f g h i j k l m n o p q r s t u v w x y z)
(G H I J K L M N O P Q R S T U V W X Y Z A B C D E F )
2. La Cryptologie :
2.1 Définition :

La cryptologie est une science pure, qui émet les idées et les principes qui servent de base à la
technique du Chiffre. Elle a pour objet de concevoir et d’analyser avec des outils
mathématiques, les mécanismes permettant d’assurer des services de sécurité : l’authentification,
l’intégrité, la confidentialité et la non répudiation des données ainsi que la signature
électronique.
La cryptologie regroupe :
- la cryptographie

- et, la cryptanalyse
3
La cryptographie est une science appliquée, qui date, comme nous l’avons rappelé plus haut, de
l’antiquité ; elle provient des mots grecs (Kruptos = caché et graphein = écrit  écriture
cachée, secrète). Alors que la Cryptographie protège le secret des données, la Cryptanalyse (ou
le Décryptement ou l’Analyse cryptographique) cherche à en percer le secret.

2.2 Rappel sur la terminologie

2.2.1 Le Chiffre :
C’est l’ensemble des moyens et prestations de cryptologie qui permettent de transformer, à
l’aide de codes secrets, des informations claires en informations inintelligibles à toute personne
non qualifiée pour les connaître, ou à réaliser l’opération inverse grâce à des moyens matériels
ou logiciels conçus à cet effet. Le Chiffre revêt deux aspects : défensif et offensif

2.2.2 Chiffrer :

C’est transformer une information claire (appelé libellé ou texte claire, message claire…etc.)
en une information chiffrée (appelé texte chiffré, message chiffré, cryptogramme y compris les
en-têtes et les signatures …. Etc.), inintelligible à toute personne non autorisée)

4
Dans le schéma ci-dessus, on retiendra ce qui suit :

2.2.3 Clef de chiffrement :

Une clef de chiffrement est une fonction de chiffrement, une convention ou un ensemble de
conventions qui fixe la manière de chiffrer (ou de déchiffrer).

2.2.4 Algorithme de chiffrement :

Ensemble de règles mathématiques (logiques) utilisées pour résoudre les problèmes de
chiffrement et de déchiffrement. On distingue :

2.2.5 Les algorithmes de chiffrement symétriques ou à clefs secrètes (Algorithmes

conventionnels, à clé secrète, ou à clé unique ; les clés de chiffrement et de
déchiffrement sont identiques.

Ils sont divisés en deux sous catégories :

 Algorithmes par bloc

 Et les algorithmes de chiffrement continu (ou par flux-

5
 Stream Cipher).
2.2.5.1 Les algorithmes de chiffrement non symétriques (Asymétriques)
ou à clefs publiques (Algorithmes de chiffrement utilisant deux
clefs : l’une étant publiée (dans un annuaire par exemple) et
l’autre étant privée ou secrète (elle n’est jamais transmise)
2.2.5.2 Les algorithmes hybrides (mélanges des deux précédents)

3. Cryptographie Symétrique ou à clés secrètes :

Vers 1960, l'arrivée de l'informatique avait supplanté les machines de chiffrement
électromécanique (type Enigma). IBM avait lancé un programme de recherche sur le
chiffrement des données informatiques. En 1975, le résultat est proposé aux banques : il s'agit du
système de Chiffrement à Clés secrètes DES (Data Encryption Standard : Algorithme de
chiffrement des données par bloc de 64 bits).
Par la suite de nombreux algorithmes à clés secrètes basés sur le chiffrement par bloc ont
été inventés pour remplacer le DES ;
- Le Triple DES (surchiffrement, trois fois, par le DES pour rendre difficile l'attaque de
l'algorithme)
- L’IDEA (International Data Encryption Algorithm), conçu par Xuejia Lai et James Massey,
en 1990, et qui traite des blocs de clair de 64 bits avec une clé de longueur 128 bits. Le même
algorithme est utilisé aussi bien pour le déchiffrement.
- L’AES (Advanced Encryption Standard ou Rijndael) inventé par Daemen et Rijmen, deux
chercheurs belges, il utilise des blocs de 128 bits et trois longueurs de clés possibles de
128, 192 et 256 bits.

6
 Avantages et Inconvénients de la cryptographie à clé secrète :

 Avantage : l’avantage principal du chiffrement symétrique est sa rapidité (quelques

dixièmes de secondes) et il est bien adapté pour la protection du secret.
 Inconvénient : Le principal inconvénient réside dans la distribution des clefs.
La gestion des clefs est vite compliquée et inextricable quand le nombre de
correspondants augmente ; le nombre de clefs pour un réseau de n correspondants
étant, en effet de : n(n-1) /2

7
4. Cryptographie Asymétrique ou à clés publiques :
Jusque-là, tous les systèmes proposés avaient leur talon d'Achille : ils avaient une clé secrète
(identique pour les correspondants) dont la distribution devient vite critique suivant
l’importance du nombre de correspondants. De ce constat, deux chercheurs américains,
Whitfield Diffie et Martin Hellman proposèrent une autre approche dans la conception et
l'utilisation des clés (Diffie-Hellman Key Exchange) : au lieu d'utiliser une clé connue de
l'expéditeur et du destinataire, il serait plus intéressant d'utiliser une clé publique, disponible
dans un annuaire public (sur Internet par exemple), et une clé privée, connue du seul
destinataire, qui lui permet de déchiffrer ses messages.

La figureI.1 montre le fonctionnement de chiffrement à clés asymétrique [1].

Figure.I.1. Chiffrement à clé asymétrique

 Alice et Bob choisissent (p) très grand ; ils choisissent aussi un générateur (a) avec
a p.
 Ils publient (a) et (p).
 Alice génère une valeur privée aléatoire (KA) avec 0 ≺ KA ≺p-1
 Bob génère une valeur privée aléatoire (KB) avec 0 ≺ KB ≺p-1
 Ils calculent alors respectivement leurs clefs publiques en utilisant les paramètres
(a) et (p) et leurs valeurs privées (KA) et (KB)
 Clef publique d’Alice : EA = aKA (p)
 Clef publique de Bob : EB = aKB (p)
 Ils échangent leurs clefs publiques (EA, EB).

8
  Alice calcule sa clef secrète comme suit : KAB = EBKA(p)=(aKB)KA(p)
 Et bob calcule aussi sa clef secrète : KBA = EAKB (p)=(aKA)KB(p)

On remarque que EBKA = EAKB

Alice et Bob ont la même clefs secrète (K) pour protéger leurs informations : K=KAB=KBA

La remarque qu’on peut tirer ici est le système Diffie-Hellman est en fait un protocole
d’échange de clefs secrètes, le premier qui est basé sur le logarithme discret.

C’est qu’en 1979 naquit le système de Chiffrement à clés publiques RSA, au Weizmann
Institute en Israël, du nom de ses inventeurs (Ronald Rivest, Adi Shamir et Leonard
Adleman), précurseur de la cryptologie non symétrique, encore appelée cryptologie à clés
publiques, qui marque ainsi véritablement la naissance de la cryptologie moderne. Les
mécanismes de la cryptologie non symétrique reposent sur l'utilisation de fonctions
mathématiques dites à sens unique, que l’on ne sait pas inverser efficacement d’un point de
vue algorithmique.

Le RSA a ensuite été popularisé par le PGP (Pretty Good Privacy = Plutôt bonne intimité), un
programme conçu, en 1984, par le mathématicien- informaticien Philip Zimmermann pour la
protection du courrier électronique.

 Il est basé sur le chiffrement exponentiel ;

 Sa sécurité repose sur la fonction à sens unique suivante :

• le calcul du produit de deux nombres premiers est aisé

• mais la factorisation d'un nombre en ses deux facteurs premiers est beaucoup plus
complexe.

C’est le Crypto Système le plus répandu ; Il emploie de grands nombres entiers (par
exemple représentés sur 1024 bits).

Son principe repose sur une paire de clés, l’une publique et une privée, calculée comme
suit :

i. Génération de deux nombres premiers p et q avec φ(n)= (p-1) (q-1)

Rappel : φ (n) est la fonction d'Euler (nombre d'entiers positifs < n et premiers à n) :

- Si p est un nombre premier, φ (p)=p-1

9
 - Si n=p * q (avec p et q premiers) : φ (n)= φ(p) φ (q) = (p-1) (q-1)
ii. Calcul de leur produit n = p * q. Selon le niveau de sécurité souhaité, la taille de n
peut varier : 512, 768, 1024 ou 2048 bits.
iii. Détermination d'un nombre (e) tel que :
3<e<(p-1) (q-1) et e^(p-1) (q-1)
iv. Calcul d'un nombre (d) tel que :
ed = 1[(p-1) (q-1)] <==> ed = 1 [φ(n)]
v. En posant (n et e étant publiques et p, q et d étant secrètes) la clé publique
Pk=(e,n) et la clé secrète Sk =(d,n). On peut déduire une équation de chiffrement
et de déchiffrement.

Ainsi pour garantir une bonne sûreté cryptologique, il faut respecter les règles suivantes :

 Ne jamais utiliser de valeur n trop petite,

 Ne pas utiliser de clefs secrètes courtes
 N’utiliser que des clefs fortes (p-1 et q-1 ont un grand facteur premier),
 Ne pas chiffrer de blocs trop courts,
 Ne pas utiliser de n communs à plusieurs clefs,
 Si (d, n) est compromise ne plus utiliser n.
 Ne jamais chiffrer ou authentifier un message provenant d’un tiers sans le modifier.

De nombreuses recherches ont été par la suite effectuées, permettant de

développer des algorithmes pour assurer l'authentification, l'intégrité, la
confidentialité des données ainsi que la signature électronique.

Parmi les algorithmes proposé ou développés, on peut citer :

- Le Crypto système de RABIN (Une extension du RSA, basée sur la difficulté de

calculer des racines carrées modulo un nombre composite ; c'est l'équivalence de la
factorisation) ;

- Le Crypto système de Tahar El GAMAL Basé sur les logarithmes discrets ; il est
utilisé pour assurer la confidentialité et la signature numérique ; sa sécurité repose sur la
difficulté de calculer les logarithmes discrets ;
- Les Crypto systèmes de Robert Mc ELIECE et de NIEDERREITER basés sur les
Codes Correcteurs ;

10
 - Les Crypto systèmes basés sur les courbes Elliptiques ; l'utilisation des courbes
elliptiques, pour réaliser des crypto systèmes, a été proposée par KOBLITZ et
MILLER en 1985 ;
Plusieurs autres algorithmes de chiffrement à clés publiques ont été proposés et
décryptés.

Avantages et Inconvénients de la cryptographie asymétrique :

 Un avantage important des chiffrements asymétriques par rapport aux chiffrements
symétriques est qu’aucun canal secret n’est nécessaire pour pratiquer l’échange de la clé
publique. Le récepteur doit simplement être sûr de l’authenticité de la clé publique. Les
chiffrements symétriques demandent un canal secret pour envoyer la clé secrète – générée
d’un côté du canal de communication – vers l’autre côté.
 Un inconvénient des chiffrements asymétriques par rapport aux chiffrements symétriques
est qu’ils tendent à être environ « 1000 fois plus lents ». Autrement dit, il peut falloir plus
de 1000 fois plus de temps de CPU pour traiter un cryptage ou décryptage asymétrique que
symétrique.
 Un autre inconvénient est que les chiffrements symétriques peuvent être percés par une
attaque par « force brutale » : essai systématique de toutes les clés possibles jusqu’à
trouver la bonne.
En raison de ces caractéristiques, les chiffrements asymétriques sont généralement utilisés pour
l’authentification de données (par l’intermédiaire de signatures numériques), pour la
distribution d’une clé de chiffrement symétrique en masse (aussi appelée enveloppe
numérique), pour des services de non-répudiation, et pour un accord de clé. Les chiffrements
symétriques sont plutôt utilisés pour assurer la confidentialité des données.

5. Cryptographie hybride :

En cryptographie, un système de chiffrement hybride combine la commodité d'un système de

chiffrement à clé publique avec l'efficacité d'un système de chiffrement à clé symétrique. Les
systèmes de chiffrement à clés publiques sont basés sur des calculs mathématiques complexes, et
ils sont donc généralement beaucoup plus lent que les crypto systèmes à clés symétriques.
Les crypto systèmes hybrides sont des crypto systèmes qui combinent les fonctionnalités des
systèmes à clés secrètes et celles des systèmes à clés publiques par deux mécanismes
d’encapsulation appelés DEM et KEM :

11
  Le mécanisme DEM (Data Encapsulation Mechanism ou Mécanisme d’Encapsulation de
Données assure la confidentialité des messages (sécurité sémantique contre les attaques
adaptatives à textes chiffrés choisis)
 Le mécanisme KEM (Key Encapsulation Mechanism ou Mécanisme d’Encapsulation de
clés) est un mécanisme qui prend en entrée, du côté de l’expéditeur, une clé publique,
produit à la sortie une clés secrète et une encapsulation de cette clé, à l’usage du
destinataire qui dispose de la clé privée correspondante à la clé publique.
Pour les très longs messages la plus grande partie du travail dans le chiffrement / déchiffrement
se fait par le système clé symétrique qui est plus efficace, alors que le système à clé publique est
uniquement utilisé pour le chiffrement / le déchiffrement et le transport d’une courte valeur de
clé.
Par exemple pour chiffrer un message adressé à Alice dans un système de chiffrement hybride,
Bob fait ce qui suit :
 Il génère une Clé.
 Symétrique (K) pour le système d'encapsulation de données, et la chiffre avec la clé
publique d’Alice ;
 Il Chiffre ensuite le message clair (x) dans le cadre du système d'encapsulation de
données, en utilisant la clé symétrique qu’il a générée.
 Envoie ces deux cryptogrammes à Alice.
A la réception des deux textes chiffres, Alice effectue les opérations suivantes :
 Elle récupère la clé symétrique (K) en déchiffrant le premier texte chiffré à l’aide de
sa clé privée ;
 Elle récupère le message clair (x) en déchiffrant le deuxième texte chiffré à l’aide de
(K) ;
La figure.I.3 montre le fonctionnement de chiffrement hybride.

Figure.I.3. Chiffrement hybride

12
 Chapitre 2 
Les services de sécurité cryptographique
La cryptographie moderne met à la disposition des concepteurs de systèmes d’information des
outils permettant d’assurer, ou de contribuer à assurer, des fonctions de sécurité telles que la
confidentialité, l’intégrité, l’authenticité et la non-répudiation.

1. L’intégrité :
C’est un service cryptographique qui permet de s’assurer que l’information n’a été ni altérée ni
modifiée, par des personnes non autorisées, pendant sa transmission ou son stockage.

2. L’authentification :

C’est un service cryptographique qui permet de s’assurer de l’identité de l’expéditeur de

l’information, et par conséquent, de confirmer son identité.

3. La Confidentialité :

C’est un service cryptographique qui permet d’assurer le secret des informations afin qu’elles ne
soient ni rendues accessibles, ni divulguées à un utilisateur, une entité ou un processus non
autorisé.

4. La non répudiation :

C’est un service cryptographique qui permet d’obtenir la preuve de l’émission ou de la réception

d’une information ; l’expéditeur et le destinataire ne peuvent ainsi en nier l’envoi ou la
réception. Il empêche donc le reniement d’actions ou de messages.

5. La signature électronique :

C’est un service cryptographique permettant de vérifier l'authenticité de l'expéditeur ainsi que

l'intégrité du message reçu, et d’en assurer la non répudiation (Services d'authentification,
d’intégrité et de non répudiation).

13
 Part II

Etude et Conception d’une

PKI

14
 Chapitre 1

Les Architectures PKI 

Une architecture PKI (Public Key Infrastructure ou Infrastructure de gestion de clés publiques))
est un ensemble d’infrastructures permettant de d’échanger des communications sécurisées

1. Principe général :
Le principe de fonctionnement des infrastructures de gestion de clés repose
essentiellement sur les services précédemment cités.

Les services que l’infrastructure PKI fournit doivent obligatoirement être précédés d’une mise
en place d’une entité capable d’effectuer la gestion des différents certificats. Ces services se
basent sur des composants tels que nous avons vu préalablement.

Ainsi le fonctionnement d’une PKI se compose de plusieurs étapes :

 Générer les clés, qui se fait aléatoirement de sorte à garantir leur non- prédictibilité ;
 Enregistrer les clés, permettant de garder toute leur intégrité et cela de manière
confidentielle ;
 Générer les certificats ;
 Révoquer un certificat, en cas de corruption de ce dernier. Une fois révoqué celui-ci
est consigné dans une CRL (Liste de Révocation de Certificat) ;
 Supprimer une clé, lorsque celle-ci est expirée ou pose un problème de sécurité.
 Archiver une clé, afin de garder une trace de celle-ci même après une mise au rencart,
afin d’assurer la continuité du travail achevé avec cette dernière.

15
 2. Eléments d’une infrastructure PKI
Une infrastructure à clés publiques PKI est un ensemble de technologies, organisations,
procédures et pratiques qui supportent l'implémentation et l'exploitation des certificats basés sur
la cryptographie à clés publiques. La PKI est une structure à la fois technique et administrative
qui a pour but d'établir la confiance dans les échanges entre des entités morales, physiques et/ou
logiques. Ainsi elle assure la création et la distribution des certificats.
Techniquement la PKI est un système de gestion des clés publiques qui permet de gérer des
listes importantes de clés publiques et d’en assurer la fiabilité pour des entités, généralement
dans un réseau. Elle offre un cadre global permettant d’installer des éléments de sécurité tels que
la confidentialité, l’authentification, l’intégrité et la non-répudiation tant au sein de l’entreprise
que lors de l’échange d’information avec les différentes entités.

Architecture PKI

2.1 Fonction d’une PKI

Les implémentations techniques des PKI varient selon d’un fournisseur à l’autre, et il est
possible d’envisager de multiples options d’architecture et d’organisation en fonction des
besoins. Ainsi on citer les principaux concepts associés et les fonctions généralement
implémentées dans une PKI :
16
 Création des certificats
 Fonctionnalités sous la responsabilité de la RA
 Fonctionnalités sous la responsabilité de la CA
 Renouvellement et révocations des certificats
 Validation des certificats
 Autres services (Recouvrement, horodatage et notariat)

En synthèse, nous avons représenté sur le schéma suivant les briques fonctionnelles présentes
dans une architecture PKI offrant un service très complet, ainsi que les interactions entre la PKI
et les utilisateurs.

Exemple d’une architecture PKI

2.2 Types de services à rendre aux utilisateurs dans la gestion

des clés et la fourniture d’archivage

2.2.1 L’archivage est un service qui permet le stockage des paires de clés pour une
restitution en cas de perte de la clé privée. En effet, il a pour mission de stocker en toute sécurité
les clés de chiffrement émis au sein de l’infrastructure.
2.2.2 La publication est un service qui répertorie les différents certificats à clés publiques émis
par la CA afin de les rendre disponibles aux éventuels futurs utilisateurs, c’est pourquoi on se
17
réfère communément à lui par le terme de dépôt. Ainsi, un annuaire peut être utilisé (LDAP ou
X500 par exemple), un serveur Web ou encore un outil de messagerie, etc.
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).

Ce sont les personnes ou entités organisationnelles ayant émis ou émettant des demandes de
certificat, ou souhaitant simplement de vérifier la validité et les informations sur l’identité d’un
certificat préalablement reçu.
En plus des principaux composants que nous venons de voir, nous avons aussi quelques-uns dits
complémentaires, à savoir : les bases de données, le serveur d’horodatage, les serveurs HTTP,
SMTP, POP.

3 Acteurs d’une PKI

Un certificat a pour fonction de certifier l’identité de son porteur, et de lier cette identité à une
clef publique. Le premier acteur à prendre en compte est donc le porteur du certificat.

Le certificat est destiné à garantir l’identité du porteur à une personne distincte de son porteur :
ceux qui utilisent les certificats, par exemple pour vérifier les authentifications ou les signatures
électroniques, sont appelés les utilisateurs de certificats.

Les autres acteurs de la certification sont ce que l’on appelle les Prestataires de Services de
Certification Électronique (PSCE). Ils se divisent en de nombreuses catégories que nous
allons décrire ci-dessous :

 L’Autorité de Certification (AC) est une entité morale qui a pour rôle la définition des
règles qui régissent le cycle de vie des certificats, et l’application de ces règles.
 L’Autorité d’Enregistrement (AE) est une entité qui procède à la vérification de
l’identité du porteur en vue de lui remettre un certificat. Cette opération est parfois
appelée « enrôlement ».
 L’Opérateur de Certification (OC) est l’entité chargée de l’exploitation de
l’infrastructure technique de délivrance de certificats.
 L’Autorité de Validation (AV) peut être interrogée par l’utilisateur de certificat qui
souhaite vérifier la validité d’un certificat.

18
  L’Autorité de Révocation (AR) peut être saisie par le porteur de certificat ou son
responsable (par exemple l’entreprise à laquelle il appartient) pour inscrire le certificat
dans la Liste des Certificats Révoqués.

3. Les certificats
Ils assurent la sécurité d’une clé publique afin d’éviter les failles de sécurité liées à
l’usurpation d’identité et à la modification écrite. Leur rôle dans le fonctionnement des PKI
sera abordé plus en profondeur dans la suite du document.

3.1 Emission d’un certificat

Pour obtenir un certificat, il faut d’abord en faire la demande. Cette demande appelée
couramment CSR (Certificate Signing Request) doit contenir les éléments requis pour obtenir le
certificat. C’est une requête au format PKCS#10 qui contient des données sur l’utilisateur et
dans le cas d’une génération en mode décentralisé, la preuve de la possession de la clé privée.
L’Infrastructure de Gestion de Clés (IGC) ne gère pas l’identification des utilisateurs, pour cela
elle s’appuie sur un annuaire LDAP pour auto-remplir ces informations dans la demande. La
requête est ensuite validée ou rejetée par un opérateur de l’Autorité d’Enregistrement (AE) en
fonction du respect des critères définis dans les procédures. Une fois validée, la requête CSR est
signée par l’Autorité de Certification (AC) et ainsi transformée en certificat.

3.2 Types de certificats

Il existe trois (3) types de certificats :

Ø Les certificats de signature : Pour assurer l’intégrité, l’authentification et

la non répudiation
Ø Les certificats d’échange de clés : Pour assurer la confidentialité des
échanges de clés secrètes
Ø Les certificats de chiffrement : pour assurer la confidentialité des
échanges de données
.

4 Support et classes de certificat

4.1 Support :
Un certificat électronique utilise un procédé cryptographique pour sécuriser et soutenir des
documents. Le certificat électronique est un fichier de type PKCS#12(Public Key Cryptography

19
Standard), il peut se présenter soit sous sa forme logicielle ou il peut être stocké dans un support
cryptographique :
 Solution logicielle : le certificat est téléchargé et stocké sur le disque dur de
l'ordinateur.

 Solution matérielle : Sur une carte à puce ou une clé USB (le certificat est enregistré
sur la clé dédiée qui se connecte directement sur le port USB du PC).
Les avantages d’un certificat stocké dans un support matériel sont plus sûrs et plus pratiques, vu
qu'on ne peut pas le copier.

4.2 Classe de certificat :

Pour établir la fiabilité d’un certificat numérique, différentes classes ont été
définies, en fonction des modes de délivrance :
4.2.1 Certificat de Niveau 1 : Attribution sans vérification de l’identité du
propriétaire, sans contrôle donc de pièce justificative. Il est délivré sur la
base de la déclaration du client (Ex. : le certificat utilisé pour la déclaration
de revenu) ;
4.2.2 Certificat de Niveau 2 : Le propriétaire décline juste son identité mais il
n’est pas vérifié que c’est bien la sienne ;
4.2.3 Certificat de Niveau 3 : Le propriétaire du Certificat doit être
physiquement présent lors de sa remise, et il est vérifié qu’il est bien celui
qu’il prétend être. C’est celui qui est accepté dans le cadre des télé-
procédures administratives.
4.2.4 Certificat de Niveau 3+ : Il peut être exigé un support cryptographique
(Token USB) pour la remise du certificat, après vérification de l’identité du
propriétaire.

5 PGP : un premier exemple de certificat

PGP [126], inventé par Phil Zimmerman, est une autre solution d’authentification à base de
certificats. Par opposition à l’architecture X.509 dont la mise en œuvre requiert une forte
centralisation et hiérarchisation de ses divers composants, l’architecture de PGP est une
architecture complètement décentralisée. Cette décentralisation intervient au niveau de l’autorité
de certificat : un principal est lui-même une autorité de certification ; il peut générer et signer ses
propres certificats, il lui est également possible de signer les certificats d’autres principaux. Le
niveau de confiance d’un certificat est associé directement au niveau de confiance accordé à
20
l’autorité de certification qui l’a généré. Pour X.509, c’est une relation binaire, on fait confiance
ou non. PGP revisite cette notion de confiance, un principal pouvant accorder différents niveaux
de confiance dans le certificat d’un autre principal. Ce modèle de confiance de PGP stipule que
le niveau de confiance accordé à un certificat dépendra du niveau de confiance accordé à tous
les signataires du certificat. À chaque nouveau certificat découvert, l’utilisateur va pouvoir
calculer le niveau de confiance du certificat en fonction des signataires mais il peut aussi choisir
d’attribuer au certificat un niveau de confiance personnalisé. Aussi l’utilisateur d’un système
basé sur PGP doit maintenir une base de données associant chaque certificat avec un niveau de
confiance.
Cette solution décentralisée et simple a rendu le mécanisme PGP populaire auprès des personnes
désirant obtenir des mécanismes de sécurité basés sur une architecture à clé publique sans pour
autant devoir subir la difficile mise en place d’une infrastructure à clé publique du genre de
X.509. Le cryptosystème PGP est surtout utilisé comme outil de chiffrement pour la messagerie
électronique, chaque email pouvant être signé et/ou chiffré numériquement.
[126] Philip Zimmermann. Pretty Good Privacy : public key encryption for the masses. In
Building in big brother : the cryptographic policy debate, pages 93–107, New York, NY, USA,
1995. Springer-Verlag New York, Inc.

6 Le certificat X.509
En 1998, l’ITU-T (Organisme international définissant les normes en télécommunication) a
présenté la recommandation X.509 comme membre des recommandations de la série X.500 qui
définissent un service d’annuaire. Appliqué au modèle des infrastructures à clé publique,
l’annuaire représente un serveur qui maintient une base de données des certificats créés. X.509 a
été proposé comme infrastructure à clé publique utilisant des certificats et des signatures
numériques pour gérer la distribution des clés publiques.
X.509 a un fonctionnement fortement centralisé (figure 2.9), il repose sur l’utilisation d’un
ensemble restreint de tierces parties de confiance (autorité de certification) pour fournir la notion
de confiance quant à la distribution des clés publiques aux utilisateurs. Seules les autorités de
certification peuvent créer des certificats et les signer. Chaque principal possède la clé publique
de l’autorité de certification et s’en sert pour vérifier si un autre certificat est valide. Le
principal, par définition, fait confiance à l’autorité de certification qui a signé son certificat.
L’autorité de certification est la racine de la hiérarchie de confiance d’un annuaire X.500.

21
La norme X.509 identifie un principal en utilisant des informations telles que le nom, l’adresse
email, la ville, etc. Le champ sujet d’un certificat X.509 doit contenir l’identité exacte d’un
principal.
L’annuaire X.500 exprime cette idée sous le terme de distinguished name. Un distinguished
name est un nom unique qu’un utilisateur pourra utiliser quand il voudra se référer à une entité.
Étant donné qu’il s’agit d’un service d’annuaire, l’unicité des noms est importante, la relation
entre un principal et son certificat étant une bijection.
Les problèmes inhérents à une architecture à clé publique de type X.509 sont l’obtention de la
clé publique de l’autorité de certification, l’obligation d’utiliser des noms (DN) uniques,
l’architecture globale construite suite au chaînage de certificats des autorités de certification.

FIG. 2.9 – Une PKI selon X509

7 Cycle de vie d’un certificat

Lorsque l’autorité de certification délivre un certificat, celui-ci contient sa date de création et
une date de fin de validité. Généralement, comme de nombreuses cartes professionnelles, un
certificat de personne dans une entreprise a une durée de vie fixe par défaut, un an par exemple.
Si la personne est un stagiaire, un contractuel, un visiteur … cette durée peut correspondre
exactement à la durée de sa présence dans l’entreprise.
Mais cette date n’est pas suffisante pour invalider un certificat dans certains cas. En effet, une
personne peut quitter une entreprise ou changer de service ou se faire dérober sa clé secrète.
Dans ce cas il faut invalider son certificat courant. La méthode est la même que pour les cartes
bancaires. Chaque autorité de certification publie régulièrement la liste des certificats
révoqués, qui ne sont plus valides. Cette liste est généralement dans un annuaire LDAP,

22
accessible par le Web. Pour garantir son origine et son intégrité, elle est signée par l’autorité de
certification. De même que les commerçants récupèrent régulièrement la liste des cartes
bancaires non valables, il faut que les outils sécurisés chargent régulièrement, de manière
automatique ou avec intervention de l’utilisateur, cette liste de certificats révoqués.
Ce qu’on peut retenir sur la durée de vie d’un certificat est de :  

 Généré (valide) : Cette étape consiste à gérer techniquement un fichier électronique à

partir des informations personnelles du demandeur.
 Expiré : Au-delà d’une certaine date le certificat n'est plus valide car la validité
temporelle a été dépassée.
 Renouvelé : Le certificat régénère un nouveau certificat moyennant les mêmes
informations contenues dans le certificat expiré.
 Révoqué : Tout certificat est sujet à la révocation pour des raisons multiples. Il peut être
volé soit physiquement, soit suite à une attaque informatique. Pour cette raison, chaque
AC possède une CRL qui comporte les certificats dont les propriétaires ont exprimé leur
demande de révocation.
 Suspendu : Dans le cas où l'utilisateur a un problème temporaire avec son certificat, il
demande la suspension de son certificat, par la suite celui-ci est placé dans la CRL
jusqu'à nouvel ordre.

Cycle de vie d'un certificat

8 Composants d’une PKI
8.1 Autorité de de certification

23
Une Autorité de Certification est une organisation qui délivre des certificats électroniques à une
population. Elle possède elle-même un certificat (auto signé ou délivré par une autre AC) et
utilise sa clé privée pour créer les certificats qu’elle délivre, une AC joue le rôle de tiers de
confiance. Les services des autorités de certification sont principalement utilisés dans le cadre de
la sécurisation des documents ou des communications numériques via Internet ou Intranet.
Lorsqu'une personne souhaite transmettre des données en utilisant par exemple une
communication HTTPS (Hypertext Transfer Protocol Secure), elle génère une clé publique et
une clé privée puis envoie à l'une des autorités de certification une demande de signature de
certificat contenant sa clé publique ainsi que des informations sur son identité (coordonnées
postales, téléphoniques, email...).
Après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement,
l'autorité de certification signe le CSR grâce à sa propre clé privée (et non pas avec la clé privée
de la personne) qui devient alors un certificat puis le transmet en retour à la personne qui en a
fait la demande.

8.2 Architecture logique d’une AC

Dans la vie courante, comme dans le cas de distribution de certificats physiques (permis de
conduire, carte d’identité…), il est courant de posséder plusieurs types de certificats. De la
même façon, du point de vue électronique, nous serons amenés à posséder des certificats
provenant d’autorités différentes mais pour des usages différents. Mais, même pour un usage
identique, il peut être nécessaire de mettre en œuvre plusieurs autorités de certification. En effet,
il est difficile de pouvoir tout gérer, surtout au niveau mondial, par un serveur de certification
unique.

8.3 Opérations effectuées par l’autorité de certification

8.3.1 Délivrance des certificats

Une AC crée un certificat en le signant par sa propre signature numérique. Généralement, une
paire de clés (publiques, privées) est générée par le client, puis celui- ci dépose une demande de
délivrance de certificat pour l’AC. La demande doit contenir au moins la clé publique du client
et quelques autres informations (nom, adresse email,). Quand une RA est fondé l’AC n’a plus
besoin de faire le processus de vérification ou les autres fonctions de gestion car ils deviennent
parmi les responsabilités de la RA. Après la vérification de la demande, l’AC crée le certificat
numérique et le signe.

24
 8.3.2 Renouvellement des certificats
Chaque certificat a une période de validité et donc une date d’expiration bien connue. Quand un
certificat expire, un processus de renouvellement est éventuellement initialisé et donc après
l’approbation positive, un nouveau certificat va être publié pour l’EE considérée.
8.3.3 Révocation des certificats
L’AC envoyé le certificat pour le CRL (liste de certificats annulés) quand la durée de vie
maximale pour un certificat est expirée. Il y a plusieurs raisons peuvent amener une autorité à
annuler des certificats :
 Il est supposé que la clé privée du détenteur du certificat a été révélée ou subtilisée de
façon frauduleuse ;
 L’utilisateur a perdu le rôle attaché à la possession de son certificat ;
 La clé privée de l’autorité de certification a été compromise ou subtilisée.
 Publication des certificats et des CRLs

Une fois le certificat est délivré ou qu’il est révoqué, l’information doit être publiée dans un
annuaire public (conforme aux normes X.500 dans la majorité des cas).

9 Autorité d’enregistrement RA
L'autorité d'enregistrement est responsable des tâches administratives associées aux requêtes
effectuées par l'entité d'extrémité.

C’est une entité optionnelle dans la PKI. Si l'autorité d'enregistrement n'est pas présente dans la
PKI, l’AC assume les mêmes tâches que celles associées à l'autorité d'enregistrement.
Les fonctions qu'une autorité d'enregistrement doit mettre en application varient selon les
fonctions que l'on souhaite mettre en œuvre sur la PKI, mais elle doit au minimum gérer les
fonctions de vérification de l'identité du demandeur.
L’autorité d’enregistrement est généralement constituée des fonctions suivantes :
 Authentification personnelle (physique) du sujet demandant un certificat ;

 Vérification de la validité des informations indiquées par le demandeur ;

 Valider le droit pour un sujet de demander un certificat ;
 Vérification que le sujet possède la clé privée relative à la demande de certificat. On se
réfère généralement au POP (Preuve de Possession) ;

 Reporter une compromission de clé quand une révocation est nécessaire ;

25
  Attribution des noms à des fins d'identification ;
 Génération des secrets partagés à utiliser pendant les phases d'initialisation et les phases
de collecte de demande de certificat ;

 Déclenchement du procédé d'enregistrement avec l'autorité de certification de la part de

l'entité d'extrémité ;

 Archivage des clés privées ;

 Initiation du processus de recouvrement de clé ;
 Distribution des clés privées (cartes à puce, Token USB (Universal Serial Bus).

10 Autorité de dépôt (Repository)

Le dépôt est généralement un annuaire LDAP (Lightweight Directory Access Protocol) qui est
utilisé pour le stockage public des certificats et des CRL. PKI supporte essentiellement les
annuaires LDAP via les protocoles opérationnels. Bien que les opérations avec un protocole de
gestion puissent fournir un support de requête pour obtenir certains certificats ou des CRL,
LDAP peut être employé directement comme protocole de consultation pour le même type
d'information.
10.1 LDAP

Le LDAP est un protocole d'accès aux services annuaire qui propose une grande flexibilité pour
la gestion des certificats d'une organisation. Les administrateurs systèmes peuvent stocker la
plupart des informations requises par la gestion des certificats dans un annuaire compatible
LDAP. Les informations stockées dans l'annuaire peuvent également être utilisées en association
avec les certificats pour contrôler l'accès aux différentes ressources disponibles sur un réseau en
fonction des utilisateurs ou des groupes d'utilisateurs.

11 Architectures hiérarchiques reposant sur X.509

 L'organisme de normalisation ISO a défini la norme X.509, définissant le format et le
contenu d'un certificat digital.
 Un certificat X.509 est composé des principaux champs suivants :
 Version
 Numéro de série
 Algo ID et paramètres
 Émetteur
 Période de validité
26
 ...{
 Le N° de version désigne la version du certificat (vs. 2 ou vs. 3)
 Le numéro de série est attribué au certificat par l'émetteur.
 L'algo ID désigne l'algorithme utilisé pour la signature du certificat. Les paramètres
associés indiquent par exemple la longueur de la clé utilisée, …
 L'émetteur est le nom de l'autorité qui a généré le certificat.
 Période de validité du certificat.
 Le propriétaire est le nom de l'entité à qui appartient ce certificat.
 PK est la clé publique de ce propriétaire.
 L'algo ID désigne l'algorithme avec lequel sera utilisée la clé PK. Les paramètres
associés indiquent par exemple la longueur de la clé utilisée, …
}

 Propriétaire
 PK du Propriétaire
 Algo ID et paramètres
 SIGNATURE

12 Le modèle PKIX
Le groupe de travail PKIX a été créé à l'automne 1995 dans le but de développer des normes
Internet pour prendre en charge les infrastructures à clé publique (PKI) basées sur X.509.
Initialement, PKIX a poursuivi cet objectif en profilant les normes X.509 développées par le
CCITT (plus tard l'UIT-T). Plus tard, PKIX a lancé le développement de normes qui ne sont pas
des profils de travail de l'UIT-T, mais plutôt des initiatives indépendantes conçues pour
répondre aux besoins PKI basés sur X.509 sur Internet. Au fil du temps, cette dernière catégorie
de travail est devenue le principal objectif du travail de PKIX, c'est-à-dire que la plupart des
RFC générées par PKIX ne sont plus des profils de documents ITU-T X.509.
PKIX a produit un certain nombre de RFC normalisés et informatifs. RFC 3280 (certificat et
profil CRL) et RCF 3281 (profil de certificat d’attribut) sont des exemples récents de RFC de
suivi des normes qui profilent les documents de l'UIT-T. RFC 2560 (profil d'état du certificat en
ligne), RFC 3779 (extensions d'adresse IP et de numéro AS) et RFC 3161 (autorité
d'horodatage) sont des exemples de normes de suivi des RFC initiées par l'IETF. Les RFC 4055
(RSA) et RFC 3874 (SHA2) sont des exemples de RFC informatives qui décrivent comment
utiliser les algorithmes de clé publique et de hachage dans les PKI.

27
PKIX continuera à suivre l'évolution des documents UIT-T X.509 et maintiendra la
compatibilité entre ces documents et IETF PKI normes, puisque le profilage des normes X.509 à
utiliser sur Internet reste un sujet important pour le groupe de travail.
PKIX n'approuve pas l'utilisation d'algorithmes cryptographiques spécifiques avec ses
protocoles. Cependant, PKIX publie des normes de suivi des RFC qui décrivent comment
identifier les algorithmes et représenter les paramètres associés dans ces protocoles, et comment
utiliser ces algorithmes avec ces protocoles. Nous prévoyons que des efforts dans ce domaine
continueront d'être nécessaires au fil du temps.
PKIX poursuivra de nouveaux travaux dans l'arène PKI si les membres du groupe de travail
manifestent un intérêt suffisant et s'ils sont approuvés par le directeur de la zone de sécurité
compétent. Par exemple, la validation de certificat sous X. Les normes 509 et PKIX exigent
qu'une partie de confiance utilise une ancre de confiance comme début d'un chemin de certificat.
Ni X.509 ni les normes PKIX existantes ne définissent de protocoles pour la gestion des ancres
de confiance. Les mécanismes existants de gestion des ancres de confiance, par exemple dans
les navigateurs, sont limités en fonctionnalités et non standard. Il y a un intérêt considérable
dans la communauté PKI pour définir un modèle standard pour la gestion des ancrages de
confiance, et des protocoles standard pour permettre la gestion à distance. Ainsi, un futur
élément de travail pour PKIX est la définition de ces protocoles et des modèles de données
associés.

13 La fonction d’administration
Contrôle sur le conteneur des services de clé publique Active Directory. Contrôle donc les
modèles, la publication approuvée et les autres éléments de configuration à l'échelle de
l'entreprise (forêt).
Possède des droits de gestion d'autorité de certification sur l'autorité de certification. Contrôle
l'attribution des rôles sur l'autorité de certification. Est également autorisé à changer les
propriétés de l'autorité de certification. En général, ce rôle correspond également à un
administrateur local du serveur de l'autorité de certification, sauf si une séparation des rôles est
adoptée.
Possède des droits d'utilisateur de gestion de la sécurité et de journaux d'audit sur une autorité de
certification. Ce rôle correspond également à un membre du groupe Administrateurs locaux sur
l'autorité de certification (requis pour accéder aux journaux d'audit).
Possède des droits d'émission et de gestion des certificats sur la CA.

28
Il est possible de configurer plusieurs gestionnaires de certificats sur chaque autorité de
certification – chacun d'eux gérant des certificats pour un sous-ensemble d'utilisateurs ou
d'autres entités finales.
Conserve le certificat et la clé requis pour signer la demande de certificat avant approbation.
Conserve le certificat et la clé requis pour décrypter les clés privées archivées stockées dans la
base de données des certificats.
Possède des droits de sauvegarde et de restauration sur un serveur de CA.

14 Authentification d’entités à partir de certificats

Dans cette section, nous allons nous intéresser à l’authentification des entités sécurisées.
Lors d’une interaction, le gestionnaire de sécurité doit pouvoir identifier les entités
sécurisées impli- quées afin de rechercher les règles de sécurité concernant cette interaction.

Il faut se rappeler que l’un des buts poursuivis dans notre approche est de proposer une
gestion de la sécurité la plus transparente et configurable possible aussi bien pour
l’utilisateur que pour le développeur. Pour cela, on doit au mieux supprimer ou, dans le pire
des cas, minimiser une interaction entre le code de sécurité et l’utilisateur. Il nous faut une
solution technique qui permette l’automatisation des divers processus entrant en jeu dans la
gestion de la sécurité. Dans le cas qui nous intéresse maintenant, notre solution doit pouvoir
créer les objets nécessaires à l’identification d’une entité automatiquement.
En nous basant sur l’étude bibliographique présentée dans ce manuscrit et des
contraintes suscitées, la solution d’authentification qui s’impose est l’utilisation d’une
architecture à clé publique de type SPKI. Le choix de la solution SPKI s’explique par la
nature même des entités à identifier. En effet, l’infrastructure SPKI permet l’attribution de
certificats à des objets logiques comme les runtimes, les nœuds ou encore les objets actifs ce
qui n’est pas le cas de l’infrastructure PKI dont les certificats identifient une entité physique
ou morale en donnant son nom, son émail, sa localisation, . . . . Ainsi, l’identification des
diverses entités sécurisées se fera en attribuant une identité unique à chaque entité au moyen
de certificats.

Une autre fonctionnalité intéressante réside dans la possibilité d’établir une chaîne de
certificats. Le chaînage de certificats permet d’obtenir l’identité de toutes les entités qui ont
successivement généré des certificats jusqu’au certificat final qui identifie l’entité courante.

29
 En d’autres termes, à partir du certificat d’une entité, nous sommes capables de retrouver le
certificat de l’utilisateur qui l’a lancée. Il n’existe aucune limitation à la taille de cette
chaîne de certificats. Cependant il convient de modérer la taille de cette chaîne : étant donné
que la validation d’un certificat requiert la validation de tous les certificats présents dans la
chaîne, plus cette chaîne est courte, plus la validation du certificat sera rapide.
Nous avons créé une interface graphique regroupant les fonctionnalités nécessaires à la
gestion des certificats. Elle permet la création de certificats au format PKCS#12,
l’importation et l’exportation de certificats vers d’autres formats standard pouvant être
utilisés par d’autres logiciels. Il est possible d’utiliser l’interface graphique pour générer des
certificats pour tous les types d’entités ainsi que des certificats d’application. La figure 5.8
présente une entité dont le certificat contient une chaîne de certificats.

FIG. 5.8 – Outil de gestion des certificats

15 Architectures non hiérarchiques

15.1 Modèle de confiance PGP
PGP (Pretty Good Privacy) est un mécanisme de sécurité au niveau applicatif, il a été inventé
par Philip Zimmermann. Le premier logiciel utilisant
PGP a été publié en 1991 comme logiciel libre. PGP est un système de cryptographie hybride
car il combine la cryptographie symétrique et asymétrique. La combinaison de ces deux
mécanismes de cryptographie le rend très performant. Il est basé sur :

30
-la signature électronique pour le contrôle d’authenticité (s’assurer que le message vient bien de
la personne qui déclare l’avoir envoyé) et le contrôle d’intégrité (s’assurer qu’il n’y a pas eu
altération du message pendant le transport).
-le chiffrement pour permettre la confidentialité du message.
Le principe de PGP avant l'expédition du message est le suivant :
La clé secrète

Un xb3pTu
secret 6" U
4g&)j?i

Le message en Le message
clair Le message chiffré
chiffré + la clé
secrète
chiffrée

La clé publique
La clé g6(à
secrèt Yku:
e or9s5,

La clé secrète en La clé secrète

clair chiffrée

31
 Figure 7 : fonctionnement de PGP : envoi d'un message

On effectue l'opération inverse à la réception du message

16 Autres architectures
L’infrastructure PKI est généralement composée de plusieurs CA reliés par des « trust paths
» ou chemins de confiance. Selon l’environnement, les CAs peuvent être organisés de manière
complètement différente et de leur architecture dépendra l’adaptabilité du modèle de
confiance. Ainsi, les architectures les plus couramment utilisées sont les suivantes :
- L’architecture hiérarchique
Le fonctionnement de cette architecture dans le cas de deux autorités de certification (CA1 et
CA2) régies par une autorité de certification centrale ou « CAroot » est le suivant : CA1 et
CA2 envoient leur clé publique au CA central qui génère un certificat pour chacun des deux
CA. Au sein de cette architecture, le « CAroot » a le plus haut niveau d’autorité et possède
donc un certificat autosigné. Aussi, cela implique que tous les composants de l’architecture
placent leur confiance dans le CA central.
- L’architecture P2P (Peer-to-Peer)
En opposition à l’architecture hiérarchique, l’architecture Peer-to-Peer place les différents CA
au même niveau d’autorité. On arrive alors à une situation dans laquelle les certificats sont
cosignés, le CA1 pouvant signer des certificats pour le CA2 et vice-versa. L’inconvénient de
cette architecture est alors le besoin d’échange mutuel des différentes clés publiques pour
qu’un CA génère des certificats pour ses homologues.
- L’architecture en pont

L’architecture en pont ou « Bridge » est une association des deux architectures précédemment
abordées. Comme l’architecture hiérarchique a pour principales lacunes la disponibilité et la
sécurité et que le modèle pair-à-pair est ralentit par la multitude d’échanges qui y sont
générés, alors l’architecture en pont palie aux lacunes des deux architectures précédentes.
Son fonctionnement est similaire à celui du P2P à la différence que les échanges entre CA qui
ralentissaient le P2P sont réduits dans la mesure où les CAs n’échangent leurs clés qu’avec l’autorité
pont. On peut aussi définir cette architecture comme une architecture hiérarchique où le CAroot est
au même niveau d’autorité que les autres CAs qui y sont affiliés.

La figure 2 et le tableau 2 présentent une comparaison des trois architectures citées ci-haut.

32
 Figure 2: Les architectures PKI

Type d’architecture Avantages Inconvénients

Classique (Hiérarchique) Adapté à une grande

implémentation Non flexible
Problème en cas
d’indisponibilité du Root CA

Mesh Flexibilité
Non adapté à une grande
implémentation
Difficulté à remonter une chaîne
de confiance

33
 Bridge
Interopérabilité entre PKI Problème en cas
Flexibilité d’indisponibilité du Bridge CA
Adapté à une grande
implémentation

Tableau 2 : Comparaison des architectures PKI

17 Spooky/Sudsy (SPKI/SDSI)
La lourdeur d’une infrastructure à clé publique basée sur X.509 a amené la communauté à
chercher d’autres solutions de sécurité basées sur une infrastructure à clé publique. SPKI
(Simple Public Key Infrastucture) [35, 36] est le fruit de ces recherches. Il propose un système
de sécurité distribué simple à mettre en œuvre.
Un des premiers principes de SPKI est de revenir sur la définition du certificat qui, dans
X.509, associe une personne physique à une clé publique. SPKI lève cette limitation en
permettant d’attribuer une paire de clés publique/privée à n’importe quelle entité. Bien
évidemment la notion de propriétaire (personne, organisation, ordinateur) d’une clé est
possible et autorisée mais elle n’est pas nécessaire. Le propriétaire contrôle la clé publique et
on peut la voir comme un proxy pour un individu.
Le deuxième principe est de considérer toutes les clés comme égales. Contrairement à X.509
où seules les autorités de certification peuvent certifier un certificat, tout principal (certificat)
est capable de générer des certificats donc des principaux (certificats). De plus,
l’infrastructure de sécurité ne repose pas sur une architecture centralisée ; cette approche
permet le déploiement facile et rapide d’architectures sécurisés autonomes.
Chaque principal peut assigner un nom choisi arbitrairement à un principal, l’unicité globale
des noms n’est plus requise et ils peuvent être définis de manière à être compréhensible par
des humains. Les noms assignés dans un principal ne restent valides que dans le contexte de
ce principal. Ainsi des noms génériques comme "maman" ou "papa" peuvent être utilisés par
plusieurs principaux sans pour autant faire le lien vers les mêmes principaux.
SDSI (Simple Distributed Security Infrastructure) [90, 80] désigne le mécanisme de nommage
existant au sein de SPKI. Les politiques de sécurité sont conçues pour s’exprimer au sein de
listes de contrôle d’accès. Afin de faciliter leur gestion, il est possible de regrouper les
principaux au sein de groupes et d’utiliser ces groupes au sein des politiques de sécurité ou
d’utiliser les noms symboliques définis au sein des certificats.

34
Cependant le modèle présuppose qu’un principal soit à tout moment accessible pour fournir
un ensemble de services comme l’accès aux certificats générés par ce principal et l’accès aux
autres objets appartenant au principal qui ont pu générer des certificats.

18 Politique de sécurité et contre-mesures

18.1 Politique de sécurité
Avant de mettre en œuvre une politique de sécurité réseau, les organisations doivent définir
les privilèges des utilisateurs, le rôle des administrateurs, le système de maintenance et
comme l’organisation va prévenir et réagir aux éventuelles brèches dans la sécurité. Cette
politique est la ligne conductrice qui sera suivi lors de la mise en œuvre de la PKI.
Une fois cette problématique définie, la politique de sécurité réseau pourra être définie elle
aussi en incluant couramment :
 Rapport pratique de certification CPS (Certification Practice Statement).

 Politique du certificat CP (Certificate Policy).

18.2 Modélisation de la menace et contre-mesures

19 Défauts des PKI
Le principal inconvénient de notre approche réside dans le temps nécessaire à la génération
de la paire de clés asymétriques nécessaire lors de la création d’un certificat. Ainsi une
application qui passe son temps à créer des objets actifs se trouvera pénalisée dans son
fonctionnement. Cependant, cette remarque s’applique également, dans une moindre mesure,
au concept d’objet actif sans sécurité. Un objet actif est composé de plusieurs méta-objets et
d’un fil d’exécution. Sa création est elle-même coûteuse par rapport à la création d’un objet
java standard. Il nous semble raisonnable de supposer que lorsqu’un objet actif (sécurisé ou
non) est créé, sa durée de vie est largement supérieure au temps de sa création.

35
 Chapitre 2

Présentation d’EJBCA
EJBCA (Enterprise Java Bean Certification Authority) est une IGC Open Source écrit en
JAVA/JEE pouvant gérer plusieurs autorités de certification (CA). C’est la firme suédoise
PRIMEKEY AB qui assure le maintien, du développement et de la distribution de la version
commerciale. EJBCA propose aussi un serveur d’horodatage, un serveur OCSP et un serveur de
signature qui peut être déployé séparément de l’IGC EJBCA.Chaque composant peut être déployé
de manière autonome ou combinée avec EJBCA. EJBCA comporte une architecture applicative et
une architecture fonctionnelle.
L’architecture fonctionnelle est composée de :
 l’autorité de la PKI ou autorité de certification ;
 l’autorité d’enregistrement ou entité administrative ;
 l’autorité d’enregistrement local ;
 le webra conçu pour renforcer la partie fonctionnelle d’EJBCA.
 De composants additionnels tels que :

L’architecture applicative quant à elle est composée de :

 la couche de présentation ;
 la couche applicative ;
 la couche de données.

1 ARCHITECTURE FONCTIONNELLE
Elle est représentée par la figure suivante :

36
37
1.1 L’autorité de certification ou autorité de la PKI

Elle est chargée de l’émission et de la révocation des certificats. Une même instance peut gérer
plusieurs autorités de certification et autorités de certification subordonnées. Ses principales
fonctions sont :
 Edition et création des certificats d’autorité de certification ;

 Création et l’édition de profils de certificats ;

 Affichage et récupération des certificats d’autorité de certification et la génération des listes de

certificats révoqués ;

 Création et l’édition de profils de certificats ;

 Paramétrage du service de publication des certificats et des listes de certificats révoqués ;

 Génération des listes de certificats révoqués ;

1.2 L’autorité d’enregistrement ou entité administrative

Elle est chargée de la gestion de la PKI c’est-à-dire des fonctions d’authentification, de gestion de
vie des certificats, de la journalisation, de la publication et de paramétrage de la PKI. Elle est par
ailleurs comme toute autorité d’enregistrement de la gestion des requêtes en direction de l’autorité
de certification. Elle permet aussi de définir les éléments constitutifs des certificats et le format
(des entités publiques).
Les fonctions incluses dans l’autorité d’enregistrement sont les suivantes :

38
 La gestion des administrateurs et des droits associés ;

 La définition du service de publication ;

 La gestion de clefs (séquestre et recouvrement) ;

 La gestion des requêtes pour l’obtention de certificats (rejet, validation et révocation) ;

 La gestion du renouvellement des certificats ;

 La gestion des tokens USB et cartes à puces ;

 La gestion des profils de certificats et profils d’entité ;

1.3 L’autorité d’enregistrement local

Elle joue le rôle d’interface avec l’infrastructure c’est par son biais que sont réalisés les requêtes
de certificats, de révocation ou pour obtenir les éléments publiques de l’Infrastructure de gestion
de clefs. Elle propose les appels suivants :
 A partir d’une page web sur le site de l’organisation ou site dédié à l’infrastructure de gestion de
clefs ;

 A partir d’une ligne de commandes et permet en outre d’effectuer des tâches d’administration ;

 A partir d’une API Java intégrée dans des composants métiers ;

 Par le biais du protocole SCEP (Simple Certification Enrollment Protocol) pour les routeurs
CISCO ;

1.4 Le WebRA

Son rôle est de renforcer la partie fonctionnelle et se compose des éléments suivants :
 Modules de gestion de vie des certificats (précondition, demande, révocation, renouvellement) ;

 Moteur de workflow qui permet de définir des cinématiques de vie des certificats ;

 Outils de reporting, facturation et de statistiques ;

 Indépendance de la gestion de l’authentification et de l’habilitation ;

39
2 ARCHITECTURE APPLICATIVE
Elle se compose de trois couches conformément au modèle d’application 3-tiers puisque cette
architecture est développée en Java/JEE : la couche présentation, la couche application et la
couche de données :
 La couche présentation ; elle fournit les interfaces aux clients et administrateurs pour les
demandes en direction de l’autorité de certification et d’enregistrement ;

 La couche applicative ou couche métier : elle regroupe les fonctions de la PKI et comprend :

Les fonctions d’authentification, de gestion de vie des certificats, de journalisation, de publication

et de paramétrage de la PKI;

Elle fournit également un gestionnaire de clefs

 La couche de données : elle permet de stocker l’ensemble des données de la PKI dans une base
de données avec la possibilité de connecter un ou plusieurs annuaires LDAP bases de données
pour abriter les données publiques de la PKI ;

Elle est représentée par la figure suivante :

2.1 CARACTERISTIQUES
EJBCA est conforme aux standards. Il est compatible avec les spécifications de l’IETF
notamment sur les certificats numériques (X.509V3) et CRLV2 ainsi que PKCS et SCEP

40
(Simple Certificate Enrollment Protocol). Il intègre le protocole CMP (Certificate Management
Protocole) pour l’interopérabilité avec les autres solutions de PKI.
EJBCA est aussi indépendant des systèmes d’exploitation, des bases de données et des serveurs
d’application.
 Il peut être déployé sur les systèmes d’exploitation Microsoft, Unix ou Linux, Solaris ;

 Il est compatible avec les serveurs d’application tels que JBOSS, GLASSFISH, JONAS,
WEBSPHERE, WEBLOGIC ;

 Les bases de données suivantes sont supportées : Oracle, MySQL PostgreSQL, Sybase,
Informix, SQL Server, DB2 ;

 Il permet l’utilisation de modules HSM (Hardware Security Module) pour la protection des clefs
cryptographiques. Les produits utilisés sont : nCipher, Utimaco, Safenet, AEP Network.

2.2 INSTALLATION DETAILLEE ET PRESENTATION

Nous avons effectué l’installation sur un serveur Ubuntu 12.04 LTS (Long Term Support) qui a
nous a permis de générer les certificats pour notre serveur SSL et pour le chiffrement de données
et leur signature. Pour cela nous avons mis en place la topologie suivante :

41
Les différentes étapes et les captures d’écran y correspondant :
Il faut télécharger les logiciels suivants : openjdk, jboss, ejbca en utilisant les commandes
suivantes : apt-get install openjdk-6-jdk

Téléchargement jboss-5 par la commande :

sudo wget http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-
jdk6.zip

Téléchargement d’ejbca par la commande :

sudo wget http://www.sourceforge.net/ejbca/files/ejbca4/ejbca_4_0_10/ejbca_4_0_10.zip

42
43
Après téléchargement, il faut extraire les fichiers qui sont au format .zip avec la commande unzip
et placer les fichiers obtenus, à savoir ejbca_4_0_10 et jboss-5.1.0, dans un même répertoire
d’installation :
Effectuer la commande suivante après avoir extrait les deux fichiers :
echo ‘’ appserver.home = /home/oumarlog/jboss-5.1.0.GA’’ >>
ejbca_4_0_10/conf/ejbca.properties.
A noter que /home/oumarlog est le répertoire de l’utilisateur.
On se déplace sur le répertoire ejbca_4_0_10 et on exécute la commande suivante :
ant bootstrap. On obtient la capture suivante :

44
On ouvre un autre terminal, et on se place dans le répertoire bin de jboss-5.1.0 (cd /jboss-
5.1.0/bin) on tape la commande suivante : ./run.sh pour lancer le serveur d’application jboss

Une fois le serveur jboss lancé on retourne sur l’autre console (ejbca) pour lancer l’installation
d’ejbca avec la commande : ant install. C’est pendant cette étape que seront demandées les
informations sur les caractéristiques du serveur pour la création d’un certificat. Nous avons
conservé les données fournies par défaut.

45
46
47
Dans ce même terminal on effectue le déploiement d’ejbca par la commande : ant deploy
Puis on se rend sur l’autre terminal (jboss) pour arrêter le serveur avec ctrl+c et le redémarrer
avec ./run.sh.

48
La dernière étape consiste à copier le certificat superadmin.p12 stocké dans le répertoire p12 crée
lors de l’installation d’ejbca et de l’importer dans le navigateur web utilisé.
Pour vérifier que notre installation fonctionne correctement, nous ouvrons une page web avec
comme url : https://localhost:8443/ejbca, nous recevons un avertissement de la part du serveur :

En cliquant sur confirmer l’exception de sécurité, on accède à l’interface web de notre

infrastructure de gestion de clefs :

En cliquant sur ‘’Administration’’, on accède à la page d’administration.

49
Nous passons à la présentation de l’interface graphique de l’infrastructure de gestion de clefs
EJBCA.
L’interface d’administration est composée de trois grandes parties qui sont : l’autorité de
certification, l’autorité d’enregistrement et de supervision.
Fonctions d’autorité de certification
Ce menu regroupe un ensemble de sous menus liés aux fonctionnalités de base d’une autorité de
certification : la gestion des certificats d’autorité de certifications émises au sein d’EJBCA. Les
principales fonctions de l’autorité de certification sont :
Création et édition des certificats d’autorité ;

Création et édition des profils de certificats ;

Affichage et récupération des certificats d’autorité de certification et la génération des listes de

certificats révoqués ;

Génération des LCR (liste de certificats révoqués).

Les fonctions de base

Cette partie nous donne les informations sur les listes de certificats révoqués et les autorités de
certification qui sont actives. Les fonctionnalités offertes sont les suivantes :
La récupération des certificats d’autorité de certification sous plusieurs formats ;

La récupération des listes des certificats révoqués ;

50
La visualisation des informations sur les autorités de certification et leur certificat

La génération des listes de certificats révoqués de manière manuelle ;

La date de génération des listes de certificats révoqués et le nombre émis.

Les profils de certificats

Dans EJBCA on distingue deux types de profils :
Les profils, de certificats qui permettent de définir le contenu des certificats par rapport à la norme
X.509 ;

Les profils d’entité qui permettent de définir les informations liées au propriétaire du certificat.

Dès la première installation d’EJBCA, il y a un certain nombre de profils de certificats qui sont
marqués (FIXED) qui ne peuvent être ni modifiés ni supprimés.
La gestion des profils de certificats
Le processus se déroule en deux étapes :
La création d’un profil ;

La définition de ce profil.

Le service de publication
C’est un ensemble de fonctions permettant de créer et de paramétrer des services de publication
pour l’infrastructure de gestion de clefs. C’est un service de dépôt pour les données qui sont
considérées comme publiques par exemple les certificats émis par une autorité de certification et
les listes des certificats révoqués. Les types d’annuaire qui peuvent être publiés par défaut sont :
LDAP v3 et Active Directory de Microsoft.
Editer et créer les autorités de certification
Les autorités de certification sont créées et éditées à partir de cette rubrique. Une autorité de
certification peut être créée de plusieurs façons :
L’infrastructure génère le couple de clefs (publique, privée) et le certificat de la future autorité de
certification ;

Le certificat et le couple de clefs(publique, privée) sont importés depuis un fichier externe ;

Une requête de certificat est générée depuis EJBCA et est exportée pour être signée par une
autorité externe.

51
Les fonctions d’autorité d’enregistrement
Elles regroupent un ensemble de sous menus liés aux fonctionnalités de base d’une autorité
d’enregistrement c'est-à-dire la gestion des requêtes et des certificats émis au sein d’EJBCA. Pour
accéder aux fonctions d’autorité d’enregistrement, il faut se connecter en tant qu’administrateur
possédant les droits d’accès à l’autorité d’enregistrement. Cette partie de l’interface est composée
de :
Gestion des données externes

Ajouter une demande d’identité ;

Lister et éditer les identités.

Les fonctions de supervision

Ce menu est constitué de sous-menus lié aux fonctionnalités ne relevant ni de l’Autorité de
certification ni de l’autorité d’enregistrement. Pour y accéder, il faut avoir les droits d’accès aux
fonctions de supervision. Les fonctionnalités qu’on y retrouve sont : la gestion des requêtes, la
gestion des journaux et la configuration des rapports.
Les fonctions système
Pour avoir accès aux fonctions systèmes, il faut avoir les droits nécessaires pour se connecter à
EJBCA en tant qu’administrateur possédant les droits d’accès aux fonctions systèmes. Ce menu
comprend les fonctionnalités suivantes :
Configuration du système : cette page permet de modifier des paramètres spécifiques à
l’infrastructure de gestion de clefs par exemple : l’activation du recouvrement de clefs, la
production de tokens matériels : ce champ permet la mise en place d’un système de génération de
demandes de certificats associés avec des tokens matériels (carte à puce, clef USB
cryptographique) ;

Configuration de services ;

Gestion des administrateurs ce menu permet d’éditer et de créer des groupes d’administrateur
pour la gestion d’EJBCA. Un administrateur peut avoir les droits sur un ensemble de fonctions
(Autorité de certification, autorité d’enregistrement, supervision), à des pages précises, à des
autorités de certification précises. Dans EJBCA, nous disposons d’un certain nombre de rôles
prédéfinis qui sont :

L’administrateur de l’autorité de certification (CA administrator) qui est chargé de gérer :

 Les profils de certificats ;

52
 Les profils d’entités finales ;

 Les configurations des connexions (log) ;

 La création des administrateurs d’autorité d’enregistrement ;

 Le renouvellement d’une autorité de certification avec un nouveau certificat et une nouvelle

paire de clefs

L’administrateur de l’autorité d’enregistrement (RA Administrator) chargé de gérer :

 La création d’entités finales ;

 La modification d’entités finales ;

 La révocation d’entités finales ;

 La suppression d’entités finales ;

 La visualisation des entités existantes et leur historique ;

Le superviseur (supervisor) qui est chargé de gérer;

 La visualisation d’entités créées ;

 Consulter le fichier log et vérifier quelles actions ont été exécutées ;

Le super administrateur (super administrator) a tous les droits :

 Il a accès à l’ensemble de l’infrastructure de gestion de clefs ;

 Il peut éditer le menu configuration du système ;

 Il peut gérer les autorités de certification ;

 Il peut gérer aussi les dépôts de publication ;

 Il peut créer les administrateurs d’autorité de certification.

53
Part III.
54
55