Introduction aux mod`eles de s´ecurit´e

En pratique, les diff´erents audits pass´es par equensWorldline (PCI, Visa, Mastercard,. . . )

s’attachent `a v´erifier les bons usages de la cryptographie classique (mod`ele en boˆıte noire)

et s´ecuritaire (mod`ele en boˆıte blanche). Jusqu’au d´ebut des ann´ees 90, les sch´emas

cryptographiques propos´es respectaient le traditionnel mod`ele en boˆıte noire pour lequel

les plateformes ex´ecutant les calculs ´etaient suppos´ees s´ecuris´ees. Un adversaire n’avait

alors acc`es qu’aux entr´ees sorties d’un syst`eme mais pas `a son ´etat interne [118]. Les

travaux de P. Kocher [119] ont exhib´e les limitations de telles consid´erations puisqu’un

adversaire aura potentiellement acc`es `a des informations que laissent fuiter des dispositifs

physiques. ´Etendant ces consid´erations, la cryptographie en boˆıte blanche a ´et´e introduite

en 2003 par Chow et al. [120]. Le domaine de la cryptographie en boˆıte blanche peut se

voir comme un cas particulier du domaine de l’obfuscation de programme [121] dont

les consid´erations restent th´eoriques et ´eloign´ees de consid´erations pratiques [122, 123].

Cependant, contrairement `a l’obfuscation de programme, la cryptographie en boˆıte

blanche n’a pas pour objectif – mˆeme si cela peut en ˆetre une cons´equence– de rendre

inintelligible un programme mais seulement s’assurer que les cl´es secr`etes sont inaccessibles

`a un attaquant logiciel [124]. D’autre part, les tentatives d’impl´ementations dans le mod`ele

en boˆıte blanches ont ´et´e cass´ees [125, 124] de sorte que d’un point de vue industriel, les

solutions sont g´en´eralement prot´eg´ees par des impl´ementations ad hoc.

Ainsi, equensWorldline consid`ere deux mod`eles de s´ecurit´e dans sa conception de

logiciels, :

• Mod`ele Blackbox. Mod`ele de s´ecurit´e classiquement d´epeint d’un point de vue

cryptographique : l’attaquantApeut voir les ´echanges entre l’utilisateurU utilisant

Appinstall´ee surT et un serveur d’authentification. Aaura acc`es `a certains oracles

lui permettant de simuler cette vue ;

• Mod`ele Whitebox. Par le requis R1, notre solution doit ˆetre logiciellement

prot´eg´ee. Dans ce mod`ele, un attaquant whitebox A0 peut se voir comme un

attaquant logiciel qui a potentiellement acc`es `a ”tout ce qui se passe” sur les

terminauxT de l’utilisateurU. Plus pr´ecis´ement, toute donn´ee charg´ee en m´emoire

(e.g. cl´e ou profil utilisateur) par T est accessible `a A0.

2.5.1 Mod`ele en boˆıte blanche

Pr´ecisions sur la cryptographie en boˆıte blanche

Comme la cryptographie en boˆıte noire, la cryptographie en boˆıte blanche est un domaine

`a part enti`ere de la cryptographie. Cependant, les techniques propos´ees dans la litt´erature

sont soit cass´ees [125,124] ou pas (encore) applicables au monde industriel [121,122,123].

Ainsi, nous proc´edons aux pr´ecisions suivantes :

• le mod`ele en boˆıte blanche est commun `a la cryptographie acad´emique et aux

probl´ematiques industrielles et jouit de mod`eles proches [118] ;

• les solutions de la litt´erature ne sont pas utilisables dans le monde industriel ;

• des impl´ementations d’algorithmes cryptographiques adapt´ees aux contraintes

industrielles et r´epondant aux contraintes du mod`ele en boˆıte blanche existent ;

elles sont commercialis´ees sous le nom de whiteboxes.

Ces whiteboxes constituent des impl´ementationsad hoc pour lesquelles les principes de

Kerckhoffs [21] ne s’appliquent pas. En effet, lors des audits notamment, la consistance

des algorithmes est v´erifi´ee sans qu’aucune sp´ecification sur leur fonctionnement interne

ne soit requise.

Description du mod`ele en boˆıte blanche

Un attaquant logicielA0 a potentiellement acc`es `a toutes les donn´ees charg´ees en m´emoire

et pourra mˆeme en modifier certaines. Par exemple, il pourra acc´eder `a la valeur d’un

attribut. L’accession/modification d’une valeur d’un programme s’appelle un exploit.

Comme son nom l’indique, un exploit n’est pas simple `a r´ealiser et l’accession par A0 `a

un attribut n’implique pas que tous les autres attributs seront menac´es. Par exemple,

en contournant les d´efenses du module IDE, l’attaquant A0 pourra acc´eder `a une libraire

sans pour autant ˆetre capable d’apprendre d’autres attributs. Ainsi la r´ealisation d’un

exploit, bien que pr´eoccupante, n’impliquera pas n´ecessairement la fin de vie d’un profil

utilisateur. Dans les faits, il est peu probable qu’un attaquant ait acc`es `a de nombreux

attributs sans que l’application App ne s’en aper¸coive et ne lance des contre-mesures

adapt´ees via le module IDE notamment.

Aujourd’hui, le foss´e entre th´eorie et pratique est encore trop important -d’un point de

vue des temps de calcul- pour appliquer des solutions acad´emiques au monde industriel.

Ce sont donc sont des solutionsad hocqui sont utilis´ees. equensWorldline ach`ete de telles

solutions `a une soci´et´e priv´ee Soc, qui permettent de ”whiteboxer” certains algorithmes.

Plus pr´ecis´ement, ´etant donn´e un algorithme cryptographique standard s´ecuris´e du point

de vue deA, la solution fournie parSocpermet de le transformer en un algorithme s´ecuris´e

du point de vue de A0. Ainsi, quiconque pourra constater la consistance de l’algorithme

mais comprendre ou d´eduire des informations sur son fonctionnement logiciel revient `a en

casser la s´ecurit´e.

2.5.2 Mod`ele en boˆıte noire

Comme pr´esent´e `a travers la Figure 2.5, la mise en œvre de diff´erents SDKs permet

l’articulation de l’application App. Le cœur des travaux pr´esent´es au prochain chapitre

concerne la g´en´eration de cl´es cryptographiques `a partir d’attributs utilisateurs. Cette

tˆache sera effectu´ee par le module FAST, int´egr´e au CryptoCore. Avant de la formaliser

au cours du prochain chapitre, nous consid´erons que la s´ecurit´e de FAST devra r´esister `a

un attaquant A de type blackbox ayant acc`es `a :

1. `a ce que l’application App prend en entr´ee : des donn´ees publiques relatives `a

l’utilisateurU. En revanche, le profil Ω, source de la g´en´eration de la cl´e sk n’a pas

vocation `a ˆetre divulgu´e ;

2. `a ce que l’application retourne : des param`etres publics li´es `a l’utilisateur et une

preuve de connaissance de la cl´esk. Parmi ces param`etres publics, certains d´enot´es

1. prend en entr´ee un profil utilisateur Ω (voir Figure 2.2) et des donn´ees publiques ;

ce profil (secret) est renseign´e par le SDK TA tandis qu’il est prot´eg´e par le module

IDE et des whiteboxes ;

2. g´en`ere un secret cryptographique sk, lui aussi prot´eg´e par les mˆemes outils et une

donn´ee publique hd transmise au serveur d’authentification ;

3. re-g´en`ere ledit secret cryptographique sk en s’appuyant sur hd;

Que ce soit par le jeu des mises `a jour ou par l’utilisation d’un framework autre que la

solution TA, le module FAST sera amen´e `a g´en´erer plusieurs fois des cl´es cryptographiques

pour un mˆeme utilisateur. De ce fait, de nombreuses donn´ees publiqueshds seront g´en´er´ees

et certaines cl´es pourraient ˆetre attaqu´ees par des exploits de A0 ou plus simplement par

des failles de s´ecurit´e d’applications autres que TA utilisant FAST.

Ainsi, le mod`ele de s´ecurit´e associ´e, formalis´e au prochain chapitre, requiert que ni

les publications des donn´ees auxiliaireshds ni d’´eventuelles corruptions de cl´es secr`etessk

issues d’un mˆeme profil n’impacte pas la s´ecurit´e dudit profil et des secrets non corrompus.

Un r´esum´e de la situation est propos´e en Figure 2.7.

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´eeshd^js sont publiques.

Certains secretsskjs peuvent ˆetre corrompus,

sans que la s´ecurit´e des autres

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

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

M´ethodologie

Pour qu’une solution propos´ee satisfasse `a ces deux mod`eles de s´ecurit´e en mˆeme temps,

la m´ethodologie adopt´ee par equensWorldline est la suivante :

1. Proposer une application Apps´ecuris´ee vis `a vis de l’attaquant A.

2. Utiliser les solutions ad hoc fournies par Soc pour le rendre r´esistant `a l’attaquant

A0.

Dans la suite e ce manuscrit, nous nous focaliserons donc sur la proposition de solution

r´esistantes `a l’attaquant A

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