Evaluation d'applications de paiement sur carte à puce

HAL Id: tel-01419220

https://hal.archives-ouvertes.fr/tel-01419220

Submitted on 19 Dec 2016

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Evaluation d’applications de paiement sur carte à puce

Germain Jolly

To cite this version:

Germain Jolly. Evaluation d’applications de paiement sur carte à puce. Cryptographie et sécurité [cs.CR]. Normandie Université, France, 2016. Français. �tel-01419220�

THESE

Pour obtenir le diplôme de doctorat

Spécialité4200040

Préparée au sein de « Université de Caen / ENSICAEN »

Evaluation d’applications de paiement sur carte à puce

Présentée et soutenue par

Germain JOLLY

Thèse dirigée par Christophe ROSENBERGER, laboratoire GREYC Thèse soutenue publiquement le 08 Juillet 2016

devant le jury composé de

M. Benjamin NGUYEN Professeur à l’INSA centre Val de Loire Rapporteur M. Lionel BRIAND Professeur à l’université de Luxembourg Rapporteur M. Pierre PARADINAS Professeur au CNAM Paris Examinateur M. Christophe DOLABDJIAN Professeur à l’Université de Caen

Normandie Examinateur

M. Sylvain VERNOIS Ingénieur de recherche ENSICAEN Co-encadrant M. Christophe ROSENBERGER Professeur à l’ENSICAEN Directeur de thèse

Remerciements

Je tiens `a remercier en vers de douze pieds Toutes ces personnes avec qui j’ai ´echang´e, Sans qui je n’aurai pas pu cr´eer au fil des ann´ees.

Je tente de r´esumer en quelques vers, ces ann´ees Sous la forme d’un sonnet, peut ˆetre un peu l´eger, Avec lequel j’esp`ere ne pas vous assommer :

————————————————————————

Cette aventure prend fin, apr`es tant de questions, Tant de p´erip´eties mais tant de d´ecouvertes,

Et tournant ainsi la page d’une p´eriode experte De recherche, d’enseignement et de transmission.

Cette th`ese s’ach`eve, grˆace `a l’´ecoute et au soutien De ma direction et de mon ´equipe enti`ere,

Et m’ayant ainsi permis d’apporter ma pierre A l’´edifice du savoir, pour le bien des miens.

Je d´edie cette ´etude, fabuleuse exp´erience, D´esirant partager et faire avancer la science,

A toutes les personnes qui m’ont tant ´eveill´e.

A tout ces bons instants pass´es dans cette ville, A tout ce que je dois `a mes parents, ma famille,

Aux coll`egues et amis qui m’ont tant partag´e.

R´

esum´

e

Le sujet s’intitule : ”Evaluation d’applications de paiement sur carte `a puce.”

Cette th`ese traite des m´ethodes d’´evaluation de haut niveau, proche des applica-tions. Une m´ethode d’´evaluation d’application sur cartes `a puces, compl´ementaire aux m´ethodes existantes, a ´et´e d´efinie durant de la th`ese. La m´ethode sur laquelle je travaille est une m´ethode qui mˆele observation de la communication et d´etection de violation de propri´et´es. Le but est de d´etecter les anomalies pr´esentes sur cartes `a puce (et plus pr´ecisemment sur l’application de la carte `a puce) et de fournir une do-cumentation accrue sur cette erreur ainsi que les raisons d´eclencheurs de cette erreur. Avec l’utilisation de propri´et´es, nous ne stressons pas l’application et nous n’avons pas la difficult´e de devoir ordonner les tests pour constituer les suites de tests. Nous allons donc savoir `a la vol´ee si une application poss`ede une erreur d’impl´ementation. L’utilisateur de l’outil va configurer un ensemble de propri´et´es correspondant aux comportements attendus de l’application qu’il va v´erifier, localement ou globalement, durant la phase de test par exemple.

Approches :

La premi`ere approche consiste `a observer l’´evolution de l’application carte par rapport `a la machine d’´etat fournie par les sp´ecifications. Nous observons alors le comportement global de l’application et pouvons d´etecter la pr´esence d’une erreur. La seconde approche consiste `a ´etudier l’´evolution de l’application localement. Un observateur prend en entr´ee une collection de propri´et´es et une communication APDU et nous obtenons en sortie une liste de propri´et´es viol´ees ou non. L’apport de la m´ethode par rapport au test est donc une documentation accrue et une v´erification partielle du comportement sans devoir construire enti`erement le comportement global.

de la th´eorie (sp´ecifications), la premi`ere ´etape est la g´en´eration de l’oracle, ´el´ement de r´ef´erence lors d’une activit´e de v´erification et validation. Dans un premier temps, une approche triviale a ´et´e trait´ee par la g´en´eration de la totalit´e des comportements possibles de l’application. Cependant, nous nous sommes vite orient´es vers une technique plus intelligente permettant de cibler des comportements `a v´erifier plus int´eressants pour notre ´etude. Pour ce faire, nous avons travaill´e sur une m´ethode de g´en´eration bas´ee sur un algorithme g´en´etique prenant en entr´ee un ensemble de logs de transaction qui permet de g´en´erer automatiquement un ensemble de propri´et´es (c’est `a dire un ensemble de comportements locaux et attendus de l’application carte).

R´esultats :

La m´ethode de v´erification est developp´ee grˆace au framework WSCT. Deux plugins ont ´et´e cr´e´es et permettent de communiquer avec l’application carte mais aussi d’observer et d´etecter une anomalie dans le comportement de l’application carte. Nous avons utilis´e une applet JavaCard developp´ee au laboratoire afin de tester la faisabilit´e de la m´ethode. De plus, l’interface graphique a ´et´e travaill´ee afin d’ˆetre accessible et compr´ehensible.

Usages :

Cette m´ethodologie d’´evaluation d’application carte permet une utilisation dans diff´erents contextes :

– lors de la phase de test, la m´ethodologie peut ˆetre utilis´ee en parall`ele de la m´ethode utilis´ee par l’entreprise de certification (par exemple, du test) afin d’obtenir plus d’informations concernant une anomalie et avoir un rapport d’´evaluation de meilleure qualit´e (plus complet et plus sˆur) ;

– lors du d´eveloppement de l’application, l’utilisation de cette m´ethodologie permet un guidage du d´eveloppement. On peut ainsi l’utiliser dans le cadre d’un enseignement du d´eveloppement JavaCard par un enseignant. Cet outil permet alors de traiter le d´eveloppement JavaCard, la s´ecurit´e des applications carte mais aussi leur conformit´e vis `a vis des sp´ecifications.

mots cl´es : Validation, carte `a puce, ´evaluation, s´ecurit´e, javacard, propri´et´es temporelles, observation, d´etection, g´en´eration.

Summary

This thesis is entitled : ”Evaluation of payment applications on smart cards.”

This thesis deals with high-level evaluation of applications in smartcards. An evaluation method of applications on smart card, complementary to existing methods, was defined during this PhD thesis. The proposed method combines observation of the communication and detection of properties’ violation. The goal is to detect anomalies on smart cards (and more precisely on its implementation) and provide a better documentation on this error and on the reasons that triggered this error. With the use of properties, we do not put application under stress and also we do not have the difficulty of ordering the tests to establish the test suites. We can know on the fly if an application has an error of implementation. The user of the tool configures a set of properties corresponding to the expected behavior of the application will check, locally or globally, during the test phase for example.

Approaches :

The first approach is to observe the evolution of the application from the state machine provided by the specification. We then verify the global behavior of the appli-cation and can detect the presence of an error. The second approach is to study locally the evolution of the application. An observer takes as input a collection of properties and APDU communications and we get as output a list of violated properties. The contribution of the method compared to the test is a increased documentation and the verification of a partial behavior without having to fully build the global behavior.

Generation of the oracle

To ascertain compliance of the behavior of the card application with the theory (specifications), the first step is the generation of the oracle, reference used during

directed to a smarter technique to target the most interesting behaviors to check for our study. To do this, we worked on a generation method based on a genetic algorithm taking as input a set of transaction logs to automatically generate a set of properties (i.e. a set of local and expected behaviors of the applications).

Results :

The evaluation methodology is developped through the WSCT framework. Two plugins were created and used to communicate with the smart card application, but also to observe and detect an abnormality in the behavior of the application. We used a JavaCard applet developped in the laboratory to test the feasibility of the method. In addition, the GUI has been worked to be accessible and understandable.

Use cases :

This methodology can be used in different contexts :

– During the test phase, the methodology can be used in parallel by the certifi-cation firm (e.g., testing) to obtain more information about an anomaly and have a better report of the evaluation (more complete and more precise) ; – During the development of the application, the use of this methodology allows

to guide the development. It can also be used as part of a JavaCard development teaching with an interdisciplinary approach (dealing with development, security and evaluation during the life cycle of a smart card).

Keywords : Validation, Smart card, Evaluation, Safety, Javacard, Temporal properties, Observation, Detection, Oracle.

Table des mati`

eres

Introduction 1

1 Positionnement du probl`eme 5

1.1 Contexte de l’´etude . . . 6

1.1.1 Une transaction ´electronique . . . 6

1.1.2 La mon´etique . . . 6

1.1.3 Les sp´ecifications et certifications . . . 8

1.2 La s´ecurit´e des applications sur carte . . . 9

1.2.1 El´ement s´ecuris´e . . . 9

1.2.2 Norme ISO/IEC 7816 . . . 11

1.2.3 Communication PC/SC : . . . 13

1.2.4 Les sp´ecifications EMV . . . 13

1.2.5 Sp´ecifications propri´etaires . . . 16

1.2.6 JavaCard . . . 17

1.2.7 GlobalPlatform . . . 17

1.2.8 Discussion . . . 18

1.3 Attaques sur une transaction de paiement . . . 19

1.3.1 Attaques invasives ou semi-invasives : . . . 19

1.3.2 Attaques non invasives . . . 20

1.3.3 Transactions sans contact . . . 22

1.3.4 R´ecapitulatif : . . . 22

1.4 Evaluation d’applications . . . 24

1.4.1 Introduction . . . 24

1.4.2 D´efinitions . . . 24

1.4.3 Le cas du logiciel . . . 27

1.4.4 Le cycle de vie de l’application carte . . . 28

1.5 Objectifs de la th`ese . . . 29

1.6 Conclusion . . . 30

2 Une m´ethodologie d’analyse d’applications sur carte `a puce 31 2.1 Introduction . . . 31

2.2 Etat de l’art . . . 32

2.2.1 M´ethodes d’analyse sur carte `a puce . . . 32

2.2.2 Outils d’analyse de la carte `a puce . . . 36

2.2.3 Solutions acad´emiques : outils de d´eveloppement . . . 37

2.2.4 Construction de l’oracle . . . 38

2.2.5 Discussion . . . 38

2.3 Repr´esentation de l’application et de son comportement . . . 41

2.3.1 Introduction . . . 41

2.3.2 D´efinition . . . 41

2.3.3 El´ements de base . . . 42

2.3.4 Repr´esenter le comportement global . . . 43

2.3.5 Repr´esenter le comportement local . . . 43

2.3.6 Mod`ele de repr´esentation . . . 43

2.4 Observation de comportements globaux et locaux d’une application . 45 2.4.1 Contexte . . . 45

2.4.2 Inspirations . . . 45

2.4.3 Analyse temporelle sur la communication APDU . . . 46

2.4.4 D´etection d’anomalie grˆace `a l’observation de la communication 47 2.5 Analyse par la d´etection de violation de propri´et´e . . . 50

2.5.1 Introduction . . . 50

2.5.2 D´efinition de propri´et´e . . . 50

2.5.3 D´etection de violation . . . 52

2.6 Illustrations de la m´ethodologie . . . 55

2.6.1 Mise en place de la m´ethodologie . . . 55

2.6.2 Cas 1 : Observation de l’application de paiement EMV . . . . 57

2.6.3 Cas 2 : Analyse d’une application PME . . . 61

2.6.4 Discussion . . . 65

2.7 Conclusion . . . 66

3 De la g´en´eration d’oracle aux usages 67 3.1 Introduction . . . 67

3.2 Etat de l’art . . . 68

3.3 M´ethodes de g´en´eration d’oracle . . . 71

TABLE DES MATI `ERES iii

3.3.2 M´ethode de g´en´eration de laboratoire bas´ee sur la r´etro-ing´enierie et la constitution d’un mod`ele . . . 72

3.3.3 M´ethode de g´en´eration directe et intelligente bas´ee sur la r´ etro-ing´enierie en mode boˆıte noire . . . 73

3.4 Applications d’usage . . . 79

3.4.1 Cas 1 : Outil d’analyse d’une application carte utilisant un terminal externe `a WSCT . . . 79

3.4.2 Cas 2 : Utilisation pour l’enseignement du d´eveloppement et de l’´evaluation d’applet JavaCard . . . 82

3.5 Conclusion . . . 89

Conclusions et perspectives 91

Publications de l’auteur 93

Bibliographie 95

Liste des abr´eviations 105

Table des figures 107

Introduction

« Un homme digne de ce nom ne fuit jamais. Fuir, c’est bon pour les robinets. »

Boris Vian

Contexte de r´

ealisation de la th`

ese

Cette th`ese est r´ealis´ee grˆace `a un financement minist´eriel. J’ai effectu´e cette ´etude `a Caen au sein de l’Ecole doctorale Structures, informations, mati`ere et mat´eriaux (SIMEM), et le laboratoire Groupe de recherche en informatique, image, automatique et instrumentation (GREYC) dans l’´equipe Mon´etique et Biom´etrie depuis le 27-09-2012, financ´ee par le Minist`ere de l’Enseignement sup´erieur et de la Recherche (MESR). La s´ecurit´e des transactions s´ecuris´ees fait partie des domaines de recherche de cette ´equipe. Alors que les transactions s´ecuris´ees sont pr´esentes partout dans la vie de tous les jours (transport, paiement, identification), il est n´ecessaire d’´etudier et d’enrichir la s´ecurit´e de ces transactions. Ma th`ese s’intitule ”Evaluation d’applications de paiement sur carte `a puce”.

Motivation

En 1974, un premier brevet est d´epos´e par Roland Moreno concernant un ”proc´ed´e pour la m´emorisation de donn´ees et la commande correspondante de machines ´electroniques”, plus couramment appel´e carte `a puce [1]. Depuis, ce syst`eme a ´et´e largement d´eploy´e et a ´evolu´e, notamment avec l’apparition de standards. Une carte `

a puce est actuellement compos´ee de deux parties : ´electronique et logicielle, chacune responsable de la s´ecurit´e et de la mise en oeuvre des fonctionnalit´es d’usage. C’est en 2004 que les sp´ecifications EMV (Europay Mastercard Visa) sont d´eploy´ees en France,

ayant pour objectif de garantir un haut niveau de s´ecurit´e ainsi que l’int´erop´erabilit´e des syst`emes pour le paiement. Selon EMVCo, le nombre de cartes `a puce EMV utilis´ees dans le monde s’´elevait `a 3,4 milliard en 2015 et ce chiffre augmente encore [2]. Le d´eploiement de masse et la large disponibilit´e impliquent l’apparition de risques s´ecuritaires et donc le besoin pour les fabricants d’avoir une longueur d’avance sur les attaquants. Avant d’ˆetre utilis´ee dans la vie de tous les jours, une carte `a puce doit ˆetre v´erifi´ee vis `a vis d’exigences fonctionnelles et s´ecuritaires. Le probl`eme est qu’il est difficile pour une campagne de tests intensifs de retrouver la raison d’une anomalie de fonctionnement. En effet, le d´eclenchement de l’erreur peut ˆetre g´en´er´ee avant la d´etection du dysfonctionnement. Diff´erentes solutions de validation et v´erification d’applications embarqu´ees sur une carte existent d’un point de vue op´erationnel et acad´emique mais la complexit´e des sp´ecifications et les diff´erentes impl´ementations possibles propos´ees par les d´eveloppeurs peuvent ˆetre la source d’erreurs.

Objectifs

Durant le cycle de vie de la carte `a puce, le syst`eme, `a la fois logiciel et mat´eriel, va ˆetre test´e, v´erifi´e et valid´e. Il peut s’agir de techniques de v´erification durant la conception afin d’apporter une aide au prototypage, durant la phase de certification afin de garantir le respect fonctionnel ou encore durant l’utilisation de la carte dans la vie de tous les jours pour garantir la s´ecurit´e de la transaction `a un utilisateur. Nous verrons par la suite que ces techniques peuvent ˆetre caract´eris´ees de m´ethodes dˆıtes de boˆıte blanche (code source connu) ou boˆıte noire (aucune connaissance hormis les entr´ees `a fournir). Dans cette th`ese, nous nous concentrons sur la communication entre la carte `a puce et le terminal et nous adoptons alors une analyse en boˆıte noire permettant de d´etecter et d’analyser des failles fonctionnelles et s´ecuritaires de l’application carte `a partir de l’observation de cette communication. L’objectif principal est de s’assurer de la validation d’une application de paiement par rapport aux sp´ecifications la d´efinissant et ceci en d´etectant les possibles erreurs d’impl´ e-mentation. L’originalit´e est d’utiliser des outils d’analyse formelle sur une m´ethode de d´etection `a la vol´ee, c’est `a dire que cette m´ethode utilise une communication existante entre un terminal et une carte `a puce, correspondant par exemple `a une transaction nominale ou une transaction de test.

INTRODUCTION 3

Principales contributions de la th`

ese

Cette th`ese se situe dans la probl´ematique de l’´evaluation des applications sur carte `a puce permettant des transactions ´electroniques s´ecuris´ees comme le paiement, la fid´elit´e, le transport ou le contrˆole d’acc`es. Le march´e mondial des cartes `a puces est cons´equent avec plus de 8 milliards de cartes `a puces dans le monde en 2015 [3]. L’enjeu est pour les fournisseurs de proposer des cartes `a puces de qualit´e avec des applications s´ecuris´ees. L’usage de cartes `a puces dans le cadre de transactions s´ecuris´ees fait intervenir de nombreux acteurs directs (´emetteur, porteur, accepteur et acqu´ereur) et indirects (entreprise de certification, laboratoire de test, chercheurs acad´emiques).

Au cours de cette th`ese, nous nous attachons `a bien positionner la probl` ema-tique de l’´evaluation d’applications en termes de m´ethodes de d´etection d’anomalie. Apr`es avoir trait´e l’´etat de l’art des m´ethodes d’analyses d’une application carte, une m´ethodologie est propos´ee pour d´etecter un comportement anormal d’une ap-plication `a partir de la communication entrante et sortante de l’application cible. Nous d´efinissons un langage pour d´efinir les propri´et´es, comportements th´eoriques de l’application cible, d´eveloppons une plateforme d’observation d´evelopp´ee avec le framework WSCT afin de prouver l’efficacit´e de notre m´ethode. L’observation globale permet de savoir si l’application est correcte d’un point de vue fonctionnel. L’observation de comportements locaux nous permet d’avoir une documentation accrue sur la pr´esence d’une anomalie mais aussi sur les raisons qui ont d´eclench´ees cette anomalie. Cette preuve de concept est r´ealis´ee pour une application de paiement mais le principe peut ˆetre appliqu´e `a toute application carte.

Nous traitons dans un second temps, la question de la g´en´eration de l’oracle d’une m´ethode d’´evaluation. Afin de d´etecter un mauvais comportement, il va falloir connaˆıtre tous les comportements possibles d’une application. Nous d´efinissons donc un language permettant de repr´esenter les comportements globaux mais aussi locaux afin de savoir si cette application suit son ´evolution attendue. Nous d´efinissons alors une plateforme de g´en´eration de propri´et´es automatis´ee et optimis´ee par l’usage d’algorithmes g´en´etiques.

Nous avons ensuite r´efl´echi `a l’usage de cette m´ethode `a diff´erentes phases du cycle de vie de la carte `a puce (phase de d´eveloppement, phase de test ou phase d’utilisation). La preuve de concept principale est mise au point sur une application de type Porte Monnaie Electronique (PME), dans un premier temps, dans le contexte

de d´eveloppement et de s´ecurisation de cette application. Dans un second temps, son int´erˆet est illustr´e dans le cadre de l’enseignement du d´eveloppement d’applications JavaCard et de la s´ecurit´e associ´ee.

Nous proposons une approche pragmatique originale au vu de la litt´erature et applicable dans le cadre industriel. C’est pourquoi cette ´etude est pens´ee selon trois axes : l’int´egration dans une plateforme existante, afin de disposer d’un outil d´eployable en milieu industriel, la d´efinition d’un langage de propri´et´es simple pour les non-initi´es et une focalisation sur la souplesse d’utilisation plutˆot que sur la compl´etude formelle.

Organisation du manuscrit

Le manuscrit est organis´e de la fa¸con suivante :

– Le chapitre 2 positionne le contexte en donnant les notions les plus impor-tantes pour appr´ehender les contributions de la th`ese.

– Le chapitre 3 pr´esente la m´ethodologie g´en´erale propos´ee de v´erification d’une application carte vis `a vis d’exigences fonctionnelles et s´ecuritaires. Dans ce chapitre, nous supposons connu l’oracle, c’est `a dire l’ensemble des propri´et´es n´ecessaires `a l’´evaluation d’une application sur carte.

– Le chapitre 4 pr´esente la g´en´eration automatique de l’oracle d’une application carte et diff´erents cas d’usage de la m´ethodologie propos´ee..

Chapitre

1

Positionnement du probl`

eme

Ce chapitre pr´esente les d´efinitions permet d’appr´ehender la probl´ematique ainsi que le p´erim`etre de l’´etude. Suite `a ces rappels, nous d´efinissons clairement les objectifs de cette th`ese.

Sommaire

1.1 Contexte de l’´etude . . . 6

1.2 La s´ecurit´e des applications sur carte . . . 9

1.3 Attaques sur une transaction de paiement . . . 19

1.4 Evaluation d’applications . . . 24

1.5 Objectifs de la th`ese . . . 29

1.6 Conclusion . . . 30

C

ette partie a pour objectif de donner au lecteur les notions les plus importantes pour appr´ehender la probl´ematique de la th`ese. Nous allons donc d´efinir les termes majeurs et introduire les sp´ecifications sur lesquelles est bas´ee l’´etude. Nous d´efinissons le cadre de l’´etude et les enjeux de cette th`ese en consid´erant `a la fois les aspects acad´emiques et industriels. Plus les exigences s´ecuritaires sont importantes, plus les attaques sont ´elabor´ees. Nous verrons `a quels moments du cycle de vie de la carte `a puce et sous quelles formes les processus de s´ecurit´e sont mis en place afin d’obtenir un syst`eme le plus s´ecuris´e possible. Ensuite, nous traitons la question de l’analyse d’applications en vue de la certification du syst`eme.

1.1

Contexte de l’´

etude

1.1.1

Une transaction ´

electronique

Une transaction ´electronique est un ´echange d’informations d´emat´erialis´ees entre deux entit´es (individus ou organisations) via des syst`emes informatiques [4]. La figure

1.1 illustre une transaction ´electronique dans les usages quotidiens.

Figure 1.1 – Le p´erim`etre de la chaˆıne d’une transaction ´electronique s´ecuris´ee (source : Pˆole Transactions ´Electroniques S´ecuris´ees [4])

Une transaction ´electronique peut se d´ecomposer en plusieurs transactions qui sont chacune un ensemble coh´erent d’informations au travers d’un r´eseau. Une transaction peut ˆetre la validation d’une information sur une carte `a puce (contrˆole d’acc`es), le demande du solde (cr´edit mobile, solde bancaire, ...) ou encore un paiement [5]. Les technologies employ´ees pour s´ecuriser la transaction sont nombreuses (cryptographie, r´eseau, biom´etrie, firewalls, ...) dont un objet important est l’´el´ement s´ecuris´e.

1.1.2

La mon´

etique

Apparu d`es les ann´ees 1980, le mot mon´etique vient de la contraction des termes mon´e(taire) et (informa)tique et est d´efini dans l’ouvrage [6]. Il d´esigne l’ensemble des techniques ´electroniques, informatiques et t´el´ematiques permettant d’effectuer des transactions et des transferts de fonds. A l’origine, ce terme a ´et´e cr´e´e pour d´esigner l’ensemble des activit´es li´ees `a la carte de paiement bancaire. Avec l’introduction de la carte `a puce, le terme mon´etique a ´et´e utilis´e pour d´esigner les activit´es de paiement par carte et les technologies comparables `a base de carte (cartes t´el´ephoniques, cartes billettiques, cartes pr´epay´ees, ...). La d´emat´erialisation a permis d’inclure la notion de carte virtuelle (recharge t´el´ephonique, e-carte Bleue). Aujourd’hui, l’ensemble du domaine est d´esign´e par l’appellation Transactions Electroniques S´ecuris´ees (TES).

1.1. CONTEXTE DE L’ ´ETUDE 7

Il recouvre les technologies li´ees `a la carte, aux moyens de paiement, `a l’identification num´erique, `a l’e-sant´e et `a l’e-administration [7].

Depuis 1990, on observe une ´evolution du terme Mon´etique et du m´etier de mon´eticien. Une d´efinition de son p´erim`etre bas´ee sur la notion de carte `a puce et de traitement des transactions ´electroniques associ´ees est plus juste et en ad´equation avec l’´evolution de ce domaine. Nous nous focalisons dans cette ´etude sur le paiement par carte `a puce.

La carte de paiement est un moyen de paiement pr´esent´e sous forme de carte plastique, ´equip´ee d’une bande magn´etique et ´eventuellement d’une puce ´electronique. Il existe plusieurs sortes de cartes, en fonction de leur vocation :

– La carte de d´ebit qui permet l’utilisation d’argent pr´esent sur le compte du porteur

– La carte de cr´edit pour des paiements impliquant un taux d’int´erˆet (d´ebit en plusieurs fois moyennant un cr´edit financier automatique)

– Le Porte Monnaie Electronique (PME) permettant de charger une carte afin d’effectuer des paiements

Le paiement par carte de paiement met donc en relation plusieurs acteurs comme le montre la figure1.2 :

Figure 1.2 – Sch´ema `a quatre coins repr´esentant les acteurs pour le paiement (source : Comprendrelespaiements.com [8])

– Un client (porteur) qui poss`ede une carte de paiement

– Un commer¸cant (accepteur) ´equip´e d’un terminal de paiement

– Etablissement financier du commer¸cant (accepteur) sur lequel est connect´e le terminal

– Etablissement financier du client (´emetteur) qui va r´epondre `a la demande d’autorisation online

La transaction de paiement peut s’effectuer soit en ligne soit hors ligne. Dans le premier cas, le r´eseau interbancaire est utilis´e, ce qui permet la communication entre les diff´erentes entit´es et l’acceptation du paiement (si la transaction est l´egitime et autoris´ee). Cependant, la demande d’autorisation n’est pas obligatoire. Il se peut que la transaction se fasse hors ligne. Dans ce cas, il est n´ecessaire d’avoir une confiance totale dans l’impl´ementation des sp´ecifications qui r´egissent la transaction, c’est-`a-dire l’application de paiement. Un distributeur de billet est un appareil capable d’accepter une carte de paiement et de distribuer de l’argent. Dans ce cas, la transaction est obligatoirement en ligne. De plus en plus, les transactions de type paiement sont possibles `a distance. On parle donc de transactions avec ou sans contact. Dans le cas du paiement mobile, le paiement est r´ealis´e avec un ´el´ement s´ecuris´e sans contact.

1.1.3

Les sp´

ecifications et certifications

Des sp´ecifications d´efinissent les aspects fonctionnels d’une application et garan-tissent des exigences de s´ecurit´e. Durant les ´etapes de cr´eation de la carte `a puce, la notion de s´ecurit´e est trait´ee. Un produit dit certifi´e a g´en´eralement ´et´e test´e non seulement durant la phase de d´eveloppement par le constructeur mais aussi par un laboratoire de certification afin de garantir son bon fonctionnement vis `a vis des sp´ecifications. Ce processus de certification permet de reconnaˆıtre un niveau de s´ecurit´e par un laboratoire externe `a l’entreprise `a l’origine du produit. Pour le paiement de type Europay Mastercard Visa (EMV), EMVCo fournit le document appel´e ”Security Evaluation Process” `a ses membres [9]. Il assure une base de s´ecurit´e robuste pour les cartes `a puces et produits associ´es. Pour r´esumer, EMVCo fournit des documents afin de guider le test et l’´evaluation de cartes `a puces mais aussi une liste des laboratoires approuv´es par EMVCo [10].

Plus g´en´eralement, l’´evaluation de plus haut niveau est permise par la certifica-tion dite tierce partie, ”qui permet `a un client de s’assurer par l’intervention d’un professionnel ind´ependant, comp´etent et contrˆol´e, appel´e organisme certificateur, de la conformit´e d’un produit `a un cahier des charges ou `a une sp´ecification tech-nique. La certification tierce partie apporte au client la confirmation ind´ependante et impartiale qu’un produit r´epond `a un cahier des charges ou `a des sp´ecifications techniques publi´ees” [11]. En France, la certification s’appuie sur des travaux effectu´es par des centres d’Evaluation de la S´ecurit´e des Technologies de l’Information (CESTI)

1.2. LA S ´ECURIT ´E DES APPLICATIONS SUR CARTE 9

acr´edit´es par le Comit´e Fran¸cais d’Acr´editation (COFRAC) selon la norme ISO/IEC 17025 [12]. Les CESTI m`enent ces ´evaluations selon les sp´ecifications de l’Agence Nationale de la S´ecurit´e des Syst`emes d’Information (ANSSI) afin d’´emettre des certificats attestant que le produit certif´e est conforme `a une sp´ecification technique appel´ee cible de s´ecurit´e.

L’´evaluation selon les Crit`eres Communs [13] permet quant `a elle de certifier, et ainsi d´elivrer un certificat, un produit selon des niveaux d’assurance de s´ecurit´e Evaluation Assurance Level (EAL) tr`es vari´es, allant de EAL1 (niveau d’attaquant faible) `a EAL7 (niveau d’attaquant ´elev´e). Les certificats ´emis par l’ANSSI et bas´es sur les Crit`eres Communs peuvent b´en´eficier d’une reconnaissance internationale. On peut aussi citer le CCRA (Common Criteria Recognition Agreement) sign´e par 25 membres permettant la reconnaissance au niveau EAL2 (niveau d’attaquant basique) et l’accord europ´een SOG-I5 [14] regroupant actuellement 10 membres dont les CESTI et permettant la reconnaissance des certificats jusqu’`a EAL4, voire pour certains domaines techniques particuliers jusqu’`a EAL7.

1.2

La s´

ecurit´

e des applications sur carte

Figure 1.3 – Le contexte de l’´etude

Dans cette partie, nous pr´esentons toutes les notions li´ees `a la s´ecurit´e des appli-cations sur carte en d´ecrivant les aspects mat´eriels, les standards et les sp´ecifications afin de positionner les travaux de cette th`ese (illustration dans la figure 1.3).

1.2.1

El´

ement s´

ecuris´

e

Un ´el´ement s´ecuris´e ou ”Secure Element”(SE) est une plate-forme ”inviolable” capable d’h´eberger une ou plusieurs applications en toute s´ecurit´e ainsi que leurs

donn´ees confidentielles et cryptographiques (par exemple, gestion des cl´es). L’authen-tification, l’idenL’authen-tification, la signature et la gestion du PIN sont au coeur du syst`eme. Le SE contrˆole les interactions entre les sources de confiance (un ´etablissement financier), l’application de confiance (une application de paiement) stock´ee sur la SE et des tiers (un commer¸cant). Le domaine s´ecuris´e prot`ege les informations d’identifi-cation de l’utilisateur et traite la transaction de paiement dans un environnement de confiance afin d’assurer la s´ecurit´e des donn´ees de l’utilisateur. La figure 1.4 fournit un zoom sur le SE de la carte `a puce.

Figure 1.4 – Zoom sur l’´el´ement s´ecuris´e (Source : cartes-america [15])

Il y a trois diff´erents types de SE :

– le SE pour le mobile : Universal Integrated Circuit Card (UICC) – le SE embarqu´e

– le SE sous forme de microSD

Chaque SE r´epond `a des besoins diff´erents du march´e. La puce `a microcircuit qui r´eside dans les cartes de paiement a ´et´e adapt´ee pour r´epondre aux besoins du monde mobile. Avec de multiples applications actuellement stock´ees et leurs processus ex´ecut´es dans le mˆeme dispositif, il est essentiel d’ˆetre en mesure d’accueillir des applications de confiance dans un environnement s´ecuris´e. Au niveau logiciel, les SEs de type embarqu´e sont souvent bas´es sur les syst`emes d’exploitation ouverts comme JavaCard[16] et MULTOS et r´epondent aux sp´ecifications GlobalPlatform [17] pour le chargement s´ecuris´e des applications.

De nos jours, l’utilisation de la carte `a puce ne se r´eduit pas au paiement et les domaines sont vari´es (voir Figure 1.5). Les applications de la mon´etique sont nombreuses et nous avons la possibilit´e d’utiliser les suivantes :

1.2. LA S ´ECURIT ´E DES APPLICATIONS SUR CARTE 11

– Application de porte monnaie ´electronique – Application de ticketing

– Application d’identification – ...

Figure 1.5 – Domaines d’utilisation des cartes `a puce

1.2.2

Norme ISO/IEC 7816

Les donn´ees ´echang´ees au niveau applicatif `a partir d’un terminal vers une carte `

a puce sont appel´ees commandes Application Protocol Data Unit (C-APDU). Les donn´ees ´echang´ees `a partir d’une carte `a puce vers un terminal sont les r´eponses Application Protocol Data Unit (R-APDU). La carte `a puce va prendre le rˆole esclave dans le dialogue. La communication est d´efinie dans la norme ISO/IEC 7816 [18]. Dans le cas d’une transaction sans contact, on ajoute la norme d´edi´ee ISO/IEC 14443 [19] pour les aspects physiques, les aspects applicatifs restent identiques. Comme pr´esent´e sur la figure1.6, une commande envoy´ee par le terminal est obligatoirement suivie d’une r´eponse de la part de la carte.

C o m m an d e A P D U R é p o n se A P D U 0 1

Figure 1.6 – Un couple commande/r´eponse APDU

Sur la figure1.7, nous pouvons observer la structure d’une commande et d’une r´eponse APDU d’apr`es l’ISO/IEC 7816 [18]. Les champs de la commande sont les suivants : l’octet ”Class” (CLA) indique le type de la commande, l’octet ”Instruction” (INS) la commande sp´ecifique, les param`etres (P1 et P2) pr´ecisent la commande, l’octet ”Length of UDC” (LC) la longueur des donn´ees inclues dans la commande (UDC) et l’octet ”Length of UDR” (LE) la longueur des donn´ees de la r´eponse

attendue. Ces trois derniers champs sont optionnels. Si le champs LE est pr´esent, la r´eponse contiendra un UDR, donn´ees de longueur LE ainsi que deux champs obligatoires constituant le ”Status Word” (SW1 et SW2), il s’agit du statut de traitement de la commande par la carte.

CLA INS P1 P2 LC UDC LE SW1 SW2 UDR Command APDU : Response APDU : Class Byte Instruction Byte Parameters

Length of UDC Data Fields

Length of UDR

Data Fields _{Status Words}

Figure 1.7 – Structure de la communication APDU

Chaque commande poss`ede sa propre configuration (les valeurs des param`etres, l’utilisation de donn´ees ou l’attente de donn´ees dans la r´eponse). Les commandes principales d´efinies par cette norme sont les suivants (l’octet INS est suivi de la description de la commande) : – 0E : Erase Binary – 20 : Verify – 70 : Manage Channel – 82 : External Authenticate – 84 : Get Challenge – 88 : Internal Authenticate – A4 : Select File – B0 : Read Binary – B2 : Read Record(s) – C0 : Get Response – C2 : Envelope – CA : Get Data – D0 : Write Binary – D2 : Write Record – DA : Put Data – DC : Update Record – E2 : Append Record

1.2. LA S ´ECURIT ´E DES APPLICATIONS SUR CARTE 13

Figure 1.8 – SWs possibles (Source : Oracle [20])

1.2.3

Communication PC/SC :

Les sp´ecifications ”Personal Computer / Smart Smart” (PC/SC)[21] ont ´et´e cr´e´ees afin de permettre l’interop´erabilit´e des communications entre une carte `a puce et un ordinateur. Le group PC/SC, ´etabli en 1996, est `a l’origine de ces sp´ecifications (la derni`ere version datant de Juin 2013). Grˆace `a celles-ci, nous pouvons cr´eer une application en communiquant avec n’importe quel lecteur PC/SC. Une biblioth`eque de type ”Dynamic Link Library” (DLL), ensemble d’ ”Application Programming Interface” (API) est fournie par Microsoft. Cette biblioth`eque propose des fonctions utiles pour la cr´eation d’une application n´ecessitant la connexion `a une carte `a puce sur un PC. Lorsque qu’une application a besoin de ce fichier, l’ensemble de la biblioth`eque est charg´e dans la m´emoire. Pour ˆetre exact, winscard.dll est l’impl´ementation standard pour les environnements Windows et pcsclite est l’impl´ementation open source pour les syst`emes linux.

1.2.4

Les sp´

ecifications EMV

Europay Mastercard Visa (EMV) est un ensemble de sp´ecifications pour la s´ e-curit´e des paiements par cartes `a puce. C’est l’organisme EMVco qui s’occupe de ce standard (MasterCard, Visa, JCB et American Express). Les points importants de ces sp´ecifications sont l’interop´erabilit´e internationale, la v´erification et d´ echiffre-ment de la cl´e personnelle (PIN) par la puce ainsi que le multi-applicatif. Plusieurs applications peuvent alors cohabiter sur la mˆeme carte `a puce. Pr´ecisons toutefois que EMV couvre la transaction `a partir de l’´emetteur juqu’au terminal en passant par l’acqu´ereur, mais nous nous focalisons sur la relation entre la carte et le terminal seulement dans la suite de l’´etude.

Les sp´ecifications EMV de base sont constitu´ees de quatre livres disponibles sur internet librement :

Figure 1.9 – ´Evolution de EMV (source : EMVCo [22])

remise `a z´ero, description du protocole de transaction et s´election d’applications [23],

– Livre 2 : authentification des donn´ees : statique et dynamique, chiffrement du code PIN, int´egrit´e, confidentialit´e, m´ecanismes de s´ecurit´e et algorithmes cryptographiques [24],

– Livre 3 : une partie concerne les commandes et les donn´ees, une seconde d´efinit le flux transactionnel [25],

– Livre 4 : besoins fonctionnels et caract´eristiques physiques, gestion des donn´ees et du logiciel et interfaces utilis´ees [26].

La transaction est illustr´ee sch´ematiquement par la figure 1.10. Voici une des-cription concise de chaque ´etape r´egissant une transaction EMV (utilis´ee dans le contexte de paiement face `a face avec une carte `a puce `a contact) :

1. Initialisation

– Application selection : soit l’application est s´electionn´ee par l’”Application identifier” (AID) par une commande SELECT, soit le ”Payment System Environnement” (PSE) est s´electionn´e et l’AID est retrouv´e dans les donn´ees point´ees par le ”Short File Identifier” (SFI) retourn´e par la commande SELECT.

1.2. LA S ´ECURIT ´E DES APPLICATIONS SUR CARTE 15

Cardholder Verification

Terminal Decision

Card Decision

Online Processing

Completion of the Transaction Selection of the application

Data Authentication

Processing Restriction

Figure 1.10 – ´Etapes EMV

– Initiate application processing : les valeurs des ”Application Interchange Profile” (AIP) et ”Application File Locator” AFL sont retrouv´ees grˆace au ”Processing Options Data Object List” (PDOL) ou bien par la valeur par

d´efaut 83 00 dans la commande GET PROCESSING OPTION.

– Read application data : on peut alors lire les donn´ees dans les enregis-trements point´es par l’AFL. Les donn´ees sont alors r´ecup´er´ees pour ˆetre utilis´ees plus tard dans la transaction.

2. Transaction Analysis

– Offline data authentication : l’authentification la plus s´ecuris´ee est effec-tu´ee si support´ee par la carte, ”Combined Data Authentification” (CDA), avec un repli possible sur la ”Dynamic Data Authentification” (DDA) ou enfin ”Static Data Authentification” (SDA).

– Processing restrictions : cette ´etape d´etermine le degr´e de comptabilit´e de l’application dans le terminal avec l’application sur la carte.

– Card Holder Verification : le porteur est authentifi´e grˆace `a un code PIN en clair ou chiffr´e.

– Terminal Risk Management : des mesures de s´ecurit´e sont effectu´ees, v´erification du seuil limite, transaction pouvant ˆetre envoy´ee en ligne par le

terminal et v´erification d’autres compteurs. 3. Decision

– Terminal Action Analysis : en envoyant la commande GENERATE AC, le terminal demande la transaction en ligne ou non. Le TVR contient les donn´ees de sa d´ecision. R´eponse possible : AAC, TC ou ARQC.

– Card Action Analysis : la carte r´epond alors avec sa propre d´ecision. – Script processing : permet `a l’´emetteur de modifier des donn´ees sur la

carte.

– Completion : termine la transaction.

1.2.5

Sp´

ecifications propri´

etaires

Chaque ´emetteur de carte `a puce compl`ete les sp´ecifications EMV par ses propres sp´ecifications apportant des ´el´ements suppl´ementaires pour d´evelopper une appli-cation. Mastercard est `a l’origine des sp´ecifications M/CHIP [27], d´efinissant les applications cartes de paiement Mastercard conformes EMV. L’application M/CHIP peut prendre plusieurs ´etats. L’´etat de l’application ´evolue par la r´eception de com-mandes APDU et l’´emission des r´eponses associ´ees.

L’application est illustr´ee par une machine d’´etats (que nous ne pouvons pas donner enti`erement, les sp´ecifications propri´etaires ´etant confidentielles) dont les ´etats possibles sont :

– ”idle” : l’application n’est pas encore selectionn´ee – ”selected” : l’application est selectionn´ee

– ”initiated” : la transaction est initialis´ee

– ”online” : l’application demande une connexion `a l’´emetteur

– ”script” : l’application est prˆete `a recevoir une commande de script

Nous pouvons voir dans les sp´ecifications MasterCard, conformes au standard EMV, que l’application de paiement ne peut ´evoluer qu’en recevant et r´epondant `

a une s´erie de commandes APDU. Nous ne pouvons pas consid´erer l’acceptation d’une seule commande sans prendre en compte l’´etat courant th´eorique ainsi que les communications pr´ec´edentes. Chaque constructeur d´efinit son cahier des charges afin d’exposer le plus clairement possible les fonctionnalit´es d´esir´ees. Des commandes et des r´eponses sp´ecifiques peuvent ˆetre ajout´ees aux d´efinitions donn´ees par la norme ISO/IEC 7816. Les d´eveloppeurs vont, `a partir de ces sp´ecifications, standards et normes, impl´ementer l’application grˆace `a un ensemble de technologies.

1.2. LA S ´ECURIT ´E DES APPLICATIONS SUR CARTE 17

1.2.6

JavaCard

La g´en´eration actuelle de carte `a puce est bas´ee sur le premier langage orient´e objtet adapt´e aux cartes `a puce. Il s’agit d’un langage cr´e´e par les ing´enieurs de Schlumberger au Texas. En f´evrier 1997, Schlumberger et Gemplus fondent Java Card Forum [28], ils sont rejoints par les producteurs de cartes `a puce comme Bull ou Giesecked & Devrient. En octobre 2000, plus de 40 entreprises ont acquis la licence d’exploitation Java Card. Actuellement, la plus r´ecente version Java card 3.0.1 date de mai 2009.

Les principaux avantages de ce type de la technologie sont : – D´eveloppement facile

– Interop´erabilit´e des applications – Isolation entre les applications – S´ecurit´e

– Ind´ependance au hardware

– La gestion de multiples applications

Ces avantages sont permis par le langage Java, l’environnement de d´eveloppement Java et des m´ecanismes tels que l’impossibilit´e de construire des pointeurs, un firewall et l’encapsulation de la complexit´e fondamentale du syst`eme des cartes `a puce ([29] et [30]).

JavaCard est un environnement d’ex´ecution d´estin´e aux cartes `a puce permettant d’´ecrire et d’ex´ecuter des programmes appel´es Applet avec l’approche orient´ee objet du langage Java. L’architecture est pr´esent´ee dans la figure1.11.

1.2.7

GlobalPlatform

GlobalPlatform [17] est un consortium cr´e´e en 1999 par les grandes entreprises des secteurs du paiement et des t´el´ecommunications ainsi que les structures gouver-nementales. L’infrastructure globale est destin´ee `a l’impl´ementation des cartes `a puce commune `a tous les secteurs. Les sp´ecifications GlobalPlatform (anciennement Visa Open Plateform) visent `a g´erer les cartes de fa¸con ind´ependante du mat´eriel, des vendeurs et des applications. Elles r´epondent efficacement aux probl`ematiques de la gestion du multi-applicatif : chargement s´ecuris´e des applications, gestion du contenu et cycle de vie.

Figure 1.11 – Architecture d’une application JavaCard (source : Oracle [31])

1.2.8

Discussion

La transaction de paiement peut donc ˆetre vue selon deux angles. D’une part, le terminal de paiement initie et effectue la transaction en communiquant des infor-mations `a la carte et en analysant les r´eponses. La transaction est donc compos´ee des ´etapes EMV vues pr´ec´edement. D’autre part, nous pouvons voir la transaction de paiement du point de vue carte. Ce sont donc les sp´ecifications propri´etaires et la machine d’´etat d´efinie par MasterCard pour l’application carte M/CHIP qui nous permet d’appr´ehender le sujet selon les deux points de vue. Ces documents permettent aussi `a l’entreprise de certification d’effectuer une analyse sur le fonction-nement de l’application. Le paiement EMV ´etant tr`es r´epandu, une ´etude sur ce type d’application est coh´erente. Cependant, la simplicit´e de l’application Porte Monnaie Electronique (PME) par rapport au paiement EMV nous permet de travailler sur une preuve de concept plus accessible. Toutes ces applications sont bas´ees sur ISO/IEC 7816 ainsi que des sp´ecifications compl´ementaires.

1.3. ATTAQUES SUR UNE TRANSACTION DE PAIEMENT 19

1.3

Attaques sur une transaction de paiement

Dans cette partie, nous allons exposer les failles existantes sur l’usage de la carte `

a puce. Malgr´e une s´ecurit´e importante et un audit s´ecurit´e, nous pouvons voir que des attaques sur ce syst`eme existent [32]. Certaines attaques sont sp´ecialis´ees pour une transaction avec ou sans contact physique. Nous pouvons aussi distinguer les attaques invasives (impliquant une destruction partielle ou compl`ete de la carte) et les attaques non invasives.

1.3.1

Attaques invasives ou semi-invasives :

Ce type d’attaque met en p´eril l’int´egrit´e physique de la puce `a micro-circuit. Les attaques pr´esent´ees ici sont pr´esent´ees dans [33].

Par injection de fautes :

Cette attaque est une attaque semi-invasive car elle n´ecessite un acc`es direct `a la carte `a puce. Il s’agit de perturber le fonctionnement d’une carte `a puce en modifiant une donn´ee pr´ecise. Par exemple, on peut faire varier la tension d’alimentation (power glitch), l’horloge ou encore la temp´erature. Une autre m´ethode consiste `a imposer `a la puce un laser, un faisceau d’ion, un rayon X, etc. Concr`etement, plusieurs techniques ([34] ou [35]) sont connues :

– Application de lumi`ere laser sur le processeur introduit par [36]

– Attaque de Bellcore sur le chiffrement RSA (nomm´e par les initiales de ses trois inventeurs) comme dans [35]

– D´efaillance ´electronique (glitch) appliqu´e sur un calcul RSA, historiquement la premi`ere m´ethode [37]

– Attaque de type ”Differential fault analysis” (DFA) [37]

La r´ealisation de cette attaque est donc variable d’un syst`eme `a l’autre. Il faut effec-tuer de nombreux essais, de diff´erentes sortes, afin d’obtenir des r´esultats concluants.

Par conditions anormales Cette attaque varie de l’attaque pr´ec´edente par la dur´ee de la modification apport´ee [38]. Ici, on fait fonctionner la carte `a puce en dehors de ses conditions op´erationnelles. L’attaquant peut modifier la tension ou la fr´equence d’alimentation ainsi que la temp´erature facilement. Cependant, ces attaques ne semblent pas efficaces car des d´etecteurs de conditions anormales sont pr´esents dans la carte `a puce.

Par rayonnement : Afin de modifier l’ex´ecution des applications d’une carte `a puce, on peut aussi utiliser un rayonnement ´electromagn´etique. Cette attaque est semi-invasive car l’attaquant doit acc´eder `a la puce. On applique donc un rayonne-ment durant l’ex´ecution de l’application (ce qui diff`ere de l’injection de faute) [39].

Par les composants : Ces attaques [40] sont compl`etement invasives car n´ eces-sitent l’´etude d’un composant pr´ecis de la carte `a puce. On doit donc d´esassembler la carte `a puce et celle-ci ne sera plus utilisable par la suite. Cette premi`ere ´etape se d´eroule chimiquement ou physiquement. Il existe plusieurs outils possibles en vue de cette attaque [40] :

– Focused Ion Beam (FIB). Cet outil permet d’´etudier un composant avec un microscope ainsi que de retirer de la mati`ere `a la carte `a puce.

– Electron Beam Tester (EBT). Cet outil permet de lire la valeur du potentiel `a un endroit donn´e de la carte.

– Microprobing : acc`es `a la puce.

L’attaquant cherche `a trouver les syst`emes de s´ecurit´e (impl´ementations, informations contenues dans la puce) pr´esents sur un composant en particulier. Par exemple, il est possible de lire les bits sur le bus m´emoire lorsqu’on sait qu’une donn´ee int´eressante y transite.

1.3.2

Attaques non invasives

Ce type d’attaque n’alt`ere pas la puce `a micro-circuit mais consiste `a observer le fonctionnement d’une application.

Par canaux cach´es :

Une attaque sur carte `a puce consiste `a ´etudier le fonctionnement du circuit ´electronique. Plusieurs donn´ees peuvent ˆetre utilis´ees telles que la consommation du courant, les ´emissions ´electromagn´etiques ou encore le temps d’ex´ecution. Les attaques par canaux cach´es utilisent les failles mat´erielles de l’impl´ementation pour r´ecup´erer des informations sur le secret utilis´e [41].

On peut ainsi lister plusieurs techniques majeures :

– consommation du courant : Simple Power Attack / Differential Power Attack / High Order Differential Power Analysis avec par exemple [42]

– ´emissions ´electromagn´etiques : Simple Electromagnetic Attack / Differential Electromagnetic Attack [43]

1.3. ATTAQUES SUR UNE TRANSACTION DE PAIEMENT 21

– le temps d’ex´ecution dans [44]

Skimming : L’attaque dite de ” skimming ” [45] est une attaque simple `a mettre en place, d’o`u son utilisation importante. Il s’agit de r´ecup´erer des informations d’une carte `a puce en pla¸cant un ´el´ement entre le lecteur de carte `a puce et la carte `a puce (`a condition d’avoir la possibilit´e de cr´eer un ´el´ement d’´ecoute d’´epaisseur inf´erieure

`

a 0,1 mm). Cet ´el´ement a pour but de capturer les donn´ees tel que le num´ero de carte. Sur la figure1.12, on voit cet ´el´ement sur la photo en haut `a droite. La seconde partie de l’attaque est l’utilisation d’une cam´era (voir la fl`eche noire visible sur la premi`ere image de la figure 1.12). On peut ainsi r´ecup´erer le code PIN (Personal Identification Number) du porteur et se faire passer pour le porteur de la carte, mˆeme si g´en´eralement il s’agit uniquement de la lecture et la r´ecup´eration de la piste.

Figure 1.12 – La technique de skimming en images (source : Antiskimmingeye [46])

Yes Card La Yes Card est une carte vierge programmable `a l’origine. L’atta-quant copie toutes les donn´ees statiques d’une carte `a puce valide, `a une diff´erence pr`es. L’attaquant modifie le retour du test du code PIN pour accepter n’importe quel code PIN. Cependant, lors de l’envoi de la r´eponse ”code PIN accept´e”, un faux cryptogramme est envoy´e par la carte qui est d´etectable lors d’une transaction en ligne par v´erification du cryptogramme par l’´emetteur. Cette attaque n’est possible qu’en mode hors ligne.

Attaque en relais Son principe est qu’un attaquant intercepte les communica-tions entre deux entit´es. Le but de l’attaque est d’usurper l’identit´e d’un individu et de r´ecup´erer la transaction initiale entre les deux entit´es initialement en communication et de modifier cette transaction, afin par exemple de valider une autre transaction [47].

Attaque de Cambridge Contrairement `a l’attaque utilisant une YES CARD, cette attaque est typiquement un man-in-the-middle dans lequel l’intercepteur r´epond oui `a la v´erification du PIN sans transmission de la commande `a la carte r´eelle [48]. Cette faille est connue par EMVCo depuis des ann´ees et peut ˆetre combl´e par

l’authentification CDA en cours de d´eploiement.

Figure 1.13 – Illustration du mat´eriel necessaire pour effectuer l’attaque de Cam-bridge initiale

1.3.3

Transactions sans contact

Les attaques sont tout aussi possibles voire pour certaines facilit´ees dans un contexte sans contact. En effet, l’attaque dite ”´ecoute ill´egale” a pour principe l’observation de communication entre le terminal et le lecteur. Dans ce contexte, l’attaquant peut r´ecup´erer plus facilement les informations concernant la transaction ou la carte `a puce. On peut aussi parler de l’attaque dite ”scanning actif” qui permet d’activer une carte sans contact `a distance. L’attaque en relais est bien entendu possible et facilit´ee par l’usage d’une carte sans contact [49]. La figure 1.14expose cette attaque.

Figure 1.14 – Attaque en relais

1.3.4

R´

ecapitulatif :

Le tableau 1.1 r´ecapitule les attaques trait´ees dans ce document. On discerne les attaques invasives des attaques non invasives mais aussi les attaques avec ou sans contact. Certaines de ces attaques ont la particularit´e d’ˆetre facilement reproductibles comme l’attaque de Cambridge. L’´etude de ces attaques est une ´etape importante dans la recherche de s´ecurit´e. En effet, il faut connaˆıtre les risques afin de proposer des mesures adapt´ees.

1.3. ATTAQUES SUR UNE TRANSACTION DE PAIEMENT 23 T ab l e 1 .1: R ´e cap it u la ti f d es a tt aq u es A tt aq u e In v a si v e Co n tact F o n ct ion n em en t P a r in ject io n d e fa u te s O u i O u i mo d ific at ion d u fonc ti onn em en t d e la cart e `a pu ce en inj ec tan t d es er re ur s P a r con d it io n s a n or m a les O u i O u i m o d ifi cat io n d u fo n ct ion n em en t en m o d ifi a n t u n e co n d it ion su r la d u r´e e P a r ra y on n em en t O u i O u i O n ap p li q u e u n ra y o n n em en t su r la ca rte `a p u ce en fon ct io n n em en t P a r les co m p os an ts O u i O u i iso lat io n d es co m p o sa n ts p ou r iso ler les ´el ´em en ts d e s´ecu ri t´e P a r can a u x ca ch ´e s No n O u i `a p a rti r d e con so m m a ti on , tem p s ex ´ecu ti o n ou ´em iss ion s ´el ec tr o m a gn ´et iq u es Wh it e Pl a st ic No n O u i cl o n ag e d e la p a rt ie p is te d ’u n e ca rte , afi n d e l’ u ti li se r `a l’ ´et ra n ger S k im m in g No n O u i o b te n ti o n d es in for m a ti on s d ’u n e car te g rˆa ce `a d es ´e l´em en ts ex t´er ieu rs Y es C ar d No n O u i cl o n ag e d ’u n e car te `a p u ce a v ec m o d ifi ca ti on d e la v ´er ifi cat io n d u co d e PIN A tt aq u e rel a is No n O u i u ti li sa ti o n d ’u n ter m in a l m o d ifi ´e et tr an sf er t d ’u n e tr a n sa ct ion p o u r la m o d ifi er Ca m b ri d ge No n O u i ´ev ite r la v ´e ri fi cat io n d u co d e PIN p o u r acc ep ter la tr a n sac ti o n sa n s co d e PIN A tt aq u es en re lai s No n i No n u ti li sa ti o n d ’u n ter m in a l m o d ifi ´e et tr an sf er t d ’u n e tr a n sa ct ion p o u r la m o d ifi er Eco u te il l´ega le No n No n o b te n ti o n d es in for m a ti on s p a r ´e cou te d e la tr an sact io n S ca n n in g Ac ti f No n No n a ct iv a ti on d ’u n e car te p a r l’ en v oi d e com m a n d es p o u r ob ten ir d es d on n ´ees

1.4

Evaluation d’applications

Afin de garantir le bon fonctionnement et la s´ecurit´e d’applications, il est n´ecessaire les ´evaluer.

1.4.1

Introduction

Impl´ementer une application carte n’est pas une tˆache facile `a r´ealiser. Par exemple, dans le livre [50], certaines difficult´es sont exprim´ees. Des sp´ecifications impr´ecises ou des options trop vastes pourraient ˆetre `a l’origine de probl`emes. Par exemple, toutes les variantes possibles d’authentification des donn´ees et de la carte peuvent ne pas ˆetre enti`erement g´er´ees par un terminal.

L’existence d’attaques est une preuve ´evidente du besoin de s´ecurit´e. Cependant, la s´ecurit´e id´eale n’existant pas, c’est une course perp´etuelle entre les constructeurs qui tentent de s´ecuriser au mieux leurs produits et les attaquants qui con¸coivent des attaques de plus en plus complexes. Nous allons voir comment l’´evaluation de la carte `

a puce peut donner un certain niveau de garantie concernant les aspects fonctionnels et s´ecuritaires de la carte `a puce. Les enjeux s´ecurit´e sont nombreux : confidentialit´e des informations, authentification du porteur, int´egrit´e de la transaction, impossibilit´e de modifier des informations sur la puce, ...

1.4.2

D´

efinitions

Selon ISO 8402[51], la qualit´e est d´efinie comme l’ensemble des fonctions et caract´eristiques d’un produit ou d’un service qui lui conf`erent l’aptitude `a satisfaire les besoins exprim´es ou implicites. Les deux attributs les plus importants de la qualit´e d’une application sont la robustesse et l’absence de d´efauts et d’erreurs. On appelle l’´evaluation logicielle le fait d’´evaluer un logiciel. En ce qui concerne l’´evaluation d’une carte `a puce, le test est principalement utilis´e. Le but du test est toujours de trouver des d´efauts et des erreurs, le processus de test doit ˆetre orient´e vers ce but. Cependant, les tests ne peuvent ˆetre complets car il n’est jamais vraiment possible de travailler en prenant en compte toutes les combinaisons possibles. A l’instar d’une qualit´e parfaite et compl`ete, nous obtenons un niveau de qualit´e acceptable par rap-port au niveau de qualit´e souhait´e. Comme les tests ne peuvent jamais tout couvrir, il est difficile de d´efinir un crit`ere d’ach`evement pour le d´eveloppement de tests. La r`egle de base est que le mˆeme effort devrait ˆetre consacr´e `a l’´elaboration de tests qu’au d´eveloppement du produit. Le niveau minimum de couverture d’instructions

1.4. EVALUATION D’APPLICATIONS 25

devrait ˆetre de 95% et la couverture des branches de 80% [50].

On peut observer dans certains articles, l’utilisation des termes v´erification, validation ou ´evaluation de mani`ere interchangeable comme ci ces termes avaient la mˆeme signification. La norme ISO 8402[51], maintenant obsol`ete, traitait de la v´erification et la validation de syst`emes de mani`ere bien distinctes. Ce sont des processus d’´evaluation d’un syst`eme ou d’un composant. La norme de l’Institute of Electrical and Electronics Engineers (IEEE) [52] nous donne deux d´efinitions, cit´ees dans leur langue originale :

– ”verification. (1) The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Contrast with : validation. (2) Formal proof of program correctness.”

– ”validation. The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.”

Des documents d´eveloppent donc ces notions, que ce soit dans le domaine g´en´eral ou dans un domaine bien pr´ecis ([53], [54]). La v´erification permet de contrˆoler la conformit´e d’un syst`eme vis `a vis de sa d´efinition, une description formelle. La validation est le processus consistant `a d´eterminer si le syst`eme remplit effectivement le but pour lequel il a ´et´e con¸cu. L’´evaluation refl`ete l’acceptation du syst`eme par les utilisateurs ainsi que ses performances. On peut r´esumer ces notions par trois questions :

– V´erification : Est-ce que le syst`eme fonctionne correctement ? – Validation : Est-ce que le syst`eme r´ealise les fonctions attendues ? – Evaluation : Dans quelle mesure le syst`eme peut-il ˆetre utilis´e par tous ?

Concr`etement, la premi`ere chose `a faire sur un syst`eme est de le valider. Puis, il faut le v´erifier de mani`ere la plus comp`ete possible (diff´erentes techniques existent). Enfin, il s’agit de donner une ´evaluation du syst`eme. Un syst`eme correct du point de vue de la v´erification mais inutilisable (trop lourd, pas adapt´e au public) ne peut pas avoir une r´eponse positive `a l’´evaluation [53]. Les m´ethodes de V´erification et Validation (V&V) permettent de d´ecouvrir des probl`emes [54]. Cependant, il peut s’agir de diff´erents types de probl`emes. Une erreur est un probl`eme de raisonnement de la part des personnes `a l’origine de ce syst`eme. S’il est inclus dans le syst`eme, l’erreur devient une faute. Une d´efaillance se produit quand le syst`eme ne se comporte

Specification Lower-level specification Product Validation process Expectations Requirements process Customer Verification process Verification process

Figure 1.15 – Le processus de validation d’un syst`eme

pas comme il le devrait. Nous pouvons aussi parler d’anomalie, terme g´en´erique pouvant signifier une erreur, une faute ou une d´efaillance.

On peut r´ecapituler ainsi :

– Erreur : raisonnement incorrect de la part d’une personne. – Faute : erreur dans un syst`eme.

– D´efaillance : comportement d’un syst`eme incorrect.

– Anomalie : terme g´en´erique indiquant la pr´esence d’une erreur, faute ou d´ e-faillance.

En effet, il est n´ecessaire de valider chaque ´etape et chaque ´el´ement d’une carte `a puce. Il est irr´ealiste d’utiliser un composant s´ecuris´e et certifi´e avec un programme incorrect. Le programme doit ´egalement ˆetre valid´e et certifi´e. La cr´eation des crit`eres d’´evaluation a permis la certification de produits [55]. La reconnaissance de ces crit`eres permet la reconnaissance mutuelle entre les diff´erentes structures et les diff´erents pays.

Quelques grands principes d’une ´evaluation sont les suivants :

– R´ep´etabilit´e : une mˆeme ´evaluation sur un mˆeme produit doit donner le mˆeme r´esultat

– Reproductibilit´e : une mˆeme ´evaluation sur une mˆeme cible dans un autre laboratoire doit donner le mˆeme r´esultat

– Impartialit´e : il ne doit pas y avoir de biais

1.4. EVALUATION D’APPLICATIONS 27

Il existe diff´erents contextes d’´evaluation :

– en boˆıte noire : Cette ´evaluation consiste `a ´etudier le comportement de l’appli-cation en connaissant seulement les entr´ees et les sorties du syst`eme.

– en boˆıte blanche : Dans ce cas, nous avons acc`es au code de l’application. Cette connaissance compl`ete nous permet de connaˆıtre de mani`ere efficace le d´eroulement th´eorique de l’application ou encore d’ajouter des ´el´ements pour le test.

– en boite grise : Nous disposons de quelques informations mais pas l’acc`es com-plet `a l’application.

Des ´evaluations peuvent subvenir `a diff´erents moments de la mise en place d’une carte `a puce.

– Il peut s’agir d’´evaluation lors de la phase de d´eveloppement. Par exemple, la mise en place d’assertions. Afin de continuer le programme, chaque assertion doit ˆetre vraie.

– Il peut aussi s’agir d’´evaluation apr`es la production de la carte. Une entreprise peut essayer de stresser l’application carte afin de v´erifier si une attitude est incorrecte. On parle alors de phase de test.

– Durant la vie de la carte, nous pouvons aussi utiliser un syst`eme d´etectant les anomalies `a la vol´ee durant les transactions normales.

1.4.3

Le cas du logiciel

Les notions de v´erification et validation logicielles sont d´evelopp´ees dans les documents [56] et [57]. Le but principal de la V&V logicielle est de d´eterminer si le logiciel effectue les fonctions demand´ees correctement, de s’assurer qu’il n’effec-tue pas d’op´erations non d´esir´ees et de fournir des informations sur la qualit´e et la fiabilit´e du logiciel. On peut aussi s’assurer que le logiciel est en accord avec les standards non seulement vis-`a-vis de ses sp´ecifications mais aussi par rapport aux syst`emes en relation avec ce logiciel. On peut ainsi dire que la v´erification logicielle apporte la preuve que les sorties de conception d’une phase de d´ evelop-pement logiciel sont en accord avec les exigences sp´ecifi´ees pour cette phase [56]. Ceci vise `a l’exactitude du logiciel. Dans un environnement de d´eveloppement, la v´erification logicielle permet de s’assurer qu’une phase de d´eveloppement est termin´ee.

La validation logicielle permet de s’assurer que le logiciel est conforme aux besoins des utilisateurs. Selon [57], la validation logicielle peut s’apparenter `a une v´erification

car elle inclut toutes les activit´es de v´erification et de test men´ees tout au long du cycle de vie du logiciel. Elle permet une diminution des coˆuts du logiciel en diminuant les risques d’utilisation ainsi que le besoin de mises `a jour. Finalement, dans le d´eveloppement logiciel, la validation permet de dire que le bon logiciel est cr´e´e et la v´erification permet de s’assurer qu’il a ´et´e cr´e´e correctement. Un niveau de confiance, bas´e sur le niveau de validation, le niveau de v´erification et le niveau de test, pourrait alors ˆetre d´efinit pour un logiciel. On peut ainsi savoir si ce niveau de confiance est acceptable ou non. EMVco effectue des contrˆoles sur les cartes et terminaux. Un niveau de s´ecurit´e est alors accord´e `a ces ´el´ements.

1.4.4

Le cycle de vie de l’application carte

Sur la figure 1.16, le cycle de vie simplifi´e de la carte `a puce bas´e sur [58] est pr´esent´e. Pour ´evaluer et valider le produit, plusieurs tests sont effectu´es au cours des diff´erentes ´etapes de sa vie [59]. Tous les aspects de la carte (application, puce, donn´ees de personnalisation) doivent ˆetre valid´ees, ce qui assure un produit s´ecuris´e. Une fois con¸cu et valid´e, la carte est dite certifi´ee. La certification permet de recon-naˆıtre le niveau de s´ecurit´e d’un produit par un laboratoire externe.

Specification Development Chip creation Manufacturing Personnalization Marketing End of lyfe Next Step Next Step after test Fabrication of the chip Use of the chip

Figure 1.16 – Cycle de vie

Avant d’ˆetre utilis´ee en production, une carte `a puce doit ˆetre v´erifi´ee, valid´ee, ´evalu´ee et certifi´ee. Elle poss`ede alors un niveau acceptable et reconnu de s´ecurit´e

1.5. OBJECTIFS DE LA TH `ESE 29

afin d’autoriser l’utilisateur `a payer dans le cadre de la transaction de paiement. La figure 1.17 expose les acteurs principaux impliqu´es dans le cycle de vie de la carte `a puce.

Figure 1.17 – Cycle de vie (Source : exploratheque.net [60])

1.5

Objectifs de la th`

ese

Cette ´etude, effectu´ee dans le laboratoire GREYC, et plus sp´ecialement dans l’´equipe Mon´etique et Biom´etrie, se concentre entre autres sur la s´ecurit´e logicielle d’applications embarqu´ees sur une carte `a puce. 5 membres de l’´equipe travaillent sur le sujet : deux doctorant-ing´enieurs, deux ing´enieurs et un professeur. Notre vision est compl´et´ee par les discussions durant les conf´erences nationales et internationales et les ´echanges au sein de notre laboratoire. Ce sujet est donc un sujet appliqu´e `

a la carte `a puce poss´edant deux visions compl´ementaires : une vision recherche acad´emique mais aussi une vision en ing´enierie. Ce point n’est pas n´egligeable et explique le d´eroulement de la th`ese et les objectifs.

L’objectif est de traiter la carte `a puce comme un syst`eme boite noire ou plus pr´ecisemment boite grise (nous devons avoir un minimum d’informations concernant le d´eroulement de la transaction par les sp´ecifications afin de connaˆıtre le comportement