Cryptage PDF

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é),
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).

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
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..
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

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)
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.

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

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.

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

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

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

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

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

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.

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..

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

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

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
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

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

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

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)

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
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
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)

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

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
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

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

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

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.

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

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

Certificats X509
Extensions :
• Rôle du certificat
Signature
Chiffrement
Non répudiation
…
• Informations diverses
Adresse de la CRL
…
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

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
af:c4:87:ad:75:bc:b4:79:f9:c7:67:cf:eb:4a:9c:bf:64:e3:
…
4a:03:5e:ea

Certificats X509
Vérification
Certificat de Alice
Version: 3 (0x2)
Fct de hachage Empreinte 1
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

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.
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.

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
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

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.

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

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

Autorité
d’Enregistrement
Service de
Validation
Annuaire
Opérateur
de Certification
Service de
Séquestre

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

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

Annuaire
Nécessité de publier les certificats
⇒ Utilisation dd’un
’un annuaire (LDAP)
Certificats (personnes, services, AC)
CRLs

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

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

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

Certificate Revocation List (CRL)
• Peu réactif
• Gestion lourde

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

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

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

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

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 ».

É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..

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.

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.

⇒ normes communes d’interopérabilité et
critères d’assurance communs entre
plusieurs organismes.
⇒ RFC 2527

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
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

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

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

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

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)

Chiffrement S/MIME
To: dupont@
tagada To: dupont@

Content-type: x-pkcs7-mime
0134ABD14378561…
random

Multi-destinataire
Pour chaque destinataire
To: dest1, dest2
tagada
To: dest1, dest2

Content-type: x-pkcs7-mime
random
0134ABD14378561…

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

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
…

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)

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.
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

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.

Principes généraux de SSL
HTTP
LDAP
IMAP
X509 POP
SSL
Communication
sécurisée
TCP
IP

Domaines d’application
PROTOCOLE PORT
LDAPS 636
POP3S 995
IMAPS 993
NNTPS 563
HTTPS 443

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

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

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

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.
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))

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

Implémentation de référence, licence « Apache »
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
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

# /usr/bin/openssl x509 –inform PEM –in cert.pem –text -noout
Certificate:
Data:
Version: 3 (0x2)
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:
…………………
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

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

# 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
---

# 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-----
................ 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)

# 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-----
...............
-----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
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

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)

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.

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

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
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

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

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

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)

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

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..

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 …

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.

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

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

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 »

Apache
open_ ssl http://
open_ssl 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

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

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

HTTPD.conf 1/3
Listen 443
SSLengine on|off
SSLCertificateFile SSLCertificatekeyFile
SSLCACertificate (File|Path)
SSLCACertificate(File|Path)
• bundle par défaut
• make
SSLCertificateChainFile

HTTPD.conf 2/3
SSLCARevocation (File|Path)
SSLCARevocation(File|Path)
SSLEngine on|off
SSLVerifyClient none| optional|require
none|optional|require
SSLVerifyDepth n

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
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

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>

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
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?
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
RFCs S/MIME V3 : http://www.ietf.org/rfc/rfc2630.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

Cryptage PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cryptage PDF

Transféré par

Droits d'auteur :

Formats disponibles

Certificats X509

Serge Aumont CRU

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

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

 Le chiffrement des messages est donc né avec

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

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

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

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

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

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

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

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

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

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

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

 Il existe de nombreuses méthodes d’attaque

 Force brute : essayer toutes les clefs

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

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

 Parade : utiliser un algorithme tel que le cryptogramme

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

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

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

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

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

 Principe introduit en 1976 par Diffie et Hellman

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

 Si annuaire des clefs publiques : permet une utilisation du

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

 Algorithmes de chiffrement : publics

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

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

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

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

Clef privée de Bob

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

 Outils courants : permettent de signer et de chiffrer

 Chaque utilisateur a un bibi-clef

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

• la clé est -elle toujours valide?

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

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

 RFC2459 : instanciation particulière de la

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

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

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 Public Key Info Clé publique de l’entité

X509v3 extensions Extensions X509

Signature Algorithm Algorithme de signature

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

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

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

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

Clé publique de l’autorité

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

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

 Il existe des autorités

 Le niveau de confiance dépend de

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

Le chiffrement des messages est donc né avec

Il existe de nombreuses méthodes d’attaque

Force brute : essayer toutes les clefs

En 97 : 3h pour casser une clef 40 bits

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

Parade : utiliser un algorithme tel que le cryptogramme

Principe introduit en 1976 par Diffie et Hellman

Si annuaire des clefs publiques : permet une utilisation du

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

Algorithmes de chiffrement : publics

Outils courants : permettent de signer et de chiffrer

Chaque utilisateur a un bibi-clef

RFC2459 : instanciation particulière de la

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

Il existe des autorités

Le niveau de confiance dépend de

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

Le certificat peut être signé a posteriori par une

Génération des certificats

Signature « mime Entity » :

S/MIME V3 adresse ces problèmes

Utiliser une couche avec chiffrement et

Applicable à toutes les applications sur TCP