UNIVERSITÉ MOHAMED VDépartement de Mathématique et Informatique

Faculté de SciencesRabat-Agdal

Pour l’obtention d’une Licence d'Études Fondamentales -Sciences Mathématiques et Informatique

Sous le thème :

Les cartes à puce sous la technologie Java card

Réalisé par :

Ibrahim Madi MOHAMED

Mezzour TARIQ

Les membres du Jury

2008-2009

1

Mr El Mamoun SOUIDI Professeur de l'Enseignement Supérieur faculté de Science Rabat (Encadrant)Mr Said EL HAJJI Professeur de l'Enseignement Supérieur faculté de Science RabatMlle G. ORHANOU Professeur de l'Enseignement Supérieur faculté de Science Rabat

Nous tenons à remercier tout d'abord notre encadrant qui nous a accompagné

de près durant tout ce travail Mr E.M Souidi pour sa disponibilité, sa confiance qu'il a

su nous accorder, sa patience qu'il a su exercer à notre égard et les précieux

conseils qui nous a prodigués tout au long de ce modeste projet.

Nous adressons également nos remerciements aux membres de jury qui

nous ont honoré en acceptant de lire et corrigé notre projet.

Enfin, je profite cette occasion pour présenter mes vifs remerciements à mes

parents, sans eux je ne serai plus ici aujourd’hui. Je pense en particulier à mon père

et ma mère, qui n’ont ménagé aucun effort pour que je puisse être ici à ce moment.

Ma tante Hassanati M’kouboi qui m’a offert mon premier ordinateur, mon petit frère

Youssouf qui m’a beaucoup aidé sur mes études et à mon inoubliable amie Mlle

BIRRATI Halidi, qui m’a encouragé, soutenu et beaucoup conseils.

En fin, je désire également exprimer mes vifs remerciements à tout ceux qui

ont contribué de près ou de loin à la réalisation de ce travail.

2

C’est poétique :

“ Je suis très émue de vous dire que j’ai bien compris l’autre jour que vous avez toujours une envie folle de me faire danser. Je garde un souvenir de votre baiser et je voudrais que ce soit là une preuve que je puisse être aimée par vous. Je suis prête à vous montrer mon affection toute désintéressée et sans calcul. Si vous voulez me voir ainsi dévoiler, sans aucun artifice, mon âme toute nue, daignez donc me faire une visite et nous causerons en ami et en chemin. Je vous prouverai que je suis la femme sincère, capable de vous offrir l’affection la plus profonde et la plus étroite amitié, en un mot, la meilleure amie que vous puissiez rêver. Puisque votre âme est libre alors que l’abandon où je vis est bien long, bien dur et bien souvent pénible ; ami très cher, j’ai le cœur gros ; accourez vite et venez me le faire oublier. A l’amour je veux me soumettre.”

Ce à quoi, Alfred de Musset brillant stéganographe répondit :

“ Quand je vous jure, hélas, un éternel hommage. Voulez-vous qu’un instant je change de langage. Que ne puis-je avec vous, goûter le vrai bonheur. Je vous aime, ô ma belle, et ma plume en délire couche sur le papier ce que je n’ose dire avec soin de mes vers, lisez le premier mot vous saurez quel remède apporter à mes maux.”

George Sand répondit évidemment :

“ Cette grande faveur que votre ardeur réclame, nuit peut-être à l’honneur mais répond à ma flamme”

3

Le thème du projet est sur les carte a puce avec la technologie Java Card. Cette technologie consiste au Développement et à la mise en place d'applet sur des cartes à Puces intelligentes, les "Smart Cards ". Ces applets sont développées avec une sous partie du langage Java.

Vous trouverez tout d'abord un état de l'art de la technologie ainsi qu'une présentation de tous les aspects qui sont nécessaires pour comprendre et développer des applications pour cette technologie.

Ensuite on va développer un tutorial décrivant les cartes à puce, expliquera également la technologie Java Card ainsi que la sécurité de la carte à puce. Enfin la dernière partie traitera d'un exemple d'application pour comprendre concrètement les étapes de réalisation d'une application java card dans une carte à puce.

C'est une occasion pour nous de se familiariser avec beaucoup d'environnement tel que Eclipse Netbeans, Java Card et Latex

The project subject is on te smart card with Java Card technology. This technology is the development and implementation applet on smart card chips, the "Smart Cards". These applets are developed with a sub part of the Java language.

You first find the state of the art smart card and the technology as well as a presentation of all aspects that are necessary to understand and develop applications with this technology.

Then we will develop a tutorial describing the smart card will also explain the Java Card technology and the security of the smart card. The last part deals with a sample application to understand the practical steps for the realization of an application in a Java Card smart card.

For as, it's a occasion to see lot of environment : Eclipse Netbeans, Java Card et Latex

4

Introduction.La carte à puce peut être perçu comme un support électronique de haute

technologie permettant d’intégrer des applications des applications d’intégrité et de

confidentialité dans des systèmes d’information.

La carte à puce est inventée part Roland Moreno en 1974, mais c’est une idée

allemande. Son succès remarquable, le doit plus sur le domaine de télécarte. La

carte à puce jouit des avantages considérables tout d’abord par sa taille qui lui

permet d’affronter les tests de torsion sans être détériorée. Puis par le fait que tout

est rassemblé au même endroit. Part sa conception, la carte à puce apparaît comme

élément hautement sécurisé d’un système pouvant garder et protéger des secrets.

La carte à puce propose des nouvelles fonctionnalités tout en gardant ses

qualités qui on fait sa réputation, un objet portable, personnalisé et sécurisé. Elle est

devenue une plate forme d’exécution à part entière. Les cartes multi applicatives

capable d’abriter plusieurs applications font leur apparution. Ces cartes deviennent

un support générique permettant d’embarquer plusieurs applications potentiellement

communicantes, en fournissant une fournissant une plate forme d’exécution

d’application utilisant des technologies objet à l’intérieur de la carte.

Avec plus d’un milliard d’unités fabriquées par an, la carte à puce est un outil

important de nos jours. On les rencontre plus particulièrement dans les domaines

suivants : Monétique : Carte bancaire, porte monnaie. Identification : Carte

d’identité nationale (ex : Comores), E-passeport (Comores). Enseignement : Carte

d’étudiant. Téléphonie mobile : Carte SIM. Secteur médical : Carte Vitale (en

France), carte SIS (en Belgique). Titre de transport : Passe Navigo (à Paris),

Oyster (à Londres). Sécurité informatique (authentification forte et signature

électronique). Dans ce cas la carte contient un crypto-processeur pour la génération

des clés et le stockage de la clé privée.

5

I- La Carte à puce.Une carte à puce est un carte plastique dotée d’au moins un circuit intégré ou

"puce" capable de contenir de l’information. Ce circuit intégré peut se limiter à des

circuits de mémoire non volatile ou bien comporter un microprocesseur capable de

traiter cette information. Son utilisation nécessite un équipement spécialisé qui sont

les lecteurs de la carte cette lecture peut s’effectuer avec ou sans contact avec la

puce.

1. Chronologie et historique de la carte à puce.

Presque plus de trois décennies que le premier prototype de carte à puce a

été conçu et pourtant elle est toujours aussi méconnue car volontairement entourée

par ses fabricants de beaucoup de secrets. Même la paternité de son invention est

de discussion et ainsi suivant le pays son inventeur change. Le bref historique ci-

après est celui qui semble néanmoins le plus universellement admis.

• En 1968 : Deux Allemand J.Dethloff et H.Grotrupp introduise un circuit intégré

dans la carte plastique.

• En 1970 : K.Arimuva au japon dépose un brevet sur la carte à puce.

• En 1974/78: Roland Moreno, le père de la carte à puce dépose 47 brevets

dans 11 pays.

• En 1978 : Dépôt du brevet SPOM pour la détermination d’une architecture

nécessaire au fonctionnement auto programmable à la puce. Une technologie

qui permet au microprocesseur de modifier son comportement s’il y a une

alerte, au pire sa destruction.

• En 1979 :

La sortie de la première carte intelligente munie d’une mémoire et d’un

microprocesseur (Motorola).

Création de la carte à mémoire et system (Schulemberger).

• En 1983 : Premier carte téléphonique à mémoire.

• En 1984 : Adoption de la "carte bleu" (Sur un prototype Bull-CP8).

Actuellement on est à version 'Bo'.

• En 1984-87 : Normalisation sous la référence ISO 7816.

• En 1997 : Apparition du premier java carde.

6

2. Les types des cartes à puce.

On distingue deux grandes familles de type de carte. Les cartes avec contact

et les cartes sans contact.

Table 2.1 _ ceci résume les différentes types de carte à puce

2.1. Les cartes avec contact.

Ce type de carte communique via un microcontact relié à la puce (microchip)

par des fils d’or. Cet assemblage se nomme micromodule. Les cartes à contact

doivent être insérées dans un appareil et dans un sens particulier (Exemple : les

cartes bancaires). On distingue les cartes à mémoire et les cartes à

microprocesseur.

Table 2.2 _ Le micromodule1

1 Source : Rapport de stage –I4 Globalisation des résultats dans les mesures de performance sur les plateformes Java Card ESIEE - Laboratoire Cédric

7

2.1. a. Les cartes à mémoire.

La carte à mémoire n’a qu’une la mémoire et l’interface d’Entrée/ Sortie, pas

de processeur donc pas de système d’exploitation. Elles réunissent sur un circuit

intégré de la mémoire non volatile permettant de stocker quelques centaines de bits

ainsi qu’un peu de logique pour effectuer les opérations de Lecture/ Ecriture et

exécuter les algorithmes d’authentification rudimentaire. Leurs fonctionnalités sont

limitées.

On distingue deux sortes de carte à mémoire. Les cartes à mémoire simple et

les cartes à mémoire à logique câblée. La plus part de leur caractéristiques sont

communes.

• Sur les cartes à mémoire simple, les seules possibilité sont le Lecture/ Ecriture

en mémoire.

• Les cartes à mémoire à logique câblé, l’accès peut être restreint avec un PIN.

Exemple : la carte téléphonique qui contient un compteur d’unité, un numéro

de série et une donnée secrète permettant d’authentifier la carte.

Les données déjà présentes sont traitées par des fonctions simples

programmées sur la puce, le circuit ayant un nombre limité de fonction qui ne peut

être reprogrammés.

Les cartes à mémoire ne peuvent pas être réutilisées et sont donc jetés à la fin

de leur utilisation. Les contactes et l’interface électrique ne sont pas normalisé. Leur

faiblesse sur la standardisation dans ce domaine rend compliquer l’identification lors

de l’insertion dans un lecteur. Ce dernier travaille par essaie/ erreur. Essaye différent

protocole jusqu’à obtenir une réponse, ce qui fait que son coût est très faible.

2.1. b. Les cartes à microprocesseur.

Elle contient une puce, ce dernier fait l’objet d’un brevet SPOM intégré dans

une seule puce de silicium, et constitue un micro-calculateur. Une fois connectée à

son lecteur, c’est un véritable ordinateur démuni d’un clavier et d’écran. Elle

fonctionne sous le contrôle d’un système d’exploitation inclus dans la puce. Ces

puces possèdent également un coprocesseur cryptographique qui réalise les

opérations de chiffrement et déchiffrement de manière câblée améliorant ainsi

grandement les performances. Ce coprocesseur cryptographique est associé à un

générateur de nombres aléatoires RNG (Random Number Generator).

8

Le microprocesseur présent sur les cartes à puce et le plus souvent un

microprocesseur 8-16-32 bits. Certaines cartes permettent de multiplier même la

vitesse d’horloge par 2-4-8 atteignant une vitesse d’horloge de 40 Mhz. Les cartes à

puce comporte trois sorte de mémoire : ROM, EEPROM et RAM.

• Le ROM (Read Only Memory) : Mémoire persistante, il est utilisé pour stocker

les programmes fixes de la carte, les routines du microprocesseur et de

donnée permanentes. On ne peut ainsi ni les modifier, ni les supprimer.

Aucune alimentation n’est nécessaire pour conserver les données.

• L’EEPROM (Electrical Erasable Programmable Read Only Memory) : Comme

le ROM, il peut conserver les données quand la mémoire n’est plus alimentée.

La différence et que l’on peut modifier les données stocké en mémoire. En fait

c’est l’équivalent du disque dur (H.D.D du PC) pour les cartes à puce.

• La RAM (Random Access Memory) : Mémoire volatile, elle est utilisée comme

espace temporaire pour modifier et stoker les données. Son contenu n’est pas

préservé à l’arrêt de l’alimentation.

D’autre technologie de mémoire sont également en train d’apparaître sur les cartes à

puce comme la mémoire Flash. Celle-ci est en effet plus efficace en espace et en

temps que le EEPROM.

2.2. Les cartes sans contacte.

Les cartes sans contacte, elles n’ont pas besoin d’être placées dans une

machine. Elles communiquent avec l’extérieur grâce à une antenne interne reliée au

micro-chip. L’énergie peut être fourni par une batterie interne ou captée par

l’antenne. Elles transmettent alors leurs données à un appareil par onde

électromagnétique. Ces cartes sont donc très populaires dans des situations

nécessitant des transactions rapides (Exemple : carte pour satellite).

Bien sûr, que ces cartes posent aussi quelques problèmes. Par exemple, la

distance de communication entre la borne de lecture et la carte est limitée (environ

10 cm). Un autre problème est que la carte est souvent en mouvement rapide dans

l’espace d’échange et que le temps pour réaliser la transaction est de l’ordre de 200

ms ce qui limite la taille des données à échange. Par ailleurs, ces cartes sont

beaucoup plus chères que les cartes à contact. Elles sont surtout utilisées pour les

applications où l’insertion et le retrait dans un lecteur ne sont pas pratiques.

9

Dans la suite de ce travail, on traitera spécifiquement des cartes à contact,

même si la plupart des concepts sont transportables directement aux cartes sans

contact.

3. Caractéristique physique des cartes à puce.

Le plus important standard définissant les caractéristiques des cartes à puce

qui fonctionne avec un contact électrique est le ISO 7816. On note 4/15 normes pour

les cartes à puce.

L’ISO 7816-1 : Elle définit les caractères physiques des cartes à puce

• La géométrie : Même si on connaît en général deux formats de la carte à

puce. Celui de la carte bancaire et celle de SIM.

• La résistance : Les cartes dois être opaque au rayon UV et X, résisté aux

détérioration de sa surface et protéger le puce lors de manipulation du

stockage lors d’utilisation normale. Elle ne doit pas être endommagée par un

champ magnétique statique.

L’ISO 7816-2 : Elle définit les aspects électriques et la situation des contacts sur la

carte. Elle spécifie les dimensions physiques (extérieur) des contacts de la puce. Elle

distingue huit différents contacts, dont deux est régie par une autre norme ISO, qui

est le 7816-12, utilisé pour l’USB.

• VCC : Tension d’alimentation positive de la carte fournie par le lecteur. La

tension varie entre 3-5 voltes.

• RST : C’est le Reset initialise le microprocesseur et rétablissement de

l’alimentation.

• CLK : Horloge fourni à la carte par le lecteur.

• GND : Masse électrique de la carte, sa tenson est zéro.

• VPP : Tension de programmation de la carte fournie par le lecteur, cette

option n’est plus utilisé actuellement.

• I/O : utilisé pour le transfère des données et des commandes entre la carte et

le lecteur en mode semi-duplexe. Un seul sens de communication n’est

autorisé à un moment donné.

10

Table 2.3 - Dimension et contact de la carte à puce

L’ISO 7816-3 : Cette norme définit l’interface électrique et les protocoles de

transmission :

• Les protocoles de transmission (TPDU, Transmission Protocol Data Unit) :

T=0 : protocole orienté octet, T1 : protocole orienté paquet, T=14 : réservé

pour les protocoles propriétaires,

• La sélection d’un type de protocole,

• La réponse à un reset (ATR, ou Answer To Reset en anglais) qui correspond

aux données envoyées par la carte immédiatement après la mise sous

tension,

• Les signaux électriques, tels que le voltage, la fréquence d’horloge et la

vitesse de communication. Fréquence d’horloge 1 -5 Mhz, et la vitesse des

communications < 115200 bauds:

L’ISO 7816-4 : Cette norme vise à assurer l’interopérabilité des échanges. Elle

définit les messages APDU (Application Protocol Data Units), par lesquels les cartes

à puce communiquent avec le lecteur. Les échanges s’effectuent en mode client-

serveur, le terminal ayant toujours l’initiative de communication.

L’ISO 7816-5 : Cette norme définit le système de numérotation et les procédures

d’enregistrement et d’attribution des identifiants des applications (AID, ou Application

IDentifier). Un unique AID est associé à chaque application et à certains fichiers sur

la carte. Ils sont représentés par des tableaux d’octets de taille allant de cinq à seize.

Les cinq premiers octets représentent le numéro d’enregistrement du fournisseur

d’application (RID, Registered Application Provider IDentifier en anglais) qui est

attribué par la Copenhagen Telephone Company Ltd. Ils sont suivis par l’identifiant

optionnel PIX (Proprietary Application Identifier eXtension) d’une longueur allant

11

jusqu’à 11 octets. L’identifiant RID est le même pour le paquetage et l'applet, mais le

PIX doit être différent.

L’ISO 7816-6 : Cette norme spécifie des éléments de données inter-industrie pour

les échanges, tels que le numéro du porteur de carte, sa photo, sa langue, la date

d’expiration, etc.

L’ISO 7816-7 : Cette norme définit les commandes inter-industrie pour langage

d’interrogation de carte structurée (SCQL).

12

II- Java Card.La technologie Java Card permet aux cartes à puce et à d’autres

périphériques à mémoire limitée de faire fonctionner des applications écrites en

langage Java. Une Java Card est donc une carte à puce sur laquelle il est possible

de charger et d’exécuter des programmes Java, appelés applets. Tout d’abord c’est

un langage de haut niveau, orienté objet, qui permet de développer des applications

de façon plus aisée.

La spécification java Card a été introduite pour plusieurs raison, notamment la

limitation du nombre de produit différent à développer pour la satisfaction des

besoins de tous les secteurs, la séparation des application du système d’exploitation

du système d’exploitation en fin offrir aux programmeurs d’applications. La portabilité

de leur code entre les différentes cartes disponibles.

Cette spécification Java Card s’agit d’une adaptation du langage qui était déjà

disponible pour les ordinateurs et qui tient compte des spécificités de la carte.

Rappelons que à nos jours la carte à puce représente l’une des petites plates-formes

informatiques. Sa mémoire est au minimum d’ordre 1 k de RAM, 16 K EEPROM et

24 K de ROM. Le plus grand défit de la technologie Java Card est d’intégrer les

composantes java sur la carte à puce tout en gardant assez d’espace pour les

applications.

De manière synthétique, on peut dire que la technologie Java Card, telle

qu’elle est vendue par Sun microsystems, définit une plate-forme sécurisée pour

cartes à puce, portable et multi-application qui intègre beaucoup des avantages du

langage Java.

1. Historique.

• En Novembre 1996 : c’est la spécification Java Card 1.0. Un groupe

d’ingénieurs cherche à simplifier la programmation des cartes à puce tout en

préservant la sécurité. Le langage de programmation Java apparaît comme la

solution. Schlumberger devint alors la première entreprise à acquérir une

licence en proposant un draft de quatre pages.

13

• En Février 1997, Bull et Gemplus se joignent à Schlumberger pour co-fonder

le Java Card Forum. Le but de ce consortium industriel est d’identifier et de

résoudre les problèmes de la technologie Java Card en proposant des

spécifications à Java Soft. Il a également pour objectif de promouvoir des

APIs Java Card afin de permettre son adoption par l’industrie de la carte à

puce. Aujourd’hui, le Java Card Forum regroupe les fabricants de cartes, Sun

et des utilisateurs. .

• En Novembre 1997, Sun microsystems présente les spécifications Java Card

2.0 qui consistent en un sous-ensemble du langage et de la machine virtuelle

Java. Elles définissent des concepts de programmation et des APIs très

différentes de celles de la version 1.0. Il n’y a encore rien sur le format des

applets téléchargeables.

• En Mars 1999 sort la version 2.1 des spécifications Java Card. Elle se

compose en fait de trois spécifications :

la Java Card 2.1 API Spécification,

la Java Card 2.1 Runtime Environment Specification,

la Java Card 2.1 Virtual Machine Specification.

Dans cette nouvelle version, il y a eu quelques modifications des APIs notamment au

niveau de la cryptographie et des exceptions. L’environnement d’exécution des

applets a également été standardisé. Mais la contribution la plus significative de la

version 2.1 est la définition explicite de la machine virtuelle de la Java Card (JCVM :

Java Card Virtual Machine) et du format des applets, permettant ainsi une vraie inter-

opérabilité.

• En Mai 2000, de petites corrections et clarifications de la version précédente

ont abouti à la version 2.1.1 des spécifications.

• En Octobre 2000, ce sont près de quarante entreprises qui ont acquis la

licence d’exploitation de la technologie Java Card :

• En Juin 2002, Sun microsystems publie la version 2.2 des spécifications dont

les principales nouveautés sont la prise en charge des canaux logiques et de

l’appel de méthode à distance RMI [133]. Elle ajoute aussi des considérations

14

sur la façon d’installer et d’effacer des applications sur la carte et quelques

nouveaux algorithmes cryptographiques.

• Et Octobre 2003, la publication de la version 2.2.1 [169, 170, 171] corrige l’API

de la version précédente et apporte quelques clarifications mais aucune

nouveauté.

2. La technologie Java Card.

La capacité de l’espace mémoire d’une carte à puce est très faible. Java Card

a été créé pour s’adapter à ces contraintes et construire une carte Java tout en

conservant suffisamment de place pour embarquer des applications. La plate-forme

Java Card ne peut être qu’une partie du langage Java qui a été allégé

considérablement et réduit au strict minimum pour effectuer ses propres applications.

Les avantages de la technologie Java Card pour les développeurs d’applications des

cartes à puce sont pour l’essentiel les mêmes que ceux que Java a pu apporter par

rapport aux langages de programmation classiques. On peut citer :

• La programmation orientée objet offerte par Java (contre l’assembleur

auparavant).

• La possibilité d’utiliser les environnements de développement existants pour

Java.

• Une plate-forme ouverte qui définit des APIs et un environnement d’exécution

standardisé.

• Une plate-forme qui encapsule la complexité sous-jacente et les détails du

système des cartes à puce.

• La sécurité est également au rendez-vous.

Il y a ensuite l’utilisation d’une machine virtuelle permettant aux applications

embarquées de rester complètement indépendant du hardware, de l’os et des

éventuelles spécifications du fabricant de la carte. Les Java Cards étaient parmi les

premières technologies de cartes à pouvoir héberger sur une même carte des

applications provenant de fournisseurs et de domaines d’utilisation totalement

différents. Ainsi, une fois la carte fournie à son propriétaire, il est encore possible de

télécharger des applets. Les applications de la Java Card peuvent donc être

continuellement mises à jour sans avoir besoin de changer de carte.

15

Fonctionnalité supportée du langage Java

Fonctionnalité non supportée du langage Java

- Certains types de base : booléen, byte,

short.

- Tableaux à une dimension.

- Package, classes, interfaces et

exception du langage Java.

- Héritage, méthode virtuelle, surcharge.

- création dynamique d’objet.

- Certain type de base : long, double, float.

- Caractère et chaîne de caractère.

- Tableau à plusieurs dimensions.

- Chargement dynamique de classe.

- Security manager.

- Ramasse-miettes et finalisation.

- Multi-tâches.

- Sérialisation d’objet.

- Clonage d’objet.Caractéristiques optionnelles

.- Le mot clé int et le support des entiers sur 32 bits sont optionnels.Table 3.1 _ Le tableau suivant résume les fonctionnalités supportées et non supportée de Java.

On distinguera aussi trois spécifications principales dans Java Card. Quelque

soit l’implémentation de utilisée, elle doit au minimum implémenté ses trois

spécifications.

• La spécification de la Java Card Virtuel Machine (JCVM) : Elle définit un sous-

ensemble du langage de programmation Java et la définition de la machine

virtuelle nécessaire pour les applications sur cartes à puce

• La spécification du Java Carde Runtime Environment (JCRE) : Elle décrit

précisément le comportement de l’exécution de la Java Card, comme la

gestion de la mémoire, des applets et d’autres caractéristiques

• La spécification de l’API : Elle décrit l’ensemble des paquetages et des

classes Java nécessaires à la programmation des cartes à puce mais aussi

quelques extensions optionnelles.

2.1. La machine virtuelle Java Card.

Le peu de mémoire disponible, aussi volatile que non volatile en font une

denrée rare qu’il ne faut surtout pas gaspiller, conséquence la machine virtuelle Java

Card se scindera en deux partie. La première implantée sur la carte et contient

l’interpréteur de byte code, alors que l’autre partie hors carte (situé à l’ordinateur)

vérifie le code et effectue des transformations sur ce code (convertisseur). Cette

16

séparation de la machine virtuelle permet de gagner de la place en mémoire, en

consacrant uniquement à l’exécution des applications.

Figure 3.1 _ Ceci résume l'architecture retenue par Java Card.

2.1. a. Le JCVM partie sur carte.

Cette partie contient l’interpréteur, il permet au applet d’être indépendantes du

matériel (hardware). Il exécute en particulier les tâches suivantes.

• Exécution des instructions du byte code et des applets.

• Contrôle de l’allocation mémoire et de la création des objets.

• Sécurisé le temps d’exécution.

Elle ne contient pas le vérifieur car trop gourmand pour être stocké et /ou

exécuté dans la carte. Elle ne contient non plus les chargements dynamiques de

classe car pas d’accès à l’endroit où sont stockés les fichiers de classe depuis la

carte. Mais aussi pas de vérifieur dans la carte permettant de vérifier

dynamiquement la validation de classe chargée.

2.1.b. Le JCVM partie sur l’ordinateur.

Cette partie comporte le vérifieur, le convertisseur et le signeur. Elle prétraite

tous les fichiers .Class contenu dans le package et les convertis en fichier .CAP

(converted Applet). Ces fichiers .CAP produits par le compilateur à partir du code

source. Le fichier CAP est ensuite chargé sur la carte à puce et exécuté par

l’interpréteur durant le processus de conversion. Le convertisseur exécute des

tâches qui sont normalement exécutées par la JVM au moment du chargement des

classes :

17

• Vérifie la formation des Images de Java classe.

• Vérifie les violations du sous langage Java

• Initialisation des variables statiques.

• La conversion des références symbolique de classe, des méthodes et des

champs en une forme plus compacte supportée par Java Card.

• En fin alloue, stocke et crée des structures de données de la machine virtuelle

pour représenter les classes.

Le convertisseur peut aussi prendre aussi prendre un ou plusieurs fichier

d’exportation différent du fichier .CAP puis charge ces fichiers d’exportation de ces

packages pour produire un fichier .CAP est un fichier exportation du package

converti si le package à importé de class d’autre package.

2.1. c. Les modifications du fichier Class.

En effet ce n’est pas le fichier class qui est chargé sur la carte. Mais un fichier

CAP pour Applet convertie. La technologie Java apporte deux nouveaux formats

binaires de fichier qui permet de faciliter l’installation et prévoir un format plus simple

a exécuté pour une plate forme en manque de ressource.

Le fichier Class n’est pas exécutable directement, il doit subir une phase

importante d’édition des liens, contrairement au fichier CAP prévu pour une

exécution immédiate et repose sur une phase d’édition de liens simplifiée. Par

exemple le fichier CAP charge dynamiquement les classes d’applet après la

conception de la carte.

En plus les fichiers d’exportation ne sont chargés pas chargé sur la carte et ne

sont donc pas utilisable directement par l’ordinateur, mais produit et consommé par

le convertisseur à des fins de vérification. Il ne contient en effet que des informations

sur les APIs publiques des classes et des signatures des méthodes et des champs.

2.2. Le JCRE et son modèle de fonctionnement.

Le JCRE, c’est un support de exécution d’Applet carte grâce à l’API Java

Card. Il gère les ressources da la carte (leur sécurité, la communication avec le

réseau, l’exécution d’Applet). Dans la machine virtuelle Java (Interpréteur de byte

code), le JCRE renferme la structure des classes d’application Java carde (APIs), les

extensions industrielle spécifique et les classes système. Le JCRE sépare

18

habituellement les applets de la propriété de la technologie des cartes à puce des

vendeurs.

La conception de programmation Java Card du point de vue global peu être

représentée comme un système comportant deux zones différentes. La première est

figée : il renferme le JCRE et le système d’exploitation ainsi que d’extension

éventuellement fournies par le fournisseur de la carte. La seconde modifiable :

constituée des Applets chargée dans la carte. L’application se situe exclusivement

dans la zone modifiable. En conséquence la seule connaissance de l’interface du

JCRE doit suffire pour permettre de développer des Applets.

Figure 3.1 _ Structure de Java Card2

À l’introduction de la carte dans la machine (CAD- Card Accetance Device), le

JCRE opère comme une carte à puce en établissant une communication APDU

(Application protocol data unit) d’Entré/sortie avec un serveur. Chaque APDU

contient soit un ordre du serveur à l’Applet, soit une requête de l’Applet au serveur

après l’initialisation du JCRE.

Le JCRE entre dans une boucle en attente d’un ordre APDU du serveur.

Celui-ci envoie des ordres APDUs à la Java Card pour l’intermédiaire d’une

communication utilisant les points de contacts d’entrée sorti. Quand une commande

arrive le JCRE sélectionne soit un Applet à exécuté comme indique dans la

2 Source : Rapport de stage –I4 Globalisation des résultats dans les mesures de performance sur les plateformes Java Card ESIEE - Laboratoire Cédric

19

commande soit envoie directement la commande à une applet déjà sélectionnée.

L’Applet sélectionnée prend alors le contrôle et exécute la commande APDU.

Une fois la commande exécutée, l’Applet envoie une réponse à l’application

hôte et redonne le contrôle au JCRE. Le procédé se répète à l’identique à l’identique

quand une nouvelle commande arrive.

2.3. L’API Java Card.

Les APIs Java Card consistent en un ensemble de classes spécialisées dans

la programmation d’applications de smart card conformément à la norme ISO 7816.

Beaucoup de classes de la plate-forme Java ne sont pas nécessaires et donc pas

disponibles sur la plate-forme Java Card.

Jusqu’à la version 2.1.1 des spécifications Java Card les APIs ne comprenaient

qu’un noyau de trois paquetages (java.lang, javacard.framework et javacard.security)

et un paquetage d’extension (javacardx.crypto).

Mais depuis la version 2.2 trois autres paquetages ont été ajoutés pour

supporter JCRMI : java.io, java.rmi et javacard.framework.service. Les classes dans

ces APIs sont compactes et succinctes. Elles incluent des classes adaptées à la

plate-forme java fournissant un support sur le langage et des services de

cryptographie. Elles contiennent également des classes spécialement conçues pour

supporter le standard ISO 7816 des smart cardes.

2.3.a. Le package java.lang.

Sur le plate forme Java Card, la package java.lang est un sous-ensemble du

package java équivalent java.lang. Les classes supportées sont Object, Throwable,

et quelques classes d’exceptions reliées à la machine virtuelle. La classe Object est

définie comme la classe racine de la hiérarchie des classes sur la plate-forme Java

Card.

Les classes d’exceptions fournies permettent également d’assurer une

sémantique cohérente lorsqu’une erreur apparaît à cause d’une violation du langage

de programmation Java par exemple, la machine virtuelle Java et celle Java Card

lanceront toutes les deux NullPointerException quand on voudra accéder à une

référence null.

20

Mais aussi beaucoup de méthodes java ne sont toutefois pas disponibles dans ces

classes. La classe Java Card Object par exemple ne définit qu’un constructeur par

défaut et la méthode equals.

2.3.b. Le package javacard.framework.

Le package javacard.framework apporte les classes et les interfaces

essentielles pour programmer des applets Java Card. Plus important, il définit la

classe de base Applet fournit la structure sous-tendant le modèle d’exécution de

l’applet en interaction avec le JCRE pour toute la durée de vie de l’applet. Il fournit

également une autre classe importante dans ce package, la classe APDU nécessaire

pour gérer les communications des applets avec l’extérieur.

Depuis Java Card 2.2, puisque la classe System du paquetage java.lang de la

plate-forme Java n’est naturellement pas supportée, la plate-forme Java Card

propose dans le paquetage javacard.framework la classe JCSystem afin d’accéder

aux services du JCRE. Cette classe permet notamment de gérer les mécanismes de

transaction et de partage d’objets au travers du pare-feu en association avec

l’interface Shareable mais aussi de créer des objets transients et d’appeler le

mécanisme de ramasse-miettes si celui-ci est présent. C’est aussi dans ce

paquetage que se trouve l’interface MultiSelectable qui indique si l’applet accepte les

canaux logiques et la multi-sélection.

Enfin, ce paquetage fournit d’autres classes comme la classe OwnerPIN qui

propose une implantation de référence du mécanisme de PIN. Les deux autres

classes restantes sont AID pour faire des opérations sur les AIDs et Util qui propose

des méthodes souvent utilisées dans la programmation en Java Card.

2.3.c. Le package javacard.security.

Le paquetage javacard.security fournit une architecture aux fonctions

cryptographiques supportées sur la plate-forme Java Card. Sa structure, Son

implémentation est basée sur le package Java du même nom java.security de la

plate-forme Java. Il définit notamment la classe KeyBuilder pour fabriquer des clés

cryptographiques de différents types et des interfaces pour les manipuler.

Il met principalement à disposition du programmeur les classes abstraites

RandomData, Signature, MessageDigest, et Checksum pour générer respectivement

21

des nombres aléatoires, des signatures, des empreintes et des sommes de contrôle.

Il définit également l’exception CryptoException pour la gestion des différentes

erreurs.

2.3.d. Le package javacardx.crypto.

Le paquetage javacardx.crypto est un paquetage d’extension. Il contient les

classes cryptographiques et les interfaces dont les spécifications sont régulées par

les Etats-Unis. Il définit une classe abstraite de base Cipher qui supporte les

fonctions de chiffrement et de déchiffrement pour les différents algorithmes implantés

sur la carte.

En effet, dans le domaine de la cryptographie, Java Card n’impose pas aux

vendeurs d’implanter tous les algorithmes cryptographiques, ni même un ensemble

minimal. On peut ainsi se retrouver avec des Java Cards aux possibilités bien

différentes dans les domaines cryptographiques.

2.3.e. Le paquetage java.io.

Ce paquetage est un sous-ensemble strict de celui de la plate-forme Java. Il

ne propose qu’une exception IOException pour indiquer un problème de

communication survenu. Celle-ci n’est présente que pour les besoins de JCRMI qui

en hérite au travers de la classe RemoteException du paquetage java.rmi.

2.3.f. Le paquetage java.rmi

Dans la dernière version (2.2) de la spécification Java Card a été introduit une

version simplifiée des appels de méthode à distance de Java (ou RMI pour Remote

Method Invocation) permettant de dispenser le programmeur de la gestion des

APDU. Ce paquetage définit l’interface Remote qui identifie les interfaces dont les

méthodes peuvent être appelées par des applications clientes du CAD.

Il définit également l’exception RemoteException qui pourra être lancée pour

indiquer qu’une exception s’est produite lors de l’exécution d’un appel de méthode à

distance. Cependant, le protocole RMI est toujours transporté dans des APDU.

En résumé, Java Card permet :

• De séparer les applications pour carte à puce de leur environnement

d’exécution, autorisant la diffusion de cartes à puce génériques et d’applets

portables,

22

• Le chargement d’application dynamiquement durant la vie de la carte,

• La présence de plusieurs applications sur une même carte pouvant être

sélectionnées successivement.

• De structurer des applications librement en gérant des objets persistants, sans

forcément passer par un système de fichier.

2.3.g. Le paquetage javacard.framework.service.

Ce paquetage fournit un ensemble de classes et d’interfaces qui permettent à

une applet Java Card d’être conçue comme le regroupement de plusieurs services. Il

fournit aussi une classe d’agrégation, appelée Dispatcher qui propose des méthodes

pour ajouter et retirer des services de sa base interne, et pour router les commandes

APDUs vers les services enregistrés.

Le paquetage contient également l’interface Service que doivent implanter

tous les services. Cette interface propose toutes les méthodes nécessaires pour

traiter les commandes APDUs. Il existe aussi deux sous-interfaces de Services,

RemoteService et SecurityService pour l’implantation de services aux fonctionnalités

plus spécifiques.

• RemoteService est utilisé pour définir des services qui permettent à des

processus distants d’accéder aux services présents sur la Java Card.

• SecurityService est utilisé pour définir des services qui fournissent des

méthodes pour connaître le niveau de sécurité actuelle (e.g. intégrité des

données entrantes, confidentialité, etc.).

La classe BasicService fournit une implantation par défaut des méthodes définies

dans l’interface Service et par conséquent, la fonctionnalité de base d’un service.

Tous les services seront donc des sous-classes de BasicService.

Par ailleurs, afin de permettre à un programme Java fonctionnant côté poste

client d’appeler des méthodes sur les objets distants d’une applet Java Card, le

paquetage fournit les classes CardRemoteObject et RMIService. Ces classes

contiennent donc les fonctionnalités minimales exigées pour permettre l’invocation

de méthodes à distance pour la plate-forme Java Card (JCRMI).

23

3. La sécurité Java Card.

En effet, sur un ordinateur classique les sécurités intégrées au langage et le

typage fort sont normalement assurées par la machine virtuelle en association avec

le vérifieur de bytecodes. Or, historiquement il n’était pas possible d’embarquer de

vérifieur à cause des faibles capacités mémoire des cartes à puce. C’est pourquoi,

les spécifications Java Card ont introduit un mécanisme orthogonal : le pare-feu…. Il

existe plusieurs types de mécanismes sécuritaires fournis par Java Card : Ceux qui

sont intégrés au langage java et ceux qui sont rajoutés pour pallier l’absence de

vérifieur embarqué.

3.1. Sécurité du langage.

Le langage Java Card étant un sous ensemble du langage Java, il nous

conviendrait de faire un bref récapitulation sur les bases de la sécurité du mère

langage Java.

• Le langage Java est fortement typé. Ainsi on ne peut pas convertir des entiers

en pointeurs.

• Les variables doivent être initialisées avant d’être utilisées.

• Le niveau d’accès de toutes les classes, méthodes et champs est strictement

contrôlé. Par exemple, une méthode privée ne peut pas être invoquée à

l’extérieur de sa classe.

• Le langage Java n’a pas de pointeur arithmétique.

3.2- Sécurité supplémentaire des Java Cards.

Pour le mécanisme rajouter pour pallier l’absence de vérifieur embarqué on

note :

• Objets persistants et temporaires : Les objets sont stockés par défaut dans la

mémoire persistante. Pour des raisons de sécurité et de performance la plate-

forme Java Card autorise également des données temporaires comme des

clés de session à être stockées dans des objets temporaires de la mémoire

RAM. Quand la carte est retirée ou quand l’applet sélectionnée est libérée

ces objets reprennent leur valeur par défaut (zero, false ou null).

• Pare-feu d’applets : La sécurité et l’intégrité du système JCRE réside dans le

fait que les Java Cards sont protégées par le pare-feu d’applet. Celui-ci isole

24

l’applet en séparant son espace de celui du système. Les applets ne peuvent

pas se voir entre elles à moins d’être définies dans le même package.

• Partage D’objets : Voici la façon dont les objets sont partagés dans le

système Java Card : Le JCRE est un utilisateur privilégié qui a un accès total

aux applets et aux objets crées par celle-ci. Ensuite une applet a accès aux

ressources du JCRE `a travers les points d’entrée des objets. Enfin les

applets peuvent partager des objets qui implémentent des interfaces

partagées. Les applets et le JCRE peuvent partager des données à travers

des tableaux globaux.

25

III. La sécurité de la carte à puce.La sécurité d’une carte à puce est une merveille de technologie basée sur les

techniques les plus abouties en matière de sécurité. Toutefois, même si certains

acteurs du monde de la carte (e.g. le secteur bancaire) par une mauvaise intégration

et une mauvaise utilisation de la carte à puce dans un système global ont pu mettre

à mal son crédit, elle jouit encore de la réputation d’être le périphérique le plus

sécurisé au monde.

Dans ce domaine de la sécurité, les fabricants de produits des Technologies

de l’Information et les attaquants se livrent une véritable guerre. Et comme dans

toutes les guerres, on assiste à une escalade des protections. Si aujourd’hui son

niveau de sécurité est si élevé et si reconnu c’est grâce à une multitude de

caractéristiques sécuritaires que nous allons détailler ci-après.

1. Les protections que apporte la carte à puce.

1.1. Au niveau physique.

La sécurité d’une carte réside dans son apparence. Les encarteurs utilisent

des technologies d’impression sophistiquées lors de la fabrication du corps de carte.

Il peut y avoir différentes couches d’impression à diverses profondeurs dans le

plastique du corps de carte. Souvent le corps de carte comprend aussi un

hologramme et il possède un embossage des informations relatives au porteur.

Le matériau constituant le corps de carte peut aussi être de différentes

natures selon le niveau de résistance souhaité. Ces différentes protections visent à

faire échouer les attaques chimiques d’extraction du micromodule. Les constructeurs

jouent aussi sur le design du microcontact pour rendre la puce plus fragile à

l’extraction. Cet ensemble de techniques de défense, bien que contournables par

des spécialistes de la micro-électronique et des matériaux, est une première barrière

assez difficile à franchir pour le non-initié. Le but des fabricants est de pousser

l’attaquant à endommager la puce lors de l’ouverture, la rendant ainsi inutilisable.

Les normes ISO 7816 sont principalement fonctionnelles, elles assurent aussi

un certain niveau de sécurité au travers de la multitude de tests de caractérisation

effectués. On pensera tout particulièrement à l’ISO 7816-1 qui porte sur :

26

• la protection contre les ultraviolets et les rayons X;

• le profil de surface des contacts ;

• la résistance mécanique des cartes et des contacts (au pliage, à la torsion) ;

• la résistance électrique des contacts ;

• l’interférence électromagnétique entre les pistes magnétiques éventuelles de

la carte et de ses circuits intégrés ;

• l’exposition de la carte à des champs magnétiques ;

• l’exposition de la carte à une décharge d’électricité statique ;

• la dissipation thermique du circuit intégré.

1.2. Au niveau matériel.

C’est la base de la pyramide sécuritaire que constitue une carte à puce. S’il

peut être pris en défaut, alors c’est tout l’édifice qui s’écroule. Les constructeurs de

puces ont donc rivalisé d’ingéniosité pour assurer un haut degré de sécurité. Une

des premières sécurités a été d’introduire un numéro de série unique pour chaque

pièce. Puis, avec le développement de puces de plus en plus complexes, les

systèmes d’exploitation devenaient de plus en plus conséquents et donc sujets à de

plus en plus de bugs. Aussi, les constructeurs se sont mis à intégrer des mémoires

de type PROM (mémoire persistante) qui permettaient de corriger les problèmes en

ajoutant du code aux bonnes adresses mémoire.

Certaines attaques nécessitent un accès direct à la puce. Dès lors, les

fondeurs sont mis à intégrer des détecteurs sur la carte afin de déterminer son

utilisation dans un environnement hostile. Par exemple, on peut trouver sur une carte

des détecteurs de lumière ou d’autres rayonnements, des détecteurs de

température, des détecteurs de tension et de fréquence. Tous ces mécanismes

même s’ils ne sont pas garants de l’inviolabilité de la puce, ont pour but de rendre le

travail d’un attaquant plus difficile.

En effet, l’attaquant ne disposant pas des compétences et du matériel

nécessaires à la désactivation de ces détecteurs devrait voir ses attaques échouer. À

l’inverse, un attaquant qualifié pourra, lui, passer outre ces dispositifs de protection et

avoir un accès direct à la puce.

27

Parmi les autres dispositifs de protection qu’on trouve sur une carte il y a le

chiffrement des données sur les bus et dans les mémoires, mais aussi

l’enfouissement des bus sensibles dans les différents niveaux de métallisation, la

pose de leurres (i.e. pistes reliées à aucune autre), la redondance de certaines

fonctionnalités matérielles et la dissémination de l’information. Ce dernier point

signifie que des octets situés à des adresses mémoires consécutives ne sont pas

forcément situés à des positions consécutives sur le circuit.

Deux autres mécanismes sécuritaires fondamentaux sur la carte sont le co-

processeur cryptographique qui accélère les calculs cryptographiques et rend leur

observation beaucoup plus difficile, ainsi qu’un vrai générateur de nombres

aléatoires pour tirer les aléas nécessaires dans quasiment tous les algorithmes

cryptographiques.

1.3. Au niveau logiciel.

Le troisième niveau de sécurité des cartes à puce est réalisé par le logiciel et

plus particulièrement par le système d’exploitation. Le système implante souvent une

politique très stricte de contrôle d’accès aux données. L’accès à des données

nécessite la vérification de règles qui dépendent des opérations à réaliser. Le

système d’exploitation assure aussi l’intégrité des données via des mécanismes de

checksum sur toute ou partie de la mémoire mais aussi via des mécanismes de

transaction et d’atomicité des opérations.

C’est encore lui qui sécurise les entrées/sorties, en les chiffrant par exemple. Il

peut également implanter des mécanismes de migration du code et des données

dans les mémoires afin d’empêcher un attaquant de les localiser. Sur certaines

puces le système d’exploitation peut aussi changer les fréquences de travail pour

perturber les observations de l’attaquant mais il peut également assurer qu’une suite

d’opérations va s’effectuer en un nombre de cycles constant indépendamment des

données traitées afin que l’observateur ne puisse déterminer ces données.

Pour résumer, le système d’exploitation est essentiel pour assurer la sécurité

des applications qui feront appel à ses services. La sécurité apportée par le logiciel

est aussi la conséquence de l’application de techniques de programmation

sécurisée. Ainsi, tous les grands développeurs d’applications ou de systèmes

d’exploitations pour carte à puce disposent de guides sécuritaires de programmation,

28

à l’état de l’art des attaques, voire même en avance, et qui décrivent les règles de

bonne programmation (e.g. décrémentation du compteur d’essais du PIN avant de

faire la comparaison, description des informations nécessaires pour restaurer les

états une transaction échouée, etc.).

2. Les attaques classiques.

2.1. Les attaques non-invasives.

En opposition avec les attaques invasives, les attaques non-invasives ne

nécessitent pas de «détruire» la carte à microprocesseur cible. Ainsi, certaines

attaques non-invasives peuvent être réalisées à l’insu et au détriment du porteur de

la carte. De ce fait, les risques liés aux attaques non-invasives sont généralement

considérés comme réels. Parmi les attaques non-invasives, nous distinguons les

attaques basées sur l'observation de l'environnement de la carte de celles basées

sur sa perturbation.

2.1.a. Les attaques hors conditions opérationnelles.

Elles portent sur la connaissance de la tension et la fréquence d’alimentation

mais aussi de la température. L’idée principale, c’est de manipuler la puce en dehors

de fonctionnement normal. Les attaques sur la fréquence d’alimentation peuvent

servir à un attaquant de mieux comprendre les opérations faites dans la puce en les

combinant avec des procédés d’observation de canaux cachés.

Exemple : les fraudeurs testent souvent le générateur de nombre aléatoire à

différentes températures afin de voir s’ils ne peuvent pas modifier son entropie pour

obtenir un générateur prédictible.

Ces attaques sont très simples, mais peu efficace en raison des détecteurs de

conditions anormales installés sur la puce.

2.1.b. Les attaques par canaux cachés.

Celle-ci consiste tout simplement à observer d’une façon intelligente le

fonctionnement du circuit électronique. On note plusieurs types de canaux cachés.

• Le temps d’exécution.

• La consommation en courant.

• Les émissions électromagnétiques.

29

2.1.c. Les attaques par rayonnement.

Ce type d’attaque consiste à l’exposition de la puce à un rayonnement afin de

modifier l’exécution des applications embarquées. Ces attaques nécessitent ce qu’on

appelle « Ouverture », que cela soit par la face avant ou arrière de la puce. Cette

ouverture nécessite l’utilisation de procéder physico-chimique (Extraction à chaud en

utilisant des acides) pour retirer la plastique sans altérer le circuit.

Une fois la puce nue, le fraudeur peut donc l’exposer avec le rayonnement

voulu. Les techniques sont semblables à celle utiliser pour effacer la mémoire PROM

avec les rayon Ultra Violet. (UV). Plusieurs types peuvent être utiliser telle que les

rayon UV, X, IR, et lumière blanche….

Bien sûr qu’il existe également des détections pour ces rayonnements mais

peut être désactivé par les fraudeurs. Ces attaques ne sont plus performantes, le

temps d’exposition est très long pour causer une erreur. En plus la carte se retrouve

souvent dans un état inexploitable.

2.1.d. Les attaques par injection de fautes.

Souvent très efficace, cette attaque consiste durant une exécution, à perturber

de manière très brève l’environnement. On pourra faire de glitches positifs ou négatif

ou à l’aide de laser envoyer des impulsions lumineuses de courte durée et de

différentes natures sur la puce nue.

L’injection de faute est réalisée sur plusieurs exécutions des mêmes

programmes à différents moments dans le temps afin de couvrir la zone intéressante

et cela en faisant varier la durée d’exposition de la puce à la perturbation. Il ne faut

essayer différent type de perturbation et parfois même les combiner pour obtenir des

bons résultats.

2.1.e. Les attaques erreurs.

Ce sont les attaques causées par une mauvaise utilisation du produit (souvent

involontaire) de la part de l’utilisateur. Ces utilisations peuvent mettre la carte ou

l’application dans un état non prévu par les spécifications. Les causes de ces

vulnérabilités sont souvent des bugs du programmeur de l’application ou du système

d’exploitation.

30

2.2. Les attaques invasives.

Les attaques invasives impliquent des modification au niveau du câblage de la

puce on doit avoir accès aux composants élémentaires et aux bus internes du

microprocesseur afin de lire/écrire/effacer des données ou même de modifier sa

structure. Elles nécessitent un équipement rare et coûteux, mais aussi un niveau de

connaissance et compétence très élever On distingue trois types d’attaque.

2.2.a. La modification de circuit.

Celle-ci permet d’étudier la carte et de lui faire réaliser des opérations,

particulières permettant de l’attaquer plus facilement. Il suppose l’utilisation

d’équipement comme FIB (Focus Ion Beam), un outil permettant à la fois d’observer

un circuit comme un microscope électronique à balayage, d’y creuser des cavités et

mène capable de déposer de la matière (Isolante ou conducteur) à sa surface. Le

micro électronicien se sert de cet outil, pour modifier à loisir la schématique d’un

circuit.

2.2.b. Le rétro-conception matériel.

Elle consiste à faire une rétro-conception de la puce afin d’en connaître tous

les secrets et donc de pouvoir mieux l’attaquer voir même la cloner. Il est possible en

utilisant les analyses physiques de reconstruire toute la circuiterie de la puce, ce qui

permet de recenser les points sensibles pour pouvoir espionner les informations.

2.3. Les attaques internes.

Grâce à la possibilité de charger des applications contenant du code

malicieux, les cartes à puce multi-applications ouvertes sont la possibilité de créer

des attaques

• D’identification les services présent sur la carte et déduire le comportement

probable d’une applet officielle (un applet officielle est une applet installé par

un organisme officiel). Elle ne peut utiliser que le service présent sur la carte

ce qui réduit le champ d’investigation pour le fraudeur.

• Collecte des informations sur la carte pour mieux préparer des attaques

matérielles et logicielles.

• Attaquer la machine et le pare-feu.

31

IV. La communication entre la carte et le terminal.Traditionnellement, le fonctionnement de la carte à puce se faisait ainsi. La

carte communiquait avec le terminal via des commandes/réponses APDU traitées

directement par le masque de la carte. Ce dernier lit, écrit et met à jour les données

contenues dans l'EEPROM.

Table 2.4 _ L'approche traditionnelle de la programmation de la carte à puce

Avec l'approche Java Card, le traitement est différent :

Table 2.5 _ La programmation de la carte à puce telle qu'il est conçu avec Java Card

La communication entre l’hôte et la carte est half-duplex. Elle se fait à l’aide de

paquets appelés APDU (Application Protocol Data Units) en respectant le protocole

de l’ISO 7816-4. Un APDU contient une commande ou une réponse. Ainsi la carte

joue un rôle passif et attend une commande APDU à partir de l’hôte. Elle exécute

l’instruction spécifiée dans la commande et retourne une réponse APDU.

La réponse APDU sert à accuser réception la commande APDU envoyée par

le terminal. Ainsi, la carte répond en envoyant le code instruction INS, suivi de

données de longueur LEN en terminant par SW1 et SW2 (0x90 0x00 lorsque la

commande s’est déroulée avec succès). En cas d’échec, seuls les champs SW1 et

SW2 seront envoyés au terminal avec les codes d’erreur suivants :

32

0x6E 0x00 CLA error

0x6D 0x00 INS error

0x6B 0x00 P1, P2 error

0x67 0x00 LEN error

0x98 0x04 Bad PIN

0x98 0x08 Unauthorized Access

0x98 0x40 Card blocked

Quand aux applets présents dans une Java Card, sont spécifique du programme

client. Chacun d’entre eux est ainsi numérotés avec un unique identifiant : l’AID

(Application Identifier). Dans la technologie Java Card, à chaque applet est assigné

un AID, de même chaque paquetage java identifie par un AID. Ceci est la convention

définie par la norme ISO7816.

1. La description d’une AID.

Un AID est une séquence d’octets compris entre 5 et 11 octets :

National Registerd Application Provider Proprietary Application Identifier Extention

5 octets 0-11 octetsTable 2.6 _ Format d'un AID

Le RID est fournit aux compagnies par l’ISO. Chaque compagnie a donc un RID

unique. Ensuite ce sont ces compagnies qui complètent l’AID avec le PIX de leur

choix. A l’arrivée, chaque application a donc un AID unique : [RID,PIX].

Les applets situés sur une Java Card communiquent avec l’application cliente grâce

aux échanges de requêtes et de réponse, les APDUs

2- Le Cycle de vie d’une carte à puce.

Le cycle de vie de la carte à puce comprend cinq phases, on distingue :

• Fabrication : Inscription d'un programme en mémoire ROM définissant les

fonctionnalités de base de la carte : "masque" figé traitant quelques

commandes

• Initialisation : Inscription en EEPROM/NVM des données de l'application

• Personnalisation : Inscription en EEPROM/NVM des données relatives à

chaque porteur

• Utilisation : Envoi de commande APDUs à la carte. Le Traitement de ces

commandes par la carte sont :

33

Si commande est reconnu : Traitement en interne de la commande

lecture/écriture de donnée en EEPROM, puis renvoi d’un APDU de

réponse

Si la commande est inconnue, on a un renvoi d’un code d’erreur

• Mort : Invalidation logique, soit on une saturation de la mémoire, bris, perte,

vol etc.

3. La description d’un APDU.

Une applet Java Card est une application qui, une fois correctement chargée sur la plateforme, permettra à cette dernière d’accéder à une ou plusieurs fonctionnalités supplémentaires. Ces fonctionnalités sont définies dans le code de l’applet par le développeur. Les applets situés sur une Java Card communiquent avec l’application cliente grâce aux échanges de requête et de réponse, les APDUs

Table 2.7 _ Format d’une commande ADPU

Table 2.8 _ Format d'une réponse ADPU

4. Les étapes de développement

La conception d’une applet Java Card passe généralement par les 4 étapes suivantes :

• La spécification des fonctions de l'applet : Echo est une applet simple, elle se contente de stocker la donnée qu’elle reçoit pour la retourner au terminal.

34

• L’assignation des AIDs : Dans la technologie Java Card, chaque applet est identifiée et sélectionnée par un identificateur (AID). De même, à chaque paquetage Java est assigné un AID. Cette convention de nommage est conforme à la spécification de la carte à puce définie dans l’ISO7816.

• La conception des programmes de l'applet : Dans la technologie Java Card, chaque applet est identifiée et sélectionnée par un identificateur (AID). De même, à chaque paquetage Java est assigné un AID. Cette convention de nommage est conforme à la spécification de la carte à puce définie dans l’ISO7816.

• la définition de l'interface applet / terminal : Un applet Java Card doit étendre la classe javacard.framework.Applet Cette classe est une superclasse des applets résident sur la carte. Elle définit les méthodes courantes que doit utiliser une applet pour interagir avec le JCRE.

4.1. L'Applet carte.

L'applet carte est un programme serveur de la Java Card. Elle est

sélectionnée à partir de son identifiant unique, l’AID. Cette sélection se fait grâce à

une commande APDU au travers d’un terminal. Chaque applet s’exécute dans un

espace qui lui est propre. Cette propriété est assurée par La JCVM. Grâce au

« firewall », un applet peu accéder à d’autres services offerts par d’autre applet ou le

JCRE.

Une fois l’applet est installée dans la carte, elle est toujours disponible, et elle doit

hériter de la classe javacard.framework.Applet et implémenter les méthodes

suivantes qui interagissent avec le JCRE :

Select/deselect : Pour activer ou désactiver une applet.

Install /uninstall : Pour installer ou supprimer une applet sur la carte

Process : Pour traiter les commandes APDU et envoyer une réponse APDU

Register : Pour enregistrer l’applet auprès de JCRE.

Table 2.9 _ Diagramme d'états d'un applet4

Lorsque celui-ci reçoit des commandes APDU à partir du lecteur. Une fois le

code de l’applet proprement chargé sur la carte et lié aux autres paquetages se

35

trouvant sur la carte, la vie de l’applet commence lorsqu’une instance de l’applet est

créée, via la méthode install(), et enregistrée au sein du JCRE grâce à la méthode

register().

La méthode install() prend un vecteur d’octets comme paramètre. Ce vecteur

contient les paramètres d’installation pour l’initialisation et la personnalisation de

l’instance d’applet. Une applet Java Card reste inactive jusqu’à ce qu’elle soit

explicitement sélectionnée. Lorsque le JCRE reçoit une commande SELECT APDU,

il consulte sa table interne pour trouver l’applet dont l’AID correspond à celui spécifié

dans la commande. Les méthodes select() et deselect() permettent la sélection ou la

désélection d'une applet. Une fois l’applet sélectionnée, le JCRE fait suivre toutes les

commandes APDU (y compris la commande SELECT) à la méthode process() de

l’applet. Dans la méthode process(), l’applet interprète chaque commande APDU et

exécute la tâche spécifiée par la commande. Pour chaque commande APDU, l’applet

répond au CAD en envoyant une réponse APDU qui informe le CAD du résultat du

traitement de la commande APDU.

Ce dialogue commande-réponse continue jusqu’à ce qu’une nouvelle applet

soit sélectionnée ou bien que la carte soit retiré du CAD. Lorsqu’elle est

désélectionnée, l’applet devient inactive jusqu’à sa prochaine sélection / délétion.

4.1. a. Définition des méthodes obligatoirement implémenter.

install (APDU apdu) : Va allouer la mémoire pour les objets, afin d’éviter les allocation

intempestives dans le code, les paramètres de la méthode peuvent être utiliser pour

instancier les objets avec des paramètres particuliers .cette méthode ne devrait être

utiliser qu’une seule fois au moment de l’installation d’applet dans la carte

register() : Permet d’enregistrer l’instance de l’objet et applet auprès de

l’environnement d’exécution javacard, on devra appeler cette méthode dans le corps

d’Install

select () : Servira à préciser ce qui arrive lors de la sélection d’applet, doit retourner

un booléen. Celui ci doit être true si l’on doit considérer l’exécution de la méthode

comme un succès

proccess(APDU apdu) : Va gérer les commandes APDUs envoyées à la carte après

la sélection, cette méthode sera donc le centre névralgique de l’application

36

deselect() : Sera lancer lors de sélection d’une autre AID, on pourra on profiter pour

mettre à jour les compteurs par exemple.

4.1.b. La gestion des APDUs par une applet.

L'unité de base pour le traitement d'une applet est un objet de type

javacard.framework.APDU qui est transmis par le JCRE à la réception d'un APDU de

commande par la carte (en provenance du terminal). La lecture et l'écriture dans le

buffer d'APDU se déroulent comme le montre le diagramme de séquence ci dessous:

Table 2.10 _ Diagramme de séquence indiquant la gestion d'APDU

Lorsque le JCRE reçoit une commande APDU, il encapsule la commande

dans un objet APDU qu’il passe à la méthode process() de l’applet courante. L’objet

APDU comporte un tableau d’octets contenant le message APDU. L’applet traite une

commande APDU en invoquant des méthodes sur cet objet APDU. En général,

l’applet effectue les étapes suivantes:

Étape 1. Extraire le buffer APDU:L’applet invoque la méthode getBuffer() afin d’obtenir une référence au buffer

APDU, qui contient le message. Lorsque l’applet reçoit l’objet APDU, seuls les 5

premiers octets sont disponibles dans le buffer. Il s’agit dans l’ordre des octets CLA,

INS, P1, P2, et P3. L’octet P3 désigne l’octet Lc, si la commande possède des

données optionnelles. L’applet peut vérifier les octets entête pour déterminer la

structure de la commande et l’instruction spécifiée par la commande.

37

Étape 2. Recevoir des données:Si la commande APDU contient des données optionnelles, l’applet doit diriger

l’objet APDU vers la réception de données entrantes en invoquant la méthode

setIncomingAndReceive(). Les données sont lues dans le buffer APDU en suivant

l’ordre des 5 octets d’entête. Le dernier octet de l’entête (Lc) indique la longueur des

données entrantes. Si le buffer APDU ne peut contenir toutes les données, l’applet

peut traiter les données en fragments, ou bien le copier vers un buffer interne. Dans

les deux cas, elle doit faire appel de manière répétitive à la méthode receiveBytes()

afin de lire les données additionnelles à partir du buffer APDU.

Étape 3. Renvoyer des données:Après avoir traité une commande APDU, l’applet peut retourner des données

à l’application sous forme de réponses APDU. L’applet doit d’abord faire appel à la

méthode setOutgoing() pour obtenir la longueur de la réponse (Le). Le est spécifié

dans la commande APDU associée à la réponse APDU.

Ensuite, l’applet appelle la méthode setOutgoingLength() pour informer le

CAD de la longueur réelle des données de la réponse. L’applet peut transférer les

données vers le buffer APDU et appeler la méthode sendBytes() pour envoyer les

données. La méthode sendBytes() peut être appelée plusieurs fois si le buffer APDU

ne peut pas contenir toutes les données retournées. Si les données sont stockées

dans un buffer interne, l’applet invoque la méthode sendByteLong() pour envoyer les

données à partir du buffer.

Si les données de la réponse sont courtes, la classe APDU fournit une

méthode appropriée : setOutgoingAndSend(). Cette méthode est une combinaison

des méthodes setOutgoing(), setOutgoingLength() et sendBytes() (le buffer APDU

sera donc utilisé). Néanmoins cette méthode ne peut être invoquée qu’une seule

fois, et aucune méthode d’envoi ne peut être appelée après.

Étape 4. Renvoyer le mot d’état (status word):Après un succès de la méthode process(), le JCRE envoie automatiquement

0x9000 pour indiquer un traitement normal. A n’importe quel point, si l’applet détecte

une erreur, l’applet peut lever l’exception ISOException en appelant la méthode

statique ISOException.throwIt(shortreason). Le mot d’état est spécifié dans le

38

paramètre reason. Si l’exception ISOException n’est pas gérée par l’applet, elle sera

attrapée par le JCRE, qui extraira le code et l’enverra comme mot d’état.

4.2. L'application Cliente (Application terminal).

L'application cliente se trouve sur le terminal qui dialogue avec la carte. Elle

implémente les classes du terminal (avec JDK) et communique avec le serveur

(applet carte), pour cela elle s'occupe de:

L'établissement de la liaison : envoi d’un APDU de sélection avec l’AID

de l’applet (standardisé)

L’invocation de services de l’applet, c'est à dire : le codage et l'envoi

d’APDUs de commande conformes à ceux traités par l’applet la

réception et décodage des APDUs de réponse retournés par l’applet.

Il n'existe pas d’API standard de communication avec la carte, on peut utiliser

une des API fournit pas différents constructeurs. Cependant une API est en cours de

standardisation. Le diagramme de séquence ci dessous indique les communications

entre l'application cliente avec la carte :

Il n'existe pas d’API standard de communication avec la carte, on peut utiliser

une des API fournit pas différents constructeurs. Cependant une API est en cours de

standardisation. Le diagramme de séquence ci dessous indique les communications

entre l'application cliente avec la carte :

Table 2.11 _ Diagramme de séquence indique la communication entre L'application Cliente et le serveur

39

V. Application : « Gestion des Etudiants »Les cartes à puce sont aujourd’hui considérées comme des ressources sûres

du fait de leur structure interne et des validations qu’elles subissent tout au long de

leur cycle de vie. Il est donc possible de les utiliser comme élément de base pour

sécuriser différents types d’environnement : accès physiques à des locaux,

transactions bancaires, système embarqué, etc. Dans notre cas, nous allons

procéder à une réalisation pratique à base de la technologique de carte à puce.

Notre application consistera à la gestion des étudiants. Chaque étudiant une carte

personnelle muni des Informations suivantes.

Le code PIN

Nom de l’étudiant

L’adresse de l’étudiant

Filière de l’étudiant

Un étudiant utilise cette carte pour s’identifier dans ses activités, par exemple : l’entré

de l’université,

Comme nous l’avons vu précédemment, une partie de cette application sera logé sur

la carte, ce sont les applets et l’autre partie hors carte, ce sont les terminales et un

chargeur qui sert à installer des applets avec des informations (Code PIN, nom de

l’étudiant, adresse, modules ….) nécessaire à la carte.

1- Identification des acteurs et les diagrammes.

Cas d’utilisations

1. Etudiant sélectionne son applet

2. Etudiant acquiert des informations :

Etudiant acquiert son adresse

Etudiant acquiert son filière

Etudiant acquiert son nom

3. Etudiant change son code PIN

40

Figure 6.3 : diagramme du cas d’utilisation

Les diagrammes de séquence pour les cas d’utilisation Dans cette partie on va traiter

quelques diagrammes de séquence pour les différents cas d’utilisation

Figure 6.3 diagramme de séquence d’identification

41

Figure 6.3_ diagramme de séquence pour avoir les informations sur l’étudiant

2- La partie dans la carte.

L'applet de l'étudiant permet de réaliser des activités de l'étudiant. Le but

principal de cet applet pour l'étudiant : Identifier son compte. La carte utilise un

algorithme de sécurité qui exige une code PIN, a string contient 5 caractères, après 3

fois échoués de l'identification, la carte va bloque ce applet.

Attribuer AID pour l’ applet et son paquet.

Paquet AID

étudiant 0xf2 0x34 0x12 0x34 0x56 0x00 0x10 0x00 0x00

Applet AID

etudiant.EtudiantApplet 0xf2 0x34 0x12 0x34 0x56 0x00 0x10 0x00 0x01Pour l’instant on va traiter les différentes commandes et réponse APDUs sur

notre application

2.1 Sélection applet

Commande APDU :

42

0X00 0 X A4 0 X04 0 X00 0x09 9 Octets AID

Entête Sélection LC Données

Réponse APDU :

• Si la sélection est succès :

• Si le fichier n'existe pas :

2.2 Login

Commande APDU de l'Applet étudiant :

Réponse APDU. Login est succès :

La carte est bloquée pour des raisons sécurité :

La vérification échoue :

2.3 Acquérir l'adresse les informations

2.3.a - Le nom de l'étudiant

Commande APDU :

Réponse APDU :

43

20 Octet 0x90 0x00

Nom d’étudiant SW

0XB0 0 X 32 0 X00 0 X00 0 X00 LC octets

CLA INS P1 P2 LC

0X63 0 X00

0X63 0 X00

0X90 0 X00

Donnée

0XB0 0 X 20 0 X00 0 X00 LC-3 octets 3 Octets

CLA INS P1 P2 LC PIN entré Date

0x6A 0 X82

0X90 0 X00

2.3.b - L'adresse de l'étudiant

Commande APDU :

Réponse APDU :

2.3.c. la filière de l'étudiant

Commande APDU :

Réponse APDU :

2.3. d- Changer de code PIN

Commande APDU :

Réponse APDU :

• Le chargement est succès :

• P1, P2 sont fautes :

• L'utilisateur ne vérifie pas :

44

0X63 0 X01

0X6B 0 X00

0X09 0 X00

0XB0 0 X 31 0 X00 0 X00 LC octets

CLA INS P1 P2 LC Nouveau PIN

5 Octet 0x90 0x00

Classe d’étudiant SW

0XB0 0 X 32 0 X00 0 X00 0 X00 LC octets

CLA INS P1 P2 LC

0XB0 0 X 32 0 X00 0 X00 0 X00 LC octets

CLA INS P1 P2 LC

40 Octet 0x90 0x00

Adresse d’étudiant SW

3 L'Implémentation

Dans cette partie on va implémenter les différents méthodes de notre

application pour ça on va traiter deux parties la première dans la carte (applet) et une

hors carte (application cliente)

3.1 L'applet étudiant.

Cet exemple permet de comprendre le fonctionnement du code d'une applet

Java Card.

Tout d'abord il faut importer toutes les classes nécessaires qui définissent

l'applet Java card pour qu'il fonctionne selon la norme ISO 7816. Ce sont les classes

APDU, Applet et ISO7816.

Enfin pour gérer les exceptions on importe la classe ISOException. Enfin la

classe. Utile comporte des méthodes permettant d'effectuer de diverses opérations

utiles.

Méthode d'installation de l'applet dans la carte. Cette méthode crée donc un

applet GestionEtudiant " new GestionEtudiant " et l'enregistre auprès du JCRE avec

la méthode " register ". Cette méthode prend en paramètre une série d'octets qui

sont les paramètres de l'applet. Ces paramètres Sont ensuite utilisés pour

l'enregistrement auprès du JCRE.

45

La méthode process gère les commandes APDU reçues depuis l'application cliente.

Avant toute chose, elle vérifie si la commande en question n'est pas une sélection de

l'applet ; sinon elle continue son traitement

Si le champ INS prend une autre valeur que celle autorisée dans la déclaration des constantes, on renvoie une exception de type " valeur INS non supportée ". Important: Vous pouvez consulter le code de l'application en détaille sur le cd accompagne du rapport

3.2 La partie hors carte

Pour l'application hors carte on peut faire une simulation en utilisant le plugin javacard manager avec netbeans6.1 car ce plugin est compatible avec des cartes cyberflex

Apres on va sélectionner une applet en tapons son AID

46

Pour simuler les échanges APDUs on peut utiliser APDUManager Windows

47

Conclusion

Ce projet est une très bonne expérience. Nous avons découvert un sujet

original, une technologie très intéressante, bien que déjà très implantée dans le

marché, a un grand avenir devant elle.

Nous avons pu nous rendre compte que cette technologie possède beaucoup

d'attraits pour les personnes souhaitant développer des applications et sécurisées

pour univers professionnel.

Cette technologie a l'avantage d'être simple d'utilisation et possède une

grande stabilité ainsi qu'une forte opacité du contenu face à l'environnement

extérieur.

Tout au long de nos recherches sur cette technologie, nous avons pu non

seulement comprendre le fonctionnement de ces applications embarquées, mais on

a également pu enrichir nos connaissances sur Java en général. C'est en étudiant

cette technologie qu'on a pu comprendre la véritable utilité de la machine virtuelle

Java.

Durant ce projet nous avons dû faire face à diverses contraintes qui nous ont

retardés dans la phase de développement de l'application. nous aurions beaucoup

aimé avoir plus de temps pour comprendre et développer des applications plus

complexes, qui traitent notamment de la sécurité, un aspect important de cette

technologie. On garde néanmoins une très bonne expérience de ce projet, qui nous

apportera certainement un plus dans le monde professionnel. Les Javacards seront

de plus en plus développées et améliorées, et avoir des connaissances sur le sujet

sera sûrement un atout si l'occasion se présente.

48

Bibliographie

[1] Damien SAUVERON. Étude et réalisation d'un environnement d'expérimentation

et de modélisation pour la technologie Java CardTM. Application à la sécurité. Thèse

présentée à l'Université de Bordeaux I, 2004. P.280.

[2] AMIOT Olivier, ASSELOOS Erwann, BERROGAIN Nicolas, DAHAN Jean François, FORGET Sébastien, SASMITA Rio, YU Janweï. E-GATE. Sécurisation

des Transmissions dans un réseau sans fil par la carte à puce. DESS Télécom.

Université de Nice Sophia Antipolis- 2003. P.96.

[3] Sebastien Varrette. Tutorial : Installer un lecteur de cartes à puce USB sous

Linux. Version : 0.1 - Juin 2005

[4] Jean-Louis LANET. Support de cours : Carte à puce. -2006. P.89

[5] Sébastien Chassande-Barrioz, Stéphane Martin. Protection par capacité

cachée sur carte à puce Java Card. Université Joseph Fourier U.F.R. Informatiques

Juin – Août 1999. P. 25.

[6] Louis Guillou. Histoire de la carte à puce du point de vue d'un cryptologique.

Actes du Septième Colloque sur l'Histoire de l'Informatique et des Transmissions.

P.126-154.

[7] Ernest TSASSONG. Rapport de stage –I4 Globalisation des résultats dans les

mesures de performance sur les plateformes Java Card ESIEE - Laboratoire Cédric.

P.48.

[8] LANNETTE Romain. Les Java Cards. Ensem 2007-08.P.36

[9] Carine COURBIS. Simulation d'Applications Java Card : Conception et

Réalisation d'Outils d'Aide à la programmation. INRIA de Sophia-Antipolis Juillet

1998. P.27.

[10] RMI Client Application Programming Interface. Java Card 2.2 Java 2

Platform. Micro Edition. Sun Microsystems, June, 2002. P. 78

[11] kit de devellopement : http://java.sun.com/javacard/devkit/index.jsp

49

[12] pluging jcde1.0 : http://sourceforge.net/projects/eclipse-jcde/.

[13]plugin javacard manager:http://plugins.netbeans.org/PluginPortal/faces/Plugin-

DetailPage.jsp ?pluginid=10935.

[14] jre : http://www.java.com/en/download/manual.jsp.

[15] PLUGIN JCOP http://tinyurl.com/vum9K.

[16] Introduction à la programmation de Javacard sous Windows.

http://julienb.developpez.com/tutoriels/java/introjavacard/m. Date de publication :

30/04/2008 ; Dernière mise à jour : 30/04/2008

50

Table de matière :

INTRODUCTION. .................................................................................................................................................. 5

I- LA CARTE À PUCE. .......................................................................................................................................... 6

1. CHRONOLOGIE ET HISTORIQUE DE LA CARTE À PUCE. ................................................................................................... 6 2. LES TYPES DES CARTES À PUCE. ............................................................................................................................... 7

2.1. Les cartes avec contact. ............................................................................................................................ 7 2.1. a. Les cartes à mémoire. ...................................................................................................................................... 8 2.1. b. Les cartes à microprocesseur. .......................................................................................................................... 8

2.2. Les cartes sans contacte. .......................................................................................................................... 9 3. CARACTÉRISTIQUE PHYSIQUE DES CARTES À PUCE. .................................................................................................... 10

II- JAVA CARD. ................................................................................................................................................... 13

1. HISTORIQUE. ...................................................................................................................................................... 13 2. LA TECHNOLOGIE JAVA CARD. .............................................................................................................................. 15

2.1. La machine virtuelle Java Card. ............................................................................................................ 16 2.1. a. Le JCVM partie sur carte. .............................................................................................................................. 17 2.1.b. Le JCVM partie sur l’ordinateur. .................................................................................................................... 17 2.1. c. Les modifications du fichier Class. ................................................................................................................ 18

2.2. Le JCRE et son modèle de fonctionnement. ........................................................................................... 18 2.3. L’API Java Card. ................................................................................................................................... 20

2.3.a. Le package java.lang. ..................................................................................................................................... 20 2.3.b. Le package javacard.framework. .................................................................................................................... 21 2.3.c. Le package javacard.security. ......................................................................................................................... 21 2.3.d. Le package javacardx.crypto. ......................................................................................................................... 22 2.3.e. Le paquetage java.io. ...................................................................................................................................... 22 2.3.f. Le paquetage java.rmi ..................................................................................................................................... 22 2.3.g. Le paquetage javacard.framework.service. ..................................................................................................... 23

3. LA SÉCURITÉ JAVA CARD. .................................................................................................................................... 24 3.1. Sécurité du langage. ............................................................................................................................... 24 3.2- Sécurité supplémentaire des Java Cards. .............................................................................................. 24

III. LA SÉCURITÉ DE LA CARTE À PUCE. .................................................................................................. 26

1. LES PROTECTIONS QUE APPORTE LA CARTE À PUCE. ................................................................................................... 26 1.1. Au niveau physique. ................................................................................................................................ 26 1.2. Au niveau matériel. ................................................................................................................................. 27 1.3. Au niveau logiciel. ................................................................................................................................. 28

2. LES ATTAQUES CLASSIQUES. .................................................................................................................................. 29 2.1. Les attaques non-invasives. .................................................................................................................... 29

2.1.a. Les attaques hors conditions opérationnelles. ................................................................................................. 29 2.1.b. Les attaques par canaux cachés. ...................................................................................................................... 29 2.1.c. Les attaques par rayonnement. ........................................................................................................................ 30 2.1.d. Les attaques par injection de fautes. ............................................................................................................... 30 2.1.e. Les attaques erreurs. ....................................................................................................................................... 30

2.2. Les attaques invasives. ........................................................................................................................... 31 2.2.a. La modification de circuit. .............................................................................................................................. 31 2.2.b. Le rétro-conception matériel. .......................................................................................................................... 31

2.3. Les attaques internes. ............................................................................................................................. 31

IV. LA COMMUNICATION ENTRE LA CARTE ET LE TERMINAL. ...................................................... 32

1. LA DESCRIPTION D’UNE AID. ............................................................................................................................... 33 2- LE CYCLE DE VIE D’UNE CARTE À PUCE. ................................................................................................................ 33 3. LA DESCRIPTION D’UN APDU. ............................................................................................................................. 34 4. LES ÉTAPES DE DÉVELOPPEMENT ............................................................................................................................ 34

4.1. L'Applet carte. ........................................................................................................................................ 35 4.1. a. Définition des méthodes obligatoirement implémenter. ................................................................................. 36 4.1.b. La gestion des APDUs par une applet. ........................................................................................................... 37

4.2. L'application Cliente (Application terminal). ........................................................................................ 39

51

V. APPLICATION : « GESTION DES ETUDIANTS » ................................................................................... 40

1- IDENTIFICATION DES ACTEURS ET LES DIAGRAMMES. ................................................................................................. 40 2- LA PARTIE DANS LA CARTE. .................................................................................................................................. 42

2.1 Sélection applet ....................................................................................................................................... 42 2.2 Login ........................................................................................................................................................ 43 2.3 Acquérir l'adresse les informations ......................................................................................................... 43

2.3.a - Le nom de l'étudiant .................................................................................................................................... 43 2.3.b - L'adresse de l'étudiant ................................................................................................................................... 44 2.3.c. la filière de l'étudiant ...................................................................................................................................... 44 2.3. d- Changer de code PIN .................................................................................................................................... 44

3 L'IMPLÉMENTATION .............................................................................................................................................. 45 3.1 L'applet étudiant. ..................................................................................................................................... 45 3.2 La partie hors carte ................................................................................................................................. 46

CONCLUSION ...................................................................................................................................................... 48

BIBLIOGRAPHIE ................................................................................................................................................ 49

52