slide1
Download
Skip this Video
Download Presentation
Chapitre 3: Gestion des clefs

Loading in 2 Seconds...

play fullscreen
1 / 56

Chapitre 3: Gestion des clefs - PowerPoint PPT Presentation


  • 105 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Chapitre 3: Gestion des clefs' - remy


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Chapitre 3:

Gestion des clefs

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

slide2

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

slide3

clef de chiffrement de clef

clef de session

La gestion des clefs

clef maîtresse

3

slide4

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

slide5

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

slide6

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

slide7

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

slide8

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

slide9

La gestion des clefs

Bob

Alice

Kab

Kbc

Kac

Charlie

9

slide10

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

slide11

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

slide12

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

slide13

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

slide14

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

slide15

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

slide17

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

slide18

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

slide19

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

slide20

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

slide21

ISAKMP

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

21

slide22

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

slide23

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

slide24

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

slide25

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

slide26

ISAKMP

Notation

HDR = entête du paquet ISAKMP

SA = blocs SA + P + T

26

slide28

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

slide29

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

slide30

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

slide31

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

slide32

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

slide33

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

slide34

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

slide35

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

slide36

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

slide37

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

slide38

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

slide39

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

slide40

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

slide41

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

slide42

HDR, N / D

ISAKMP

Informational Exchange

Initiator

Responder

42

slide45

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

slide46

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

slide47

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

slide48

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

slide49

Main Mode

Phase 1

Aggresive Mode

Phase 2

Quick Mode

IKE

49

slide50

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

slide51

Négociation des paramètres IKE

Génération des valeurs DH et des aléas

Ces 2 messages sont chiffrés

Authentification mutuelle

IKE

Phase 1 : Main Mode

Initiator

Responder

51

slide52

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

slide53

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

slide54

HDR, HASH SA, NONCE, [KE], [IDinit, IDresp]

SA négociée

clef calculée

HDR, HASH, SA, NONCE, [KE], [IDinit, IDresp], AUTH

HDR, HASH

message chiffré

IKE

Phase 2 : Quick Mode

Initiator

Responder

54

slide55

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

slide56

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

IKE

Phase 2 : Quick Mode

Initiator

Responder

56

ad