Vous êtes sur la page 1sur 51

La

Lacarte
carteààpuce
puceet
etla
laTechnologie
TechnologieJava
Java

Samia Bouzefrane

Maître de Conférences

CEDRIC –CNAM

samia.bouzefrane@cnam.fr
http://cedric.cnam.fr/~bouzefra

1 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

La
Lacarte
carteààpuce
puce: :introduction
introductionet
etprincipe
principe

2 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


La carte à puce aujourd’hui

 Monétique :
- Carte bancaire : Groupement Cartes Bancaires, nouvelles cartes EMV, etc.
- Porte-monnaie : Octopus, Moneo en France, Proton en Belgique,
Geldkarte en Allemagne
 Identification :
Cartes d'identité nationales (eID en Belgique), E-passeports (août 2006 en France)

Enseignement (comme carte d'étudiant et/ou de restauration)

 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, Korrigo (un seul
titre de transport pour tous ses déplacements en transports en commun ).

 Sécurité informatique (authentification forte et signature électronique): carte doté


d’un cryptoprocesseur pour la génération des clés et le stockage de la clé privée).
3 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Historique – Invention de la carte à puce

 1967-1968: Jürgen Dethloff et Helmut Grötrupp ingénieurs allemands


(déposent un brevet en 1969)

 1970: Kunitaka Arimura japonais dépose un brevet en mars 1970 au Japon

 1971: Paul Castrucci de IBM dépose aux USA un brevet intitulé Information Card

 1974-1979 : Roland Moréno français dépose 47 brevets dans 11 pays


(crée ensuite la société Innovation)

 Implication industrielle de Bull et Schlumberger

4 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Première carte à puce

 1979: 1ére carte à base de microcontrôleur

 Fabriquée par Motorola pour Bull CP8

Possède une UC de type 6805 (micro-contrôleur 8 bits de Motorola)

1ère implémentation de la “smart card” (CP8)


RAM : 36 octets
EPROM : 1ko
ROM : 1,6 ko

5 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Famille de produits

 carte à mémoire

 carte logique câblée

 carte à microprocesseur

6 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Développement d’une application

 Carte mémoire = X zones mémoires

 Carte à micro-processeur : installation de vrais programmes

7 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Cartes à microcontrôleur

 Cartes à puce intelligentes

 Comportent un microcontrôleur :

- UC
- PROM
- RAM dans le même circuit
- EEPROM
- interface d’E/S
- crypto processeur

Processeur : 16 ou 32 bits

EEPROM : de 1Ko à 128 Ko (256 Ko pour une Java Card ou une Basic Card)

Interface série: UART simplifié

8 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Synoptique interne d’une carte à microcontrôleur

9 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Fonctionnement

10 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Les grandes familles de SE

Les prémisses (avant 1990):


- M4, BO, COS,...
Mono-application
Plus ou moins figé dans les fonctions et structures
COS : possibilité d’ajouter des fonctions

Les évolutions (1990-1995) :


- MP, MP100, MCOS
- Multi-application
- CQL (1993), Basic Card,....

En avant vers l’ouverture...


- Java Card
- .Net

11 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Architecture matérielle aujourd’hui

CPU : 8, 16 & 32 bits,


- Coeur 8051, AVR, ARM, MIPS, propriétaire

Mémoires :
- RAM : 1 à 4 Ko
- NVM (EEPROM/Flash) : 16 à 32 Ko
- ROM : 32 à 64Ko

Co-processeur
- Java Card : exécution directe du Byte Code Java Card Technology 2.2

12 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Caractéristiques physiques d’une carte SIM

Début des années 90:


Une carte SIM : un CPU (8 bits), RAM (128 octets), ROM (7 Ko), EEPROM (3 Ko).

Année 2008 :
Une carte SIM : un CPU (32 bits), RAM (16 Ko), ROM (512 Ko), EEPROM/FLASH
(512 Ko), processeur dédié au calcul cryptographique.

La ROM (Read Only Memory) contient le système d'exploitation de la carte, les
mécanismes de sécurité (algorithmes spécifiques (API GSM).

l'EEPROM (Electrically Erasable Programmable Read Only Memory) contient


des répertoires définis par norme GSM (tels que les numéros de téléphones l'abonné…)
et des données liées aux applets (service de messages courts et applications spécifiques).

la RAM (Random Access Memory) permet d'effectuer des calculs ou de charger
des instructions et les exécuter.

13 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

La
Lanormalisation
normalisation

14 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Les standards

Les normes liées à la carte :

ISO,

ETSI, (télécommunications, GSM)

EMV, (cartes de paiement)

ICAO, (agence de l’ONU, biométrie, passeport)

Santé,
...

15 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Normes principales des cartes à contact : l’ISO 7816

L’ISO 7816 « Idenfication cards – Integrated circuit cards with contacts »

publié par l’ISO (International Organisation for Standardisation)

le plus important standard définissant les caractéristiques des cartes


à puce qui fonctionnent avec un contact électrique

15 normes sont proposées pour les cartes à contact.

16 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Normes principales des cartes à contact

 La norme ISO 7816-1 précise les caractéristiques physiques de la carte

 La norme ISO 7816-2 définit la position et le brochage des contacts


de la carte

 La norme ISO 7816-3 définit les niveaux électriques utilisés


pour le dialogue avec la carte

 La norme ISO 7816-4 définit les commandes de base des cartes à puce

17 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

La norme ISO 7816-1

ISO 7816-1 : révisé en mars 1998


définit les caractéristiques physiques des cartes à puce à
contact, ex : la géométrie, la résistance, les contacts, etc.

18 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Caractéristiques mécaniques des cartes à puce

Même si on connaît en général deux formats de la carte à puce

Celui de la carte bancaire

Celui de la carte SIM

 3 formats normalisés : ID1, ID00 et ID000

19 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Les 3 formats

ID 01

ID 00 ID 000

20 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Les 3 formats

Le fabricant produit une seule taille (ID1), le client final pourra réduire
ses dimensions au format ID00 ou ID000 (ex. carte SIM)

21 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Normalisation AFNOR / ISO

La position des contacts : position AFNOR et position ISO

Carte ISO

Carte AFNOR

22 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’ISO 7816-2

 Elle spécifie le dimensionnement physique (extérieur) des contacts


de la puce. 2 des 8 contacts réservés à une utilisation future (RFU)
sont redéfinis pour l’utilisation USB dans la norme ISO 7816-12.

 Dimension et emplacement des contacts, révisé en mars 1998.

23 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

L’ISO 7816-2

Valeurs en mm

24 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’ISO 7816-2

Vcc: tension électrique (3 à 5 V)


RST: c’est le « reset », initialise le microprocesseur (warm reset)
cold reset = coupure et rétablissement de l’alimentation
CLK: signal d’horloge car pas d’horloge sur la carte
GND: masse
Vpp: utilisé dans les anciens modèles pour avoir une autre source d’alimentation
I/O: utilisé pour le transfert des données et des commandes entre la carte et le
lecteur. La communication half-duplex.

25 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Signification des contacts

Vcc : tension d’alimentation positive de la carte fournie par le lecteur


(4.75V ≤ Vcc ≤ 5.25V) Vcc=3.3V pour une carte SIM
RST: commande de reset de la carte, fournie par le lecteur
(entrée non obligatoire avec certaines cartes à mémoire)

CLK: Clock, horloge fournie à la carte par le lecteur


- rythme les échanges de données entre la carte et le lecteur

RFU (Reserved for Future Use) non utilisés pour le moment

GND masse électrique de la carte

Vpp: tension de programmation de la carte fournie par le lecteur


-inutilisé aujourd’hui
-21V nécessaire dans les premières cartes pour écrire dans des EPROM

I/O entrées/sorties des données


- ligne bidirectionnelle (carte  lecteur)
26 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -
L’ISO 7816-3

Elle 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) 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.

27 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

ATR défini dans l’ISO 7816-3

ATR (Answer To Reset):


Dès que la carte est mise sous tension, elle envoie un message de
réponse d’initialisation appelé ATR, il peut atteindre une taille maximale
de 33 octets. Il indique à l’application cliente les paramètres nécessaires
pour établir une communication avec elle.

Paramètres envoyés par la carte :

- Le protocole de transport ;
- Taux de transmission des données ;

28 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Le
Leprotocole
protocoleAPDU
APDU

29 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

L’ISO 7816-4

Elle définit les messages APDU (Application Protocol Data Units) utilisés
par les cartes à puce pour communiquer avec le lecteur.

Les échanges s’effectuent en mode client-serveur,

Le terminal est toujours l’initiateur de la communication.

30 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’ISO 7816-4 : Le protocole APDU

carte
terminal

Commande APDU (xxxx)

Réponse APDU (xxxx)

31 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Format des commandes APDU

Commande APDU
Entête obligatoire Corps optionnel
CLA INS P1 P2 Lc Data field Le
•CLA (1 octet): Classe d’instructions --- indique la structure et le format pour une
catégorie de commandes et de réponses APDU
•INS (1 octet): code d’instruction: spécifie l’instruction de la commande
•P1 (1 octet) et P2 (1 octet): paramètres de l’instruction
•Lc (1 octet): nombre d’octets présents dans le champ données de la commande
Avec Le=0, - Si cde d’écriture => pas de données utiles
- Si cde de lecture => la cde doit retourner 256 octets de données utiles
•Data field (octets dont le nombre est égal à la valeur de Lc): une séquence d’octets dans
le champ données de la commande

32 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Format des réponses APDU

Réponse APDU

Corps optionnel Partie obligatoire

Data field SW1 SW2

•Data field (longueur variable): une séquence d’octets reçus dans le champ données de la
réponse
•SW1 (1 octet) et SW2 (1 octet): Status words (Mots d’état)—état de traitement par la carte

SW1 SW2 = 0x90 0x00 Succès


0x6E 0x00 CLA error
0x6D 0x00 INS error
0x6B 0x00 P1, P2 error
0x67 0x00 LEN error
0x98 0x04 Bad PIN
0x98 0x40 Card blocked
33 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Exemples de classes : CLA

34 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’ISO 7816-5

Elle définit la procédure d’enregistrement et d’attribution des identifiants


des applications (AID, ou Application IDentifier).

Un unique AID est associé à chaque application = {RID, PIX}

RID : le numéro d’enregistrement du fournisseur d’application attribué


par la Copenhagen Telephone Company Ltd.
Le RID doit être le même pour le paquetage et l'applet.

Application identifier (AID)

National registered application Proprietary application identifier


provider (RID) extension (PIX)
5 octets 0 to 11 octets

35 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

La
Lagestion
gestiondes
desfichiers
fichiersd’une
d’unecarte
carteààpuce
puce

36 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Les fichiers

Cartes à mémoire: composées de zones mémoire destinées à la lect/écrit

Cartes à puce: comportent un véritable système de fichiers

- création/destruction de fichiers
- attribuer un nom à un fichier
- définir des restrictions d’accès en Letc/écrit
- lire/écrire dans un fichier
- le plus contraignant est l’échange en binaire entre le lecteur et la
carte

37 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Arborescence des fichiers et répertoires

La norme ISO 7816-4 définit l’arborescence de fichiers


Vocabulaire propre aux cartes à puce
- EF (Elementary Files): fichiers élémentaires (feuilles de l’arbre)
- DF (Dedicated Files) : qu’on peut appeler Directory Files (répertoires)
- MF (Master File): fichier maître, c’est le répertoire racine

38 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Types de Fichiers

Fichier à structure transparente : suite d’octets (min=1 octet, max: 255 octets)
 Fichier à structure linéaire fixe : enregistrements de taille fixe, indicé à partir
de 1
Fichier à structure linéaire variable: enregistrements de taille variable, indicé
à partir de 1
Fichier à structure linéaire cyclique : a la structure linéaire fixe fermée, avec
indice 1 = dernier enregistrement écrit.

39 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Les commandes de gestion de fichiers

Binary (read, write, search, erase)

Record (read, write, update, append, search, erase)

Get/Put Data

40 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’arrivée de la technologie Java Card

Année Événement

1979 Première carte fabriquée par Motorola pour


Bull CP8
1980-81 Premières expérimentations de télévision
payante
1983 Premières cartes téléphoniques France
Télecom
1984 Première version de la carte bleue à base de
carte Bull CP8
1987 Publication des normes ISO 7816

1989 Premières cartes GSM pour téléphones


mobiles (Gemplus)
1998 Premières cartes Java Card

41 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

La
Latechnologie
technologieJava
JavaCard
Card: :introduction
introductionet
etprincipe
principe

42 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Java Card - Introduction

Besoin des systèmes « programmables »

Recherche de solution « évolutive » (dépasser la ROM)

Les applications :
 Longues à développer

Statiques dans leurs fonctions

 Des tentatives
 1ère version: octobre 1996, démarrage et produit réel
en 1998, une réalité industrielle à partir de 2000. En 2004, le nombre
de Java Cards vendus a atteint le milliard.
En 2007, 3 milliards de cartes SIM fabriquées

43 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Étapes du développement de l’industrie

La carte à microprocesseur et les grandes étapes de développement de la


technologie :

 Les pionniers (1975-1985): premières idées


(les bases technologiques sont établies)
1985-1995: la technologie est améliorée
- marchés et déploiements importants: CB, GSM
- limites : besoin de davantage de flexibilité

1995-2005 : explosion du marché, nouveau paradigme avec


- les cartes évolutives basées sur Java Card

2006: 1,2 billions de téléphones mobiles utilisant des cartes SIM/Java Card
1,65 billions cartes à puce/ Java Card (source site de Sun )

2005-???: la carte devient un élément du réseau


-Les SCWS (Smart Card Web Server)
- .Net
44 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -
L’arrivée de la technologie Java Card

Novembre 1996, première proposition d’utilisation de Java pour les cartes


est faite par une équipe de Schlumberger (Austin)

 proposition de Java Card API permettant la programmation en Java de la carte

C’est la Java Card 1.0

 Bull, Gemplus et Schlumberger créent le Java Card Forum


 le JCF discute et propose à Sun des spécifications

Novembre 1997, publication de la spécification Java Card 2.0


Gemplus démontre en oct./nov. CASCADE, le premier chip RISC 32 bit
(ARM 7) avec de la mémoire Flash, « une » implémentation de la Java
Card 2.0 et des DMIs (Direct Method Invocation), etc.

45 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Les évolutions de la 2.x

La version 2.0 de la Java Card Specification introduit:

 un environnement d’exécution

La possibilité d’écrire des applets avec une approche orientée objet
(même si le format de chargement n’était pas encore spécifié)

 Mars 1999, la version 2.1 qui contient 3 parties est publiée:

 Java Card API Specification

Java Card Runtime Environment Specification

Java Card Virtual Machine Specification

46 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Un élément de la technologie Java

47 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Une plate-forme Java Card (résumé)

 est une carte à puce

 avec une machine virtuelle Java

 capable d’exécuter des applications écrites en Java

 Les plateformes Java Card sont normalisées par Sun et Java Card Forum

 Java est le langage de programmation le plus utilisé dans les applications


dédiées à la carte à puce

48 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Java Card = Java + smart Card

49 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Le
Lelangage
langageJava
JavaCard
Card

50 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Acteurs d’une Java Card

51 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Types supportés

52 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Caractéristiques non supportées jusqu’à V2.2.2

Pas de Threads

Pas de chargement dynamique

 Pas de Garbage Collector (ramasse-miettes, jusqu’à la version 2.2)

 Pas de clonage

 Pas de tableaux à plusieurs dimensions

 Toutes ces caractéristiques sont intégrées dans la version 3.0 (pile TCP/IP,
servlets, multi-threading, etc.) : spécification publiée en mars 2008.

53 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Résumé des caractéristiques

Caractéristiques supportées Caractéristiques non supportées

boolean, byte, short long, double, float, char, String

Tableau à une dimension Tableau à plusieurs dimensions

Paquetage Java, classes, interface Threads, sérialisation


et exceptions
Héritage, méthode abstraite, Chargement dynamique de classes
surcharge et création d’objets
(instantiation)
« int » est optionnel Gestionnaire de sécurité

54 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Caractéristiques spécifiques à Java Card

Objets temporaires (APDU, Reset, Select)

Atomicité

 Partage

 Gestion d’exceptions sur la carte (runtime, ISO)

 API particulière : Java Card 2.1.x et 2.2

 Méthodes spéciales pour l’installation d’applets, d’APDUs et de sélection

55 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Processus de développement d’applets

Off-Card

CAP file

On-Card

56 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Comment
Commentécrire
écrireune
uneapplet
applet

57 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Construction d’applets Java Card

Une application carte

Code dans la carte : application serveur = Applet Java Card

Code dans le terminal : application cliente

Une application construite en 3 étapes

 Écriture de l’application serveur (applet)

Installation de l’applet dans la Java Card

Écriture de l’application cliente

58 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Écrire une applet Java Card

Java Card API 2.1

Étapes du développement d’une applet

 Spécifier les fonctions de l’applet :

- spécifier les AIDs (Application IDentity) de l’applet et du paquetage


auquel elle appartient

- écrire le corps de l’applet

- compiler (.class)

- convertir (.cap)

- charger dans la carte

59 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Phases de développement d’une applet

 Spécifier les fonctions de l’applet

 Assigner des AIDs à l’applet et au paquetage contenant la classe de l’applet

 Concevoir les programmes de l’applet

 Définir l’interface entre l’applet et le terminal

60 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Comportement d’une applet

 Application écrite en Java Card

 Applet sur la carte


 est sélectionnée

 reçoit des messages à partir du lecteur

 traite ces messages

 retourne des données au lecteur

 est désélectionnée

61 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Exemple de l’applet porte-monnaie électronique

Les opérations offertes par l’application :


Lire le montant du porte monnaie, débiter ou créditer son compte.

Ces opérations sont implantées sur l’applet à l’aide des méthodes


suivantes : getBalance(), credit(), debit()
Ces méthodes sont appelées directement par la méthode
process().

D’où: pour chaque opération définir une commande APDU qui


déclenchera la méthode correspondante.

62 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Commandes de l’applet porte-monnaie électronique

Commande APDU CREDIT


Commande APDU
CLA INS P1 P2 Lc Data field Le
0xB0 0x30 0x0 0x0 1 Valeur à créditer NS

Commande APDU DEBIT


Commande APDU
CLA INS P1 P2 Lc Data field Le
0xB0 0x40 0x0 0x0 1 Valeur à débiter NS

Commande APDU GET BALANCE


Commande APDU
CLA INS P1 P2 Lc Data field Le
0xB0 0x50 0x0 0x0 NS NS 2

63 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Structure d’une Applet/1

-Inclure javacard.framework
- l’applet doit hériter de la classe Applet
- déclarer les constantes et variables
- dans le constructeur de l’applet, prévoir l’initialisation des variables déclarées
et l’enregistrement auprès du JCRE

Monnaie (byte [] bArray, short bOffset, byte bLength) {


balance = (short) 0x1000;
register();
}
- Une méthode install pour l’installation de l’applet auprès du JCRE
public static void install (byte [] bArray, short bOffset, byte bLength) {
new Monnaie (bArray, bOffset, bLength);
}
L’installation = création de l’objet Applet et son enregistrement.

- Deux méthodes select et deselect pour sélectionner ou désélectionner l’applet,


car avant toute utilisation d’une applet, celle-ci doit être sélectionnée.

64 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Structure d’une Applet/2

-Une méthode process qui traite toute commande APDU reçue du terminal:

public void process (APDU apdu) throws ISOException {


byte [] buffer = apdu.getBuffer();
if (selectingApplet()) return;
….
}
- La méthode process doit faire appel à selectingApplet() car même la
commande APDU SELECT sera reçue par la méthode process.

- Toute commande APDU traitée nécessitera une réponse APDU

65 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Applet porte-monnaie électronique/1

import javacard.framework.*;
public class APurse extends Applet {

/* declaration de constantes */
// code of CLA byte in the command APDU header
final static byte APP_CLA = (byte)0x80;

// codes INS dans l’entete de la commande APDU


final static byte VERIF_INS = (byte)0x20;
final static byte GET_BALANCE_INS = (byte)0x30;
final static byte CREDIT_INS = (byte)0x40;
final static byte DEBIT_INS = (byte)0x50;

// Poids le plus faible a droite


final static short MAX_BALANCE = (short)0x7fff;
final static short MAX_TRANSACTION_AMOUNT = (short)0x3fff;
final static byte [] MAX_BALANCE = {(byte) 0xFF, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF};
final static byte [] MAX_TRANSACTION_AMOUNT = {(byte) 0x00, (byte) 0xFF, (byte) 0xFF, (byte) 0xFF};

66 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Applet porte-monnaie électronique/2

final static short SW_INVALID_AMOUNT = (short)0x6A83;


final static short SW_AMOUNT_EXCEEDS_MAX = (short)0x6A82;
final static short SW_NEGATIVE_BALANCE = (short)0x6A84;

/* instance variables declaration */


byte [] balance;
short balance;

public void Monnaie (byte [] bArray, short bOffset, byte bLength) {


balance = (short) 0x1000;
register();
}

public static void install (byte [] bArray, short bOffset, byte bLength) {
new Monnaie (bArray, bOffset, bLength);
}

67 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Applet porte-monnaie électronique/3

public boolean select () {


return true;
}

public void deselect () {


}

public void process (APDU apdu) throws ISOException {


byte [] buffer = apdu.getBuffer();

if (selectingApplet()) return;

68 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Applet porte-monnaie électronique/4

if (buffer[ISO7816.OFFSET_CLA] != APP_CLA)
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);

switch (buffer[ISO7816.OFFSET_INS]) {
case VERIF_INS : verify(apdu);
break;
case GET_BALANCE_INS : getBalance(apdu);
break;
case CREDIT_INS : credit(apdu);
break;
case DEBIT_INS : debit(apdu);
break;
default : ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
break;
}
}

69 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Applet porte-monnaie électronique/5

public void credit (APDU apdu) {


byte [] buffer = apdu.getBuffer();
byte lc = buffer[ISO7816.OFFSET_LC];
short bytesRead = apdu.setIncomingAndReceive();
if ((lc != BALANCE_RESP_SZ) || (bytesRead != BALANCE_RESP_SZ)) {
ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
}
short creditAmount = Util.makeShort(buffer[ISO7816.OFFSET_CDATA],
buffer[ISO7816.OFFSET_CDATA+1]);
if (creditAmount < 0)
ISOException.throwIt(SW_INVALID_AMOUNT);
if (creditAmount > MAX_TRANSACTION_AMOUNT)
ISOException.throwIt(SW_INVALID_AMOUNT);
if (((short)(balance + creditAmount) > MAX_BALANCE)
|| (((short)(balance + creditAmount) < 0)))
ISOException.throwIt(SW_AMOUNT_EXCEEDS_MAX);
balance = ((short) (balance + creditAmount));
}
….
70
} // fin de l’applet
70 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -
Écriture
Écritured’une
d’uneapplet
appletpour
pourune
uneplateforme
plateforme
Java
JavaCard
CardRMI
RMI

71 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Rappel : Etapes d’
d’un appel de mé
méthode distante

Client Serveur
Serveur de
noms
3. Interroger
2. Publier
Application Cliente

1. Exposer Objet
4. Récupérer distant
Serveur d’objets

7. Appel méthode
6. Arguments
5. Appel de méthode sérialisation
Skeleton

Stub
8. Retour
10. Retour
9. Résultat

72 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Etapes d’
d’un appel de mé
méthode distante en JCRMI

Terminal Carte

Client Serveur
Service de
noms
3. Interroger
2. Enregistrer
0. Créer
Application Cliente

Objet
4. Récupérer 1. Créer distant

Applet Serveur
7. Appel méthode
6. Arguments
5. Appel de méthode sérialisation

Skeleton
Stub
8. Retour
10. Retour
9. Résultat

73 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Le service de noms

• rmiService est un service de noms qui possède une table


de hachage dont les clés sont des noms et les valeurs sont des références
aux objets distants ;

•rmiService est un objet créé par l’applet ;

• Tout objet distant créé par l’applet est enregistré dans rmiService ;

74 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Développer une application JCRMI
Côté
Côté Serveur (carte) /1

1. Définir une interface distante (Xyy.java) ;

2. Créer une classe implémentant cette interface (XyyImpl.java) qui sera l’objet
distant (ou le service)

3. Compiler cette classe (javac XyyImpl.java) ;

4. Créer une applet qui jouera le rôle du serveur d’objets (XyyServer.java) ;

5. Compiler l’applet serveur et l’installer sur la carte ;

75 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Développer une application JCRMI


Côté
Côté Serveur (carte): gé
génération de Stub

6. Lancer le générateur rmic explicitement :

Solaris and Linux platforms:


rmic -classpath ../..;$JC_HOME/lib/javacardframework.jar
-d examples/purse -v1.2 examples.purse.PurseImpl

Microsoft Windows 2000 platform:


rmic -classpath ../..;%JC_HOME%/lib/javacardframework.jar
-d examples/purse -v1.2 examples.purse.PurseImpl

On doit trouver dans examples/purse


PurseImpl_Stub.class
Purse.class

7. L’installation de l’applet sur la carte permet la création du service de noms


rmiService et des objets à enregistrer auprès de ce service;

76 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Développer une application JCRMI
Côté
Côté Client (terminal)

8. La classe cliente qui sera écrite doit disposer localement de :


- l’interface de l’objet distant et du
- stub de l’objet (généré préalablement par rmic lors de la compilation de
l’objet distant)
Le partage de l’objet distant se fait automatiquement grâce à JBuilder alors que
le stub doit être copié explicitement dans le répertoire class du projet Client

9. Créer une classe cliente qui appelle les méthodes distantes de l’objet distant
(XyyClient.java) ;

10. Compiler cette classe et lancer son exécution.

77 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Objectifs du dé
développement en JCRMI

• Appeler le service (méthodes) offert par l’applet comme si le service se trouve


sur le même terminal que le client (faire abstraction de l’endroit physique où se
trouve le service à appeler)

• Avoir un niveau d’abstraction plus élevé afin de ne pas manipuler par


exemple le protocole APDU qui est d’un niveau plus bas

• Séparer les spécifications fonctionnelles de l’application des aspects non-


fonctionnels (relatifs à la communication avec la carte).

78 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


L’interface de l’
l’objet distant

- Inclure en plus de javacard.framework le package java.rmi

- L’interface doit hériter de la classe java.rmi.Remote

public interface Purse extends Remote {

// on déclare les constantes à utiliser


// exemple
public static final short BAD_ARGUMENT = (short)0x6002;

// on définit les signatures des méthodes avec une levée


// de l’exception RemoteException et UserException si exception
// définie par l’utilisateur
// exemple :
public void debit(short m) throws RemoteException, UserException;

79 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Implé
Implémenter l’
l’interface de l’
l’objet distant

- La classe d’implémentation doit étendre CardRemoteObject pour désigner


l’objet distant
- Cette classe doit implémenter l’interface pour associer un code aux méthodes
définies dans l’interface

public class PurseImpl extends CardRemoteObject implements Purse {

// définir le constructeur qui se contente d’appeler la classe mère


public PurseImpl() { super(); }

// associer un code à chaque méthode définie dans l’interface


// en utilisant Java standard
// Exemple de la méthode debit

public void debit(short m) throws RemoteException, UserException {


if(m<=0) UserException.throwIt(BAD_ARGUMENT);

if((short)(balance-m) < 0) UserException.throwIt(UNDERFLOW);

balance -=m;
}

80 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Paramè
Paramètres des mé
méthodes distantes

 Les arguments des méthodes distantes sont de type simple (boolean, byte,
short et int), ou bien un tableau à une dimension de type simple.
Le type int n’est pas supporté par toutes les plateformes.

 La valeur de retour doit être aussi de type simple (boolean, byte, short ou int)
ou bien un type d’interface distante, ou encore de type void.

 Les objets distants sont passés par référence. Une référence à un objet distant
est en fait une référence au stub qui est le représentant local de l’objet côté client.

81 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Construire l’
l’applet Serveur/1

 L’AID attribué à l’applet doit être connu du client (terminal)

 L’objet distant doit être instancié et initialisé, ce qui sera fait dans la méthode
install().

Les objets distants communiqueront avec l’extérieur via la méthode


process() de l’applet.

La méthode install() permet l’enregistrement de l’applet auprès du JCRE


pour qu’elle soit sélectionnée après

Les méthodes select() et deselect() pour la sélection et la désélection de l’applet

82 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Construire l’
l’applet Serveur/2

Le constructeur de l’applet serveur contient la ligne suivante :


 RemoteService rmi = new RMIService(new test.PurseImpl() ) ;
permet de créer l’objet sur la carte et de lui associer une référence RMI
qui sera accessible par le client

 dispatcher = new Dispatcher((short)1) ;


dispatcher.addService(rmi, Dispatcher.PROCESS_COMMAND) ;
définit un seul service à rajouter dans le service de noms (RMIService)

La méthode process() propage la commande APDU vers le service RMI:

 dispatcher.process(apdu)

délègue le traitement de la commande APDU au service RMI qui


propage l’appel à l’objet distant.

83 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Comportement de l’
l’appel côté
côté Serveur

 La commande APDU SELECT invite le service RMI à renvoyer la référence


de l’objet distant.

Une invocation de méthode distante est récupérée par l’applet qui délègue
l’appel au service RMI qui propage l’appel vers l’objet distant. La valeur
retournée emprunte le chemin inverse.

84 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Exemple d’
d’applet Serveur
package RMITest;
import javacard.framework.service.*;
import javacard.framework.*;
import java.rmi.*;
public class PurseApplet extends Applet {
private Dispatcher dispatcher;
protected PurseApplet() {
super();
RemoteService rmi = new RMIService(new RMITest.PurseImpl());
dispatcher = new Dispatcher((short)1);
dispatcher.addService(rmi, Dispatcher.PROCESS_COMMAND);
}
public static void install(byte[] buffer, short offset, byte length) {
//instantiation et enregistrement de l'applet
(new PurseApplet()).register(buffer,(short)(offset+1),(byte)buffer[offset]);
}

public void process(APDU apdu) {


dispatcher.process(apdu);
}
public boolean select() {/* rien a faire*/
return super.select();
}
public void deselect() {/* rien a faire*/
super.deselect();
}
}

85 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Écriture du client

 Dans notre environnement, le client est généré automatiquement. Il restera


uniquement à faire des invocations aux méthodes distantes.

 Opérations faites par le client :


- Initialisation d'un CardAccessor
- Connexion à la plateforme JCRMI
- Sélection de l’applet serveur
- Obtention de la référence de l’objet distant
-Faire les invocations des méthodes de l'objet distant
- Mise hors tension de la carte après « usage ».

86 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Écriture du client: Initialisation d'un CardAccessor

L'interface CardAccessor est utilisée par la plateforme JCRMI pour


communiquer avec la carte. L'initialisation de la carte est effectuée à la création
du CardAccessor :

CardAccessor ca = (CardAccessor) new PCSCAccessor();

87 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Écriture du client: connexion à la plateforme JCRMI

La classe JCRMIConnect permet la connexion du client à la plateformes JCRMI.


Elle fournit les fonctions nécessaires pour sélectionner l'applet.
Le constructeur a besoin d'un CardAccessor.

// Créer une connexion RMI a la plateforme Java Card

JCRMIConnect jcrmi = new JCRMIConnect(ca);

88 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Écriture du client: Sé
Sélection de l’
l’Applet Serveur

Avant toute invocation de méthodes distantes, le client doit sélectionner l'applet


serveur adéquate, identifiée sur la carte par son AID (défini lors de l'installation) :
// sélectionner l'applet Java Card:

jcrmi.selectApplet(AID,JCRMIConnect.REF_WITH_CLASS_NAMES);

89 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Écriture du client: Obtenir la ré


référence de l'objet distant

Le client doit obtenir la référence de l'objet distant pour faire les invocations.

La référence retournée est celle du Stub.

// obtenir la référence initiale de l'interface PurseInterf

PurseInterf myPurse = (PurseInterf) jcrmi.getInitialReference();


if (myPurse == null) {
throw new RuntimeException("Cannot get the initial reference");
}

90 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Écriture du client: Utiliser l'objet distant dans les invocations

Le client utilise la référence de l'objet distant pour faire l'invocation des méthodes.

// appel de la méthode debit()

short balance = myPurse.debit ( debitAmount );

91 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Écriture du client: Fin de l’


l’utilisation de la carte

Terminer l'utilisation de la carte (libération de ressources) :

ca.closeCard();

92 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Exemple de client
Package rmiClient;
import com.sun.javacard.clientlib.*;
import com.sun.javacard.rmiclientlib.*;
import java.rmi.*;
import javacard.framework.UserException;
import rmi.PurseInterf;

public class MonClient {


private static byte AID []= {
(byte) 0xA0, (byte) 0x00, (byte) 0x00, (byte) 0x18,
(byte) 0x50, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x52,
(byte) 0x41, (byte) 0x44, (byte) 0x41
};
static CardAccessor ca = null; PurseInterf wallet;
public MonClient() { }

public static void main(String[] args) {


Instance init try {
ca = (CardAccessor)new PCSCAccessor();
JCRMIConnect jcrmi = new JCRMIConnect(ca);

jcrmi.selectApplet(AID,JCRMIConnect.REF_WITH_INTERFACE_NAMES
);
PurseInterf myPurse = (PursetInterf)
jcrmi.getInitialReference();

myPurse.crediter((short)10000);
myPurse.getBalance());
}
catch(Exception ex) {
System.out.println(ex.getMessage());
}
93 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Exemple de client (suite)

finally{
try {
ca.closeCard();
} catch(Exception e) {
System.out.println(e.getMessage());
}
}
} // end main
} // end class

94 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Résumé
sumé/1

ATR

Terminal Carte

-Dès la mise sous tension de la carte, elle envoie l’ATR au terminal pour
s’identifier.

- L’ATR est prise en compte par l’objet CardAccessor

95 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Résumé
sumé/2

Commande APDU SELECT

Terminal FCI Carte

Lorsque le client appelle la méthode selectApplet de JavaCardRMIConnect,


il envoie une commande APDU SELECT à la carte via l’objet CardAccessor.

L’instance de RMIService répond en envoyant une réponse APDU FCI (File Control
Information) qui inclut la référence à l’objet distant.

96 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Résumé
sumé/3

INVOKE(Réf, debit, (short)val)

Terminal RETURN avec (short)valeur Carte

- Lorsque le client appelle la méthode debit() de l’interface distante Purse,


l’objet PurseImpl_Stub envoie une commande d’invocation vers la carte via
l’objet CardAccessor, en identifiant la référence distante, la méthode et
paramètres de l’invocation.

- L’instance RMIService de l’applet désérialise l’information et appelle la méthode


debit() de l’objet distant et retourne la réponse dans une réponse APDU.

97 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Conclusion: Java Card RMI

Avantages

 offre un niveau d’abstraction plus élevé (pas de manipulation de


commandes/réponses APDU qui deviennent d’un niveau plus bas)

 se concentre sur l’aspect fonctionnel (l’aspect non-fonctionnel telle que


la communication selon le protocole APDU est à la charge de la plateforme)

 le code écrit est réutilisable sur d’autres plateformes JCRMI car il utilise
les services de RMI sans faire appel à des caractéristiques intrinsèques
(clés de sécurité, commandes APDU particulières ) à la carte: c’est le
principe de PIM.

Inconvénient
 JCRMI cache les spécificités de la carte et les problèmes liés à son interaction
(la gestion de la sécurité, le protocole APDU, etc.) qui sont importants à connaître
si on s’intéresse à ce domaine.

98 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Bibliographie

1. http://java.sun.com/products/javacard/
2. Technology for smart cards: architecture and programmer’s guide, Zhiqun
Chen, Addison Wesley, sept. 2000
3. Understanding Java Card 2.0, Zhiqun Chen & Rinaldo Di Giorgio
4. http://www.javaworld.com/javaworld/jw-03-1998/jw-03-javadev.html
5. http://javacardforum.org
6. Zhiqun Chen, “How to write a Java Card applet: A developer's guide”,
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-javacard.html.
7. Pierre Paradinas, Support de cours sur « Java Card », UV de Systèmes
Enfouis et Embarqués, Valeur C, Laboratoire CEDRIC, CNAM.
http://deptinfo.cnam.fr/~paradinas/cours/ValC-IntroJavaCard.pdf
8. Global Platform, Card Specification :
http://www.globalplatform.org/specificationform2.asp?id=archived
9. API Java Card : http://java.sun.com/products/javacard/htmldoc
10. Eric Vétillard : http://javacard.vetilles.com/2006/09/17/hello-world-smart-card/
11. Formation dispensée par Jan Nemec de Gemalto dans le cadre du concours
SIMAGINE, nov. 2007.
12. Application Programming Notes : Java Card™ Platform, Version 2.2.1,
Sun MicroSystems, 2003.
13. Samia Bouzefrane, Java RMI, Support de Cours en NFP111,
99
http://cedric.cnam.fr/~bouzefra
samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -

Bibliographie

Magazine MISC nov./déc. 2008 Octobre 2008

100 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -


Webographie

http://java.sun.com/javacard/3.0/
http://www.gemalto.com
http://www.oberthur.com
http://www.globalplatform.org
http://www.javacardforum.org
http://www.opencard.org
http://www.linuxnet.com/
http://www.iso.org
http://www.ttfn.net/techno/smartcards/
http://eurekaweb.free.fr/ih1-carte_a_puce.htm
http://membres.lycos.fr/dbon/historique.htm
http://apte.net/info-e/pubs.htm
Articles MISC hors série Cartes à puce, octobre et novembre 2008.

101 samia.bouzefrane@cnam.fr - CEDRIC ( CNAM) -