Dr. M. Jarraya, Institut Supérieur d'Informatique

Présentation au sujet: "Dr. M. Jarraya, Institut Supérieur d'Informatique"— Transcription de la présentation:

1 Dr. M. Jarraya, Institut Supérieur d'Informatique
Chapitre 3: Gestion des clefs Dr. M. Jarraya, Institut Supérieur d'Informatique

2 La gestion des clefs Les 3 types de clefs :
clefs de chiffrement de clefs : elles servent à chiffrer d'autres clefs. Elles ont une durée de vie longue. clefs maîtresses : elles servent à générer d'autres clefs. clefs de session (ou clefs de chiffrement) : elles servent à chiffrer les messages. Elles ont en général une durée de vie courte. 2

3 clef de chiffrement de clef
La gestion des clefs clef maîtresse clef de chiffrement de clef clef de session 3

4 La gestion des clefs Il existe deux méthodes pour échanger des clefs :
transport de clefs : on échange une clef chiffrée (cf. transparent précédent) génération de clefs : on partage un secret sans entente préalable. Dans le deuxième cas, l'algorithme le plus utilisé est l'algorithme de Diffie-Hellman. 4

5 La gestion des clefs Propriétés des protocoles d'échanges de clef :
Perfect Forward Secrecy : les clefs de sessions passées ne peuvent pas être retrouvées si un secret à long terme est découvert. Back Traffic Protection : la génération des clefs est telle que chaque clef est indépendante des clefs passées. 5

6 La gestion des clefs Diffie-Hellman (1976)
basé sur la cryptologie à clef publique (log. discret) permet de partager un secret sans entente préalable 6

7 La gestion des clefs Alice Bob g et n sont publics a (privé) b (privé)
A = g^a mod n B = g^b mod n Alice : Kab = B^a mod n = g^(ab) mod n Bob : Kba = A^b mod n = g^(ab) mod n = Kab 7

8 La gestion des clefs Alice Bob g et n sont publics a (privé) b (privé)
A = g^a mod n B = g^b mod n g et n A et B mais pas g^ab mod n 8

9 La gestion des clefs Alice Bob Kab Kbc Kac Charlie 9

10 La gestion des clefs Solution :
échanger des valeurs publiques authentifiées ou authentifier les valeurs publiques après l'échange Les clefs publiques doivent pouvoir être reliées de manière sûre à un individu (ou à un serveur, une institution, ...). 10

11 Protocole Photuris Protocole en trois phases :
Echange de cookies, pour garantir une faible authentification contre les attaques de type DOS(Denial of Service). Echange de valeurs publiques pour l’établissement d’une clé partagée. Echange d'identités pour une authentification mutuelle 11

12 Protocole Photuris 12 Les cookies sont basés sur: Adresses IP et port.
Un secret local Cookie = hash (adresse IP source et destination et port + secret local) 12

13 Protocole Oakley Oakley RFC 2412
Oakley dispose de plusieurs options pour distribuer les clefs : Diffie-Hellman classique chiffrer une clef puis la distribuer dériver une nouvelle clef d'une clef existante 13

14 Protocoles d'échange de clefs
Il y a trois étapes : l'échange de cookies l'échange de valeurs publiques l'authentification Proche de SKEME, Oakley permet la négocation d'un grand nombre de paramètres. 14

15 ISAKMP ISAKMP (Internet Security Association and Key Management Protocol) Ce protocole sert à : l'établissement la modification la suppression des Associations de Sécurité ISAKMP est un cadre générique qui doit être accompagné d'un domaine d'interprétation (DOI - Domain Of Interpretation). 15

16 ISAKMP 16

17 ISAKMP ISAKMP comprend deux phases : l'établissement d'une SA ISAKMP
authentification des tiers, génération des clefs, échanges ISAKMP la négociation des paramètres d'une SA pour un mécanisme donné (AH ou ESP par exemple) le trafic de cette phase est sécurisé par la SA ISAKMP NB : Une SA ISAKMP est bidirectionnelle Une SA ISAKMP a une durée de vie plus longue qu'une SA IPSec 17

18 ISAKMP Les messages ISAKMP Entête bloc 1 bloc 2 bloc 3 bloc n
2 cookies : protection contre le déni de service identifiants + Next Payload Nombre variable de blocs 18

19 ISAKMP Il existe 13 types de blocs : SA Security Association
P Proposal T Transform KE Key Exchange ID Identification CERT Certificate CR Certificate Request HASH Hash SIG Signature NONCE Nonce N Notification D Delete VID Vendor ID 19

20 ISAKMP SA (Security Association) : ce bloc contient des champs qui indiquent le contexte de la négociation. Paramètre DOI : 0 pour ISAKMP 1 pour IPSec P (Proposal) : ce bloc indique le mécanisme de sécurité que l'on désire utiliser (AH, ESP) et le SPI associé à la SA. Chaque bloc est numéroté. S'il y a plusieurs mécanismes pour une même SA, les blocs portent le même numéro. T (Transform) : ce bloc indique une transformation (algorithme de chiffrement, fonction de hachage, ...). Ces blocs sont également numérotés. 20

21 ISAKMP Après un bloc SA 1 ou plusieurs blocs P Après un bloc P
1 ou plusieurs blocs T 21

22 ISAKMP Les trois premiers types de blocs s'enchaînent donc de la manière suivante (la proposition retenue fournira le SPI à l'association de sécurité concernée) : SA P 1 T 11 T 12 P 2 T 21 T 22 T 23 T 11 algo 1 T 12 algo 2 P1 SPI T 11 algo 1 22

23 ISAKMP KE (Key Exchange) : ce bloc sert au transport des données nécessaires à la génération de la clef de session. ID (Identification) : ce bloc est utilisé pour l'identification des parties. Un des champs de ce bloc est le champ ID Type. Pour ISAKMP, cela peut être par exemple une adresse IP. CERT (Certificate) : ce bloc permet de transporter des certificats, ou toute information s'y rattachant. CR (Certificate Request) : ce bloc est utiliser pour réclamer un certificat à son interlocuteur. HASH (Hash) : ce bloc contient le résultat de l'application d'une fonction de hachage. 23

24 ISAKMP SIG (Signature) : ce bloc a le même rôle que le bloc HASH, mais il est utilisé dans le cas d'une signature. NONCE (Nonce) : ce bloc est utilisé pour transporter de l'aléa. N (Notification) : ce bloc est utilisé pour transmettre les messages d'erreur ou d'informations sur les négociations en cours. Il existe 2 champ : Notify Message Type et Notify Data. D (Delete) : ce bloc permet de supprimer une SA et indiquer qu'elle n'est plus valable. VID (Vendor ID) : ce bloc est réservé aux programmateurs pour distinguer 2 instances de son implémentation. 24

25 ISAKMP Les types de messages
A partir des blocs précédents, le protocole ISAKMP définit des types d'échanges (Exchange Types). Il y a 5 types d'échanges par défaut : Base Exchange (4 messages) Identity Protection Exchange (6 messages) Authentication Only Exchange (3 messages) Aggressive Exchange (3 messages) Informational Exchange (1 message) 25

26 ISAKMP Notation HDR = entête du paquet ISAKMP SA = blocs SA + P + T 26

27 ISAKMP 27

28 ISAKMP Base Exchange Initiator Responder Sélection des attributs de SA
HDR, SA, NONCE Sélection des attributs de SA HDR, SA, NONCE Attributs négociés HDR, KE, IDinit, AUTH Vérification de l'authenticité HDR, KE, IDresp, AUTH Vérification de l'authenticité 28

29 ISAKMP Base Exchange Les messages 3 et 4 sont authentifiés par la fonction d'authentification sélectionnée par les messages 1 et 2. L'anonymat des tiers en présence n'est pas protégé. En effet, les identités sont échangées avant qu'un secret ne soit partagé et ne permette de les chiffrer. 29

30 ISAKMP Identidy Protection Exchange Responder Initiator
HDR, SA Sélection des attributs de SA HDR, SA Attributs négociés HDR, KE, NONCE Calcul de la clef HDR, KE, NONCE Calcul de la clef HDR, IDinit, AUTH Vérification de l'authenticité HDR, IDresp, AUTH Vérification de l'authenticité Ces 2 messages sont chiffrés 30

31 ISAKMP Initiator Responder Sélection des attributs de SA 31 HDR, SA
- Cookie-I = Cookie-a (8 oct.) - Cookie-R = 0 - Message-ID = 0 - SPI = 0 (Cookie-a, Cookie-b) SA: - DOI = IPSEC - Proposal = ex. ISAKMP, IPSec ESP, (plusieurs) - Transform (plusieurs) - méthode d’authentification , signature digitale - pseudo-random functions HMAC-MD5 - algorithmes d’encryptage DES-CBC (ex, RSA_WITH_RC4_128_SHA) 31 32

32 ISAKMP Initiator Responder Attributs négociés 32 HDR, SA HDR
- Cookie-R = Cookie-b -CCookie-I = Cookie-a - Message-ID = 0 - SPI = 0 (Cookie-a, Cookie-b) SA - DOI = IPSEC - Proposal = PROTO_ISAKMP - Transform - méthode d’authentification , signature digitale - pseudo-random functions HMAC-MD5 - algorithmes d’encryptage DES-CBC 32 32

33 ISAKMP Initiator Responder Calcul de la clé 33 HDR, KE, NONCE HDR
- Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 (Message-ID reste zero dans toute la phase 1 de ISAKMP) - SPI = (Cookie-a, Cookie-b) KE - valeur public g^x en Diffie Helman de l’initiateur ou x est la clé privé de l’initiateur NONCE - Ni , un nombre aléatoire choisit à partir de formules mathématique très strictes 33 34 32

34 ISAKMP Initiator Responder Calcul de la clé 34 HDR, KE, NONCE HDR
- Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 - SPI = (C ookie-a, Cookie-b) KE - valeur public g^y en Diffie Helman de l’initiateur où y est la clé privée du répondeur NONCE - Nr , un nombre aléatoire choisit à partir de formules mathématique très strictes Génération de la clé secret SKEYID a partir de Cookie-a, Cookie-b, Ni, Nr, g^xy 34 34 32 35

35 ISAKMP Initiator Responder Vérification de l'authenticité 35
HDR, IDinit, AUTH Vérification de HDR (en Clair) l'authenticité - Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) IDii: (chiffré) - identité de l’émetteur Auth : (chiffré) - un message chiffré et signé pour qu’il soit identifié au répondeur 35 32 34 35 36

36 ISAKMP Initiator Responder Vérification de l'authenticité 36
HDR, IDresp, AUTH de l'authenticité HDR : (en Clair) - Cookie-R = Cookie-b - Cookie-I = Cookie-a - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) IDir: (chiffré) - identité du récepteur Auth : (chiffré) - un message crypté et signé pour qu’il soit identifié a l’émetteur 36 32 34 35 36

37 ISAKMP Identidy Protection Exchange
Les deux derniers échanges sont chiffrés par la clef calculée à paritr des données des échanges 3 et 4. Au prix de 2 messages supplémentaires, l'anonymat des tiers est assuré. 37

38 HDR, SA, NONCE, IDresp, AUTH
ISAKMP Authentication Only Exchange Initiator Responder HDR, SA, NONCE Sélection des attributs de SA HDR, SA, NONCE, IDresp, AUTH Attributs négociés et vérification de l'authenticité HDR, INinit, AUTH Vérification de l'authenticité 38

39 ISAKMP Authentication Only Exchange
Cet échange n'est conçu que pour l'authentification des tiers. La génération d'une clef est un processus gourmand en ressources système, et doit être évité si elle n'est pas nécessaire. 39

40 HDR, SA, KE, NONCE, IDresp, AUTH
ISAKMP Aggressive Exchange Initiator Responder HDR, SA, KE, NONCE, IDinit Calcul de la clef HDR, SA, KE, NONCE, IDresp, AUTH Vérification de l'authenticité Calcul de la clef HDR, AUTH Vérification de l'authenticité message chiffré 40

41 ISAKMP Aggressive Exchange
Dans cet échange, un seul message contient les données de négociation de la SA, d'authentification et d'échange de clef. Comme pour l'échange de base, l'anonymat des tiers n'est pas protégé. Il n'y a pas de choix possible dans la négociation de la SA. 41

42 ISAKMP Informational Exchange Initiator Responder HDR, N / D 42

43 ISAKMP 43

44 ISAKMP 44

45 IPSec DOI 45 Domaine d'interprétation pour IPSec RFC 2407
Ce document définit les paramètres négociés et les conventions pour l'utilisation du protocole ISAKMP dans le cadre d'IPSec. Exemple : Bloc P - définition du protocole de sécurité Dans le cadre de l'IPSec DOI, ce bloc peut prendre 4 valeurs : ISAKMP AH ESP IPCOMP (compression des données au niveau IP) 45

46 IPSec DOI Domaine d'interprétation pour IPSec
Exemple : Bloc T - définition de l'algorithme Pour AH, il y a 3 choix possibles : MD5 SHA DES Pour ESP : 3DES RC5 IDEA CAST BLOWFISH 3IDEA RC4 NULL 46

47 IPSec DOI Domaine d'interprétation pour IPSec
Exemple : Bloc ID - définition de l'identité du tiers DES sous-réseau IPv4 plage d'adresses IPv4 (ou IPv6) FQDN user FQDN X.500 Distinguished Name X.500 General Name Key ID 47

48 IKE IKE RFC 2409 Utilise ISAKMP pour construire un protocole pratique.
IKE comprend quatre modes : mode principal (Main Mode) mode agressif (Aggressive Mode) mode rapide (Quick Mode) mode nouveau groupe (New Group Mode) 48

49 IKE Phase 1 Main Mode Aggresive Mode Phase 2 Quick Mode 49

50 IKE Phase 1 : Main Mode 6 messages sont générés par le mode Main Mode durant la phase 1 en vue d'établir : 4 paramètres : un algorithme de chiffrement, une fonction de hachage, une méthode d'authentification et un groupe pour Diffie-Hellman 3 clefs : une pour le chiffrement, une pour l'authentification et une pour la dérivation d'autres clefs Main Mode est une instance de l'échange ISAKMP Identity Protection Exchange. 50

51 IKE Phase 1 : Main Mode Initiator Responder
Négociation des paramètres IKE Génération des valeurs DH et des aléas Authentification mutuelle Ces 2 messages sont chiffrés 51

52 IKE Phase 1 : Aggressive Mode
Le mode Aggressive Mode est une variante du mode Main Mode qui ne contient que 3 messages. C'est une instance de l'échange ISAKMP Aggressive Exchange. 52

53 IKE Phase 2 : Quick Mode Les échanges de cette phase sont protégés en confidentialité et en authenticité grâce à la SA ISAKMP établie lors de la phase 1. La phase 2 a pour but de mettre en oeuvre les SA (ou les “paquets” de SA) pour IPSec. Chaque négociation donne lieu à deux SA (les SA IPSec étant unidirectionnelle). 53

54 IKE Phase 2 : Quick Mode Initiator Responder SA négociée clef calculée
HDR, HASH SA, NONCE, [KE], [IDinit, IDresp] HDR, HASH, SA, NONCE, [KE], [IDinit, IDresp], AUTH SA négociée clef calculée message chiffré HDR, HASH 54

55 IKE Phase 2 : Quick Mode Un nouvel échange de valeurs Diffie-Hellman a lieu pour respecter la propriété "Perfect Forward Secredy". Cet échange est optionel. 55

56 IKE Phase 2 : Quick Mode Initiator Responder 56 SPI 101 ESP IDEA MD5
3DES SHA-1 Empreinte valeurs DH Aléa IDi, IDr SPI 102 ESP 3DES SHA-1 Empreinte valeurs DH Aléa IDi, IDr Empreinte 56