Sécurité des Systèmes et Réseaux

Infrastructures à
Clés Publiques

Version 1

YACINE CHALLAL

13/02/2018
 Table des
matières

I - PKI : Infrastructures à clés publiques 5

A. Systèmes asymétriques : atouts et limites...............................................................5

B. La certification numérique........................................................................................ 9

C. PKI : Infrastructure à clés publiques........................................................................12

D. Secure Socket Layer : SSL......................................................................................16

E. Pretty Good Privacy (PGP).......................................................................................17

II - Testez vos connaissances 23

A. Exercice : Man in the Middle...................................................................................23

B. Exercice : Certificat numérique...............................................................................24

C. Exercice : SSL......................................................................................................... 24

III - Série d'exercices II: Infrastructures à clés publiques 25

A. Télé-déclaration des revenus..................................................................................25

B. Travail Pratique : Sécuriser l'échange entre un client et un serveur web Apache avec
SSL.............................................................................................................................. 26
1. Créer un espace de Publication Web Apache...................................................................................26
2. Créer un répertoire pour la zone sécurisée......................................................................................26
3. Créer les certificats et les clés pour la CA et le Serveur Web..........................................................27
4. Les tests............................................................................................................................................27
5. Analyse et comparaison des échanges............................................................................................27
6. Ajouter un certificat Client................................................................................................................28

C. Déploiement de PGP............................................................................................... 29

D. Cabinet Notarial..................................................................................................... 30

3
PKI :
I-

I
Infrastructures à
clés publiques

Systèmes asymétriques : atouts et limites 5

La certification numérique 9
PKI : Infrastructure à clés publiques 12
Secure Socket Layer : SSL 16
Pretty Good Privacy (PGP) 17

A. Systèmes asymétriques : atouts et limites

La gestion des clés est plus facile avec les systèmes asymétriques
Dans ce scénario, si le réseau est composé de n noeud alors il faudra gérer n.(n-1)/2
clé, ce qui ne s'adapte pas au facteur d'échelle. Avec 500 noeud, on arrive déjà à
plus de 12 millions de clés à gérer.

Image 1 Limites de la gestion de clés symétriques

Par contre, avec un système asymétrique chaque utilisateur aura besoin d'une paire

5
 PKI : Infrastructures à clés publiques
de clés. Donc on aura à gérer seulement 2.n clés au lieu des n.(n-1)/2 clés dans le
cas symétrique.

Utilité d'un système asymétrique dans l'authentification

Nous avions déjà vus que l'usage d'un système asymétrique est indispensable pour
garantir la non-répudiation de l'origine.
L'usage d'un système asymétrique est également utile pour l'identification comme
expliqué plus bas.
Dans ce scénrio, Alice veut s'assurer de l'identité de Bob. Elle ne connaît de Bob que
sa clé publique.
Pour s'assurer de l'identité de Bob, Alice lui envoie un défi (un nombre aléatoire).
Pour prouver son identité à Alice, Bob signe le défi avec sa clé privée et envoie sa
signature sur le défi à Alice.
Pour vérifier l'identité de Bob, il suffit que Alice vérifie la signature de Bob avec sa
clé publique comme illustré sur la figure ci-contre.

Image 2 Identification avec un système asymétrique

Attention : Comment garantir qu'une clé publique correspond bien à

l'entité avec qui on communique ?
Jusque là, nous avions toujours supposé que la clé publique est distribuée d'une
manière sécurisée. Si cette hypothèse n'est pas vérifiée, un schéma asymétrique
peut subir une attaque de type "Man in the Middle". Une telle attaque est illustrée
dans le scénario ci-après.

6
 PKI : Infrastructures à clés publiques

Image 3 Man in the middle

Méthode : Certification numérique

La solution au problème dit "man in the middle" est l'usage d'un certificat
numérique qui assure la liaison entre l'identité et la clé publique correspondante
dans un document numérique signé par une tierce partie de confiance dite autorité
de certification.

B. La certification numérique

Défi nition : Certificat numérique

 Un certificat à clé publique est un certificat numérique qui lie l'identité d'un
système à une clé publique, et éventuellement à d'autres informations;
 C'est une structure de donnée signée numériquement qui atteste sur
l'identité du possesseur de la clé privée correspondante à une clé publique.
 Un certificat est signé numériquement par une autorité de certification à qui
font confiance tous les usagers et dont la clé publique est connue par tous
d'une manière sécurisée. Ainsi, afin de publier sa clé publique, son
possesseur doit fournir un certificat de sa clé publique signé par l'autorité de
certification. Après vérification de la signature apposée sur le certificat en
utilisant la clé publique de l'autorité de certification, le récepteur peut
déchiffrer et vérifier les signatures de son interlocuteur dont l'identité et la
clé publique sont inclus dans le certificat.

Exemple : Structure d'un certificat X.509

 Version
 Numéro de série
 Algorithme de signature du certificat
 Signataire du certificat
 Validité (dates limite)
- Pas avant
- Pas après
 Détenteur du certificat
 Informations sur la clé publique
- Algorithme de la clé publique

7
 PKI : Infrastructures à clés publiques
- Clé publique
 Identifiant unique du signataire (Facultatif)
 Identifiant unique du détenteur du certificat (Facultatif)
 Extensions (Facultatif)
- Liste des extensions...
La figure suivante illustre un tel certificat inclus dans un navigateur web

Image 4 Certificat Numérique

Défi nition : Autorité de certification

Une autorité de certification est toute entité qui délivre des certificats de clé
publique

8
 PKI : Infrastructures à clés publiques

Image 5 Autorité de certification

Remarque : Auto signature

Une autorité de certification auto-signe son certificat numérique. ceci ne posant pas
de problème puisque la clé publique d'une autorité de certification est censée
connue d'une manière sécurisée (remise en main propre pas exemple).

Autorité de certification et confiance

L'autorité de certification certifie la correspondance Clé publique – Identité pour
l'ensemble d'une population. Ceci mène à faire régner la confiance par transitivité :
 A fait confiance à l'Autorité de Certification
 L'Autorité de Certification délivre un certificat à B
 A est assuré de l'identité de B

C. PKI : Infrastructure à clés publiques

Défi nition : Infrastructure à clés publiques

« Ensemble de composants, fonctions et procédures dédié à la gestion de clés et de
certificats utilisés par des services de sécurité basés sur la cryptographie à clé
publique ». [Politique de certification type: Ministère de l'Economie, des Finances et
de l'Industrie, Fr]

Méthode : Cycle de vie d'un certificat

La figure suivante illustre le cycle de vie d'un certificat de sa délivrance et à sa
destruction

9
 PKI : Infrastructures à clés publiques

Image 6 Cycle de vie d'un certificat numérique

Fonctions d'une PKI

Enregistrer et vérifier les demandes de certificats
 Autorité d'enregistrement
Créer et distribuer des certificats
 Autorité de certification
Vérification de validité de certificats
 Autorité de validation
Gérer à tout moment l'état des certificats et prendre en compte leur révocation
 Dépôt de listes de certificats révoqués – CRL (Certificate Revocation List)
Publier les certificats dans un dépôt
 Dépôt de certificats (Annuaire)

Modèles de confiance dans les PKI

Modèle monopoliste
 Une CA pour tout le monde
Modèle monopoliste avec Autorités d'enregistrement
 Une CA avec plusieurs RAs pour la vérification des identités, ...
Délégation de pouvoir de certification
 Une CA délègue le pouvoir de certification à d'autres entités qui deviennent
CA à leur tour, en leur fournissant un certificat qui certifie leur capacité
d'être CA.
Modèle oligarchique
 Déploiement des produits (comme les navigateur web) avec plusieurs entités
de confiance qui sont des CA. Le navigateur fera confiance à tout certificat
signé par l'une de ces CA dans sa liste
Modèle anarchique
 Chaque utilisateur établit la liste des entités à qui il fait confiance

10
 PKI : Infrastructures à clés publiques

Validation de certificat
Pour pouvoir se fier au contenu d'un certificat, il est nécessaire de réaliser les
vérifications suivantes:

Image 7 Validation d'un certificat numérique

Il existe par ailleurs différents moyens et techniques standards pour offrir ce service
 Vérification du statut du certificat par récupération régulière de CRL
 Vérification du statut du certificat en ligne : OCSP (On-line Certificate Status
Protocol)
 Vérification complète du certificat en ligne : SCVP (Simple Certificate
Validation Protocol)

Image 8 Protocoles de vérification de certificats

Attention : Révocation de certificats

Un certificat peut être révoqué. La révocation intervient quand la fin de validité
réelle précède la fin de validité prévue. La révocation peut avoir plusieurs motifs :
 Compromission réelle ou suspectée de la clé privée
 Modification d'un au moins de attributs certifiés
 Perte de la clé privée (effacement d'un disque dur, perte ou détérioration
d'une carte à puce, oubli du code PIN, ...)
 Évolution de l'état de l'art cryptographique (la cryptanalyse de la clé privée
entre dans le domaine du possible)

11
 PKI : Infrastructures à clés publiques
 Perte de confiance vis-à-vis d'un acteur ou d'un composant de la PKI
Le demandeur doit être habilité et authentifié
 Le propriétaire du certificat
 Son supérieur hiérarchique
 Le service de gestion du personnel ...
La méthode de révocation dépend de la méthode de validation
 Utilisation d'annuaire « positif » ==> La révocation consiste à enlever le
certificat révoqué de l'annuaire
 Utilisation d'un annuaire « négatif » ou CRL ==> La révocation consiste à
inscrire le certificat dans une liste de révocation de certificat

Remarque : La gestion des CRL

La gestion des CRL peut devenir complexe et lourde :

Image 9 Gestion des CRL

Les delta CRL ne contiennent que les changements depuis la dernière diffusion :

Image 10 Gestion des delta CRL

12
 PKI : Infrastructures à clés publiques

Fondamental : Schéma fonctionnel simplifié d'une PKI

En résumé, voici les différents composants d'une PKI :

Image 11 Schéma fonctionnel d'une PKI

D. Secure Socket Layer : SSL

Aperçus générale
SSL/TLS est un protocole de sécurisation des échanges développé par Netscape. Il
assure les transactions Client / Serveur sur Internet. Il a été intégré dans les
navigateurs web depuis 1994. La vesrion 3.1 est baptisée Transport Layer Security
TLS. Cette version a été standardisée à l'IETF: RFC 2246. Le protocole fonctionne au
dessus de la couche TCP

Services de sécurité assurés par SSL

Confidentialité
 Obtenue par chiffrement symétrique
Intégrité
 En utilisant des MAC : MD5(128 bits), SHA1(160 bits)
Authentification
 Identification des deux entités (client optionnel) basée sur les certificats
X.509
 Authentification de l'origine des données basée sur des MAC

Sous protocoles de SSL

SSL se déroule selon quatre sous protocoles
1. Handshake
- Authentification mutuelle
- Négociation des algorithmes de chiffrement et de hachage
- Échange des clés symétriques
2. Change Cipher Spec

13
 PKI : Infrastructures à clés publiques
- Indiques la mise en place des algorithmes de chiffrement négocié
3. Record
- Garantir la confidentialité à l'aide du chiffrement, et L'authentification à
l'aide de condensât
4. Alert
- Émission de messages d'alertes suites aux erreurs que peuvent
s'envoyer le client et le serveur

Déroulement du protocole SSL

SSL se déroule en deux phases
1. Phase 1: authentification du serveur
- Requête client
- Le serveur envoie son certificat et une liste d'algo de crypto à négocier
- Le client vérifie le certificat du serveur à l'aide de la clé publique du CA
contenu dans le navigateur
- Le client génère un pré-master secret (PMS)(48 octets) qui sera utilisé
pour générer le master-key (48 octets).
- PMS est chiffré avec la clé publique du serveur
- Les données échangées entre le client et le serveur seront chiffrées et
authentifiées avec des clés dérivées du master-secret
2. Phase 2: authentification du client
- Le serveur peut demander au client de s'authentifier en lui demandant
son certificat
- Le client répond en envoyant son certificat puis en signant un message
avec sa clé privé (contient des info sur la session et le contenu des
messages précédents)

Image 12 Le protocole SSL/TLS

E. Pretty Good Privacy (PGP)

Objectif
Protéger l'échange de courriers électroniques

Complément : Performance
Combine systèmes symétriques et systèmes asymétriques

14
 PKI : Infrastructures à clés publiques

Fondamental : Principe de fonctionnement

PGP choisit une clef symétrique aléatoire: clef de session. Chiffre le courrier avec la
clé de session. Puis, chiffre la clé de session avec la (les) clef(s) publique(s) du (des)
destinataire(s). Ces derniers pouront alors déchiffrer la clé de session avec leur clé
privée puis déchiffre le message avec la clé de session.

Remarque : Protection des clés privées

Les clefs privées sont chiffrées sur le disque de l'utilisateur de PGP en utilisant un
algorithme de dérivation de clef à partir d'un mot de passe. Quand la clef privée est
nécessaire (pour signer ou déchiffrer un message), l'utilisateur saisit le mot de
passe pour déchiffrer sa clé privée

Méthode : Distribution des clés publiques

Le moyen le plus simple et efficace est de rencontrer la personne, de l'authentifier
et lui demander sa clé publique. Cette rencontre physique n'est pas toujours
commode. On récupère les clefs publiques des annuaires (dit serveurs) PGP. Une
clef PGP obtenue sur un serveur PGP ne devrait pas être considérée de confiance
sans vérification supplémentaire. Un intrus peut enregistrer une clef PGP sous un
faux nom car il n y a pas de vérification. Quelqu'un peut être victime d'une
usurpation de DNS et être redirigé vers un faux serveur PGP. Pour faire cette
vérification, Alice récupère de l'annuaire une clé publique de Bob signée par Charlie
à qui elle fait confiance (elle connaît la clef publique de Charlie).

Remarque : Graphe de Confiance

La relation entre Alice et Charlie peut être généralisée aboutissant à un graphe de
confiance. Le poids des arêtes est le niveau de confiance :
 Confiance inconnue
 Aucune confiance
 Confiance partielle
 Confiance totale
Avant d'envoyer un courrier à Bob, Alice doit trouver un chemin de confiance qui la
mène à Bob, calculer la confiance qu'elle a dans la personne qui a signé la clé de
Bob, décider si elle considère la clef de Bob valide

Image 13 Graphe de Confiance

Calcul du niveau de confiance dans le modèle PGP

Les poids des confiances sur un même chemin se multiplient. Les poids des
confiances sur des chemins disjoints se rajoutent.
On considère les poids suivants:
 Confiance totale = 1
 Confiance partielle = 0.5
 Aucune confiance = 0

15
 PKI : Infrastructures à clés publiques

Exemple
Dans le graphe de confiance suivant :

Image 14 Exemple de calcul de la confiance

La confiance de Alice en Bob est de 0.5. La confiance de Alice en Etienne est de 0.5.
Bob et Etienne délivrent chacun un certificat à Derrick. La confiance calculée de
Alice en Derrick est de 0 .0+0.5=1.

Révocation des clés PGP

Retirer la clé déposée sur un serveur PGP ne suffit pas. Les utilisateurs ont stocké la
clé sur leurs disques. De ce fait, la clé est répliquée sur d'autres serveurs.
Solution:
 Générer un certificat de révocation
 Envoyer ce certificat sur le serveur PGP
 Envoyer le certificat aux correspondants réguliers

16
Testez vos
II -

II
connaissances

Exercice : Man in the Middle 23

Exercice : Certificat numérique 24
Exercice : SSL 24

A. Exercice : Man in the Middle

Soit le protocole cryptographique suivant
M1 : B ==> A : [Link]
M2 : A ==> B : {m}PKb
Ce protocole est vulnérable à une attaque de type « man in the middle ». Un intrus
"I" peut attaquer ce protocole comme suit :

I intercepte M1
I bloque M1
I remplace M1 par : M1 : I ==> B : [Link]
I intercepte M2
I bloque M2
I remplace M2 par : M2 : I ==> A : {m}PKa

I intercepte M1
I bloque M1
I remplace M1 par : M1 : I ==> A : [Link]
I intercepte M2
I bloque M2
I remplace M2 par : M2 : I ==> B : {m}PKb

I intercepte M1
I bloque M1
I remplace M1 par : M1 : I ==> A : [Link]
I intercepte M2
I bloque M2
I remplace M2 par : M2 : I ==> B : {m}PKb

17
 Testez vos connaissances

B. Exercice : Certificat numérique

L'objectif d'un certificat numérique est d'assurer

La confidentialité de la signature numérique du porteur du certificat

L'authenticité de la clé publique correspondante à la clé privée du porteur du

certificat

La correspondance entre l'identité et la clé publique correspondante à la clé

privée du porteur du certificat

L'authenticité de la signature numérique de l'autorité de certification

C. Exercice : SSL
Le protocole SSL/TLS permet d'assurer

Le contrôle d'intégrité

La confidentialité des échanges entre le client et le serveur

L'authentification de l'origine de données

L'authentification du serveur optionnellement

L'authentification du client optionnellement

18
Série d'exercices
III -

III
II: Infrastructures
à clés publiques

Télé-déclaration des revenus 25

Travail Pratique : Sécuriser l'échange entre un client et un
serveur web Apache avec SSL 26
Déploiement de PGP 29
Cabinet Notarial 30

A. Télé-déclaration des revenus

Le ministère des finances décide d'automatiser la déclaration des revenus annuels
imposables. Il existe une recette des impôts au niveau de chaque mairie, mais vu
l'absence d'un réseau privé reliant ces structures administratives, le ministère
décide de réaliser l'opération à travers le web. Ainsi, chaque personne physique ou
morale concernée (commerçant, agriculteur, entreprise, ...) devrait pouvoir faire sa
déclaration de revenus en utilisant un navigateur web. Le ministère met à
disposition des citoyens un site web qui collectera les revenus déclarés en vu de les
stocker dans une base de données. Le ministère fait appel à votre expertise et vous
remet un cahier de charge, dans lequel on peut souligner les points suivants :
1. Le système de télé-déclaration fiscale doit être conforme à la loi 15-04 sur la
certification électronique. Le texte de loi est joint à ce cahier de charge (cf.
Loi Certification).
2. Les déclarations doivent rester confidentielles ;
3. Chaque déclarant doit être authentifié avant de procéder à la déclaration ;
4. Afin de donner une valeur légale aux déclarations, les déclarants doivent
signer numériquement leur déclaration ;
5. Les structures du ministère ne seront pas disposées à recevoir les
déclarants. Tout rapprochement nécessaire de l'administration fiscale devrait
se faire au niveau des recettes des impôts des mairies.

Question 1
Proposez une architecture, à base d'une PKI, pour sécuriser le système de télé
déclaration tout en répondant au cahier de charge du ministère des finances.

Question 2
Citez puis expliquez succinctement comment les protocoles et mécanismes
cryptographiques, que vous introduisez, réalisent les impératifs du cahier de
charge.

19
 Série d'exercices II: Infrastructures à clés publiques
Question 3
Expliquez comment déployer votre système à l'échelle nationale.

Question 4
Expliquez en quelques lignes, aux citoyens, comment procéder pour réaliser leur
déclaration d'une manière sécurisée.

B. Travail Pratique : Sécuriser l'échange entre un

client et un serveur web Apache avec SSL

Objectifs
Se familiariser avec les concepts d'une infrastructure à clés publiques :
 Déploiement de PKI
 Création d'une autorité de certification
 Création de certificats numériques
 Signature de certificats numériques
Configuration de la sécurité d'un serveur web Apache avec le protocole SSL
Configuration d'un navigateur Web pour l'authentification d'un client et d'un serveur
web avec SSL.

Installation et environnement logiciel

Pour avoir plus de détails sur les commandes de OpenSSL et leurs options, vous
pouvez vous référer au manuel suivants :

[Link]
Document 1 Man Page de OpenSSL
Pour réaliser ces ateliers vous devez disposer de OpenSSL, Apache et TinyCA, qui
sont déjà installés sur la machine virtuelle.

Attention
 Penser toujours à sauvegarder la dernière version d'un fichier de
configuration avant une nouvelle modification.

1. Créer un espace de Publication Web Apache

Syntaxe
1. Création d'un répertoire pour le test "delta" sous le DocumentRoot de
apache: "htdocs"
2. Modifier le fichier lampp/etc/[Link] en conséquence :
- #DocumentRoot "/opt/lampp/htdocs"
- DocumentRoot "/opt/lampp/htdocs/delta"
- #<Directory "/opt/lampp/htdocs">
- <Directory "/opt/lampp/htdocs/delta">
3. Mettre une page web dans ce répertoire "delta": "[Link]"
4. Relancer apache : sudo ./lampp restart
5. Tester avec le navigateur: [Link]
Ceci va constituer la zone libre accès du serveur

2. Créer un répertoire pour la zone sécurisée

20
 Série d'exercices II: Infrastructures à clés publiques

Syntaxe
1. Sous "htdocs/delta" créer un répertoire "secure"
2. Modifier le fichier config "[Link]" en conséquence. Ce fichier se
trouve sous "/opt/lampp/etc/extra".
- #DocumentRoot "/opt/lampp/htdocs"
- DocumentRoot "/opt/lampp/htdocs/delta/secure"
3. Mettre une page web dans ce répertoire "delta/secure": "[Link]"

3. Créer les certificats et les clés pour la CA et le

Serveur Web

21
 Série d'exercices II: Infrastructures à clés publiques

Syntaxe
1. Création du certificat du CA
Utiliser TinyCA pour générer la clé privée et certificat du CA (commande
tinyca2)
2. Sous le répertoire "lampp/etc" créer un répertoire "delta" et deux sous-
répertoires "delta/certifs" et "delta/cles". Ces deux répertoires serviront à
stocker les certificats et les clés de CA et de notre serveur.
3. Création du certificat du serveur
Utiliser TinyCA pour générer une clé privée du serveur Web dans le fichier
/opt/lampp/etc/delta/cles/[Link] et un certificat signé par la CA
dans /opt/lampp/etc/delta/certifs/[Link]
Lors de la création du certificat du serveur web, il faut donner le nom du
serveur qui est indiqué dans /opt/lamp/etc/extra/[Link], par
exemple : localhost, et laisser le champ email vide.
Quand vous exportez la clé privée du serveur, choisissez (Sans mot de passe
PKCS12) pour éviter que Apache ne se bloque en l'attente de saisie du mot
de passe.
4. Modifier le fichier config "[Link]" en conséquence. Ce fichier se
trouve sous "lampp/etc/extra".
- #SSLCertificateFile /opt/lampp/etc/[Link]/[Link]
- SSLCertificateFile /opt/lampp/etc/delta/certifs/[Link]
- #SSLCertificateKeyFile /opt/lampp/etc/[Link]/[Link]
- SSLCertificateKeyFile /opt/lampp/etc/delta/cles/[Link]

4. Les tests

Syntaxe
1. Relancer apache
2. On teste "[Link]
Ca nous demande si on accepte le certificat du serveur: On regarde les
détails du certificat et on accepte temporairement (pour la session)
Redémarrer le navigateur pour voir que de nouveau le certificat n'est pas
accepté automatiquement.
3. Exporter le certificat du CA en utilisant tinyca2
Inclure ce certificat du CA dans le navigateur et on se connecte de nouveau,
si le certificat respecte certaines règles il sera accepté automatiquement car
signé par un CA reconnu par le navigateur

5. Analyse et comparaison des échanges

Analyser et comparer les échanges entre le client (navigateur) et le serveur

(serveur web) dans les deux configurations : HTTP simple, HTTPS.
Pour cela, utilisez WireShark (un sniffer)

6. Ajouter un certificat Client

Syntaxe
1. Création du certificat du client
En utilisant TinyCA générer la clé du Client dans
/opt/lampp/etc/delta/cles/[Link] et un certificat Client dans
/opt/lampp/etc/delta/certifs/[Link]
2. Modification de apache en conséquence pour que le serveur exige un
certificat pour le client:
#SSLCACertificatePath /opt/lampp/etc/[Link]
#SSLCACertificateFile /opt/lampp/etc/[Link]/[Link]

22
 Série d'exercices II: Infrastructures à clés publiques
SSLCACertificatePath /opt/lampp/etc/delta/certifs/
SSLCACertificateFile /opt/lampp/etc/delta/certifs/[Link]
#SSLVerifyClient require
#SSLVerifyDepth 10
SSLVerifyClient require
SSLVerifyDepth 2
3. On relance apache et on teste
4. On ajoute le certificat client dans le navigateur
Pour mozilla/firefox un certificat en format PKCS12 est demandé
En utilisant TinyCA on peut générer le certificat dans ce format
conf\delta\certifs\clientcert.p12
Dans le navigateur on ajoute "clientcert.p12" dans "your certificates"
5. On relance apache et on teste

C. Déploiement de PGP
Alice, directrice d'une agence d'une société, doit faire parvenir régulièrement un
compte-rendu d'activité au responsable qualité de la société. Pour cela, ce dernier
préconise à tous les directeurs d'agences d'utiliser PGP afin de chiffrer et de signer
les données transmises ; il déconseille en revanche d'utiliser un graphe de
confiance pour valider les clefs.
Après avoir installé PGP sur son ordinateur, Alice a généré une paire de clefs
asymétriques (clef publique / clef privée) pour le chiffrement et la signature des
données. Elle conserve cette paire de clefs uniquement sur le disque dur de son
ordinateur.

Question 1
Quel moyen permet d'éviter que n'importe qui puisse lire la clef privée d'Alice sur
son disque dur ?

Question 2
Donner la démarche précise que doivent accomplir Alice et le responsable qualité
avant de pouvoir s'échanger de manière sûre des informations par courrier
électronique.

Question 3
On suppose maintenant que l'étape de la question précédente a été réalisée. Alice
souhaite envoyer son compte-rendu d'activité. Elle chiffre le fichier mais oublie de le
signer. A sa grande surprise, PGP ne lui demande aucun mot de passe, Pourquoi ?

Question 4
Etant donné que les systèmes de chiffrement asymétriques sont beaucoup plus
lents que les systèmes de chiffrement symétrique, PGP n'utilise pas directement la
clef publique du destinataire pour chiffrer les données proprement dites. Expliquer
le procédé réellement utilisé par PGP.

Question 5
Détailler ce procédé si le responsable qualité envoie un même courrier électronique
à plusieurs directeurs d'agence.

Question 6
Satisfaite, des services de PGP, Alice souhaite également l'utiliser pour chiffrer les
sauvegardes de son disque dur : elle chiffre son répertoire avec PGP puis
sauvegarde le fichier obtenu sur une bande magnétique. A quel risque s'expose-t-
elle si son disque dur tombe en panne ?
Le responsable qualité de la société s'aperçoit qu'il est fastidieux de gérer ce
procédé et préfère abandonner PGP au profit d'un service accessible via un site web

23
 Série d'exercices II: Infrastructures à clés publiques
en utilisant un serveur HTTPS.

Question 7
Quel est le protocole de sécurité sur lequel est fondé HTTPS ?

Question 8
Le responsable qualité a obtenu un certificat X-509 pour le site web auprès d'une
autorité de certification. Quel est le but de ce certificat ?

Question 9
Outre la signature de l'autorité de certification, quelles sont les deux onformations
essentielles que l'on trouve de manière générale dans un certificat ?

Question 10
Lorsque Alice se connecte sur le site web, son navigateur vérifie la validité du
certificat fourni. Quelle clef sera utilisée par son navigateur ? Comment l'aura-t-il
obtenue ?

D. Cabinet Notarial
La fédération nationale des cabinets notariaux (FNCN) souhaiterait dématérialiser
les fonctions notariales des cabinets y compris la signature des actes. Elle fait appel
à votre expertise pour l'aider à réaliser ce projet.
Elle vous demande de concevoir un système qui permettra l'implémentation d'un
parapheur électronique qui permet aux cabinets de délivrer les actes à leurs clients
pour signature en toute confidentialité, intégrité et en assurant l'authentification
des contractants.
Pour des fins lucratives, la FNCN voudrait avoir la responsabilité de gestion des
certificats de ses clients.
La FNCN vous demande de respecter scrupuleusement la loi 15-04 (cf. Loi1504
certification Electronique) portant sur la certification électronique du 11 Rabi Ethani
1436 correspondant au 1er février 2015 promulguée au journal officiel N°06 dont un
extrait est joint à ce document.

Question 1
En vous conformant à la loi 15-04, réalisez une conception du système souhaité par
la FNCN.

Question 2
Rédigez une feuille de route à destination de la FNCN afin de réaliser ce système
(démarches à suivre).

Question 3
3. Donnez une spécification technique du parapheur électronique à la lumière de la
conception proposée et la loi 15-04.

24