Les contours du projet Trusted Authentication (TA)

Dans un premier temps, nous r´esumons l’appel `a projet formul´e par la SG avant de

rappeler certaines notions ou d´efinitions inh´erentes aux solutions d’authentification selon

equensWorldline. Finalement, nous ´etablirons de nouvelles d´efinitions propres `a la

philosophie du projet TA.

2.2.1 Description de l’appel `a projet de la SG

Le projet TA est la r´eponse `a un appel `a projet lanc´e par la Soci´et´e G´en´erale (SG)

en 2008, client historique d’equensWorldline : l’objectif est de fournir une solution

exclusivement logicielle d’authentification forte d’un utilisateur U sur son smartphone.

Par extension, nous consid´erons authentification de U `a travers T, l’ensemble de ses

terminaux possiblement r´eduit `a un smartphone seul. Le terme exclusivement logiciel

sous-entend que la s´ecurit´e du paiement par t´el´ephone ne pourra pas reposer sur

un ´el´ement (mat´eriel) s´ecuris´e (de type carte SIM) [101]. Puisque l’utilisation d’une

carte SIM en tant qu’´el´ement s´ecuris´e sur le smartphone sous-entend la coop´eration de

l’op´erateur t´el´ephonique concern´e, elle implique un certain prix dont les banques cherchent

`a s’affranchir. En ce sens, le projet TA a alors permis d’anticiper l’´emergence de la

technologie HCE rappel´ee ci-dessus.

En plus des pratiques induites par le contexte industriel rappel´e en Section 2.1, le

produit TA r´epondra principalement aux objectifs et contraintes de l’appel `a projet dont

un r´esum´e pourrait ˆetre :

• OP. l’objectif principal (OP) est de r´ealiser une solution d’authentification forte ;

• C1. La premi`ere contrainte (C1) est de proposer une solution n’impliquant aucune

tierce partie donc en particulier permettant de s’affranchir de l’usage de la SIM. La

solution sera donc potentiellement ex´ecut´ee en milieu hostile ; la solution propos´ee

Clients de TA La r´eponse d’equensWorldline, d´ecrite dans la suite de cette section, a

´et´e vendue `a de nombreux clients dont une liste non exhaustive pourrait ˆetre la suivante :

Soci´et´e G´en´erale, BNP Paribas, Cr´edit Agricole, Cr´edit du Nord, Bancontact Mistercash

(BCMC), BforBank, AXA Banque, Postbank, Visa.

Dans toute la suite, nous nous r´ef´erons au cas d’usage d´ecrit ci-dessus o`u une

application logicielle App permet l’authentification forte d’un utilisateur U muni de son

smartphone -voire de l’ensemble de ses terminaux- d´enot´e(s) T.

2.2.2 Authentification forte

Dans cette sous-section, nous d´efinissons certains concepts sur lesquels nous allons

nous appuyer tout au long de ce manuscrit. Nous commen¸cons par une d´efinition

de l’authentification forte pour ensuite d´efinir de mani`ere g´en´erique un protocole

d’authentification selon equensWorldline par la Figure 2.1.

Bien qu’il ne soit pas ais´e de trouver une d´efinition arrˆet´ee et formelle de

l’authentification forte, il est commun´ement admis qu’une session d’authentification forte

est une session qui s’appuie sur plusieurs facteurs d’authentification que l’ANSSI semble

d´efinir selon quatre cat´egories [107]: ce qu l’on sait, ce que l’on a, ce que l’on est et ce que

l’on sait faire. Un facteur d’authentification permet de classifier une information fournie

par un utilisateur pour s’authentifier (e.g. le mot de passe est un facteur de connaissance).

Nous proposons alors la d´efinition suivante.

D´efinition 43 (Authentification forte). On appelle une authentification forte une session

d’authentification au cours de laquelle l’utilisateur s’authentifie en prouvant la validit´e

d’au moins, deux facteurs d’authentification (FA) parmi les suivants :

FA-1 Ce que l’on sait (e.g. un mot de passe) ;

FA-2 Ce que l’on a (e.g. une carte `a puce) ;

FA-3 Ce que l’on est (e.g. une empreinte digitale), ou autrement dit biom´etrie

physiologique;

FA-4 Ce que l’on fait/sait faire/peut faire (e.g. une signature manuscrite), ou autrement

dit le comportement utilisateur.

Nous d´efinissons volontairement le facteur FA-4 de mani`ere plus globale que l’ANSSI

afin de ne pas l’assimiler `a de la biom´etrie comportementale pure. En effet, nous verrons

que le comportement de l’utilisateur transparaˆıtra `a travers l’usage qu’il fera de ses

terminauxT, de type smartphone. Usuellement restreint `a la biom´etrie comportementale

classique (e.g. signature, d´emarche, voix), nous ´etendrons alors le facteur FA-4 `a certaines

valeurs caract´eristiques d’un comportement sur T (e.g. liste des application install´ees,

pr´ef´erences utilisateurs). Ces donn´ees sont de plus en plus ´etudi´ees pour identifier et

traquer les utilisateurs sur l’internet via les domaines des empreintes de navigateurs et

d’appareils (browser fingerprinting [110] et device fingerprinting [111]).

Exemple 1. Une m´ethode d’authentification forte tr`es r´epandue `a l’heure actuelle est

celle le r´esultat de la norme 3-D Secure Entrer sur son navigateur web l’OTP (One

Time Password) re¸cu sur son t´el´ephone -non n´ecessairement un smartphone- assure

la possession dudit t´el´ephone (FA-2) tandis que la possibilit´e de l’utiliser assure la

connaissance du PIN associ´e (FA-1).

2.2.3 R´eponse d’equensWorldline `a l’appel `a projet

La solution propos´ee par equensWorldline consiste en une session d’authentification telle

que d´ecrite `a la Figure 2.1.

Protocole g´en´erique d’authentification

Nous consid´erons ici le cas d’une authentification unidirectionnelle au cours de

laquelle un serveur equensWorldline v´erifie l’identit´e d’un utilisateur. On suppose que

l’utilisateur s’adresse effectivement au serveur par une v´erification classique de certificats

cryptographiques. Alors que diff´erentes m´ethodes d’authentification (Proof of Knowlegde,

Signature) ont ´et´e explicit´ees dans le premier chapitre (partie 1.3.3), nous pr´esentons le

fonctionnement g´en´erique d’un protocole d’authentification dans le paradigme TA, d´efini

par le triplet d’algorithmes (authGen, authProve, authVerif).

1. authGen(sk) g´en`ere un cl´e publiquepkassoci´ee au secretsk

pr´ealablement enrˆol´e.

2. authProve(sk,pk;µ) g´en`ereπune preuve quepkest issue de

sk.

3. authVerif(π,pk) retourne 1 siπ a bien ´et´e g´en´er´ee `a partir

du secretskassoci´ee `apk; 0 sinon.

4. La propri´et´e de s´ecurit´e repose sur deux points :

• retrouver le secretsk `a partir des donn´ees publiques

(dontpk) est un probl`eme difficile.

• les preuves g´en´er´ees πis ne sont pas rejouables ni

utilisables pour s’authentifier au nom de l’utilisateur

l´egitime.

Figure 2.1: Description informelle d’une authentification TA

fonction du contexte, une authentification TA pourra ˆetre mise en œuvre par l’utilisation

de Proof of Knowledge ou encore de signature num´erique. Dans le contexte TA, aucun

moyen de stockage s´ecuris´e n’est mis `a disposition de l’utilisateur ; ce sont donc la

g´en´eration et la gestion du secret sk qui seront les ´etapes critiques au regard de la

contrainte C1. D’autre part, afin d’assurer une authentification forte, la g´en´eration

dudit secret sk devra ´egalement faire la preuve de l’implication de diff´erents facteurs

d’authentification.

Nouveaux objectifs et nouvelles contraintes

Du fait de la contrainte C1 relativement forte, equensWorldline a propos´e une solution

s’appuyant sur le plus de facteurs de confiance possible. La philosophie de la solution est

donc la suivante : l’utilisateur U devra ˆetre capable de prouver simultan´ement qu’il est

le bon utilisateur U utilisant le bon smartphone (resp. ensemble de terminaux) T par

usage de la bonne application logicielle App. Reprenant la Figure 2.1, l’utilisateur devra

prouver la connaissance d’un secret qui est propre `a son identit´e publique et assurant ces

diff´erents objectifs. Worldline a donc propos´e la solution Trusted Authentication (TA)

pour laquelle une session d’authentification devra satisfaire la d´efinition suivante.

D´efinition 44. En consid´erant un utilisateur U muni des terminaux T o`u est install´ee

l’application logicielleApp, une authentification TA est une session d’authentification telle

que d´efinie par la Figure 2.1 r´epondant aux objectifs suivants :

O1 Authentifier l’utilisateur.

O2 Authentifier ses terminaux.

O3 Authentifier son application logicielle App.

O4 Prouver la connaissance d’un secret valide assurant que O1, O2 et O3 sont

conjointement remplis.

Une authentification TA est une session d’authentification satisfaisant O4.

Remarque 1. Une authentification TA est n´ecessairement une authentification forte.

Par la contrainte C1, T ne dispose pas d’´el´ement s´ecuris´e ; la manipulation de donn´ees

sensibles devra alors ˆetre minimis´ee. En particulier, il sera dangereux d’y stocker sk

pour de futures sessions d’authentification. Ce secret devra alors ˆetre (re-)g´en´er´e quand

n´ecessaire c’est-`a-dire lors des phases d’enrˆolement et d’authentification.

Contrainte de la vie priv´ee En plus de la contrainte C1 ´etablie par la SG, l’´Etat, la

CNIL notamment [109] impose le respect de la vie priv´ee des utilisateurs. D’autre part,

les clients et le grand public y sont de plus en plus sensibilis´es. Nous d´efinissons alors la

contrainte C2 qui sera trait´ee en filigrane tout au long de ce manuscrit :

C2. Vie priv´ee. equensWorldline ne doit pas pouvoir manipuler des donn´ees

utilisateurs consid´er´ees comme priv´ees. Seule l’application App d´eploy´ee en local

sur T en est capable. Ainsi, l’application App doit assurer un service personnalis´e

sans qu’equensWorldline n’apprenne rien de cette personnalisation.

Mise en perspective A travers les exemples 2 et 3, nous exhibons ce que la solution

TA ne pourra pas ˆetre `a la vue des contraintes C1 et C2.

Exemple 2. Supposons qu’il soit possible de munir l’utilisateur final d’un ´el´ement

s´ecuris´e, e.g. une carte `a puce. Alors, il suffirait d’y stocker une cl´e cryptographique.

´

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.

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