Doc

Transcription

Doc

Certificats X509
&
Infrastructure de Gestion de
Clés
Serge Aumont
Claude Gross
Philippe Leca
CRU
CNRS/UREC
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)
-répudiation
Non
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
), vote électronique
Anonymat (non traçabilité
traçabilité),
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).
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
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, encrypter
”: pas de sens clair
““crypter,
encrypter”:
clair..
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
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.
-tables : substitutions dépendantes de
les SS-tables
la position de la lettre dans le message (la
table de substitution est choisie en fonction
du rang de chaque caractère)
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.
9
Chiffrement de Vignère
U
N
I
V
E
R
S
I
T
E
A
B
B
Y
A
B
B
Y
A
B
V
P
K
U
F
T
U
H
U
G
• Avec une clef de 4 caractères dans un
alphabet de 26 caractères, le nombre de
substitutions est de 264=456976
• Enigma : 28 roues dentées (clefs de 28
caractères). 2628=4.162x1039
• Non violé pendant toute la 2eme guerre,
mais considéré aujourd’hui comme faible
parce que la connaissance d’un message
chiffré permet de retrouver la clef.
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.
11
Masque jetable 2/3
1
1
0
1
0
0
1
0
0
0
1
1
1
0
0
1
1
0
1
0
1
0
0
0
0
1
0
0
1
1
1
0
0
1
1
0
1
1
0
1
0
0
1
0
0
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
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
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
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
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.
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
2.

3.
serveur pour calculer la longueur du mot de passe (pas
d’écho pendant la frappe du mot de passe)
Analyse statistique de la vitesse de frappe des caractères
en fonction de leur position sur le clavier !
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..
18
Chiffrement : confidentialité
Clef de chiffrement
TE
TEX ir
la
en c
Algorithme de chiffrement
Alice
TE
TEX ir
la
en c
Internet
Algorithme de déchiffrement
Bob
Clef de déchiffrement
19
Chiffrement à clefs symétriques (1/2)
clef de chiffrement = clef de déchiffrement
clef secrète
DES :: Data
Data Encryption
Encryption Standard
Standard
DES
Clef de
de 56
56 bits
bits
•• Clef
Standard de 1977
de 1977
•• Standard

3DES : 3 passes dans DES en utilisant 2 ou 3 clefs
: 3 passes dans DES en utilisant 2 ou 3 clefs
3DES
distinctes (112 ou 168 bits)
distinctes (112 ou 168 bits)
RC2, RC4, RC5 : clef de 1 à 1024 bits
RC4, RC5 : clef de 1 à 1024 bits
RC2,
IDEA (International Data Encryption Algorithme)
(International
Data Encryption
Algorithme)
IDEA
AES
(Advanced
Encryption
Standard),
issu d’un
concours international pour remplacer DES.
Standard
AES (Advanced Encryption Standard), issu d’un
concours international pour remplacer DES. Standard
20
publié en Avril 2001
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
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
22
Clef publique de Bob
TE
X
E
T
ir
a
l
c
en
Chiffrement asymétrique
Alice
TE
X
E
T
ir
a
l
c
en
Internet
Déchiffrement asymétrique
Bob
Clef privée de Bob
23

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
24
Robustesse de RSA
Non divulgation de la clef privée
Fondée sur
Difficulté à décomposer en facteurs premiers un nombre
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
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)
26
Chiffrement : clef aléatoire (2/2)
Clef publique de Bob
Clef aléatoire
TE
TEX ir
la
en c
Chiffrement
asymétrique
Chiffrement
symétrique
Ε
ντε
ι
ε
ρ
µπ
ντε
ι
ε
ρ
Εµπ
❅■
✴✥ ❒
✸
✥
✴
❁❉
❃●
❅■
✴✥ ❒
✸
✥
✴
❁❉
●
❃
Internet
Alice
Clef privée de Bob
Bob
TE
X
E
T
ir
a
l
c
en
Clef aléatoire
Déchiffrement symétrique
Déchiffrement
asymétrique
Ε
ντε
ι
ε
ρ
µπ
❅■
✴✥ ❒
✸
✥
✴
❁❉
●
❃
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
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
•
n-1 essais pour retrouver
l'attaque par force brute (moyenne 2 n-1
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)
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
30
Signature électronique (2/2)
TE
X
E
T
ir
a
l
c
en
Clef privée de
Alice
TE
X
E
T
lair
c
n
e
Fct
de h
ach
a
ge
nte
i
e
r
Emp
TE
X
E
T
ir
a
l
c
en
Chiffrem
ent
Alice
Em
te
n
i
e
r
p
Internet
Fct de hachage
TE
X
E
T
lair
c
n
e
Em
Bob
égalité ?
TE
X
E
T
lair
c
n
e
nte
i
e
r
p
Dé c
hiff
re m
ent
Clef publique de
Alice
31
Chiffrement à clefs asymétriques
-clef
Chaque utilisateur a un bibi-clef
Questions :
-elle bien celle appartenant à la personne avec qui
• la clé est
est-elle
les échanges sont envisagés?
-il « digne de confiance »?
• le possesseur de cette clé est
est-il
-elle toujours valide?
• la clé est
est-elle
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
33
Certificat X509 (2)
-T X.509 international
Norme X509 (ITU
(ITU-T
standard V3 - 1996
RFC2459 : instanciation particulière de la
norme X.509 pour l'Internet
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.
35
Certificats X509
Version
Serial Number
Issuer
Données
No de série du certificat
DN de l’autorité de certification
Validity
Dates de validité (création et péremption)
Subject
DN de l’entité
Subject Public Key Info
X509v3 extensions
Signature
Version de la norme X509
Signature Algorithm
Signature
Clé publique de l’entité
Extensions X509
Algorithme de signature
Signature
36
Certificats X509
Distinguished Name (DN)
Nom et prénom
Email
Unité
Organisation
Pays
Ex : C=FR,O=CNRS,OU=UPS836,CN=Claude
[email protected]
C=FR,O=CNRS,OU=UPS836,CN=Claude Gross/
Gross/[email protected]
37
Certificats X509
Extensions :
• Rôle du certificat
Signature
Chiffrement
Non répudiation
…
• Informations diverses
Adresse de la CRL
…
38
Fonction de
signature
digitalSignature
Signature
numérique
x
nonRepudiation
Non
répudiation
x
keyEncipherment
Chiffrement
de clé
dataEncipherment
Chiffrement
de données
keyAgreement
keyCertSign
cRLSign
Fonction de
certification
(signature de
certificats /
CRL).
Négociation
de clés
Clé de
signature de
certificat
Signature de
CRL
encipherOnly
Chiffrement
seul
decipherOnly
Déchiffrement
seul
Fonction de
Fonction de
Fonction de
chiffrement de chiffrement de négociation de
clé
données
clé
x
x
x
x
x
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 protected], 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
af:c4:87:ad:75:bc:b4:79:f9:c7:67:cf:eb:4a:9c:bf:64:e3:
…
4a:03:5e:ea
40
Certificats X509
Vérification
Certificat de Alice
Version: 3 (0x2)
Issuer: C=FR, O=CNRS, CN=CNRS
Validity
Not Before: Nov 6 09:43:01 2001 GMT
Not After : Nov 6 09:43:01 2003 GMT
Subject: C=FR, O=CNRS, OU=UREC,
CN=Alice/[email protected]
…
Empreinte 1
Fct de hachage
Certificat
invalide
non
oui
Egalité ?
Certificat
valide
Clé publique de l’autorité
de certification CNRS
Signature
1b:2b:c0:3e:52:4d:14:43:…
Déchiffrement
Empreinte 2
41
C’est une organisation qui délivre des certificats
à une population.
-même un certificat
Une AC possède elle
elle-même
Il existe des autorités
intranet d’une entreprise),
• privées ((intranet
• organisationnelles (CRU, CNRS),
• corporative (notaires),
Thawte, Verisign
• commerciales ((Thawte,
Verisign,, …),
• etc.
42
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.
43
-être auto
-signé :
Le certificat d’une AC peut
peut-être
auto-signé
autorité racine
-être été émis par une autre
Le certificat peut
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
44
Certification hiérarchique
AC
Racine
AC0
AC0
AC
intermédiaire
AC1
AC1
AC2
AC2
AC
émettrice
AC3
AC3
AC5
AC5
AC4
AC4
AC0
+
AC2
+
AC5
+
Cx
= chaîne de certification
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.
46
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
47
Elle est constituée par :
AC)
• Une autorité de certification ((AC)
AE)
• Une autorité d'enregistrement ((AE)
OC)
• Un opérateur de certification ((OC)
• Un annuaire de publication de certificats
• Un service de validation
• Éventuellement, un service de séquestre de clés
48
Autorité
d’Enregistrement
Annuaire
Service de
Validation
Opérateur
de Certification
Service de
Séquestre
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
50
Opérateur de Certification
Génération des certificats
Révocation des certificats
⇒ Utilisation de la clcléé priv
ée de ll’AC
’AC
privée
51
Annuaire
Nécessité de publier les certificats
’un annuaire (LDAP)
⇒ Utilisation dd’un
Certificats (personnes, services, AC)
CRLs
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
53
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
54
Certificate Revocation List (CRL):
Version 1 (0x0)
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
Serial Number: F0
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
55
Certificate Revocation List (CRL)
• Peu réactif
• Gestion lourde
56
Online Certificate Status Protocol (OCSP)
• Protocole client/serveur
• Validation « temps réel »
• RFC2560
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
58
Scénario (1)
1
6
7
5
4
Autorité
d’Enregistrement
2
3
Annuaire
Service de
Validation
Opérateur
de Certification
Service de
Séquestre
IGC
59
Scénario (2)
1
2
Application
3
6
6
5
4
Autorité
d’Enregistrement
Service de
Validation
Annuaire
Opérateur
de Certification
Service de
Séquestre
IGC
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 ».
61

Étude
tificat en
Étude de
de la
la population/des
population/des utilisateurs
utilisateurs àà qui
qui est
est destiné
destiné le
le cer
certificat
en
tenant
e l’utilisation
tenant compte
compte àà la
la fois
fois des
des caractéristiques
caractéristiques des
des utilisateurs,
utilisateurs, dde
l’utilisation
qui
és morales
qui sera
sera faite
faite du
du certificat
certificat (signature,
(signature, chiffrement
chiffrement entre
entre entit
entités
morales
et/ou
ise en
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
mise
en
place
place des
des critères
critères d’attribution.
d’attribution.

Étude
n et
Étude des
des moyens
moyens de
de collecte
collecte des
des informations,
informations, de
de leur
leur validatio
validation
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
-ci, de la gestion
des certificats,
certificats, de
de la
la consolidation
consolidation de ceux
ceux-ci,
gestion des
des listes
listes de
de
révocations.
révocations.

Étude
cations
Étude des
des moyens
moyens de
de distribution
distribution des
des certificats
certificats via
via des
des communi
communications
sécurisées
édit » avec
sécurisées de
de type
type «« VPN
VPN »» ou
ou sur
sur un
un support
support style
style «« carte
carte de
de cr
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..
62

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
mple :: gestion
Définition des
des services
services nécessitant
nécessitant une
une haute
haute disponibilité
disponibilité (exe
(exemple
gestion des
des
listes
de
révocation).
listes de révocation).

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

Étude
eur en
Étude du
du support
support matériel/logiciel
matériel/logiciel du
du certificat
certificat chez
chez l’utilisat
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 des
des évolutions
évolutions aisées.
aisées.

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

Définition
Définition de
de la
la formation/information
formation/information des
des acteurs.
acteurs.
63
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.
64
⇒
⇒
normes communes d’interopérabilité et
critères d’assurance communs entre
plusieurs organismes.
RFC 2527
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
66
S/MIME
Utilisation de certificat X509 pour la signature
de message en utilisant le format MIME
Signature « mime Entity » :
-type: Multipart
/signed
• Content
Content-type:
Multipart/signed
-Type: application/x
-pkcs7-signature;
• Content
Content-Type:
application/x-pkcs7-signature;
Chiffrement:
-Type: xx-pkcs7-mime
-pkcs7-mime
• Content
Content-Type:
67
Signature
From [email protected]
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
68
Limites
Les entêtes du message ne font pas partie du
« mime entity » et ne sont donc pas signées.
From: [email protected]
To: [email protected]
[email protected]
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
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
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)
71
Chiffrement S/MIME
To: dupont@
tagada
random
To: dupont@
Content-type: x-pkcs7-mime
0134ABD14378561…
72
Multi-destinataire
Pour chaque destinataire
To: dest1, dest2
tagada
random
To: dest1, dest2
Content-type: x-pkcs7-mime
0134ABD14378561…
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
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
…
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)
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.
77
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 :
.fr
• camif
camif.fr
.com
• camif
camif.com
.fr
• lacamif
lacamif.fr
.biz
• camif
camif.biz
78
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.
79
Principes généraux de SSL
SSL
LDAP
IMAP
HTTP
POP
X509
Communication
sécurisée
TCP
IP
80
Domaines d’application
PROTOCOLE
PORT
LDAPS
636
POP3S
995
IMAPS
993
NNTPS
563
HTTPS
443
81
SSL record/handshake protocol
-couches
SSL est divisé en deux sous
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
82
SSL handshake
Client hello
Server Hello
Server Certificate
Server Hello Done
Client Certificate
Change Cipher Spec
0.2 à
0.4 KB
Finished
Change Cipher Spec
Finished
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
84
Identificateur de session 1/2
Pour reprendre une session déjà initialisée, le
client envoie (dans le Client Hello
Hello))
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.
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))
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
87
Implémentation de référence, licence « Apache »
www.openssl.org
http://
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
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 protected]/CN=ca-rssi/O=cru/C=fr
89
# /usr/bin/openssl x509 –inform PEM –in cert.pem –text -noout
Certificate:
Data:
Version: 3 (0x2)
Issuer: [email protected], 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 protected], 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:
…………………
90
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
91
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
92
# openssl s_client -connect pki.cru.fr:443
CONNECTED(00000003)
depth=2 /[email protected]/CN=ca-cru/O=CRU/C=FR
chaîne
interrompue
session
SLL
sur le port
avant
succès
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 protected]/CN=pki.cru.fr/O=cru/C=fr i:/[email protected]/CN=caservers/O=cru/C=fr
1 s:/[email protected]/CN=ca-servers/O=cru/C=fr i:/[email protected]/CN=ca-cru/O=CRU/C=FR
2 s:/[email protected]/CN=ca-cru/O=CRU/C=FR i:/[email protected]/CN=ca-cru/O=CRU/C=FR
Server certificate
le certificat serveur
(tronqué sur ce document)
-----BEGIN CERTIFICATE----subject=issuer
MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
donc self-signed
....
-----END CERTIFICATE----subject=/[email protected]/CN=pki.cru.fr/O=cru/C=fr
issuer=/[email protected]/CN=ca-servers/O=cru/C=fr
--JRES2001 – Tutoriel Certificats X509 et Infrastructure de Gestion de Clés
dans ce cas la session
continue malgré
l’erreur
93
# openssl s_client -connect pki.cru.fr:443 -CAfile /usr/local/openca/ca-cru/stuff/cacert.pem
le certificat
CONNECTED(00000003)
trusted
depth=2 /[email protected]/CN=ca-cru/O=CRU/C=FR verify return:1
depth=1 /[email protected]/CN=ca-servers/O=cru/C=fr verify return:1
depth=0 /[email protected]/CN=pki.cru.fr/O=cru/C=fr verify return:1
ce certificat de
Certificate chain
chaîne est
0 s:/[email protected]/CN=pki.cru.fr/O=cru/C=fr i:/[email protected]/CN=ca-servers/O=cru/C=fr
justement
trusted
2 s:/[email protected]/CN=ca-cru/O=CRU/C=FR
i:/[email protected]/CN=ca-cru/O=CRU/C=FR
Server certificate
-----BEGIN CERTIFICATE----MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
ok, le certificat
................
correspond au hostname
mode crypte + auth
la
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:
(secret)
protocol : TLSv1
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)
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 protected]/CN=ca-cru/O=CRU/C=FR verify return:1
depth=1 /[email protected]/CN=ca-servers/O=cru/C=fr verify return:1
certificat et clé
depth=0 /[email protected]/CN=pki.cru.fr/O=cru/C=fr verify return:1
du client
Certificate chain
0 s:/[email protected]/CN=pki.cru.fr/O=cru/C=fr i:/[email protected]/CN=ca-servers/O=cru/C=fr
2 s:/[email protected]/CN=ca-cru/O=CRU/C=FR i:/[email protected]/CN=ca-cru/O=CRU/C=FR
Server certificate
-----BEGIN CERTIFICATE----MIIEcTCCA1mgAwIBAgIBAjANBgkqhkiG9w0BAQQFADBQMR4wHAYJKoZIhvcNAQkB
...............
Acceptable client certificate CA names
/C=US/O=Digital Signature Trust Co./OU=DSTCA E1
/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 protected]/CN=ca-cru/O=CRU/C=FR
/[email protected]/CN=ca-rssi/O=cru/C=fr
/[email protected]/CN=ca-users/O=cru/C=fr/
Le serveur est paramétré pour
demander le certificat client.
Il présente la liste des ca
acceptables
---
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
JRES2001
– Tutoriel Certificats X509 et Infrastructure de Gestion de Clés
etc
95
Stunnel 1/3
SSL Tunneling Proxy
http://www.stunnel.org)
Licence GPL ((http://www.stunnel.org)
-plateforme Unix, Windows
Multi
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
96
Stunnel 2/3
Peut être un client SSL (initialise le handshake
protocol
protocol)) ou en mode serveur.
Activer via inetd
inetd.. Exemple :
pop3s
usr/sbin/stunnel …… --l
l //usr/sbin/ipop3d
usr/sbin/ipop3d
pop3s stream
stream tcp
tcp nowait
nowait root
root //usr/sbin/stunnel
• 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)
97
Stunnel 3/3
/wrapper (respecte les
Compatible tcp
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.
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
99
concaténer le certificat serveur|client et sa clé
privée au format PEM dans un fichier (séparés par
une ligne vide)
path> pour spécifier l’emplacement de
Option ––pp <<path>
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 !!!
-signée sauf utilisateurs
Ne pas utiliser une clé auto
auto-signée
avertis
100
A). Même format
Les autorités de confiance (option ––A).
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
101
Exemples d’utilisation
Client IMAPS
Client
IMAP
Stunnel
client
Serveur IMAPS
Tunnel ssl
/usr/sbin/stunnel \
-c -d imap \
-r mailhost.cru.fr:imaps \
-p client.pem \
-A ca-bundle.pem
Stunnel
serveur
Serveur
IMAP
/usr/sbin/stunnel \
-d imaps \
-l /usr/sbin/imapd \
-v level3 \
-a client-cert-dir \
-p mailhost.pem \
-A ca-bundle.pem
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
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)
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
105
HTTPS
1 seul certificat (côté serveur) pour chiffrer la
saisie d’informations sensibles.
-commerce se limite souvent à cela !
EE-commerce
Chiffrer la saisie de mots de passe
Chiffrer les données des formulaires.
Chiffrer des cookies
cookies..
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 …
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.
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
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
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 »
111
Apache
ssl http://
www.openssl.org
open_
open_ssl
http://www.openssl.org
_ssl http://
www.modssl.org
mod
mod_ssl
http://www.modssl.org
_ssl peut être utilisé en mode DSO
mod
mod_ssl
112
Source http://www.modssl.org/docs/apachecon2001
113
Installation

Sur red hat 7.0 le rpm Apache installe
open_
ssl et mod
_ssl. Le démarrage
open_ssl
mod_ssl.
standard ouvre le port 80 et le port 443.
cd
openssl-0.9.6 ;; ./configure;
cd ../
../openssl-0.9.6
./configure; make
make
cd
mod-ssl-2.8.2
cd ../
../mod-ssl-2.8.2
./configure
with ../apache_1.3.19
with-ssl ../open
-ssl-0.9.6 ––prefix
prefix //usr/local/apache
usr/local/apache
./configure ––with
../apache_1.3.19 ––with-ssl
../open-ssl-0.9.6
cd
dummy ;; make
cd ../apache_1.3.19
../apache_1.3.19 ;; make
make ;; make
make certificate
certificate type=
type=dummy
make install
install;; c’est
c’est fini
fini !!
//usr/local/apache/bin/httpd
usr/local/apache/bin/httpd ––DSSL
DSSL
netscape
://localhost
netscape https
https://localhost
114
HTTPD.conf 1/3
Listen 443
SSLengine on|off
SSLCertificateFile SSLCertificatekeyFile
(File|Path)
SSLCACertificate
SSLCACertificate(File|Path)
• bundle par défaut
• make
SSLCertificateChainFile
115
HTTPD.conf 2/3
(File|Path)
SSLCARevocation
SSLCARevocation(File|Path)
SSLEngine on|off
optional|require
SSLVerifyClient none|
none|optional|require
SSLVerifyDepth n
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
Email} eq ««[email protected]
[email protected] » \
and %{SSL_CLIENT_I_DN_
%{SSL_CLIENT_I_DN_Email}
or %{
remote_addr} =~ m/^129
\.20\.10\.[0-9]/)
%{remote_addr}
m/^129\.20\.10\.[0-9]/)
SSLOptions +|
+|-- <option>
• StdEnvVars : extraction des infos du certificat vers
des variables à usage des CGI
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
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>
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
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?
121
Références
Documents
IGC CNRS :
IGC du CRU :
PKIX Working Group :
PKI Forum :
The Open–source PKI Book :
The PKI Page :
Serveur de RSA :
The SSL Protocol :
Serveur DCSSI :
Ten Risks of PKI:
http://www.urec.cnrs.fr/igc/Doc/IGC_docs.html
http://pki.cru.fr/
http://www.imc.org/ietf-pkix/index.html
http://www.pkiforum.org/
http://ospkibook.sourceforge.net/
http://www.pki-page.org/
http://www.rsasecurity.com
http://home.netscape.com/eng/ssl3/ssl-toc.html
http://developer.netscape.com/tech/security/ssl/howitworks.html
http://www.scssi.gouv.fr/
http://www.counterpane.com/pki-risks.html
Standards
RFC 2459 - PKIX Certificate and CRL Profile :
RFC 2510 - PKIX Certificate Management Protocols :
RFC 2511 - PKIX Certificate Request Message Format :
RFC 2527 - Certificate Policy and Certification Practices Framework :
RFC 2560 - PKIX Online Certificate Status Protocol (OCSP) :
RFCs S/MIME V2 :
RFCs S/MIME V3 :
http://www.ietf.org/rfc/rfc2459.txt
Produits
Openssl :
Modssl :
Stunnel :
Sendmail/TLS :
Postfix/TLS :
OpenCA :
http://www.openssl.org/
http://www.modssl.org/
http://www.stunnel.org
http://www.sendmail.org/~ca/email/starttls.html
http://www.hsc.fr/ressources/breves/postfix-tls.html
http://www.openca.org
122