ENIG AU : 2017-2018

L’infrastructure de gestion de clés IGC

Public Key Infrastructure PKI
1. Infrastructure de Gestion de Clé
PKI : 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 »

1.1 Les composants d’une PKI

Notons ces 5 éléments qui composent une PKI :

• Autorité de certification (Certificate Authority CA)

Créer et distribuer des certificats, révoque les certificats

• Autorité d’enregistrement (Registration Authority RA)

Vérifier la validité de certificats et enregistre les demandes d’obtention de certificat.

• Dépôt de listes de certificats révoqués (CertificateRevocationList CRL)

Liste des certificats révoqués (raison ; corruption de la clé privée, le licenciement,..)

• Dépôt de certificats (Certficate Repository)

Un site électronique qui détient et rend publique les certificats et les listes de
révocation

• L’utilisateur de certificat (Certificate User)

Une entité qui utilise les certificats pour connaitre la clé publique d’autres entités

1.2 Les 5 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. Voir figure 1.

1
ENIG AU : 2017-2018

Figure 1: Délégation de Certification

• Modèle oligarchique

Déploiement des produits (comme les navigateurs 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

Remarque :

Il y a plusieurs Outils pour Utiliser les certificats et les PKIS comme :

Les PKI open source, ils sont utilisés par les entreprises qui veulent avoir leur propre autorité
de certification pour leurs employés et les applications dans les échanges intranet, exemples :
Oracle iPlanet Web Server, Oracle iPlanet Web Proxy Server, OpenCA
[Link] , IDX-PKI , EJBCA [Link]

Les librairies JAVA comme:

API Java : Java Cryptography Extention (JCE) et Java Secure Socket Extention (JSSE)
contient SSL/TLS
API Java for XML
JSR 104 XML Trust Service APIs
JSR 105 XML Digital Signature APIs ([Link])
JSR 106 XML Digital Encryption APIs
Pour plus de détails, lire ce cours : [Link]

2
ENIG AU : 2017-2018

2. Certificat de clés publique

Cette approche (1978) consiste à employer des certificats pouvant être utilisés par des
participants pour échanger des clefs sans entrer en contact avec une autorité de clés publiques,
d’une façon fiable comme si les clefs avaient été obtenues directement à partir d’une telle
autorité.

Chaque certificat contient une clef publique et des informations supplémentaires (la période
de validité, les droits d’utilisation, etc.). Il est créé par une autorité de certification CA (cette
situation est illustrée à la figure 2), et est donné au participant disposant de la clef privée
assortie. Un participant fournit l’information sur sa clé à un autre en transmettant son
certificat. Son contenu est signé par la clé privée du CA.

Figure 2: Certificats de clés publiques

Plusieurs propriétés permettent de garantir une meilleure sécurité :

– N’importe quel participant peut lire un certificat pour déterminer le nom et la clé
publique du propriétaire du certificat.
– N’importe quel participant peut vérifier que le certificat provient réellement du CA
et n’est pas contrefait.
– Seul le CA peut créer et mettre à jour des certificats.
– Tous les participants peuvent vérifier la validité des certificats (Denning - 1983)
Pour mieux comprendre ce concept, illustrons-le par un exemple : si vous commandez des cds
sur Internet, comment être sûr que vous envoyez bien votre numéro de carte bleue au
commerçant, et non à un pirate qui aurait usurpé son identité et donné sa propre clé publique ?
3
ENIG AU : 2017-2018

Pour passer un examen, il vous faut prouver votre identité grâce à une carte d’identité, un
passeport ou un permis de conduire. Un organisme supérieur (l’Etat) a signé ces certificats,
s’assurant auparavant (par un acte de naissance,...) qu’il s’agit bien de vous.

2.1 Principe d’usage :

Les certificats numériques fonctionnent sur le même principe. Alice veut certifier que sa clé
publique lui appartient. Elle envoie sa clé à un organisme de certification, ainsi que
différentes informations la concernant (nom, email, etc...). Cet organisme vérifie les
informations fournies par Alice, et ajoute au certificat son propre nom, une date limite de
validité, et surtout une signature numérique. Cette signature est réalisée grâce à sa clé privée
et à un algorithme de hachage laissé au choix, bien que le RSA et le SHA soit maintenant
préféré. En résumé, l’autorité de certification fournit un certificat tel que

CA = EKRauth[T, IDA,KUa]

où EKRauth représente la signature apposée au certificat, T est un timestamp, IDA est

l’ensemble des informations propres à l’entité A et KUa est la clé publique de A.

Lorsque B veut envoyer un message à A ou simplement vérifier la validité du certificat que A

lui a envoyé, il applique la clé publique de l’autorité de certification. Cette action permet de
vérifier que le certificat est bien authentique :

DKUauth[CA] = DKUauth[EKRauth[T, IDA,KUA]] = (T, IDA,KUA)

Remarque:

Les certificats sont utilisés dans les protocoles IPSEC, SSL, S/MIME (PGP), code signing
(Java, Javascript, ActiveX,…)

Les formats et types de certificats sont : X509 PKIX, PGP (Pretty Good Privacy), SPKI/SDSI
(Simple PKI/ Simple Distrubuted Security Inrfrastructure)

2.2 Génération de la paire de clé

a) Par le client

Le CA ne connait pas la clé privée. Dans le cas de perte de la clé ou le départ d’un employé,
on ne peut plus lire les mails reçus chiffrés.

Il faut Aussi une étape de « Proof of possession », le client dialogue avec le CA pour prouver
qu’il détient la clé privée du certificat à signer.

b) Par le CA

Les avantages sont :

- La génération est plus sure du nombre aléatoire pour la fabrication de la paire de clés.
- L’archivage de la clé privée

4
ENIG AU : 2017-2018

- Historique des paires de clés

- Transfert sécurisé de la paire de clés vers le client (en utilisant par exemple le
PKCS#12 Personal Information Exchange Syntax Standard)
Remarque :
Pour plus de détails sur les PKCS Public Key Cryptographic Standars (ils sont 15) visitez
la page [Link]

3. Les certificats - Service d’authentification X.509

Il s’agit d’une partie de la norme de service d’annuaire X.500, qui regroupe des serveurs
distribués maintenant une base de données d’informations. Le service définit le cadre pour des
services d’authentification, internationalement admis pour construire un certificat de clé
publique. L’annuaire peut stocker des certificats de clé publique et les clés publiques des
utilisateurs correspondants. Ces certificats sont également signés par une autorité de
certification. Il utilise la cryptographie à clé publique et les signatures digitales. Aucun
algorithme de chiffrement n’est imposé, mais le RSA est recommandé. N’importe quel
utilisateur ayant accès au CA peut obtenir un certificat de celui-ci, mais seul le CA peut
modifier un certificat. Comme il est difficile de forger un certificat, on peut sans trop de
risque le placer dans un annuaire public.

La figure 3 illustre le format d’un certificat. L’exemple donné concerne un certificat signé par
RSA et MD5.

Figure 3: Format standard et exemple de certificat X.509

5
ENIG AU : 2017-2018

A tout moment, nous pouvons pour valider un certificat numérique X.509 avec le protocole
OSCP (Online Certificate Status Protocol). Ce protocole est une alternative réglant certains
des problèmes posés par les listes de révocation de certificats (CRL)

Les certificats ont une période de validité. On doit pouvoir le retirer avant l’échéance
(révoquer) car il se peut que la clef privée de l’utilisateur soit compromise, que l’utilisateur ne
soit plus certifié par ce CA ou encore que le certificat du CA soit compromis.

Les CA maintiennent donc une liste des certificats retirés. Cette liste porte le nom de "liste de
révocation de certificats" (CRL) et est vérifiable par tout utilisateur.

4. Procédures d’authentification avec les certificats

X.509 inclut trois procédures alternatives d’authentification :

3.1 One-Way (utilisée dans les mails)

Un seul message (A B) est utilisé (voir figure 4) pour établir à la fois

– l’identité de A et l’origine du message,

– le destinataire du message,

– l’intégrité et l’authenticité du message.

Le message inclut l’horodateur (tA), le nonce (rA), l’identité de B (IDB) et être signé par A
(sgnData)

Figure 4: Authentification unidirectionnelle (One-Way)

3.2 Two-Way
Deux messages (A B, B A) sont utilisés (voir figure 5). Le principe est le même que
pour l’authentification One-Way mais détermine plus de caractéristiques des entités :

– l’identité de B et que cette réponse est de B,

– la réponse est destinée à A,

– l’intégrité et l’authenticité de la réponse.

La réponse inclut le nonce de A, l’horodateur et le nonce de B.

6
ENIG AU : 2017-2018

Figure 5: Authentification bidirectionnelle (Two-Way)

3.3 Three-Way
Trois messages sont échangés (A B, B A, A B) permettant une authentification sans
horloge synchronisée (voir figure 6).

La réponse de A à B contient la copie signée du nonce de B ce qui signifie que les horodateurs
n’ont pas besoin d’être vérifiés ou comptés.

Figure 6: Authentification tridirectionnelle (Three-Way)