kamel nassima

UNIVERSIT DE LIMOGESCOLE DOCTORALE Sciences et Ingnierie pour lInformation

FACULT DES SCIENCES ET TECHNIQUES

Thse No 69/2012

THSE

pour obtenir le titre de

DOCTEUR DE LUNIVERSIT DE LIMOGES

Discipline / Spcialit : Informatique

prsente et soutenue par

Nassima Kamel

le 20 dcembre 2012

Scurit des cartes puce serveur Webembarqu

Thse dirige par Jean-Louis Lanet,co-encadre par Julien Iguchi-Cartigny

JURYRapporteurs :Mme. Samia Bouzefrane Matre de Confrences (HDR) au CNAM de ParisM. Christophe Bidan Matre de Confrences (HDR) Suplec de RennesExaminateurs:Mme. Marie-Laure Potet Professeur Ensimag, Grenoble INPM. Christophe Clavier Professeur lUniversit de LimogesM. Jean-Louis Lanet Professeur lUniversit de LimogesM. Julien Iguchi-Cartigny Matre de Confrences lUniversit de Limoges

iRemerciementsJe tiens tout dabord remercier les rapporteurs Dr. Samia Bouzeframe et Dr. Christophe

Bidan, davoir accpt de faire un compte rendu de ce mmoire et pour les corrections quils ontapportes. Je remercie galement les examinateurs Pr. Marie-Lore Potet et Pr. Christophe Clavierdavoir bien voulu consacrer de leur temps juger ce travail.

Je remercie mon directeur de thse Pr. Jean-Louis Lanet de mavoir donn lopportunit dat-teindre cet objectif de prparer une thse doctorale en me proposant ce sujet, et de mavoir dirigetout le long de ces trois annes.

Je remercie galement Dr. Julien Iguchi-Cartigny mon codirecteur, notament davoir contribula dfinition de mon sujet de thse.

Mes remerciements vont galement mes adorables collgues (doctorants et ingnieurs), je cite :Amaury, Bhagya, Damien, David, Guillaume et Pierrick, pour leur amiti et pour tous les bon mo-ments de rire et de folie que nous avons passs ensemble. Je remercie encore une fois ceux dentreeux qui ont eu la gentillesse de lire des parties de ce mmoire.

Je remercie aussi tous les autres doctorants : Aymrick, Antoine, Richard, Slim, Julien ; les an-ciens doctorants : Oana, Alex, Agns, Ahmadou et dautres ; les stagiaires passs et prsents denotre quipe ainsi que le personnel technique et administratif en particulier Hubert, Sylvie et Odile,pour leurs amiti et sympathie.

Je noublie pas aussi de remercier mes amies de longue date, Fatiha, Kahina et Samira pourleur prsence.

Mes plus vifs remerciement vont ma chre famille qui inclue mon fianc, de mavoir soutenueet encourage dans les moments difficiles. mes parents particulirement, je ddie ce titre deDOCTEUR dont ils seront sans doute plus heureux que je ne le suis.

Merci tous ceux qui ont contribu de prt ou de loin laboutissement de cette thse.

ii

RsumLes cartes puces sont des dispositifs scuriss, de plus en plus utiliss dans le monde. Leur

succs est principalement d leur aspect tamper-resistant qui permet de stocker des informationssensibles (cls de chiffrement) de manire scurise. Vu les nombreux sensibles domaines dutilisa-tion des cartes puce (bancaire, mdical, tlphonie), plusieurs recherches se sont intresss lascurit et aux attaques possibles sur ces dispositifs.

La nouvelle gnration de cartes puce dfinit un serveur Web embarqu. Il existe princi-palement deux types de spcifications pour ces nouveaux dispositifs, la premire a t tabliepar lorganisation OMA qui propose un simple serveur HTTP nomm Smart Card Web Serveur(SCWS) indpendant de la plateforme dexcution. La seconde est une nouvelle version de JavaCard propose par Sun Microsystems (actuellement Oracle), nomme Java Card 3, dition connec-te ; elle inclue le support de lAPI Java servlet 2.4, et une amlioration significativement de lAPIJava Card (thread, String, etc.) et des fonctionnalits de scurit supportes.

Lintgration du serveur Web dans la carte puce apporte un ensemble davantages et dfinitun nouvel usage de la carte puce. En effet, en plus de laspect authentification robuste que lacarte peut dsormais fournir sur le rseau, lutilisation des standards du Web permet davoir uneexprience utilisateur continue et enrichit laspect et la convivialit des interfaces fournies via unnavigateur Web. Face ces avantages, les risques dattaques augmentent. En plus des attaquesclassiques connues sur les cartes puce (physiques et logiques), certaines attaques Web connuessur des applications Web standards peuvent se reproduire sur les cartes puce. Parmi ces attaques,la Cross Site Scripting (appele aussi XSS) est lune des plus rpandues ; elle est simple ralisermais ses consquences peuvent tre trs graves. Cette attaque exploite des applications vulnrablesqui ne filtrent pas les donnes non fiables (entre par un utilisateur) avant de les utiliser. Elleconsiste injecter un code malicieux dans une entre fournie par lapplication, qui est ensuiteretourn dans une ressource de lapplication et excut dans le navigateur Web de la victime.

Dautre part, les spcifications des cartes serveur Web embarqu dfinissent des protocoles(HTTP, BIP, TCP/IP) qui doivent ncessairement tre implments pour assurer la communicationde la carte avec le navigateur Web et sur le rseau. Des failles dimplmentation de ces protocolespeuvent engendrer des vulnrabilits facilitant les attaques sur les cartes puce.

Dans cette thse nous nous intressons la scurit des cartes puce serveur Web embarqu deux niveaux. Le premier concerne la scurit des applications Web contre des attaques XSS.Nous proposons dans ce cadre un outil danalyse statique des applications Web Java Card 3, qui apour objectif de vrifier quune application est scurise contre ces attaques, incluant un filtrage desdonnes non fiables. Notre outil peut tre considr comme un outil de certification de la robustessedes applications Web avant leur chargement dans la carte. Nous avons galement implment uneAPI de filtrage que le dveloppeur peut importer dans son application.

Le second niveau de scurit explor, concerne limplmentation du protocole HTTP ; nous sug-grons un outil de fuzzing pour tester la conformit et la robustesse du protocole HTTP implmentdans une carte. Cet outil apporte un ensemble doptimisations qui rduit le temps du fuzzing etgnre des donnes de test de manire intelligente.

Mots cl : carte puce, Java Card , SCWS, XSS, HTTP, analyse statique, dpendance causale,Fuzzing.

iii

AbstractSmart cards are widely used secure devices in todays world, which can store data in a secured

manner and ensure data security during transactions. The success of smart card is mainly due totheir tamper-resistant nature which allows them to store sensitive datas like cryptographic keys.Since they are using in multiple secure domains, like banking, health insurance, etc. more and moreresearches are taken place in this domain for security and attacks.

The last generation of smart card, defines an embedded web server. There are two types ofspecifications for these devices, the first one is defined by OMA organisation that propose a simpleHTTP web server named Smart Card Web Server (SCWS), the second is proposed by Sun Micro-systems (currently Oracle), consists of a Java card 3 connected edition platform, that includes aJava servlet 2.4 API with improved Java Card API and security features. In addition to networkbenefits from the robustness of smart card, the use of web standards provide a continuous userexperience, equivalent to that seen while surfing on the internet and it enhances the look and feel ofGUI interfaces. The GUI interfaces are accessible from a browser which is located on the terminalon which the card is connected.

However, in addition to the classical attacks (physical and logical), the integration of web serveron smart card, exposes the smart card to some existing classical web application attacks. The mostimportant one is the cross site scripting attack, also named XSS. It consists of injecting maliciousdata to the given web application inputs and if the resource returned to the browser includesthe malicious code, it will be interpreted and executed, causing an attack. A web application isvulnerable to XSS if it uses an untrusted data without filtering malicious characters before. On theother hand, to ensure the communication between web applications and browser or other networkentities, it is necessary to integrate some protocols to the smart card, for example HTTP, BIP orTCP/IP. The vulnerabilities in the implementation of these protocols can facilitate some attacks.

Our contribution on this thesis is divided in two parts, in the first part, we are interested on thesecurity of web applications against XSS attack. We suggest a static analysis tool, based on taintingapproach, that allow to verify if a web application is secured or not, including filtering data in allinsertion points where XSS is possible. We also implement, an API filter, compatible with JavaCard 3 platform, that developers can import during the development of their applications. Thesecond part consists of verifying the conformance and the robustness of the implemented HTTPprotocol. For that we propose an intelligent fuzzing tool that includes a set of optimisations thatallows to reduce the time of fuzzing.

Key words : smart card, Java Card 3, SCWS, HTTP, XSS attacks, Fuzzing, Static analysis,Tainting.

vSommaire

Introduction gnrale 1

I Domaine dtude 7

1 Contexte dtude 9

1.1 La carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Les protocoles de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.1 Le protocole APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.2 Le protocole BIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.3 Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Les cartes puce serveur Web embarqu . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.1 Les cartes serveur Web SCWS . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4.2 Les cartes Java Card 3 Edition Connecte . . . . . . . . . . . . . . . . . . . 17

1.5 Cas dutilisation des cartes puce serveur Web embarqu . . . . . . . . . . . . . 21

1.5.1 Accs rapide et simple aux services offerts par la carte . . . . . . . . . . . . 21

1.5.2 Amlioration de linterface daccs aux services offerts par lmetteur . . . . 22

1.5.3 Scurit de connexion dun terminal distant une application . . . . . . . . 22

1.5.4 Exemple dapplication : le Disque Virtuel . . . . . . . . . . . . . . . . . 23

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Les attaques sur carte puce 25

2.1 Attaques sur cartes puce standards . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.1 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.2 Attaques logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.3 Attaques combines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Les attaques Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.1 Exemples dattaques Web les plus rpandues . . . . . . . . . . . . . . . . . 32

2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vi SOMMAIRE

II Scurit des applications Web Java Card 3 39

3 Les attaques Cross Site Scripting 41

3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1 Injection volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2 Injection persistante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Porte et exploitation des attaques XSS . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3.1 Solutions ct client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.2 Solutions ct serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Dtection de vulnrabilits dans un programme 53

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2.1 tat de lart des outils danalyse statique . . . . . . . . . . . . . . . . . . . 56

4.2.2 Lanalyse statique dans Java Card . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Analyse statique de bytecode Java Card 3 63

5.1 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Reprsentation dune vulnrabilit XSS . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Processus dexcution dun bytecode . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1 Zones de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.2 La frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.3 Les instructions de la JCVM . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.4 Findbugs et ses limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5 Analyse inter-procdurale et interclasses . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5.1 Prsentation du concept de CFG . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5.2 Analyse inter-mthodes et inter-classes . . . . . . . . . . . . . . . . . . . . . 72

5.5.3 Imprcision de lanalyse insensible au contexte . . . . . . . . . . . . . . . . 72

5.6 Analyse des flux de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6.1 La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6.2 tiquetage des conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

SOMMAIRE vii

5.6.3 Dtection des champs persistants . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6.4 Dpendance causale inter-mthodes . . . . . . . . . . . . . . . . . . . . . . 78

5.7 API de filtrage XSS pour des applications cartes puces . . . . . . . . . . . . . . . 79

5.7.1 Filtrage des donnes insres dans un lment HTML . . . . . . . . . . . . 80

5.7.2 Filtrage des donnes insres dans des attributs HTML . . . . . . . . . . . 80

5.7.3 Filtrage des donnes insres dans un code JavaScript . . . . . . . . . . . . 81

5.7.4 Filtrage et validation des donnes insres dans les proprits de style HTML 82

5.7.5 Filtrage des donnes insres dans des valeurs de paramtres dURL . . . . 83

5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Implmentation et exprimentations 85

6.1 Prsentation de BCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2 Interprtation abstraite de la JCVM . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2.1 Simulation dune frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2.2 Reprsentation dun item . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2.3 Plugin XSSDetector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3 Implmentation de JCXSSFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4 Exprimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4.1 Stratgie dvaluation de loutil danalyse statique . . . . . . . . . . . . . . 92

6.4.2 Temps de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4.3 Dtection de vulnrabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.4.4 Faiblesse de lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.4.5 Surcot du filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

III Scurit du protocole HTTP 103

7 Le protocole HTTP et les techniques de vrification 105

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.2 Les techniques de vrification et de validation de protocoles . . . . . . . . . . . . . 106

7.2.1 La vrification formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.2.2 Test de logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.3 Le Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.3.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7.3.2 tat de lart des logiciels de fuzzing . . . . . . . . . . . . . . . . . . . . . . 109

7.3.3 Le fuzzing sur carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

viii SOMMAIRE

7.4 Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.4.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.4.2 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.4.3 Les requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.4.4 Les rponses HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.4.5 Les champs dentte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.4.6 Accs aux ressources protges . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.4.7 Antmmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8 Fuzzing HTTP 117

8.1 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.2 Lapplication PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

8.2.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

8.2.2 Fonctionnalits de PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.2.3 Stratgie danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8.3 Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.3.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.3.2 tude des requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.3.3 Conception dune BNF (Backus Normal Form) HTTP interactive . . . . . 128

8.3.4 Modlisation des donnes de test . . . . . . . . . . . . . . . . . . . . . . . . 128

8.3.5 Configuration de Peach pour les cartes puce SCWS . . . . . . . . . . . . . 129

8.3.6 Le paralllisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.3.7 Fichiers de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.3.8 Analyse des vnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

9 Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT 133

9.1 Implmentation de PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

9.2 Rsultats de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

9.3 Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

9.3.1 Les modles de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

9.3.2 Les modles dtats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

9.3.3 Les mutations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

9.3.4 Configuration des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

9.3.5 Configuration du processus dexcution . . . . . . . . . . . . . . . . . . . . 141

SOMMAIRE ix

9.4 Exprimentations et Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

9.4.1 Temps dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

9.4.2 Failles dtectes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

9.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

IV Conclusions et perspectives 145

10 Conclusions et perspectives 147

10.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

10.2 Principales contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

10.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

10.3.1 Analyse des applications Web . . . . . . . . . . . . . . . . . . . . . . . . . . 149

10.3.2 Fuzzing HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

10.4 Synthse gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

V Annexes 153

A 155

A.1 Reprsentation du fichier assesment.xml . . . . . . . . . . . . . . . . . . . . . . . . 155

A.2 Fichiers de journalisation de Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . 156

B 157

B.1 Exemple de servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

B.2 Descripteurs de dploiement dune application Web . . . . . . . . . . . . . . . . . . 158

C 161

C.1 Notions Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

x SOMMAIRE

xi

Liste des tableaux

2.1 Slection dOWASP des dix vulnrabilits les plus rpandues en 2010 . . . . . . . . 32

3.1 Exemples dencodages pour outrepasser une liste noire . . . . . . . . . . . . . . . . 50

5.1 Exemples de caractres spciaux et leur encodage en entits HTML . . . . . . . . . 80

6.1 Temps de lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.2 Rsultat danalyse des applications Disque virtuel et JC3CreditDebit . . . 94

6.3 Rsultats danalyse de lapplication TestPackage . . . . . . . . . . . . . . . . . . . 95

7.1 Versions du protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.2 Les codes de retour dune rponse HTTP . . . . . . . . . . . . . . . . . . . . . . . 114

8.1 Stratgie de dtection des champs HTTP implments . . . . . . . . . . . . . . . . 122

8.2 Les requtes conditionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

xii LISTE DES TABLEAUX

xiii

Table des figures

1.1 Carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Commande APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Rponse APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Communication entre SCWS et tlphone mobile via le protocole BIP . . . . . . . 13

1.5 Architecture du SCWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6 SCWS dans une carte Java Card 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.7 Composents dune application Web Java Card . . . . . . . . . . . . . . . . . . . . . 19

1.8 Exemple dapplication Java Card 3 : le Disque Virtuel . . . . . . . . . . . . . . . . 23

3.1 Affichage dune fentre de dialogue par un script . . . . . . . . . . . . . . . . . . . 42

3.2 Attaque XSS persistante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Automate dune vulnrabilit XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Reprsentation des structures de la JCVM . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Exemple de graphe CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4 Suivi des flux de donnes inter-mthodes . . . . . . . . . . . . . . . . . . . . . . . . 79

7.1 Principe du fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7.2 Communication en HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

8.1 Vue gnrale de loutil de fuzzing HTTP . . . . . . . . . . . . . . . . . . . . . . . . 118

8.2 Fonctionnement de lapplication PyHAT sur une carte SCWS . . . . . . . . . . . . 119

8.3 Fonctionnement de lapplication Smart-Fuzz (cas des serveurs SCWS) . . . . . . . 123

8.4 BNF de lentte Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

8.5 Fuzzing sur SCWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

8.6 Fuzzing parallle sur plusieurs cartes puce . . . . . . . . . . . . . . . . . . . . . . 130

xiv TABLE DES FIGURES

1Introduction gnrale

1 Introduction

Les capacits des cartes puce en termes de taille mmoire et de puissance de traitement,permettent aujourdhui dintgrer un serveur Web. Les premires spcifications de cartes puce serveur Web embarqu ont t dfinies par lorganisation Open Mobil Alliance (OMA) proposantla spcification Smart Card Web Server SCWS qui dfinit linterface dun serveur HTTP/1.0 ouHTTP/1.1 embarqu dans la carte puce [All08a, All08c, All08b]. Cette spcification est destineaux cartes SIM. Elle permet une connexion locale entre le client HTTP (navigateur Web) du ter-minal et le serveur Web, ainsi quune administration distance via un protocole scuris (TLS)des applications charges dans le serveur. Elle fournit un ensemble de ressources statiques et dy-namiques gres par des applications Web (xHTML, JavaScript, etc.), et accessibles lutilisateurvia le client (navigateur Web). Les spcifications ETSI [ETS10b] dfinissent une API et des bi-bliothques disponibles pour la plateforme Java Card 2.2 utiles au dveloppement des applicationsWeb bases sur des servlets et fournissant des mthodes permettant une servlet de grer lesrequtes/rponses HTTP.

La spcification SCWS nest pas lie la Java Card 3 qui dfinit galement un serveur Webembarqu. La spcification de lOMA est plus simple, dissocie de Java Card et a pour but uniquede fournir un simple serveur Web embarqu. Elle correspond des cartes qui nont pas lesperformances suffisantes pour supporter lAPI Java card 3 et les protocoles TCP/IP. Pour com-muniquer avec le terminal bas sur la pile TCP/IP, des protocoles ont t dfinis dont BearerIndependent Protocol-BIP. Une passerelle BIP est ncessaire dans le terminal pour assurer la com-munication entre les deux parties. La version Java Card 3.0.2 est la spcification la plus rcentede la plateforme Java Card de Sun Microsystems (aujourdhui Oracle). Elle est disponible en deuxditions distinctes : classique et connecte.

La premire [JC309a, JC309e, JC309d] dcrit une volution lgre (API cryptographiques)de la plate-forme Java Card 2.2.2 et cible des marchs faible valeur ajoute en privilgiantla compatibilit avec les plates-formes prcdentes. Ce march reprsente aujourdhui plus dunmilliard de cartes par an.

La seconde [JC309c, JC309b, JC309f] est conue pour la nouvelle gnration de cartes puceet sadresse donc aux marchs les plus haut de gamme, en particulier les cartes SIM les pluspuissantes. Avec cette nouvelle technologie, la carte puce peut communiquer via les protocolesTCP/IP comme tout autre lment dun rseau informatique. Ainsi, elle est capable de fournir oudaccder des services du rseau.

2 TABLE DES FIGURES

La principale nouveaut de cette dition est lintgration de certains standards Web, notammentHTTP ou HTTPS. Elle conserve les principes des prcdentes versions (notamment, lexcutiondapplications multiples et une stricte isolation des applications) et permet le dploiement simul-tan dapplications des versions prcdentes (applets) et dapplications Web ( laide dun nouveaumodle de programmation hrit de JEE : les Servlets [Ser03]). Elle apporte galement des vo-lutions majeures au niveau des APIs et des fonctionnalits supportes (support de types String,programmation multi-tches, vrifieur de bytecode obligatoire, etc.).

Cette nouvelle technologie oblige repenser toute la scurit de ces dispositifs par rapport aumodle traditionnel des cartes puce. Lutilisation de cette technologie rend la carte plus ouverteet plus accessible aux utilisateurs et potentiellement des attaquants travers les protocoles rseautels que HTTP, TCP/IP et BIP. Des vulnrabilits peuvent provenir de failles dimplmentation desprotocoles rseau ou dun dveloppement non scuris des applications Web qui devraient respecterune mthodologie de dveloppement scuris.

2 Cadre de la thse

Les travaux prsents dans cette thse proposent un ensemble de solutions pour rpondre auxnouvelles problmatiques que posent les cartes puce serveur Web embarqu. Nous nous intres-sons particulirement la scurit deux niveaux. Le premier concerne la scurit des applicationsWeb contre des attaques par injection de code particulirement le cross site scripting, et le secondsintresse la vrification de la conformit et la robustesse du protocole HTTP implment dansles cartes puce.

2.1 Scurit au niveau applicatif

Dans cette partie nous nous intressons la dtection et la prvention des attaques Web parinjection de code. En effet, si lapplication nest pas soigneusement dveloppe, ne respectant pasune mthodologie de dveloppement scurise [OWA07, OWAa], alors des attaques Web standardspourraient se produire sur la carte puce. La plus rpandue de ces attaques est le cross site scriptingappele aussi XSS [KGJE09]. Elle consiste injecter des donnes contenant un script malicieuxdans une entre dune application (gnralement du JavaScript). Ce code est ensuite excut dansle navigateur dune victime lorsquune ressource de lapplication intgrant ce code est charge sansavoir t filtr au pralable. Cette attaque peut tre persistante si le code malicieux est sauvegarddans une ressource permanente dans le serveur, ou volatile si elle est gnre uniquement quandlutilisateur accde un lien hostile.

Linterprtation du code malicieux peut engendrer le transfert de donnes (cookie par exemple)vers le domaine dun pirate, modifier le comportement en local de lapplication (dans le navigateurde la victime) ou encore provoquer une indisponibilit de services.

Nous avons dabord considr les solutions existantes diffrents niveaux. Une premire solutionest lintgration de mcanismes de dtection de code malicieux au niveau du serveur (pare-feuxapplicatifs) [SS02, Mod] . Ce mcanisme possde lavantage dtre indpendant de lapplication.Cependant il est difficile de diffrencier le code malicieux du code JavaScript classique (prvu danslapplication). En gnral ces services ne dtectent que des squences connues comme hostiles,

TABLE DES FIGURES 3

ce qui est aisment contournable en rcrivant le code malicieux avec des encodages diffrents.Les mcanismes de dtection dintrusion IDS [PHP, Gui08] sont une variante de cette approche, ilsconsistent vrifier la lgalit des flux qui transitent entre le navigateur et le serveur afin dempcherque des ressources soient rediriges vers le domaine dun attaquant. Cependant, comme toutes lessolutions dynamiques (analyse pendant lexcution du code) cette approche engendre des cotssupplmentaires en termes de temps de rponse du serveur et doccupation despace mmoire parlIDS. De plus, cette approche ncessite gnralement une instrumentation du bytecode. Cettesolution ne conviendrait pas des dispositifs faibles ressources comme les cartes puce.

Une deuxime solution est un mcanisme lintrieur du navigateur autorisant ou non lexcu-tion du code JavaScript [MOZ]. La dcision de bloquer un code JavaScript se base sur la dtectionde squences particulires ou lutilisation de listes blanches et listes noires. Outre le fait que ladtection de squences est contournable, la dcision de classer un code comme potentiellementdangereux est de la responsabilit de lutilisateur. De plus, il ny aucune garantie que ce mca-nisme soit prsent ou actif dans un navigateur communiquant avec la carte.

La solution la plus recommande consiste prvenir les vulnrabilits XSS depuis la phase deconception des applications Web en renforant la scurit par de bonnes pratiques de dveloppement[OWAa]. Le dveloppeur doit considrer toutes donnes externes lapplication comme non fiableset donc potentiellement malicieuses. Les rponses retournes lutilisateur doivent tre filtres sicelles-ci sont gnres partir de donnes malicieuses. Cette solution est difficile appliquer carelle demande une attention ddie de la part du programmeur. Une alternative cette solutionconsiste utiliser une API de filtrage "de confiance" (dveloppe par une tierce partie) capable defiltrer efficacement une variable contenant une donne non fiable. Cependant, nous navons aucunegarantie que lapplication inclue bien une API filtrage, ni si tous les points dinsertion de donnesdans lapplication ont t filtrs. Une solution serait dutiliser la technique de dpendance causalepour suivre la propagation des donnes non fiables dans un chemin dexcution du code et devrifier si sur ce chemin les fonctions de filtrage sont appeles avant que la ressource non fiable soitretourne au client ou sauvegardes en mmoire persistante.

Une dpendance causale entre deux objets est prsente sil existe un flux dinformation direct ouindirect entre eux. Un exemple de technique pour vrifier si une telle relation existe est de marqueravec une tiquette les entres (les sources) dun programme et de propager celle-ci toute variableassigne partir de ces entres ou une variable possdant dj une tiquette (les drivations). Siles variables tiquetes atteignent des mthodes considres comme critiques (on parle des tatspuits) alors le systme considre quil existe une vulnrabilit potentielle. loppos, si une variabletiquete atteint une fonction permettant la dtection ou le nettoyage des donnes alors ltiquetteest enleve pour signifier que la donne nest plus considre comme critique.

Contribution. Notre solution est base sur une analyse statique appliquant la dpendance cau-sale permettant de suivre la propagation des donnes non fiables (tiquetes) dans un code et devrifier quelles sont nettoyes par une fonction de filtrage de confiance avant dtre retournesdans une ressource vers le navigateur de lutilisateur (XSS volatile) ou sauvegardes en mmoirepersistante (XSS persistante). Lobjectif de cet outil est de certifier quune application est scurisecontre les XSS (volatiles et persistantes) avant son chargement dans la carte puce.

Notre outil est bas sur le logiciel danalyse statique FindBugs [Fin] qui est capable deffectuerune analyse des flux de donnes partir dune abstraction de lexcution du bytecode. Cependant,

4 TABLE DES FIGURES

ce logiciel a des limites, en particulier, les analyses inter-procdurale et inter-classes ne sont pasprises en compte.

Nous avons donc amlior cette analyse afin dtendre FindBugs et permettre la propagationdes tiquettes entre objets de mme mthode ou de mthodes diffrentes qui appartiennent unemme classe ou de classes diffrentes. Ainsi, notre solution se compose de deux outils :

un outil danalyse statique, nomm XSSDetector sous forme de plugin pour FindBugs, capablede suivre lexcution abstraite dune application afin de vrifier si chaque entre passe parune fonction de filtrage de confiance avant dtre retourne lutilisateur ;

une API nomme JCXSSFilter base sur lAPI ESAPI dOWASP [ESA], compatible avec laplateforme Java Card 3 permettant de filtrer les donnes contre les attaques XSS.

Un programmeur dcidant dutiliser nos outils pour dvelopper son application utilise les fonc-tions de JCXSSFilter afin de nettoyer toutes les entres dans son programme. Puis une fois lap-plication ralise, il excute loutil danalyse statique afin de vrifier que toutes les entres duprogramme sont bien nettoyes avant dtre sauvegardes en mmoire persistante ou retournes lutilisateur. On peut signaler que notre outil peut tre tendu pour dtecter dautres cas quipeuvent tre grs par analyse statique.

2.2 Scurit au niveau du protocole HTTP

La deuxime contribution de nos travaux sintresse au protocole HTTP qui doit tre ncessai-rement ajout la carte afin dassurer la communication entre le serveur Web et le navigateur Web.Ce protocole est sans tat (chaque requte est traite indpendamment des autres). Il permet def-fectuer des demandes de ressources sur le serveur, adresses sous forme dURIs avec des requtescompltes par des enttes. Outre le fait quil fonctionne en mode texte avec des requtes trslongues, les nombreuses enttes composant une requte, ont chacune un comportement particulierquil faut caractriser.

De nombreux travaux bass sur les mthodes formelles ont t raliss pour la vrification desprotocoles [CMcMW04, MF05, Boc03, Hol91]. Cependant, cette approche permet simplement devrifier si des proprits spcifies sont respectes dans limplmentation du protocole. Dautrepart, la technique de validation par test consiste utiliser un jeu de tests qui est appliqu auprotocole pour vrifier diffrents critres dont : la conformit la spcification, la robustesse, lascurit. La technique de test la plus classiquement utilise pour lvaluation des protocoles rseauxest le fuzzing. Cest une technique dinjection de donnes invalides sur une cible. En fonction desrponses du serveur, il est possible de dduire des faiblesses dans la gestion des entres de la ciblequi peuvent tre dues au non respect de la spcification ou des failles de scurit. Il existe deuxgrandes classes de gnrations dentres invalides : partir de modles de donnes ou par mutationde squences [TDM08]. Dans notre cas, nous avons utilis la premire approche en se basant surle logiciel Peach [Micb].

Le choix de cette approche est motiv par le fait que les fabricants de cartes ne fournissentgnralement aucune information sur limplmentation des applications installes dans les cartes puce. Nous supposons donc que nous navons aucune connaissance sur limplmentation du proto-cole HTTP que nous voudrions tester, que ce soit le code source ou la possibilit dintrospecter lesinstances en cours dexcution (boite noire). Nous ne pouvons, donc quobserver les entres/sortiessans avoir connaissance du comportement interne de la carte.

TABLE DES FIGURES 5

Les inconvnients de la technique du fuzzing rsident dans le temps ncessaire pour appliquertous les jeux de tests possibles sur le systme cibl et aussi dans ltude des rsultats en sortieafin de dtecter ses faiblesses. Lapproche classique dun fuzzing pour tudier les rsultats dunesquence invalide consiste vrifier que la cible fonctionne encore correctement aprs chaque testenvoy (processus encore vivant, machine rpondant certaines commandes...). Mais dans notrecas, nayant accs quaux rponses nos requtes (et labsence de rponses parfois), notre ana-lyse consiste donc, comparer les couples requte/rponse aux rsultats attendus fournis par unoracle. Cependant, la gnration de cet oracle ncessite une caractrisation du protocole HTTPimplment. La caractrisation serait difficile raliser vu que les fonctionnalits HTTP dfiniesdans les spcifications (RFCs) [FGM+99] ne sont pas forcment toutes implmentes. En effet, laspcification HTTP utilise une terminologie qui dfinit pour chaque fonctionnalit si celle-ci estobligatoire ou non (utilisation des mots SHOULD , MAY et MUST ). De plus, le proto-cole implment ne respecte pas forcment la norme HTTP : absence de certaines fonctionnalits,rponses ngatives ou invalides certaines requtes, etc.

Contribution. Loutil de fuzzing que nous proposons est compos de deux outils complmen-taires PyHAT et Smart-Fuzz [KBBL11]. Loutil PyHAT permet davoir une description des fonc-tionnalits et des caractristiques de la cible, la plus prcise possible. Il se base sur lanalyse desrponses des requtes spcifies en entre.

La plus grande difficult est de pouvoir interprter les rsultats retourns, sachant que certainesrponses nindiquent pas si une erreur sest produite ou si le serveur Web ne respecte pas les RFCs.Pour chaque mthode, version de HTTP et enttes, il a fallu trouver un algorithme dvaluation.Certains cas sont dailleurs indcidables et PyHAT considre alors par dfaut que la carte supportece cas.

PyHAT gnre donc une grammaire rduite dont certains paramtres sont fixs. Cette gram-maire est ensuite exploite par notre outil de fuzzing Smart-Fuzz bas sur Peach pour la gnrationdes requtes HTTP envoys la carte. Lutilisation de cette grammaire rduit considrablement lenombre de donnes de test en se limitant uniquement des fonctionnalits implmentes.

Dans Smart-Fuzz, nous avons conu des modles de donnes dcrivant les requtes HTTP etles diffrents champs qui la composent. Ce sont ces modles que Peach utilise pour gnrer lesdonnes de test qui sont envoyes la carte. Cependant Peach ne compte pas parmi ses possibilitsde configuration le protocole de communication BIP. Nous avons donc dvelopp une interfacepermettant de grer cette communication. Nous avons galement optimis le temps dexcution denotre outil par la configuration dun fuzzing parallle sur plusieurs cartes. Smart-Fuzz est galementcompos dune application danalyse des vnements recueillis durant la phase du fuzzing et quise charge de vrifier les codes derreurs retourns et la cohrence des enttes et des rponses parrapport un oracle prdfini.

3 Organisation du document

Lensemble de ce document est organis en trois parties et contient en tout neuf chapitres. Lapremire partie sintitule domaines dtude, elle est compose de deux chapitres :

6 TABLE DES FIGURES

Le chapitre 1 est un rappel sur la dfinition dune carte puce et sur les volutions majeuresquelle a connues. Nous prsentons galement plus en dtails les cartes puce serveur Webembarqu auxquelles nous nous intressons dans cette thse ;

Le chapitre 2 aborde les attaques sur cartes puce en gnral (physiques et logiques) etprsente galement quelques exemples dattaques Web susceptibles de se reproduire sur lacartes puce serveur web embarqu.

La deuxime partie prsente la premire problmatique que nous avons traite et qui concerne lascurit des applications Web ddies des cartes puce (en particulier Java Card 3) contre desattaques XSS. Elle est compose de trois chapitres.

Le chapitre 3, dfinit la vulnrabilit XSS et ses consquences et prsente un tat de lart desdiffrentes approches utilises pour la prvention contre cette vulnrabilit ;

Le chapitre 4 prsente un tat de lart des outils de vrification de programmes en particulierlanalyse statique et la dpendance causale ;

Le chapitre 5 dtaille notre premire contribution durant cette thse qui consiste en une APIde filtrage de donnes compatible avec la spcification Java Card 3 et un outil de dtectionde vulnrabilits XSS bas sur une analyse statique du bytecode.

Le chapitre 6 prsente limplmentation de notre outil danalyse et des rsultats exprimen-taux.

La troisime et dernire partie aborde notre deuxime axe de recherche qui concerne la scuritdes cartes puce serveur Web embarqu au niveau du protocole HTTP implment. Elle estcompose de trois chapitres :

Le chapitre 7 dcrit le protocole HTTP et les diffrentes techniques de vrification et devalidation de protocoles. Nous nous attardons particulirement sur la techniques de fuzzingque nous avons adopte ;

Le chapitre 8 dtaille notre seconde contribution durant cette thse qui consiste en un outilde fuzzing qui comporte un ensemble doptimisations rendant le fuzzing plus intelligent ;

Le chapitre 9 dcrit notre implmentation de loutil de fuzzing et les rsultats exprimentauxobtenus.

Nous finissons ce rapport par une conclusion gnrale et de quelques perspectives pour destravaux futurs.

7Premire partie

Domaine dtude

9Chapitre 1

Contexte dtude

Sommaire1.1 La carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Les protocoles de communication . . . . . . . . . . . . . . . . . . . . . 11

1.3.1 Le protocole APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2 Le protocole BIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Les cartes puce serveur Web embarqu . . . . . . . . . . . . . . . 131.4.1 Les cartes serveur Web SCWS . . . . . . . . . . . . . . . . . . . . . . 141.4.2 Les cartes Java Card 3 Edition Connecte . . . . . . . . . . . . . . . . . 17

1.5 Cas dutilisation des cartes puce serveur Web embarqu . . . . 211.5.1 Accs rapide et simple aux services offerts par la carte . . . . . . . . . . 211.5.2 Amlioration de linterface daccs aux services offerts par lmetteur . . 221.5.3 Scurit de connexion dun terminal distant une application . . . . . . 221.5.4 Exemple dapplication : le Disque Virtuel . . . . . . . . . . . . . . . 23

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Dans ce chapitre nous prsentons notre domaine dtude, savoir, la carte puce serveurWeb embarqu. Avant de passer la description de ce type de cartes, nous commenons par unebrve dfinition de la carte puce et un historique de ses volutions les plus marquantes puis nousprsentons lensemble des diffrents protocoles utiliss dans les cartes serveurs Web embarqu.Nous finirons par prsenter lapport de lintgration dun serveur Web dans une carte puce travers quelques cas dutilisation et un exemple dapplication Web ddie ce type de cartes.

1.1 La carte puce

Une carte puce est un composant lectronique, dfini par un ensemble de normes tabliespar lorganisme international de normalisation (ISO), portant le nom de ISO 7816 [Sta]. Ellepermet deffectuer des oprations (stocker, calculer, etc.), de faon scurise. Les cartes puce sont

10 1. Contexte dtude

utilises dans diffrents domaines (bancaire, tlphonie, etc.). Sa puissance de calcul et sa capacitde stockage dinformations sont restreintes et peuvent tre diffrentes dune carte lautre.

Fig. 1.1 Carte puce

Il existe diffrentes plateformes logicielles permettant dutiliser les cartes puce. Java Card estlune des plateformes les plus utilises sur le march, elle reprsente lheure actuelle 95% descartes puce dans le monde. Java Card est un sous-ensemble des technologies Java adapt auxobjets faibles ressources comme les cartes puce. Il sagit dune plateforme portable, scuriseet multi-applicative qui intgre les avantages du langage Java :

la programmation oriente objet offerte par Java (contre lassembleur auparavant) ; une plateforme ouverte qui dfinit des interfaces de programmation (APIs 1) et un environ-nement dexcution standardis ;

lutilisation dune machine virtuelle permettant la portabilit des applications et une scuritaccrue lors de lexcution du code ;

une plateforme qui encapsule la complexit sous-jacente (assembleur) et les dtails du systmedes cartes puce.

Grce la machine virtuelle Java Card (JCVM), il est possible de charger dans la carte plusieursapplications (Applets) capables de sexcuter dans un environnement scuris. Les programmeschargs dans cette plateforme sont gnralement des applets bien que depuis la version 3.0 ditionconnecte il est possible de charger des servlets aussi. La compilation des applets Java gnredes fichiers CAP 2 (plateforme Java Card classique) ou des fichiers class (Java card 3.0 ditionconnecte).

1.2 Historique

Depuis leur invention, les cartes puce ont connu une trs grande volution, commenantpar de simples cartes mmoire, suivies par des cartes microprocesseur, puis des cartes multi-applicatives et enfin la plus rcente rvolution est la naissance des cartes puce serveur Webembarqu. Dans ce qui suit, nous prsentons un bref historique des volutions les plus marquantes :

1979 : Sortie des premires cartes microprocesseur : La Bull CP8 (1 Ko de mmoireprogrammable et un cur base de microprocesseur 6805) ;

1983 : Utilisation des cartes puce dans le secteur mdical et social. Dans la mme anne,apparaissent les premires cartes tlphoniques mmoire ;

1. Application Programming Interface ou API est un ensemble de fonctions, procdures ou classes mises dis-position par une bibliothque logicielle

2. Format pr-charg des applications Java Card (applets), gnr en dehors de la carte par un outil appelconvertisseur et partir de fichier class. Ce format est utilis pour des raisons doptimisation des ressources limitesdes cartes standards

1.3. Les protocoles de communication 11

1984 : Commercialisation des premires cartes mmoire bancaires, conues par Bull,Schlumberger et Philips.

1985 : Bull livre ses premires cartes bancaires dotes de microprocesseur ; 1991 : Lancement des premiers rseaux et services GSM (roaming, SMS, etc.), et des pre-mires cartes Subscriber Identity Module (SIM) ;

1996 : Cration du langage Java Card, un sous ensemble du langage Java ; 1997 : Bull, Gemplus et Schlumburger crent le Java Card Forum afin de discuter et deproposer de nouvelles spcifications. Java Card devient la plateforme standard de dvelop-pement des applications pour cartes puce. La Java Card a connu plusieurs versions, nouscitons particulirement : la Java Card 2.1, sortie en 1999, qui inclut des modifications de quelques APIs, notamment

au niveau de la cryptographie et des exceptions. la version Java Card 2.2 (en 2002) a pour principales nouveauts, la prise en charge descanaux logiques et lappel de mthodes distance.

la Java Card 2.2.2 est une mise jour de la prcdente ; elle inclut une amlioration delinteroprabilit avec de multiples interfaces de communication et des dispositifs de scu-risation normaliss. Elle fournit galement de nouvelles APIs pour un dveloppement plusconomique des applications. Cette version a t adapte pour correspondre aux normes descartes puce USIM 3, tout en tant compltement compatible avec les versions prcdentes.

2002 : la technologie de communication near field communication NFC a et lance parSony et Philips. Cest une technologie de communication sans-fil courte porte et hautefrquence, permettant lchange de donnes entre un lecteur et un terminal mobile ou entreles terminaux eux-mmes un dbit maximum de 424 Kbits/s et une distance de 20 cm aumaximum.

2008 : lorganisation Open Mobile Aliance (OMA) [All08a, All08c, All08b], a annonc laspcification dun serveur Web Smart Card Web server (SCWS), destin des cartes SIMpermettant dexcuter des applications plus riches sur les cartes puce, et communiquantsur le rseau via le protocole Bearer Independent Protocol(BIP).Dans la mme anne en mars 2008, Sun (dsormais Oracle) annonce la spcification JavaCard 3.0, dont la plus rcente version est Java Card 3.0.2 en 2010. Elle est dfinie en deuxditions distinctes, ldition classique et ldition connecte. Ldition classique est semblable la version Java Card 2.2, avec quelques amliorationsaux niveaux des APIs notamment au niveau cryptographique.

Ldition connecte dfinit un nouveau modle de programmation, les servlets et le supportdAPI et de fonctionnalits additionnelles telles que, le multi-taches (Multi-threading), lestypes String, le ramasse-miette, etc. Nous prsentons cette version plus en dtail dans lasection 1.4.2.

1.3 Les protocoles de communication

La communication entre une carte puce classique et un terminal se fait via un protocole decommunication appel Application Protocol Data Unit (APDU). Lintgration dun serveur Webembarqu dans les cartes puce ncessite le support du protocole HTTP permettant lchange

3. Carte puce ddie la tlphonie 3G


de donnes entre les applications et le navigateur Web. Dautre part, les cartes puce serveurWeb embarqu sont considres comme une entit dun rseau. TCP/IP sont les protocoles decommunication rseau les plus utiliss ; cependant, ils ne peuvent tre supports que sur des cartes hautes ressources. Le protocole BIP est le plus adapt pour des cartes moins performantes. Dansce qui suit nous prsentons brivement cet ensemble de protocoles.

1.3.1 Le protocole APDU

Le protocole APDU est le protocole de communication dfini dans la norme ISO 7816-4, per-mettant une applet sexcutant sur une carte puce de recevoir des requtes manant du terminalet denvoyer des informations en rponse. Le dialogue entre la carte et le terminal se fait via unchange de commandes et rponses APDU.

Une commande APDU est une requte envoye par le terminal vers une applet charge dansune carte puce. La figure 1.2 reprsente les diffrents champs qui la composent :

Fig. 1.2 Commande APDU

CLA : octet de classe dfini par lISO 7816 comme fournissant un certain nombre dinforma-tions sur la commande (exemples : 0xBC pour les cartes vitales, 0x0A pour les cartes SIM,0x00 pour les Mastercard/Visa) ;

INS : octet dinstruction ; P1 : paramtre 1 ; P2 : paramtre 2 ; Lc : taille des donnes envoyes la carte (0x00 si pas de donnes) ; Le : taille des donnes attendues en rponse.

La rponse APDU contient des informations sur le rsultat de la commande et ventuellementdes donnes si ncessaires. Elle est compose dun champ de donne et dun mot dtat (figure : 1.3).La donne doit respecter la taille indique dans le champ Le de la commande. Le mot dtat (statusword) est cod sur deux octets : SW1 et SW2. SW1 indique si la commande t correctementexcute et SW2 correspond des informations supplmentaires concernant la rponse. A titredexemple, la valeur du mot dtat : 90 00 signifie que la commande sest excute correctement.

Fig. 1.3 Rponse APDU

1.3.2 Le protocole BIP

Le protocole de communication BIP a t introduit dans la spcification ETSI [ETS10a], ilest ddi aux cartes de type (U)SIM. Il permet une carte (U)SIM dutiliser les moyens de com-munication de lquipement (tlphone) auquel elle est connecte, quel que soit la technologie de

1.4. Les cartes puce serveur Web embarqu 13

communication utilise. Il offre la fois la possibilit daccs des donnes portes par des in-terfaces (Bluetooth, IrDA, etc.) et des donnes rseau (GPRS, 3G, etc). BIP est dfini par unensemble de commandes proactives permettant douvrir les canaux de communication, dmissionet de rception des donnes.

OpenChannel : ouvre un canal de communication entre la carte et le tlphone ; GetChannelStatus : demande au tlphone ltat du canal de communication ; SendData : envoie des donnes au tlphone ; ReceiveData : se prpare recevoir des donnes ; CloseChannel : ferme un canal de communication.

La communication avec le terminal se fait via des protocoles standards UDP ou TCP (fi-gure : 1.4). BIP est le protocole de communication utilis dans les cartes puce Smart Card WebServer, en remplacement du protocole TCP/IP qui nest pas support. Nous prsentons ce type decartes dans la section suivante.

Fig. 1.4 Communication entre SCWS et tlphone mobile via le protocole BIP

1.3.3 Le protocole HTTP

Hypertext Transfer Protocol (HTTP) est le protocole de communication le plus utilis sur In-ternet. Il est bas sur le modle de communication client/serveur, le client HTTP correspondant aunavigateur Web partir duquel un utilisateur peut envoyer des requtes un serveur contenant desdonnes. La version HTTP/1.1 est dcrite dans la RFC 2616 date de juin 1999. Les cartes puce serveur Web embarqu utilisent ce mme protocole permettant aux applications Web de la cartedchanger des requtes/rponses avec le client Web hberg dans le terminal (le tlphone mobileen loccurrence). Dans la partie III de ce document, nous prsentons plus en dtail ce protocole etnous proposons un outil de fuzzing pour tester et vrifier la conformit et la robustesse du protocoleHTTP implment dans une carte puce.

1.4 Les cartes puce serveur Web embarqu

La stratgie des fabricants de cartes puce a toujours t dinventer des objets de plus en pluspuissants et de nouveaux standards pour chaque nouvelle fonction. Avec larrive du protocole BIP,il est devenu possible dtablir une communication entre la carte SIM et le terminal en utilisant leprotocole Internet Protocol (IP). Ainsi, lorganisation OMA a ralis la spcification de SCWS, unserveur Web HTTP embarqu dans des cartes SIM. Gemalto a ensuite fabriqu les premiers produitsde ce type de cartes SIM, capables de servir de serveur Web (SCWS), de sauvegarder lensemble


du contenu du tlphone, dimplmenter des fonctions NFC voir GPS indpendantes de celles dutlphone etc. Dautre part, Sun (aujourdhui Oracle) a voulu exploiter les nouvelles volutionsmatrielles des cartes puce, en annonant les spcifications Java Card 3 dition connecte, unenouvelle version de la plateforme Java Card. Cette plateforme est destine des cartes pucede haut de gamme. Elle supporte de nombreuses fonctionnalits et APIs la rendant trs prochede Java. La communication sur le rseau se fait via les protocoles TCP/IP qui sont cette foisdirectement supports sur cette plateforme.

1.4.1 Les cartes serveur Web SCWS

Le serveur Web SCWS est la technologie normalise par lorganisation OMA et ddie auxcartes SIM [All08d, All08a, All08c, All08b]. La spcification SCWS/1.0 dfinit un serveur WebHTTP/1.1 [All08a] intgr dans la carte puce dont le contenu est accessible via une URL. Unprotocole dadministration est galement dfini permettant de mettre jour et de configurer distance le SCWS, ce protocole est aussi bas sur le protocole HTTP/1.1.

Dans la version SCWS/1.1, la gestion distance par diffrentes entits de confiance est opti-mise. Chaque entit peut tre contrle pour vrifier quel contenu et quelle application elle a ledroit daccs en utilisant une URL, partir dun client HTTP/HTTPS install sur son terminaldistant.

Le premier produit de cartes SCWS a t ralis par Gemalto qui a dvelopp des cartes SIM SCWS combin la technologie Near Field Communication (NFC), sur la base dune plateformeJava Card 2.2 [Gem]. Ils ont galement propos le protocole Single Wire Protocol (SWP) dfini dansle standard European Telecommunications Standards Institute (ETSI), TS 102 588. Ce protocolepermet la carte de communiquer sur un seul fil avec un circuit NFC dans nimporte quel "objetintelligent". SWP nutilise quun seul contact, il permet ainsi de librer les deux contacts restants quipourraient tre utiliss pour tablir une connexion de type USB avec le tlphone pour communiqueren mode IP. En novembre 2008, Gemalto et LG Electronics ont annonc le lancement du premiertlphone mobile commercial avec un serveur Web embarqu sur une carte microprocesseur. LeSCWS nest pas encore une technologie trs rpandue, mais elle pourrait rvler tout son potentielavec dploiements de la technologie NFC.

Architecture du SCWS

Le SCWS comprend trois composantes : un serveur HTTP, un dpt (repository) contenant les donnes SCWS, un gestionnaire de tche dadministration qui met jour le dpt SCWS.Lentit de communication externe (navigateur Web ou application OTA) communique avec la

carte en utilisant les requtes/rpenses HTTP. Aprs tre relaye la couche de communication, larequte HTTP est envoye au serveur HTTP. La gestion des multi-requtes est assure par la couchecommunication, le serveur tant cens recevoir et grer une requte par session. Une session SCWScommence avec la rception de la requte et termine par lmission de la rponse. Le serveur HTTPse charge de transfrer la requte la destination correspondant lURL indique dans lenttede la requte. Cette URL peut pointer vers une ressource dynamique (servlet dans le cas de laplateforme Java Card 2.2), une ressource statique, ou une tache administrative (figure : 1.5).


Fig. 1.5 Architecture du SCWS

Les spcifications de lOMA dfinissent un contrleur daccs HTTP qui sappuie sur des en-sembles protgs. Un ensemble protg contient des ressources et la liste des utilisateurs qui sontautoriss y accder. Si le chemin daccs indiqu dans lURL de la requte correspond unensemble protg alors laccs la ressource demande est autorise uniquement aux utilisateursdfinis dans par ensemble.

Des politiques de scurit ont t mises en place pour prvenir un accs illgal aux ressourcesde la carte [NN11] :

1. sparation des URLs : les ressources statiques et les diffrentes servlets doivent tre sparesen terme dURL correspondant chacune delles.

2. pas daccs illgal une ressource statique : laccs ne doit pas tre possible : une ressource qui na pas de correspondance URL ; une ressource qui ne correspond pas lURL indique dans la requte ; une ressource non autorise.

3. pas dinvocation illgale de servlets : une invocation ne peut pas cibler : une servlet non enregistre ; une servlet dont aucune correspondance nest dfinie ; les servlets qui ne correspondent pas lURL indique dans la requte ; des servlets non autorises.

4. pas daccs aux ressources externes au serveur : les donnes de la carte puce qui sontexternes au serveur Web ne doivent pas tre accessibles.

5. ne pas envoyer des ressources en cas derreur : en cas derreur, la rponse ne doit pas contenirautre que le code derreur.

6. gestion scurise du contenu de la carte : les contenus de la carte (ressources statiques, applets,dpt) sont mis jour uniquement par ladministrateur.


Les cartes serveur Web bases sur la plateforme Java Card

Larchitecture dune carte puce base sur la plateforme Java Card 2.2 et contenant un serveurSCWS est prsente dans la figure 1.6. Dans le but davoir des applications interoprables four-nissant du contenu dynamique, les spcifications ETSI TS.102.588 [ETS10b] dfinissent une APIet des bibliothques disponibles pour la plateforme Java Card 2.2. Ces bibliothques permettentde dvelopper des applications Web bases sur des servlets et fournissent des mthodes permet-tant une servlet de traiter les requtes HTTP et de retourner des rponses au client (navigateurWeb)(exemple doPost() pour traiter les requtes POST). Les servlets sont des Applets enregistresdans le SCWS.

Fig. 1.6 SCWS dans une carte Java Card 2.2

Communication entre le SCWS et le terminal

Le SCWS est utilis en mode serveur lorsquil communique avec le client (navigateur Web) dutlphone et en mode client lorsquil est administr distance par lmetteur de la carte [All08c,GDS07]. Les protocoles TCP/IP ntant pas supports dans la plupart des cartes puce, unepasserelle SCWS doit tre installe dans le terminal pour assurer la communication entre le terminalet le protocole de transport local install sur la carte puce. La passerelle SCWS se charge detraduire les requtes HTTP reues par le client HTTP en commandes spcifique au protocole local(BIP en loccurrence). Elle assure aussi un contrle daccs scuris aux donnes du SCWS.

Le protocole BIP est le protocole de transport local le plus utilis. La carte communique avec letlphone laide de commandes BIP [GDB06]. Ces commandes sont constitues de un ou plusieursTLV (Tag Length Value) correspondant un tag, la taille des donnes et les donnes. Elles fontparties de la technologie SIM Application Toolkit (SAT) dfinie par lETSI. Le protocole BIP seulne suffit pas pour assurer la transmission des paquets. Deux protocoles de transport sont galementutiliss :

TCP est dploy sur le tlphone et utilis lorsque la carte SIM communique avec le tlphone ; CAT-TP (Card Application Toolkit Transport Protocol) est dploy sur la carte SIM et utilislorsque la carte communique avec un serveur distant.

Le terminal utilise une passerelle BIP permettant dintercepter les commandes BIP envoyespar la carte et de les transformer en commandes TCP afin de les renvoyer lapplication HTTP.


Cette passerelle joue le rle dun convertisseur de protocole. Pour communiquer avec la passerelle,la carte dispose des commandes BIP SIM Toolkit. chaque commande Sim Toolkit, le tlphonerpond via une commande de type TerminalResponse. De plus, la passerelle interagit avec la carte laide dvnements :

DataAvailable : commande dinitiation dun envoi de donnes du terminal la carte. ChannelStatus : commande pour demander la carte, ltat du canal de communication.

Toute communication entre la carte et le tlphone dbute par louverture dun canal de com-munication. Pour cela, le tlphone envoie la commande TerminalProfile afin dinformer la cartequil utilise le protocole BIP. Aprs cette commande, la carte attend la commande Fetch avantdouvrir un canal de communication avec le tlphone via la commande OpenChannel. La com-mande Fetch initie une communication avec le terminal. Si le terminal rpond correctement via lacommande TerminalResponse, le canal de communication est ouvert. Ensuite, la passerelle BIPcoute sur le port 3516 ddi aux communications HTTP et lutilisateur peut interagir avec leSCWS partir de son navigateur Web en utilisant ladresse http ://127.0.0.1 :3516/index.html.

1.4.2 Les cartes Java Card 3 Edition Connecte

La Java Card 3 est la dernire version de la plateforme Java Card, dont la plus grande volutionest ldition connecte. Elle apporte le support dun nouveau modle de programmation bas surdes servlets et louverture de la plateforme au rseau IP, via un serveur Web intgr et le supportdes protocoles standards TCP/IP et HTTP. Cependant, ces nouvelles fonctionnalits font que cettespcification nest supporte que sur des cartes puce haute de gamme (un processeur 32 bits, 128ko dEEPROM, 512 ko de mmoire ROM, 24 ko de RAM). Dans la suite, nous dsignons par lenom Java Card 3, ldition connecte.

Architecture de la plateforme

La plateforme Java Card 3 introduit dans son architecture une nouvelle machine virtuelle etun nouvel environnement dexcution qui supporte, en plus des applets classiques de la versionJava Card 2.2, des applets tendues et les applications Web bases sur des servlets. Ces diffrentesapplications se caractrisent respectivement par :

Les Applets classiques : communiquent avec le terminal via le protocole APDU (norme ISO 7816-4). peuvent implmenter uniquement les API compatibles avec la prcdente version.

Les Applets tendues : communiquent avec le terminal via le protocole APDU. supportent les API des applets classiques et aussi de nouvelles APIs telles que les Threads,

Strings, et GCF (Generic Connection Framework). Les Servlets : communiquent avec le terminal via le protocole HTTP ou HTTPS. Bases sur la spcification des Servlets version 2.4 [Ser03].

La plateforme Java Card est conue pour des cartes puce possdant des interfaces physiques haut dbit. Les protocoles vers des interfaces dE/S additionnelles ont t intgrs, comme :

Universal Serial Bus (USB), MultiMediaCard (MMC)


ISO 14443 (contactless) Le protocole de communication par APDU bas sur la norme ISO 7816-4 est aussi support.

Au niveau logique, la mise en uvre de la plateforme Java Card 3 doit fournir aux applicationsune interface rseau logique qui prend en charge les protocoles rseau suivants :

Internet Protocol (IP) Transmission Control Protocol (TCP) Universal Datagram Protocol (UDP) Transport Layer Security (TLS) HyperText Transfer Protocol (HTTP) Secure HyperText Transfer Protocol (HTTP sur TLS)

La bibliothque Java Card 3

En plus du nouvel environnement dexcution, la plateforme Java Card se caractrise par unebibliothque beaucoup plus riche qui rduit nettement lcart entre les langages Java Card et Java.Parmi les lments Java qui sont dsormais supports nous pouvons citer :

tous les types Java de base excepts les nombres virgule flottante (float et double) ; les structures de donnes de base, savoir les tableaux multidimensionnel et les objets detype String et StringBuffer

les supports natifs des fichiers classes avec ldition des liens dans la carte ; les classes utilitaires : un sous ensemble important du paquet java.util (Stack, Vector, Ha-shtable, Enumeration, Iterator, Date, Calendar, TimeZone, EventObject, EventListener, Re-sourceBundle, ListResourceBundle, Random, StringTokenizer, etc) ;

la bibliothque GCF (Generic Connection Framework) permettant douvrir des connexionsrseau et le paquetage microedition.io, compos de classes qui grent des connections gn-riques. Le paquetage java.io est en partie support incluant un ensemble de classes ncessaires la cration, la lecture, lcriture et le traitement des flux ;

la persistance dans Java Card 3 est diffrente des prcdentes versions. Un objet est dit per-sistant sil est dfini dans un champ de type Static, instance de javacard.framwork.appletou instance de javax.Servlet.ServletContext ou par accessibilit (si un champ persistantest affect un champ volatile, ce dernier devient automatiquement persistant) ;

les transactions ont t amliores, les transactions Java bases sur les annotations sontsupportes ;

le Multi-tches, permettant un ensemble dapplications de sexcuter simultanment. Ce-pendant les groupes de threads ou les threads fonctionnant comme des dmons, ne sont passupports.

la destruction automatique des objets non utiliss ; etc.

Les applications Web Java Card

Une application Web dans Java Card est une archive possdant lextension .war qui est ensuitedploye et instancie dans le conteneur Web. Elle est identifie par le chemin spcifique (rootpath) par lequel elle est adresse dans ce conteneur Web. Ce chemin est utilis :


comme identificateur unique (URI application) de lapplication sur la partie interne de laplateforme pour la communication inter-application ;

comme identificateur externe (URL) pour lenvoi de requtes HTTP par un client Web (na-vigateur Web).

Fig. 1.7 Composents dune application Web Java Card

Structure de fichiers contenus dans une archive .war Une application Web Java Card ala mme structure (rpertoires, fichiers de configuration, etc) que les applications Web JEE (fi-gure : 1.7. La seule restriction est quil nexiste pas de bibliothque spcifique chaque applicationWeb (le rpertoire WEB-INF/lib nexiste pas). De plus, la plateforme Java Card 3 dfinit un des-cripteur dapplication spcifique nomm javacard.xml [JC309c]. Le rpertoire WEB-INF contientles classes de lapplication Web et un descripteur de dploiement (web.xml). Les fichiers .class etles servlets sont stocks dans des paquetages. Ils sont accessibles via un chemin daccs relatif aunom du paquetage (package) qui les hberge.

Une servlet est une classe Java permettant la gnration dynamique de contenu. Elle reoitdes requtes HTTP (sous forme dobjets Java). La spcification des servlets pour la plateformeJava Card est un sous ensemble de la spcification des servlets Java v 2.4. Des fonctionnalits nonsupportes par la JCVM ont t supprimes telles que les pages JSP (Java Server Pages).

Le fichier META-INF/MANIFEST.MF dfinit des informations supplmentaires du descripteur.Le rpertoire META-INF contient galement le descripteur dapplication javacard.xml spcifique la plateforme Java Card.

Tous les autres fichiers inclus dans le fichier .war, en dehors de la hirarchie des rpertoiresMETA-INF et WEB-INF, ne sont pas directement utiliss par la plateforme. Ils sont simplementmmoriss sous forme de fichiers ressources de lapplication et correspondent des ressources Webstatiques desservies par le Web conteneur pour un client off-card.


La scurit de la plateforme Java Card 3

Comme ses prcdentes versions, la Java Card 3 dition connecte permet de bnficier desavantages du langage Java, principalement :

le typage : Java est un langage fortement typ permettant dviter les codes frauduleux ; les pointeurs ou rfrences : les oprations arithmtiques sont interdites sur les pointeurs ; la conversion de type : les conversions de type sont encadres avec des concepts de polymor-phisme, dencapsulation et dhritage.

Outre ces avantages, la plateforme offre des mcanismes de scurit dont certains taient djprsents dans les prcdentes versions et dautres ont t renforcs. Parmi ces diffrents mcanismes,nous citons :

La rcupration de mmoire : un mcanisme automatique appel ramasse-miettes (Gar-bage Collector) permet de librer les zones mmoires des objets volatiles (objets dure devie limite stocks dans une mmoire volatile) non rfrencs depuis une longue dure. Pourdes objets persistants (stocks dans une mmoire non-volatile) ce mcanisme peut tre appel la demande.

Lisolation des objets des applications grce un pare-feu (firewall) : le pare-feu estun mcanisme permettant de partitionner le systme en espaces protgs o chaque partieappartient un contexte de groupe diffrent. Un contexte de groupe est un paquetage Javacompos dun ensemble dapplets instances de classes de mme paquetage. Un objet ne peuttre accessible que par des mthodes de mme contexte de groupe. Toutefois, la plateformeoffre un mcanisme SIO (Shareable Interface Object) permettant une application de dis-poser dune interface de partage, pour rendre accessibles certains services des applicationsautorises de contextes de groupe diffrents. Il existe aussi un contexte propre la plate-forme appel le contexte JCRE (Java Card Runtime Environnement). Une application nepeut accder quaux services (APIs) de la plateforme pour lesquelles elle a les permissionsrequises. Cependant les applets appartenant au contexte JCRE peuvent accder tout objetde nimporte quel autre contexte de la plateforme.

La vrification obligatoire de bytecode : le vrificateur de bytecode tait optionnel dansles prcdentes versions. Il est maintenant obligatoire lors du chargement des applets sur laplateforme. Il consiste faire une interprtation abstraite du bytecode qui implique entreautre de verifier le type des objets manipuls, et la consistance de la pile.

La gestion de donnes volatiles : certains objets peuvent tre conservs en RAM, ce quipeut rendre certaines attaques plus complexes.

Un contrle daccs fin (Access Controller) : permet de protger laccs aux services dela plateforme et aux ressources dune application par dautres applications. Lors du charge-ment dune application un fichier policy est joint : il comporte toutes les permissions associes lapplication. Quand une application tente daccder un service, le systme rcupre lecontexte dexcution de lapplication et les permissions qui lui sont associes pour vrifier sioui ou non cette application est autorise accder ce service.

Une communication scurise base sur TLS : la communication sur le rseau est sujette de nombreuses attaques telles que lcoute de la transmission ou linjection de paquets, etc.TLS (Transport Layer Security) [HTT] permet de scuriser cette communication en crantun tunnel scuris entre le client et le serveur bas sur des algorithmes cryptographiques.

Une authentification des utilisateurs pour une gestion fine de laccs aux res-

1.5. Cas dutilisation des cartes puce serveur Web embarqu 21

sources : en effet la plateforme offre un mcanisme permettant de vrifier lidentit de luti-lisateur et ses droits daccs : les rles. Un rle dtermine les droits daccs dun utilisateurauthentifi des ressources protges, telles que les services bass sur les SIO et les ressourcesWeb.Dans la Java Card, deux types dutilisateurs sont dfinis : le propritaire de la carte etdautres utilisateurs (comme ladministrateur). Chaque utilisateur a une identit et des droitsdiffrents sur la carte.Lauthentification se fait via des identificateurs appels authenticators. Un identificateur est leservice spcialis dans lauthentification qui peut utiliser diffrents schmas dauthentificationtels quun mot de passe, un code PIN ou une information biomtrique. Ce service peut treutilis par une application ou un conteneur Web.

Les annotations de scurit : elles sont supportes dans Java Card 3 ; il sagit dun mca-nisme permettant de scuriser tout ou une partie de lapplication en dfinissant une politiquedexcution. Les annotations peuvent tre utilises pour protger les applications contre descomportements inattendus de la plateforme. Elles peuvent tre associes des classes ou desmthodes. La plateforme fournit un ensemble dannotations telle que @Sensitive.Confidentielqui signifie que la mthode ou la classe ne doit tre excute que dans un contexte authenti-fi. Cependant, les fournisseurs de la carte ou les dveloppeurs du systme ont la possibilitdimplmenter des annotations additionnelles.

1.5 Cas dutilisation des cartes puce serveur Web em-barqu

Lintgration dun serveur Web embarqu introduit de nouvelles problmatiques au domaine descartes puce. Vis--vis des volutions des tlphones mobiles qui permettent daccder Internetet tous les services offerts sur ce rseau, nous pouvons nous demander lutilit mme dembarquerun serveur Web dans la carte puce. Dans ce paragraphe. Nous rpondons cette interrogationpar un ensemble de cas dutilisation [KICLB10, KMM10].

1.5.1 Accs rapide et simple aux services offerts par la carte

Lutilisation des protocoles standards dInternet offrent une plus grande flexibilit dutilisationet dintgration de la carte puce aux quipements existants et aussi une plus grande aisancedadministration pour les metteurs de carte (industriels et oprateurs). Il est dsormais possiblede lire le contenu de sa carte, ou de faire des transactions bancaires ou commerciales en toutescurit partir de nimporte quel terminal contenant un navigateur Web. Les applications sonthberges dans un environnement scuris (la carte puce) et sont donc mieux protges que sur unterminal qui peut facilement tre compromis par un virus ou un programme malicieux. Lmetteurde la carte peut installer plusieurs services accessibles localement sur la carte via un navigateurWeb comme tout autre service dInternet. Laccs Internet ou un service disponible sur lacarte est donc transparent pour lutilisateur. Il peut tlcharger les applications quil souhaite enaccdant une page daccueil qui lui propose une liste de services et des contenus sur Internet. Cesapplications peuvent galement tre configures selon ses besoins. En demandant dinstaller une


application, le propritaire de la carte remplit un formulaire et lapplication installe sera configureselon ses besoins indiqus dans le formulaire.

Du ct de lmetteur de la carte, lutilisation dun serveur Web embarqu et du protocoleHTTP(S) standard permet une administration distance des applications installes sur la carte.En effet, un administrateur peut effectuer un suivi des applications, faire des mises jour ou desinstallations, condition que la carte soit connecte lInternet.

Le serveur Web embarqu est une solution lamlioration de la portabilit des applications etdes services en cas de renouvellement de lquipement mobile. En effet, en cas de changement detlphone, il ne serait plus ncessaire de recharger les applications utilisateur, tandis quil faudraitprobablement adapter le contenu la taille de lcran du nouvel appareil.

1.5.2 Amlioration de linterface daccs aux services offerts par lmet-teur

Lutilisateur souhaite avoir une interface daccs aux services offerts par la carte et qui soitconviviale et facilement personnalisable. Les standards du Web permettent davoir une exprienceutilisateur continue et quivalente celle disponible sur Internet. En utilisant des cartes standards,ces interfaces sont offertes par les lecteurs de carte tels que les tlphones mobiles et elles diffrentdun appareil lautre. Lintroduction dun nouveau modle dapplication compltement ddi aumode Web (servlet) offre aux oprateurs ou metteurs de cartes la possibilit de concevoir desinterfaces conviviales et standardises pour tous les lecteurs condition que celui-ci dispose dunnavigateur Internet. Dans le cas dune carte SIM, par exemple, une gestion locale (dans la carte puce) du carnet dadresses via une interface est facilement ralisable. De plus la forte connectivitde la carte permet denvisager un enrichissement de ce genre dapplications.

1.5.3 Scurit de connexion dun terminal distant une application

Une carte puce serveur Web embarqu est une carte forte connectivit avec une possibilitdaccder Internet via un rseau intermdiaire (par exemple, les rseaux 2G/3G pour les cartesSIM). Elle permet galement de renforcer laccs distance des applications critiques. En effet,sa proprit de tamper-resistance permet de garantir lidentit de lutilisateur qui tente daccder distance des donnes critiques (exemple : application bancaire).

Dautre part, laspect Web apporte lutilisation du protocole TLS pour la scurisation de bout-en-bout entre la carte et son correspondant, ainsi quune gestion fine des utilisateurs (dfinitiondes rles et des permissions), de leur authentification et de laccs aux diffrentes ressources de lacarte. Sajoute cela dautres aspects scuritaires qui ont t renforcs et rajouts dans la JavaCard 3 (vrificateur de bytecode, gestion de donnes volatiles, rcupration de mmoire).

La carte puce serveur Web permet galement de rsoudre le problme de dploiement dap-plications dans un environnement non contrl comme un tlphone portable, o des problmes telsque la suppression accidentelle dune application critique par un utilisateur final peut se produire.

Toutefois, des failles dans le dveloppement des applications Web peuvent ouvrir des portes diffrents types dattaques Web, tel que linjection de donnes malicieuses dans une page Web, levol didentifiants de session ou laccs non autoris des ressources [OWA07]. Un attaquant peut

1.5. Cas dutilisation des cartes puce serveur Web embarqu 23

Fig. 1.8 Exemple dapplication Java Card 3 : le Disque Virtuel

alors russir effectuer du vol dinformations, troubler le bon fonctionnement dun service, accder des ressources non autorises, modifier des donnes, etc. Les mcanismes de scurit (firewall,SSL, ..) ne suffisent pas pour protger les applications Web. En effet, un attaquant peut sattaquer la logique mme des applications, tout en respectant les contrles effectus lextrieur du serveurWeb. Les failles dans le dveloppement des applications Web seront les premires vulnrabilitsvises par lattaquant. Ainsi, une bonne conception et de bonnes pratiques de dveloppement delapplication Web simposent.

1.5.4 Exemple dapplication : le Disque Virtuel

Lapplication Disque Virtuel, dveloppe au sein de notre quipe, est un gestionnaire de fichierssur carte puce Java Card 3. Il permet de rcuprer et denvoyer des fichiers sur des serveursFTP distants. Ces fichiers peuvent tre chiffrs la vole par la carte ce qui garantit une scuritmaximale en cas de compromission du serveur Web. La carte contient les cls de dchiffrementdes fichiers ainsi que ladresse o se trouvent ces fichiers. La figure 1.8 illustre le mcanisme detransfert de fichiers via notre application.

Avant dtre charge dans une carte puce, notre application doit tre signe avec une cl luipermettant davoir des permissions spcifiques : par exemple, accepter les connexions extrieures.La signature permet donc dappartenir un domaine de protection spcifique. Le mcanisme detransfert de fichiers est trs simple. Lutilisateur doit possder un serveur FTP sur sa machine pourpouvoir envoyer ou rcuprer des fichiers. Par exemple (figure 1.8), pour le tlchargement dunfichier, la carte rcupre le fichier sur un serveur FTP distant, le dchiffre la vole puis lenvoiesur le serveur FTP local. Le mcanisme de sauvegarde est simplement linverse du tlchargement :la carte rcupre le fichier sur le serveur FTP local, le chiffre la vole puis lenvoie sur un serveurFTP distant.

Lavantage de cette application est davoir un outil permettant de manipuler un grand nombre


de fichiers stocks distance tout en garantissant leur intgrit. En cas de compromission du serveurWeb o sont stocks les fichiers, un attaquant ne pourra pas les utiliser sans la cl de dchiffrementassocie pour chaque fichier. On peut ainsi voir ce Disque Virtuel comme un espace de stockageo les donnes ne seraient visibles que par le propritaire de la cl. Lutilisateur peut rcuprer sesdonnes partir de nimporte quel terminal distant condition que celui-ci dispose dun serveurFTP local.

Notre application utilise des mcanismes de scurit, comme une authentification par code PINou encore les annotations. Nous avons rendu cette application intuitive afin de montrer les capacitsdes cartes puce Java Card 3 par rapport aux anciennes.

A travers cette application nous avons pu constater la facilit de dveloppement en Java Card 3,compar sa prcdente version Java Card 2.2. Java Card 3 se rapproche beaucoup de JavaME ce qui en fait un outil de dveloppement plus simple adapter pour les dveloppeurs Java(contrairement au dveloppement dapplications Java Card 2.2 o il est ncessaire davoir desconnaissances spcifiques). Les transactions laborieuses mettre en place en Java Card 2.2 ontgrandement t simplifies en Java Card 3 avec lutilisation des annotations. De plus, contrairement la Java Card 2.2, nous disposons dun ramasse miette automatique pour supprimer les objetsinutiliss en mmoire volatile. Le dveloppement a aussi t simplifi par le support de nouveautype de donnes comme les types Integer et String.

1.6 Conclusion

La carte puce serveur Web embarqu constitue une grande volution. Louverture de lacarte aux standards du Web HTTP/HTTPS offre un accs plus simple et plus rapide aux servicesquelle offre, et une communication plus scurise grce lutilisation du protocole TLS. Dans laplateforme Java Card 3, les mcanismes de scurit ont t renforcs par une gestion plus fine desutilisateurs et une vrification des applications avant leur chargement (vrificateur de bytecodeobligatoire) et pendant leur excution (pare-feu, isolation de contexte dexcution, ramasse miette,etc.). Dautre part, cette plateforme offre aux dveloppeurs un moyen de programmation plussimple adopter, qui se rapproche beaucoup de Java ME.

Cependant, le dveloppement dapplications Web ncessite dadopter des mesures afin de ga-rantir leur scurit et de prvenir certaines attaques. En effet, les attaques sur les applications Websont trs rpandues (XSS, CSRF, etc.) et leurs consquences peuvent tre trs graves. La cartemanipule des donnes trs sensibles. Une mthodologie de dveloppement dapplications Web estncessaire afin dviter quelles soient vulnrables aux attaques Web. De plus une mauvaise im-plmentation du protocole HTTP, qui ne respecterait pas la spcification, pourrait conduire descomportements inattendus et causer des failles et des vulnrabilits.

Dans les deux parties qui suivent nous allons respectivement aborder la scurit au niveauapplicatif et au niveau du protocole HTTP implment.

25

Chapitre 2

Les attaques sur carte puce

Sommaire2.1 Attaques sur cartes puce standards . . . . . . . . . . . . . . . . . . 26

2.1.1 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.2 Attaques logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.3 Attaques combines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Les attaques Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.1 Exemples dattaques Web les plus rpandues . . . . . . . . . . . . . . . 32

2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

La carte puce offre un environnement scuris pour lexcution de plusieurs programmes etla manipulation de donnes. De plus, elle propose des mcanismes dauthentification trs robustes.La scurit de la carte puce rside dans le fait quelle enferme des donnes scurises que lemicroprocesseur embarqu est en mesure de traiter en fonction des instructions fournies par lelecteur de carte. Afin de garantir la scurit de ces oprations, plusieurs dispositifs de pro

kamel nassima

Documents