PFE mohamed
-
Upload
jeanloui25 -
Category
Documents
-
view
1.187 -
download
5
Transcript of PFE mohamed
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