Introduction à Java Card

Introduction à Java Card
par
Étienne Gagnon
Plan
●
Introduction
●
Sous-ensemble de Java
●
Compilation et installation
●
Structure d'une « applet »
●
Gestion des mémoires
●
Atomicité et transactions
●
Bibliothèque
●
Conclusion
Introduction
●
●
Programmation en Java - matériel restreint :
–
peu de capacité de calcul
–
peu de mémoire / spéciale : RAM & EEPROM
Destiné aux cartes à puces « intelligentes »
Introduction (suite)
●
Avantages :
–
Supporte les systèmes à 8, 16 et 32 bits
–
Facilité de développement
–
Portabilité
–
Sécurité
●
●
–
pas de corruption de mémoire
« firewall » entre applications (pas couvert aujourd'hui)
Compatibilité avec standards (ISO 7816)
Sous-ensemble de Java
●
Java Card ne retient qu'un sous-ensemble de
Java :
–
Pas de threads / synchronisation
–
Types primitifs supportés : boolean, byte, short
–
Pas de virgules flottantes (float/double), String, char
–
int est optionnel (spécifique à la plateforme)
–
Tableaux à une seule dimension
–
Pas de collections (java.util.*)
–
java.lang.Object dénudé, 1 méthode : equals()
Compilation
●
●
●
Une « applet » est compilée avec « javac »
produisant des fichiers *.class
Elle est ensuite traduite et empaquetée dans un
fichier CAP
Le fichier CAP est installé sur la carte
intelligente par un processus particulier à la
plateforme (i.e. non-standard)
Installation
Machine Virtuelle Java Card (JCRE)
Fonctionnement JCRE
●
●
●
La machine virtuelle n'est jamais redémarrée;
elle a un fonctionnement « éternel »
Lorsque le courant est remis (i.e. la carte est
insérée dans le lecteur), la machine virtuelle
redémarre son exécution à partir d'un point
précis
Spécificités (lors de la perte de courant) :
–
mémoires permanente et volatile
–
opérations atomiques et transactionnelles
Fonctionnement
Modèle de programmation
●
Une application « applet » fonctionne en mode
réactif (i.e. serveur)
●
Tâche : répondre aux requêtes APDU
●
Une applet hérite de la classe Applet :
–
install
–
select
–
process
–
deselect
Applet Identifier (AID)
Communication
Communication (suite)
public class WalletApp extends Applet {
public static void install
(byte[] bArray, short bOffset, byte bLength) {
new WalletApp();
register()
}
...
}
public void process(APDU apdu) {
byte[] buffer = apdu.getBuffer();
...
// verify the CLA byte
if (buffer[ISO7816.OFFSET_CLA] != Wallet_CLA)
ISOException.throwIt
(ISO7816.SW_CLA_NOT_SUPPORTED);
}
// check the INS byte to decide which service method to call
switch (buffer[ISO7816.OFFSET_INS]) {
case GET_BALANCE: getBalance(apdu); return;
case DEBIT: debit(apdu); return;
case CREDIT: credit(apdu); return;
case VERIFY: verify(apdu); return;
default:
ISOException.throwIt
(ISO7816.SW_INS_NOT_SUPPORTED);
}
Gestion de la mémoire
●
JCRE n'a pas de « garbage collector » !
–
●
Rappel : JCRE vit éternellement
Les cartes à puces ont 3 types de mémoire :
–
ROM
●
–
EEPROM
●
●
–
ne peut être gravée qu'une fois
Lente, mais peu chère
préserve son contenu lors du retrait du courant
RAM
●
●
Rapide (1000 * EEPROM), mais plus chère
volatile
Typiquement
●
La mémoire ROM est gravée lors de la
fabrication, peut contenir :
–
●
La mémoire EEPROM est initialilsée lors de
l'installation de l'applet, peut contenir :
–
●
JCRE, bibliothèques
applets, bibliothèques du développeur, données
sauvegardées
La mémoire RAM est utilisée lors de l'exécution
de l'installateur et des applets, peut contenir :
–
données volatiles
Utilisation de la RAM
●
●
Toutes les variables locales et les paramètres
de méthodes (i.e. pile d'exécution) sont placés
dans la RAM
On peut allouer des tableaux dans la RAM avec
l'API :
–
JCSystem.makeTransient***Array()
Utilisation de l'EEPROM
●
●
Tous les objets alloués avec « new » sont
placés en EEPROM
Tous les attributs statiques de classe sont
placés en EEPROM
Éviter les fuites de mémoires
●
●
●
On alloue tous les objets à l'invocation de la
méthode « install() » lors de l'installation de
l'applet sur la JCRE
Cette appel est transactionnel; s'il échoue (i.e.
exception), toute la mémoire allouée est
automatiquement libérée
Les méthodes select, process et deselect ne
doivent pas allouer de mémoire
Atomicité et transactions
●
●
●
Toutes les écritures de valeurs primitives
(boolean, byte, short, int) sont atomiques
JCRE supporte les « transactions » pour
préserver le contenu de l'EEPROM :
–
récupération des valeurs initiales
–
réclamation de la mémoire allouée
API :
–
JCSystem.beginTransaction();
–
JCSystem.commitTransaction();
–
JCSystem.abortTransaction();
Limites et complication
●
●
●
Les transactions imbriquées ne sont pas
supportées
Le contenu de la mémoire RAM n'est pas
préservé lors de l'avortement d'une transation
(Complication : La JCRE remet
automatiquement à « null » le contenu d'une
variable locale référençant un objet réclamé)
Bibliothèque Java Card
●
java.lang :
–
●
Object / Throwable
java.card :
–
java.card.framework :
●
–
java.card.security :
●
●
Applet, JCSystem, Util, APDU, AID, OwnerPIN
KeyPair, MessageDigest, RandomData, Signature, etc.
java.cardx :
–
java.cardx.security : contrôle d'exportation (US)
–
java.cardx.* : optionnels
Références
●
Le contenu, les exemples et les images de
cette présentation sont tirés de :
–
Zhiqun Chen, Java Card™ Technology for Smart
Cards, Addison-Wesley Professional, 2000, ISBN10: 0-201-70329-7
Conclusion
●
Java Card = « Java - - »
●
Pour cartes à puce « intelligentes »
●
Pas de garbage collector
●
Mode réactif
●
Mémoires volatile et permanente
●
Atomicité et transactions
●
Bibliothèque minimale