PKI

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
MINISTERE DE LA POSTE ET DES TECHNOLOGIESDE
L’INFORMATIONET DE LA COMMUNICATION
INSTITUT NATIONAL DE LA POSTE ET DES TECHNOLOGIES DE L ’INFORMATION
ET DE LA COMMUNICATION
Domaine : Sciences et Technologies
Filière : Génie Electrique
Mémoire de Projet de Fin d’Études pour l’obtention
du diplôme de Licence
Spécialité : Télécommunications et Réseaux Informatiques
Réalisé et présenté par :
SAMMA Houssameddine
Soutenu, le : ../06 /2017, devant le jury composé de :
Mme. BOUTALEB N Maitre Assistante INPTIC Président
M. BARKATI Enseignant INPTIC Examinateur
M. ZOUGAR Abdellah Ingénieur Algérie Télécom Encadreur
M. DAHMANI Riadh enseignant INPTIC Co-encadreur
Année Universitaire : 2016-2017
Conception et implémentation d'une solution d’authentification
forte « PKI », afin de renforcer la politique de contrôle d'accès
d’Algérie Télécom.
Thème

Dédicaces
A la lumière de mes jours, la source de mes efforts, la flamme de
mon cœur, ma vie et mon bonheur, maman que j’adore.
A mon exemple éternel, mon soutien moral et source de joie et de
bonheur, celui qui s’est toujours sacrifié pour me voir réussir, que
Dieu te Garde, à toi mon père.
Aux personnes dont j’ai bien aimé la présence dans ce jour.
À tous mes frères, mes sœurs et toute ma famille, je dédie ce travail
dont le grand plaisir leur revient en premier lieu pour leurs
conseils, aides, et encouragements.
A mes amies Ali Slimane et Souhaib,
Aux personnes qui m’ont toujours aidé et encouragé, qui étaient
toujours à mes côtés, et qui m’ont accompagné durant mon chemin
d’études supérieures, mes aimables amis et frères.
Sans oublier HAMICHE Islam et Bouannane,
Houssameddine.

Remerciements
Je remercie Allah le tout puissant. C’est grâce à lui que j’ai eu la foi et la force pour accomplir
ce travail.
Je tiens à exprimer mes sincères gratitudes et respects à mes encadreurs Mr DAHMANI
Riad, et Mr ZOUGAR Abdellah, pour leurs encouragements et les précieux conseils qu'ils n'ont
cessés de nous prodiguer tout au long de ce projet.
Je tiens à remercier très chaleureusement l’ensemble des membres du jury qui ont accepté de
juger ce travail.
Mes sincères remerciements iront aussi à tous mes enseignants pour la qualité de l'enseignement
qu'ils ont bien voulu nous prodiguer durant nos études.
Je ne manquerai pas de saluer tous ceux qui ont de près ou de loin participé à l'accomplissement
de ce travail.
Du fond du cœur, merci.
Houssameddine

Table des matières
Table des matières
Introduction générale..........................................................................................................................................1
Chapitre I : Etat de l’art de l’authentification forte
Introduction ............................................................................................................................................................2
I.1. Généralités sur la sécurité des réseaux informatiques ...................................................................2
I.1.1. Définition de la cryptologie..............................................................................................................2
I.1.2. Objectif de la cryptographie .............................................................................................................2
I.1.3. Cryptographie a clés symétriques et asymétriques ....................................................................3
I.1.3.1. Algorithme à clé symétrique (clé secrète)...........................................................................3
I.1.3.2. Algorithme à clé asymétrique (à clé publique)..................................................................3
I.1.3.3. Inconvénient de la cryptographie asymétrique ..................................................................4
I.1.4. Chiffrement à sens unique hachage (empreinte) ........................................................................5
I.1.4.1. MD5................................................................................................................................................5
I.1.4.2. SHA-1............................................................................................................................................5
I.1.5. Chiffrement hybride............................................................................................................................5
I.2. Sécurité et gestion des accès......................................................................................................................6
I.2.1. Principes généraux du contrôle d’accès ........................................................................................6
I.2.2. Authentification forte .........................................................................................................................7
I.2.3. Systèmes d’authentification forte....................................................................................................8
I.2.3.1. OTP.................................................................................................................................................8
I.2.3.2. Authentification biométrique ..................................................................................................8
I.2.3.3. Authentification PKI................................................................................................................10
Conclusion.............................................................................................................................................................. 10
Chapitre II : Infrastructure à clé publique
Introduction .......................................................................................................................................................... 11
II.1. Définition de la PKI..................................................................................................................................11
II.2. Composants du PKI .................................................................................................................................11
II.2.1. Autorité de Certification ................................................................................................................12
II.2.1.1. Architecture logique d'une AC............................................................................................13
II.2.1.2. Opérations effectuées par l’Autorité de Certification ..................................................14
II.2.2. Autorité d'enregistrement RA.......................................................................................................14
II.2.3. Autorité de Dépôt (Repository)....................................................................................................15
II.3. Certificat électronique............................................................................................................................. 16
II.3.1. Types de certificats..........................................................................................................................16
II.3.2. Supports de certificat ......................................................................................................................17
II.3.3. Cycle de vie d'un certificat............................................................................................................17

Table des matières
II.3.4. Caractéristiques d’un certificat.....................................................................................................18
II.4. Politique de sécurité .................................................................................................................................18
II.4.1. Rapport pratique de certification CPS........................................................................................19
II.4.2. Politique de certificat CP ...............................................................................................................19
II.5. Projection du PKI dans domaine sécurité.......................................................................................19
II.5.1. Authentification................................................................................................................................19
II.5.2. Authentification asymétrique........................................................................................................20
II.5.2.1. Signature numérique ..............................................................................................................20
II.5.2.2. Signature par clé privée.........................................................................................................20
II.5.2.3. Signature par fonction de hachage et clé publique........................................................20
II.6. Etude d’un cas d’authentification SSL............................................................................................. 21
Conclusion.............................................................................................................................................................. 22
Chapitre III : Mise en œuvre et application
Introduction .......................................................................................................................................................... 23
III.1. Proposition d’un système d’authentification forte.....................................................................23
III.1.1. Architecture de l’entreprise .........................................................................................................23
III.1.2. Description de l’architecture de la solution ............................................................................24
III.1.3. Présentation de l’environnement de travail.............................................................................25
III.2. Mise en place d’AC racine...................................................................................................................25
III.2.1. Installation du rôle AD CS...........................................................................................................25
III.2.2. Configuration du rôle AD CS .....................................................................................................25
III.2.3. Configuration du CRL...................................................................................................................27
III.3. Installation d’AC Secondaire..............................................................................................................28
III.3.1. Configuration d’AC Secondaire.................................................................................................28
III.3.2. Activation d’AC Secondaire .......................................................................................................29
III.5. Configuration de serveur web Apache............................................................................................ 30
III.6. Authentification de l’utilisateur.........................................................................................................33
Conclusion.............................................................................................................................................................. 34
Conclusion Générale..........................................................................................................................................35
Références bibliographique
Annexes

Liste des figures et des tableaux
Liste des figures et des tableaux
Chapitre I : Etat de l’art de l’authentification forte
Figure.I.1.Chiffrement à clé asymétrique........................................................................................4
Figure.I.2.Fonction de hachage.......................................................................................................5
Figure.I.3.Chiffrement hybride .......................................................................................................6
Figure.I.4.Contrôle d’accès aux ressources.....................................................................................7
Figure.I.5.Mécanisme de l’OTP......................................................................................................8
Figure.I.6.Authentification par l’empreinte digitale .......................................................................9
Figure.I.7.Authentification par visage.............................................................................................9
Figure.I.8.Authentification par la voix............................................................................................9
Chapitre II : Infrastructure à clé publique
Figure.II.1.Architecture d’une PKI ...............................................................................................12
Figure.II.2.Modèle hiérarchique....................................................................................................13
Figure.II.3.Cycle de vie d'un certificat..........................................................................................18
Figure.II.4.Authentification avec certificat x.509.........................................................................21
Chapitre III : Mise en œuvre et application
Figure.III.1.Architecture de l’entreprise .......................................................................................23
Figure.III.2.Déploiement de PKI dans l’entreprise.......................................................................24
Figure.III.3.Installation de rôle AD CS.........................................................................................25
Figure.III.4.Configuration d’AC racine ........................................................................................26
Figure.III.5.Configuration d’options de chiffrement et la période de validité..............................26
Figure.III.6.Configuration de CRL et AIA ...................................................................................27
Figure.III.7.Publication de liste de révocation ..............................................................................27
Figure.III.8.Configuration d’AC Secondaire ................................................................................28
Figure.III.9.Signature de certificat d’AC Secondaire. ..................................................................29
Figure.III.10.Déliverence de certificat d’AC Secondaire .............................................................29
Figure.III.11.Installation de certificat d’AC Secondaire...............................................................29
Figure.III.12.Requête de signature de certificat du site server.alg.tlcm........................................30
Figure.III.13.Signature de la CSR.................................................................................................31
Figure.III.14.Telechargement de certificat....................................................................................31
Figure.III.15.Configuration de serveur apache .............................................................................32
Figure.III.16.Connexion réussie au site https://server.alg.tlcm.....................................................32
Figure.III.17.Inscription de certificat d’utilisateur........................................................................33
Figure.III.18.Authentification par certificat..................................................................................34
Liste des tableaux
Tableau.II.1.Caractéristiques d’un certificat X.509 ......................................................................18

Liste des abréviations
A
AES : Advanced Encryption Standard
AC : Autorité de Certification.
AE : Autorité d’enregistrement
ACTEL : Agence Commerciale de
Télécommunication
AD CS: Active Directory Certificate
Service
AIA: Authority information access
AD: Active directory
C
CA: Certificat Autorité
CSR: certificate-signing request
CPS: Certification Practice Statement
CP: Certificate Policy
CDP: Crl Distribution Points
CRL: Certificate Revocation List
CSR: Certificate Signing Request
CPU: Central Processing Unit
D
DNS: Domain Name System
DES: Data Encryption Standard
DH: Diffie-Hellman
DO: direction opérationnel
DER: Distinguished Encoding Rules
E
EE: entité d’extrémité
EAP-TLS: Extensible Authentication
Protocol-Transport Layer Security
F
FTP: File Transfert Protocol
G
GPO: Group Policy Object
H
HTTPS: Hypertext Transfer Protocol
Secure
I
ICP : Infrastructure à Clés Publiques
IEEE: Institute of Electrical and Electronics
Engineers
L
LDAP: Lightweight Directory Access
Protocol
M
MD5: Message Digest 5
O
OTP: one-time password
OCSP : Online Certificate Status Protocol
P
PKI : Public Key Infrastructure
POP : preuve de possession
PKCS#12: Public Key Cryptography
Standard
R
RA : Registration Authority
RSA : Algorithme de cryptographie
asymétrique

S
SSL: Secure Socket Layer
SHA1: Secure Hash Algorithm
T
TLS : Transport layer Secure
U
UIT : Union international des
Télécommunications
URL: Uniform Resource Locator
USB: Universal Serial Bus

Introduction générale
1
Introduction générale
La sécurité est un enjeu majeur des technologies numériques modernes. Avec le
développement de l'Internet, les besoins de sécurité sont de plus en plus importants. En effet, les
besoins tels que, l’identification et l’authentification des entités communicantes, l’intégrité des
messages échangés, la confidentialité des transactions, etc., liées à la sécurité des communications
sont à satisfaire.
La cryptographie moderne permet la mise en œuvre de ces services de sécurité grâce à
différents mécanismes tels que le chiffrement et la signature électronique. Plusieurs de ces
mécanismes sont basés sur des algorithmes cryptographiques asymétriques dits « à clé publique ».
Bien que très efficace, la cryptographie à clé publique comporte cependant un enjeu majeur ; qui
consiste à la gestion des clés publiques. En effet, l’efficacité de ce mécanisme de sécurité dépend
du niveau de certitude que détient l’utilisateur d’une clé publique quant à l’identité de son
propriétaire légitime.
La problématique que rencontrent plusieurs grandes entreprises, c’est comment assurer la
sécurité des transactions entre les différentes entités, filières et partenaires à travers le réseau
interne ou externe ? Et Comment assurer une authentification et un accès sûr aux ressources de
l’entreprise ? Et comment assurer l’intégrité, et la non- répudiation des échanges établis ?
Dans ce contexte l’objectif de ce projet est de Concevoir et implémenter une solution
d’authentification forte PKI (Public Key Infrastructure), afin de renforcer la politique de contrôle
d’accès d’Algérie Télécom. il s’agit de mettre en place une plateforme infrastructure clé publique
pour assurer l’identification et l’authentification forte des utilisateurs du système d’information
d’Algérie Télécom, et protéger l’accès aux services métiers de l’entreprise à travers des certificats
numériques.
Ce document est structuré en trois chapitres présenté comme suit :
 Dans le premier chapitre, on décrit Un état de l’art des systèmes d’authentification forte.
 Le deuxième chapitre pour la proposition d’une approche de mise en œuvre d‘un système
d’authentification forte.
 Le troisième et dernier chapitre de ce mémoire est l’implémentation de la solution
d’authentification forte.

Chapitre I
Etat de l’art de
l’authentification forte

Chapitre I Etat de l’art de l’authentification forte
2
Introduction
Le système d’information est généralement défini par l’ensemble des données et des
ressources matérielle et logicielles de l’entreprise permettant de les stocker ou les faire. C’est un
patrimoine essentiel de l’entreprise. Il s’avère donc nécessaire d’accompagner la mise en place
d’un système d’information dans l’entreprise par mesures ou mécanismes de sécurité permettant
d’en protéger les ressources.
Nous verrons dans ce chapitre les concepts généraux de la sécurité informatique, et les
différents algorithmes utilisés dans la sécurité des transactions de données à travers le réseau.
I.1. Généralités sur la sécurité des réseaux informatiques
I.1.1. Définition de la cryptologie
La cryptologie est une science de chiffrement, englobant la cryptographie et la
cryptanalyse. Elle a pour objet les écrits secrets et leur étude. Elle permet de cacher des
informations, d'assurer la confidentialité des messages et de garantir leur authenticité.
Cryptographie : La Cryptographie c’est la transmission des messages ou des données de façon
confidentielle et secrète, en utilisant des techniques et des fonctions mathématiques nommées
algorithme cryptographique qui dépend d'un paramètre appelé clé.
Cryptanalyse : La Cryptanalyse c’est l’inverse de la cryptographie, et ensemble des techniques
mises en œuvre pour déchiffrer un message codé.
I.1.2. Objectif de la cryptographie
Pour assurer la sécurité dans le transfert de données, la cryptographie dans les applications
téléinformatiques doit garantir la sécurité à quatre niveaux :
 Confidentialité : La confidentialité des données garantit que seul le destinataire peut lire
le message.
 Authentification : L'authentification a pour objectif de vérifier l’identité des processus
communicants, et garantit que le message vient bien de la personne de qui il déclare venir.
 Intégrité : L'intégrité des données garantit que les messages ne sont pas modifiés durant
le transfert, et le récepteur peut vérifier que le message reçu est identique au message
envoyé et qu'aucune manipulation ne s'est produite.
 Non-répudiation : La non-répudiation des données est un service similaire qui permet à
l'expéditeur d'un message d’être identifié de façon unique.

3
I.1.3. Cryptographie a clés symétriques et asymétriques
Nous distinguons deux types de cryptographie symétrique et asymétrique.
I.1.3.1. Algorithme à clé symétrique (clé secrète)
Le principe de la cryptographie symétrique repose sur l’utilisation d’une seule clé secrète
appelée clé privée pour chiffrer et déchiffrer, elle permet d’assurer la confidentialité des données
ainsi que leur authentification du faite que seules les personnes possédant la clé peuvent chiffrer
et déchiffrer un message. Cependant son plus grand avantage repose sur sa rapidité et la facilité
dans sa mise en œuvre sur les circuits (bon marché).
D’autre part, si une personne malicieuse prend part de cette clé alors tout devient à
découvert, il devient possible pour cette personne de déchiffrer le message et de le modifier. Par
ailleurs le plus grand inconvénient est d’avoir toujours des problèmes dans la gestion des clés
quand on a un nombre d’utilisateurs élargi, en effet, il faudrait au moins une clé privée pour chaque
couple d’utilisateurs, ainsi on se retrouve dans le problème de partage et de distribution des clés.
 DES (Data Encryption Standard) : est un algorithme de chiffrements par bloc de 64 bits
(clé : 56 bits + redondance : 8bits) ce qui nous donne 256 possibilités. C’est un algorithme
robuste et bien conçu, il a résisté à toutes les attaques [2].
 3DES : utilisé 3clés, ce qui nous donne une clé effective de 168 bits (56*3). Ce système
est suffisamment robuste pour la plupart des transactions bancaire. Mais vu le nombre de
traitement, il nécessite des ressource système important, une grande capacité mémoire, son
exécution ralentirais la communication. Il est généralement utilisé serveurs et les stations
de travail.
 AES (Advanced Encryption Standard) : « standard de chiffrement avancé », il s’agit d’un
algorithme de chiffrement symétrique, il prend en entrée un bloc de 128 bits (16 octet), la
clé fait 128, 192 ou 256 bits.
I.1.3.2. Algorithme à clé asymétrique (à clé publique)
Afin de résoudre les principaux inconvénients de cryptographie symétrique qui consiste
dans la gestion des clés, une nouvelle technique cryptographique a été mise en place c’est la
Cryptographie Asymétrique à base de clé publique. Le principe de cryptographie asymétrique
repose sur l’utilisation de deux clés déférentes, l’une est publique et l’autre est privée. La clé
publique est utilisée pour le chiffrement et peut être publiée librement, tandis que la clé privée est
destinée pour le déchiffrement, elle doit être impérativement secrète et cachée.
La figureI.1 montre le fonctionnement de chiffrement à clés asymétrique [1].

4
Figure.I.1.Chiffrement à clé asymétrique
Puisque la clé publique sert au chiffrement, alors tous les utilisateurs peuvent chiffrer un
message que seul le propriétaire de la clé privée pourra déchiffrer, on assure ainsi la
Confidentialité, puisque les clés de chiffrement et de déchiffrement sont distinctes et ne peuvent
Se déduire l’une de l’autre [3].
 RSA (Algorithme de Cryptographie Asymétrique) : Pour générer les deux clés, il s’agit
de choisir deux nombres premiers p et q. et un nombre e n’ayant pas de facteur commun
avec q-1 et p-1, n=p*q est partagé et l’expéditeur calcule (M : message). Cet algorithme
assurer la sécurité des transactions sensibles. Il est recommandé d’avoir recours à des clés
de 1024 bits pour les applications normales et 2048 bits pour les applications les plus
critiques.
 DH (Diffie-Hellman) : est un protocole de cryptographie asymétrique qui permet à deux
parties qui n'ont aucune connaissance préalable de l'autre d’établir conjointement une clé
secrète partagée sur un canal de communication non-sécurisé qui utilise un chiffrement des
clés de 512, 1024 ou 2048 bits [4].
I.1.3.3. Inconvénient de la cryptographie asymétrique
En contrepartie de leurs propriétés spécifiques, les chiffrements asymétriques sont
globalement moins performants que leurs équivalents symétriques ; les temps de traitement sont
plus longs, et pour un niveau de sécurité équivalent ; les clés doivent être beaucoup plus longues.
Ils tendent à être environ 1000 fois plus lents. Autrement dit, il va falloir plus de 1000 fois plus de
temps de CPU (Central Processing Unit) pour traiter un cryptage ou décryptage asymétrique que
symétrique. Si le chiffrement asymétrique permet de se prémunir des écoutes passives, la
transmission initiale de la clé publique sur un canal non sécurisé exposé à des attaques de l'homme
du milieu. Pour se prémunir contre ce risque on fait généralement appel à une infrastructure à clés
publiques.

5
I.1.4. Chiffrement à sens unique hachage (empreinte)
Une fonction à sens unique est une fonction facile à calculer mais difficile à inverser. La
Cryptographie à clé publique repose sur l’utilisation de fonctions à sens unique à brèche secrète
celui qui connait le secret, la fonction devient facile à inverser.
Le hachage est l’une des fonctions qui utilise le chiffrement à sens unique qui convertit une
chaine de caractères à une chaine de caractère à longueur fixe souvent taille inferieur, le résultat
d’une fonction de hachage est appelé une empreinte, cette empreinte est unique et pas redondante,
car il est rare de trouver deux empreintes similaires. Les fonctions de hachages sont souvent
utilisées pour assurer l’intégralité et l'authentification de l’origine des documents envoyés [6]. La
figure.I.2 illustre le fonctionnement de hachage.
Figure.I.2.Fonction de hachage
I.1.4.1. MD5
C’est l’un des algorithmes de hachage les plus utilisés. Il divise un texte en plusieurs mots
de 512 bits chacun pour en déduire un mot de 128bits. Ces 128bits sont calculés en blocs de 32bits
par des permutations et des fonctions logiques. Malgré quelques failles découvertes dans le MD5
(Message Digest 5) mais il reste sécurisé et très performant [5].
I.1.4.2. SHA-1
Comme le MD5, il exécute une série d’itérations et de fonction logique pour en déduire un
mot de 160bits qui est l’ensemble de cinq mots de 32 bits.
I.1.5. Chiffrement hybride
Le chiffrement hybride est un système qui combine les deux branches de chiffrement
Symétrique et asymétrique, cela en utilisant le chiffrement à la clé publique du destinataire pour
Chiffrer la clé de session (privée).
La méthode de cet échange consiste à établir une communication entre deux individus
Alice et Bob. Alice génère une clé de session privée pour chiffrer le message envoyé, cette clé de

6
session sera chiffrée par la clé publique de Bob. Bob déchiffre le message à l’aide de sa clé Privée,
et connaît ainsi la clé de session commune. Alice chiffre ensuite le message avec la clé de session
connue par Bob qui pourra aisément le déchiffrer.
La figure.I.3 montre le fonctionnement de chiffrement hybride.
Figure.I.3.Chiffrement hybride
I.2. Sécurité et gestion des accès
Le contrôle d'accès à un système d'information, Consiste à vérifier si une entité (une
personne, un ordinateur…) demandant d’accéder à une ressource a les droits nécessaire pour le
faire. Pour accomplir ce contrôle, chaque entité essayant d’obtenir un accès doit d’abord être
authentifiée, de telle sorte que les droits d’accès correspondants.
I.2.1. Principes généraux du contrôle d’accès
Un mécanisme de contrôle d’accès logique aux ressources informatiques est basé sur
l’identification des personnes, leur authentification et sur les permissions ou droits d’accès qui leur
sont accordés.
Le profil de l’usager regroupe toutes les informations nécessaires aux décisions
d’autorisation d’accès. Il doit être défini avec soin et résulte de la définition de la politique de
gestion des accès. Comme illustre la figure.I.4.

7
Figure.I.4.Contrôle d’accès aux ressources
Pour autoriser un usager à utiliser un service demandé, le système de contrôle d’accès
procède à une vérification des droits de l’usager, en fonction de la cohérence du service sollicité,
de l’équipement, de la date et de l’heure de la demande. Le contrôle de cohérence revient à
comparer le profil du service avec celui de l’utilisateur et du système à partir duquel la requête est
émise.
L’autorisation est accordée quand l’usager possède des droits sur le service et que les
besoins en équipement terminal d’accès et en composants logiciels indispensables au service sont
supportés.
Insistons sur le fait que les solutions de sécurité ont aussi besoin d’être protégées et
sécurisées afin qu’elles puissent offrir un certain niveau de sécurité (notion de récursivité de la
sécurité). Ainsi, la sécurité informatique est obtenue par une succession de barrières (des mesures
de sécurité) qui augmentent le niveau de difficulté que de potentiels attaquants doivent franchir
pour accéder aux ressources, peut contribuer à réaliser une sécurité en profondeur.
I.2.2. Authentification forte
L'authentification est la vérification d’informations relatives à une personne ou à un
processus informatique. Le processus d'authentification compare les informations d'identification
fournies par des utilisateurs autorisés avec les informations enregistrées dans une base de données
stockée sur le système d'exploitation local ou dans un serveur d'authentification. Si les
informations sont identiques, le processus aboutit et l'utilisateur se voit autoriser l'accès [w1].
L’authentification peut se faire de multiples manières, et notamment par la vérification de :
 Quelque chose que l’utilisateur connaît (mot de passe, question secrète, etc.) ;
 Quelque chose que l’utilisateur possède (carte, etc.) ;
 Quelque chose que l’utilisateur est (biométrie).
La combinaison de plusieurs de ces méthodes (aussi appelées facteurs d’authentification)
permet de renforcer le processus d’authentification, on parle alors d’authentification forte [w2].

8
I.2.3. Systèmes d’authentification forte
Il existe plusieurs systèmes d’authentification forte dans le domaine de la sécurité
informatique.
I.2.3.1. OTP
L’OTP (One-Time Password) permet de sécuriser l’utilisation du mot de passe sur le
réseau. En effet avec un système OTP, l’utilisateur possède un calculateur spécialisé qui lui fournit
à la demande un mot de passe. Ce mot de passe est valide pendant une durée limitée seulement, et
pour une seule utilisation. La figure I.5 illustre le mécanisme de l’OTP.
Figure.I.5.Mécanisme de l’OTP
Chaque utilisateur doit posséder une calculatrice spécifique et le mot de passe associé. Il
faut donc mettre en place les procédures de gestion des demandes utilisateurs suite à la perte ou
l’oubli d’une calculatrice ou à l’oubli d’un mot de passe [7].
I.2.3.2. Authentification biométrique
L’authentification biométrique est la vérification automatique de l’identité ou
l’identification basée sur les caractéristiques biologiques uniques de l'utilisateur, c'est-à-dire sur
ses attributs biométriques, les solutions biométriques proposées sont les reconnaissances de
l’empreinte, du visage, de la forme de la main, et beaucoup d’autres [w3].
 Empreinte digitale (finger-scan)
L'authentification de l'empreinte digitale est la mesure biométrique la plus employée dans
le monde, la donnée de base est le dessin représenté par les crêtes et sillons de l'épiderme. Ce
dessin est unique et différent pour chaque individu. La figure I.6 montre l’authentification par
l’empreinte digitale.

9
Figure.I.6.Authentification par l’empreinte digitale
 visage (facial-scan)
Il s'agit ici de faire une photographie plus ou moins évoluée pour en extraire un ensemble
de facteurs qui se veulent propres à chaque individu. Ces facteurs sont choisis pour leur forte
invariabilité et concernent des zones du visage tel que le haut des joues, les coins de la bouche,
etc... On évitera d'autre part les types de coiffures, les zones occupées par des cheveux, en général
ou toute zone sujette à modification durant la vie de la personne. La figure I.7 représente
l’authentification par visage.
Figure.I.7.Authentification par visage
 Biométrie vocale
La biométrie vocale permet d'authentifier vos clients à l'aide de leur empreinte vocale, leur
évitant ainsi toutes les contraintes liées aux codes confidentiels, mots de passe et autres questions
de sécurité. Elle garantit un niveau de sécurité optimal, tout en offrant aux appelants une
expérience inédite reposant sur le pouvoir de la parole [w4]. La figure I.8 montre l’authentification
par la voix.
Figure.I.8.Authentification par la voix

10
I.2.3.3. Authentification PKI
PKI est un système de gestion des clefs publiques qui permet de gérer des listes importantes
de clefs 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 d'échanges
d'information entre les différentes entités.
Le rôle de la PKI est de s'assurer qu'il est transmis et contrôlé à chaque accès à un service
nécessitant une authentification.
 Les PKI Microsoft sont très performantes :
 Cryptographie asymétrique ;
 Démarrages à longueur clé de 1024 bit ;
 Peut accueillir (héberger) les identités dans Cartes à puce ;
 Assurer tous les mécanismes de sécurité (Authenticité, Intégrité, Confidentialité
Non Répudiation).
 Les PKI Microsoft sont très flexibles :
 Simple à implémenter : dans la majorité des entreprises l’architecture déployée est
l’Active Directory Microsoft Windows Server, donc le déploiement d’une
architecture PKI Microsoft tirera profit des investissements techniques et matériels
liés à l’infrastructure Active Directory.
Conclusion
L’authentification forte est devenue un essentiel pour les différents services de l’entreprise
ainsi que pour augmenter la sécurisation de l’authentification de l’utilisateur.
Nous abordant dans le chapitre suivant l’architecture et l’importance de l’utilisation du
l’infrastructure à clé publique PKI.

Chapitre II
Infrastructure à Clé
Publique

Chapitre II infrastructure à clé publique
11
Introduction
Le monde numérique qui est repose sur le concept de sécurité des systèmes d’informations
recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources et les
échanges. Dans ce chapitre, nous allons découvrir une des méthodes utilisées pour améliorer la
sécurité appelée PKI, aussi nous allons présenter une définition sur la PKI, les différentes méthodes
qui assurent la transaction des données d'une manière confidentielle et authentique, et les certificats
qui garantissent leur sécurité
II.1. Définition de la 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.
II.2. Composants du PKI
Les PKI se compose de (04) quatre entités distinctes :
 AC (Autorité de Certification) qui a pour mission de signer les demandes de certificat
CSR (Certificate Signing Request) et de signer les listes de révocation CRL (Certificate
Revocation List).
 L'Autorité d'Enregistrement RA (Registration Authority) qui a pour mission de générer
les certificats, et d'effectuer les vérifications d'usage sur l'identité de l'utilisateur final.
 L’Autorité de Dépôt (Repository) qui a pour mission de stocker les certificats
numériques ainsi que les listes de révocation.
 L'Entité Finale EE (Entité d’Extrémité) : L’utilisateur ou le système qui est le sujet d’un
certificat.
La figure II.1 illustre l’architecture d’une PKI.

12
Figure.II.1.Architecture d’une PKI
II.2.1. Autorité de Certification
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.

13
II.2.1.1. 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.
 Le modèle hiérarchique
Une autorité centralisée pourra déléguer ses pouvoirs de certification à des serveurs
intermédiaires qui, eux-mêmes, les céderont à d’autres autorités jusqu’à un serveur de
certification terminal qui délivrera les certificats aux particuliers. Ainsi, se crée, une hiérarchie de
certification dans laquelle chaque niveau accrédite un niveau inférieur. Dans ce cas en parle de
Co-certification. Le point central est le serveur racine (AC racine) qui doit distribuer sa clé
publique à tous. Cette racine est le point de convergence de toutes les vérifications de certificats,
c’est l’ancre de confiance.
La figure II.2 montre le modèle hiérarchique.
Figure.II.2.Modèle hiérarchique
Une chaîne de certification est l'ensemble des Certificats nécessaires pour valider la
généalogie d'un certificat d'un porteur de certificat. Ainsi la valeur pathlen du champ Basic doit
être égal au nombre d’AC, dans ce cas il doit contenir la valeur 3.
Il y a aussi plusieurs types du modèle comme le modèle trust list Le modèle maillé.

14
II.2.1.2. Opérations effectuées par l’Autorité de Certification
 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.
 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.
 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é.
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).
Les répondeurs OCSP (Online Certificate Status Protocol) qui offrent des avantages
considérables par rapport aux CRL sont utilisés aussi pour répondre à cette fonction de révocation
(Voir l’annexe A).
II.2.2. 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é EE.

15
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 ;
 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),…).
II.2.3. 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.
 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

16
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.
II.3. Certificat électronique
Un certificat est un document électronique émis par un tiers de confiance ou AC, il est
utilisé principalement pour identifier une entité physique ou morale, mais aussi pour chiffrer
des échanges. Il assure un environnement de confiance aux utilisateurs pour échanger des
informations numériques et confidentielles.
Un certificat spécifie le nom d'une personne, serveur ou entité. Il certifie que la clé publique
incluse dans le certificat, lui appartient.
Les certificats donc sont des petits fichiers divisés en deux parties :
 Une partie contenant des informations,
 Une partie contenant la signature de l’AC.
Son intérêt est de garantir l'intégrité du contenu du message, s'assurer que les instructions
originales sont respectées et qu'elles ne seront pas modifiées lors de leur transmission.
La structure des certificats est normalisée par le standard X.509 de l'UIT(Union
International des Télécommunications) qui définit les informations contenues dans le certificat :
 Nom de l'autorité de certification ;
 Nom du propriétaire du certificat ;
 Date de validité du certificat ;
 Algorithme de chiffrement utilisé ;
 La clé publique du propriétaire.
II.3.1. Types de certificats
Il existe quatre types de certificats électroniques :
 Certificats de personne : Destiné aux personnes est semblable à une carte d'identité
nationale. Ce certificat peut être utilisé pour signer les messages électroniques et
l'authentifier lors d'une session sécurisée.
 Certificats serveur : Propre à un serveur (web, courrier...). Il assure la sécurité des
échanges entre le serveur et ses clients lors de l'établissement d'une session sécurisée.
 Certificat VPN : Permet à des informations dans certains nœuds du réseau (routeurs, Pare-
feu...) d'être associées à une clé publique. Ce certificat est utilisé pour garantir la sécurité

17
des échanges effectués entre une organisation et ses branches sécurisées dans le réseau de
communication.
 Certificat de signature de code : Cela permet à un programme, un script ou un
logiciel d'être signé pour garantir son authenticité par la signature de son développeur. Ce
type de certificat permet la protection contre les risques de piratage.
II.3.2. Supports de certificat
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
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.
II.3.3. Cycle de vie d'un certificat
 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.
La figure.II.3 résume toutes les étapes d’un cycle de vie de certificat.

18
Figure.II.3.Cycle de vie d'un certificat
II.3.4. Caractéristiques d’un certificat
Le standard de certificat X.509 est lancé en association avec la norme X.500. Il représente
un système d'autorité de certification pour la délivrance des certificats et la vérification des
signatures.
Version Ce champ identifie à quelle version de X.509 correspond ce
certificat.
Serial number Numéro de série du certificat (propre à chaque AC).
Signature Algorithm ID Désigne l'algorithme utilisé par l’AC pour signer le certificat, ainsi
que tous les paramètres de l'algorithme.
Issuer Name Permet d'identifier la AC qui a délivré le certificat. Il existe un formalisme
bien déni pour attribuer un nom à chaque entité sans ambigüité.
Validity period C’est une paire de date durant laquelle le certificat est valide.
Subject Name Identifie le détenteur de la clé publique.
Subject public key info Le nom de l’algorithme à clé publique (ex RSA), ainsi que tous les
paramètres concernent cette clé, et la clé proprement dite.
Issuer Unique
ID/Subject Unique Id
Extensions optionnelles introduites avec la version 2 de X.509.
Extensions Extensions génériques optionnelles, introduites avec la version 3de
X.509, Il permet aux autorités de certification de rajouter leurs
propres informations aux certificats qu'elles délivrent.
Signature Signatures numériques de l’AC sur l’ensemble des champs
précédents
Tableau.II.1.Caractéristiques d’un certificat X.509
II.4. 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

19
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).
II.4.1. Rapport pratique de certification CPS
Il s’agit d’un document légal créé et publié par l’AC, il spécifie les critères de certification
et la politique de révocation des certificats. Ce document sera jugé par les utilisateurs pour définir
le niveau de confiance qu’ils peuvent placer dans l’AC.
II.4.2. Politique de certificat CP
Une politique de certificat a pour but d’expliciter et de limiter l’utilisation du
certificat numérique. En d’autre terme, elle définit le niveau de confiance qu’un utilisateur peut
placer dans le certificat d’autrui. Ces indications peuvent être incluses à l’intérieur du certificat ou
indirectement référencée.
II.5. Projection du PKI dans domaine sécurité
II.5.1. Authentification
L’authentification est une identification entre l’expéditeur et le destinataire. S’identifier
c’est communiquer son identifiant, s’authentifier c’est apporter la preuve de son identité.
L'authentification d'un message est également possible dès lors que l'expéditeur utilise sa clé privée
pour chiffrer le message qu'il désire envoyer. Le destinataire utilisera la clé publique de
l’expéditeur pour déchiffrer le message qui sera ainsi authentifié.
Remarquant que bien que le message soit chiffré, il n'est pas confidentiel car n'importe qui
peut utiliser la clé publique de l'expéditeur pour en prendre connaissance, il n'est donc que signé
par le propriétaire de la clé privée. Le destinataire est alors confronté au problème qui consiste à
se convaincre de l'identité de l'utilisateur de la clé privée qui a servi à signer le message.
Les certificats numériques y apportent une réponse acceptable en associant une clé
publique et des informations permettant de déterminer l'identité d'une personne [w6].

20
II.5.2. Authentification asymétrique
Ce mode d’authentification se base sur l’utilisation de deux clés distinctes, une clé privée
et une clé publique.
II.5.2.1. Signature numérique
La signature électronique repose donc sur le principe de la cryptographie asymétrique. Une
signature doit convaincre le destinataire que le document a bien été réalisé par lui-même, pour
cela, elle doit être authentique et difficilement imitée.
En principe une signature ne devrait pas être réutilisable, elle devrait faire partie intégrante
du document, de plus un document signé ne peut plus être modifié, il est inaltérable.
Dans la réalité, on s’aperçoit que ces exigences sont en principe respectées, car il n’est pas
évident de copier une signature manuscrite, il n’en est pas de même pour des données
informatiques car la présence d’une signature sur un document ne représente rien, vu la facilité
avec laquelle un fichier peut être dupliqué et modifié.
II.5.2.2. Signature par clé privée
Chiffrer un document avec sa clé privée engendre une signature numérique sûre du
document, car seul le propriétaire de la clé privée a été capable de le chiffrer. Cette méthode est
efficace car elle respecte les contraintes énoncées précédemment, l’authenticité est respectée. La
signature est infalsifiable car c’est la clé privée qui la générée. La signature n’est pas réutilisable
car elle fait partie intégrante du document. Le document est immuable car la moindre falsification
sur le document provoquerait un non déchiffrage du document. L’algorithme à clé publique RSA
permet d’effectuer de telles signatures.
II.5.2.3. Signature par fonction de hachage et clé publique
Dans les applications pratiques, les algorithmes à clé publique sont souvent trop inefficaces
pour signer de longs documents. Pour gagner du temps, les protocoles de signatures numériques
sont souvent réalisés avec des fonctions de hachage à sens unique. Au lieu de signer le document,
on signe l’empreinte du document.
En résumé, l’émetteur hache le document qu’il désire envoyer, il obtient donc un code qui
est l’empreinte. À l’aide d’une fonction de hachage à sens unique, il chiffre cette dernière avec sa
clé privée, par la suite il envoie le document original et l’empreinte chiffrée.
Le destinataire hache lui-même le document original, déchiffre l’empreinte de l’émetteur
avec sa clé publique puis compare son empreinte avec celle qu’il a déchiffré, si les deux empreintes
sont identiques, c’est que l’identité de l’émetteur est correcte.

21
II.6. Etude d’un cas d’authentification SSL
L’objectif des certificats est de permettre l’identification des accès aux systèmes
d’information de l’entreprise, aux sites internet, intranet. Parade au phishing, sécurisant les accès
et les opérations sensibles pour les populations nomades, le certificat permet d’éviter les
usurpations d’identité.
Lors d’une négociation SSL (Secure Socket Layer), il faut s’assurer de l’identité de la
personne avec qui on communique (risque d’une attaque de type « Man In the Middle »).
Voici dans la figure.II.4 le fonctionnement d’une authentification SSL mutuelle lors de la
création d’une connexion sécurisée entre un client et un serveur avec certificats (utilisateur et
serveur) [w5].
Figure.II.4.Authentification avec certificat x.509
Cette technique permet d’avoir un canal de communication sécurisé (chiffré) entre deux
machines (un client et un serveur) après une étape d’authentification (Voir l’annexe B).
Les échanges définis par le protocole SSL se déroulent en deux phases :
 Première phase : authentification du serveur (en rouge)
 requête d’un client, le serveur envoie son certificat au client et lui liste les
algorithmes cryptographiques, qu’il souhaite négocier.

22
 Le client vérifie la validité du certificat en interrogeant la liste CLR.
 Le client génère ensuite une empreinte chiffré avec la clé publique du serveur puis
transmis à ce dernier.
 Les données échangées par la suite entre le client et le serveur sont chiffrées et
authentifiées à l’aide de clés dérivées de celle-ci.
 Deuxième phase : authentification (optionnelle) du client (en vert)
 Le serveur (et seulement lui) peut demander au client de s’authentifier en lui
demandant tout d’abord son certificat.
 Le client réplique en envoyant ce certificat puis en signant un message avec sa clé
privée (ce message contient des informations sur la session et le contenu de tous les
échanges précédents).
L’utilisation d’une authentification bidirectionnelle (mutuelle) permet d’assurer l’intégrité,
la confidentialité et grâce à la Deuxième phase, la non répudiation, permettant de garantir qu’une
transaction ne peut être niée par aucune des deux parties (client ou serveur).
Conclusion
Dans ce chapitre nous avons vu l’importance de l’utilisation d’une PKI, ainsi que sa
composition, On peut dire que la PKI englobe plusieurs caractéristiques et protocoles, ainsi que
déférentes fonctionnalités qui améliorent son fonctionnement et qui se traduisent dans sa capacité
à s’associer avec d’autre protocole cryptographique pour plus d’efficacité dans le domaine
de sécurité des échanges de données. Cependant nous venons implémenter ce dernier dans
l’entreprise où nous expliquons toutes les étapes dans le chapitre qui suit.

Chapitre III
Mise en œuvre et
application

Chapitre III mise en œuvre et application
23
Introduction
Après avoir expliqué, aux deux premiers chapitres précèdent, l’importance et la nécessité
de la sécurité du système d’information en utilisant l’infrastructure à clé publique. Nous allons
procédés à la mise en œuvre d’une infrastructure de gestion de clés au sein de l’entreprise, cette
ICP (Infrastructure à Clés Publiques) requière une activité complexe et rigoureuse. Plusieurs
paramètres sont à prendre en considération avant la mise en place de celle-ci.
III.1. Proposition d’un système d’authentification forte
III.1.1. Architecture de l’entreprise
Le réseau national de l’entreprise Algérie Télécom est composé de cinquante (50) DO
(Direction Opérationnelle) divisé par quatre (4) régions :
 Alger couvrant la région centre.
 Oran pour la région ouest.
 Constantine pour la région est.
 Ouargla pour la région sud.
En effet, chaque DO est subdivisé en Agences Commerciales de Télécommunication
(ACTEL), selon l’architecture représenté dans la figure suivante :
Figure.III.1.Architecture de l’entreprise

24
III.1.2. Description de l’architecture de la solution
L'utilisation de certificats numériques est l'une des nombreuses solutions d'authentification
disponibles, car elle présente une panoplie d’avantages tel que :
 Une solution facile à déployer et à administrer.
 Coûts réduits (La solution est intégrée avec Active Directory Windows Server).
 Diminution des risques (Authentification forte et en toute sécurité des
utilisateurs).
En prenant en considération l’architecture précédente, l’implémentation de l’infrastructure
à clé publique est illustrée dans la figure III.2.
Figure.III.2.Déploiement de PKI dans l’entreprise
Pour commencer l’implémentation d’une solution d’infrastructure à clé publique afin de
sécuriser les échanges entre les différents composants d’un réseau, nous devons créer deux
serveurs, le premier est AC racine (au niveau de la direction générale), il doit être non connecté au
réseau et au domaine pour mesure de sécurité. Le deuxième serveur est un serveur subordonné AC
Secondaire connecté au réseau et joint au domaine « alg.tlcm » dans l’Active Directory, il va
hériter sa confiance d’AC racine afin de pouvoir délivré des certificats numérique aux clients.

25
Ce dernier est un service d’annuaire LDAP qui organise et contrôle les accès, il a pour but
de stocker les informations dans un domaine, ainsi de lister les éléments d’un réseau administré
tels que les comptes des utilisateurs, les serveurs, les postes de travail…etc.
III.1.3. Présentation de l’environnement de travail
L’outil qui a été utilisé dans notre projet afin de parvenir à réaliser la solution envisagé est :
Windows Server 2012.
III.2. Mise en place d’AC racine
III.2.1. Installation du rôle AD CS
Pour commencer, nous avons installé notre autorité de certification racine. Pour cela, en
cliquant sur "ajouter des rôles et des fonctionnalités" dans l’Actives Directory, comme le démontre
dans la figure.III.3.
Figure.III.3.Installation de rôle AD CS
 Sélectionner « installation basé sur un rôle ou une fonctionnalité».
 Sélectionner le serveur de destination.
 Cochez la case " Services de certificats Active Directory ".
 Cochez la case «Autorité de certification ". (Le rôle que nous souhaitons installer à AD
CS (Active Directory Certificate Service)).
 Et enfin cliquer sur installer.
III.2.2. Configuration du rôle AD CS
Une fois l'installation terminée, en cliquant sur le lien "configurer les services des
certificats Active Directory sur le serveur de destination", il affiche la fenêtre de «Configuration
AD CS », nous avons coché le service de rôle à configurer «Autorité de certification», comme
montre la figure III.4.

26
Figure.III.4.Configuration d’AC racine
Nous avons choisi le chiffrement RSA-SHA512 (RSA-Secure Hach Algorithm 512) et
sélectionner 4096 bits comme longueur de clé afin de renforcé la sécurité. La figure III.5 représente
la configuration des options de chiffrement et la période de validité.
Figure.III.5.Configuration d’options de chiffrement et la période de validité
Et enfin en cliquant sur « configure », notre AD CS est configuré avec succès.

27
III.2.3. Configuration du CRL
Le serveur AC racine obtient un certificat d’autorité que nous devons garder dans un lieu
très sûr, cet AC racine va créer et publier un CDP (Crl Distribution Points) qui est l’endroit de
publication du CRL et l’AIA (Authority Information Access) qui est l’endroit de publication des
certificats.
Nous avons accédé aux propriétés de notre AC racine, ajouté le CRL et AIA. Comme le
montre la Figure.III.6.
Figure.III.6.Configuration de CRL et AIA
 Publication du CRL
Nous avons publié le CRL, qui stocke les AC révoqué. Comme illustre dans la figure III.7.
Figure.III.7.Publication de liste de révocation

28
III.3. Installation d’AC Secondaire
Passons maintenant à l’autorité de certification secondaire, qui est une autorité de
certification Entreprise, qui va traiter les demandes de certificat des clients.
Notre serveur nommé CAsec.ALGER est une subordonnée jointe au domaine
«Alg.TLCM» sur lequel on va installer AD CS, en suivant les mêmes étapes précédentes
(installation d’AC racine).
 Sélectionner le rôle a installé « AD CS ».
 coche « Autorité de certification » et «inscription de l’autorité de certification».
 continue et installe.
III.3.1. Configuration d’AC Secondaire
La configuration est commencé une fois la fenêtre de configuration est ouverte. Nous avons
coché « autorité de certification » et « inscription de l’autorité de certification via le web », les
deux rôles qui nous souhaitons configurer. La Figure III.8 illustre la configuration de l’AC
secondaire.
Figure.III.8.Configuration d’AC Secondaire
Nous avons enregistré le fichier de la demande d’autorisation pour que la AC
secondaire hérite sa confiance du AC racine.
La configuration été bien réussite.

29
III.3.2. Activation d’AC Secondaire
Afin que le AC racine génère un certificat d’autorité à AC Secondaire, nous avons cliqué
sur «Soumettre une nouvelle demande...» puis sélectionné le fichier de la demande d’autorisation.
La Figure.III.9 montre la signature de certificat d’AC Secondaire.
Figure.III.9.Signature de certificat d’AC Secondaire.
Dans la l’arborescence de la console certsrv, nous avons sélectionné le répertoire
« Demandes en attente », puis sur « Délivrer », comme illustre la figure III.10.
Figure.III.10.Déliverence de certificat d’AC Secondaire
Au niveau de l’AC secondaire, on fait un clic droit sur AD CS, puis « Autorité de
certification », puis clic droit sur le serveur d’AC Secondaire, puis « Toutes les taches », enfin «
Installer un certificat d’autorité de certification» en sélectionnant le certificat d’AC Secondaire qui
est certifié par l’AC racine. La figure III.11 montre l’installation de certificat d’AC Secondaire.
Figure.III.11.Installation de certificat d’AC Secondaire

30
Pour mettre en marche le serveur on clique sur « Start », et le serveur sera prêt pour délivrer
des certificats signés aux clients.
III.5. Configuration de serveur web Apache
Afin de sécuriser le trafic à travers le web, nous avons utilisé le serveur Apache où nous
avons demandé un certificat de type serveur.
Nous avons généré la clé privé du serveur « server.alg.tlcm » sur le serveur où s’exécute
le serveur web Apache qui utilisera la clé privée. Pour cela, nous avons fait appel à OpenSSL,
une boîte à outils pratique, offrant une interface ligne de commande qui permet entre autres de
réaliser les clés cryptographiques ainsi que la création de la requête de signature de certificat CSR.
Nous avons créé en premier temps la clé privée de serveur web protégé par un mot de passe
à l’aide de commande suivants :
Et ensuite la commande qui permet de générer la requête de signature de certificat :
Voici dans la figure III.12 le CSR dans son format texte (base 64) :
Figure.III.12.Requête de signature de certificat du site server.alg.tlcm
L’étape suivante consiste à faire signer le certificat par l’AC secondaire, il suffit d’accéder
à l’autorité de certification secondaire via l’interface Web puis saisir le type de certificat (serveur
web) et copier le contenu du CSR, comme illustrer la figure III.13.
Openssl > genrsa -out server .Key 2048
Openssl > req –new –key server. Key –out server.csr

31
Figure.III.13.Signature de la CSR
Une fois la signature complétée, une boite de dialogue du navigateur web nous invite à
sauvegarder le certificat du serveur web contenant sa clé publique et le certificat d’AC, comme
illustre la figure III.14.
Figure.III.14.Telechargement de certificat
Une fois cette étape franchie, il ne nous reste plus qu’à compléter la configuration
du serveur Apache afin qu’il puisse utiliser ces certificats. Pour ce faire, il suffit de réaliser les
opérations suivantes :

32
1. Copier tous les certificats (serveur web et AC) dans le même dossier.
2. Ajouter le code suivant dans le fichier de configuration httpd.conf d’Apache qui est les chemins
des certificats et le chemin de la clé privé généré par OpenSSL.
La figure III.15 illustre la configuration de serveur apache.
Figure.III.15.Configuration de serveur apache
Il suffit maintenant de se connecter au site https://server.alg.tlcm/, comme le montre la
figure III.16.
Figure.III.16.Connexion réussie au site https://server.alg.tlcm

33
III.6. Authentification de l’utilisateur
La prochaine étape consiste à démontrer comment notre PKI permettra de bénéficier
de l’authentification par certificat utilisateur. Nous allons procéder à l’installation d’un certificat
client dans la machine d’un utilisateur, et ce, simplement en faisant appel à l’interface web de
l’autorité de certification pour inscrire un certificat de type utilisateur. La figure III.17 montre
l’inscription de certificat d’utilisateur.
Figure.III.17.Inscription de certificat d’utilisateur
En appuyant sur « OK », le certificat sera téléchargé puis installé automatiquement.
Afin de tester l’utilisation du certificat client récemment installé dans le navigateur de
l’utilisateur, il faut procéder à l’activation de l’authentification client par certificat au niveau du
serveur Apache. Pour ce faire, il suffit de réaliser les étapes suivantes :
1. Télécharger le fichier de la chaine de certificat depuis l’autorité de certification, puis
on copie dans le dossier contenant déjà les autres certificats créés dans la configuration
précédente.
2. Ajouter le code suivant dans le fichier de configuration httpd.conf d’Apache :
Maintenant le serveur Apache est configuré pour authentifier les clients par leurs
certificats.

34
Lors de l’établissement de la session SSL avec le serveur web, ce dernier a demandé au
client de s’authentifier à l’aide de son certificat. Le navigateur web a demandé de choisir le
certificat à utiliser parmi la liste des certificats personnels installés (ce certificat est protéger avec
un mot de passe connait par l’utilisateur). Après avoir sélectionné le certificat, l’établissement de
la session SSL s’est poursuivi et l’authentification mutuelle fut réalisée avec succès comme le
montre la figure suivante :
Figure.III.18.Authentification par certificat
Conclusion
Notre travail comprend des exemples d’implémentation d’une solution PKI sous Microsoft,
où nous avons adhéré les normes internationales et les bons pratiques.
Dans la première phase nous avons montré comment implémenter l’AC racine qui va être
utilisé pour donner une fiabilité au subordonnée afin qu’elle devient un point de confiance. Ensuite,
nous avons intégré un serveur qui joue le rôle d’AC secondaire et qui fait déjà partie du domaine
entreprise ALG.TLCM. Et finalement nous avons vu l’authentification mutuelle des utilisateurs
par des certificats au serveur web Apache.
La solution d’implémentation PKI n’existe pas que sous Microsoft, il y a plusieurs
technologies telles que Linux Unix, ou même des technologies payantes et open source.

Conclusion générale
35
Conclusion Générale
Ce projet nous a permis d’approfondir les connaissances théoriques et pratiques que nous
avons acquises tout au long de notre formation, il consiste d'étudier et implémenter une
infrastructure PKI qui assure l’authentification des utilisateurs et ordinateurs, la signature
électronique des certificats et la sécurité des sites web ainsi que le trafic entre différentes entités...
etc.
Il nous a été confié durent ce projet la mission de réaliser une solution d’administration
électronique basée sur l’identification et l’authentification par infrastructure à clé publique, cette
dernière a de nombreux avantages tels que la facilité et la gestion des problèmes d’administration,
résoudre la notion de confiance et d’authentification et assurer la sécurité des informations… etc.
L’élaboration de ce travail nous a permis de rentré dans un monde de sécurité informatique
tellement vaste, et d’apprendre la façon d’appliquer les outils informatiques pour une bonne
gestion d’authentification et de confiance, et d’élever le niveau de protection des données des
personnes.
Pour conclure, ce projet nous a permis de s’intégrer dans le milieu professionnel, de
bénéficier une expérience. Cependant, le développement d’un tel projet n’est jamais totalement
achevé et certaines idées n’ont pas pu être réalisées à cause de contraintes de temps. C’est dans ce
sens et afin d’améliorer ce présent travail que nous proposons de réalisé une implémentation base
sur les certificats électronique de protocole de contrôle d'accès aux équipements d'infrastructures
réseau 802.1x sur le réseau filaire est sans fil, EAP-TLS qui est La forme la plus sécurisée de
l'authentification IEEE 802.1x.
Enfin, nous souhaiterons que ce travail puisse servir d’accompagnement pour les futurs
étudiants.

Références biographiques
Bibliographie
[1] Ghislaine Labouret CONSULTANTS « introduction à la cryptographie » Cabinet de
Consultants en Sécurité Informatique depuis 1999-2001
[2] Renaud Dumont « Cryptographie et Sécurité informatique». Notes de cours Provisoires,
Université de Liège 2009 – 2010
[3] G Florin, S Natkin « LES TECHNIQUES DE CRYPTOGRAPHIE » Unité de valeur
Systèmes et applications répartis. 2002
[4] Pascal Gachet, "Déploiement de solutions VPN : PKI Etude de cas" : travail du diplôme
Ecole d'ingénieur du Canton de Vaud 2011
[5] Network Associates, Inc. et ses filiales. Introduction à la Cryptographie
[6] William Stallings; cryptography and network security, prentice-hall; 1999[29]
Webographie
[w1] http://www.alfae.fr/wp-content/uploads/2015/12/Rapport-authentification-forte.pdf
[w2] https://fr.wikipedia.org/wiki/Authentification_forte (Page consultée le 5 février 2016).
[w3] https://www.securiteinfo.com/conseils/biometrie.shtml (Page consultée le 5 février 2016).
[w4] http://www.nuance.fr/landing-pages/products/voicebiometrics/(page consulté le 21 mars
2016).
[w5] http://nicolasbroisin.fr/blog/etude-infrastructure-pki/ (Page consultée le 10 mars 2016).
[w6] https://www.certificatnymérique.com/ (page consulté le 30 mars 2016).

Annexe
Annexe A : protocole OCSP
A.1. Protocole OCSP
La technique classique de distribuer des CRL par une autorité de certification émettrice
présente comme on vient de le voir plusieurs inconvénients. C'est pourquoi l'IETF a introduit le
protocole OCSP.
C'est une meilleure approche pour valider les certificats. Elle consiste à utiliser un
protocole qui permet à un client OCSP d'émettre une requête sur l'état d'un certificat particulier
auprès d'une autorité de confiance et si possible en temps réel. Online Certificate Status Protocol
est un protocole dans lequel l'information sur la révocation des certificats est disponible on
line depuis un répondeur OCSP à travers un mécanisme de requête/réponse. Il est utilisé
exclusivement pour vérifier l'état des certificats numériques.
Dans ce protocole, le serveur demande l'état d'un ou de plusieurs certificats à la fois, au
répondeur OCSP. Celui-ci vérifie l'état du certificat impliqué et retourne une réponse à
l'entité finale.
A.1.1. Requête OCSP
Une requête OCSP se compose des éléments suivants :
 Une version du protocole.
 Le nom du requérant quand la requête est signée.
 Certaines informations sur le certificat ciblent.
 Les extensions facultatives qui peuvent être traitées par le répondeur OCSP.
A.1.2. Composition d’une réponse OCSP
Les réponses OCSP peuvent être de différents types, mais il existe une réponse de base qui
doit être supportée par tous les serveurs OCSP. Les messages de réponses définitives doivent être
signés. La clé utilisée pour signer cette réponse doit appartenir à l’une des entités suivantes :
Lorsqu’un certificat est dit bon (good), ce résultat indique une réponse positive à la
requête d’état. Si le certificat n’est pas révoqué. Toutefois il ne signifie pas nécessairement que le
certificat n’a jamais été révoqué et que le moment où la réponse a été produite est dans l’intervalle
de validité du certificat.
L’état «révoqué» (revoked) indique que le certificat a été révoqué temporairement ou
définitivement.

Annexe
L’état « inconnu » (unknow) indique que le répondeur n’a pas d’information sur le certificat
demandé.

Annexe
Annexe B : SSL/ TLS
B.1. SSL/ TLS
L’authentification par certificats est mise en œuvre notamment par un protocole de
sécurisation des échanges sur Internet nommé Secure Sockets Layer (SSL) ou plus récemment
standardisé sous le nom Transport Layer Security (TLS) par l’IETF. Ce protocole a été développé
par Netscape pour assurer initialement la sécurité des échanges entre un serveur Web et un client
muni d’un navigateur.
SSL permet de chiffrer les communications entre un client et un serveur et d’authentifier le
serveur (version 2). Il peut aussi, de façon facultative, authentifier le client (version 3). Bien que
ce protocole ait été développé pour les communications HTTP entre un navigateur Web et un
serveur Web, il peut aussi être utilisé pour les transferts de fichiers FTP.
Le serveur s’authentifie par l’envoi de son certificat au client. D’une part, ce dernier
vérifie sa validité par consultation du certificat de l’autorité qui a signé le certificat du
serveur. D’autre part, le client envoie au serveur le passe -partout de la session, chiffré par la clé
publique de ce dernier, afin de s’assurer de l’identité du serveur. Seul le possesseur de la clé privée,
donc le bon serveur, peut déchiffrer le passe-partout.
Le client s’authentifie en envoyant au serveur à la fois son certificat et un message (jeton)
signé avec sa clé privée. Le serveur peut ainsi vérifier que le certificat a bien été envoyé par le vrai
client, en contrôlant la signature qu’il va recevoir. (À noter que le contenu du message signé n’est
connu que du serveur et du client.).
Nous voyons ici l’importance de la certification pour garantir l’authentification des
parties en présence, comprenant une vérification poussée du certificat (signature de l’émetteur,
listes noires, dates de validité, etc.).

Annexe
Figure.B.1.Schéma simplifié d’un établissement de session SSL

Annexe
Annexe C : Construction de confiance entre AD et AC racine
C.1. Exportation de certificat
Pour pouvoir faire confiance entre l’autorité de certification et les autres machines, nous
aurons besoin d’exporter le certificat d’autorité racine. La figure.C.1 illustre l’exportation de
certificat.
Figure.C.1.Exportation de certificat
Nous avons installé le certificat d’autorité racine dans l’AD. Comme le montre la figure.C.2.
Figure.C.2.Installation de certificat de l’AC
C.2. Installation de certificat d’autorité dans les machines de domaine par
GPO
Dans notre serveur Active Directory on ajoute une nouvelle stratégie de groupe à ce
domaine pour qu’on puisse appliquer un ensemble de configuration sur ce groupe d’utilisateurs,
Comme la figure.C.3 illustre.

Annexe
Figure.C.3.Création de nouvel objet GPO
Dans l’arborescence gestion stratégie de clé publique nous avons activé l’option inscription
client aux services de certificat utilisateur et ordinateur. La figure.C.4 montre l’activation de
stratégie.
Figure.C.4.Activation de stratégie
Ensuite nous avons importé le certificat d’autorité dans l’arborescence Autorité de
certification racine de confiance, comme le montre la figure.C.5.

Annexe
Figure.C.5.Importation de certificat
Et enfin nous avons exécuté la commande « gpupdate /force » pour exiger au serveur
d’appliquer toute la nouvelle politique au niveau utilisateur.
La Figure.C.6 illustre l’exécution de la commande.
Figure.C.6.Excution de la nouvelle stratégie

Annexe
Annexe D : Préparation des modèles de certificats
Voilà quelques modèles de certificat au niveau de notre solution PKI ou nous avons
dupliqué le certificat afin de pouvoir modifier en dessus.
Nous avons personnalisé un modèle de certificat pour le serveur web(Apache) au niveau
de l’Autorité de Certification Secondaire.
LA figure.D.1 montre la Personnalisation d’un modèle de certificat.
Figure.D.1.Personalisation d’un modèle de certificat
Et nous avons aussi personnalisé trois modèles de certificats (Agent d’inscription,
Connexion par carte à puce, Serveur web), comme le montre la figure.D.2.
Figure.D.2.Modèle de certificat.

Résumé
Ce travail consiste à mettre en place de systèmes basés sur des certificats électroniques.
Ces certificats permettent d'authentifier une entité au système d'information d'Algérie télécom en
faisant un lien entre celle-ci et sa clé publique qui est établie et gérée grâce aux infrastructures de
gestion de clés (Public Key Infrastructure, PKI) qui sont considérées actuellement comme
les piliers des transactions sécurisées.
Mots clés : Authentification forte, PKI, Contrôleur de domaine, Identification, certificat
numérique.
‫الملخص‬
‫هذا‬‫العمل‬‫هو‬‫األنظمة‬ ‫تنفيذ‬‫القائمة‬‫على‬‫الشهادات‬‫الرقمية‬.‫وتستخدم‬‫هذه‬‫الشهادات‬‫لمصادقة‬‫كيان‬‫لنظام‬‫معلومات‬‫اتصاالت‬
‫الجزائر‬‫عن‬‫طريق‬‫وصلة‬‫بينه‬‫وبين‬‫المفتاح‬‫العمومي‬‫الذي‬‫تم‬‫تأسيسه‬‫وإدارته‬‫من‬‫يعتبر‬ ‫الذي‬ ‫العام‬ ‫للمفتاح‬ ‫التحتية‬ ‫البنية‬ ‫خالل‬
‫حاليا‬‫منصب‬‫ركائز‬‫المعامالت‬.‫اآلمنة‬
‫المفتاحية‬ ‫الكلمات‬،‫قوية‬ ‫مصادقة‬ :،‫المجال‬ ‫تحكم‬ ‫وحدة‬،‫رقمية‬ ‫شهادة‬ ،‫الهوية‬ ‫تحديد‬
Abstract
This work involves setting up systems based on electronic certificates. These certificates
make it possible to authenticate an entity to the information system of Algeria telecom by linking
it to its public key ,which is established and managed thanks to the key management infrastructures
that are currently consider the pillars of transactions secure.
Key word: Strong Authentication, PKI, Domain Controller, Identification, Digital
Certificate.

PKI

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à PKI

Similaire à PKI (20)

PKI