Les protocoles de sécurité - univ-orleans.fr · Yohan Boichut, Cours Sécurité Master 2 Un résumé rapide côté crypto Soient : – M, M1, et M2 des messages – K une clé –

Yohan Boichut, Cours Sécurité Master 1

Les protocoles de sécurité


Un résumé rapide côté crypto● Soient :

– M, M1, et M2 des messages– K une clé– A et B des agents

● On note : – M1.M2 : le message constitué de M1 et M2– {M}

K : M est chiffré par avec la clé K

– A -> B : M : A envoie le message M à B– I(A) -> B : M : I envoie le message M à B en se faisant passer

pour A


Un résumé rapide côté crypto● Chiffrement symétrique :

– KAB

= KAB

-1

– Bon rapport Volume données à chiffrer / Temps de chiffrement

– Une clé par couple d'acteur● Chiffrement asymétrique

– KA la clé publique de A, K

A-1 la clé privée de A

– {{M}K}

K-1= {{M}K-1}K

= M

– Inutilisable pour le chiffrement de gros volumes de données– Deux clés par acteur !


Un résumé rapide côté crypto● Fonctions de hachage (SHA, MD4, MD5...)

– |hash(d)| << |d|

● Statistiquement,

– Pour d1, d

2 : hash(d

1) != hash(d

2) si d

1 != d

2

– hash-1(d) est très difficile à calculer


Propriétés associées à la cryptographie● Confidentialité »

– {numéroDeCompte}KBanque

– {recette_fondue_au_morbier}KYohanSomeone

● Authentification / Signature électronique– « [email protected] ».{« yohan.boichut@univ-

orleans.fr »}K-1Yohan

– « Cours4.pdf ».{hash(« Cours4.pdf »)}K-1Yohan

● Intégrité : le contenu M d'un message {M}K ne peut pas être

modifié sans K


Propriétés associées aux protocoles● Les principales propriétés sont :

– Secret– Authentification d'un message (ou d'une entité)– Fraîcheur (anti-rejeu)– Accord non répudiable– Equité– Anonymat


Quelques applications● Communication secrète (SSL de https, SSH, GSM,...)● Authentification d'agents (Login, OTP, GSM,...)● Signature de contrats électroniques● Paiement par carte à puce● Paiement en ligne● Paiement hors-ligne● TV payante● Vote électronique● ...


Quelques définitions● Définition (Secret) : Un protocole assure le secret d'une donnée s

si un intrus ne peut pas déduire s

● Définition (Authentification de message) : un protocole permet à un agent A d'authentifier un message m s'il peut connaître de façon sûre l'émetteur de m

● Définition (Authentification d'entité) : Un protocole permet à un agent A d'authentifier un agent B si à la fin de la session réussie, A a la garantie qu'il a bien réalisé le protocole avec B

● Définition (Fraîcheur) : Pendant une session d'un protocole, une donnée est fraîche si l'on peut garantir qu'elle n'a pas été utilisée dans une autre session par un des acteurs


Principes de bases des protocoles● Envoi d'un secret de A à B (premier essai)

A -> B : {s}KB

– Si l'on considère un chiffrement parfait, seul B peut lire s



A -> B : {s}KB

– Si l'on considère un chiffrement parfait, seul B peut lire s– Mais de qui vient s ?

● Envoi d'un secret de A à B (deuxième essai)

– A -> B : {s.A}KB

– Et que fait un intrus dans ces conditions ? Hein ??



A -> B : {s}KB

– Si l'on considère un chiffrement parfait, seul B peut lire s– Mais de qui vient s ?

● Envoi d'un secret de A à B (deuxième essai)

– A -> B : {s.A}KB

– Et que fait un intrus dans ces conditions ? Hein ??

– Voilà ce qu'il fait : I(A) -> B : {sI.A}

KB


Principes de bases des protocoles● Envoi d'un secret de A à B (troisième essai)

A -> B : {s.A.{s}K-1A

}KB

– Donc ici, nous avons ● s secret● B authentifie s comme étant émis par A ● ...


Principes de bases des protocoles● Envoi d'un secret de A à B (troisième essai)

A -> B : {s.A.{s}K-1A

}KB

– Donc ici, nous avons ● s secret● B authentifie s comme étant émis par A ● Mais... I peut faire accepter de nouveau s par rejeu

– A -> B : {s.A.{s}K-1A

}KB

– I(A) -> B : {s.A.{s}K-1A

}KB


Principes de bases des protocoles● Envoi d'un secret de A à B (quatrième essai)

B -> A : {A.B.N1}

KA « challenge de B »

A -> B : {s.A.B.N1}

KBréponse de A au challenge de B


Principes de bases des protocoles● Envoi d'un secret de A à B (quatrième essai)

B -> A : {A.B.N1}

KA « challenge de B »

A -> B : {s.A.B.N1}

KBréponse de A au challenge de B

– Donc ici, nous avons ● s secret● {s.A.B.N

1}

KB frais

● B authentifie s comme étant émis par A● B authentifie A au cours de la session


Etude de cas : le protocole des cartes bancaires● Le protocole d'utilisation d'une carte bancaire

doit permettre d'authentifier les transactions. L'authentification concerne deux préoccupations: – prouver que la carte utilisée a bien été émise par

l'autorité légitime;– prouver qu'une carte légitimement émise n'est pas

utilisée frauduleusement.● Chaque carte bancaire comporte un code secret

PIN, garantissant que seul la personne autorisée peut utiliser la carte. Il s'agit en général d'un nombre de 4 chiffres.


Fabrication de la carte● Un PIN est généré aléatoirement● Le PIN, et d'autres informations (numéro de compte par

exemple) est chiffré par un DES triple, en utilisant une clé de travail

● Une fonction à sens unique extrait certains bits du bloc chiffré obtenu pour construire le PIN offset

● Le PIN Offset est enregistré dans la mémoire de la carte, avec le numéro de compte

● Le PIN est posté au possesseur de la carte et effacé de la mémoire

● Une fois la carte émise, seul le possesseur légitime de la carte connaît le PIN


Résumé


Validation d'une transaction● La validation d'une transaction peut se faire localement

à partir d'un terminal. Elle se limite alors à un protocole d'identification du propriétaire.– Le possesseur de la carte tape son PIN sur le terminal;– le terminal chiffre le PIN et le numéro de compte par un DES

triple, en utilisant la clé de travail et extrait le PIN offset;– le PIN offset est comparé avec celui enregistré sur la carte.

● Le terminal doit avoir accès à la clé de travail qui a servi à chiffrer le PIN.

● Une clé maître (TMK) est générée et installée pour chaque terminal. Le système central télécharge les clés de travail, chiffrées avec la TMK correspondante.


● Ce protocole donne une garantie contre l'utilisation frauduleuse d'une carte légitimement émise, mais ce n'est pas un protocole d'authentification car il n'empêche pas la fabrication de fausses cartes.

● La validation peut aussi être faite par un serveur, ce qui évite de conserver les clés de travail sur le terminal.


Protocole utilisé pour un retrait d'espèces dans un distributeur

● Un client insère sa carte dans le distributeur;● la piste magnétique est lue;● le client entre son code PIN; il est stocké dans un buffer

inaccessible;● le client tape la somme qu'il veut retirer;● le message contenant le PIN et la somme est chiffré avec la

TMK et envoyé au serveur;● Le serveur de la banque déchiffre le message et calcule le PIN

Offset avec la clé de travail correspondante. Il le compare au PIN Offset stocké dans sa base de données.

● La transaction est approuvée.


Gestion des clés secrètes● Quand deux interlocuteurs se trouvent en deux poins différents

d'un réseau et qu'ils souhaitent dialoguer de manière confidentielle, ils doivent échanger une clé secrète.

● On peut imaginer de nombreux protocoles permettant le partage d'un clé secrète:– A choisit une clé secrète et la remet physiquement à B;– Un tiers de confiance choisit une clé et la remet physiquement à A et B;– Si A et B ont récemment utilisé une clé commune, l'un des deux

interlocuteurs transmet une nouvelle clé à l'autre, en utilisant l'ancienne;– Si A et B disposent chacun d'un canal de communication sûr avec un

tiers de confiance, celui-ci peut leur envoyer une clé commune.– etc,...


● Avec les protocoles 1 et 2, le problème est le nombre de clés à remettre. – A raison d'une clé par paire d'interlocuteurs, il faut

N(N-1)/2 clés pour N interlocuteurs. ● Par exemple:

– Il faudra 500000 clés pour 1000 communications;– Il faudra, 500 millions de clés pour 10000

communications.● Avec le protocole 3, si un attaquant découvre une clé,

il peut déchiffrer tous les échanges échangés ultérieurement.


Hiérarchies de clés ● Afin de réduire le nombre de clés à distribuer

c'est le protocole 4 (ou des variantes) qui est le plus largement utilisé actuellement.

● Un organisme central est responsable de la distribution des clés.

● Les clés sont organisées en hiérarchie (2 niveaux au minimum). Chaque utilisateur partage une clé-maitre (master-key) avec le centre de distribution et, pour dialoguer, deux interlocuteurs partagent une clé de session (session-key).


● La clé de session est communiquée aux deux interlocuteurs par le centre de distribution, en utilisant la clé-maître.

● La clé de session est valable en principe pour la durée d'une connexion.

● Avec une hiérarchie à deux niveaux, on voit que N interlocuteurs n'ont besoin que de N clés maîtres remises matériellement, au lieu de N(N-1)/2 avec les autres modes de distribution.


Protocoles d'échange de clés● Avec un tiers de confiance S et des clés symétriques

1. A -> S : A.B.Na2. S -> A : {Na.B.K

AB.{K

AB.A}

KBS}

KAS

3. A -> B : {KAB

.A}KBS

Propriétés attendues :– Secret de K

AB

– Fraîcheur de KAB

(pour A mais pas pour B)

– Authentification des messages émis par S


● Le but d'un protocole d'échange avec authentification est de permettre à deux interlocuteurs d'échanger une clé secrète en garantissant que chacun parle bien à l'autre et non pas à un intercepteur.

● Le protocole de Needham et Schroeder utilise un chiffre à clés publique comme le RSA

Echange avec authentification (Needham et Schroeder) sans tiers de

confiance


● On suppose qu'au départ les interlocuteurs A et B disposent chacun de la clé publique authentique de l'autre.

● De cette hypothèse d'authenticité des clés publiques découlent deux conséquences importantes.– Si un message, chiffré avec la clé publique de A, a

été déchiffré, ce ne peut être que par A lui-même– Un message que l'on peut déchiffrer avec la clé

publique de A a nécessairement été chiffré avec la clé privée correspondante, donc par A lui-même


● A utilise la clé publique KU_B de B pour chiffrer un message destiné à B et contenant son identité ID_A et un challenge N1 qui sert à identifier l'instance du protocole.

● B utilise KU_A pour chiffrer un message destiné à A et contenant N1 ainsi qu'un nouveau challenge N2.

● Puisque seul B a pu déchiffrer le message précédent, la présence de N1 permet à A de vérifier que son correspondant est bien B.

● A renvoie N2 à B, chiffré avec KU_B.● Puisque seul A a pu déchiffrer le message précédent, la présence de N2 permet

à B de vérifier que son correspondant est bien A.● A génère une clé secrète SK et envoie à B: C=E(KU_B, E(KR_A, SK))● Le chiffrement avec KU_B garantit que seul B peut lire le message. Le

chiffrement avec KR_A garantit que seul A peut l'avoir envoyé.● Pour obtenir la clé secrète, B déchiffre C en calculant:

SK=D(KU_A, D(KR_B,C))


Distribution des clés publiques

● Comme on vient de le voir, la distribution des clés publiques doit autant que possible permettre de garantir leur authenticité. On peut classer les techniques de distribution utilisées en trois grandes catégories:– Diffusion.– Répertoire public– Certificats


Diffusion● C'est la méthode la plus simple. Le possesseur

d'une clé publique la diffuse librement, par exemple en l'ajoutant à la fin des messages qu'il place dans un forum, ou encore à la fin de chaque courrier électronique qu'il envoie.

● Un attaquant peut prétendre être l'utilisateur A, et diffuser une clé, en affirmant qu'il s'agit de la clé publique de A. Il est ainsi capable de lire tout message chiffré avec cette clé et destiné en fait à A. L'authenticité n'est pas garantie.


Répertoire public● Afin d'éviter l'usurpation d'identité, un tiers de confiance, l'Autorité,

gère une liste de paires (nom, clé_publique). ● Chaque utilisateur doit prouver son identité pour enregistrer sa clé

auprès de l'autorité. ● Lorsque deux utilisateurs A et B veulent communiquer, chacun doit

demander à l'autorité la clé publique de l'autre. Le point faible est ici la communication avec l'autorité.

● Pour sécuriser la distribution des clés à partir du répertoire public on peut utiliser le protocole suivant:

● Les communications entre les utilisateurs et l'autorité utilisent un chiffre à clé publique comme RSA, permettant de déchiffrer avec la clé publique un message chiffré avec la clé privée correspondante. On suppose que chaque utilisateur connaît la clé publique KU_auth de l'autorité. Seule l'autorité connaît la clé privée KR_auth correspondante.


● A envoie à l'autorité un message estampillé (date) demandant la clé publique de B;● L'autorité répond en envoyant à A un message chiffré avec sa clé privée KR_auth.

Ce message contient:– la clé publique KU_B de B;

– le message originel de A, afin de vérifier qu'il n'a pas été altéré avant sa réception par l'autorité;

– l'estampille originale, afin d'éviter la retransmission d'un ancien message de l'autorité contenant une autre clé que celle de B;

● A note la clé publique de B, et l'utilise pour envoyer à B un message chiffré contenant un identificateur de A et un challenge N1 (nonce)

● B obtient de la même manière la clé publique KU_A de A.● B envoie à A un message chiffré avec KU_A, et contenant N1 ainsi qu'un nouveau

challenge N2. ● Comme seul B a pu déchiffrer le message de A, la présence de N1 permet à A de

vérifier que son correspondant est bien B.● A retourne N2, chiffré avec KU_B, pour permettre à B de vérifier que son

correspondant est bien A.


Certificats● Avec le protocole précédent, chaque utilisateur doit s'adresser à

l'Autorité chaque fois qu'il veut obtenir la clé publique d'un correspondant. Une autre approche consiste à utiliser des certificats, permettant l'échange sûr des clés publiques sans intervention de l'autorité.

● Un certificat est émis par l'autorité. Il contient la clé publique de son propriétaire, ainsi que d'autres informations. Il doit satisfaire les contraintes suivantes.– chaque interlocuteur peut lire un certificat, afin de connaître le

nom et la clé publique du propriétaire;– chaque interlocuteur peut vérifier que le certificat provient bien

de l'autorité et qu'il n'a pas été altéré;– Seule l'autorité peut émettre des certificats;– un certificat à une validité limitée dans le temps.


● Exemple. Un utilisateur A fournit matériellement à l'Autorité une clé publique KU_A et demande un certificat. Après vérification de l'identité ID_A de A, l'Autorité construit le certificat:C_A=E(KR_Auth, [ID_A,KU_A])où KR_Auth est la clé privée de l'Autorité.

● Ce certificat peut donner lieu à une attaque active par répétition.– Un attaquant C vole la clé privée KR_A de A;– A s'en aperçoit et demande un nouveau certificat;– C envoie à B l'ancien certificat de A;– B chiffre ses messages destinés à A avec l'ancienne clé KU_A;– C les déchiffre avec KR_A.

● Afin de limiter les conséquences d'une telle attaque, on ajoute une date limite de validité T (timestamp) au certificat: A=E(KR_Auth,[ID_A,KU_A, T])


Protocoles d'échange de clés● Avec un tiers de confiance S et des clés publiques

1. A -> S : A.B2. S -> A : {K

B.B}

K-1S

3. S -> B : {KA.A}

K-1S

Propriétés attendues :– Authentification des clés publiques– Mais

● pas de secret (pas nécessaire)● pas de fraîcheur (pas nécessaire ?)


Protocoles d'échange de clés DH● Le protocole de Diffie-Hellman est utilisé dans de

nombreux produits commerciaux pour permettre l'échange sûr d'une clé secrète. – Il se généralise autour de la génération d'un secret par

des sous-secrets distribués● Il est basé sur la difficulté de calculer des

logarithmes discrets– On appelle racine primitive d'un entier p tout nombre

entier a dont les puissances successives engendrent les p-1 entiers > 0 modulo p.

Exemple. a=2 est une racine primitive de p=5. Les racines primitives de 19 sont 2,3,10,13,14,15.


Protocoles d'échange de clés DH


● Il n'y a que peu d'entiers qui admettent des racines primitives. Ce sont les nombres de la forme ou

, avec q premier, q>2.● Si a est une racine primitive de p, alors pour tout entier b>0

il existe un unique exposant L compris entre 1 et p-1 tel que :

● Le nombre L est appelé logarithme discret de b pour la base a modulo p, et on le note :

● Exemple:

qm

2qm

bmod p=aL mod p

L=ind a , pb

ind 2,5 14=2


●Le calcul des logarithmes discrets conduit à des algorithmes impraticables. ●Actuellement on considère qu'avec des nombres p comportant plus de 600 chiffres, le calcul est impossible.●Le protocole de Diffie-Hellman fixe un nombre p et une racine primitive a de p. Les valeurs a et p sont publiques. A et B procèdent ainsi pour échanger une clé secrète.● A génère aléatoirement un entier X_A < p et calcule ● B procède de même, avec X_B et Y_B;● A et B gardent secrets X_A et X_B et envoient Y_A et Y_B à

leur correspondant● A calcule la clé et B calcule

Y A=a X A mod p

K=Y BX A K '=Y A

X B


●On voit que les clés K et K' calculées par A et B sont égales. ●Un attaquant ne connaissant que Y_A et Y_B doit calculer

pour trouver la clé. ●Comme il ne permet pas à A et B de vérifier qu'ils parlent bien l'un à l'autre le protocole de Diffie-Hellman ne résiste pas à une attaque par interception.

X A= ind a , p Y A


● Clé symétrique sans tiers de confiance – Diffie Hellman

– Entiers p et g publics et g générateur Zp

1. A -> B : XA = gx mod p

2. B -> A : YB = gy mod p

– A calcule (YB) x mod p et B calcule (X

A) y mod p

– KAB

= (YB) x mod p = (X

A) y mod p = gx*y mod p


● Clé symétrique sans tiers – Diffie Hellman– Entiers p et g publics et g générateur Z

p

1. A -> B : XA = gx mod p

2. B -> A : YB = gy mod p

● Propriétés attendues – Secret de K

AB

– Fraîcheur de KAB

● Mais...– Pas d'authentification des entités – Pas de réelle authentification de K

AB par A et B !


Avec une cryptographie parfaite, les protocoles sont ils sûrs pour autant ?


Un protocole pas si sûr que çà...

● Les acteurs sont : ● A un utilisateur● B la banque● C la carte de A● T le terminal du commerçant



● Scénario● A introduit sa carte● Le commerçant saisit le montant m sur T● T authentifie C● A donne son code à C (3456)● Si m > 100€ (et dans 20% des cas)● T demande à B l'autorisation pour c● B donne l'authorisation


Un protocole pas si sûr que çà...● A possède un code secret 3456● B possède

● Une clé publique KB

● Des clés secrètes KB

-1 et KCB

● C possède des informations publiques● Data = nom, prénom, numéro carte, validité● Valeur de signature = {hash(Data)}

K-1B

● Clé secrète : KCB

(DES)

● T possède la fonction hash et la clé publique KB (RSA)



● Initialement, la sécurité de la carte reposait beaucoup sur :● La non réplicabilité de la carte● Le secret autour des clés employées

● Mais ● Faille cryptographique clé RSA 320 bits (1988)● Faille logique du protocole : pas de lien entre le

code à 4 chiffres et authentification● Faille physique : Yescard (Humpich 1998)



1.C -> T : Data.{hash(Data)}K-1B

T authentifie C

C authentifie A (A donne son code à C)2.T -> A : Code ? 3.A -> C : 34564.C -> T : Ok



1.C -> T : Data.{hash(Data)}K-1B

T authentifie C

C authentifie A (A donne son code à C)2.T -> A : Code ? 3.A -> C' : 75754.C' -> T : Ok


Et comment fait on pour lutter ?


Et comment fait on pour lutter ? Art. 67-1. (L. n 91-1382 du 30 déc. 1991) Seront punis d’un emprisonnement d’un an à sept ans et d’une amende de 3.600 F à 5.000.000 F ou de l’une de ces deux peines seulement :

1. Ceux qui auront contrefait ou falsifié une carte de paiement ou de retrait ;

2. Ceux qui, en connaissance de cause, auront fait usage d’une carte de paiement ou de retrait contrefaite ou falsifiée ;

3. . . .


Plus sérieusement...

Il existe aujourd'hui des outils issus du milieu de la recherche qui assurent la sécurité d'un protocole

● Proverif● AVISPA● Hermes● Securify● Scyther● FDR● NRL Protocol Analyzer● + tout un tas de prouveur...


Principe de vérification

Modélisation d'un intrus

● Il peut chiffrer un message● Il peut déchiffrer un message s'il a la clé correspondante● Il peut décomposer un message● Il peut composer un message● Il peut lire tout ce qui traîne sur le réseau● ...

Nous verrons tout ceci en détail dans le cours : Modélisation et Vérification



Le problème de sécurité d'un protocole est indécidable dans le cadre le plus général !!!

● Nombre non borné d'agents● Nombre non borné d'exécutions● Taille non borné des messages



Le problème de sécurité d'un protocole est indécidable dans le cadre le plus général !!!

● Nombre non borné d'agents● Nombre non borné d'exécutions● Taille non borné des messages

Il existe des semi-algorithmes permettant de montrer qu'un protocole est sûr dans de telles conditions :

- Calculs de sur-approximations de la connaissance de l'intrus



Le problème de sécurité d'un protocole est décidable pour un nombre d'exécutions donné

● Nombre borné d'agents● Nombre borné d'exécutions

Utilisation de Model-checker : SAT, Contraintes, Réécriture, Clauses de Horn, ...


Petit historique La recherche / Protocoles de sécurité

Needham Schroëder – 1978Protocole d'authentification prouvé manuellement

ALICE BOB




{Nalice.Alice}

Kbob

ALICE BOB




{Nalice.Alice}

Kbob

{Nalice.N

bob}Kalice

ALICE BOB




{Nalice.Alice}

Kbob

{Nalice.N

bob}Kalice

{Nbob}Kbob

ALICE BOB



18 ans plus tard... Découverte d'une faille logiquepar Gavin Lowe grâce aux méthodes formelles(Model-checking)

{Nalice.Alice}

Kbob

{Nalice.N

bob}Kalice

{Nbob}Kbob

ALICE BOB



L'attaque est du type MITM

ALICE BOBBOB

MOI




{123.Alice}Kmoi

ALICE BOBBOB

MOI




{123.Alice}Kmoi

ALICE BOBBOB

MOI

{123.Alice}Kbob




{123.Alice}Kmoi

{123.234}Kalice

ALICE BOBBOB

MOI

{123.Alice}Kbob




{123.Alice}Kmoi

{123.234}Kalice

ALICE BOBBOB

MOI

{123.Alice}Kbob

{234}Kmoi




{123.Alice}Kmoi

{123.234}Kalice

ALICE BOBBOB

MOI

{123.Alice}Kbob

{234}Kmoi

{234}Kbob


Prolifération de résultats

● Problèmes de décidabilités et de complexité

● Pleins de techniques de vérifications

● Langages de spécification - Grosso modo 1 langage par approche :-s- Des langages de plus haut niveau et des

regroupements d'outils (ex : AVISPA et HLPSL)

Documents

Les protocoles de sécurité - univ-orleans.fr · Yohan Boichut, Cours Sécurité Master 2 Un résumé rapide côté crypto Soient : – M, M1, et M2 des messages – K une clé –