Cryptographie

1
Chapitre1:
Les algorithmes de chiffrements

2
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 3
 Chiffrement, Déchiffrement,
Décryptement
l Cryptologie = Cryptographie+Cryptanalyse

Clé de chiffrement Clé de déchiffrement

Texte Texte chiffré Texte

Chiffrement Déchiffrement
En clair cryptogramme En clair

Décryptemen
t
Texte en clair et/ou clé 4
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

5
 Les Algorithmes Symétriques
(à clé secrète)****

Même clé
secrète

Données Données Données

en clair chiffrées en clair
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 6
 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
7
 Algorithmes de Chiffrement Symétrique
Algorithmes de Concepteur(s) Taille de la clé Taille du bloc Commentaires
chiffrement

RC4 Ron Rivest (1994) Variable, 128 bits en Adapté aux codages rapides
(Continu) général 10 fois plus rapide que DES

RC2 Ron Rivest Variable Equivalent à DES

(Par bloc)

DES (Data Encryption IBM (1976) 56 bits 64 bits Relativement rapide

Standard) Destiné au chiffrement de gros volumes
(Par bloc) Clé craquée en 1998

Triple DES IBM 3 clés 64 bits Remplace DES

(Par bloc) et dérivé de DES différentes, 168 bits

IDEA X.Lai et J. Massey 128 bits 64 bits Conçu pour une efficacité maximale lors de
(International Data (1990) calculs logiciels
Encryption Algorithm) Nécessite une licence
Par bloc

BLOWFISH Bruce Schneier Variable, de 32 à 448 64 bits Rapide

Par bloc (1994) bits Gratuit

CAST-128 Carlisle Adams, et 128 bits 64 bits Alternative à IDEA et Blowfish, mais moins
Par bloc Stafford Tavares utilisé qu’eux

Rijndael Joan Daemen, et Variable 128 bits Considéré comme l’algorithme de

(NIST finaliste de l’AES Vincent Rijmen 128, 192 ou 256 bits chiffrement le plus fiable actuellement
(Advanced Encryption
Algorithm) compétition)
8
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,

9
 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

10
 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é

11
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

12
Les algorithmes de chiffrement asymétrique
Algorithmes Concepteur Taille de Taille du Commentaires
de (s) la clé bloc
chiffrement
RSA (Rivest, Rivest, Shamir, Variable, Variable Système le plus utilisé
Shamir, et Adelman 512 bits et < taille Nécessite une licence
Adelman) (1978) en des clés
(Par bloc) général

Diffie- Whitfield Système de cryptage le

Hellman Diffie, Martin moins récent et toujours
Hellman en exploitation
(1976)
El Gamal El Gamal Variante de Diffie-
(1985) Hellman, mais
nécessitant l’envoi du
double d’information
13
 Utilisations de la Cryptographie à Clé Publique
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
Clé publique de Clé privée de
Bob Bob

Données Données chiffrées

Données en
en clair clair
Alice Bob

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
Clé pivée de Clé publique
Alice de Alice

Données Données chiffrées

Données en
en clair clair 14
Alice Bob
 Cryptographie Symétrique et
Asymétrique: utilisation
l Cryptographie à clé publique
l Lente
l  ne peut pas être
utilisée pour chiffrer
les données
 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é


15
 Exemple de combinaison clé publique/clé secrète**

Clé secrète

Clé privée de
Bob
Données Données Clé secrète
en clair chiffrées
Alice Enveloppe
Clé publique de numérique
Bob Clé secrète
Clé secrète
Enveloppe Données Données
numérique en clair
chiffrées

16
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

17
 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
 18
La Signature Numérique:
Fonctionnement***

Clé privée
Alice
Signature :

Message
Empreinte Signature
Alice
Vérification :

Message Empreinte
Identiques ?
Bob
Signature Empreinte

Clé
publique
Alice
19
 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.

Message

Empreinte
20
 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 !
21
 Les Fonctions de
Hachage**
Fonctions de Concepteur Taille de Commentaires
hachage (s) l’empreinte
MD5 Ronald Rivest 128 bits Successeur de MD4
(Message (1991) Présente des problèmes de
Digest 5) collision qui ont affecté son
expansion
SHA NSA (National 160 bits SHA-1 révision publiée en
(Secure Hash Security 1994, considérée plus sur
Algorithm) Agency), et que MD5
normalisé par SH1-2 (octobre 2000)
le NIST agrandit la taille de
l’empreinte dans plusieurs
versions en 224, 256, 384, et
512 bits

22
La Signature Numérique:
Les algorithmes
Algorithme de Concepteur Algorithme de Fonction de
Signature (s) chiffrement à hachage
numérique
DSA (Digital NIST(1991) clé publique
El Gamal SHA-1
Signature
Algorithm)
DSS (Digital
Signature
Standard)

RSA Digital Rivest, RSA SHA-1 ou MD5

Signature Shamir, et
Adelman

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

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

25
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
Message
(longueur variable)

Algorithme
de
chiffrement
Clé
symétrique
secrète
en mode CBC

Dernier bloc
Code d’authentification
de message
26
Le Scellement: Fonctionnement***

Scellement:

Sceau
Alice Message
Clé secrète
Vérification :

Message Sceau
Bob Clé secrète
Sceau
Identiques ?

27
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

28
Intégrité et authentification
S’assurer que
1.Le message provient bien de la source
annoncée
  uthentification
de l’origine
2. Il n’a pas été modifié en cours de transfert
  ntégrité
 services indissociables

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

30
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 = ME mod N
l • Déchiffrement : M = CD mod N

31
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 = 213 mod 33 = 8192 mod 33 = 8
l • Déchiffrement
l – 817 mod 33 = 2 = M

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

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

36
37
l Portemonnaie électronique (pas de création
de fausse monnaie, pas de création de
faux porte-monnaie)

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

40
41
l En pratique : E et D sont paramétrées par des clés
Ke et Kd : EKe (M) = C et DKd (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) (Ke = Kd =
K)
l Systèmes à clé publique (ou asymétriques) (Ke ≠ Kd
)

42
Chapitre2:
Les algorithmes d’attaques

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

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

45
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 2taille(clefs ))
l
46
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 ):

47
Algorithmes d'attaques
l Attaque brutale
l Énumérer toutes les valeurs possibles de
clefs
l 64 bits ) 264 clefs = 1.844 * 1019
combinaisons
l Un milliard de combinaisons/s ) 1 an sur
584 machines

48
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

49
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

50
Attaque par analyse différentielle

l Utiliser
les faibles différences entre plusieurs
messages (ex : logs)
l pour deviner la clef

51
Deep Crack, circuit dedie a l'attaque par
force brute de
DES.

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

53
Enigma

54
Chiffrement symétrique : outils
de base utilises

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

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

57
58
Exercice:
RSA

59
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 = Me (mod n)
l Pour déchiffrer C; on calcule d l'inverse de e mod ϕ (n); ensuite
on
l calcule Cd mod n

60
Ø On a alors,
l  Cd(mod n) (Me )d (mod n) ≡ Med (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 Med (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 Cd ≡ M (mod n)

61
Ø 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 Cd ≡ 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

62
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 = Me (mod n)
 et l'envoie a Bob

calcule Cd (mod n)
 et en déduit M
l

63
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 = Me mod n = 6617 mod 2773 = 872
Ø Déchiffrement de C :
l Cd mod n = 872157 mod 2773 = 66

64
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

65
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 = 402517 mod 899 = 123
l
66
Protocole d'échange de clefs de Diffie-
Hellman

67
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 = ga et l'envoie à Bob.
Ø Bob choisit un entier 1 ≤ b ≤ n - 1 au hasard.
Ø Bob calcule B = gb et l'envoie à Alice.
Ø Alice est en mesure de calculer Ba et Bob de
calculer Ab.
Ø La clef commune est donc
l K = gab = Ab = Ba
l

68
Schéma
 Alice Bob
l génère a génère b
l A = gamod p B = gb mod p
l A
l B
l (dispose de [a,A,B,p]) (dispose de[b,A,B,
p])
l Clé secrète: K = Bamod p Clé secrète : K = Ab
mod p

69
 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 ga mod p = 36 mod 23 = 16
4. Bob choisit à son tour un nombre secret b = 15

5. Bob envoie à Alice la valeur gb mod p = 315 mod 23 = 12

6. Alice peut maintenant calculer la clé secrète :

l (gb mod p)a mod p = 126 mod 23 = 9

7. Bob fait de même et obtient la même clé qu'Alice :

l (ga mod p)b mod p = 1615 mod 23 = 9

70
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

71
Protocole d'échange de cle de
Die-Hellman (corrigé)
l ga = 4511 mod 233 = 147; gb = 4520 mod 233
= 195;
Ø (gb)a mod p = 19511 mod 233 = 169 et (ga)b
mod p = 14720 mod 233 = 169:
Ø Alice et Bob disposent d'une clé privée
commune : k = 169:
l

72
Chapitre 3:
PKI
(Public Key Infrastructure)

73
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
74
 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 e *****
 mission et l’enregistrement des
clés publiques leur stoc age et
distribution leur révocation et
vérification de statut et enfin
leur sauvegarde et récupération
répondre aux besoins de confidentialité, d’authentification, du

contrôle d'accès, de non répudiation et d’intégrité.


75
 Constituants Elémentaires
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

76
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

77
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

78
 PKI (suite)
Accès à l’annuaire

Utilisateur final A Utilisateur final B

Application Sur le fil Relais de

d’abonnement l’application
de partie
API

Services de
chiffrement
Vérification
Application de certification de statut
Demande de révocation en ligne
Interface d’édition de

Accès à l’annuaire
Autorité
d’enregistrement
certificat

Service
Service
Interface AC/AR de
d’annuaire
validation
Autorité de
certification

Alimentation de l’autorité de validation 79

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.

80
 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 )
- 81
 Version
Serial number
Serial algorithm ID
Issuer name Clé privée de
l’AC
Validity period Génération de la
signature
Subject name
Subject public key info
Issuer unique ID
V2
Subject unique ID
Extensions (Type, Critical/ Non-critical, Field value) V3

Signature:
Algorithm ID and signature value

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 82
Signature : Signature numérique de l’AC sur l’ensemble des champs précédents
 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)
Garantie de la
véracité des
informations
contenues dans le
certificat émis
Requête de Émission de
certificat certificat Alice
CA
Alice Récupération du
Clé certificat via
publique et Certificat annuaire par
preuve auto-signé exemple
d’identité Récupération du
AC certificat d’une façon
sûre
Bob
Vérification de la 83
signature de l’AC
PKI: Solutions
Commerciales***
l Entrust
l Baltimore
l RSA
l SSH
l Valicert
l Cryptomatic
l etc.

84
PKI: Solutions Open Source

l OpenSSL
l OpenCA
l IdealX
l TinyCA
l NewPKI
l etc.
l

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

86
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

87


 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

88
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

89
 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

90
Génération d’un certificat
d’utilisateur final (suite)
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

91
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

92
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

93
 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

94
 Chapitre4:Les
Protocoles de Sécurité
IPsec,IPv4,IPv6

95
Les Protocoles de Sécurité

SET PGP

S/MIME
S-HTTP
Couche Application

SMTP
HTTP
FTP
SSL (TLS) Couche Session

TCP Couche Transport

IP
IPsec (AH, ESP) Couche Réseau

PPTP L2TP 96
PPP
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

97
Adresses IPv4 et IPv6

98
 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
 99
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
– ...

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

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

102
 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é


103
  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) 104
l
IPsec: les modes

105
Champs protégés avec AH

106
IPsec AH Extension Header,
Transport**

107
IPsec AH Extension Header,
Tunnel

108
Protection (IPv4) avec ESP

109
IPsec ESP Extension Header,
Transport***

110
IPsec ESP Extension Header,
Tunnel

111
IPsec AH-ESP Extension Headers, Tunnel+Transport

112
IPSEC : AH
authentification des datagrammes

T
R
A
N
S
P
O
R
T

113
TU


N
N
E
L

114
IPSEC : ESP
confidentialité/authenticité des
données

T
R
A
N
S
P
O
R
T

115
TU
N
N
E
L

116
SSL

117
sous Internet Explorer sous Mozilla

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

119
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
120
121
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

122
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

123
SSL 3.0

l SSL 3.0 vise à authentifier le serveur vis-à-

vis du client et éventuellement le client vis-
à-vis du serveur.

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

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

126
Système de paiement électronique

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

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

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

130
Sécurisation avec SSL
v SSL 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.


131

Sécurisation avec SSL
 Les sous-protocoles de SSL:


Ø Handshake
Ø Record
Ø ChangeCipherSpec
Ø Alert
ü

132
Empilement des sous-protocoles de SSL

Application

SSL
Handshake

Alert CCS

Record

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

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

135
 Calculs de paramètres

Client_random PreMasterSecret Server_random

(par connexion) (par session) (par connexion)

Fonction
Mathématique

MasterSecret

Client_random MasterSecret Server_random

(par connexion) (par session) (par connexion)

Fonction
Client MAC write Mathématique
secret
Client write secret
Server MAC write Vecteur d’initialisation Server write secret
secret Du client et du server (par connexion)
(par connexion) (par connexion)
136
 Le protocole Handshake
client 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 (authentification serveur)

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

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

138
 Le protocole Record

Application

Le protocole Record a pour rôle

d’encapsuler les données du Handshake et
Fragmentation Réassemblement
de les transmettre sans aucune modification
vers la couche du protocole TCP.
Ces données subissent les taches suivantes:
Décompression
Compression
-fragmentation en blocs de octets au
214
Protocole Record maximum
-compression
-génération d’un condensât pour assurer le
MAC et
Déchiffrement et service d’intégrité
Vérification
Chiffrement
MAC
-le chiffrement pour assurer le service de
confidentialité
Les tâches inverses sont effectuées du côté
récepteur.

TCP Transport Layer

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

140
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

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

142
 Les acteurs d’une transaction SET

Détenteur de la carte Commerçant

Passerelle
de paiement

Autorité de certification

Institut d’émission Institut d’acquisition

143
 Lancement du logiciel dédié au commerce électronique
Recherche de produit ou de service Achat
sur internet
Passage des paramètres conformément au protocole SET
Produit acheté,num de carte bancaire,etc

Modules
cryptographiques
Codage des différentes et fonctions de sécurité
Structures de Génération des
données condensat,
Signatures et
Chiffrement des
messages

Protocole
SET

Création des
messages

Couche de transport TCP

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

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

146
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

147
 Traitement du message dans SET

Message en clair

Hachage

Condensât

Clé privée Chiffrement à clé

De publique
l’émetteur

Chiffrement symétrique
Sceau Message en clair Message chiffré

Message
Clé de chiffrement symétrique transmis

Alé
a Clé secrète chiffré

148

Clé publique du destinataire

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.

149
 Messages échangés au cours d’une transaction d’achat de SET

Commerçant

1-PReq
3-AuthRes

6- CapRes
2-AuthReq
4-PRes
5- CapReq

Détenteur de carte

Passerelle de paiement

150
Messages Sens de Signification
transmission
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

151
Condensât des Condensât de
Renseignements l’ordre
D’achat D’achat

Signature
duale Signature duale

Chiffrement
symétrique
Condensât des Condensât des
Instructions de Instructions de
paiement paiement
Clé aléatoire de
chiffrement symétrique
Signature duale DES Signature duale

PAN
PAN Chiffrement avec la clé pub de
152
chiffrement de la passerelle
Composition du message PReq
 La signature duale du message PReq

hachage
Condensât OI

Juxtaposition des hachage

Nouveau condensât
condensâts

hachage
Condensât PI Signature duale
Chiffrement avec la clé
privée de signature du
porteur
153
 Clé aléatoire de chiff sym

hachage

hachage condensât
Clé p de sig mar
condensât
sceau
Clé privé de signature
du marchand
sceau
Clé pub de chif
de la passerelle

Condensât des
Instructions
de paiement
Signature
duale

PAN
Message AuthReq transmis par le marchand
à l’attention de la passerelle de paiement
154
 Application: KLeline

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

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

156
 Application: Kleline(1)
Le protocole CPTP(Customer Server Transaction Protocole)decrit le deroulement d’un
achat et son règlement.

157
 Echanges de messages dans un achat Kleline

1-consultation du catalogue
2-sélection d’articles
4- offre de vente
Client 5-commande Commerçant
KLEBOX 12-livraison
6-ticket de caisse(PRT)
11-bon de caisse(PPT)

6-ticket de caisse(PRT)
8-cmde
confirmée(CAR)

7-comfir de cmde(CAC) Serveur de paiement

Kleline
10-bon de caisse (PPT)

compensation

Banque de
Kleline

Banque du Banque du 158

client commerçant
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.

159
VPN

160
  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 161
 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

162
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

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

165
166
167
Chapitre5:
Les Protocoles
d’authentifications

168
Le protocole Radius
lProtocole d'authentification
Remote
ld'utilisateurs distants
Access
lInitialement plutôt utilisé par les ISP
lPour authentifier leurs utilisateurs
Dial lDéveloppé par Livingston
In Enterprises
lLe protocole de base de RADIUS est
User
décrit dans le RFC 2865.
Service
lUtilise UDP sur le port 1812
(anciennement 1645)

169
Radius est un serveur de type
AAA
l Authentification
l Quime parle ?
l Authorization
l Quelles autorisations je lui accorde ?
l Accounting
l Que fait-il ?
l

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

172
l L’implémentationde ce serveur a été
développée pour une plateforme UNIX,
mais une version gratuite existe pour Linux,
elle se nomme freeRADIUS.

173
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.
174
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.
175
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.
176
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).

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

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

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

181
l C’estle 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
182
l Lafigure ci-dessous décrit le flux de
messages échangés pendant une phase
d’authentification réussie entre un client et
un serveur RADIUS.

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

185
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é.
186
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.
187
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

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

189
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 190
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.


191
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

192
 Authentificateur(1
Code(1) Identifier(1) Longueur(2)
6)
Attrributs et valeurs
(variables)

193
Le champs Code
l1 - access-request
l 2 - access-accept
l 3 - Access-reject
l 4 - Accounting-request
l 5 - Accounting-response
l 11- Access-challenge

194
Identifier
l
l utilisé
pour associer les requêtes et les
réponses.

195
Authentificateur
l Utilisé
pour que l'équipement NAS
l puisse authentifier les réponses du serveur
l -> Request authenticator
l -> Response authenticator

196
Attributs et valeurs

l Ensemble d'attributs et leur valeur qui indique

quels services sont demandés ou
autorisés.

197
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é.
198
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.

199
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

200
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

201
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

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

203
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

204
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

205
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

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

207
 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

208
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

209
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

210
base de données MySql :
Migration vers une
authentification MySQL
l L’objectifde 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.

211
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

212
l #mysql –u root –p
l mysql> create database radius ;
l mysql> exit

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

214
l #mysql –u root radius < <rep decompression
archive
freeradius>/src/modules/rlm_sql_mysql_db
_mysql.sql

215
l Vous obtenez dans la base radius les tables
suivantes

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

217
KERBEROS

218
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
219
Ticket Request
l LeTGT est un ticket crypté par le mot de
passe ayant le login envoyé dans le 1er
message.
l TGT ne suffit pas à authentifier Alice puisqu’il
est transmis en clair et peut donc être
réutilisé par un intrus.

220
 USER

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)

5- TGS+ Authentificateur

Crypté avec le TGKey

Serveur
KERBEROS
4- TGT service(TGS) contient (Clé de session crypté avec le TG
Key)
Crypté avec le AS Key

Serveur d’application 221

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

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

224