Administration Et Securité Reseau Chap 5

Administration et sécurité des réseaux
Chap 5: Gestion des clés symétriques ou asymétriques, Protocoles

d’authentification, Kerberos, Protocoles de sécurité
Rhouma Rhouma
https://sites.google.com/site/rhoouma
ENSIT
Décembre 2014
1 / 97
Plan
1 Distribution des clés secrètes dans les alg symétriques
2 Distribution des clés publiques ds les alg asymétriques
3 Authentification des utilisateurs : contrôle d’accés
4 Protocoles d’authentification
5 Kerberos
6 Sécurité du Web (TCP/IP)
7 Sécurité au niveau de la couche Transport

SSL
mitm attack : sslstrip
SSH
8 Sécurité niveau application : sécurité e-mail

PGP
9 Sécurité IP
2 / 97
Distribution des clés secrètes dans les alg symétriques
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
3 / 97
Problème de distribution et gestion des clés
Le problème de génération et distribution des clés est un

problème majeure dans les communications sécurisées.
La sécurité des protocoles et des alg de cryptage est basé sur ce
problème fondamental
La gestion des différents clés des différents entités est aussi un
problème majeur
Les alg symétriques requiert que les deux interloculteurs
partagent la même clé secrète
les alg asymétriques requiert que les interlocuteurs possédent
des clés publiques valides de leurs correspondants
4 / 97
Distribution des clés
Alice et Bob ont beaucoup d’alternatives pour distribuer une clé

Alice peut sélectionner une clé et la délivre physiquement à Bob
(main à main)
Une tierce partie peut sélectionner et délivrer la clé à Alice et Bob
Si Alice et bob ont communiqué auparavant, ils peuvent utiliser
l’ancienne clé pour chiffrer la nouvelle
Si Alice et Bob ont des lignes sécurisés avec une tierce partie
Charlie, alors Charlie peut relayer la clé entre Alice et bob.
5 / 97
Hiérarchie des clés
Généralement deux types de clés

clé de session
clé temporaire
utilisée por chiffrer les données entre deux interlocuteurs
utilisée pour une seule session puis rejeté
clé principale :
utilisée pour chiffrer les clés de sessions
partagée par les utilisateurs et un centre de distribution de clé
(KDC)
6 / 97
Protocoles d’authentification
utilisés pour convaincre les entités de leurs identités et pour

échanger des clés de session
Peut être dans un seul sens ou mutuel (ds les deux sens)
Les protocoles d’authentification permettre de garantir :
confidentialité : pour protéger les clés de session
Timeliness (tiens compte du timing) : pour empêcher les attaques
replay (rejeu)
7 / 97
Authentification dans un seul sens
ce type d’authentification est requis lorsque émetteur et récepteur

ne sont pas en communication en même temps (ex : e-mail)
l’entête de ce type de protocole doit être clair (non chiffré) pour
être délivré sans problème par un système d’email
le contenu du corps d’email peut être chiffré
l’émetteur doit être authentifié
8 / 97
Authentification par cryptographie symétrique
peut être faite moyennant un centre de distribution de clé (KDC)

chaque entité partage sa clé principale avec le KDC
le KDC génère les clés de session utilisés pour la connexions
entre les différents entités
les clés principales sont utilisés pour distribuer les clés de session
9 / 97
Scénario de distribution de clé : Needham-Schroeder
10 / 97
Protocole de Needham-Schroeder
distribution de clés par une tierce partie

pour une session entre deux entités A et B orchestré par un KDC
le protocole est comme suit :
1 A -> KDC : IDA ||IDB ||N1
2 KDC -> A : E(Ka , [Ks ||IDB ||N1 ||E(Kb , [Ks ||IDA ])])
3 A -> B : E(Kb , [Ks ||IDA ])
4 B -> A : E(Ks , [N2 ])
5 A -> B : E(Ks , [f (N2 )])
11 / 97
replay attack sur Needham-Schroeder
Le protocole est vulnérable à une replay-attack : le message de

l’étape 3 peut etre retransmit convainquant B qu’il est en
communication avec A
solution pour résoudre ce problème :
ajouter des timestamps dans l’étape 2 et 3
ajouter un nombre aléatoire à usage unique externe pour chaque
échange de clé Ks
12 / 97
Distribution de clé automatique dans un protocole

orienté connexion
13 / 97
Distribution d’une clé à l’aide d’une alg asymétrique :

une simple distribution de clé
Merkle a proposé le protocole suivant pour distribuer une clé :
14 / 97
Man-in-the-middle-attack sur le protocole de Merkle
15 / 97
Distribution d’une clé à l’aide d’une alg asymétrique :

confidentialité et authentification
16 / 97
Distribution des clés publiques ds les alg asymétriques
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
17 / 97
Distribution des clés publiques
Peut se faire par :

annonce publique
à travers une archive (répertoire) disponible publiquement
à travers Une autorité de clé publique
Certificats de clés publiques
18 / 97
Distribution par Annonce publique
Les utilisateurs distribuent leurs clés publiques aux bénéficiaires

(intéressés) ou par diffusion à la communauté
attacher les clés publiques de PGP aux e-mails, ou les envoyer aux
nouveaux groupes ou diffusion aux mails du carnet d’adresses
Principal problème de cette méthode est la modification =
contrefaçon
n’importe qui peut créer une clé prétendant être quelqu’un d’autre
et la diffuser
jusqu’à ce que la falsification soit découverte, l’adversaire peut
communiquer comme si c’était l’utilisateur légitime
19 / 97
Distribution des clés par répertoire disponible

publiquement
20 / 97
Distribution de clé par autorité de clé publique
21 / 97
Distribution de clé par Certificats
Les certificats permettent l’échange de clés publiques sans acces

en temps réel à une autorité de clé publique
Le certificat fait le lien entre l’identité et la clé publique
généralement avec d’autre info tel que période de validité, droits
d’utilisation
le contenu de la certificat est signé par une une autorité de clé
publique ou une autorité de certification (AC)
n’importe quel utilisateur connaissant la clé publique de l’AC peut
vérifier la signature
22 / 97
Création et échange des certificats
23 / 97
Utilisation du certificat
24 / 97
Certificat X.509
X.509 est une partie de la serie de recommandations X.500 qui

deéfinit un annuaire de services.
l’annuaire est un serveur ou un ensemble de serveurs qui maintient
une base de donnée sur les utilisateurs
X.509 définit une méthode de travail pour la fourniture de services
d’authentification par l’annuaire X.500 à ses utilisateurs
paru en 1988 et révisé dernièrement en 2000.
basé sur l’utilisation de la cryptographie asymétrique et les
signatures numériques
n’impose pas d’utiliser un alg spécifique mais recommande
l’utilisation de RSA
n’impose pas une fonction de hachage spécifique
chaque certificat contient la clé publique de l’utilisateur et signé
par la clé privée de l’AC
X.509 propose des protocoles d’authentifications basé sur
l’utilisation des certificats numériques
25 / 97
Certificat X.509
le certificat est généré par une authorité de Certification (CA), et

contient :
version V (1, 2, ou 3)
numéro de série SN (unique dans une CA) identifiant le certificat
l’identifiant de l’algorithme de signature (AI)
l’CA créateur du certificat)
periode de validité TA (de - à dates)
Le nom du sujet (nom du propriétaire du certificat)
les info concernant la clé publique du sujet(algorithme, paramètres,
clé publique)
l’identifiant unique du créateur de la signature (v2+)
l’identifiant unique du sujet (v2+)
champs d’extension (v3)
signature (du hash de tous les champs dans le certificat)
la notation CA«A» indique que le certificat de A est signé par CA
26 / 97
Format X.509
27 / 97
La hiérarchie des autorités de certification
Si les deux utilisateurs partage la même CA, alors ils connaissent

tous les deux sa clé publique
sinon les autorité de certifications forment une héarchie
utiliser des certificats liant les membres de la hiérarchie pour
valider les autres CA
chaque CA a des certificats pour ses clients et ses parents
chaque client fait confiance à ses parents
la hiérarchie permette la vérification de n’importe quel certificat
d’un CA par les utilisateurs des autres CA dans la héarchie
28 / 97
La hiérarchie des autorités de certification
29 / 97
PKI : Public Key Infrastructure
30 / 97
Authentification des utilisateurs : contrôle d’accés
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
31 / 97
Authentification des utilisateurs
Aspect fondamental de sécurité : base de controle d’acces

c’est le processus de la vérification d’identité revendiqué par un
système
l’authentification se fait en deux étapes
identification : spécifier l’identifiant
vérification : lier l’identité (du système ou la personne) à l’identifiant
ce n’est pas l’authentification de message
32 / 97
Les méthodes d’authentification des utilisateurs
Quelque chose que vous connaissez ...

mot de passe, PIN
Quelque chose que vous avez ...
Clé physique, jeton, carte magnétique, carte à
puce
Quelque chose que vous êtes ...
Empreinte digitale, la voix, la rétine, l’iris
Quelque part où vous êtes ...
localisation GPS
Préférable d’utiliser deux ou plus de ce qui
précède : Appelé authentification à deux
facteurs
33 / 97
Jeton d’authentification (de RSA) basé sur le temps
34 / 97
Empreintes digitales
35 / 97
Le Scan d’Iris
36 / 97
Protocoles d’authentification
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
37 / 97
Kerberos
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
38 / 97
Kerberos
Kerberos
Service d’authentification dévéloppé au MIT

Pourquoi Kerberos ?
Un utilisateur peut accéder à un poste de travail particulier et faire
semblant d’être un autre utilisateur opérant à partir de ce poste.
Un utilisateur peut modifier l’adresse de réseau d’une station de
travail de sorte que les requêtes envoyées par le poste de travail
modifié semblent provenir de la station de travail usurpée
Un utilisateur peut espionner les échanges et utiliser une attaque
replay pour gagner l’entrée à un serveur ou à perturber les
opérations
Kerberos fournit un service d’authentification centralisé dont la
fonction est d’authentifier les utilisateurs aux serveurs et les
serveurs aux utilisateurs
Kerberos est basé totalement sur la cryptographie symétrique. La
cryptographie à clé publique n’est pas utilisée
il y a deux version de Kerberos : 4 et 5
39 / 97
Kerberos
Kerberos V4
Utilise DES pour l’authentification
le serveur d’authentification (AS) :
connaît les mots de passe de tous les utilisateurs et les enregistre
dans une base de donnée centralisé
partage une clé secrète avec chaque serveur
Ticket :
un ticket est crée une fois l’AS authentifie l’utilisateur. Le ticket
contient l’ID de l’utilisateur, l’adresse réseau, et l’Id serveur
le ticket est chiffré par la clé secrète partagé par l’AS et le serveur
TGS : Ticket-granting Service
crée et distribue les tickets aux utilisateurs qui ont été authentifié
par l’AS
à chaque fois que l’utilisateur requiert l’accès à un nouveau service,
le client demande cette connexion au TGS en utilisant le ticket pour
s’authentifier au près du TGS
Le TGS accorde alors un ticket pour le service particulier
Le client enregistre les tickets de chaque service et les utilise pour
s’authentifier à un serveur à chaque fois un service particulier est
demandé
40 / 97
Kerberos
l’échange de messages par Kerberos V4
41 / 97
Kerberos
42 / 97
Kerberos
43 / 97
Sécurité du Web (TCP/IP)
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
44 / 97
Sécurité du Web
Le Web (TCP/IP) est utilisé en commerce, par le gouvernement et

par des individuels
Mais le web est vulnerable
il y a beaucoup de problèmes qui menacent :
la confidentialité
l’intégrité
la disponibilité
l’authentification
il faut des mécanismes additionnels à la pile de protocole TCP/IP
45 / 97
Positionnement des mécanismes de sécurité dans

TCP/IP
46 / 97
Sécurité au niveau de la couche Transport
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
47 / 97
Sécurité au niveau de la couche Transport SSL
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
48 / 97
SSL
Secure Socket Layer est un service de sécurité Transport

développé par Netscape etintegré dans son navigateur
est devenu le standard internet TLS (Transport Layer Security)
utilise TCP pour fournir un service de sécurité de bout en bout
SSL a deux couches de protocoles
49 / 97
La pile de protocoles SSL
SSL se base sur des sous protocoles :

SSL handshake (authentification
mutuelle du serveur et du client,
négociations des algorithmes,
négociations des clés de session)
SSL Change Cipher Spec
SSL Alert (envoi de messages d’erreur
ou warning / fatal)
SSL Record (confidentialité et intégrité
des données)
50 / 97
51 / 97
52 / 97
Encapsulation de SSL
53 / 97
Architecture SSL
connexion SSL :
transitoire, peer-to-peer, lien de communication
associé à une session SSL
Session SSL :
une association entre client et serveur
crée par le protocole handshake
définit un ensemble de paramètres cryptographiques
peut être partagé par plusieurs connexions SSL
54 / 97
SSL Record Protocol Services
Confidentialité
utilise un cryptage symétrique avec une clé partagé défini par le
protocole Handshake
AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40,
RC4-128
le message est compressé avant cryptage
Intégrité : utilise un MAC avec une clé secrète partagée
55 / 97
Opération faite par le protocole SSL record
56 / 97
format du SSL record
57 / 97
Le protocole SSL Handshake
permette au serveur et client de :

s’authentifier l’un à l’autre
négocier les algorithmes de cryptage et du MAC
négocier les clés cryptographiques qui vont être utilisées
comprend une série de messages dans plusieurs phases
établir les capacités de sécurité
Authentification du serveur et échange de clés
Authentification du client et échange de clés
Termine la connexion
58 / 97
Les messages de SSL Handshake
59 / 97
Le protocole Handshake (établissement de connexion)

en action
60 / 97
TLS
c’est une standardization IETF qui a pour but de produire un

standard internet basé sur SSL
défini comme un standard internet en RFC 5246
RFC 5246 est très similaire à SSL v3
principales différences :
numéro de Version
Message Authentification Code
fonction Pseudo-aléatoire
clés d’alerte
la série des algorithmes de cryptage
le type de certificat client
Les messages Certificate_verify et Finished
61 / 97
HTTPS
HTTPS est HTTP bsé sur SSL

Combinaison de HTTP et SSL/TLS pour sécuriser les
communications entre la navigateur et le serveur
Utilise https :// URL au lieu de http ://
Utilise le port 443 au lieu de 80
chiffre : l’url, le contenu, la forme de données, cookies, l’entête
HTTP
62 / 97
Sécurité au niveau de la couche Transport mitm attack : sslstrip
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
63 / 97
SSLstrip
man in the middle attack sur SSL

SSL peut parfois donner un faux sentiment de securité
Moxie Marlinspike a crée sslstrip et l’a présenté à Black Hat DC
2009
http ://www.thoughtcrime.org/
N’attaque pas SSL, mais la transition de la communication
non-chiffrée à la communication chiffrée.
64 / 97
connexion https normale
65 / 97
connexion https hacké par sslstrip
66 / 97
comment fonctionne sslstrip ?
Configurer la machine du mitm pour "IP forwarding" :

Configure attack machine for IP forwarding
rediriger le trafic http (port 80) à sslstrip (port 54321) :
iptables –t nat –A PREROUTING –p tcp –destination-port 80
–j REDIRECT –to-port 54321
démarrer sslstrip :
sslstrip –l 54321
Configure ARP spoofing :
arpspoof –i eth0 –t <targetIP> <gatewayIP>
lancer un sniffer et collection des données (logins/passwords)
67 / 97
https normal
68 / 97
https stripped
69 / 97
Sécurité au niveau de la couche Transport SSH
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
70 / 97
Secure Shell (SSH)
Protocole pour communications réseaux sécurisées

SSH1 fourni une facilité de connexion à distance sécurisée
Remplace TELNET et d’autres protocoles non sécurisés
en plus il fournit une architecture client/serveur
SSH2 vient pour corriger quelques problèmes de sécurité dans
SSH1
les clients et serveurs SSH2 sont très bien répandu
71 / 97
Auparavant il y avait Telnet
72 / 97
Connexion à distance par SSH
73 / 97
Avantages de SSH
chiffrement de la session et mot de passe unique (OTP)
le client SSH est disponible sur un très grand nombre de
platesformes
la sécurité est assurée depuis le client jusqu’au serveur
(end-to-end security)
possibilité de faire le port forwarding : Le Port Forwarding (ou
transfert de port) permet d’utiliser une liaison SSH pour
transporter des protocoles non sécurisés (POP, NNTP, ...).
On peut alors constuire un VPN basé sur des liaisons SSH.
74 / 97
Formation du packet SSH
75 / 97
Les algorithmes cryptographiques utilisés par SSH
76 / 97
Sécurité niveau application : sécurité e-mail
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
77 / 97
Sécurité niveau application : sécurité e-mail PGP
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
78 / 97
Sécurité des e-mails
Confidentialité : Protection contre la divulgation des messages

Authentification : de l’émetteur du message
intégrité du message : protection de la modification
non-répudiation de l’émetteur : preuve d’envoie de message
2 applications : PGP et S/MIME
79 / 97
PGP
Pretty good Privacy tres repandu pour protéger les e-mails

développé par Phil Zimmermann
PGP a sélectionné le meilleur des algorithmes cryptographiques
pour les implementer
intégré dans un seul programme
sur UNIX, PC, MAcintoch et autres systèmes
originalement gratuit, il y a des versions commerciales aussi
80 / 97
Résumé sur les services PGP
81 / 97
Opération PGP d’authentification
1 l’émetteur crée un message

2 il applique le hash SHA-160-bit sur le message
3 il fait joindre le condensé signé par RSA au message
4 Le récepteur déchiffre & retrouve le condensé
5 le récepteur verifie le condensé reçu
82 / 97
Opération PGP de confidentialité
1 l’émetteur forme une clé de session aléatoire de 128-bit

2 chiffre le message avec la clé de session
3 fait joindre la clé de session, chiffrée avec RSA, au message
4 le récepteur déchiffre et retrouve la clé de session
5 la clé de session est utilisée pour déchiffrer le message
83 / 97
PGP : confidentialité et authentification
On peut appliquer les deux services au meme message

creer la signature et l’attacher au message
chiffrer le message et la signature
attacher les clés de session chiffré par RSA ou ElGamal
84 / 97
Transmission et réception des messages PGP
85 / 97
Gestion des clés dans PGP
Dans PGP, il n’ y a pas une tierce partie : autorité de certification

chaque utilisateur de PGP est son propre CA
un utilisateur peut signer les clés des utilisateurs qu’il connaît
les utilisateurs forme "un réseau de confiance"
un utilisateur peut faire confiance à des clés que d’autres ont
signé s’il y a une chaîne de signatures conduisant à ces
utilisateurs
un utilisateur possède une porte-clés avec des indicateurs de
confiance pour chaque clé
les utilisateurs peuvent également révoquer leurs clés
86 / 97
Sécurité IP
Plan
5 Kerberos

SSL
SSH

PGP
9 Sécurité IP
87 / 97
Sécurité IP
Pourquoi sécurité IP
il existe des mécanismes de sécurité dédié à des applications

spécifiques :
ex : S/MIME, PGP, Kerberos,SSL/HTTPS
mais il y a des problèmes de sécurité qui sont indépendants des
couches de protocole
On veut implémenter une sécurité sur le réseau et pour toutes les
applications
La sécurité IP fournit :
l’authentification
la confidentialité
gestion des clés
applicable à des LAN, WAN publique et privée, et pour l’internet
implémente sécurité pour IPv4 et IPv6
88 / 97
Sécurité IP
Scénario de IPsec
89 / 97
Sécurité IP
Les Atouts de IPsec
Lorsque IPsec est mis en oeuvre dans un pare-feu ou un routeur, il offre une sécurité
renforcée qui peut être appliquée à tout le trafic traversant le périmètre
IPsec dans un pare-feu est résistant au contournement si tout le trafic de l’extérieur doit
utiliser une IP pour entrer et le pare-feu est le seul moyen de l’entrée à l’organisation
depuis l’internet
IPsec est en dessous de la couche de transport (TCP, UDP) et il est donc transparent pour
les applications
Il n’est pas nécessaire de modifier le software sur le système ou de changer le serveur,
lorsque IPsec est mis en oeuvre dans le pare-feu ou un routeur
IPsec peut être transparente pour les utilisateurs
Il n’est pas nécessaire de former les utilisateurs sur les mécanismes de sécurité, ou sur le
problème de creation/gestion des clés ou de révoquer la saisie de clés lorsque les
utilisateurs quittent l’organisation
IPsec peut assurer la sécurité des utilisateurs individuels si nécessaire
Ceci est utile pour les travailleurs hors site pour mettre en place un sous-réseau virtuel
sécurisé (VPN) au sein d’une organisation pour les applications sensibles
90 / 97
Sécurité IP
Architecture IPsec
Architecture
RFC4301 Security Architecture for Internet Protocol
Authentication Header (AH)
RFC4302 IP Authentication Header
Encapsulating Security Payload (ESP)
RFC4303 IP Encapsulating Security Payload (ESP)
Internet Key Exchange (IKE)
RFC4306 Internet Key Exchange (IKEv2) Protocol
algorithmes Cryptographiques
91 / 97
Sécurité IP
Services de IPsec
IPsec fournit des services de sécurité à la couche IP en permettant à

un système de :
Sélectionner les protocoles de sécurité requis
Déterminer l’algorithme à utiliser pour le service
Mettre en place des clés cryptographiques nécessaires pour
fournir les services demandés
RFC 4301 énumère les services suivants :
1 contrôle d’accès
2 l’intégrité
3 Authentification de l’origine des données
4 Rejet de paquets répétés
5 confidentialité (cryptage)
92 / 97
Sécurité IP
Mode Transport et Mode tunnel
Mode Transport
pour chiffrer et authentifier (option) les données des datagrames IP
sécurité allégé pour performance meilleure
approprié pour communication hôte à hôte utilisant ESP
Mode tunnel
chiffre tout le datagramme Ip (entete et données)
ajoute une nouvelle entête pour le prochain routage (saut)
aucun routeur dans le chemin ne peut examiner l’IP chiffré
(intérieur)
approprié pour VPN, haute sécurité passerelle à passerelle
93 / 97
Sécurité IP
AH mode transport
94 / 97
Sécurité IP
AH mode Tunnel
95 / 97
Sécurité IP
ESP mode transport
96 / 97
Sécurité IP
ESP mode Tunnel
97 / 97

Administration Et Securité Reseau Chap 5

Transféré par

Droits d'auteur :

Formats disponibles

Administration Et Securité Reseau Chap 5

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Administration Et Securité Reseau Chap 5

Transféré par

Droits d'auteur :

Formats disponibles

Administration et sécurité des réseaux

Chap 5: Gestion des clés symétriques ou asymétriques, Protocoles

1 Distribution des clés secrètes dans les alg symétriques

2 Distribution des clés publiques ds les alg asymétriques

3 Authentification des utilisateurs : contrôle d’accés

6 Sécurité du Web (TCP/IP)

7 Sécurité au niveau de la couche Transport

8 Sécurité niveau application : sécurité e-mail

1 Distribution des clés secrètes dans les alg symétriques

2 Distribution des clés publiques ds les alg asymétriques

3 Authentification des utilisateurs : contrôle d’accés

6 Sécurité du Web (TCP/IP)

7 Sécurité au niveau de la couche Transport

8 Sécurité niveau application : sécurité e-mail

Problème de distribution et gestion des clés

Le problème de génération et distribution des clés est un

Distribution des clés

Alice et Bob ont beaucoup d’alternatives pour distribuer une clé

Hiérarchie des clés

Généralement deux types de clés

utilisés pour convaincre les entités de leurs identités et pour

Authentification dans un seul sens

ce type d’authentification est requis lorsque émetteur et récepteur

Authentification par cryptographie symétrique

peut être faite moyennant un centre de distribution de clé (KDC)

Scénario de distribution de clé : Needham-Schroeder

distribution de clés par une tierce partie

replay attack sur Needham-Schroeder

Le protocole est vulnérable à une replay-attack : le message de

Distribution de clé automatique dans un protocole

Distribution d’une clé à l’aide d’une alg asymétrique :

Merkle a proposé le protocole suivant pour distribuer une clé :

Man-in-the-middle-attack sur le protocole de Merkle

Distribution d’une clé à l’aide d’une alg asymétrique :

1 Distribution des clés secrètes dans les alg symétriques

2 Distribution des clés publiques ds les alg asymétriques

3 Authentification des utilisateurs : contrôle d’accés

6 Sécurité du Web (TCP/IP)

7 Sécurité au niveau de la couche Transport

8 Sécurité niveau application : sécurité e-mail

Distribution des clés publiques

Peut se faire par :

Distribution par Annonce publique

Les utilisateurs distribuent leurs clés publiques aux bénéficiaires

Distribution des clés par répertoire disponible

Distribution de clé par autorité de clé publique

Distribution de clé par Certificats

Les certificats permettent l’échange de clés publiques sans acces

Création et échange des certificats

X.509 est une partie de la serie de recommandations X.500 qui

le certificat est généré par une authorité de Certification (CA), et

La hiérarchie des autorités de certification

Si les deux utilisateurs partage la même CA, alors ils connaissent

La hiérarchie des autorités de certification

PKI : Public Key Infrastructure

1 Distribution des clés secrètes dans les alg symétriques

2 Distribution des clés publiques ds les alg asymétriques

3 Authentification des utilisateurs : contrôle d’accés

6 Sécurité du Web (TCP/IP)