stéphane amato julien chabanon novembre 2001 carte à puce et java

Stéphane AMATOJulien CHABANON

Novembre 2001

Carte à puce et Java

Historique

Partie I : Carte à puce

Partie II : JavaCard

Conclusion

Sommaire

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Sommaire

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Historique

Historique (1/6)

1974 - Roland Moreno crée la carte à puce à circuit intégré


1979 - Création de Bull CP8

Historique (2/6)

1980 - La carte à puce comme un nouveau moyen de paiement


1983 - La carte à puce dans le secteur sanitaire et social

Historique (3/6)

1984 - La télécarte


1986 : 2 millions de cartes vendues par an1991 : 6 millions de cartes vendues par mois

Historique (4/6)

Novembre 1996 - Schlumberger simplifie la programmation des SmartCards Spécification JavaCard 1.0


Février 1997 - Bull, Sun et Gemplus se joignent à Schlumberger pour fonder le JavaCard forum

Novembre 1997 - Sun présente les spécifications de JavaCard 2.0

Historique (5/6)

Mars 1999 - La version 2.1 des spécifications de la JavaCard sort :

The JavaCard 2.1 API Specification The JavaCard 2.1 Runtime Environment Specification The JavaCard 2.1 Virtual Machine Specification


Historique (6/6)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - JavaCard

Les différents types de cartes

Le système informatique

La normalisation

Cycle de vie d’une carte

Carte à puce

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Type de carte

Carte à mémoire

Mémoire simple (sans processeur) accessible en lecture sans protection, mais l’écriture peut être rendue impossible Programmation impossible Carte « porte-jetons » pour applications de prépaiement (carte téléphonique)

Types de cartes (1/3)


Carte à logique câblée

Mémoire accessible via des circuits préprogrammés et figés pour une application particulièreCarte « sécuritaire » pouvant effectuer des calculs figés (accès à un local …)



Carte à puce ou SmartCard

Microcontrôleur encarté (processeur + mémoires) Carte « programmable » pouvant effectuer tout type de traitements





La normalisation


Carte à puce

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Système informatique

Processeur, mémoire, interface de communications

Un véritable ordinateur mais : Communiquant environ 300 fois moins vite (de 3,58 à 4,92 MHz) Possédant 200 000 fois moins de mémoire (64 Ko de ROM)

Système informatique (1/2)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Système informatique

Une application carte = une carte + un terminal

Traitement conjoint des données présentes sur la carte ET sur le terminal

Communication entre la carte et le terminal

Système informatique (2/2)




La normalisation


Carte à puce

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Normalisation

ISO 7816

Format carte de crédit

Définition des contraintes physiques supportables (chaleur, humidité...)

85 mm

54 mm

0,76 mm

Normalisation (1/7)


La puce Seule interface de communication avec l’extérieur Lecteur de cartes = CAD (Card Acceptance Device) Surface 25 mm² Épaisseur 0,3 mm Composée de 8 contacts métalliques

Normalisation (2/7)


Protocoles de communication

ISO 7816-3 Protocoles de communication asynchrones et half-duplex

Normalisation (3/7)


Format de commandes

Protocole APDU Application Protocol Data Unit Communication entre le lecteur de cartes (CAD) et la SmartCard Message de commande du lecteur vers la carte ou ... ... message de réponse de la carte au lecteur

Normalisation (4/7)


Commandes applicatives ISO 7816-4 : Manipulation des données au travers d’une structure hiérarchique de fichiers ISO 7816-5 : Identification des applications ISO 7816-6 : Éléments de données référencées (accès direct) ISO 1816-7 : Manipulation des données au travers d’un schéma relationnel ETSI GSM 11.11 : Commandes des cartes S.I.M. E.M.V. : Commandes de paiement ...

Normalisation (5/7)


Le microcontrôleur (1/2)

Technologie M.A.M. : Substrat de silicium (0,35 à 0,7 microns) contenant microprocesseur + bus + mémoires Mémoire non volatile reprogrammable

Sécurité : Composant inaccessible (seule la puce l’est) Détecteurs de conditions anormales

Normalisation (6/7)


Le microcontrôleur (2/2)

Types de microprocesseurs utilisés : 8, 16 ou 32 bits + coprocesseur cryptographique Hitachi, Motorola, NEC, SGS-Thomson, Siemens...

Types de mémoires : ROM : jusqu’à 64 Ko (mémoire non volatile en lecture seule) RAM : jusqu'à 2 Ko (mémoire volatile) Flash EEPROM : jusqu'à 32 Ko (mémoire non volatile réinscriptible)

Normalisation (7/7)




La normalisation


Carte à puce

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Cycle de vie

FabricationROM : inscription d’un programme définissant les fonctions de base de la carte

InitialisationEEPROM (Electrical Erasable Programmable ROM) : inscription des données communes à l’application

PersonnalisationEEPROM : inscription des données personnelles de l’utilisateur

Cycle de vie (1/2)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Cycle de vie

Utilisation Envoi d’APDU de commandes à la carte via le lecteur (CAD) Traitement des commandes effectué par le masque de la carte Sinon renvoi d’un code d’erreur

Mort Invalidation logique (volontaire ou lors d’une tentative d’intrusion), saturation mémoire, vol, perte, bris ...

Cycle de vie (2/2)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Résumé

La carte à puce est un véritable serveur embarqué Elle gère des données personnelles et les sécurise

Cependant :

Le code applicatif est figé en ROM Pas de protocole standard de communication entre le lecteur et son hôte Communications de bas niveaux (APDUs) nécessite des compétences spécifiques

Résumé


Présentation

Architecture

Les outils commerciaux adaptés à la JavaCard

Quelques applications

JavaCard

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Présentation

JavaCard un sous-ensemble du langage Java

Une applet est une application JavaCard

Possibilité de charger dynamiquement une nouvelle applet

JavaCard lié aux spécificités des SmartCard

Présentation (1/3)


Supportés Non supportés

Boolean, byte, short, int

Object Tableau à une

dimension Méthodes virtuelles Allocation dynamique Paquetages Exceptions Interface Méthodes natives

Float, double, long Char, String Tableau à n

dimensions Class et ClassLoader Ramasse-miettes SecurityManager Threads

Présentation (2/3)


API java.lang de JavaCard réduite à : Object { public Object () ;

public boolean equals (Object obj) ; } Throwable { public Throwable () ; }-- Exception

-- RuntimeException-- Arthmetic Exception-- ClassCastException-- NullPointerException-- SecurityException-- ArrayStoreException-- NegativeArraySizeException-- IdexOutOfBoundsException

-- ArrayIndexOutOfBoundsException

Présentation (3/3)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - JCVM

Implémentation en deux parties : La partie on-card (SmartCard) La partie off-card (JavaCard)

Machine virtuelle

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Les standards Class Librairies

JavaCard.lang

JavaCard.framework

JavaCard.security

JavaCardx.crypto

Librairies standard

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - JCRE

JCRE = JavaCard Runtime Environment

JCRE

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Compiler en Java

Obtention d’un code JavaCard

Compiler en Java (1/3)

Bytecode désassemblé


...public static int fact(int n){ int i,j; j=1; for(i=1;i<n;i++) j*=i; return j;}...

...Method public static int fact(int)>> max_stack=2, max_locals=3 << 0 iconst_1 1 istore_2 2 iconst_1 3 istore_1 4 goto 14 7 iload_2 8 iload_1 9 imul10 istore_211 iinc_1 by 114 iload_115 iload_016 if_icmplt 719 iload_220 ireturn...



Récapitulatif des opérations



Présentation

Architecture



JavaCard

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Architecture

Méthodes Natives

Donne accès aux ressources physiques telles que la mémoire, les E/S, le coprocesseur cryptographique

Machine Virtuelle Java (interpréteur)

Exécute les applets, garantit la sécurité et gère le partage des données

Librairies standard (API)

Interface cachant l’infrastructure de la carte

Applet N

Programme

Applet 1

Programme

Card Executive

Charge et sélectionne les applications

Communique avec le monde extérieur

Gère le cycle de vie de la carte

Architecture (1/8)


Méthodes natives

Fonctions de bas niveaux gérant Les E/S La mémoire Le coprocesseur cryptographique

Architecture (2/8)


Machine virtuelle Java

Exécute le bytecode (obtenu après compilation et édition de liens) Offre le support du langage Gère le partage des données entre applications Implantée au dessus du circuit intégré (OS + méthodes natives)

Indépendance totale par rapport à la plate-forme de la carte

Architecture (3/8)


Librairies standard

Ensemble d’APIs Cache les détails de l’infrastructure Interface facile à manipuler Définition des conventions utilisées par les applets pour accéder aux méthodes natives

Architecture (4/8)


Applets

Programmes écrits en JavaCard puis compilés Exécution en réponse à des demandes du terminal

Architecture (5/8)


Installation d’une applet

Réalisé lors de la fabrication de la carte ou de sa mise à jour à partir d’un terminal Chargement l’applet en mémoire (ROM ou EEPROM) Appel automatique de la méthode install () par le JCRE : phase de connaissance Applet définitivement connue par le JCRE

Architecture (6/8)


Sélection, activation et désactivation d’une applet

Une Applet est inactive tant qu’elle n’est pas sélectionnée pour être exécutée Identification d’une Applet par une clé unique Sélection réalisée par le terminal Suspension de l’exécution de l’Applet active : deselect() Activation de l’Applet sélectionnée : select() Le JCRE redirige tous les APDUs de commande vers cette Applet

Architecture (7/8)


Communication avec les applets

Le JCRE appelle process() lorsqu’il reçoit un APDU de commande pour cette applet

Architecture (8/8)


Présentation

Architecture



JavaCard

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Les outils commerciaux

Odissey-Lab de Bull

GemXpresso Rapid Applet Development (RAD) de Gemplus

Cyberflex 2.0 Multi8K de Schlumberger

Outils commerciaux

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Odissey-Lab de Bull

Conforme aux spécifications JavaCard API 2.0 Sa JVM est l’une des plus performantes du marché selon Bull A été conçu pour les besoins des plate-formes ouvertes Est adaptée à de nouveaux mécanismes de sécurité

Odissey-Lab de Bull

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - GemXpresso RAD de Gemplus

Plate-forme de développement basée sur les spécifications de JavaCard 2.0 et sur un processeur RISC 32 bits Supporte les API JavaCard 2.0 pour 8 ou 32 bits Accélère le développement et les tests Simulateur pour tester les programmes directement sur une station de travail

GemXpresso RAD de Gemplus

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Cyberflex de Schlumberger

Conforme aux spécifications de JavaCard 2.0 Pas d’environnement de développement car très facile de l’intégrer dans un environnement de développement Java existant Simulateur qui vérifie le code

Cyberflex de Schlumberger


Présentation

Architecture



JavaCard

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Applications

Télévision

Santé

Applications (1/2)

Stéphane AMATO / Julien CHABANON Novembre 2001Cartes à puce et Java - Applications

Carte d’étudiant

Fidélité

Applications (2/2)


• Carte à puce vs JavaCard

Conclusion

stéphane amato julien chabanon novembre 2001 carte à puce et java

Documents