• Aucun résultat trouvé

D´efinition du module FAST et mod`ele de s´ecurit´e

Chapitre 3 : Stade TA2 - Module FAST

3.3 D´efinition du module FAST et mod`ele de s´ecurit´e

Dans cette section, nous nous attachons `a d´efinir le module FAST qui pourra se voir

comme un g´en´erateur de cl´es prenant en entr´ee des profils utilisateurs Ω (D´efinition 45).

Nous rappelons les limitations que ce module devra r´esoudre :

• gestion d’attributs variables et donc de profils variables (Limitation L2) ;

• respect de la politique d’authentification sur deux niveaux (Limitation L3).

Au passage, le module FAST permettra d’exploiter le fingerprinting, identifi´e comme

r´eponse aux limitations L0 et L1

3.3.1 efinition et discussion

D´efini par le triplet de primitives(GenParam, GenKey, RepKey), le module FAST va g´en´erer

une politique d’authentification adapt´ee au niveau de s´ecurit´eλpar le biais de la primitive

GenParam. La primitive GenKey prendra en entr´ees un profil utilisateur adapt´e `a la

politique PA pour g´en´erer une cl´e sk et une donn´ee publique d’aide de reconstruction

prendra en entr´ee un profil Ω0 toujours adapt´ee `a la politique d’authentification PA et

la donn´ee publique hd pour reconstruire le secret sk `a condition que Ω et Ω0 soient

compatibles selon PA. Afin de d´efinir le champ d’action dun module FAST, nous

consid´ererons des distributions de probabilit´es dont seront issus les profils utilisateurs.

Nous proposons la d´efinition suivante.

efinition 49. Soit W une famille de distributions de probabilit´es d´efinies sur AT Tn.

Un module FAST est un triplet de proc´edures randomis´ees (GenParam, GenKey, RepKey)

satisfaisant les propri´et´es suivantes :

1. La proc´edure de g´en´eration des param`etres GenParam prend en entr´ee un param`etre

de s´ecurit´e λ pour retourner les param`etres publics du syst`eme constitu´es du triplet

(s, l, ) ∈ N2 × R, de la politique d’authentification PA ∈ Γ et ´eventuellement de

donn´ees de configuration DC∈ {0,1}∗.

2. La proc´edure de g´en´eration de cl´es GenKey en prend en entr´ees Ω∈ AT Tn adapt´e

`a PA, ladite politique PA∈Γ et DC∈ {0,1}∗ pour retourner une chaˆıne sk∈ {0,1}l

et une donn´ee de reproduction hd∈ {0,1}∗.

3. La proc´edure de reproduction RepKey prend en entr´ees Ω0 ∈ AT Tn adapt´e `a la

politique d’authentification PA ∈ Γ et les chaˆınes binaires DC et hd. La propri´et´e

de correctness de FAST garantit que si Ω0 ≈PA, (sk,hd) ← GenKey(Ω,PA,DC)

et ((s, l, ),PA,DC)←GenParam(1λ), alors RepKey(Ω0,PA,DC,hd) =sk. Dans tout

autre cas, aucune garantie n’est assur´ee sur la sortie sk.

4. La propri´et´e de s´ecurit´e doit garantir que la cl´e extraite est effectivement

pseudo-al´eatoire. Plus pr´ecis´ement, pour tout profilissu d’une distribution W ∈ W, la

valeur sk doit appraˆıtre pseudo-al´eatoire, mˆeme en pr´esence de hd. Autrement dit,

pour toute distribution W ∈ W, en notant SK et HD les distributions induites par

GenKey (i.e. (SK,HD)←GenKey(W,PA,DC)), on aura δD

s

((sk,HD),(Ul,HD))6.

Sur l’entropie et la s´ecurit´e d’un profil

En fonction du niveau de s´ecurit´e vis´e λ, la politique d’authentification g´en´er´ee PA

(primitive GenParam) s´electionnera des identifiants d’attributs pour constituer des profils

contenant suffisamment d’entropie relativement `aλ. Par exemple, si deux utilisateursU et

U∗ venaient `a pr´esenter des profils Ω et Ω∗ compatibles selon PA, la consistance de FAST

permettait alors `aU∗ de s’authentifier au nom deU. Il faudra alors que l’entropie pr´esente

dans les attributs s´electionn´es par PA soit suffisante pour authentifier les utilisateurs

uniquement.

Ainsi et de mani`ere analogue `a la biom´etrie classique, les attributs d’un utilisateur

devront ˆetre prot´eg´es en confidentialit´e et int´egrit´e pour assurer la s´ecurit´e du syst`eme

et maintenir le respect de la vie priv´ee. Ce sont des contre-mesures logicielles pr´esentes

dans le module IDE (pour Intrusion Detection Engine, Figure 2.6) qui nous assurerons

que le module FAST prendra en entr´ee un profil utilisateur suppos´e ni corrompu ni connu

par un attaquant. Par analogie avec le cas biom´etrique, la connaissance de ce profil

correspondrait au cas o`u un attaquant connaˆıt l’empreinte digitale d’un utilisateur pour

qui il essaie de se faire passer.

Propri´et´es de s´ecurit´e

`A la mani`ere des Fuzzy Extractors, FAST prend en entr´ee des donn´ees potentiellement

variables pour retourner non seulement un secret cryptographique skmais ´egalement une

donn´ee publique hd permettant la reconstruction future du secret sk. Ainsi, les notions

de s´ecurit´e que nous allons consid´erer sont ´equivalentes `a celles des Fuzzy Extractors :

1. Secret cryptographique. Au vu de la d´efinition introduite ci-dessus, la donn´ee

sk est un secret cryptographique et doit donc apparaˆıtre al´eatoire aux yeux de tout

entit´e limit´ee en puissance de calcul. Ainsi, hd g´en´er´e ´egalement `a partir de Ω ne

devra pas d’information ni sur le profil utilisateur Ω ni sur le secret sk. Puisque

sk est issu de Ω, s’assurer en particulier que hd ne r´ev`ele rien sur sk suffit. Cela

correspond `a la propri´et´e de s´ecurit´e de la D´efinition 49.

2. eutilisabilit´e. La primitive GenKey pourra ˆetre appel´ee plusieurs fois au cours

de la vie d’un profil utilisateur puisque:

• un utilisateur pourra, en fonction de mises `a jour de l’application (Application

App) ou autres (e.g. Syst`eme d’exploitation) proc´eder `a un r´e-enrˆolement de

son profil utilisateur;

• la brique FAST est un g´en´erateur de cl´es ind´ependant de la solution TA ; aussi

d’autres solutions pourront en faire usage (e.g. coffre cryptographique).

La gestion du point 2 est assur´ee par le mod`ele de s´ecurit´e que nous d´efinissons dans

la prochaine sous-section.

3.3.2 Mod`ele de s´ecurit´e

Par les d´efenses logicielles propos´ees par l’IDE et de whiteboxes adapt´ees (Figure 2.6),

nous pouvons nous concentrer sur la description du mod`ele en boˆıte noire du module

FAST. Ce mod`ele s’attachera `a quantifier l’information qu’un adversaire pourrait r´ecolter

par diff´erents enrˆolements d’un mˆeme utilisateur. Alors que classiquement le mod`ele en

boˆıte noire conf`ere `a un attaquant la vue des entr´ees/sorties d’un algorithme, ce ne sera

pas le cas pour FAST puisque l’entr´ee (profil utilisateur Ω) est exactement la donn´ee `a

prot´eger en confidentialit´e. Notons le parall`ele avec les Fuzzy Extractors o`u les mod`eles

d´efinis par Boyen [85] et Canettiet al. [94] ne conf`erent pas non plus `a l’adversaire l’acc`es

au secret bruit´ew, qui l`a aussi, constitue le secret `a prot´eger.

Ainsi, un utilisateur donn´e U devra pouvoir enrˆoler ou r´e-enrˆoler plusieurs profils

compatibles Ω1, . . . ,ρ sur diff´erents serveurs sans que le cumul des donn´ees de

reconstruction associ´ees hd1, . . . ,hdρ ne permette `a un adversaire d’en d´eduire de

l’information significative.

Nous rappelons alors, par la Figure 3.1, la vue de haut niveau du mod`ele de s´ecurit´e

concernant le module FAST .

1. Entr´ees: ρvariantes de Ω.

et des donn´ees de configurationDC.

2. Sorties: FAST g´en`ereρsecrets `a

partir de Ω, et les hdjs associ´es auxskjs.

3. S´ecurit´e:

Les donn´eeshdjs sont publiques.

Certains secretsskjs peuvent ˆetre corrompus,

sans que la s´ecurit´e des autres

ski (i6=j) ne soit pas impact´ee.

Figure 3.1: Aper¸cu du mod`ele de s´ecurit´e de FAST

Nous nous appuyons sur la r´eutilisabilit´e des FEs selon Canetti et al. [94] pour

d´efinir la r´eutilisabilit´e de FAST par les jeux d´ecrits `a la Figure 3.2. Consid´erons alors

un challengeur C mettant au d´efi un adversaire A qui sp´ecifiera ρ variables al´eatoires

W1, . . . , Wρ d´efinies surAT T.

D’autre part, au cours du jeu, A pourra faire faire appel `a l’oracle Ocorrupt(.) pour

lequel un nombre polynomial de q requˆetes lui est accord´e :

• ´etant donn´e un exposant j sp´ecifi´e par l’adversaire, l’oracle lui retourne le secret

associ´e skj. Le syst`eme est mis `a jour : (j,skj) est ajout´e `a la liste des secrets

corrompus SC.

Le challengeurCet l’adversaireAvont alors ´echanger selon le sc´enario d´ecrit ci-dessous

:

1. Le challengeur C ex´ecute honnˆetement le protocole GenParam pour obtenir les

param`etres publicsparam dont la politique d’authentification PA.

2. L’adversaire A sp´ecifie ρ variables al´eatoires W1, . . . , Wρ d´efinies sur AT T pour

lesquelles les profils seront adapt´es `a la politique PA.

3. Pour j = 1. . . , ρ, le challengeur ´echantillonne Ωj$ Wj et calcule (skj,hdj) ←

GenKey(Ωj).

4. L’adversaire fait q0 6qrequˆetes `a l’oracleOcorrupt puis choisit d’attaquer l’exposant

j0.

5. Dans le cas d´ecisonnel, le challengeur retourne skj

0

`a l’adversaire si b = 1 et une

valeur al´eatoireµ← {$ 0,}l sinon.

6. L’adversaire peut encore faire qq0 requˆetes `a l’oracle Ocorrupt.

7. Dans la version calculatoire, A termine le jeu en retournant une valeur g ∈ {0,1}l

et gagne si g =skj

0

.

8. Dans la version d´ecisionnelle, l’adversaire produit b et gagne si b =b.

Discussion Supposer que l’adversaire serait celui qui a le moins de connaissances sur les

distributions des profils utilisateurs est injustifi´e et c’est en ce sens que la sp´ecification des

Wjs lui est attribu´ee `a l’´etape 2. En effet, toute information accessible `a un utilisateur

honnˆete est potentiellement `a disposition de l’adversaire. D’autre part, supposer ces

distributions de profils confidentielles aux yeux de l’adversaire peut s’av´erer dangereux :

un syt`eme pourrait alors baser sa s´ecurit´e sur cette m´econnaissance de l’adversaire mais

s’il advenait, par quelque mani`ere que ce soit, que ce dernier apprenne finalement ces

certaines informations, cela remettrait en cause la s´ecurit´e globale du syst`eme.

Dans la version calculatoire du jeu, l’adversaire choisit un exposant `a attaquer et

essaie de deviner la cl´e secr`ete associ´ee. La version d´ecisionnelle propose une ´etape

suppl´ementaire o`u l’adversaire doit d´ecider si la valeur retourn´ee par le challengeur est

effectivement le secret associ´eskj

0

ou une valeur al´eatoirement tir´ee. Puisqu’un adversaire

capable de retrouver le secretskj

0

(version calculatoire du jeu) sera capable de le distinguer

d’une valeur al´eatoire, un module FAST prouv´e sˆur vis-`a-vis de la version d´ecisionnelle le

sera aussi dans le cas calculatoire.

Nous formalisons le jeu, dans ses versions calculatoire et d´ecisionnelle, `a travers la

Figure 3.2.

efinition 50 (S´ecurit´e de FAST). Soit un A avec un nombre de requˆetes polynomial

q(λ) `a l’oracle Ocorrupt. On dira que le module FAST est q-r´eutilisable si les avantages

Advcalc

C,A(λ) et Advdec

C,A(λ) (Figure 3.2) sont n´egligeables.

Dans la prochaine section, nous proposons l’usage de FEs pour instancier la d´efinition

d’un module FAST.

(a) Version calculatoire CalcC,A(λ)

1. Cg´en`ereparam←GenParam(1λ).

avecparam= ((, s, l),PA,DC).

2. InitialiserSC=L=∅.

3. Asp´ecifie les distributionsW1, . . . , Wρ.

4. Pourj= 1. . . ρ,

C´echantillone ΩjWj.

(skj,hdj)←GenKey(Ωj,PA,DC),L∪hdj.

5. (j0, r)← A(param,L,SC:Ocorrupt).

6. Si (j0,skj

0

)∈SC, recommencer le jeu.

7. Agagne sir=skj

0

.

Advcalc

C,A(λ) =|Pr[r=skj

0

]−2−l

|

(b) Version d´ecisionnelle Decb

C,A(λ)

Etapes 1,2 et 3 identiques `a CalcC,A(λ).

3. Asp´ecifie les distributionsW1, . . . , Wρ.

4. Pourj= 1. . . ρ,

C´echantillone ΩjWj.

(skj,hdj)←GenKey(Ωj,PA,DC),L∪hdj.

5. j0← A(param,L,SC:Ocorrupt).

Sib= 1,Cretourner=skj

0

`aA.

Sib= 0,Cretourner← {$ 0,1}l`aA.

6. b∗← A(param,L,SC, r:Ocorrupt).

7. Si (j0,skj

0

)∈SC, recommencer le jeu.

Sinon l’adversaire gagne sib∗=b.

Advdec

C,A(λ) =|Pr[b=b]−1

2|

Figure 3.2: S´ecurit´e de FAST

3.4 Instanciation de FAST et r´eponse aux limitations