1

Cryptographie
2
Chapitre1:
Les algorithmes de chiffrements
3
Le chiffrement: terminologie
l
Cryptologie = Cryptographie+Cryptanalyse
l
La Cryptographie: L ’étude des méthodes
permettant la transmission de données
confidentielles.
l
Chiffrement
l
Texte clair ---> texte Chiffré = cryptogramme
l
Déchiffrement
l
Texte chiffré ---> texte clair
l
La Cryptanalyse: étude des procédés
cryptographiques afin de trouver des failles et
pouvoir décrypter des textes chiffrés sans
connaître la clé de déchiffrement.
l
l
4
Chiffrement, Déchiffrement,
Décryptement
l
Cryptologie = Cryptographie+Cryptanalyse
Chiffrement
Déchiffrement
Texte
En clair
Clé de chiffrement
Texte chiffré
cryptogramme
Clé de déchiffrement
Texte
En clair
Décryptemen
t
Texte en clair et/ou clé
5
Les Algorithmes de chiffrement
l
Les Algorithmes Symétriques
l
Les Algorithmes Asymétriques
l
Les Algorithmes Hybrides
l
La cryptographie Quantique
l
Calculer les clés secrètes à l ’aide
d ’ordinateurs quantiques
l
Transmission d ’états quantiques sur la f.o.
l
Fraude ==> dérangement des états
quantiques
6
Les Algorithmes Symétriques
(à clé secrète)****
Données
en clair
Données
chiffrées
Données
en clair
Même clé
secrète
Alice
Bob
Principes
1 clé (secrète) pour le chiffrement et le déchiffrement
+Chiffrement de longs messages
- échange de clé secrète sur un canal sécurisé (autre que
l ’Internet) entre l ’émetteur et le récepteur
+ autant de clés que de récepteurs
7
Les Procédés de Chiffrement

l
Le chiffrement par bloc (bloc cipher):

Opèrent sur bloc de 64 bits en général

ex: - DES (clé de 56 codée sur 64)

- 3DES

. EDE: Encrypt-Decrypt-Encrypt

. 3 clés distinctes (160 bits) ou 2 (112bits)

. IDEA (128 bits)

. CAST-128

. Blowfish (clé de taille variable jusqu’à 448 bits

. AES (Rijndael, longueur variable: 128, 192, 256 bits
l
Le chiffrement continu (stream cipher): chiffrement
d ’un bit à la fois.
l
Ex: RC4: longueur de clé variable, généralement 128bits
8
Algorithmes de
chiffrement
Concepteur(s) Taille de la clé Taille du bloc Commentaires
RC4
(Continu)
Ron Rivest (1994) Variable, 128 bits en
général
Adapté aux codages rapides
10 fois plus rapide que DES
RC2
(Par bloc)
Ron Rivest Variable Equivalent à DES
DES (Data Encryption
Standard)
(Par bloc)
IBM (1976) 56 bits 64 bits Relativement rapide
Destiné au chiffrement de gros volumes
Clé craquée en 1998
Triple DES
(Par bloc)
IBM
et dérivé de DES
3 clés
différentes, 168 bits
64 bits Remplace DES
IDEA
(International Data
Encryption Algorithm)
Par bloc
X.Lai et J. Massey
(1990)
128 bits 64 bits Conçu pour une efficacité maximale lors de
calculs logiciels
Nécessite une licence
BLOWFISH
Par bloc
Bruce Schneier
(1994)
Variable, de 32 à 448
bits
64 bits Rapide
Gratuit
CAST-128
Par bloc
Carlisle Adams, et
Stafford Tavares
128 bits 64 bits Alternative à IDEA et Blowfish, mais moins
utilisé qu’eux
Rijndael
(NIST finaliste de l’AES
(Advanced Encryption
Algorithm) compétition)
Joan Daemen, et
Vincent Rijmen
Variable
128, 192 ou 256 bits
128 bits Considéré comme l’algorithme de
chiffrement le plus fiable actuellement
Algorithmes de Chiffrement Symétrique
9
Les Algorithmes Symétriques
(à clé secrète)

Les Algorithmes Symétriques
l
DES:
l
publié par le NIST, norm. ANSI, clé: 64 et 128 bits
l
AES (Advanced Encryption Standard)
l
RC2 & RC4 (Ron ’s Code 2 ou Rivest Cipher 4)
l
RSADSI (privé), clés de taiiles variables,
l
RC2 4x+rapide que DES, RC4 10x+ rapide.
IDEA (International Data Encryption Algorithm)
l
IDEA (International Data Encryption Algorithm)
l
1990, breveté au Japon, clé: 128bits,

10
Les Algorithmes à clé publique
(Asymétriques)
l
RSA:
l
paire de clé: clé privée & clé publique
l
message chiffré avec une clé de la paire ne peut
être déchiffré qu ’avec l ’autre clé de la même
paire.
l
Impossible pratique de déterminer la clé privée à
partir de la clé publique
l
Inconvénient: lenteur pour les longs messages
l
Rabin et El Gamal: moins utilisés
11
Les Algorithmes à clé publique
(Asymétriques)
l
Diffie & Hellman : 1976
l
RSA : 1978
l
Basée sur des problèmes difficules à résoudre
l
Logarithmes discret
l
Factorisation des grands nombres
l
Clés de chiffrement et de déchiffrement distinctes
l
La connaissance de la clé publique ne permet pas
de connaître la clé privée correspondante
l
Inconvénient: lenteur pour les longs messages
l
Usage non intense recommandé

12
Les Algorithmes à clé publique
l
Les Algorithmes à clé publique: 1996, Diffie et
Hellman
l
RSA
l
chiffrement et signature numérique
l
DSA
l
signature numérique, cle publique de 1024
bits, plus long que RSA
l
Diffie-Hellman
l
utilisé pour la distribution des clés
l
13
Algorithmes
de
chiffrement
Concepteur
(s)
Taille de
la clé
Taille du
bloc
Commentaires
RSA (Rivest,
Shamir,
Adelman)
(Par bloc)
Rivest, Shamir,
et Adelman
(1978)
Variable,
512 bits
en
général
Variable
et < taille
des clés
Système le plus utilisé
Nécessite une licence
Diffie-
Hellman
Whitfield
Diffie, Martin
Hellman
(1976)
Système de cryptage le
moins récent et toujours
en exploitation
El Gamal El Gamal
(1985)
Variante de Diffie-
Hellman, mais
nécessitant l’envoi du
double d’information
Les algorithmes de chiffrement asymétrique
14
Données
en clair
Données chiffrées
Données en
clair
Alice Bob
Clé publique de
Bob
Clé privée de
Bob
Chiffrement: Utiliser la clé publique du récepteur pour le chiffrement
seul e détenteur de la clé privée peut déchiffrer le message
Données
en clair
Données chiffrées
Données en
clair
Alice Bob
Clé pivée de
Alice
Clé publique
de Alice
Signature: Utiliser la clé privée de l’émetteur pour le chiffrement
seul le détenteur de la clé privée peut chiffrer le message
· utilisée pour la signature
Utilisations de la Cryptographie à Clé Publique
15
Cryptographie Symétrique et
Asymétrique: utilisation
l
Cryptographie à clé publique
l
Lente
l
 n p ut p s êtr
ut l sé pour r r
l s onné s

La combinaison des deux type d ’algo.
l
Chiffrement : algo. Symétriques
l
transmission de la clé secrète: algo. Asymétrique
l
==> Base des normes de sécurité

16
Données
en clair
Données
chiffrées
Alice
Clé secrète
Clé publique de
Bob
Clé secrète
Enveloppe
numérique
Clé privée de
Bob
Clé secrète
Données
chiffrées
Clé secrète
Données
en clair
Exemple de combinaison clé publique/clé secrète**
Enveloppe
numérique
17
La Signature Numérique

ISO 7498-2 :

Signature numérique = “données ajoutées
à une unité de données, ou transformation
cryptographique d’une unité de données,
permettant à un destinataire de prouver la
source et l’intégrité de l’unité de données, et
protégeant contre la contrefaçon (par le
destinataire, par exemple)”.

seul l’expéditeur doit être capable de générer
la signature.

La signature numérique 

Authentification de l’origine des données + intégrité
des données + non-répudiation de l’émetteur
18

Les Signatures Electronique
Diffie et Hellman en 1992
Authentification+Non Répudiation de
l ’émetteur+Intégrité

Principe :

1- Appliquer une fonction de hashage au message à
transmettre

--> résumé=condensât, empreinte

2- Chiffrer le résumé avec la clé privée de l ’émetteur

Les algorithmes de hachage
l
MD5
l
1991 par RSA, empreinte de 128 bits,
machines 32 bits, checksums antivirus
l
SHA-1
l
1993 par NIST, révisé 1994, empreintes de
160 bits sur documents de au - 264 bits
de longueur

19
La Signature Numérique:
Fonctionnement***
Empreinte Signature
Alice
Bob
Clé
publique
Alice
Clé privée
Alice
Signature
Empreinte
Empreinte
Identiques ?
Signature :
Vérification :
Message
Message
20
Message
Empreinte
Le Hachage**
Fonction de hachage= fonction de condensation:
convertir une chaîne de longueur quelconque en
une chaîne de taille inférieur, et généralement fixe.
appelée empreinte (digest), ou condensé de la chaîne initiale.
21
Le Hachage****
Fonction de hachage
A sens unique: il est difficile d’engendrer la chaîne initiale à
partir de l’empreinte.
Sans collision: il est impossible de trouver deux messages
ayant la même empreinte.
La plupart des fonctions de hachage à sens unique sans collision sont
construites par itération d’une fonction de compression:
- M est décomposé en n blocs m1, m2, …, mn,
- Une fonction de compression f est appliquée à chaque bloc,
et au résultat de la compression du bloc précédent.
- L’empreinte h(M) = résultat de la dernière compression.
Les fonctions de hachage
intégrité.
Sensible à l’attaque MIM !
22
Les Fonctions de
Hachage**
Fonctions de
hachage
Concepteur
(s)
Taille de
l’empreinte
Commentaires
MD5
(Message
Digest 5)
Ronald Rivest
(1991)
128 bits Successeur de MD4
Présente des problèmes de
collision qui ont affecté son
expansion
SHA
(Secure Hash
Algorithm)
NSA (National
Security
Agency), et
normalisé par
le NIST
160 bits SHA-1 révision publiée en
1994, considérée plus sur
que MD5
SH1-2 (octobre 2000)
agrandit la taille de
l’empreinte dans plusieurs
versions en 224, 256, 384, et
512 bits
23
La Signature Numérique:
Les algorithmes
Algorithme de
Signature
numérique
Concepteur
(s)
Algorithme de
chiffrement à
clé publique
Fonction de
hachage
DSA (Digital
Signature
Algorithm)
DSS (Digital
Signature
Standard)
NIST(1991) El Gamal SHA-1
RSA Digital
Signature
Rivest,
Shamir, et
Adelman
RSA SHA-1 ou MD5
24
Le Scellement**


Principe : Adjoindre au message un
sceau ou code d ’authentification
(MAC) résultant d ’un hachage et
crypté avec un clé secrète

Vocabulaire:
l
MAC = Message Authentication Code =
Sceau

Scellement 

Authentification de l’origine des données +
intégrité des données.
25
Le Scellement****


Construction possible :
1.Dernier bloc du cryptogramme obtenu
avec un alogorithme de chiffrement en
mode CBC
2.Fonction de hachage à sens unique avec
une clé:
1. Keyed-MAC (Keyed MD5, Keyed SHA-1)

Hach (secret, message,secret)

2. HMAC (HMAC MD5, HMAC SHA-1)

H(K+opad, H(K+ipad,M))
26
Le Scellement**

La façon la plus courante: générer un code
d’authentification de message en appliquant un
algorithme de chiffrement symétrique en mode
CBC au message. Le MAC est alors le dernier
bloc du cryptogramme comme l’illustre la figure
suivante
Clé
secrète
Message
(longueur variable)
Algorithme
de
chiffrement
symétrique
en mode CBC
Dernier bloc
Code d’authentification
de message
27
Le Scellement: Fonctionnement***
Scellement:
Sceau
Alice
Bob
Clé secrète
Identiques ?
Vérification :
Message
Sceau
Message
Sceau
Clé secrète
28
Fonctions de hachage,
signature et scellement

3 services de sécurité
l
Intégrité des données
l
Authentification de l’origine
l
Non répudiation de l’origine
29
Intégrité et authentification

S’assurer que
1.Le message provient bien de la source
annoncée

 ut nt t on
l’or n

2. Il n’a pas été modifié en cours de transfert

 nté r té

s rv s n sso l s
30
Principe de l’algorithme RSA
l
l
• Soit P et Q deux grands nombres premiers
l
• Soit N = PQ
l
• Soit Φ(N)=(P-1)(Q-1)
l
• On calcule D et E tels que
l
– E premier avec Φ(N) dans l’intervalle [max(P,Q)
+1,
l
N-1]
l
– D inverse de E modulo Φ(N)
l
• Clé publique = {E,N}
l
• Clé privée = {D, P, Q}
31
l
Soit P et Q deux grands nombres premiers
l
• Soit N = PQ
l
• Soit Φ(N)=(P-1)(Q-1)
l
• On calcule D et E tels que
l
– E premier avec Φ(N) dans l’intervalle [max(P,Q)+1, N-1]
l
– D inverse de E modulo Φ(N)
l
• Clé publique = {E, N}
l
• Clé privée = {D, N} P et Q doivent rester secrets!
l
• Chiffrement : C = M
E
mod N
l
• Déchiffrement : M = C
D
mod N
32
l
• P=3, Q=11 , premiers,
l
• N = 33
l
• φ(33)=(P-1)*(Q-1)=20
l
• On choisit :
l
– E = 13 [12, 33] ∈
l
– D = inv(13,20) = 17 (car 13*17 mod 20 = 1)
l
• Chiffrement de M=2
l
– C = 2
13
mod 33 = 8192 mod 33 = 8
l
• Déchiffrement
l
– 8
17
mod 33 = 2 = M
33
34
l
Vote électronique (le résultat reflète le vote,
chaque vote est confidentiel, on ne peut
pas connaître des résultats partiels, seuls
les
l
électeurs peuvent voter et une seule fois)
35
36
l
Décodeurs (vérification de l'abonné,
impossibilité de retransmettre les données
décodes à une tierce personne, mise a jour
de l'abonnement)
37
38
l
Porte monnaie électronique (pas de création
de fausse monnaie, pas de création de
faux porte-monnaie)
39
40
l
Bases de données sécurises (ex : carte
vitale. seules les personnes habilitées ont
accès a la vue partielle a laquelle elles ont
droit, les données peuvent être échangées
entre un médecin, un laboratoire, un
hôpital, mise à jour possible des données)
41
42
l
En pratique : E et D sont paramétrées par des clés
Ke et Kd : E
Ke
(M) = C et D
Kd
(C) = M
l
I Ke ;Kd ∈ espace des clés.
l
I Définit deux catégories de systèmes
cryptographiques :
l Systemes à clé secrète (ou symétriques) (K
e
= K
d
=
K)
l
Systèmes à clé publique (ou asymétriques) (Ke ≠ Kd
)
43
Chapitre2:
Les algorithmes d’attaques
44
Les grands types de menaces :
menaces passives
l
Oscar ne fait qu'écouter le message.
l
menace la confidentialité
l
une information sensible parvient également
à une autre personne que son destinataire
légitime.
45
Les grands types de menaces :
menaces actives
l
Oscar peut modifier le contenu des messages échangés.
l
menace l'intégrité de l'information.
l
Exemple d'attaques actives :
l
l'usurpation d'identité (de l'émetteur ou du récepteur)
l
l'altération / modification du contenu des messages ;
l
la destruction de messages/ le retardement de la transmission ;
l
la répétition de messages (jusqu'a engorgement)
l
la répudiation de message : l'émetteur nie avoir envoie le
message.
46
Modélisation de l'adversaire
l
On veut modéliser un attaquant :
l
Ile plus intelligent possible ! il peut faire
toutes les opérations qu'il souhaite
l
Qui dispose d'un temps limite.
l
on ne souhaite pas considérer les attaques
faisables en 280 ans sinon, l'adversaire
peut touut toujours énumérer toutes les
clefs (temps
l
exponentiel en 2
taille(clefs
))
l
47
Les attaques sur un
chiffrement
l
Cryptanalyse : étude de la sécurité des procèdes de chiffrement
l
utilises en cryptographie
l
Niveaux d'attaques possibles :
l
Texte chiffre connu : seul C est connu d'Oscar
l
Texte clair connu : Oscar connaît C et M correspondant
l
Texte clair choisi : quelquesoit M, Oscar peut obteinir C
l
Texte chiffré choisi : quelquesoit C, Oscar peut obtenir M
l
garantir la confidentialite ) Oscar ne peut pas :
l
trouver M a partir de E(M)
l
trouver la méthode de déchiffrement D a partir d'une séquence
l
Mi ; E(Mi ):
48
Algorithmes d'attaques
l
Attaque brutale
l
Énumérer toutes les valeurs possibles de
clefs
l
64 bits ) 2
64
clefs = 1.844 * 10
19

combinaisons
l
Un milliard de combinaisons/s ) 1 an sur
584 machines
49
Attaque par séquences
connues
l
Deviner la clef si une partie du message est
connue
l
ex : en-têtes de standard de courriels
l
50
Attaque par séquences forcées
l
Faire chiffrer par la victime un bloc dont
l'attaquant connaît le contenu, puis on
applique l'attaque précédente ...
l
l
51
Attaque par analyse différentielle
l
Utiliser les faibles différences entre plusieurs
messages (ex : logs)
l
pour deviner la clef
52
Deep Crack, circuit dedie a l'attaque par
force brute de
DES.
53
Bref historique des codes
secrets.
l
Cryptographie Ancienne
l
Transposition Sparte (5eme siècle av JC)
l
Substitution César : décalage des lettres (1er
siècle av JC),
54
Enigma
55
Chiffrement symétrique : outils
de base utilises
56
l
Autres opérations utiles :
l
Arithmétique modulaire dans Zn; a; b; n 2 N; avec n 2:
l
a = b mod n n divise a b
l
En pratique : b = reste de la division euclidienne de a par n:
l
5 = 1 mod 4 et 3 = 125 mod 128 ·
l
I Notions associées : Primalité, Euclide, Th. des restes chinois,
Gauss,
l
Euler...
l
opération XOR (ou exclusif )
l
Opération bijective (bijection inverse : )
l
correspond a une addition bit-a-bit modulo 2.
57
Le chiffrement de César...
l
Chiffrement par décalage avec K = 3:
l
EK (M) = M + K mod n et DK (C) = C - K mod n
l
Seulement n façons différentes de chiffrer un
message
l
code très peu sur (recherche exhaustive facile)
l
avantage de la simplicite employé par les ociers
sudistes (guerre de Seccession)
l
remployé sur les forums de News : ROT 13(K =
13)
l
Generalisation : chiffrement affine E(a,b)(M) = a* M
+ b mod n( pour a ∈ Zn )
58
59
Exercice:
RSA
60
R.S.A
Ø Alice veut envoyer M à Bob.
l
M un entier représentant un message.
l
Bob choisit p et q deux nombres premiers et on note n leur
produit.
l
Bob choisit e un entier premier avec p - 1 et q - 1.
l
On a ϕ (n) = (p - 1)(q - 1) donc e est premier avec ϕ (n) et on
obtient (via Bezout) qu'il est inversible modulo ϕ (n); i.e. il
existe un entier dtel que e.d ≡ 1 (mod ϕ (n)).
l
Le message chiffré sera alors représenté par :
l
C = M
e
(mod n)
l
Pour déchiffrer C; on calcule d l'inverse de e mod ϕ (n); ensuite
on
l
calcule C
d
mod n
61
Ø On a alors,
l
 C
d
(mod n) (M
e
)
d
(mod n) ≡ M
ed
(mod n)
Ø Comme ed ≡ 1 (mod ϕ (n)) par définition de modulo, on a
l
ed = 1 + kϕ (n); avec k ∈ N:
Ø D'où,
l
M
ed
(mod n)≡ M.M
kϕ (n)
(mod n) ≡ M (M
ϕ (n)
)
k
(mod n)
Ø
Or si x est premier avec n; on a x
ϕ (n)
≡ 1 (mod n);
Ø d'après le théorème d'Euler.
Ø Donc finalement, si le message M est premier avec n :
l
C
d
≡ M (mod n)
62
Ø
Le cas ou le message M n'est pas premier avec n
est un peu plus compliqué mais le résultat reste le
même :
l
C
d
≡ M (mod n):
Ø
(n,e) est appelé clef publique
Ø
(n,d) est appelé clef privée.
Ø
pour chiffrer, il sut de connaître e et n.
Ø
pour déchiffrer, il faut d et n; autrement dit connaître
la décomposition de n en facteurs premiers.
l
63
Schéma

Alice Bob

M

choisit p et q

e premier avec p - 1 et q - 1

calcule n = p* q

d tel que ed ≡ 1 (mod
ϕ (n))

envoie (n,e) à Alice

calcule C = M
e
(mod n)

et l'envoie a Bob

calcule C
d
(mod n)

et en déduit M
l
64
Le cryptosystème RSA :
Exemple
l
Ø Prenons p = 47 et q = 59
Ø On calcule n = p.q = 47.59 = 2773
Ø On choisit e, premier par rapport à ϕ (n) . Ex : e = 17:
Ø On calcule alors, par l'algorithme d'Euclide étendu, d tel que
l
d . e= 1 mod (p - 1)(q - 1) , soit d = 157:

Clef publique : (e, n) = (17, 2773)

Clef prive : d = 157:
Ø Chiffrement du message M = 01000010 = 66 :
l
C = M
e
mod n = 66
17
mod 2773 = 872
Ø Déchiffrement de C :
l
C
d
mod n = 872
157
mod 2773 = 66
65
Le cryptosystème RSA :
Exercice
l
Prenons p = 29, q = 31 et e = 13. Utilisé le
protocole RSA pour chiffrer et déchiffrer
l
M = 123
l
Casser RSA est équivalent à la factorisation
de n
l
66
Réponse
Ø
Les variables étant données, p = 29; q = 31; e =
13; m = 123;
Ø
Nous calculons : n = p* q = 899
Ø
(p - 1)* (q -1) = 840
l
d = 517 car e*d = 13 517 = 8 * (p - 1) * (q - 1) + 1
Ø
Pour chiffrer,
l
c = 12313 mod 899 = 402
Ø
Et pour déchiffrer,
l
m = 402
517
mod 899 = 123
l
67
Protocole d'échange de clefs de Diffie-
Hellman
68
l
Alice et Bob veulent partager une clé secrète K. On
suppose que les données G,n = |G| et g sont
publiques.
Ø
Alice choisit un entier 1≤ a≤ n -1 au hasard.
Ø
Alice calcule A = g
a
et l'envoie à Bob.
Ø
Bob choisit un entier 1 ≤ b ≤ n - 1 au hasard.
Ø
Bob calcule B = g
b
et l'envoie à Alice.
Ø
Alice est en mesure de calculer B
a
et Bob de
calculer A
b
.
Ø
La clef commune est donc
l
K = g
ab
= A
b
= B
a
l
69
Schéma

Alice Bob
l
génère a génère b
l
A = g
a
mod p B = g
b
mod p
l
A
l
B
l
(dispose de [a,A,B,p]) (dispose de[b,A,B,
p])
l
Clé secrète: K = B
a
mod p Clé secrète : K = A
b

mod p
70
Protocole d'échange de clé de Die-
Hellman (exemple)

1. Alice et Bob choisissent un nombre premier p et une base g:
Dans notre exemple, p = 23 et g = 3

2. Alice choisit un nombre secret a = 6

3. Elle envoie à Bob la valeur g
a
mod p = 3
6
mod 23 = 16

4. Bob choisit à son tour un nombre secret b = 15

5. Bob envoie à Alice la valeur g
b
mod p = 3
15
mod 23 = 12

6. Alice peut maintenant calculer la clé secrète :
l
(g
b
mod p)
a
mod p = 12
6
mod 23 = 9

7. Bob fait de même et obtient la même clé qu'Alice :
l
(g
a
mod p)
b
mod p = 16
15
mod 23 = 9
71
Protocole d'echange de cle de Die-
Hellman (exercice)

1. Supposons qu'Alice et Bob partagent p =
233 et g = 45 :

2. si Alice choisit a = 11 et Bob b = 20,alors :

3. Quelle est leur clef secrète commune
72
Protocole d'échange de cle de
Die-Hellman (corrigé)
l
g
a
= 45
11
mod 233 = 147; g
b
= 45
20
mod 233
= 195;
Ø
(g
b
)
a
mod p = 195
11
mod 233 = 169 et (g
a
)
b

mod p = 147
20
mod 233 = 169:
Ø
Alice et Bob disposent d'une clé privée
commune : k = 169:
l
73
Chapitre 3:
PKI
(Public Key Infrastructure)
74
L ’infrastructure PKI
(Public Key Infrastructure)

=ICP (Infrastructure à Clés Publiques)
l
Cryptographie à clés publiques : 2clés

==> distribution de la clé publique aux
correspondants
l
Problème : Confiance dans l ’authenticité
de la clé publique
l
émettre des informations confidentielles
l
Clé publique de chiffrement du récepteur
l
recevoir des informations signées
l
Clé publique de signature de l ’émetteur
75
PKI (suite)

Définition

Infrastructures, englobant différentes entités, protocoles et
services du réseau, afin de gérer les clés publiques à grande
échelle.

= Ensemble de personnel, composants et procédures dédiés
à la gestion de clés et de certificats utilisés par des services de
sécurité.


Rôl *****

m ss on t l’ nr str m nt s
lés pu l qu s l ur sto t
str ut on l ur révo t on t ·
vér t on st tut t n n
l ur s uv r t ré upér t on

répondre aux besoins de confidentialité, d’authentification, du
contrôle d'accès, de non répudiation et d’intégrité.

76
l
L’autorité de certification (AC)
l
L’autorité d’enregistrement (AE)
l
Un système de stockage des certificats ou
des listes de certificats révoqués (LCR)
l
Les utilisateurs finaux et les administrateurs
l
La politique de certification qui décrit les
relations entre les différents composants
Constituants Elémentaires
77
PKI (suite)
l
Autorités de certification (CA)
l
Accepte la clé publique moyennant une ou plusieurs
preuves d ’identité et des droits d ’obtention
l
Tient une base de données de certificats
l
Tient une liste de certificats révoqués
l
Dispose d ’un agrément de délivrance de certificats

l
Autorités d ’enregistrement (RA)
l
Assure la validation de l ’identité de l ’entité pour
laquelle la CA va générer un certificat
l
Relation de confiance entre CA et RA
78
Services d’une ICP
l
Enregistrement des utilisateurs finaux
l
Création d’un certificat
l
Publication d’un certificat ou d’une LCR (Liste de
Certificats Révoqués)
l
Renouvellement des certificats
l
Révocation des certificats
l
Archivage des clés de chiffrement
l
Validation des certificats
l
Horodatage
79
PKI (suite)
Application
d’abonnement
Services de
chiffrement
Relais de
l’application
de partie
Service
de
validation
Service
d’annuaire
Autorité
d’enregistrement
API
Sur le fil
Utilisateur final A Utilisateur final B
Autorité de
certification A
c
c
è
s

à

l

a
n
n
u
a
i
r
e
I
n
t
e
r
f
a
c
e

d

é
d
i
t
i
o
n

d
e

c
e
r
t
i
f
i
c
a
t
Alimentation de l’autorité de validation
Vérification
de statut
en ligne
Application de certification
Demande de révocation
Interface AC/AR
Accès à l’annuaire
80
Standards applicables
l
RFC 3280 : détails des structures du certificat et de
la LCR resp. au format X509 v3 et v2.
l
RFC 3647 : Internet X.509 PKI Certificate Policy and
Certification Practices Framework.
l
RFC 2587 : Internet X.509 Public Key Infrastructure
LDAPv2 Schema.
l
RFC 3161 : Internet X.509 Public Key Infrastructure
Time Stamp Protocols (TSP).
l
PKCS : développés par les laboratoires RSA.
l
Etc.
81
Les Certificats: Contenu &Format
Un certificat électronique comporte généralement, et selon
le format de sa norme:
-nom du détenteur de la clé publique
-une clé publique de chiffrement
-un délai de validité (entre six mois et un an)
-une catégorie
-un numéro d’identification du certificat
-raison sociale de l’organisme de certification.
Types:
Verisign : 4 classes de certificats
X509 (ITU-T) (version, numéro de série, algorithme de signature,
ID, nom de l ’émetteur; période de validité, nom utilisateur, clé
publique, IU émetteur, IU utilisateur, extensions, signature des
informations )
-
82
Serial number
Version
Serial algorithm ID
Issuer name
Validity period
Subject name
Subject public key info
Issuer unique ID
Subject unique ID
Signature:
Algorithm ID and signature value
Extensions (Type, Critical/ Non-critical, Field value)
Génération de la
signature
Clé privée de
l’AC
V2
V3
Version : Indique la version X.509 du certificat (v1, v2, ou V3)
Serial number : Numéro de série du certificat, qui est propre à chaque AC
Signature Algorithm ID : Identifiant du type de signature utilisée
Issuer Name : Distinguished Name (DN) de l’AC qui a émis le certificat
Validity period : Période de validité, avec les dates et heures de début et
d’expiration
Subject Name : Distinguished Name (DN) du détenteur de la clé publique
Subject public key info : Informations sur la clé publique du certificat
Issuer Unique ID/ Subject Unique ID : Extensions optionnelles introduites avec la
version 2 de X.509
Extensions : Extensions génériques optionnelles, introduites avec la version 3
Signature : Signature numérique de l’AC sur l’ensemble des champs précédents
83
Garantie de la
véracité des
informations
contenues dans le
certificat émis
Alice
Bob
Clé
publique et
preuve
d’identité
Récupération du
certificat via
annuaire par
exemple
Requête de
certificat
Alice
CA
Certificat
auto-signé
Émission de
certificat
AC
Récupération du
certificat d’une façon
sûre
Vérification de la
signature de l’AC
Les Certificats: Emission et Vérification
Un certificat : « connecte » l ’identité d ’une entité à sa clé publique
signé par un organisme de confiance CA (Autorité de
Certification)
84
PKI: Solutions
Commerciales***
l
Entrust
l
Baltimore
l
RSA
l
SSH
l
Valicert
l
Cryptomatic
l
etc.
85
l
OpenSSL
l
OpenCA
l
IdealX
l
TinyCA
l
NewPKI
l
etc.
l
PKI: Solutions Open Source
86
Cas pratique : OpenSSL
l
Effort de collaboration pour développer un
toolkit robuste et complet, avec un code
source disponible.
l
Contrôlé par une communauté de bénévoles
qui utilisent l'Internet développer le toolkit
et sa documentation.
87
OpenSSL (suite)

Propriétés
l
Application de SSL v2/v3.
l
Protocole de sécurité de couche transport : TLS.
l
Bibliothèque cryptographique :
l
AES, DES3, DES…
l
RSA, DSA, ECC…
l
SHA1, MD5…

Sous redhat 9:
l
Fichier de configuration :
/usr/share/ssl/openssl.cnf
l
Exécutable : /usr/bin/openssl


88
OpenSSL (démo)
l
Architecture : autorité de certification unique (single
CA).
l
Fonctions à réaliser :
l
Génération de paire de clés asymétrique
l
Génération d’un fichier de requête (PKCS #10)
l
Signature de certificat
l
Révocation de certificat
l
Génération d’une LCR
l
Outil : openssl
89
Mise en place de l’autorité
l
Génération de la paire de clé :

openssl genrsa –des3 –out
private/cakey.pem 2048
l
Génération du certificat auto-signé :

openssl req –x509 –new –days 3650 –key
private/cakey.pem –out cacert.pem
90
Génération d’un certificat
d’utilisateur final
l
L’utilisateur peut être : personne physique,
serveur web, routeur VPN, autorité de
certification.
l
Différences :
l
Valeur du champ keyUsage
l
Format de clé et du certificat
91
l
Génération de la paire de clé :

openssl genrsa –des3 –out private/user.pem 1024
l
Génération de la requête :

openssl req –new –key private/user.pem –out reqs/user.req
l
Signature du certificat :

openssl ca –in reqs/user.req –out newcerts/user.crt
l
Export en format pkcs#12 :

openssl pkcs12 –export –inkey private/user.pem –certfile
cacert.pem –in newcerts/user.crt –out p12/user.p12
Génération d’un certificat
d’utilisateur final (suite)
92
Révocation d’un certificat
l
Révocation d’un certificat :

openssl ca –revoke newcerts/user.crt
l
Génération d’une LCR :

openssl ca –gencrl –out crl.crl
93
Commandes d’affichage
l
Clé : openssl rsa –in /private/user.pem –
text
l
Requête : openssl rsa –in reqs/user.req –
text
l
Certificat : openssl x509 –in
newcerts/user.crt –text
l
p12 : openssl pkcs12 –in p12/user.p12 –
info
l
LCR : openssl crl –in crl.crl –text
94

Les Protocoles de sécurité
l
Différents niveaux de la pile TCP/IP
l
Niveau physique: boitiers chiffrants
l
Niveau 2:
l
PPTP (Point to Point Tunneling protocol)
l
L2TP (Layer 2 Tunneling protocol)
l
Niveau 3: Ipsec
l
Niveau Socket: SSL, TLS
l
Niveau Applicatif: S/HTTP; S/MIME,
PGP/MIME, SET, IKE
95
Chapitre4:Les
Protocoles de Sécurité
IPsec,IPv4,IPv6
96
Les Protocoles de Sécurité
IP
IPsec (AH, ESP)
TCP
H
T
T
P
F
T
P
S
M
T
P
S
-
H
T
T
P
S
/
M
I
M
E
SET PGP
Couche Application
Couche Session
Couche Transport
Couche Réseau
SSL (TLS)
PPTP L2TP
PPP
97
IPsec

IP v6: Nouvelle version du protocole IP

– Version courante = v4 (25 ans). Nouvelle = v6

– Aucun changement sur les autres niveaux

● Règle des problèmes actuels

– Adressage, efficacité, facteur d'échelle, ...

● Ajoute des fonctionnalités nécessaires

– Mobilité, sécurité, autoconfiguration, qualité de

service

● Marchés primaires en 2004: Japon, Corée, Chine,

Europe, US DoD

98
Adresses IPv4 et IPv6
99
IPv6
•Adresses: de 32 à 128 bits:
-Pour les populations non encore connectées
-Automatisation (autoconfiguration, découverte, ...)
-Un large espace d'adresses (réseau maison a plus d'adresses
que l'Internet IPv4)
-Un espace d'adressage privé, mais globalement unique
Résout les connections entre réseaux privés, fusions,
intégrations.
•Bout en bout est restauré
Applications peuvent etre déployées
Securité bout en bout sans compromis
Gestion de réseaux beaucoup plus simple et efficace
•IP partout, sur tout: milliards de dispositifs
connectés: cell 3G, senseurs, multimédia, etc...
•Réseaux adhoc automatisés, sans conflits.
•Aggrégation des préfixes

100
IPv6
•Facteur d'échelle (scalabilité) et efficacité
– Routage plus simple et efficace
Moins de traitement des paquets IP par les routeurs
– Les routes globales sont plus simples à gérer et plus
stables
– ...
101
Types d'adresses IPv6
l
“standard”

Chaque “site” reçoit des adresses pour: 65K réseaux (LAN)

Chaque réseau (LAN) peut avoir: 264 ordinateurs

Site = organisation, entreprise, maison
l
Privées uniques

Chaque site peut avoir un autre espace d'adresses privées,

mais unique globalement: aucune autre org ne peut avoir ces

adresses.
l
Temporaires

Chaque session d'un usager peut utiliser une adresse
temporaire

102
Nouvelles fonctionalités
l
Mobilité
l
“tout” est devenu mobile. 3G, Wifi, etc...
l
Sécurité incluse et bout en bout
l
Autoconfiguration, découverte
l
micro-senseurs, “entertainment”, plug and play,
...
l
Qualité de service

103
IPsec et IPv6
l
IPsec difficile à déployer avec IPv4 à cause de
la traduction d'adresses (NAT)
l
Toute implémentation d'IPv6 inclut IPsec.
l
IPv6 rend le déploiement d'IPsec possible,
simple et à une très grande échelle.
l
Sécurité bout en bout
l
Filtrage, journalisation, gestion de la sécurité

104

Ipsec : 2 sous protocoles
l
AH (Authentication Header)
l
Intégrité des données
l
ESP (Encapsulating Security Payload)
l
Confidentialité des données: Chiffrement

Ipsec : 2 modes
l
Mode Tunnel
l
Tunneliser le datagramme IP& génération d ’un nouvel
en-tête IP
l
protection totale entre Firewalls mais lenteur
l
Mode Transport
l
Appliquer les services de sécurité sur les données
seulement
l
garder l ’en-tête IP d ’origine
l
Utilisé par les hosts, assez rapide
l
pas d ’authentification,confidentialité de l ’en-tête IP
(gênant quand spoofing)
l
105
IPsec: les modes
106
Champs protégés avec AH
107
IPsec AH Extension Header,
Transport**
108
IPsec AH Extension Header,
Tunnel
109
Protection (IPv4) avec ESP
110
IPsec ESP Extension Header,
Transport***
111
IPsec ESP Extension Header,
Tunnel
112
IPsec AH-ESP Extension Headers, Tunnel+Transport
113
IPSEC : AH
authentification des datagrammes
T
R
A
N
S
P
O
R
T
114

TU
N
N
E
L
115
IPSEC : ESP
confidentialité/authenticité des
données
T
R
A
N
S
P
O
R
T
116
TU
N
N
E
L
117
SSL
118
sous Internet Explorer sous Mozilla
119
Fonctionnement de SSL 2.0
l
La sécurisation des transactions par SSL 2.0 est
basée sur un échange de clés entre client et
serveur. La transaction sécurisée par SSL se fait
selon le modèle suivant :
l
Dans un premier temps, le client se connecte au site
marchand sécurisé par SSL et lui demande de
s'authentifier. Le client envoie également la liste
des cryptosystèmes qu'il supporte, triée par ordre
décroissant selon la longueur des clés.
120
l
Le serveur à réception de la requête envoie
un certificat au client, contenant la clé
publique du serveur, signée par une
autorité de certification (CA), ainsi que le
nom du cryptosystème le plus haut dans la
liste avec lequel il est compatible (la
longueur de la clé de chiffrement - 40 bits
ou 128 bits - sera celle du cryptosystème
commun ayant la plus grande taille de clé).
l
l
121
122
l
Le client vérifie la validité du certificat (donc
l'authenticité du marchand), puis crée une
clé secrète aléatoire (plus exactement un
bloc prétenduement aléatoire), chiffre cette
clé à l'aide de la clé publique du serveur,
puis lui envoie le résultat (la clé de session
).
l
123
l
Le serveur est en mesure de déchiffrer la clé
de session avec sa clé privée. Ainsi, les
deux entités sont en possession d'une clé
commune dont ils sont seuls connaisseurs.
Le reste des transactions peut se faire à
l'aide de clé de session, garantissant
l'intégrité et la confidentialité des données
échangées.
l
124
SSL 3.0
l
SSL 3.0 vise à authentifier le serveur vis-à-
vis du client et éventuellement le client vis-
à-vis du serveur.
125
PLAN

Introduction


Système de paiement électronique


Sécurisation des télépaiements avec SSL


Sécurisation des télépaiements avec SET


Application:Kleline


Conclusion



126
Introduction

Deux générations de monnaies électroniques:

Ø
1
ère
génération s’insère dans les circuits fermés et sécurisés

par les banques:

-paiement par carte bancaire

-retrait de billet dans les guichets automatiques

Ø
2
ème
génération suscite des inquiétudes directement liées au

fait que ces nouveaux instruments de paiement

s’insèrent dans les réseaux ouverts et non plus fermés, d’où la

nécessité de les sécuriser.
127
Système de paiement électronique
128
Risques propres aux dispositifs de paiement
Ø Risques opérationnels, risques de perte liés à l’inadéquation ou

à la défaillance des procedures,des hommes sur des systèmes ou

liés à des évènements extérieurs.

Ø Risques juridiques.

Ø Trois problèmes principaux se posent du point de vue sécurité de
paiement:

-Identifier l’expéditeur du message: authentification

-Vérifier que le message expédié n’a pas été altéré durant la

transmission et empêché que le message ne soit redirigé vers un

destinataire autre que l’expéditeur: confidentialité et intégrité.
Ø
129
Sécurisation avec SSL
§
SSL: Secure Socket Layer (couche interface de connexion sécurisée),
protocole généraliste de sécurisation des échanges entre un client et
un serveur sur les réseaux ouverts.
§
Applique la sécurité entre les couches d’applications et de transport.
§
SSL opère au-dessus du protocole TCP et non pas au-dessus du
protocole UDP ,car ce dernier n’offre pas un moyen de transport
fiable.



130
Sécurisation avec SSL

Définition des flux sur un routeur

L’IANA a accordé à certaines applications des ports IP

particuliers pour Leur permettre de communiquer avec SSL.

• https(HTTP avec SSL, port 443)
• ssmtp(SMTP avec SSL, port 465)
• snntp(NNTP avec SSL, port 563)
• ssl-ldap(LDAP avec SSL, port 636)
• spop3(POP3 avec SSL, port 995)
131
Sécurisation avec SSL
vSSL fournit trois services de sécurisation:
l’authentification, l’intégrité et la confidentialité.

v
SSL se décompose:

-d’un générateur de clés,

-de fonctions de hachage,

-d’algorithmes de chiffrement,

-de protocoles de négociation et de gestion de session,

-de certificats.



132
Sécurisation avec SSL

Les sous-protocoles de SSL:

Ø
Handshake
Ø
Record
Ø
ChangeCipherSpec
Ø
Alert
ü
133
Empilement des sous-protocoles de SSL
Alert CCS
Handshake
Record
Application
Application
TCP
TCP
SSL
134
Variables d’état d’une session SSL
l
L’identification de session(session ID)

-séquence arbitraire de 32octets
l
Le certificat du pair(Peer certificate)
l
La méthode de compression
l
La suite de chiffrement(cipher spec),elle définit les algorithmes
de cryptage et de hachage
l
La MasterSecret,secret de 48 octet
l
Le drapeau(is resumable)
l
135
Variables d’état d’une connexion SSL
l
client_random & server_random:
l
Nombre aléatoires de 32 octets
l
client_MAC_write_secret & slient_MAC_write_secret:
l
clés secrètes utilisées pour le calcul du MAC
l
client_write_key & server_write_key:
l
Clé de chiffrement symétrique des données
l
2 vecteurs d’initialisation
l
2 numéros de séquence codés sur 8 octets:
l
Incrémentés à chaque émission de message  Non rejeu
l

136
Calculs de paramètres
Client_random
(par connexion)
PreMasterSecret
(par session)
Server_random
(par connexion)
Fonction
Mathématique
MasterSecret
Client_random
(par connexion)
Client write secret
Server write secret
(par connexion)
Vecteur d’initialisation
Du client et du server
(par connexion)
Server_random
(par connexion)
Client MAC write
secret
Server MAC write
secret
(par connexion)
Fonction
Mathématique
MasterSecret
(par session)
137
Le protocole Handshake
Serveur
Client Hello (version, client_random, session_ID, suite de chiffrement, methodes de compression
Server Hello (version, server_random, session_ID, suite de chiffrement, methodes de compression
Server Certificate
ServerKeyExchange (certificat de signature et ou si pas de certificat)
Certificate request
ServerHelloDone
ClientKeyExchange(K
+
S
(PreMasterSecret))
CertificateVerify(vérification explicite du certificat du client)
Finished
(authentification serveur)
client
138
Le protocole ChangeCipherSpec(CCS)
l
l
l
Permet de signaler des transitions dans les stratégies de
chiffrement.

l
Envois réciproque d’un message simple pour indiquer que les
messages suivants utilisent les nouveaux paramètres
négociés.
139
Le protocole Record
Application
TCP Transport Layer
Fragmentation
Compression
MAC et
Chiffrement
Déchiffrement et
Vérification
MAC
Décompression
Réassemblement
Le protocole Record a pour rôle
d’encapsuler les données du Handshake et
de les transmettre sans aucune modification
vers la couche du protocole TCP.
Ces données subissent les taches suivantes:
-fragmentation en blocs de octets au
maximum
-compression
-génération d’un condensât pour assurer le
service d’intégrité
-le chiffrement pour assurer le service de
confidentialité
Les tâches inverses sont effectuées du côté
récepteur.
14
2
Protocole Record
140
Le protocle Alert
l
l
Génère des messages d’alerte suite aux erreurs de parcours.

l
Signale les changements d’état tels que la fermeture d’une
connexion.
141
Sécurisation avec SET
l
SET(Secure Electronic Transaction), sécurisation des
transactions par carte bancaire effectuée sur les réseaux
ouverts
l
SET, parrainé par Visa et MasterCard en collaboration avec IBM,
GTE, Microsoft.
l
SET opère au niveau de l’application indépendamment de la
couche transport
l
SET porte uniquement sur l’acte de paiement
l
142
Sécurisation avec SET(1)

Les principaux acteurs de SET sont au nombre de six

-Le détenteur de la carte bancaire (le porteur); il possède une

carte, conforme aux spécifications SET, émise par un institut

d’émission, typiquement affilié à visa ou MasterCard

-Le serveur du marchand;

-La passerelle de paiement;

-L‘auorité certifiante;

-L’institut émetteur de la carte bancaire du porteur;

-L’institut acquéreur, qui est souvent la banque du marchand.
143
Détenteur de la carte
Commerçant
Autorité de certification
Passerelle
de paiement
Institut d’émission
Institut d’acquisition
Les acteurs d’une transaction SET
144
Lancement du logiciel dédié au commerce électronique
Couche de transport TCP
Codage des différentes
Structures de
données
Création des
messages
Modules
cryptographiques
et fonctions de sécurité
Génération des
condensat,
Signatures et
Chiffrement des
messages
Protocole
SET
Recherche de produit ou de service
sur internet
Achat
Passage des paramètres conformément au protocole SET
Produit acheté,num de carte bancaire,etc
145
Sécurisation avec SET(2)


Les transactions de SET fournissent les services suivants:

§ Inscription des porteurs et des marchands auprès de l’autorité certifiante;
§ Octroi de certificats aux porteurs et aux marchands;
§ Authentification, confidentialité, intégrité des transactions d’achat;
§ Autorisation de paiement;
§ Capture(collecte) du paiement pour initier la demande de compensation
financière au profit du marchand.
146
SET utilise les techniques de cryptographie à clé publique afin de
garantir à la fois;
l
La confidentialité des échanges pour qu’ils ne puissent pas être lu en
ligne par une entité exterieure à la transaction;
l
L’intgrité des données échangées entre le client,le marchand et la
banque acquéreur;
l
L’identification des intervenants;
l
L’authentification des intervenants.
147
Algorithmes cryptographiques utilisés
Algorithme Services
DES Confidentialité
RSA Authentification, identification et intégrité
SHA-1 Génération de condensât
HMAC-SHA-1 Génération de paragraphes avec hachage
148
Traitement du message dans SET
Condensât
Message en clair
Message en clair
Sceau
Clé privée
De
l’émetteur
Message chiffré
Clé secrète chiffré
Alé
a
Hachage
Chiffrement à clé
publique
Chiffrement symétrique
Clé publique du destinataire
Message
transmis
Clé de chiffrement symétrique
149
Procédure d’achat avec SET

SET se charge;

- dans un premier temps de sécuriser l’acheminement de
l’autorisation du paiement à travers le réseau ouvert;

- protéger la confirmation de la transaction;

- afin s’occupe du remboursement du
marchand(compensation).
-

L’échange de base pour un paiement comprend les
messages suivants:

PReq, AuthReq, AuthRes, PRes,CapReqt et CapRes.
150
Messages échangés au cours d’une transaction d’achat de SET
1-PReq
4-PRes
3-AuthRes
2-AuthReq
5- CapReq
6- CapRes
Détenteur de carte
Passerelle de paiement
Commerçant
151
Messages
Sens de
transmission
Signification
PReq Porteur marchand demande d’achat
PRes Marchand porteur

Réponse à la demande
d’achat
AuthReq Marchand passerelle

demande d’autorisation
AuthRes Passerelle marchand Réponse à la demande
d’autorisation
CapReq Marchand passerelle

demande de compensation
CapRes Passerelle marchand Réponse à la demande de
compensation






152
Condensât des
Renseignements
D’achat
Signature
duale
Condensât des
Instructions de
paiement
Signature duale
Condensât de
l’ordre
D’achat
Signature duale
Condensât des
Instructions de
paiement
Signature duale
Chiffrement
symétrique
Clé aléatoire de
chiffrement symétrique
DES
PAN
PAN
Chiffrement avec la clé pub de
chiffrement de la passerelle
Composition du message PReq
153
Condensât OI
Nouveau condensât
Juxtaposition des
condensâts
Signature duale Condensât PI
hachage
hachage
hachage
Chiffrement avec la clé
privée de signature du
porteur
La signature duale du message PReq
154
condensât
sceau
hachage
Clé privé de signature
du marchand
condensât
sceau
hachage
Clé p de sig mar
Signature
duale
Condensât des
Instructions
de paiement
PAN
Clé aléatoire de chiff sym
Clé pub de chif
de la passerelle
Message AuthReq transmis par le marchand
à l’attention de la passerelle de paiement
155

KLeline:

-filiale de la compagnie bancaire et de LVMH(Louis Vuitton-Moët-Hennesy)

-plate-forme englobant une galerie virtuelle et un système de paiement nommé

Globe ID

Le serveur KLeline est simultanément l’intermédiaire entre le commerçant et le client,

la passerelle entre l’internet et les réseaux bancaires, le notaire, le tiers de confiance, en

plus des hôtes d’une galerie commerciale virtuelle. Authentifie les parties en présence

-Logiciel du client:Klebox ou PACK(Personal Authentication and Confirmation Kit).

-Kit du marchand: SACK(Server Authentication and Certification Kit), installé sur le

serveur du marchand, sécurise les communications avec le serveur Kleline. Gère les

fonctions de l’arrière boutique(la personnalisation de l’offre en fonction du profil du

client,l’émission des tickets…
Application: KLeline
156
Application: Kleline(1)
v Le client s’inscrit au service en communiquant:

-ses coordonnées bancaires, le mode de chargement de son porte-monaie,son

adresse électronique et facultativement des renseignements sur son profil de

consommation.
v Le client reçoit en retour:

-un code confidentiel(PIN)

-un indentifiant client ou customer Identifier(CID)

-le logiciel Klebox

Cette transaction est sécurisée au moyen d’une paire de clés RSA de 512bits
v Après inscription, le marchand reçoit un kit, permettant de personnaliser le

tiroir-caisse élctronique,une paire de clés de chiffrement asymétrique et un

Certificat.Sa bibliothèque contient les fonctions du serveur marchand

-concevoir et émettre des tickets de caisse

-recevoir et enregistrer les bons de caisse

-actualiser et gerer les taux de change des devises.
157
Application: Kleline(1)

Le protocole CPTP(Customer Server Transaction Protocole)decrit le deroulement d’un

achat et son règlement.
158
Client
KLEBOX
Commerçant
Serveur de paiement
Kleline
Banque de
Kleline
Banque du
commerçant
Banque du
client
compensation
10-bon de caisse (PPT)
7-comfir de cmde(CAC)
8-cmde
confirmée(CAR)
6-ticket de caisse(PRT)
11-bon de caisse(PPT)
6-ticket de caisse(PRT)
12-livraison
5-commande
4- offre de vente
2-sélection d’articles
1-consultation du catalogue
Echanges de messages dans un achat Kleline
159
conclusion
Ø Le protocole SSL offre les services d’authentification, de confidentialité et

d’intégrité des données dans les applications de point à point.

-Son grand avantage est sa transparence par rapport aux applications TCP;

-L’utilisation des clés de 40 bits rend SSL particulièrement vulnérable aux

attaques ;

-une faiblesse, provient du fait que les paramètres de chiffrement ne sont pas

obligatoirement modifiés pendant une session;

-le risque de casser les clés augmente avec la longueur de la session.

Ø Le protocole SET veut devenir le standard pour la sécurisation des paiements
par carte bancaire sur l’internet.

-Néamoins,les moyens de sécurisation sont assez compliqués, ce qui se traduit

par une surcharge en calcul et des temps de réponse assez longs

-les secrets du porteur de la carte se trouvent stockés sur son disque dur, ce qui

augmente les risques.
160
VPN
161

Les Réseaux Privés Virtuels
(VPN)
l
l
VPN = une extension de l ’Intranet de
l ’entreprise à un réseau public (ex.
Internet).
l
Utile en B2B et parfois en B2C
l
1 politique de sécurité/partenaire
commercial
l
Ipsec: VPN entre Firewalls
l
l
l
162
Intégration des VPNs

Pas de dialogue direct entre l'extérieur et l'intérieur

Les VPNs IPsec ne traversent pas la plate-forme de sécurité Internet
Sauf exceptions où la sécurité de bout-en-bout est justifiée

Intégration dans l'architecture de sécurité Internet
Dans une DMZ, et plutôt coté extérieur

Attention aux limites
•Pas de filtrage IP sur la traffic reçu par le tunnel IPsec
•Attention aux difficultés indépendantes de la sécurité
•Plan d'adressage IP, routage, traduction d'adresses, triples DNS,
configuration des MX, etc

163
Choix techniques
l
L2tp : création d’un tunnel IPSec :
sécurisation des données
(encryption,intégrité) au niveau réseau
l
Radius : authentification des utilisateurs
164
165
L2TP
l
Le protocole L2TP (Layer Two Tunneling
Protocol) est un protocole de tunneling
basé sur des RFCs
l
Une trame PPP (un datagramme IP ou IPX,
ou une trame NetBEUI) est encapsulée
dans un en-tête L2TP et un en-tête UDP
l
Authentification basée sur PPP
l
Supporte l’utilisation d’IPSec pour le
chiffrement des données
166
167
168
Chapitre5:
Les Protocoles
d’authentifications
169
Le protocole Radius

Remote

Access


Dial

In

User

Service
l
Protocole d'authentification
l
d'utilisateurs distants
l
Initialement plutôt utilisé par les ISP
l
Pour authentifier leurs utilisateurs
l
Développé par Livingston
Enterprises
l
Le protocole de base de RADIUS est
décrit dans le RFC 2865.
l
Utilise UDP sur le port 1812
(anciennement 1645)
170
Radius est un serveur de type
AAA
l
Authentification
l
Qui me parle ?
l
Authorization
l
Quelles autorisations je lui accorde ?
l
Accounting
l
Que fait-il ?
l
171
Présentation générale de
RADIUS
l
Son rôle et de stocker les données servant à
l’authentification de chaque utilisateur (mots de
passe, clés, certificats…). De plus, ce serveur
enregistre un compte pour chaque utilisateur. Ce
compte sauvegarde des paramètres sur l’état de
la session en cours, comme la durée de la
connexion par exemple. Une base de données
est maintenue pour stocker toutes les
informations relatives aux utilisateurs. On parle
alors de serveur AAA, pour Authentification,
Autorisation et Acompte.
172
l
RADIUS, qui signifie Remote Authentication Dial In
User Service, est un protocole. D’authentification
de type client/serveur. Il a été créé par Lucent
Remote Access et est défini par les RFC 2865 et
2866 [6]. Il a d’abord été conçu pour les
connexions PPP. Il permet l’échange de
messages entre le serveur AAA et un NAS
(Network Access Service), pour réaliser le
processus d’authentification. Dans notre cas, c’est
le serveur Nocat qui joue le rôle du NAS (qui est
nommé client dans ce texte). Le serveur
d’authentification s’appellera serveur RADIUS.
173
l
L’implémentation de ce serveur a été
développée pour une plateforme UNIX,
mais une version gratuite existe pour Linux,
elle se nomme freeRADIUS.
174
l
RADIUS apporte certains avantages. Au lieu
d’être dispersées un peu partout sur
plusieurs machines de votre réseau, toutes
les informations relatives aux utilisateurs
sont stockées sur une seule machine,
apportant ainsi de la clarté et minimisant
déjà certains risques. Très flexible, ce
protocole peut être utilisé avec plusieurs
types de serveur de communication qui le
supporte.
175
l
Donc c’est RADIUS qui s’adapte à votre réseau, et
non l’inverse. De plus, une base de données est
relativement simple à tenir, il est facile d’y
accéder et de mettre à jour les données. Une
petite interface graphique rend la chose encore
plus agréable. Finalement, un serveur RADIUS
peut également jouer le rôle de proxy dans le cas
où plusieurs serveurs sont disposés. Il
transmettra alors les requêtes vers un autre
serveur et redirigera également les réponses
destinées au client.
176
2 Les requêtes
l
l
Notons tout d’abord que le protocole RADIUS est
employé entre un NAS et un serveur RADIUS et
pas directement entre l’utilisateur et le serveur.
Ce choix devient logique lorsque l’on prend en
considération le rôle de l’autorisation. En effet,
c’est au niveau du point d’accès (Nocat) que l’on
peut bloquer l’accès à certains services et
applications. Dans le cas d’un réseau câblé, c’est
un switch par exemple qui jouerait le rôle du NAS.
Lorsqu’un client est configuré pour utiliser
RADIUS, chaque utilisateur qui désire se
connecter à celui-ci doit lui transmettre ses
données d’authentification.
177
l
Ensuite, le client envoie ces données vers un
serveur RADIUS. Il s’agit du paquet Access
Request, qui sert à réaliser une demande
d’authentification. On trouve dans ce paquet
certains attributs comme le nom d’utilisateur, son
mot de passe ou encore l’ID du client par lequel il
veut s’authentifier. A la réception de ce message,
le serveur vérifie tout d’abord le secret partagé
avec le client. Il s’agit d’une chaîne de caractère
connue uniquement du client et du serveur et qui
a été échangée de manière sur (indépendamment
du réseau, comme une disquette par exemple).
178
l
Si ce critère n’est pas satisfait, la requête ne
sera pas traitée. Si le client est valide, le
serveur peut contrôler l’existence de
l’utilisateur dans sa base de données et
vérifier son mot de passe. D’autres critères
peuvent être ajoutés pour satisfaire
l’authentification, comme l’IP du client ou
encore le port qui est alloué à l’utilisateur.
179
l
Si un des critères n’est pas valide, le serveur
renvoi au client un Access Reject pour
indiquer le refus de l’utilisateur sur le
réseau. Au contraire, si tous les critères
sont confirmés, la réponse est retournée
sous la forme d’un challenge auquel
l’utilisateur doit participer. Il s’agit du
paquet Access Challenge.
180
l
Dans un mode d’authentification
challenge/response, l’utilisateur reçoit un
nombre pseudoaléatoire qu’il doit encrypter
grâce à une connaissance commune entre
le serveur d’authentification et lui-même.
Cette connaissance peut-être de plusieurs
formes, comme un système de clé publique
gérée par certificats. Le NAS transmettra
alors ce challenge à l’utilisateur. Ce dernier
pourra calculer la réponse et la renvoyer au
client qui fera suivre la réponse au serveur
RADIUS par l’intermédiaire du paquet
Access Response.
181
l
Le serveur contrôle alors la validité de la
réponse et acceptera l’utilisateur dans
le cas où la réponse est correcte.
l
182
l
C’est le paquet Access Accept qui permet
cette confirmation au client. Sinon, C’est
encore un paquet Access Reject qui
indiquera au client que l’utilisateur ne peut
pas avoir accès au réseau. Il est possible
d’avoir plusieurs challenges échangés
entre l’utilisateur et le serveur lorsque la
procédure d’authentification est un peu plus
complexe que le simple échange de mots
de passe
183
l
La figure ci-dessous décrit le flux de
messages échangés pendant une phase
d’authentification réussie entre un client et
un serveur RADIUS.
184
185
Base de données mySQL
l
Il faut admettre, qu’une base de données est
beaucoup plus pratique et plus simple à
gérer que les fichiers textes. Surtout quand
le nombre d’utilisateurs devient
conséquent. Donc, la gestion d’une base
de données est complètement intégrée et
prévue par RADIUS
186
l
Il suffit de créer un serveur de BD et la base elle
même, dont le schéma est donné. Il faut
finalement activer dans les fichiers de
configuration l’utilisation et l’emplacement de la
BD. Plusieurs types de base sont admis, Oracle
ou MySQL par exemple. C’est MySQL qui a été
choisi. Déjà implémenté dans Linux (openSQL), il
ne reste plus qu’à installer le serveur, le
configurer, créer la base radius en exécutant le
script sql fournis dans le paquetage RADIUS et le
tour est joué.
187
l
Il faut tout de même un peu plus de temps
pour le réaliser que pour le dire…
l
Une fois que ça fonctionne, c’est par des
requêtes sql qu’il va être possible de gérer
les différentes tables et donc les
utilisateurs.
l
Notons qu’une petite interface graphique
sous la forme d’un site WEB existe, ce qui
permet de faciliter la gestion des
utilisateurs, mais pas de la configuration.
188
Le protocole Radius: les types
de paquets
l
Le protocole utilise 4 types de paquets
suffisants pour assurer toutes les
l
transactions: (hors accounting)
l
Access-Request
l
Access-Accept
l
Access-Reject
l
Access-Challenge
l
189
l
Access Request
l
Premier paquet envoyé par le client (NAS)
l
Contient l'identité de l'utilisateur qui se
connecte ( username/password ou CN du
certificat ou MAC adresse)
190
l
Access-Accept
l
Renvoyé par le serveur Radius pour accepter
la requête du client après interrogation de
sa base d'authentification.
l
Ce paquet peut contenir une liste d'attributs
correspondant aux
l
services qui sont autorisés (par exemple le
vlan).
l
l
191
l
Access-reject
l
Emis par le serveur radius pour spécifier au
client que sa requête est rejetée.
l
En principe ce paquet peut être émis à tout
moment pour mettre fin à une connexion,
mais certains équipement ne supporte pas.

192
l
Access-challenge
l
Emis par le serveur Radius pour demander
soit de ré-emettre un access-request, soit
pour demander des informations
complémentaires.
l
193
Code(1) Identifier(1) Longueur(2)
Authentificateur(1
6)
Attrributs et valeurs
(variables)
194
Le champs Code
l
1 - access-request
l
2 - access-accept
l
3 - Access-reject
l
4 - Accounting-request
l
5 - Accounting-response
l
11- Access-challenge
195
Identifier
l
l
utilisé pour associer les requêtes et les
réponses.
196
Authentificateur
l
Utilisé pour que l'équipement NAS
l
puisse authentifier les réponses du serveur
l
-> Request authenticator
l
-> Response authenticator
197
Attributs et valeurs
l
Ensemble d'attributs et leur valeur qui indique
quels services sont demandés ou
autorisés.
198
Le protocole Radius: les types de
paquets
Authentificateur
l
Lorsque le client NAS envoi un paquet access-
request il inclut un authentificateur appelé
request-authenticator qui est une séquence
aléatoire.
l
Le serveur répond par un paquet access-accept ou
accept-reject ou accept-challenge avec un
response-authenticator composé avec les
informations contenues dans le paquet
l
access-request, le request authenticator et un
secret partagé avec le NAS et le tout crypté MD5.
l
Le NAS est alors en mesure de vérifier que le
serveur qui répond est bien celui qu'il a contacté.
199
Le protocole Radius: les
attributs
l
Les transactions RADIUS ont pour but de véhiculer
des attributs et leur valeur entre le client NAS et le
serveur.
l
Ces attributs et leur valeur sont appelés paires
attribut-valeur (AVP= attribut-value pair)
l
Ces attributs permettent au client de communiquer
des informations au serveur (password, MAC
adresse…) et au serveur de communiquer les
paramètres des autorisations qu'il délivre (vlan…)
ou bien demander des informations
complémentaires.
200
l
Un attribut est caractérisé par son type et sa valeur
(éventuellement nulle)
l
Integer
l
Enumerated
l
IP address
l
Chaîne de caractères
l
Date
l
Binaire
l
Vendor-specific
201
Le protocole Radius: les
attributs standards
l
Il y a beaucoup d'attributs standards mais
peu sont utilisables dans le cas d'une
utilisation avec 802.1x.
l
Par exemple l'attribut CALLBACK-NUMBER
contient le numéro de téléphone sur lequel
il faut rappeler le client. Ce qui est inutile
dans notre cas… Seront décrits ici
uniquement les attributs intéressants pour
l'authentification 802.1X et Radius Mac
202
l
Called-Station-Id
l
Contient l'adresse MAC de l'équipement NAS
l
Calling-Station-Id
l
Contient l'adresse MAC de la machine de
l'utilisateur.
l
NAS-IP-Address
l
Adresse IP de l'équipement NAS
l
NAS-Port
l
Port sur lequel est connecté le supplicant
l
User-Name
l
User-Password
203
le dictionnaire
l
Chaque attribut possède un numéro
d'identification.
l
Seul ce numéro est transmis dans les
paquets .
l
La correspondance entre le nom de l'attribut,
son numéro et son type est réalisé dans un
dictionnaire.
204
Le protocole Radius: les
attributs vendor
l
Les fabricant de matériel réseau (NAS) ont
parfois intégré à leurs équipements
l
des attributs spécifiques en plus des attributs
standards définis dans le RFC.
l
Ces attributs sont encapsulés dans l'attribut
standard vendor-specific qui a pour
l
numero 26. Ils sont appelés VSA = Vendor
Specific Attribut
205
l
Vendor ID:
l
N° d'immatriculation du fabricant
l
(NMPECS= Network Management Private Enterprise Codes
(RFC1700)
l
Attribut number
l
Comme pour les attributs standards, les vendor-attributs
possèdent un numéro
l
d'identification. Ce numéro est répertorié dans un dictionnaire
spécifique au
l
fabricant.
l
Longueur
l
Valeur
206
Les extensions du protocole
Radius: support des vlans
l
Le support des attributs de tunnel est une extension
du protocole de base
l
de RADIUS dont le but initial est de créer des
tunnels avec des clients distants.
l
Ces extensions sont décrites dans le RFC 2868
l
·Le support des VLANs est réalisé par le biais des
attributs de tunnel
Ø
Les attributs concernés sont :
l
Tunnel-type
l
Tunnel-Medium-Type
l
Tunnel-Private-group-Id
207
Les extensions du protocole
Radius: support des vlans
l
Tunnel-Type
l
Il y a 13 types de tunnels. Bien que le RFC
ne parle que des 12 premiers.
l
Le 13ème étant les VLAN 802.1q.
208
1 Point-to-Point Tunneling Protocol (PPTP)
2 Layer 2 Forwarding (L2F)
3 Layer 2 Tunneling Protocol (L2TP)
4 Ascend Tunnel Management Protocol (ATMP)
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-Mode (AH)
7 IP-in-IP encapsulation (IP-IP)
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP)
9 IP encapsulating Security Payload in the tunnel-mode (ESP)
10 Generic Route Encapsulation (GRE)
11 Bay dial in virtual Services (DVS)
12 IP-in-IP Tunneling
13 Vlan 802.1Q
209
Les extensions du protocole
Radius: support des vlans
l
Tunnel-Medium-Type
l
Cet attribut indique quel type de transport est utilisé. Il y a 14 types
possibles.

1 . IPv4

2 . UPv6

3 . NSAP

4 . HDLC5 BBN 1822

6 . 802 ETHERNET

7 . E.163 (POTS)

8 . E.164 (SMDS, Frame relay, ATM)

9 . F.69 (Telex)

10. X.121

11. IPX

12. Appletalk

13. Decnet IV

14. Banyan Vines
210
l
Tunnel-Private-Group-Id
l
Indique un group-id pour un tunnel
spécifique. Dans le cas des VLANs il s'agit
du numéro de Vlan.
l
Autres attributs tunnel
l
Il existe d'autres attributs de tunnel, non
utilisés pour nos besoins
211
Configuration de freeradius avec
base de données MySql :
Migration vers une
authentification MySQL
l
L’objectif de l’utilisation d’une base de
donnée est de simplifier l’administration
des utilisateurs et des NAS clients.
l
Remarque : Il est important de compiler
FreeRadius avec MySQL déjà installer. En
effet dés la compilation FreeRadius fait
appel à un certain nombre d ‘élément de
MySQL.
212
l
Ensuite, la création de la base « radius »
l
Il vous tout d’abord créer la base « radius »,
pour cela il vous suffit de vous connecter
au serveur MySQL et de créer la base à
l’aide de la commande « create » comme
suit :
l
213
l
#mysql –u root –p
l
mysql> create database radius ;
l
mysql> exit
214
l
FreeRadius est livré avec un petit script de
configuration de MySQL très pratique. En
effet le script « db_mysql.sql » se charge
de la création des tables nécessaires. Il
suffit donc juste de l’exécuter comme suit :
215
l
#mysql –u root radius < <rep decompression
archive
freeradius>/src/modules/rlm_sql_mysql_db
_mysql.sql
216
l
Vous obtenez dans la base radius les tables
suivantes
217
l
mysql> select * from usergroup;
l
+----+---------------+-----------+
l
| id | UserName | GroupName |
l
+----+---------------+-----------+
l
| 1 | fredf | dynamic |
l
| 2 | barney | static |
l
| 3 | dialrouter | netdial |
l
+----+---------------+-----------+
l
3 rows in set (0.00 sec)
l
mysql> select * from radcheck;
l
+----+-----------+--------------+------------|----+
l
id | UserName | Attribute | Value | Op |
l
+----+-----------+--------------+------------+----+
l
| 1 | client | Password | client | == |
l
| 2 | sebi | Password | sebi | == |
l
| 3 | john | Password | jhon | == |
l
| 4 | jerome | Password | jerome | == |
l
+----+-----------+--------------+------------+----+
218
KERBEROS
219
Utilité de KERBEROS
l
Résoud le problème relative à l’envoi du login
et mot de passe en clair sur le réseau
l
Schéma de sécurité basé l’authentification
cassable par simple écoute
l
KERBEROS réduit le risque d’interception
l
Conflit de fonctionnalité entre FW et
KERBEROS
l
l
220
Ticket Request
l
Le TGT est un ticket crypté par le mot de
passe ayant le login envoyé dans le 1
er

message.
l
TGT ne suffit pas à authentifier Alice puisqu’il
est transmis en clair et peut donc être
réutilisé par un intrus.
221
Shéma
1- Envoi de User name en clair
2-TGT(Contient TG key)
Crypté avec le mot de passe de User
3- (UserName+ Requète de service+Time)
Crypté avec le TGKey
4- TGT service(TGS) contient (Clé de session crypté avec le TG
Key)
Crypté avec le AS Key
5
-

T
G
S
+

A
u
t
h
e
n
t
i
f
i
c
a
t
e
u
r

Serveur d’application
USER
Serveur
KERBEROS
222
Faiblesse de KERBEROS
l
Il n’y a pas des systèmes cryptographique
parfait S’il y a un vol de ticket on peut
accéder au réseau
l
Attaque par dictionnaire
l
Contrainte temps de 5 min (L’attaquant à
seulement 5min pour qu’il décrypte le mot
de passe
l
l
223
l
Attaque par répétition (ou rejeu)
l
Bien que les datations ou horodotage est
supposé éviter celà les messages peuvent
être rejoués pendant la durée de vie des
tickets (typiquement 8 heures)
l
Service de datation: Les authentifiants
dépendants du fait que toute les horloges
du réseau sont plus au moins
synchronisés.
224
l
Si on peut tromper KERBEROS ou le serveur
d’application quand à l’horloge réel les
authentifiants pourront être rejoués
l
La plupart des protocoles de maintient de
temps en réseau ne sont pas sûr ce qui
peut être donc un sérieux défaut.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.