SlideShare une entreprise Scribd logo
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
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
Liste des abréviations
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.
Chapitre I Etat de l’art de l’authentification forte
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].
Chapitre I Etat de l’art de l’authentification forte
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.
Chapitre I Etat de l’art de l’authentification forte
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
Chapitre I Etat de l’art de l’authentification forte
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.
Chapitre I Etat de l’art de l’authentification forte
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].
Chapitre I Etat de l’art de l’authentification forte
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.
Chapitre I Etat de l’art de l’authentification forte
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
Chapitre I Etat de l’art de l’authentification forte
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.
Chapitre II infrastructure à clé publique
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.
Chapitre II infrastructure à clé publique
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é.
Chapitre II infrastructure à clé publique
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.
Chapitre II infrastructure à clé publique
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
Chapitre II infrastructure à clé publique
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é
Chapitre II infrastructure à clé publique
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.
Chapitre II infrastructure à clé publique
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
Chapitre II infrastructure à clé publique
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].
Chapitre II infrastructure à clé publique
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.
Chapitre II infrastructure à clé publique
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.
Chapitre II infrastructure à clé publique
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
Chapitre III mise en œuvre et application
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.
Chapitre III mise en œuvre et application
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.
Chapitre III mise en œuvre et application
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.
Chapitre III mise en œuvre et application
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
Chapitre III mise en œuvre et application
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.
Chapitre III mise en œuvre et application
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
Chapitre III mise en œuvre et application
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
Chapitre III mise en œuvre et application
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 :
Chapitre III mise en œuvre et application
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
Chapitre III mise en œuvre et application
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.
Chapitre III mise en œuvre et application
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.

Contenu connexe

Tendances

projet fin d'étude IWAN
projet fin d'étude IWANprojet fin d'étude IWAN
projet fin d'étude IWAN
Med Amine El Abed
 
Présentation Cryptographie
Présentation CryptographiePrésentation Cryptographie
Présentation Cryptographie
Cynapsys It Hotspot
 
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
Danny Batomen Yanga
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
Tidiane Sylla
 
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdfProtection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
MELLAH MOULOUD Sorbonne Université - Sciences et Ingénierie
 
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Salmen HITANA
 
Rapport projet fin d'étude
Rapport projet fin d'étudeRapport projet fin d'étude
Rapport projet fin d'étude
HibaFarhat3
 
Securite informatique
Securite informatiqueSecurite informatique
Securite informatique
Souhaib El
 
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
Mise en place de la solution d’authentification Radius sous réseau LAN câbléMise en place de la solution d’authentification Radius sous réseau LAN câblé
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
Charif Khrichfa
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau
Yaya N'Tyeni Sanogo
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
bamaemmanuel
 
Présentation audits de sécurité
Présentation   audits de sécuritéPrésentation   audits de sécurité
Présentation audits de sécurité
Harvey Francois
 
Etude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec OpenstackEtude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec Openstack
BayeOusseynouFall
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
Karim Ben Alaya
 
Sécurité de l'IoT | Internet des objets - Formation d'une journée
Sécurité de l'IoT | Internet des objets - Formation d'une journéeSécurité de l'IoT | Internet des objets - Formation d'une journée
Sécurité de l'IoT | Internet des objets - Formation d'une journée
Tactika inc.
 
Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
Samia HJ
 

Tendances (20)

projet fin d'étude IWAN
projet fin d'étude IWANprojet fin d'étude IWAN
projet fin d'étude IWAN
 
Présentation Cryptographie
Présentation CryptographiePrésentation Cryptographie
Présentation Cryptographie
 
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT ...
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
 
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdfProtection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
 
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...Mise en place d’une solution de tests de sécurité pour les passerelles réside...
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
 
Rapport projet fin d'étude
Rapport projet fin d'étudeRapport projet fin d'étude
Rapport projet fin d'étude
 
Securite informatique
Securite informatiqueSecurite informatique
Securite informatique
 
Le chiffrement
Le chiffrementLe chiffrement
Le chiffrement
 
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
Mise en place de la solution d’authentification Radius sous réseau LAN câbléMise en place de la solution d’authentification Radius sous réseau LAN câblé
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
 
Présentation audits de sécurité
Présentation   audits de sécuritéPrésentation   audits de sécurité
Présentation audits de sécurité
 
Etude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec OpenstackEtude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec Openstack
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Sécurité de l'IoT | Internet des objets - Formation d'une journée
Sécurité de l'IoT | Internet des objets - Formation d'une journéeSécurité de l'IoT | Internet des objets - Formation d'une journée
Sécurité de l'IoT | Internet des objets - Formation d'une journée
 
Système de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans filSystème de supervision des réseaux de capteurs sans fil
Système de supervision des réseaux de capteurs sans fil
 

Similaire à PKI

Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdfRégulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
MedKad3
 
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdfRégulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
MedKad3
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
slim Hannachi
 
879
879879
Mise en place d'une solution de détection des pirates et des malwares dans le...
Mise en place d'une solution de détection des pirates et des malwares dans le...Mise en place d'une solution de détection des pirates et des malwares dans le...
Mise en place d'une solution de détection des pirates et des malwares dans le...
Mohamed Ben Bouzid
 
Conception et realisation_dun_robot_mobi
Conception et realisation_dun_robot_mobiConception et realisation_dun_robot_mobi
Conception et realisation_dun_robot_mobi
mohsen1974
 
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
Zaki Saidani
 
Analyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reelAnalyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reel
Sid Ahmed Benkraoua
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YounesAGABI
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
Mounir Kaali
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
La protection de la vie privée dans un sgi final
La protection de la vie privée dans un sgi finalLa protection de la vie privée dans un sgi final
La protection de la vie privée dans un sgi finalboumriga hassane
 
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
abdoulayendiaye60
 
these sur la gestion des risques.pdf
these sur la gestion des risques.pdfthese sur la gestion des risques.pdf
these sur la gestion des risques.pdf
SIHAMBELLAGNECH
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
MahmoudiOussama
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
MahmoudiOussama
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
tutoriel sur la mise en place d'une politique de sécurité informatique
tutoriel sur la mise en place d'une politique de sécurité informatiquetutoriel sur la mise en place d'une politique de sécurité informatique
tutoriel sur la mise en place d'une politique de sécurité informatique
Manuel Cédric EBODE MBALLA
 
2007.23_ascensseur.pdf
2007.23_ascensseur.pdf2007.23_ascensseur.pdf
2007.23_ascensseur.pdf
FaridAloua
 

Similaire à PKI (20)

Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdfRégulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
 
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdfRégulation et supervision d un procédé d étalonnage de débitmètres.pdf
Régulation et supervision d un procédé d étalonnage de débitmètres.pdf
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
 
879
879879
879
 
Mise en place d'une solution de détection des pirates et des malwares dans le...
Mise en place d'une solution de détection des pirates et des malwares dans le...Mise en place d'une solution de détection des pirates et des malwares dans le...
Mise en place d'une solution de détection des pirates et des malwares dans le...
 
Conception et realisation_dun_robot_mobi
Conception et realisation_dun_robot_mobiConception et realisation_dun_robot_mobi
Conception et realisation_dun_robot_mobi
 
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
Etude des machines synchrones a démarrage direct sur le réseau (line start pe...
 
Analyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reelAnalyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reel
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
La protection de la vie privée dans un sgi final
La protection de la vie privée dans un sgi finalLa protection de la vie privée dans un sgi final
La protection de la vie privée dans un sgi final
 
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
Realisation-dun-module-Odoo-de-gestion-de-recrutements-carriere-et-conges-des...
 
these sur la gestion des risques.pdf
these sur la gestion des risques.pdfthese sur la gestion des risques.pdf
these sur la gestion des risques.pdf
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
tutoriel sur la mise en place d'une politique de sécurité informatique
tutoriel sur la mise en place d'une politique de sécurité informatiquetutoriel sur la mise en place d'une politique de sécurité informatique
tutoriel sur la mise en place d'une politique de sécurité informatique
 
2007.23_ascensseur.pdf
2007.23_ascensseur.pdf2007.23_ascensseur.pdf
2007.23_ascensseur.pdf
 

PKI

  • 1. 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
  • 2. 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.
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. Liste des abréviations 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
  • 8. Liste des abréviations 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
  • 9. 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.
  • 10. Chapitre I Etat de l’art de l’authentification forte
  • 11. 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.
  • 12. Chapitre I Etat de l’art de l’authentification forte 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].
  • 13. Chapitre I Etat de l’art de l’authentification forte 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.
  • 14. Chapitre I Etat de l’art de l’authentification forte 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
  • 15. Chapitre I Etat de l’art de l’authentification forte 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.
  • 16. Chapitre I Etat de l’art de l’authentification forte 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].
  • 17. Chapitre I Etat de l’art de l’authentification forte 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.
  • 18. Chapitre I Etat de l’art de l’authentification forte 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
  • 19. Chapitre I Etat de l’art de l’authentification forte 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.
  • 21. 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.
  • 22. Chapitre II infrastructure à clé publique 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.
  • 23. Chapitre II infrastructure à clé publique 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é.
  • 24. Chapitre II infrastructure à clé publique 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.
  • 25. Chapitre II infrastructure à clé publique 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
  • 26. Chapitre II infrastructure à clé publique 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é
  • 27. Chapitre II infrastructure à clé publique 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.
  • 28. Chapitre II infrastructure à clé publique 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
  • 29. Chapitre II infrastructure à clé publique 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].
  • 30. Chapitre II infrastructure à clé publique 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.
  • 31. Chapitre II infrastructure à clé publique 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.
  • 32. Chapitre II infrastructure à clé publique 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.
  • 33. Chapitre III Mise en œuvre et application
  • 34. 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
  • 35. Chapitre III mise en œuvre et application 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.
  • 36. Chapitre III mise en œuvre et application 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.
  • 37. Chapitre III mise en œuvre et application 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.
  • 38. Chapitre III mise en œuvre et application 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
  • 39. Chapitre III mise en œuvre et application 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.
  • 40. Chapitre III mise en œuvre et application 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
  • 41. Chapitre III mise en œuvre et application 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
  • 42. Chapitre III mise en œuvre et application 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 :
  • 43. Chapitre III mise en œuvre et application 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
  • 44. Chapitre III mise en œuvre et application 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.
  • 45. Chapitre III mise en œuvre et application 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.
  • 46. 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.
  • 47. 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).
  • 48. 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.
  • 49. Annexe L’état « inconnu » (unknow) indique que le répondeur n’a pas d’information sur le certificat demandé.
  • 50. 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.).
  • 51. Annexe Figure.B.1.Schéma simplifié d’un établissement de session SSL
  • 52. 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.
  • 53. 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.
  • 54. 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
  • 55. 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.
  • 56. 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.