Vous êtes sur la page 1sur 122

Certificats X509

&
Infrastructure de Gestion de
Clés

Serge Aumont CRU


Claude Gross CNRS/UREC
Philippe Leca CNRS/UREC
Rappel des services de base en sécurité
(1)
ƒ Authentification
• Assurance de l’identité d’une personne, d’un objet
• Carte nationale d’identité, passeport
ƒ Intégrité
• Garantie de non modification par un tiers d’un contenu
(message, document ou programme par exemple)
• Document manuscrit : simple
ƒ Confidentialité
• Protection contre la « lecture » non autorisée par un tiers:
garantir le secret de l’information transmise ou archivée
• Coffre -fort, pli cacheté
Coffre-fort,

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 2


Rappel des services de base en sécurité
(2)
ƒ Non -répudiation
Non-répudiation
• Pour que l’émetteur ne puisse pas nier l’envoi
• Et le récepteur ne puisse pas nier la réception
• Transactions financières – commerciales

ƒ Contrôle d’accès
• Autorisations ou non d’accès à des objets

ƒ Anonymat (non traçabilité), vote électronique


traçabilité),
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 3
Pourquoi chiffrer ? 1/2
ƒ Depuis la nuit des temps, les hommes (surtout
les militaires) ont pratiqué l’espionnage (et le
contre -espionnage).
contre-espionnage).

ƒ Le chiffrement des messages est donc né avec


les armées (au moins avec les armées de
Rome).

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 4


Pourquoi chiffrer ? 2/2
ƒ Aujourd’hui le chiffrement est partout :
• Carte vitale
• Téléphone GSM
• Anti -vol de voiture
Anti-vol
• Carte bancaire
• Télévision à péage
• Mot de passe informatique
• Services sensibles de l’l’internet
internet …
ƒ Il conditionne la sécurité du système
d’information et la confidentialité des
communications
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 5
Vocabulaire
ƒ CHIFFRER :
transformer à l’aide d’une convention secrète (clef) des
informations claires en informations inintelligibles par
des tiers n’ayant pas connaissance du secret
ƒ DECHIFFRER :
retrouver les informations claires
claires,, à partir des
informations chiffrés en utilisant la convention secrète
de chiffrement
ƒ DECRYPTER :
retrouver l’information intelligible, à partir de
l’information chiffrée sans utiliser la convention
secrète de chiffrement

ƒ ““crypter,
crypter, encrypter ”: pas de sens clair
encrypter”: clair..
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 6
Un peu d’historique
ƒ L’histoire du chiffrement montre que ce qui est
réputé sûr un jour devient naïf.
ƒ L’augmentation de la puissance des machines
altère petit à petit la fiabilité des algorithmes de
chiffrement.
ƒ Les progrès théoriques peuvent brusquement
casser certaines technologies. Exemple : gain
récent d’un facteur 10 sur la complexité de la
réduction en facteurs premiers

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 7


Exemples
ƒ César : décalage par rotation des lettres de
l’alphabet.
ƒ Evolutions : remplacer le « shift » par une
substitution (bijection dans l’alphabet)
ƒ Méthode très fragile : ne résiste pas à une
simple analyse statistique de la fréquence
des caractères.
ƒ les SS-tables
-tables : substitutions dépendantes de
la position de la lettre dans le message (la
table de substitution est choisie en fonction
du rang de chaque caractère)
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 8
Chiffrement de Vignère
ƒ Utilisé par les nazis sous forme d’une machine
à roues dentées : Enigma
ƒ Une clef de n caractères.
ƒ On découpe le message en blocs de la même
longueur que la clef.
ƒ On effectue une substitution de chaque
caractère de chaque bloc en l’additionnant avec
le caractère de la clef du même rang.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 9


Chiffrement de Vignère

U A V • Avec une clef de 4 caractères dans un


N B P alphabet de 26 caractères, le nombre de
I B K substitutions est de 264=456976
V Y U • Enigma : 28 roues dentées (clefs de 28
E A F caractères). 2628=4.162x1039
R B T • Non violé pendant toute la 2eme guerre,
S B U mais considéré aujourd’hui comme faible
I Y H parce que la connaissance d’un message
chiffré permet de retrouver la clef.
T A U
E B G

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 10


Masque jetable 1/3
ƒ 1917 Gilbert Vernam
ƒ Pour chiffrer un message de n caractères, on
utilise une clef secrète composée d’une suite
aléatoire de bits d’une longueur au moins égale
au message.
ƒ Le message chiffré est un simple ou exclusif bit
à bit entre le message et la clef.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 11


Masque jetable 2/3

1 0 1 0 1
1 1 0 1 1
0 1 1 1 0
1 1 0 1 1
0 0 0 0 0
0 0 0 0 0
1 1 0 1 1
0 1 1 1 0
0 0 0 0 0

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 12


Masque jetable 3/3
ƒ Le masque est appelé « clef secrète»
ƒ C’est un exemple de chiffrement symétrique : une clef
unique permet de chiffrer ou de déchiffrer
ƒ Méthode très efficace : si les clefs sont bien aléatoires,
le cryptogramme a une bonne entropie (dispersion
statistique)
ƒ Comment partager des clefs secrètes ayant une telle
taille ?
ƒ La connaissance d’un message en clair et de sa forme
chiffrée permet de déduire la clef secrète

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 13


Sécurité de la cryptographie
ƒ Elle repose sur trois facteurs
facteurs::
• La qualité des algorithmes : la qualité d’un algorithme
repose sur sa fiabilité mathématique et surtout pas sur le
secret de sa réalisation

• L’implémentation des algorithmes : il est souvent bien plus


facile de contourner une mauvaise implémentation que
d’attaquer un algorithme

• La gestion des clefs : une faille dans la gestion des clefs


peut remettre en cause la fiabilité de l’ensemble

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 14


Les attaques 1/4

ƒ Il existe de nombreuses méthodes d’attaque


parfois extrêmement sophistiquées.

ƒ Force brute : essayer toutes les clefs


possibles. Principal danger : l’augmentation
de la puissance des machines. Parades :
augmenter la longueur des clefs, choisir des
algorithmes coûteux

ƒ En 97 : 3h pour casser une clef 40 bits


JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 15
Les attaques 2/4

ƒ Analyse statistique :
ƒ basée sur les propriétés des messages en clair
(exemple : le «e» représente 14.5 % des caractères
utilisés dans un texte en français).

ƒ La méthode utilisée par Morse pour optimiser son


code est dépassée. Il existe des tables statistiques
pour des motifs de plusieurs lettres.

ƒ Parade : utiliser un algorithme tel que le cryptogramme


ait une entropie maximale

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 16


Les attaques 3/4
ƒ Attaque à texte en clair connu.
• L’attaquant connaît un message en clair et son équivalent
chiffré. Il tente d’en déduire la clef.

ƒ Attaque de l’algorithme.
• Par exemple, pour les algorithmes qui génèrent une clef
secrète aléatoirement, il arrive que l’aléa ne soit pas parfait et
donc reproductible par l’attaquant.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 17


Les attaques 4/4
ƒ Le plus souvent les attaques exploitent le mode
d’usage de l’algorithme de chiffrement, pas sur le
chiffrement lui même. Exemples :
1. Analyse du nombre de caractères envoyés et de l’écho du
serveur pour calculer la longueur du mot de passe (pas
d’écho pendant la frappe du mot de passe)
2. Analyse statistique de la vitesse de frappe des caractères
en fonction de leur position sur le clavier !
3. Force brute en exploitant 1 & 2
ƒ Pas besoin de grandes compétences pour mettre
en œuvre ces méthodes en utilisant des kits de
hackers
hackers..

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 18


Chiffrement : confidentialité
Clef de chiffrement

TE Algorithme de chiffrement
TEX ir
la
en c
Alice
Internet

TE
TEX ir
la
en c Algorithme de déchiffrement

Bob
Clef de déchiffrement

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 19


Chiffrement à clefs symétriques (1/2)
ƒ clef de chiffrement = clef de déchiffrement
clef secrète
ƒƒ DES
DES :: Data
Data Encryption
Encryption Standard
Standard
•• Clef
Clef de
de 56
56 bits
bits
•• Standard
Standard de 1977
de 1977
ƒ 3DES : 3 passes dans DES en utilisant 2 ou 3 clefs
ƒ 3DES : 3 passes dans DES en utilisant 2 ou 3 clefs
distinctes (112 ou 168 bits)
distinctes (112 ou 168 bits)
ƒ RC2, RC4, RC5 : clef de 1 à 1024 bits
ƒƒ RC2, RC4, RC5 : clef de 1 à 1024 bits
IDEA (International Data Encryption Algorithme)
ƒƒ IDEA
AES (International
(Advanced Data Encryption
Encryption Algorithme)
Standard), issu d’un
concours international pour remplacer DES. Standard
ƒ AES (Advanced Encryption Standard), issu d’un
concours international pour remplacer DES. Standard
publié en Avril 2001 20
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés
Chiffrement à clefs symétriques (2/2)
ƒ Chiffrement et déchiffrement rapide
ƒ Comment se partager les clefs secrètes ? Il faut
un canal sûr.
ƒ Nombre de clefs pour assurer la confidentialité
au sein d’un groupe de n personnes :
2 1
3 3
4 6
5 10
n n(n-1)/2

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 21


Chiffrement à clefs asymétriques (1/3)

ƒ Principe introduit en 1976 par Diffie et Hellman


ƒ Clef de chiffrement ≠ clef de déchiffrement
ƒ Couple de clefs (créées ensemble) : bi-clef
ƒ Impossible de découvrir une clef à partir de l’autre
ƒ Tout texte chiffré avec une clef est déchiffré avec
l’autre et uniquement avec celle-ci
ƒ Concrètement :
• 1 bi-clef / utilisateur ou machine ou application
• Créé par l’utilisateur sur son poste ou …
• 1 clef publique : que l’on rend publique (annuaire)
• 1 clef privée : que le propriétaire est le seul à connaître
• Chiffrement avec une clef / Déchiffrement avec l’autre
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 22
Chiffrement à clefs asymétriques (2/3)
Clef publique de Bob

E X TE Chiffrement asymétrique
T ir
cl a
en
Alice
Internet

E X TE
T ir
cl a
en Déchiffrement asymétrique

Bob
Clef privée de Bob

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 23


Chiffrement à clefs asymétriques (3/3)
ƒ RSA (Rivest, Shamir, Adelman): 1976
• Devenu public (fin des droits de la sté RSA) depuis 09/2000
• Le principe est basé sur le fait qu'il est très difficile de décomposer
en facteurs premiers un nombre (si le nombre est suffisamment
grand).

ƒ Si annuaire des clefs publiques : permet une utilisation du


chiffrement de manière planétaire

ƒ Problème : temps de chiffrement et de déchiffrement


• RSA : 100 à 1000 fois plus lent que Triple DES
Î Solution: mixte chiffrement asymétrique et chiffrement symétrique

ƒ Algorithmes de chiffrement : publics


Secret : certaines clés

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 24


Robustesse de RSA
Non divulgation de la clef privée
Difficulté à décomposer en facteurs premiers un nombre
Fondée sur donné (suffisamment grand).
L’absence de méthodes mathématiques pour déduire
la clé privée de la clé publique

RSA155 : un nombre de 155 digits codé sur 512 bits factorisé en


sept. 99 !!! (300 ordinateurs, 1 Cray, 4 mois de calcul soit 32 ans
pour un 250 Mhz)

Avancée théoriques en matière de chiffrement et de déchiffrement

Évolution de la capacité des machines

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 25


Chiffrement: clef aléatoire (1/2)
ƒ Pour contourner les mauvaises performances des
traitements avec les algorithmes asymétriques
ƒ Durant une session (courte dans le temps) ou lors d’un
échange de document:
• Choix d’une clef (aléatoire) par un des interlocuteurs
• Transfert de cette clef chiffrée de manière asymétrique à
l’autre interlocuteur
• Ensuite, utilisation de cette clef pour chiffrer de manière
symétrique le texte
ƒ Nombre de bytes chiffrés en asymétrique très petit (la
clef) / nombre de bytes chiffrés en symétrique (le texte)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 26


Chiffrement : clef aléatoire (2/2)
Clef publique de Bob

ρ ειντε ιντε
Ε µπ ρ ε
Clef aléatoire Chiffrement
Εµπ
asymétrique ❅■
✥✸ ✴✥ ❒
✴ ❁❉
❃●

❅■
TE Chiffrement ✸ ✴✥ ❒
TEX ir symétrique ✴ ✥
● ❁❉ Internet
la ❃
en c
Alice

Clef privée de Bob

Bob ρ ειντε
Clef aléatoire Déchiffrement
Ε µπ
asymétrique ❅■
✸ ✴✥ ❒
E X TE ✴ ✥
❁❉
T ir ❃ ●
cl a Déchiffrement symétrique
en
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 27
Chiffrement: longueur des clefs (1/2)
ƒ Décrypter
• Déchiffrer sans posséder la clef de déchiffrement
• Nombreuses méthodes. Limite : rapidité des calculateurs
ƒ Plus la clef est longue (nombre de bits), plus il est
difficile de décrypter
• Avec un algorithme de chiffrement solide (bon
mathématiquement)
ƒ La puissance des machines augmente
• La taille des clefs utilisées doit augmenter
• La législation s’adapte :
Utilisation des produits de chiffrement en France :
ƒ Avant 1999 : libre pour des clefs jusqu’à 40 bits
ƒ Après 1999 : libre pour des clefs jusqu’à 128 bits
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 28
Chiffrement: longueur des clefs (2/2)
ƒ ne pas confondre algorithmes à clefs secrètes (clefs
couramment entre 40 et 256 bits) et algorithmes à
clefs publiques (clefs couramment entre 512 et 2048
bits), pour lesquels la longueur de la clef n'est pas
comparable :
• pour les algorithmes à clefs secrètes, la référence est
l'attaque par force brute (moyenne 2 n-1n-1 essais pour retrouver

la clé)
• pour les algorithmes à clefs publiques, la robustesse est
basée sur la difficulté mathématique à résoudre le problème
sur lequel est basé l'algorithme (l'attaque par force brute n'a
guère de sens)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 29


Signature électronique (1/2)
ƒ Un mécanisme pour l’authentification et l’intégrité
ƒ Utilise une fonction de hachage (appliquée sur le
document)
• Génère une suite de bits de taille fixe (très petite)
• Empreinte ou condensé
• Un bit du texte initial modifié ⇒ Empreinte différente
• MD5 (Message Digest) : empreinte de 128 bits
• SHA (Secure Hash Algorithm) : empreinte de 160 bits
• On chiffre l’empreinte avec la clef privée de l’émetteur

ƒ Outils courants : permettent de signer et de chiffrer


JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 30
Signature électronique (2/2)
Clef privée de
X TE X TE Alice
E X TE
T E T E T ir
cl air lair cl a
en e n c en
Fct
de h r e inte Chiffrem
ent
ach
a ge Emp
Alice Internet

E X TE
in te T
Em pr e Fct de hachage
n clair
e
E X TE
inte T
Em pr e
n clair
Dé c
e
hiff
Bob re m
ent
égalité ?
Clef publique de
Alice
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 31
Chiffrement à clefs asymétriques

ƒ Chaque utilisateur a un bibi-clef


-clef

ƒ Questions :
• la clé est -elle bien celle appartenant à la personne avec qui
est-elle
les échanges sont envisagés?

• le possesseur de cette clé est-il « digne de confiance »?


est-il

• la clé est -elle toujours valide?


est-elle

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 32


Certificats X509 (1)
ƒ Une « autorité de confiance » signe avec sa clé
privée un document contenant :
• L’identité d’une entité possédant un couple de clé
• La clé publique
• Des informations décrivant l’usage de cette clé
•…
ƒ Le résultat est un certificat
ƒ L’ « autorité de confiance » est appelée
Autorité de Certification

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 33


Certificat X509 (2)
ƒ Norme X509 (ITU-T X.509 international
(ITU-T
standard V3 - 1996

ƒ RFC2459 : instanciation particulière de la


norme X.509 pour l'Internet

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 34


Certificat X509 (3)
ƒ Un certificat X509 :
ƒ prouve l’identité d’une personne au même titre qu’une
carte d’identité, dans le cadre fixé par l’autorité de
certification qui l’a validé ;

ƒ pour une application il assure que celle -ci n’a pas été
celle-ci
détournée de ses fonctions ;

ƒ pour un site il offre la garantie lors d’un accès vers celui -ci
celui-ci
que l’on est bien sur le site auquel on veut accéder.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 35


Certificats X509
Version Version de la norme X509

Serial Number No de série du certificat

Issuer DN de l’autorité de certification

Données Validity Dates de validité (création et péremption)

Subject DN de l’entité

Subject Public Key Info Clé publique de l’entité

X509v3 extensions Extensions X509

Signature Algorithm Algorithme de signature


Signature
Signature Signature

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 36


Certificats X509
ƒ Distinguished Name (DN)
ƒ Nom et prénom
ƒ Email
ƒ Unité
ƒ Organisation
ƒ Pays

Ex : C=FR,O=CNRS,OU=UPS836,CN=Claude
C=FR,O=CNRS,OU=UPS836,CN=Claude Gross/Email=Claude.Gross@urec.cnrs.fr
Gross/Email=Claude.Gross@urec.cnrs.fr

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 37


Certificats X509
ƒ Extensions :
• Rôle du certificat
ƒ Signature
ƒ Chiffrement
ƒ Non répudiation
ƒ…

• Informations diverses
ƒ Adresse de la CRL
ƒ…
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 38
Fonction de
certification Fonction de Fonction de Fonction de
Fonction de
(signature de chiffrement de chiffrement de négociation de
signature
certificats / clé données clé
CRL).
Signature
digitalSignature
numérique x
Non
nonRepudiation
répudiation x
Chiffrement
keyEncipherment
de clé x
Chiffrement
dataEncipherment
de données x
Négociation
keyAgreement
de clés x
Clé de
keyCertSign signature de x
certificat
Signature de
cRLSign
CRL x
Chiffrement
encipherOnly
seul
Déchiffrement
decipherOnly
seul

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 39


Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4 (0x4)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, O=CNRS, CN=CNRS-Standard
Validity
Not Before: May 3 09:00:43 2001 GMT
Not After : May 3 09:00:43 2002 GMT
Subject: Email=Philippe.Leca@urec.cnrs.fr, CN=Philippe Leca, OU=UPS836, O=CNRS, C=FR
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:f8:c4:f7:d9:0a:51:ba:b5:45:8d:f5:2c:f2:c1:
...
45:a0:96:74:14:73:ee:36:73
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Key Identifier:
CE:5D:A2:36:19:86:F5:E1:D7:9F:EE:41:26:1C:D5:93:3F:12:C8:80
X509v3 Authority Key Identifier:
keyid:67:59:A5:E5:07:74:49:03:EF:05:CF:CC:2E:A4:18:D5:10:C8:9E:3C
DirName:/C=FR/O=CNRS/CN=CNRS
serial:02
X509v3 CRL Distribution Points:
URI:http://igc.services.cnrs.fr/cgi-bin/loadcrl?CA=CNRS-Standard&format=DER
Signature Algorithm: md5WithRSAEncryption
af:c4:87:ad:75:bc:b4:79:f9:c7:67:cf:eb:4a:9c:bf:64:e3:

4a:03:5e:ea

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 40


Certificats X509
ƒ Vérification
Certificat de Alice

Version: 3 (0x2)
Fct de hachage Empreinte 1
Serial Number: 114 (0x72)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, O=CNRS, CN=CNRS
Validity
Not Before: Nov 6 09:43:01 2001 GMT non oui
Not After : Nov 6 09:43:01 2003 GMT Certificat Egalité ?
Certificat
Subject: C=FR, O=CNRS, OU=UREC,
CN=Alice/Email=alice@urec.cnrs.fr invalide valide

Clé publique de l’autorité


de certification CNRS

Signature
1b:2b:c0:3e:52:4d:14:43:… Déchiffrement Empreinte 2

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 41


Autorité de Certification
ƒ C’est une organisation qui délivre des certificats
à une population.

ƒ Une AC possède elle-même un certificat


elle-même

ƒ Il existe des autorités


• privées ((intranet
intranet d’une entreprise),
• organisationnelles (CRU, CNRS),
• corporative (notaires),
• commerciales ((Thawte,
Thawte, Verisign
Verisign,, …),
• etc.
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 42
Autorité de Certification
ƒ La CA agit en tiers de confiance en se portant
garant de l’identité du titulaire du certificat

ƒ Le niveau de confiance dépend de


• La procédure de vérification de l’identité lors de la
délivrance d’un certificat
• La protection de la clef privée de la CA
• Les services annexes comme la révocation des
certificats compromis.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 43


Autorité de Certification
ƒ Le certificat d’une AC peut-être auto
peut-être -signé :
auto-signé
autorité racine

ƒ Le certificat peut -être été émis par une autre


peut-être
AC (relation hiérarchique)

ƒ Le certificat peut être signé a posteriori par une


autorité co -latérale : relation de confiance
co-latérale
croisée
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 44
Certification hiérarchique
AC
Racine
AC0
AC0

AC
intermédiaire

AC1 AC2
AC1 AC2

AC
émettrice

AC3 AC4 AC5


AC3 AC4 AC5

AC0 + AC2 + AC5 + Cx = chaîne de certification

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 45


Infrastructure de Gestion de Clés

Ensemble des matériels, logiciels, personnes,


règles et procédures nécessaire à une Autorité
de Certification pour créer, gérer et distribuer
des certificats X509.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 46


Infrastructure de Gestion de Clés
ƒ Les fonctions principales d'une IGC sont :
• Émettre et révoquer des certificats
• Publier les certificats dans un annuaire
• Éventuellement, fournir un service de séquestre et
de recouvrement des clés privées

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 47


Infrastructure de Gestion de Clés
ƒ Elle est constituée par :
• Une autorité de certification ((AC)
AC)
• Une autorité d'enregistrement ((AE)
AE)
• Un opérateur de certification ((OC)
OC)
• Un annuaire de publication de certificats
• Un service de validation
• Éventuellement, un service de séquestre de clés

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 48


Infrastructure de Gestion de Clés

Autorité
d’Enregistrement
Service de
Validation
Annuaire

Opérateur
de Certification

Service de
Séquestre

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 49


Autorité d’Enregistrement
ƒ Traitement des demandes de création, de
renouvellement et de révocation de certificats.

Ö contrôle des données identifiant le demandeur de


certificat

Ö validation des demandes de révocation

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 50


Opérateur de Certification

ƒ Génération des certificats


ƒ Révocation des certificats

⇒ Utilisation de la clcléé privée de ll’AC


privée ’AC

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 51


Annuaire
ƒ Nécessité de publier les certificats

⇒ Utilisation dd’un
’un annuaire (LDAP)
ƒ Certificats (personnes, services, AC)
ƒ CRLs

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 52


Service de Validation
ƒ Certificats invalides
• Date de validité
• révocation
ƒ Compromission de la clé privée
ƒ Fin de droit
ƒ…

⇒ nécessité d’un service de validation

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 53


Service de Validation
ƒ Certificate Revocation List (CRL)
• Liste des noo de série des certificats révoqués
• Signée avec la clé privée de l’AC

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 54


Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: /C=FR/O=CNRS/CN=CNRS-Standard
Last Update: Nov 26 23:14:49 2001 GMT
Next Update: Dec 26 23:14:49 2001 GMT
Revoked Certificates:
Serial Number: 01
Revocation Date: May 16 11:11:21 2001 GMT
Serial Number: 02
Revocation Date: May 11 10:25:22 2001 GMT

Revocation Date: Nov 8 12:44:08 2001 GMT
Serial Number: EB
Revocation Date: Nov 9 15:02:10 2001 GMT
Serial Number: F0
Revocation Date: Nov 12 14:02:31 2001 GMT
Signature Algorithm: md5WithRSAEncryption
be:0f:ed:14:bb:b8:c0:50:da:de:0d:d2:21:de:2f:63:90:73:
…:
ec:64:0f:b9:02:fb:40:08:9f:27:83:3b:0b:b7:b4:9f:fb:e5:
71:ca:30:5e

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 55


Service de Validation
ƒ Certificate Revocation List (CRL)
• Peu réactif
• Gestion lourde

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 56


Service de Validation
ƒ Online Certificate Status Protocol (OCSP)
• Protocole client/serveur
• Validation « temps réel »
• RFC2560

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 57


Service de Séquestre
ƒ Récupération des clés privées en cas de perte
• Uniquement pour les clés de chiffrement
Ö Récupération de données chiffrées
Ö Obligation légale

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 58


Scénario (1)
7
1 6
5

4
Autorité
d’Enregistrement
Service de
Annuaire Validation
2 3

Opérateur
de Certification

Service de
Séquestre
IGC

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 59


Scénario (2) 1
2

Application 3

6
6

Autorité
d’Enregistrement
Service de
Validation
Annuaire

Opérateur
de Certification

Service de
Séquestre
IGC

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 60


Politiques de Certification

« Ensemble de règles indiquant, ce pour quoi le


certificat est applicable et par qui, et quelles
sont les conditions de leur mise en oeuvre au
sens juridique, administratif et technique ».

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 61


Politiques de Certification
ƒ Étude
Étude de
de la
la population/des
population/des utilisateurs
utilisateurs àà qui
qui est
est destiné
destiné le
le cer tificat en
certificat en
tenant
tenant compte
compte àà la
la fois
fois des
des caractéristiques
caractéristiques desdes utilisateurs,
utilisateurs, dde
e l’utilisation
l’utilisation
qui
qui sera
sera faite
faite du
du certificat
certificat (signature,
(signature, chiffrement
chiffrement entre
entre entit és morales
entités morales
et/ou
et/ou physiques,
physiques, accès
accès àà des
des applications
applications sécurisées)
sécurisées) et et de
de la
la m ise en
mise en
place
place des
des critères
critères d’attribution.
d’attribution.

ƒ Étude
Étude des
des moyens
moyens de de collecte
collecte des
des informations,
informations, de
de leur
leur validatio
validationn et
et de
de la
la
création
création des
des certificats.
certificats.

ƒ Définition
Définition de
de la
la durée
durée de
de vie
vie des clefs
clefs (privée,
(privée, publique
publique et/ou
et/ou de
de session),
session),
des
des certificats,
certificats, de
de la
la consolidation
consolidation de ceux -ci, de la gestion
ceux-ci, gestion des
des listes
listes de
de
révocations.
révocations.

ƒ Étude
Étude des
des moyens
moyens dede distribution
distribution des
des certificats
certificats via
via des
des communi cations
communications
sécurisées
sécurisées de
de type
type «« VPN
VPN »» ou
ou sur
sur un
un support
support style
style «« carte
carte de
de cr édit » avec
crédit
récupération
récupération en
en main
main propre
propre ou
ou par
par un
un agent
agent de
de sécurité
sécurité sur
sur site
site..

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 62


Politiques de Certification
ƒ Sécurité
Sécurité des
des IGC
IGC au
au sens
sens implantation
implantation physique,
physique, et
et sécurité
sécurité des
des annuaires
annuaires supports
supports
des informations publiques en tenant compte de l’infrastructure, de l’administration
des informations publiques en tenant compte de l’infrastructure, de l’administration
et
et du
du coût
coût de
de gestion.
gestion.

ƒ Définition
Définition des
des services
services nécessitant
nécessitant une
une haute
haute disponibilité
disponibilité (exemple :: gestion
(exemple gestion des
des
listes de révocation).
listes de révocation).

ƒ Prise
Prise en
en compte
compte de
de la
la nécessité
nécessité d’un
d’un recouvrement
recouvrement des
des clefs
clefs priv ées et
privées et de
de
l’interaction
l’interaction avec
avec l’autorité
l’autorité suprême
suprême et/ou
et/ou avec
avec d’autres
d’autres commun autés
communautés
(interopérabilité
(interopérabilité pour
pour certifications
certifications croisées).
croisées).

ƒ Étude
Étude du
du support
support matériel/logiciel
matériel/logiciel du
du certificat
certificat chez
chez l’utilisat eur en
l’utilisateur en tenant
tenant compte
compte de
de
la
la vétusté
vétusté des
des postes
postes de
de travail
travail et
et en
en prévoyant
prévoyant desdes évolutions
évolutions aisées.
aisées.

ƒ Prise
Prise en
en compte
compte de
de l’impact
l’impact sur
sur les
les structures
structures existantes
existantes :: phys iques et
physiques et
organisationnelles.
organisationnelles.

ƒ Définition
Définition de
de la
la formation/information
formation/information des
des acteurs.
acteurs.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 63


Politiques de Certification
ƒ 2 documents
• Politique de Certification (PC)
• Déclaration des Pratiques de Certification (DPC)
ƒ description des détails des processus techniques mise en
oeuvre au sein des différentes composantes de l'IGC (CA,
RA,...), conformément à la PC.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 64


Politiques de Certification
⇒ normes communes d’interopérabilité et
critères d’assurance communs entre
plusieurs organismes.

⇒ RFC 2527

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 65


Standards
ƒ Formats de messages
• PKCS7, PKCS10, PKCS12…
ƒ Groupe de travail PKIX
• Instanciation des certificats X509v3 et des CRLs
X509v2 pour l’Internet
• Protocole d’exploitation (RFC2559, RFC2585)
ƒ Distribution des certificats et des CRLs
• Protocole de gestion (RFC2510)
ƒ Protocoles internes aux IGCs
• Règles d’usage et considération pratiques
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 66
S/MIME
ƒ Utilisation de certificat X509 pour la signature
de message en utilisant le format MIME

ƒ Signature « mime Entity » :


• Content -type: Multipart
Content-type: /signed
Multipart/signed
• Content -Type: application/x
Content-Type: -pkcs7-signature;
application/x-pkcs7-signature;

ƒ Chiffrement:
• Content -Type: xx-pkcs7-mime
Content-Type: -pkcs7-mime

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 67


Signature

From dupont@cru.fr
Subject: test
Content-type: multipart/signed

Content-type: text/plain
Content-transfert-encoding: base64
A934B163418C52D
A934B163418C52D6706714A58C3F11
85706714A58C706714A58C33749326
6706714A58C3F11
85706714A58C706
714A58C33749326

Content-Type: application/x-pkcs7-signature;
Content-Transfer-Encoding: base64

1234915642AC2461C268903261C

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 68


Limites
ƒ Les entêtes du message ne font pas partie du
« mime entity » et ne sont donc pas signées.

From: vip@gouv.fr
To: pizza@pizza.com
avion@arme.com
Date: Thu, 06 Dec 2000
Subject: pizza
porte 4avion
saisons
nucléaire
Content-type: text/plain
J’en veux deux, merci de me
Livrer rapidement.

Content-Type: application/x-pkcs7-signature;

1234915642AC2461C268903261C

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 69


Limites
ƒ Toutes les applications vérifient que le
« sender » et le « signer » sont bien les même
personnes.

ƒ S/MIME V3 adresse ces problèmes

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 70


Chiffrement
ƒ Pour émettre un message chiffré il faut disposer
du certificat du destinataire.

• Annuaire LDAP contenant les certificats


• Simple échange préalable de messages signés (les
clients mémorisent les certificats reçus)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 71


Chiffrement S/MIME

To: dupont@

tagada To: dupont@


Content-type: x-pkcs7-mime

0134ABD14378561…
random

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 72


Multi-destinataire
Pour chaque destinataire
To: dest1, dest2

tagada

To: dest1, dest2


Content-type: x-pkcs7-mime
random

0134ABD14378561…

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 73


Signer et chiffrer
ƒ &&crypt(&sign($msg))
crypt(&sign($msg))
• Les informations de la signatures ne sont pas
confidentielles

ƒ &&sign(&crypt($msg))
sign(&crypt($msg))
• On ne peut transmettre le message à un tiers sans
altérer la signature

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 74


Les produits
ƒ Netscape 4.7X mais pas Netscape 6.X
ƒ Outlook
ƒ Lotus
ƒ The bat
ƒ Eudora : néant
ƒ Un grand nombre de plugging et de proxy
ƒ…

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 75


SSL: Secure socket Layer
ƒ A ce jour, probablement le domaine
d’application le plus utilisé.

ƒ Utiliser une couche avec chiffrement et


authentification au dessus de TCP/IP

ƒ Applicable à toutes les applications sur TCP


(sans réécriture de celles -ci)
celles-ci)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 76


Objectifs de SSL 1/3

ƒ Chiffrement
ƒ Pour les applications utilisant un mot de
passe.
ƒ Très utile dans le cas des annuaires LDAP
utilisé en référentiel unique d’authentification
: le mot de passe devient de plus en plus
critique.
ƒ Très utile pour les usages nomades à
travers des réseaux réputés non sûrs.
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 77
Objectifs de SSL 2/3
ƒ Authentification du serveur
ƒ Le chiffrement à partir d’un certificat du serveur ; le
client peut exploiter ce certificat pour authentifier le
serveur.
ƒ Attention : l’authentification du serveur ne permet pas
de savoir si le serveur de la camif est :
• camif .fr
camif.fr
• camif .com
camif.com
• lacamif .fr
lacamif.fr
• camif .biz
camif.biz

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 78


Objectifs de SSL 3/3
ƒ Authentification mutuelle
ƒ Un certificat côté serveur et un certificat côté
client : permet en plus du chiffrement
d’authentifier le client.
ƒ Certaines applications sont modifiées pour
hériter de l’authentification assurée par la
couche SSL.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 79


Principes généraux de SSL

HTTP

LDAP
IMAP
X509 POP
SSL
Communication
sécurisée
TCP

IP

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 80


Domaines d’application
PROTOCOLE PORT

LDAPS 636

POP3S 995

IMAPS 993

NNTPS 563

HTTPS 443

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 81


SSL record/handshake protocol
ƒ SSL est divisé en deux sous-couches
sous-couches
ƒ SSL record protocol et SSL handshake protocol
ƒ Handshake : négociation du chiffrement et de
l’authentification
• Sélection des algorithmes de chiffrement
• Sélection et échange des certificats
• Echange d’une clé de chiffrement symétrique

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 82


SSL handshake

Client hello
Server Hello
Server Certificate
Server Hello Done
Client Certificate 0.2 à
0.4 KB
Change Cipher Spec
Finished
Change Cipher Spec
Finished

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 83


Nature des échanges
ƒ fixer la version de SSL utilisée
ƒ arrêter un identificateur de session
ƒ envoi du certificat serveur
ƒ à la demande du serveur, envoi du certificat client
(et de sa chaîne de certification)
ƒ envoi par le client d’une chaîne chiffrée avec la clé
privée du client. (le serveur vérifie que le client est
bien titulaire de la clé privée en déchiffrant cette
chaîne avec la clé publique du client).
ƒ fixer une clé de chiffrement symétrique

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 84


Identificateur de session 1/2
ƒ Pour reprendre une session déjà initialisée, le
client envoie (dans le Client HelloHello))
l’identificateur de cette session.
ƒ S’il retrouve cet identificateur dans son cache
de session le serveur répond avec le même
identificateur de session dans le Server
Hello
ƒ Cet identificateur permet de restaurer le
contexte de la session, en particulier la clé de
chiffrement symétrique.
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 85
Identificateur de session 2/2
ƒ Le serveur peut forcer la renégociation en
répondant avec un nouveau Session Id
ƒ Optimisation indispensable donc importance du
réglage des paramètres des serveurs :
• Durée de conservation des contextes de session
• Partage du cache en processus coopérants
(principalement httpd
httpd))

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 86


TLS
ƒ SSL proposé par Netscape
Netscape.. SSL v3 : 1996
ƒ Transport Layer Security : IETF RFC2246
ƒ TLS/SSL v3 compatibles
ƒ Les implémentations de SSLv3 incluent TLS

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 87


ƒ Implémentation de référence, licence « Apache »
ƒ http://www.openssl.org
http://www.openssl.org
ƒ Librairie + jeu de commandes
ƒ Algorithmes d’empreintes et de chiffrements
ƒ Manipulation de PKCS#
ƒ Manipulation de certificats et CRL
ƒ SSL
ƒ S/MIME v2
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 88
Opérations de base avec OpenSSL

Afficher le DN du titulaire du certificat cert.pem


cert.pem

# /usr/bin/openssl x509 -in cacert.pem -subject \


-inform PEM –noout
subject=/Email=ca-admin@cru.fr/CN=ca-rssi/O=cru/C=fr

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 89


# /usr/bin/openssl x509 –inform PEM –in cert.pem –text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: md5WithRSAEncryption
Issuer: Email=ca-admin@cru.fr, CN=ca-cru, O=CRU, C=FR
Validity
Not Before: Apr 26 12:54:43 2001 GMT
Not After : Mar 22 12:54:43 2023 GMT
Subject: Email=ca-admin@cru.fr, CN=ca-rssi, O=cru, C=fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:f9:54:bd:4f:c4:4b:4c:cb:9c:5e:55:ab:26:76:
........
08:7d:3d:2f:18:b6:18:43:b7:42:ee:00:7b:86:62:
df:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: CA:TRUE
X509v3 Subject Key Identifier:
…………………
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 90
Opérations de base avec OpenSSL

Vérifier un certificat (autorités de confiance


compilées dans cabundle .pem)
cabundle.pem)

# /usr/bin/openssl verify -CAfile cabundle.pem \


-purpose any cert.pem
cert.pem: OK

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 91


Opérations de base avec OpenSSL

Supprimer la « pass phrase » qui protège une


clé privée

# /usr/local/openssl rsa -in key.pem \


-out key.en-clair.pem
read RSA key
Enter PEM pass phrase:
writing RSA key

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 92


# openssl s_client -connect pki.cru.fr:443
chaîne
session interrompue
SLL sur le port
CONNECTED(00000003) avant succès
depth=2 /Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR https de pki.cru.fr

verify error:num=19:self signed certificate in certificate chain


verify return:0
chaîne de certification,
Certificate chain
(contient les certificats)
0 s:/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-
servers/O=cru/C=fr
1 s:/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR
2 s:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR
Server certificate
le certificat serveur
-----BEGIN CERTIFICATE----- (tronqué sur ce document)
MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
subject=issuer
.... donc self-signed
-----END CERTIFICATE-----

subject=/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr dans ce cas la session


issuer=/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr continue malgré
l’erreur
---

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 93


# openssl s_client -connect pki.cru.fr:443 -CAfile /usr/local/openca/ca-cru/stuff/cacert.pem
CONNECTED(00000003)
le certificat
depth=2 /Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR verify return:1 trusted
depth=1 /Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr verify return:1
depth=0 /Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr verify return:1 ce certificat de la
Certificate chain chaîne est
0 s:/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr
1 s:/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR justement
2 s:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR trusted
Server certificate
-----BEGIN CERTIFICATE-----
MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
................ ok, le certificat
-----END CERTIFICATE----- correspond au hostname
subject=/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr
issuer=/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr mode crypte + auth
serveur seulement
No client certificate CA names sent
SSL handshake has read 3819 bytes and written 320 bytes
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Id session (circule en clair) &
Server public key is 1024 bit clef de cryptage symétrique
SSL-Session:
protocol : TLSv1
(secret)
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 2D07890E0D33DF017DD5F0460F5326E61186810F7D5CA1D5017030F2FDA4118B
Session-ID-ctx:
Master-Key: CFA689D0643472A29FF206D1BDEB8D26E32BF771B174BCF6E730E8661CF2C2C151546D25C46A3DF02687F41E Key-Arg :
None
Start Time: 991131072 Persistence en
Timeout : 300 (sec)
inactivité
Verify return code: 0 (ok)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 94


# openssl s_client -connect pki.cru.fr:443 -CAfile cacert.pem -cert mycert.pem -key mykey.pem
Enter PEM pass phrase:
CONNECTED(00000003)
depth=2 /Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR verify return:1
depth=1 /Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr verify return:1 certificat et clé
depth=0 /Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr verify return:1 du client
Certificate chain
0 s:/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr
1 s:/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR
2 s:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR i:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR
Server certificate
-----BEGIN CERTIFICATE-----
MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
...............
-----END CERTIFICATE-----
subject=/Email=webmaster@cru.fr/CN=pki.cru.fr/O=cru/C=fr
Le serveur est paramétré pour
issuer=/Email=ca-admin@cru.fr/CN=ca-servers/O=cru/C=fr
demander le certificat client.
Acceptable client certificate CA names Il présente la liste des ca
/C=US/O=Digital Signature Trust Co./OU=DSTCA E1 acceptables
/C=US/O=Digital Signature Trust Co./OU=DSTCA E2
/C=US/O=Digital Signature Trust Co./OU=DST-Entrust GTI CA
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR
/Email=ca-admin@cru.fr/CN=ca-rssi/O=cru/C=fr
/Email=ca-admin@cru.fr/CN=ca-users/O=cru/C=fr/
---

SSL handshake has read 13326 bytes and written 1603 bytes
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
etc
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 95
Stunnel 1/3
ƒ SSL Tunneling Proxy
ƒ Licence GPL ((http://www.stunnel.org)
http://www.stunnel.org)
ƒ Multi -plateforme Unix, Windows
Multi-plateforme
ƒ Basé sur les librairies OpenSSL
ƒ Usage multiple en frontal, proxy
proxy,, localement ou
pour rediriger des flux vers une autre machine
ƒ Exemple POP3S, LDAPS, IMAPS

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 96


Stunnel 2/3

ƒ Peut être un client SSL (initialise le handshake


protocol
protocol)) ou en mode serveur.
ƒ Activer via inetd
pop3s
inetd.. Exemple :
pop3s stream
stream tcp
tcp nowait
nowait root
root //usr/sbin/stunnel
usr/sbin/stunnel …… --l
l //usr/sbin/ipop3d
usr/sbin/ipop3d

• pas de cache des sessions


• fork de stunnel + fork de l’application:
ƒ Préférer le mode daemon avec option ––dd et
option ––tt timeout (gestion du cache des
sessions)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 97


Stunnel 3/3
ƒ Compatible tcp/wrapper (respecte les
tcp/wrapper
restrictions d’accès des fichiers hosts. allow
hosts.allow
et hosts. deny)
hosts.deny)

ƒ Attention à la définition du service dans


hosts.( allow|deny) dans le cas où stunnel est
hosts.(allow|deny)
utilisé pour rediriger un flux vers un autre host.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 98


Stunnel et les certificats 1/3
ƒ Selon usage, 4 catégories de certificats
manipulés par Stunnel
• Les certificats des autorités de confiance
• Le certificat serveur et sa clé
• Le certificat client et sa clé
• Les certificats clients acceptés pour un accès au
service

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 99


Stunnel et les certificats 2/3
ƒ concaténer le certificat serveur|client et sa clé
privée au format PEM dans un fichier (séparés par
une ligne vide)
ƒ Option ––pp <<path>
path> pour spécifier l’emplacement de
ce fichier
ƒ La clé doit être en clair : impose de protéger la
machine utilisant stunnel ⇒ plus facile sur un
serveur
ƒ Ne pas utiliser la clé livrée avec la distrib : c’est une
clé sous licence GPL !!!
ƒ Ne pas utiliser une clé auto -signée sauf utilisateurs
auto-signée
avertis
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 100
Stunnel et les certificats 3/3
ƒ Les autorités de confiance (option ––A).
A). Même format
qu’avec openssl ; concaténation des certificats
séparés par des lignes blanches (le bundle est extrait
des clients Netscape
Netscape))
ƒ L’option ––vv level2 permet de vérifier la validité des
certificats clients
ƒ L’option ––vv level3 ––aa <directory> permet d’énumérer
les certificats clients autorisés

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 101


Exemples d’utilisation

Client IMAPS Serveur IMAPS

Client Stunnel Tunnel ssl Stunnel Serveur


IMAP client serveur IMAP

/usr/sbin/stunnel \
-c -d imap \ /usr/sbin/stunnel \
-r mailhost.cru.fr:imaps \ -d imaps \
-p client.pem \ -l /usr/sbin/imapd \
-A ca-bundle.pem -v level3 \
-a client-cert-dir \
-p mailhost.pem \
-A ca-bundle.pem

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 102


imaps pops
ƒ Le mail, principal service nomade
ƒ Outlook, Netscape messenger
messenger,, Eudora 5.X :
imaps et pops ((Opera,
Opera, uniquement pops)
ƒ Contrôle d’accès possible par certificat client,
mais :
• Outlook n’envoie pas le certificat client même s’il est
demandé
• Non dispo avec beaucoup de serveurs (contournement
avec stunnel
stunnel))
• Le certificat client est utilisé pour du contrôle d’accès
mais pas pour l’authentification

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 103


SMTP/TLS 1/2
ƒ Capture de contenus, analyse de trafic,
utilisation frauduleuse de la fonction de
relais (le relais est utile pour l’usage
nomade).
ƒ Autres solutions : webmail
webmail,, relais smtp
ouvert temporairement après une
authentification POP
ƒ Seul TLS permet de chiffrer les adresses
emails des correspondants (S/MIME ne
chiffre que le corps des messages)

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 104


SMTP/TLS 2/2
ƒ Décrit dans le RFC 2487
ƒ Nouvelle directive de extented SMTP :
STARTTLS
ƒ Pas de port spécifique
ƒ Postfix : http://www.hsc.fr/ressources/breves/postfix-tls.html
ƒ Sendmail : http://www.sendmail.org/~ca/email/starttls.html

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 105


HTTPS
ƒ 1 seul certificat (côté serveur) pour chiffrer la
saisie d’informations sensibles.
ƒ EE-commerce
-commerce se limite souvent à cela !
ƒ Chiffrer la saisie de mots de passe
ƒ Chiffrer les données des formulaires.
ƒ Chiffrer des cookies
cookies..

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 106


HTTPS
ƒ 1 certificat serveur + 1 certificat par client
ƒ permet de sécuriser fortement l’authentification
des clients,

ƒ Remplace des méthodes d’authentification peu


pratiques : plus de mot de passe, plus de
formulaire préalable, plus de cookie
cookie,,
programmation des applications simplifiée …

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 107


HTTPS
ƒ Mode chiffrement : un certificat X509 émis par une
autorité doit être installé sur le serveur.
ƒ Le client accepte le certificat serveur
• S’il a été émis par une CA de confiance
• Si le certificat de cette CA est en cours de validité
• Si le champ CN du DN du certificat du serveur contient
le nom du serveur
• Si le certificat serveur est en cours de validité
• S’il n’a pas été révoqué
ƒ Sinon …
ƒ Le contrôle des CAs de confiance utilisées par les
clients de la population visée est très important.

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 108


HTTPS
ƒ Mode chiffré avec authentification du client.
ƒ 2 certificats X509 : 1 client + 1 serveur
ƒ Le client choisit un certificat parmi la liste des
CA auxquelles le serveur fait confiance,
ƒ La communication est chiffrée, le serveur
récupère les infos extraites du certificat client
en particulier son DN

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 109


Que faire avec HTTPS ?
ƒ restreindre les droits d’accès à une partie des
clients, logiques possibles :

• distribuer des certificats aux gens autorisés. Un


utilisateur peut avoir beaucoup de certificats. La
gestion des droits est faite par la PKI.

• lister dans le serveur les DN autorisés. Pas de notion


de privilège dans le certificat. (réplication des privilèges
sur chaque serveur)

• on peut panacher ces méthodes : classe de certificats

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 110


HTTPS et les serveurs virtuels

On ne peut réussir une session HTTPS avec un virtual


host basé sur un CNAME DNS.
¾HTTPS c’est HTTP sur SSL, il faut établir la session
SSL avant la connexion HTTP.
¾Au niveau SSL, la directive http Host: n’étant pas
encore disponible, le serveur délivre obligatoirement
le certificat du host par défaut.
¾Le client refuse donc une session avec un certificat
n’ayant pas « le bon Subject DN »

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 111


Apache
ƒ open_ ssl http://
open_ssl www.openssl.org
http://www.openssl.org
ƒ mod _ssl http://
mod_ssl www.modssl.org
http://www.modssl.org
ƒ mod _ssl peut être utilisé en mode DSO
mod_ssl

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 112


Source http://www.modssl.org/docs/apachecon2001

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 113


Installation

ƒ Sur red hat 7.0 le rpm Apache installe


open_ ssl et mod
open_ssl _ssl. Le démarrage
mod_ssl.
standard ouvre le port 80 et le port 443.
cd
cd ../ openssl-0.9.6 ;; ./configure;
../openssl-0.9.6 ./configure; make
make
cd
cd ../ mod-ssl-2.8.2
../mod-ssl-2.8.2
./configure
./configure ––with
with ../apache_1.3.19
../apache_1.3.19 ––with-ssl
with-ssl ../open -ssl-0.9.6 ––prefix
../open-ssl-0.9.6 prefix //usr/local/apache
usr/local/apache
cd
cd ../apache_1.3.19
../apache_1.3.19 ;; make
make ;; make
make certificate
certificate type= dummy ;; make
type=dummy make install
install;; c’est
c’est fini
fini !!
//usr/local/apache/bin/httpd
usr/local/apache/bin/httpd ––DSSL
DSSL
netscape
netscape https ://localhost
https://localhost

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 114


HTTPD.conf 1/3

ƒ Listen 443
ƒ SSLengine on|off
ƒ SSLCertificateFile SSLCertificatekeyFile
ƒ SSLCACertificate (File|Path)
SSLCACertificate(File|Path)
• bundle par défaut
• make
ƒ SSLCertificateChainFile

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 115


HTTPD.conf 2/3

ƒ SSLCARevocation (File|Path)
SSLCARevocation(File|Path)
ƒ SSLEngine on|off
ƒ SSLVerifyClient none| optional|require
none|optional|require
ƒ SSLVerifyDepth n

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 116


HTTPD.conf

ƒ SSLRequireSSL : interdit un accès en http simple


ƒ SSLRequire <expression>
• Expressions +/
+/-- complexes utilisant les variables
d’environnement dont celles extraites des
certificats
SSLRequire ( %{SSL_CLIENT_S_DN_O} =~ m/^Université/ \
and
and %{SSL_CLIENT_I_DN_ Email} eq ««ca-admin@cru.fr
%{SSL_CLIENT_I_DN_Email} ca-admin@cru.fr » \
or %{ remote_addr} =~ m/^129
%{remote_addr} \.20\.10\.[0-9]/)
m/^129\.20\.10\.[0-9]/)

ƒ SSLOptions +|
+|-- <option>
• StdEnvVars : extraction des infos du certificat vers
des variables à usage des CGI
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 117
HTTPD.conf
• FakebasicAuth : le DN est utilisé comme nom
d’usager dans le fichier d’authentification basique.
(le mot de passe est alors xxj31ZMTZzkVA). Cette
option doit associer avec Require valid -user,
valid-user,
AuthUserFile
AuthUserFile,, AuthName
• StrictRequire utile avec « satisfy any » si on veut
SSLRequire ou ((SSLRequireSLL
SSLRequireSLL et d’autres
conditions). Grâce à cette directive le « any » ne
concerne que les autres conditions

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 118


Les pièges
ƒ Ne jamais faire le raccourci, SSL = sûr.
ƒ Attention à ne pas créer avec HTTPS des
backdoor HTTP.
ƒ Ne pas confondre identification et privilèges
ƒ Ne pas partager la racine. Sinon :
<location /zone>
RewriteEngine On
RewriteCond %{HTTPS} != on
RewriteRule ^(.*)$ https ://mon.host/zone/$1 [R,L]
https://mon.host/zone/$1
SSLRequireSSL
SSLCypherSuite all:! eNULL
all:!eNULL
</location>

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 119


Conclusion (1)
ƒ Problèmes
• Sécurité des clés privées
• Amorçage du système
• A qui faire confiance?
• Implémentations clients
• Formation utilisateurs finaux
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 120
Conclusion (2)
ƒ Technologie séduisante
ƒ Compliquée
• Partie technique
• Partie organisationnelle
ƒ Pas complètement mûre (clients, …)
ƒ Ce n’est pas la solution à tous les pbs de
sécurité
ƒ Alternatives?
JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 121
Références
‰ Documents
IGC CNRS : http://www.urec.cnrs.fr/igc/Doc/IGC_docs.html
IGC du CRU : http://pki.cru.fr/
PKIX Working Group : http://www.imc.org/ietf-pkix/index.html
PKI Forum : http://www.pkiforum.org/
The Open–source PKI Book : http://ospkibook.sourceforge.net/
The PKI Page : http://www.pki-page.org/
Serveur de RSA : http://www.rsasecurity.com
The SSL Protocol : http://home.netscape.com/eng/ssl3/ssl-toc.html
http://developer.netscape.com/tech/security/ssl/howitworks.html
Serveur DCSSI : http://www.scssi.gouv.fr/
Ten Risks of PKI: http://www.counterpane.com/pki-risks.html

‰ Standards
RFC 2459 - PKIX Certificate and CRL Profile : http://www.ietf.org/rfc/rfc2459.txt
RFC 2510 - PKIX Certificate Management Protocols : http://www.ietf.org/rfc/rfc2510.txt
RFC 2511 - PKIX Certificate Request Message Format : http://www.ietf.org/rfc/rfc2511.txt
RFC 2527 - Certificate Policy and Certification Practices Framework : http://www.ietf.org/rfc/rfc2527.txt
RFC 2560 - PKIX Online Certificate Status Protocol (OCSP) : http://www.ietf.org/rfc/rfc2560.txt
RFCs S/MIME V2 : http://www.ietf.org/rfc/rfc2311.txt
http://www.ietf.org/rfc/rfc2312.txt
http://www.ietf.org/rfc/rfc2313.txt
http://www.ietf.org/rfc/rfc2314.txt
RFCs S/MIME V3 : http://www.ietf.org/rfc/rfc2630.txt
http://www.ietf.org/rfc/rfc2631.txt
http://www.ietf.org/rfc/rfc2632.txt
http://www.ietf.org/rfc/rfc2633.txt
‰ Produits
Openssl : http://www.openssl.org/
Modssl : http://www.modssl.org/
Stunnel : http://www.stunnel.org
Sendmail/TLS : http://www.sendmail.org/~ca/email/starttls.html
Postfix/TLS : http://www.hsc.fr/ressources/breves/postfix-tls.html
OpenCA : http://www.openca.org

JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés 122