Cartes - À Puce en Java - Card - RMI

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

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

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
Famille de produits
carte à mémoire
carte logique câblée
carte à microprocesseur

Développement d’une application
Carte mémoire = X zones mémoires
Carte à micro-processeur : installation de vrais programmes
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é

Synoptique interne d’une carte à microcontrôleur
Fonctionnement

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
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

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.
La
Lanormalisation
normalisation

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é,
...
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.

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

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
Les 3 formats
ID 01
ID 00 ID 000

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)
Normalisation AFNOR / ISO
La position des contacts : position AFNOR et position ISO
Carte ISO
Carte AFNOR

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.
L’ISO 7816-2
Valeurs en mm

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

Le
Leprotocole
protocoleAPDU
APDU
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.

L’ISO 7816-4 : Le protocole APDU
carte
terminal
Commande APDU (xxxx)
Réponse APDU (xxxx)
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

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
Exemples de classes : CLA

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
La
Lagestion
gestiondes
desfichiers
fichiersd’une
d’unecarte
carteààpuce
puce

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
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

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.
Les commandes de gestion de fichiers
Binary (read, write, search, erase)
Record (read, write, update, append, search, erase)
Get/Put Data

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
La
Latechnologie
technologieJava
JavaCard
Card: :introduction
introductionet
etprincipe
principe

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
É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
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.
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

Un élément de la technologie Java
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

Java Card = Java + smart Card
Le
Lelangage
langageJava
JavaCard
Card

Acteurs d’une Java Card
Types supportés

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.
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é

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
Processus de développement d’applets
Off-Card
CAP file
On-Card

Comment
Commentécrire
écrireune
uneapplet
applet
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

É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
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

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

Commandes de l’applet porte-monnaie électronique
Commande APDU CREDIT

Commande APDU
0xB0 0x30 0x0 0x0 1 Valeur à créditer NS
Commande APDU DEBIT

Commande APDU
0xB0 0x40 0x0 0x0 1 Valeur à débiter NS
Commande APDU GET BALANCE

Commande APDU
0xB0 0x50 0x0 0x0 NS NS 2
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.

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
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};

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);
}
public boolean select () {

return true;
}
public void deselect () {

}
public void process (APDU apdu) throws ISOException {

if (selectingApplet()) return;

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;
}
}
public void credit (APDU apdu) {

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
Écriture
Écritured’une
d’uneapplet
appletpour
pourune
uneplateforme
plateforme
Java
JavaCard
CardRMI
RMI
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

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
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 ;

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 ;

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;

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

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;
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;
}

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

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

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();
}
}
É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 ».

É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();
É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);

É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);
É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");
}

É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 );
Écriture du client: Fin de l’

l’utilisation de la carte
Terminer l'utilisation de la carte (libération de ressources) :
ca.closeCard();

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());
}
Exemple de client (suite)
finally{
try {
ca.closeCard();
} catch(Exception e) {
System.out.println(e.getMessage());
}
}
} // end main
} // end class

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

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

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

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.

Cartes - À Puce en Java - Card - RMI

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cartes - À Puce en Java - Card - RMI

Uploaded by

Copyright:

Available Formats

La

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

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

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

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

Historique – Invention de la carte à puce

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

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

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

Implication industrielle de Bull et Schlumberger

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

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)

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

carte logique câblée

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

Carte mémoire = X zones mémoires

Carte à micro-processeur : installation de vrais programmes

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

Cartes à puce intelligentes

Interface série: UART simplifié

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

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

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

Les prémisses (avant 1990):

Les évolutions (1990-1995) :

En avant vers l’ouverture...

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

Architecture matérielle aujourd’hui

CPU : 8, 16 & 32 bits,

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

Début des années 90:

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

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

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

Les normes liées à la carte :

ETSI, (télécommunications, GSM)

EMV, (cartes de paiement)

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

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

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

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

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

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

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

La norme ISO 7816-1

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

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

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

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