1 / 56

Chapitre 3: Gestion des clefs

Chapitre 3: Gestion des clefs. 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.

remy
Download Presentation

Chapitre 3: Gestion des clefs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 clef de session La gestion des clefs clef maîtresse 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. A = g^a mod n B = g^b mod n La gestion des clefs Bob Alice g et n sont publics a (privé) b (privé) Alice : Kab = B^a mod n = g^(ab) mod n Bob : Kba = A^b mod n = g^(ab) mod n = Kab 7

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

  9. La gestion des clefs Bob Alice 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 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. Entête bloc 1 bloc n bloc 2 bloc 3 ISAKMP Les messages ISAKMP 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 KeyExchange • ID Identification • CERT Certificate • CR CertificateRequest • HASH Hash • SIG Signature • NONCE Nonce • N Notification • D Delete • VID VendorID 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. T 11 T 12 P 2 T 21 T 22 SA P 1 T 23 T 11 algo 1 T 12 algo 2 P1 SPI T 11 algo 1 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) : 22

  23. ISAKMP • KE (KeyExchange) : 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 (CertificateRequest) : 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 (VendorID) : 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. HDR, SA, NONCE Sélection des attributs de SA Attributs négociés HDR, SA, NONCE Vérification de l'authenticité HDR, KE, IDinit, AUTH Vérification de l'authenticité HDR, KE, IDresp, AUTH ISAKMP Base Exchange Initiator Responder 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. Sélection des attributs de SA HDR, SA Attributs négociés HDR, SA HDR, KE, NONCE Calcul de la clef HDR, KE, NONCE Calcul de la clef Vérification de l'authenticité HDR, IDinit, AUTH Vérification de l'authenticité HDR, IDresp, AUTH ISAKMP Identidy Protection Exchange Responder Initiator Ces 2 messages sont chiffrés 30

  31. ISAKMP 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 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 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 d’authentification , signature digitale - pseudo-random functions HMAC-MD5 - algorithmes d’encryptage DES-CBC 32 32

  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 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 32 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 = (C ookie-a, Cookie-b) KE - valeur public g^y en DiffieHelman 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 32 34 35

  35. ISAKMP Initiator Responder Vérification HDR, IDinit, AUTH 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 HDR, IDresp, AUTH Vérification 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 34 32 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. Sélection des attributs de SA HDR, SA, NONCE Attributs négociés et vérification de l'authenticité HDR, SA, NONCE, IDresp, AUTH Vérification de l'authenticité HDR, INinit, AUTH ISAKMP Authentication Only Exchange Initiator Responder 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. Calcul de la clef HDR, SA, KE, NONCE, IDinit Vérification de l'authenticité Calcul de la clef HDR, SA, KE, NONCE, IDresp, AUTH HDR, AUTH Vérification de l'authenticité ISAKMP Aggressive Exchange Initiator Responder 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. HDR, N / D ISAKMP Informational Exchange Initiator Responder 42

  43. ISAKMP 43

  44. ISAKMP 44

  45. IPSec DOI 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 : • DES • 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. Main Mode Phase 1 Aggresive Mode Phase 2 Quick Mode IKE 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

More Related