La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


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

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

2 La gestion des clefs 2 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.

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

4 La gestion des clefs 4 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.

5 La gestion des clefs 5 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.

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

7 La gestion des clefs 7 Bob Alice a (privé) b (privé) g et n sont publics 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

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

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

10 La gestion des clefs 10 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,...).

11 Protocole Photuris 11 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 dune clé partagée. Echange d'identités pour une authentification mutuelle

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)

13 Protocole Oakley 13 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

14 Protocoles d'échange de clefs 14 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.

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 18 bloc 1 Entête bloc 2 bloc 3 bloc n 2 cookies : protection contre le déni de service identifiants + Next Payload Nombre variable de blocs

19 ISAKMP Il existe 13 types de blocs : SA Security Association P Proposal TTransform KEKey Exchange ID Identification CERTCertificate CRCertificate Request HASHHash SIGSignature NONCENonce NNotification DDelete VIDVendor 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 21 Après un bloc P 1 ou plusieurs blocs P 1 ou plusieurs blocs T

22 ISAKMP 22 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) : P 1SA T 11 T 12 T 21P 2 T 22 T 23 P1 SPI T 11 algo 1 T 12 algo 2 T 11 algo 1

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

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

27 ISAKMP 27

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

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

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

31 ISAKMP 31 Initiator Responder HDR, SA Sélection des attributs de SA HDR - 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 dauthentification, signature digitale - pseudo-random functions HMAC-MD5 - algorithmes dencryptage DES-CBC (ex, RSA_WITH_RC4_128_SHA) 32

32 ISAKMP 32 Initiator Responder HDR, SA Attributs négociés 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 dauthentification, signature digitale - pseudo-random functions HMAC-MD5 - algorithmes dencryptage DES-CBC

33 ISAKMP Initiator Responder HDR, KE, NONCE Calcul de la clé 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 linitiateur ou x est la clé privé de linitiateur NONCE - Ni, un nombre aléatoire choisit à partir de formules mathématique très strictes 34

34 ISAKMP Initiator Responder HDR, KE, NONCE Calcul de la clé HDR - Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) KE - valeur public g^y en Diffie Helman de linitiateur 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 35

35 ISAKMP Initiator Responder HDR, IDinit, AUTH Vérification de HDR (en Clair) - Cookie-I = Cookie-a l'authenticité - 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 quil soit identifié au répondeur 36

36 ISAKMP Initiator Responder Vérification HDR, IDresp, AUTH de HDR : (en Clair) l'authenticité - 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 quil soit identifié a lémetteur

37 ISAKMP 37 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é.

38 ISAKMP 38 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é

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

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

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

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

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)

46 IPSec DOI 46 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 : DES 3DES RC5 IDEA CAST BLOWFISH 3IDEA RC4 NULL

47 IPSec DOI 47 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

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

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

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

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

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

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

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

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

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


Télécharger ppt "Dr. M. Jarraya, Institut Supérieur d'Informatique Chapitre 3: Gestion des clefs."

Présentations similaires


Annonces Google