Description du stade TA1

A chaque authentification, le terminalT interroge alors l’´el´ement s´ecuris´e pour permettre

le d´eroulement d’une authentification telle que d´ecrite `a la Figure 2.1 .

La contrainte C1 empˆeche le d´eroulement d’un sc´enario tel que celui d´ecrit ci-dessus

tandis que la contrainte C2 empˆeche un sc´enario similaire `a l’exemple suivant.

Exemple 3. Afin d’authentifier de mani`ere certaine l’utilisateur, equensWorldline

l’enrˆole r´ecoltant toutes ses donn´ees identifiantes et les stocke sur ses serveurs.

Lorsqu’une phase d’authentification s’engage, il r´ecup`ere toutes les valeurs d’empreintes

de l’utilisateur `a l’instant t et les compare `a celles pr´ec´edemment stock´ees.

D’un point de vue s´ecuritaire, ce dernier exemple serait acceptable (en consid´erant

une base de donn´ees inattaqu´ee) mais le respect de la vie priv´ee de l’utilisateur ne serait

alors pas assur´ee.

2.3 Description du stade TA1

Selon le mode de fonctionnement de TA, un utilisateur souhaitant s’authentifier va prouver

la connaissance d’un secret, difficile `a retrouver pour toute entit´e autre que lui 2.1. Pour

ce faire, plusieurs probl´ematiques affleurent :

1. Secret Cryptographique. Pour ˆetre consid´er´e comme un secret cryptographique,

une donn´ee doit apparaˆıtre al´eatoire (ou pseudo-al´eatoire) et uniform´ement

distribu´ee. Un secret cryptographique consistera en une telle donn´ee et son

impr´edictibilit´e d´ecoulera de sa longueur (environ 100 bits d’apr`es l’ANSSI en

2016 [112]) pour assurer un niveau de s´ecurit´e ad´equat. Les empreintes biom´etriques

2. Gestion de secret. Une fois qu’un tel secret cryptographique a ´et´e g´en´er´e, se pose

la question de sa gestion. Si un secret cryptographique est conserv´e en clair sur un

dispositif, il peut ˆetre lu par un attaquant. S’il est stock´e, il doit l’ˆetre dans un

´el´ement s´ecuris´e.

3. Reproduction de secret. Au vu de notre contexte purement logiciel (contrainte

C1), aucun secret ne peut ˆetre stock´e ; il faudra ˆetre en mesure de la reconstruire `a

partir de certaines donn´ees plus `a mˆeme d’ˆetre conserv´ees ou r´ecup´er´ees.

2.3.1 Aper¸cu du fonctionnement

Initi´e en 2008 pour r´epondre `a l’appel `a projet rappel´e ci-dessus, la solution TA a pour

philosophie de g´en´erer `a la demande la cl´e secr`ete sk d’un utilisateur U. Ainsi, l’id´ee

consiste `a g´en´erer cette cl´e `a partir de donn´ees identifiantes que l’utilisateur aura a sa

disposition ; ces donn´ees seront alors port´ees par l’utilisateur U et/ou ses appareils T

(Smartphone, PC, . . . ) vus comme des sources d’al´ea n´ecessaire `a la g´en´eration du

secret sk. Cette d´emarche correspond au domaine du fingerprinting pour lequel des

´etudes formelles ont ´et´e propos´ees en 2010 et en 2016 respectivement dans le cas des

navigateurs [110] et des smartphones [111]. Dans le cas des empreintes biom´etriques

physiologiques classiques, deux faits sont commun´ement admis :

• chaque utilisateur peut ˆetre identifi´e uniquement par sa valeur d’empreinte (e.g.

empreinte digitale) ;

• les variations dans l’acquisition de tels signaux empˆechent l’utilisation de techniques

classiques (fonction de hachage, chiffrement) dans leur exploitation.

Les choses sont un peu diff´erentes dans le cas des empreintes de navigateur et d’appareils :

c’est l’accumulation de valeurs de plusieurs champs caract´eristiques (e.g. liste des plugins,

user agent, syst`eme d’exploitation) qui constituera une empreinte de navigateur [113,114].

Chaque champ apporte de l’information mais pas suffisamment pour identifier uniquement

un utilisateur ; on parle d’identification partielle. Certains travaux [115] proposent

alors d’appliquer une fonction de hachage sur l’ensemble de ces valeurs pour obtenir

un identifiant secret relatif `a un profil. Dans toute la suite de ce manuscrit, chaque

champ apportant de l’information sur un utilisateur sera d´efini comme un attribut : la

liste des plugins, le user agent, le syst`eme d’exploitation, num´ero de SIM sont autant

d’attributs permettant d’identifier partiellement des utilisateurs. Anticipant l’´emergence

dufingerprinting, la solution TA proposait d’appliquer un KDF `a de telles donn´ees pour

g´en´erer le secret sk. Avec une limitation cependant : les valeurs consid´er´ees ne doivent

souffrir d’aucune variation puisqu’une modification d’un seul champ modifierait alors la

valeur du secret retourn´e.

Pour r´esumer, l’id´ee g´en´erale de TA est donc la suivante : U muni de T doit ˆetre

capable de g´en´erer et re-g´en´erer `a la demande un secretskn´ecessaire `a son authentification

comme illustr´e par la Figure 2.1. Cette g´en´eration de secret pourra tirer profit de ses

diff´erents attributs.

Afin d’assurer la s´ecurit´e du secret g´en´er´e, l’agr´egation d’un certain nombre d’attributs

constituant un profil utilisateur pourra ˆetre r´ealis´ee.

2.3.2 Profil utilisateur

L’IMEI (pour International Mobile Equipment Identity) est un attribut tel que d´efini

ci-dessus. Compos´e de 15 digits dont 14 al´eatoirement choisis, il permet d’identifier de

mani`ere unique chacun des terminaux de t´el´ephonie mobile et r´epond donc au facteur

de possession FA-2 (D´efinition 43). Cet attribut donne acc`es `a 14 × log2(10) ≈ 47

bits d’entropie ; ce sera l’un des attributs portant le plus d’attributs mais ce sera bien

´evidemment trop peu d’un point de vue cryptographique.

L’id´ee est donc de consid´erer un profil utilisateur, not´e Ω, qui consistera en l’ensemble

des valeurs d’attributs r´ecolt´es par l’application logicielle App. Un exemple de profil

utilisateur tel que d´efini au stade TA1 est repr´esent´e en Figure 2.2.

Attributatti Valeurωi

IMEI 354784054129987/02

SIM 208 20 1134567890

Connecteur USB micro USB

D´efinition ´ecran 720×1280

Debogueur Android Debug Bridge (ADB)

Hash de la librairie OpenSSL 8e52d5cb. . . 20afb443

Mode root oui / non

Nom du t´el´ephone T´el´ephone de Bob

WiFi activ´e oui / non

Hash de l’applicationApp 0d04bfeb. . . 34c9984d

Figure 2.2: Profil Utilisateur au stade TA1

Renseign´e par une politique, un module d´edi´e de la solution TA aura pour but de

collecter le profil Ω en s’assurant que la nature des attributs consid´er´es permettra de

r´ealiser une authentification TA (D´efinition 44). Le cadre de nos travaux consistera `a

en extraire un secret stable sk pour permettre de r´ealiser cette authentification. D’autre

part, pour assurer un certain niveau de s´ecurit´e, un profil utilisateur devra porter assez

d’entropie afin de g´en´erer une cl´eskde longueur suffisante [112]. Alors que cette estimation

est plutˆot directe dans le cas d’attributs comme ceux sp´ecifi´es par la Figure 2.2, nous

verrons au Chapitre 3 que certains sont plus difficiles `a ´evaluer ; nous verrons que cette

´evaluation fera l’objet d’´etudes futures pour permettre l’accession au stade TA3-Ind.

2.3.3 Premi`ere solution

L’objectif O4 requiert que l’utilisateur soit capable, `a partir de son profil Ω, de g´en´erer

un secretsklors de chaque session d’authentification. Notons Ω = (w₁, . . . , wn), o`uwi est

la valeur de l’attributatti,saltune graine publique,KDFun KDF et(authGen, authProve,

authVerif) un protocole d’authentification tel qu’introduit `a la Figure 2.1. Les primitives

d’enrˆolement et d’authentification de la solution TA1 peuvent ˆetre respectivement d´ecrits

`a travers les Figures 2.3 et 2.4.

Entr´ee : Un profil Ω = (w1, w2, . . . , wn).

1. Le serveurS envoie un challengec`a l’utilisateurU.

2. L’utilisateur U cr´ee une identit´e publique `a partir de son

profil Ω :

• Il calculesk=KDF(w1,kw2k. . .kwnksalt).

• Il g´en`ere sa cl´e publiquepk←authGen(sk)

• Il g´en`ere un preuveπ=authProve(sk,pk;c).

3. U envoie (pk, π) au serveurS.

4. S v´erifie queauthVerif(π,pk) = 1 et associepketsalt`aU.

Il abandonne sinon.

Figure 2.3: Enrˆolement de U via Ω au stade TA1

`A la fin de l’enrˆolement, le serveur d’authentification a alors associ´e l’identit´e publique

pk `a l’utilisateur U. Lors d’une authentification future, ce dernier devra alors prouver

la connaissance du secret associ´e sk pour convaincre de son identit´e. Ne disposant

d’aucune capacit´e de stockage s´ecuris´e, il n’est pas dans son int´erˆet de conserver ce secret

sur son terminal T. Ainsi, lorsque U souhaite s’authentifier, son application App va

collecter son profil Ω0 = (w⁰₁, w₂⁰, . . . , wn) o`u⁰ w_i⁰ consiste en la valeur de att_i au moment

de l’authentification. U suit alors la proc´edure d´ecrite dans la Figure 2.4 pour tenter

reconstruire le secret sk.

Contrairement `a la session d’enrˆolement, l’utilisateur U n’envoie paspk⁰ au serveurS.

En fait si Ω0 est correct (i.e. ´egal `a Ω), la consistance est ´evidente. Cela entraine que

sk⁰ =sk et par cons´equent pk=pk⁰. Finalement, on obtient :

authVerif(π⁰,pk) = authVerif(authProve(sk⁰,pk⁰;c⁰) =authVerif(authProve(sk,pk;c⁰),pk) = 1.

Est-ce une authentification TA ? En supposant que les profils d’authentification Ω0

et Ω soient ´egaux en tout point, alors un utilisateur est capable de reconstruire le mˆeme

sket donc de s’authentifier. Au vu du profil utilisateur (Figure 2.2), les objectifs O2 et O3

(D´efinition 44) sont clairement r´ealis´es alors que l’objectif O1 n’est pas atteint a priori.

Pour ce faire, il est n´ecessaire au stade TA1 de recourir `a une interaction avec l’utilisateur

Entr´ee : Un profil Ω0= (w⁰₁, w⁰₂, . . . , w⁰n).

1. Senvoie un challengec0etsalt`aU.

2. Udoit re-g´en´ererskpour prouver sa connaissance du secret

associ´e `apk

• Il calculesk⁰=KDF(w0

1,kw0

2k. . .kw0

nksalt).

• Il g´en`erepk⁰←authGen(sk⁰).

• Il g´en`ereπ⁰=authProve(sk,pk;c⁰).

3. Il envoieπau serveurS.

4. Sa v´erifie que authVerif(π⁰,pk) = 1. Il rejette

l’authentification sinon.

Figure 2.4: Authentification de U via Ω aux stade TA1

qui doit alors taper son mot de passe, ce qui constitue une une premi`ere limitation au

stade TA1. Cette limitation est renforc´ee par la tendance actuelle `a se passer de solutions

d’authentification bas´ees sur l’usage de mots de passe `a l’image de ce que promeut le

consortium FIDO constitu´e de g´eants du domaine (Google, Qualcomm, Discover Financial

Services, Visa Inc, Mastercard, . . . ) [116, 117]. On notera L0 la limitation qui contraint

l’utilisateur `a une interaction du type mot de passe.

2.4 Vue d’ensemble de la solution TA et diff´erents

Dans le document Protocoles cryptographiques pour l’authentification numérique et le respect de la vie privée (Page 74-78)