Construction d’applications avec la carte à puce


Construction d’applications avec la carte à puce

 

École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 École d?été IMAG, INRIA, LIFL - Autrans, août 1999 « Construction d?applications réparties » Construction d?applications avec la carte à puce Jean-Jacques Vandewalle Gemplus Research Lab Introduction Qu?est-ce donc que ce cours ? J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Pourquoi la carte à puce ? ? La carte à puce est un système informatique u Disposede processeur, mémoires, interface de communication ? Une application avec la carte à puce est une application répartie u «Application carte» = (serveurs +) terminaux + cartes u Traitements et données présents à la fois dans le terminal, (le lecteur,) et la carte u Nécessité de communiquer entre le terminal et la carte ? Rôle de la carte à puce de plus en plus important u Commerce (électronique), fidélité, sécurité (physique, logique), dossier portable, ... 3 Sujet du cours ? La construction d?applications carte u En fonction des spécificités de la carte à puce ½ Support matériel, normalisation ½ Interfaces matérielle (terminal - lecteur - carte) et logicielle (protocoles de communication) ½ Mode de programmation hérité des composants embarqués u En fonction des besoins des applications ½ Souplesse de développement, haut niveau de sécurité, évolutivité des applications TM u Illustrée avec la plate-forme Java Card et l?environnement TM de développement GemXpresso 4 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Auditoire du cours ? Concepteurs et développeurs d?applications réparties u Curieux de la carte à puce u Intéressés par la sécurisation de données/d?accès à base de cartes u Intéressés par la distribution de données sur support individuel ? Concepteurs et développeurs d?applications carte TM u Curieux du langage Java u Concernés par l?évolution récente des environnements carte u Intéressés par les techniques issues des environnements répartis 5 Programme du cours ? Première partie : Carte à puce et Java u De Roland Moreno à la Java Card (30 mn.) u La technologie Java Card 2.0 (40 mn.) Illustré par un exemple u Nouveautés : Java Card 2.1, VOP 2.0, OCF 1.1 et Systèmes concurrents (20 mn.) ? Deuxième partie : GemXpresso u Discussion (10 mn.) u Application des principes de programmation des applications réparties à la Java Card (40 mn.) Illustré par un exemple u Sujets à appronfondir et perspectives de travail (10 mn.) u Conclusion et discussion (15mn.) 6 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Objectif du cours ? Hypothèse : La carte à puce est un élément des systèmes d?information ? Problème : Elle est difficile à intégrer dans les applications ? Lemme : Montrer que Java Card offre aux développeurs «non carte» la possibilité de programmer facilement des cartes à puce ? Théorème : Montrer qu?une application carte peut être construite comme une application répartie ? Corollaire : La construction d?applications avec la carte à puce devient plus simple 7 Cheminement de la démonstration ? Expliciter ce qu?est une carte à puce u Comment ça fonctionne u Qu?est-ce qu?on en fait ? Expliciter la plate-forme Java Card u Plate-forme Java appliquée à la carte puce u Utilisation du langage Java et de l?API Java Card ? Expliciter comment construire des applications carte u En appliquant les techniques des systèmes répartis à la Java Card ? Ouvrir des pistes pour aller plus loin 8 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 De Roland Moreno à la Java Card État de l?art de la carte à puce Historique (1/2) ? 1974 : Dépots de brevets par Roland Moreno ? 1978 : Michel Ugon (Bull CP8) invente le M.A.M. ? 1980 : Création du G.I.E. «carte à mémoire» ? 1981 : Début de la normalisation AFNOR ? 1982-1984 : Expérimentation de paiement par cartes sur 3 sites. La technologie Bull est retenue pour les «cartes bancaires» (CB) ? 1983 : Lancement de la «télécarte» par la D.G.T. Début de la normalisation ISO ? 1988 : Création de Gemplus 10 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Historique (2/2) ? 1990 : «Télécarte» entre dans le dictionnaire ? 1992-1999 : Essor des applications avec des cartes à puce u Généralisation des CB u Téléphonie mobile (GSM) utilise une carte SIM u Premières expériences de carte santé (Sésame, Vitale, All.) u Premiers porte-monnaie électroniques (Proton, La Poste) ? 1992-1999 : Développement de la technologie carte u Augmentation des capacités matérielles u Systèmes d?exploitation de plus en plus ouverts u Système Java Card 11 Différents types de cartes ? Carte à mémoire u Mémoire simple (sans processeur) accessible en lecture sans protection, mais l?écriture peut être rendue impossible u Carte «porte-jetons» pour applications de pré-paiement ? Carte à logique câblée u Mémoire accessible via des circuits pré-programmés et figés pour une application particulière u Carte «sécuritaire» pouvant effectuer des calculs figés ? Carte à puce u Microcontrôleurencarté (processeur + mémoires) u Carte «programmable» pouvant effectuer tout type de traitements 12 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Caractéristiques des cartes à puce ? La normalisation u Caractéristiquesphysiques u Protocoles de communication u Commandes applicatives ? Le microcontrôleur u Technologie M.A.M. et élements de sécurité u Types de microprocesseurs u Types des mémoires ? Les fonctionnalités u Cycle de vie de la carte u Fonctions applicatives de la carte 13 Normalisation du matériel ? ISO 7816 u Partie 1 : caractéristiques physiques ½ Format carte de crédit (85 * 54 * 0.76 mm.) ½ Définition des contraintes que doit supporter une carte u Partie 2 : dimensions et positions des contacts 3 v. ou 4.75-5.25 v. VCC GND Signal de R.A.Z. Écriture mémoire EPROM RST (VPP) 3.58 ou 4.92 MHz CLK I/O 1 seule ligne ==> semi-duplex (RFU) (RFU) u Partie 3 : caractéristiques électriques 14 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Normalisation de la communication ? ISO 7816-3 pour protocoles lecteur-carte u Transmission d?un caractère ½ 1 bit démarrage, 8 bits données, 1 bit de parité ½ Définition d?un temps de garde entre 2 caractères u Réponse de la carte à la R.A.Z. : séquence d?octets décrivant les caractéristiques de la carte u Sélection du type de protocole u Protocoles de communication (asynchrones et semi-duplex) ½ Mode maître-esclave : la carte répond à des commandes ½ T=0 : transmission de caractères (le plus utilisé) ½ T=1 : transmission de blocs de caractères 15 Normalisation du format des commandes ? ISO 7816-4 u Définition du format des «paquets de données» échangés entre un lecteur et une carte : APDUs (Application Programming Data Units) de commande et de réponse u Mots d?état SW1 et SW2 standardisé (OK = 0x9000) 16 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Normalisation de commandes ? 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 7816-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 ? etc. 17 Microcontrôleur pour carte (1/2) ? Contraintes physiques ISO 7816-1 ==> u Surface <= 25 mm2 u Épaisseur <= 0,3 mm. ? Fondé sur la technologie M.A.M. u Microprocesseur + bus + mémoires réunis sur un même substrat de silicium (technologie de 0,7 à 0,35 microns) u Peut être «re-programmé» par l?écriture de programmes en mémoire non-volatile ? Éléments de sécurité u Composant inacessible u Détecteurs de conditions anormales 18 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Microcontrôleur pour carte (2/2) ? Types de microprocesseur u 8-16-32 bits (+ coprocesseur cryptographique) u SGS-Thomson, Siemens, Motorola, Hitachi, NEC, etc. ? Types des mémoires u ROM (Read-Only Memory) : mémoire non-volatile à lecture seule (jusqu?à 64 Ko) u RAM (Random Access Memory) : mémoire volatile à accès rapide (jusqu?à 2 Ko) u EEPROM (Electrical Erasable Programmable ROM) : mémoire non-volatile réinscriptible (jusqu?à 32 Ko) ½ l?EPROM devenue obsolète ½ Nouveaux types : Flash EEPROM 19 Cycle de vie de la carte (1/2) ? Fabrication u Inscription d?un programme en mémoire ROM définissant les fonctionnalités de base de la carte : «masque» figé sachant traiter un nombre limité de commandes pré-définies ? Initialisation u Inscription en EEPROM des données communes à l?application u Possibilités pour certaines cartes d?ajouter des «filtres» ? Personnalisation u Inscription en EEPROM des données relatives à chaque porteur 20 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Cycle de vie de la carte (2/2) ? Utilisation u Envoi d?APDUs de commande à la carte u Traitement de ces commandes par le masque de la carte ½ Si commande reconnue ? Traitement en interne de la commande ==> lecture/écriture de données en EEPROM ? Renvoi d?un APDU de réponse ½ Si commande inconnue ? Renvoi d?un code d?erreur ? Mort u Par invalidation logique, saturation de la mémoire, bris, perte, vol, etc. 21 Fonctionnalités des masques carte ? Caractéristique commune : définition d?un jeu figé de commandes que la carte sait traiter ? Types de masques u Masque spécifique à une application (B0?, Proton, SIM) : Lecture/écriture de données figées avec règles de sécurité figées u Masque spécifique à un contexte applicatif (GPK, CryptoFlex) : Lecture/écriture de données formatées, fonctions de sécurité adaptées au contexte u Masque générique (MCOS, MFC, PocketBase) : Lecture/écriture de données, algorithmes cryptographiques 22 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Développement d?applications carte ? La carte u Accessible via un jeu de commandes figé gravé lors de la fabrication du composant u Maintient des données pouvant évoluer ? Le lecteur et la communication avec la carte u Nécessite un lecteur de cartes (et donc un «driver» pour le piloter) u Messages échangés définis par des APDUs de commande ? Le terminal et l?application cliente u Communique avec la carte via le driver du lecteur u Envoie des requêtes APDUs conformes au jeu de commandes de la carte 23 Architecture d?application carte ? Schéma général u Le terminal contrôle, la carte est passive u Dialogue terminal-carte de type requête/réponse u Format de messages standard : APDUs 24 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Éléments importants ? Le code applicatif de la carte est gravé en ROM au moment de la fabrication u La carte est un serveur figé en terme de fonctionnalités u Le développement du code nécessite des compétences carte ½ Le code est généralement développé par les fabricants u Pas de possibilité d?évolution et d?adaptation du code ½ Pas de chargement dynamique de nouveaux programmes en EEPROM ? Pas de protocole standard de communication entre le système hôte et le lecteur u Pas d?API standard d?accès aux drivers des lecteurs u Drivers offrent uniquement une API de transport des APDUs 25 Difficultés à la construction d?applications ? Si l?application requiert de nouvelles fonctions carte u Nécessite le développement d?un nouveau masque (coûteux) ? Si les fonctionnalités de la carte doivent pouvoir évoluer u Nécessiteun masque qui accepte d?exécuter des programmes en EEPROM (rare et pas standardisé) ? Intégration dans les systèmes d?informations u Pas d?interface standard de communication avec les différents lecteurs (travaux en cours) u Communication via APDUs (très bas niveau) 26 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Résumé de l?état de l?art ? La carte à puce est un véritable ordinateur utilisé comme serveur portable et sécurisé de données personnelles ? Elle est programmée comme un composant embarqué avec un code applicatif figé ? Elle est difficile à intégrer dans les systèmes d?informations 27 Vers des cartes plus ouvertes (1/2) ? Problèmes à résoudre et/ou besoins à satisfaire u Permettre le développement de programmes pour la carte sans avoir besoin de graver un nouveau masque ½ Faciliter et accélérer les développements de codes dans la carte u Faire de la carte un environnement d?exécution de programmes ouvert (chargement dynamique de code) ½ Rendre plus souples et plus évolutives les applications carte u Faciliter l?intégration des cartes dans les applications ½ Faciliter et accélérer les développements d?applications clientes des cartes 28 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Vers des cartes plus ouvertes (2/2) ? Éléments de solutions u Java Card ½ Utiliser le langage Java pour programmer les cartes ? Bénéficie d?un langage orienté objet ½ Utiliserla plate-forme Java pour charger et exécuter des applications dynamiquement ? Bénéficie d?une architecture sécuritaire u GemXpresso ½ Utiliserles concepts de la programmation d?applications réparties pour développer des applications carte avec Java Card ? Bénéficie des concepts du client-serveur orienté objet 29 La technologie Java Card Comprendre Java Card J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Comprendre Java Card : sommaire ? Les concepts u Qu?est-ce que Java Card ? u Statut du standard Java Card u Sous-ensemble du langage Java u La machine virtuelle u Le modèle mémoire ? La pratique u Concepts de programmation u Les APIs de programmation u Développement d'une applet Java Card u Construire une application avec la Java Card 31 Qu?est-ce que Java Card ? ? Une Java Card est une carte à puce qui peut exécuter des programmes Java (applets carte) u Utilisationdu langage Java pour programmer des applications carte ½ Basée sur un «standard», programmation orientée-objet u Java Card définit un sous-ensemble de Java (1.0.2, sic!) dédié pour la carte à puce : ½ Sous-ensemble du langage de programmation Java ½ Sous-ensemble du paquetage java.lang ½ Découpage de la machine virtuelle Java ½ Modèle mémoire adapté à la carte ½ APIs spécifiques à la carte 32 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Statut du standard Java Card (1/2) ? 10/96 : Spécification Java Card 1.0 u Poussée par Schlumberger (produit CyberFlex) u Très limitée (4 pages) et proche de la carte ? 02/97 : Création du «Java Card Forum» u Regroupe les fabricants de cartes et Sun pour établir les spécifications + des utilisateurs pour promouvoir Java Card ? 10/97 : Spécification Java Card 2.0 u Sous-ensemble du langage et de la machine virtuelle Java u Concepts de programmation et APIs ? 03/99 : Spécification Java Card 2.1 u Modifications API (crypto, exceptions), normalisation BC... 33 Statut du standard Java Card (2/2) ? Licenciés Bull, Dallas Semiconductor, De La Rue, Gemplus, Giesecke & Devrient, Inside Technologies, Keycorp, Lucent, Motorola, NatWest, Oberthur, Schlumberger, Toshiba, TL Technologies, ... ? Produits u Schlumberger : CyberFlex Open 16K (JC 2.0) u Gemplus : GemXpresso RAD 1.0 (JC 2.0) u Bull SA : Odyssey (JC 2.0) u Giesecke & Devrient : C@ppucino (JC 2.0) u Dallas Semiconductor : iButton (bague Java!) 34 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Sous-ensemble du langage Java ? Pourquoi un sous-ensemble ? u Limitationscarte : puissance de calcul, tailles des mémoires ½ JVM doit pouvoir s?exécuter sur composant 8 bits avec 512 octets RAM, 16 Ko EEPROM, et 24 Ko ROM u Contexte applicatif carte : petites applications de type serveur ? Définition d?une application Java Card u Applets Java Card (javacard.framework.Applet) u À la différence du JDK, pas de notions : ½ d?applets : java.applet.Applet ½ d?applications : public static void main( String[] args ) 35 Java Card par rapport à Java (1/4) ? Pas de chargement dynamique de classes u Classes de base présentes dans la carte (avec le masque) u Nouvelles classes chargées dans la carte ne doivent référencer que des classes «connues» ? Objets u Instances de classes ou de tableaux à une dimension u Allocation dynamique d?objets supportée (new) u Pas de clonage d?objets (méthode equals() supportée) ? Pas de ramasse-miettes (gc) u Pas de désallocation explicite non plus ==> mémoire allouée peut ne pas être récupérée u Pas de méthode finalize() 36 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Java Card par rapport à Java (2/4) ? Types de base (nombres signés, complément à 2) : byte, short, boolean (8 bits), int (optionnel) u En l?absence du type int, les calculs intermédiaires ou non assignés doivent toujours être «castés» en byte ou short u Pas de types char (pas de classe String), double, float et long u Pas de modifieur transient u Pas de classes Boolean, Byte, Class, etc. ? Tableaux à une dimension avec élements : u Types de base u Objets (les tableaux sont eux-mêmes des objets) 37 Java Card par rapport à Java (3/4) ? Pas de threads u Pas de classe Thread, pas de mots-clés synchronized ni volatile ? Mécanisme d?héritage identique à Java u Surcharge de méthodes, méthodes abstraites et interfaces u Invocation de méthodes virtuelles u Mots-clés instanceof, super et this ? Sécurité u Notion de paquetage et modifieurs public, protected et private identiques à Java u Pas de classe SecurityManager : politique de sécurité implémentée dans la machine virtuelle 38 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Java Card par rapport à Java (4/4) ? Mécanisme d?exceptions supporté u Peuvent être définies (extends Throwable), propagées (throw) et interceptées (catch) u Classes Throwable, Exception et Error supportées et certaines de leurs sous-classes (dans java.lang) ? Méthodes natives (native) u Supportées pour les classes de base (masquées) u Optionnelles pour les nouvelles classes chargées ? Atomicité u Miseà jour de champs d?objets doit être atomique u Modèle transactionnel : beginTransaction(), commitTransaction() et abortTransaction() 39 Résumé Java Card p/r à Java (1/2) ? Supportés: ? Non supportés : u boolean, byte, short, int u float, double, long u Object u char, String u Tableau à une dimension u Tableau à n dimensions u Méthodes virtuelles u Class et ClassLoader u Allocation dynamique u Ramasse-miettes u Paquetages u SecurityManager u Exceptions u Threads u Interface u Méthodes natives 40 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Résumé Java Card p/r à Java (2/2) ? Mots-clés non disponibles : char, double, float, long, synchronized, transient, volatile ? API java.lang de Java Card réduite à : u Object { public Object(); public boolean equals(Object obj); } u Throwable { public Throwable(); } -- Exception -- RuntimeException -- ArithmeticException -- ClassCastException -- NullPointerException -- SecurityException -- ArrayStoreException -- NegativeArraySizeException -- IndexOutOfBoundsException -- ArrayIndexOutOfBoundsException 41 Machine virtuelle JC : partie carte ? Définition de la machine virtuelle Java u Vérifieur de Bytecode u Chargeur dynamique de classes u Interpréteur de Bytecode ? Dans la carte, la JCVM n?implémente que : u Interpréteur de byte-code } u Gestion des classes et objets u Isolation des applets ½ Par paquetage 42 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Machine virtuelle JC : découpage ? Pourquoi la JCVM ne contient pas le vérifieur ? u Trop lourd pour être stocké et/ou exécuté dans la carte ? Pourquoi la JCVM ne contient pas le chargement dynamique de classes ? u Pas d?accès à l?endroit où sont stockés les fichiers de classes depuis la carte u Pas de vérifieur dans la carte permettant de vérifier dynamiquement la validité d?une classe chargée ? Architecture JCVM p/r à la JVM u «Identique» mais découpée en une partie dans la carte et une partie hors carte («Java Card Converter») 43 Machine virtuelle JC : architecture 44 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Machine Virtuelle JC : partie hors-carte ? Vérifieur de Bytecode u Utilise le vérifieur de Bytecode Java «classique» u Contrôle le sous-ensemble Java Card (langage + API) ? Convertisseur («early binding») u Préparation : initialise les structures de données de la JCVM u Optimisation : ajuste l?espace mémoire, remplace certains InvokeVirtual par des InvokeStatic, etc. u Édition de liens : résout les références symboliques à des classes déjà présentes dans la carte (via «image» de la carte) ? Signeur u Valide le passage par le vérifieur et le convertisseur par une signature vérifiée par la carte au moment du chargement 45 Modèle mémoire Java Card ? La JCVM est toujours active même quand la carte est déconnectée u Elle est automatiquement remise en route à la (re-)connexion ? Les objets sont stockés de manière persistente u Stockage en EEPROM sans ramasse-miettes u Attention ! aux clauses throw new Exception(); ½ Créer l'objet une fois (patron "singleton"), utiliser des méthodes statiques Exception.throwIt(...); ½ Détruire les objets locaux non assignés en fin d'exécution ? L?objet applet u Créé une seule fois (avec un identifiant AID unique) u Toujours une applet active par défaut 46 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Comprendre Java Card : sommaire ? Les concepts u Qu?est-ce que Java Card ? u Statut du standard Java Card u Sous-ensemble du langage Java u La machine virtuelle u Le modèle mémoire ? La pratique u Concepts de programmation u Les APIs de programmation u Développement d'une applet Java Card (+ exemples) u Construire une application avec la Java Card 47 Concepts de programmation (1/2) ? Approche traditionnelle Terminal Commandes Applications clientes Masque carte (APDUs) Données carte Réponses u Masque carte traite les APDUs de commande u Masque carte lit/écrit/met à jour les données carte u Application cliente envoie des APDUs de commande 48 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Concepts de programmation (2/2) ? Approche Java Card Terminal Commandes JCRE (masque) Applications clientes (APDUs) API Java Card Applets Carte Réponses u Environnement d'exécution Java Card (JCRE) = support de l'exécution d'applets carte grâce à l'API Java Card u Applets carte traitent des APDUs de commande u Application cliente envoie des APDUs de commande 49 Les APIs de programmation Java Card ? Paquetage javacard.framework u Principale API pour programmer une applet carte u Définit les classes : ½ AID, APDU, Applet, ISO, PIN, JCSystem, Util ½ Plus des classes d'exceptions ? Extensions u javacardx.framework : gestion de fichiers conforme à la norme ISO 7816-4 u javacardx.crypto : gestion de clés publiques et privées, générateur de nombres aléatoires, fonction de chiffrement et de hashage... 50 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Les APIs utilitaires de javacard.framework (1/2) ? public final class JCSystem u Méthodes statiques (natives) pour interagir avec le JCRE ½ Gestion des transactions (1 seul niveau) ½ Gestion du partage d'objets entre applets ? public class Util u Méthodes statiques (natives) utiles pour performance carte ½ Copie, comparaison de tableaux de bytes ½ Création de short à partir de byte ? public final class AID u Encapsule des identifiants d'applications carte conformes à la norme ISO 7816-5 51 Les API utilitaires de javacard.framework (2/2) ? public class ISO u Champs statiques de constantes conformes aux normes ISO 7816-3 et 4 u ISOException.throwIt(short reason) ½ Renvoie la «raison» ? public abstract class PIN u Représentation d'un code secret (tableau d?octets) ½ OwnerPIN : code secret pouvant être mis à jour 52 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Applet carte ? Une applet carte est un programme serveur de la Java Card u APDU de sélection depuis le terminal u Sélection par AID (chaque applet doit avoir un AID unique) ? Une fois installée dans la carte, est toujours disponible ? Classe qui hérite de javacard.framework.Applet ? Doit implémenter les méthodes qui interagissent avec le JCRE : u install(), select(), deselect(), et process() 53 Méthodes publiques d'une applet ? Public static void install( APDU apdu ) u Appelée (une fois) par le JCRE quand l'applet est chargée dans la carte u Doit s?enregistrer auprès du JCRE (méthode register()) ? public boolean select() u Appelée par le JCRE quand un APDU de sélection est reçu et désigne cette applet u Rend l'applet active ? public void process( APDU apdu ) u Appelée par le JCRE quand un APDU de commande est reçu pour cette applet (doit être active) ? public void deselect() u Appelée par le JCRE pour désélectionner l'applet courante 54 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Gestion des APDUs par une applet (1/2) ? L'unité de traitement de base d'une applet est un objet de type javacard.framework.APDU u Transmis par le JCRE à la réception d'un APDU de commande par la carte ½ Appel à la méthode process() de l'applet courante ? Classe javacard.framework.APDU u Compatible avec le format de messages ISO 7816-4 u Cache les caractéristiques des protocoles de communication bas niveau (T=0 ou T=1) u Encapsule les échanges de messages APDUs (commandes et réponses) dans un buffer d'entrées/sorties 55 Gestion des APDUs par une applet (2/2) ? Lecture/écriture dans le buffer d'APDU 56 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Résumé des caractéristiques du JCRE ? Classes de l?API Java Card ? Machine virtuelle Java Card u Interpréteurde Bytecode u Gestion des classes et des objets ? Gestion des applets u Installation,enregistrement et initialisation u Sélection et désélection u Transmission des APDUs u Récupération des exceptions ? Méthodes natives u Entrées/sorties, transactions, cryptographie 57 Conception d?une applet Java Card ? Rôle d'une applet u Maintenir son propre état : gestion des champs de l'applet, créer des objets et les référencer pour travailler u Répondre à des APDUs de commande (méthode process()) et retourner des APDUs de réponse ? Conception u Créer les objets de base à l'installation, initialiser les champs ½ Implémentation de la méthode install() u Définir les APDUs traités par la méthode process() ½ Implémentation d'un analyseur de commandes ½ Utilisation des champs et objets de l'applet u Définir les traitements à la sélection et à la désélection 58 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Exemple «Compteur» : Conception ? État de l'applet : u Maintient une valeur entière positive ou nulle (pas d'objets) ? Installation : création de l'objet Applet u Initialisation de la valeur du compteur u Enregistrement auprès du JCRE ? Opérations : u Lecture: retourne la valeur du compteur u Incrémentation/décrémentation : ajoute/soustrait un montant au compteur et retourne la nouvelle valeur du compteur ? Sélection et désélection : u Aucun traitement 59 Exemple «Compteur» : APDUs ? Rappels : ? APDUs traités par l'applet : u int lire() ½ Commande : AA 01 XX XX 00 04 ½ Réponse : RV3 RV2 RV1 RV0 90 00 u int incrementer( int ) ½ Commande : AA 02 XX XX 04 AM3 AM2 AM1 AM0 04 ½ Réponse: RV3 RV2 RV1 RV0 90 00 u int decrementer( int ) : idem mais INS=03 60 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Applet «Compteur» : Classe Applet package compteur.carte.gemplus.fr ; import javacard.framework.* ; public class Compteur extends Applet { private int valeur; public Compteur() { valeur = 0; register(); } public static void install( APDU apdu ) { new Compteur(); } public void process( APDU apdu ) { byte[] buffer = apdu.getBuffer(); if ( buffer[ISO.OFFSET_CLA] != 0xAA ) ISOException.throwIt(ISO.SW_CLA_NOT_SUPPORTED); switch ( buffer[ISO.OFFSET_INS] ) { case 0x01: ... // Opération de lecture case 0x02: ... // Opération d'incrémentation case 0x03: ... // Opération de décrémentation default: ISOException.throwIt(ISO.SW_INS_NOT_SUPPORTED); } } } 61 Applet «Compteur» : décrémentation case 0x03: // Opération de décrémentation { // Réception des donnnées byte octetsLus = apdu.setIncomingAndReceive(); if ( octetsLus != 4 ) ISOException.throwIt(ISO.SW_WRONG_LENGTH); int montant = (buffer[ISO.OFFSET_CDATA]<<24) | (buffer[ISO.OFFSET_CDATA+1]<<16) | (buffer[ISO.OFFSET_CDATA+2]<<8) | buffer[ISO.OFFSET_CDATA+3]; // Traitement if ( montant<0 || valeur-montant<0 ) ISOException.throwIt((short)0x6910); valeur = valeur - montant; // Envoie de la réponse buffer[0] = (byte)(valeur>>24); buffer[1] = (byte)(valeur>>16); buffer[2] = (byte)(valeur>>8); buffer[3] = (byte)(valeur); apdu.setOutgoingAndSend((short)0, (short)4); return; } 62 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Exemple 2 (1/4) package banque.com ; import javacard.framework.*; public class Pme extends Applet { final static byte Pme_CLA = (byte)0xB0; final static byte Crediter_INS = (byte)0x10; final static byte Debiter_INS = (byte)0x20; final static byte Lire_INS = (byte)0x30; final static byte Valider_INS = (byte)0x40; final static byte MaxEssai_PIN = (byte)0x03; final static byte MaxLg_PIN = (byte)0x08; final static short BalanceNegative_SW = (short)0x6910; OwnerPin pin; byte balance; byte[] buffer; private Pme( byte[] valeurPin ) { pin = new OwnerPIN(MaxEssai_PIN, MaxLg_PIN); balance = 0; register() ; } 63 Exemple 2 (2/4) public static void install( APDU apdu ) { new Pme(); buffer = apdu.getBuffer(); byte octetsLus = (byte)apdu.setIncomingAndReceive(); if ( octetsLus <= MaxLg_PIN ) pin.updateAndUnblock(buffer, ISO.OFFSET_CDATA , octetsLus); } public boolean select() { pin.reset(); return true; } public void process( APDU apdu ) { buffer = apdu.getBuffer(); if ( buffer[ISO.OFFSET_CLA] != Pme_CLA ) ISOException.throwIt(ISO.SW_CLA_NOT_SUPPORTED); switch ( buffer[ISO.OFFSET_INS] ) { case Crediter_INS : crediter(apdu); return; case Debiter_INS : debiter(apdu); return; case Lire_INS : lire(apdu); return; case Valider_INS : valider(apdu); return; default: ISOEXception.throwIt(ISO.SW_INS_NOT_SUPPORTED); } } 64 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Exemple 2 (3/4) // Réception de données private void crediter( APDU apdu ) { if ( !pin.isValidated() ) ISOException.throwIt(ISO.SW_PIN_RIQUIRED); byte octetsLus = apdu.setIncomingAndReceive(); if ( octetsLus != 1 ) ISOException.throwIt(ISO.SW_WRONG_LENGTH); balance = (byte)(balance + buffer[ISO.OFFSET_CDATA]); } // Réception de données private void debiter( APDU apdu ) { if ( !pin.isValidated() ) ISOException.throwIt(ISO.SW_PIN_RIQUIRED); byte octetsLus = apdu.setIncomingAndReceive(); if ( octetsLus != 1 ) ISOException.throwIt(ISO.SW_WRONG_LENGTH); if ( (balance - buffer[ISO.OFFSET_CDATA]) < 0 ) ISOException.throwIt(BalanceNegative_SW); balance = (byte)(balance - buffer[ISO.OFFSET_CDATA]); } 65 Exemple 2 (4/4) // Émission de données private void lire( APDU apdu ) { if ( !pin.isValidated() ) ISOException.throwIt(ISO.SW_PIN_RIQUIRED); apdu.setOutgoing(); apdu.setOutgoingLength((byte)1); buffer[0] = balance; apdu.sendBytes((short)0, (short)1) ; } // Manipulation du code secret private void valider( APDU apdu ) { byte octetsLus = apdu.setIncomingAndReceive(); pin.check(buffer, ISO.OFFSET_CDATA, octetsLus); } } 66 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Construction d?applications Java Card ? Une application carte = u Code dans la carte (application serveur = applet Java Card) u Code dans le terminal (application cliente) ? Construction d?une application Java Card u Construction de l?application serveur (applet) ½ Implémentation de services u Installation de l?applet dans les cartes ½ Initialisation de services u Construction de l?application cliente ½ Invocation de services 67 Construction de l?application serveur ? Construction de l?applet Java Card u Implémentation des classes de l?applet avec l?API Java Card u Définition des APDUs de commande traités par l?applet et des APDUs de réponse renvoyés par l?applet (données ou erreurs) : implémentation de la méthode process() u Le JCRE fournit l?environnement d?exécution et la couche de communication ? Installation de l?applet Java Card u Compilation, conversion et chargement sécurisé de l?applet dans les cartes (Java Card IDE) u Appel à la méthode install() des applets (non standardisé) 68 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Construction de l?application cliente (1/2) ? Construction de l?application terminal u Implémentation des classes du terminal (avec JDK) u Communication avec le serveur (applet carte) ½ Établissement de la liaison : envoi d?un APDU de sélection avec l?AID de l?applet (standardisé) ½ Invocation de services de l?applet : ? codage et envoi d?APDUs de commande conformes à ceux traités par l?applet ? réception et décodage des APDUs de réponse retournés par l?applet u Pas d?API standard de communication avec la carte 69 Construction de l?application cliente (2/2) 70 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 API de communication avec la carte ? Open Card Framework (OCF) : API Java u opencard.core.terminal : abstractions pour les lecteurs, les modes de communication, les connexions/déconnexions avec la carte u opencard.core.service : «framework» pour la définition de services carte ? Existant u PC/SC : API C/C++ Microsoft pour accéder aux cartes sur les plates-formes Windows 32 bits (98 et NT4 et 5) u API Cliente du Gemplus SDK ½ Tout lecteur Gemplus ½ Java VM (JDK 1.1 ou MS 2.0) sous Windows et Solaris 71 API Cliente du Gemplus SDK ? Paquetage com.gemplus.gcr u Classe Ifd (Interface Device) ½ Représente le lecteur ½ Gère canaux de communication avec le lecteur ½ Sous-classe pour chaque mode de communication u Classe Icc (Integrated Circuit Card) ½ Représente la carte ½ Gère la connexion à la carte ½ Gère l?échange d?APDUs avec la carte par la méthode : ApduResponse exchangeApdu(ApduCommand command) throws GcrException u Classe GcrException (et sous-classes) pour les erreurs de communication 72 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Client «Compteur» : liaison carte package compteur.client.gemplus.fr ; import com.gemplus.gcr.* ; /* Application terminal */ Ifd lecteur = new IfdSerial(IFDTYPE.GCR410, SERIALPORT.G_COM1, 9600); Icc carte = new Icc() ; try { // Connexion à la carte via lecteur GCR410 short canal = reader.openChannel(); SessionParameters atr = carte.openSession(canal); // Échange d?APDUs (APDU de selection de l?applet Compteur) ApduCommand commande = new ApduCommand( /* paramètres */ ); ApduResponse reponse = carte.exchangeApdu(commande); /* etc */ // Fin de la connexion carte.closeSession(); lecteur.closeChannel(canal); } catch ( GcrException e ) { // Récupération de l?erreur System.out.println(??Problème : ?? + e.getMessage()); } 73 Client «Compteur» : décrémentation // Commande = AA 03 XX XX 04 AM3 AM2 AM1 AM0 04 // Reponse = RV3 RV2 RV1 RV0 90 00 ou 69 10 int montant = System.in.read(); byte[] montantApdu = new byte[4]; montantApdu[0] = (byte)(montant >> 24); montantApdu[1] = (byte)(montant >> 16); montantApdu[2] = (byte)(montant >> 8); montantApdu[3] = (byte)(montant); ApduCommand commande = new ApduCommand(0xAA, 0x03, 0, 0, montantApdu, 4); ApduResponse reponse = carte.exchangeApdu(commande); if ( reponse.getShortStatus() == 0x9000 ) { byte[] apduValeur = reponse.getDataOut(); int valeur = (apduValeur[0]<<24) | (apduValeur[1] <<16) | (apduValeur[2]<<8) | apduValeur[3]; System.out.println(??Valeur compteur : ?? + valeur); } else { if ( reponse.getShortStatus() == 0x6910 ) { /* Traite l?erreur «Valeur négative» */ } } 74 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Conclusion Java Card ? Méthodologie de développement d?applets cartes u Basée sur Java pour programmer la carte u Basée sur APDUs pour communication client-applet ? Points positifs u Carte ouverte u Langage Java u API standard ? Nouveautés arrivent... 75 Nouveautés Java Card 2.1, VOP 2.0, OCF 1.1 et Systèmes concurrents J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Java Card 2.1 : Généralités ? Nouvelle norme Java Card u Format des fichiers de chargement d?applet carte : .cap u Nouveaux modèles : objets temporaires, partage d?objets, etc. u Modification des spécifications de l?API ? Agenda u Sortie en février 99 u Implémentation de référence le 31 mars 1999 ½ API + simulateur pour JVM classique (crypto, transactions, etc.) ½ Convertisseur ??? ½ Machine virtuelle Java Card ??? 77 J C 2.1 : Format de fichier .cap (1/3) ? Format normalisé !!! u Pluspour l?interopérabilité u Mais manque la façon de le charger !!! ? Fichier .cap identique à .class sauf : u 1seul fichier .cap par paquetage Java u Pas d?informations textuelles ½ Utilisation d?identifiants numériques ½ Correspondance texte-numéros dans un fichier externe u Taille par défaut d?un élément = 16 bits (au lieu de 32 bits) u Fichier organisé en 11 composants (11 fichiers .cap) ½ 10obligatoires + 1 optionnel ½ Possibilité d?ajouter des composants optionnels (à part) 78 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 J C 2.1 : Format de fichier .cap (2/3) <1:header> « magic » + numéros de version <2:directory> liste des autres composants avec taille <3:applet> liste des applets avec leur AID et un pointeur vers leur méthode install() <4:refedpackages> liste des paquetages référencés dans ce paquetage (paquetages devant donc être présents dans la carte avant de charger celui-ci) <5:constantpool> table des références aux classes, méthodes et champs dans le code des méthodes <6:class> table des classes et interfaces <7:method> code des méthodes des classes 79 J C 2.1 : Format de fichier .cap (3/3) <8:staticfield> valeurs initiales de tous les champs statiques du paquetage <9:reflocations> liste des références relatives dans le code des méthodes à transformer au chargement dans la carte en références absolues <10:export> liste des éléments de ce paquetage que les autres paquetages peuvent référencer directement (méthodes et champs statiques public ou protected dans classes publiques) <11:descriptor> information de typage (signatures) si ce paquetage est accessible par d?autres paquetages 80 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 J C 2.1 : Nouveaux modèles (1/2) ? Objets temporaires: méthode System.makeTransient( Object... ) remplacée par JCSystem.makeTransient{Boolean, Byte, Short, Object}Array() ? « Firewall » entre applets u L?implantation de la VM doit vérifier à l?exécution que le code d?une applet ne sort jamais de son contexte (1 contexte par applet et un contexte actif à la fois) u Mécanismes de changement de contexte ½ Objets points d?entrée et tableaux globaux du JCRE peuvent être accédés par les applets (e.g., APDU) ½ Le JCRE peut accéder à n?importe quel objet ½ Interactions entre applets via interfaces partageables Suppresion de la méthode System.share( Object ... ) 81 J C 2.1 : Nouveaux modèles (2/2) ? Interfaces partageables Applet A JCRE Applet B interface Sharable getAppletSIO( A, param) getSIO( B, param ) extends O/N? x cast en Sharable cast en Xi Xi implements X x.foo() changement de contexte x.foo() getPreviousContextAID() B réponse changement de contexte 82 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 J C 2.1 : Autres principales nouveautés ? Applet.install( APDU apdu ) remplacé par Applet.install( byte[] b ) ? Exceptions dans java.lang sont dans un strict sous- ensemble des exceptions standards de java.lang ? Une applet peut être instanciée plusieurs fois en s?enregistrant à chaque fois avec un AID différent : méthode Applet.register( byte[], short, short ) ? Classe AID plus générale avec constructeur et méthode equals() ? Paquetage javacardx.framework (fichiers 7816-4) retiré ? Paquetages cryptographiques restructurés (export) 83 J C 2.1 : Conclusion ? Évolution intéressante par rapport à 2.0 ? Mais peut mieux faire... u Fichier de chargement défini mais pas la façon dont on le charge ==> l?interopérabilité de J C 2.1 s?arrête juste avant la carte... (convertisseur OK, chargeur = ???) u Modèle des objets temporaires encore insatisfaisant (lourd) u Firewall, changement de contexte et interfaces partageables sont ½ lourds (possibilité de contournement ==> beaucoup de vérification à la main) ½ couteux (sauvegarde de contexte, vérification à l?exécution) 84 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 VOP 2.0 : Visa Open Platform ? Historique u VOP 1.0 (Août 1998) ½ API Java complémentaire de J C 2.0 pour la gestion du cycle de vie des applets ½ Définition de commandes APDUs pour l?initialisation et la personnalisation des cartes / des applications u VOP 2.0 (Mi-99) ½ Architecture de sécurité pour carte multi-applicative (Java ou non) ½ Définit quand et comment (i.e., avec quel niveau de sécurité) initialiser, personnaliser une carte à l?émission ou ajouter, initialiser et personnaliser une nouvelle application dans une carte émise 85 VOP 2.0 : Architecture ? Niveaux de sécurité Card Domain Card Issuer Security Security Security Security Applets Domain Domain Domain Domain Provider Applet Applet Applet Applet Applet Applet ? Cycle de vie des applications ? Mécanismes cryptographiques 86 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 VOP 2.0 : Conclusion ? Objectifs u Passage à des cartes ouvertes sur infrastructure existante u Gestion des niveaux de sécurité u Gestion du cycle de vie des applications carte u Définition de mécanismes de sécurité pour (télé-)chargement d?applications ? Commentaires u Standard propriétaire mais seul existant u Complémentaire à Java Card pour la sécurité du déploiement u Pas une solution pour l?interopérabilité du déploiement 87 OCF 1.1 : Open Card Framework ? Première version stable de la norme OCF (oct. 98) ? Framework standard d?accès à des cartes et des lecteurs depuis un environnement Java ? Drivers doivent être implémenter et intégrer dans le framework par chaque fabricant u Accessible depuis la classe CardTerminal u Plusieurs possibilités ½ Driver natif accessible depuis JNI ½ Driver PC/SC ½ Driver Java utilisant l?API javax.comm ? Chaque carte est représentée par une classe CardService 88 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 OCF 1.1 : Architecture 89 OCF 1.1 : Conclusion ? Objectifs u Tenter de définir un consensus pour une API d?accès aux lecteurs et aux cartes régi par un consortium autour d?IBM u Approche orientée objet : extensibilité, réutilisabilité, etc. ? Commentaires u Standard ouvert qui commence à susciter de l?intérêt (vs PC/SC) u Complémentaire à Java Card pour le développement des applications clientes u Problème d?adaptation aux petits environnements (e.g., terminaux de paiement) 90 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Conclusion ? Intérêts grandissant autour de Java et carte u Java Card 2.0 et 2.1, VOP 1.0 et 2.0, OCF 1.0 et 1.1 u Volonté d?affronter tous les aspects des applications cartes ½ Manque encore de l?interopérabilité ½ Processus de fabrication, diffusion et maintenance pas encore maitrisés ? Premières réelles applications pour l ?an 2000 ? ? Attention à la concurrence : u MultOS : Consortium autour de Master Card pour système d?exploitation carte multi-applicatif u Windows Smart Card : Windows CE pour développer des applications carte dans le monde Windows 91 Discussion : les problèmes des développeurs Les limites de Java Card J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Deux types de problèmes ? Portabilité des applications u Une applet Java Card peut-elle s?exécuter sur toutes les Java Cards du marché ? u Une application cliente Java Card peut-elle s?exécuter avec différents matériels ? u Besoins : ½ Diversification des sources cartes et des terminaux ½ Pérennité des développements ? Procédé de construction des applications u Permettre le développement «rapide» d?applications carte «évoluées» par des «non spécialistes» u But : de nouvelles applications pour de nouveaux marchés ! 93 Résumé construction d?applications (1/2) ? Développement de l?applet carte u Utilisationde l?API Java Card ½ Essentiellement pour traiter des APDUs u Conversion et installation dans la carte ½ Format du Bytecode défini mais procédure d?installation dans la carte non défini ½ Portabilité des applets s?arrête au chargement u Exécution par le JCRE ½ Sélection d?applet défini par Java Card ½ Réception et transmission d?APDUs par l?applet définies par Java Card 94 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Résumé construction d?applications (2/2) ? Développement de l?application cliente u Utilisation d?une API de communication carte permettant de transporter des APDUs ½ Bientôt une API Java standard (OCF) u Sélection de l?applet par son AID ½ Commande définie par Java Card u Échanges d?APDUs avec l?applet carte ½ Codage d?APDUs de commande et décodage d?APDUs de réponse conformes aux APDUs traités par l?applet 95 Deux types de problèmes (suite et fin) ? Portabilité des applications u Conversion et installation des applets sont définies par Java Card 2.1, mais nombreuses options encore possibles u OCF définit une API Java d?accès aux cartes, mais fournisseurs doivent la supporter ? Procédé de construction des applications u Client et applet communiquent par APDUs ½ Structure de données pauvre (tableau d?octets), peu explicite (pas de typage), et difficile à manipuler ½ Oblige à définir le contenu et la sémantique des messages échangés : décodage et encodage d?APDUs par le client et l?applet 96 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Problèmes pour la construction ? La spécification des échanges entre client et applet correspond à un protocole u Le format des messages APDUs échangés est utilisé comme spécification commune u Travail sur un protocole plutôt que sur des fonctionnalités u Nécessite une formation carte ? L?applet et le client implémentent un protocole u Code «dupliqué» dans les programmes clients et applets ½ Dans la carte : toutes les applets décodent des APDUs u Code «sensible» ½ Difficile à programmer : prévoir tous les cas, pas d?outils ½ Source d?erreurs 97 Les techniques des applications réparties appliquées à la carte Construire les applications carte mieux et plus facilement J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Applications réparties carte : sommaire ? Les concepts u Approche client-serveur, objets répartis et carte ½ Les RPC u Invocation de méthodes dans la carte ½ Protocole DMI u Mise en ?uvre dans GemXpresso ? La pratique u Concepts de programmation u Développement d'une applet (+ exemple) u Construire une application avec GemXpresso 99 Rappel ? Approche Java Card Terminal Commandes JCRE (masque) Applications clientes (APDUs) API Java Card Applets Carte Réponses u Environnement d'exécution Java Card (JCRE) = support de l'exécution d'applets carte grâce à l'API Java Card u Applets carte traitent des APDUs de commande u Application cliente envoie des APDUs de commande 100 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Modèle client-serveur de Java Card ? Codage/décodage des messages à un niveau proche du protocole de communication (APDUs)... 101 Client-serveur et Remote Procedure Call ? Définition de RPC u Introduit dans les applications réparties pour porter l?échange de messages entre un client et un serveur au niveau de l?appel de procédures ½ Message de requête = appel de procédure par le client ½ Message de réponse = valeur de retour de la procédure exécutée par le serveur u Protocole d'appel de procédures sur machine distante indépendant de la couche de communication ½ Définit comment «nommer» une procédure distante ½ Définit comment sont codés les paramètres et les valeurs de retour dans un format «neutre» 102 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Architecture RPC 103 Construction d?applications avec RPC ? Définir les interactions entre clients et serveurs u Liste des procédures serveurs «appelables» depuis un client via RPC = interfaces (contractuelles) des services ? Produire les souches clientes et serveurs u Emballage et déballage des messages RPC u Autant de souches différentes que de machines cibles ? Développer les applications clientes et serveurs u Utilisation des souches clientes pour utiliser les services comme des services locaux u Utilisation des souches serveurs pour implémenter les appels aux services comme des appels locaux u Utilisation des bibliothèques RPC pour liaison client-serveur et transmission/réception des messages RPC 104 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 RPC et systèmes à objets répartis ? Principes u Utilisation de la notion d'interfaces objet pour décrire les objets distants u Pré-compilateur pour générer les souches (proxys et squelettes) u Protocole d'invocation de méthodes ? Mises en ?uvre u CORBA ½ InterfacesIDL, projections dans langages cibles, protocoles ORB et inter-ORB u Java ½ Interfaces Java, rmic, protocole RMI dans JVM 105 RPC et carte : approche ? Construire les applications avec la carte comme des applications réparties à objets u Applet Java Card = objet serveur distant u Client invoque des méthodes de l'applet Terminal Invocation de Applications clientes méthodes JCRE (masque) Interfaces API Java Card (APDUs) Proxys d?applets Interfaces Applets Carte Réponses 106 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 RPC et carte : mécanismes ? Invocation de méthodes de l'applet carte prises en charge par un protocole «à la» RPC : Direct Method Invocation (DMI) u APDUs de commande et réponse pour la sélection d'applet u APDUs de commande et réponse pour l'invocation de méthodes ? Génération des souches cliente et serveur pour l'emballage et le déballage des messages DMI u Proxy pour le client (Card Applet Bridge) u Description d?interface pour le JCRE ? Description des interfaces d'applets u Interface Java avec restrictions 107 RPC et carte : architecture 108 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Protocole DMI : généralités ? Protocole applicatif d?échange de messages pour : u La sélection de services carte (select()) u L?invocation de méthodes du service sélectionné (invoke()) ? Les messages-réponses DMI sont spécifiés par des APDUs de commande et de réponse u Compatibilité avec format de messages ISO 7816-4 ½ Peuvent être transportés par les APIs lecteur u Nécessite l?interprétation de ces commandes par le masque de la carte (JCRE) ½ Commandes non standard mais pourraient l?être... ½ Pas interdit par Java Card ? Non limité à Java Card 109 Protocole DMI : select (1/2) ? Sélection d?une applet Java Card par son AID u CompatibilitéISO 7816-5 et Java Card u AID sur 16 octets ? Message u CLA INS P1 P2 Lc DataIn Le A8 A4 04 XX 10 «applet AID» 00 ? Interprétation u Si l?applet existe (AID référencé dans la carte) et accepte d?être sélectionnée (méthode Applet.select() renvoie true), alors les prochains APDUs de commande seront destinés à cette applet (l?applet courante est désélectionnée) u Sinon, l?applet courante reste active 110 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Protocole DMI : select (2/2) ? Réponse u Pas de données renvoyées u 90 00 si la sélection a réussi u Sinon, code d?erreurs ½ 6A 82 : applet non trouvé ½ 6F A0 : exception/erreur renvoyée par la JCVM 111 Protocole DMI : invoke (1/2) ? Invocation d?une méthode d?applet Java Card avec la signature de la méthode et ses paramètres u Identifiantde méthode (numéro de 01 à 7F) u Types et valeurs des arguments ½ Chaque type a un identifiant (signature) ½ Les paramètres sont passés par valeurs u Type de la valeur de retour ? Message u CLA INS P1 P2 Lc DataIn Le A8 36 #meth TypeRet ?? Valeur params 00 112 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Protocole DMI : invoke (2/2) ? Interprétation u Si la méthode existe dans l?applet courante, alors elle est exécutée avec les paramètres fournis et le résultat de l?exécution (valeur de retour ou exception) est retournée u Sinon, un code d?erreur est retournée ? Réponse u DataOut SW1 SW2 Valeur Retour ou Exception 90 00 u Sinon, code d?erreurs ½ 6F 00 : méthode inconnue ½ 61 03 : erreur renvoyée par la JCVM en cours d?exécution 113 Mise en ?uvre dans GemXpresso (1/2) ? GemXpresso u Implémentation de Java Card 2.0 (32 bits, 8/512/32) u Ajout du mécanisme DMI ? Applet Java Card doit aussi implémenter une interface u class MonApplet extends Applet implements MonInterface u Types transportés par DMI (acceptés dans les interfaces Java d?applets) ½ (void), byte, boolean, short, et int ½ Tableaux à une dimension des types de base ½ Exceptions définies par les spécifications Java Card 114 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Mise en ?uvre dans GemXpresso (2/2) ? Génération de proxies clients u Dans les langages Java/C++/C/VisualBasic u Utilise l?API cliente du Gemplus SDK (Java) ou l?API 4 de Gemplus (C++/C/VB) u A été étendue aux APIs OCF (Java) et PC/SC (C++/C/VB) ? Souches serveurs u Gérées directement par le JCRE de la carte GemXpresso u Fourniture à l?installation de l?applet de la carte de la description de l?interface au JCRE ½ «Dépôt d?interfaces» dans la carte ½ Vérification et décodage des messages invoke de DMI 115 Architecture GemXpresso interface description d?interface proxy client dépôt d?interfaces DMI 116 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Autres caractéristiques GemXpresso (1/3) ? En plus par rapport à Java Card 2.0 u Type int et mot-clé transient u Destruction des objets locaux non assignés u Politique de sécurité : paquetage public ou privé u Exceptions Java Card 2.1 ? En moins par rapport à Java Card 2.0 u Pas de gestion des transactions u Partage d?objets non implémenté car a été complétement revu dans Java Card 2.1 u Chargement sécurisé par un mot de passe u Algorithmes cryptographiques non implémentés pour des raisons d?export 117 Autres caractéristiques GemXpresso (2/3) ? APIs com.gemplus.gemxpresso.library u Interface IApplet avec méthodes de javacard.framework.Applet ½ interface MonInterface extends IApplet u Notification : Observer et Observable u Streams : CardByteArrayInputStream et CardByteArrayOutputStream u Arithmetique : Byte, Short, Int avec uniquement MIN_VALUE, MAX_VALUE u Mathématique : Math avec uniquement abs, min et max u Manipulation de champs de bits : BitSet u Utilitaire : Util32 pour construire des int depuis des byte 118 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Autres caractéristiques GemXpresso (3/3) ? Spécifités DMI u Invocation du clinit des classes au chargement d?un paquetage ½ Numéro de méthode 00 pour le invoke de DMI ½ Pas de paramètres u Invocation du constructeur de l?applet au chargement ==> Une applet peut avoir plusieurs constructeurs ½ Numéro de méthode FE à 80 pour le invoke de DMI ½ Paramètres du constructeur ½ Enregistre automatiquement l?applet si pas d?exceptions/d?erreurs 119 Applications réparties carte : sommaire ? Les concepts u Approche client-serveur, objets répartis et carte ½ Les RPC u Invocation de méthodes dans la carte ½ Protocole DMI u Mise en ?uvre dans GemXpresso ? La pratique u Concepts de programmation u Développement d'une applet (+ exemple) u Construire une application avec GemXpresso 120 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Conception d?une applet GemXpresso ? Compatible avec Java Card u Mode Java Card seul possible u Mode GemXpresso = sur-ensemble Java Card 121 Applet carte GemXpresso et JCRE (1/2) ? Installation u JavaCard ½ Appel à install(apdu) u GemXpresso ½ Appel à un constructeur de l?applet ou ½ Appel à install(apdu) ? Sélection u Mécanisme identique pour Java Card et GemXpresso ½ APDU de commande select de Java Card et DMI identiques ½ Utilisation de deselect() et select() 122 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Applet carte GemXpresso et JCRE (2/2) ? Communication u JavaCard ½ Classe qui hérite de javacard.framework.Applet ½ APDUs traités par process(apdu) de l?applet u GemXpresso ½ Classe qui implémente une interface et hérite de javacard.framework.Applet ½ Si commande APDU = invoke de DMI alors décodage par le JCRE et invocation d?une méthode de l?interface de l?applet ½ Sinon, méthode process(apdu) appelée par le JCRE ? Si process() non redéfinie, ne fait rien et renvoie 90 00 123 Applet «Compteur» : interface ICompteur package nouveauCompteur.carte.gemplus.fr ; import javacard.framework.* ; public interface ICompteur { public static final short VALEUR_NEGATIVE = 1; public int lire(); public int incrementer( int montant ) throws UserException; public int decrementer( int montant ) throws UserException; } 124 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Applet «Compteur» : classe Compteur package nouveauCompteur.carte.gemplus.fr ; import javacard.framework.* ; public class Compteur extends Applet implements Icompteur { private int valeur; public Compteur() { valeur = 0; } public int lire() { return value; } public int incrementer(int montant) throws UserException { if (montant<0) throw new UserException(VALEUR_NEGATIVE); valeur += montant; return valeur; } public int decrementer(int montant) throws UserException { if (montant<0 || valeur-montant<0) throw new UserException(VALEUR_NEGATIVE); valeur -= montant; return valeur; } } 125 Applet «Compteur» : extensions ? Ajout d?un autre constructeur public Compteur( int valeur ) { this.valeur = valeur; } ? Compatibilité avec applet «Compteur» Java Card u Ajout des méthodes install() et process() identiques à l?applet Java Card u Permet à des terminaux travaillant avec l?applet Java Card (communiquant donc avec les APDUs traités par celle-ci) de continuer de travailler avec l?applet GemXpresso ½ Java Card utile pour reprogrammer des applications existantes ½ GemXpresso permet de développer plus facilement de nouvelles applications 126 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Construction de l?application cliente ? Construction de l?application terminal u Implémentation des classes du terminal avec JDK u Communication avec le serveur (applet carte) ½ Utilise l?interface de l?applet via le proxy généré ½ Établissement de la liaison : envoi d?un APDU de selection avec l?AID de l?applet (standardisé) ? Méthode select() du proxy ½ Invocation de méthodes de l?applet par l?utilisation du proxy u API de communication avec la carte ½ API cliente du Gemplus SDK ½ Paquetage com.gemplus.gcr.toolkit.gemxpresso 127 API cliente du Gemplus SDK Appli Appli Appli Appli Appli PROXY com.gemplus.util gemxpresso pcos com.gemplus.gcr.toolkit com.gemplus.gcr JNI JDirect wjnigcr w32gcr40 128 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 API Cliente du Gemplus SDK ? Paquetage com.gemplus.gcr.toolkit u «Framework» pour les applications clientes de cartes ? Paquetage com.gemplus.gcr.toolkit.gemxpresso u class GxCard extends JavaCard (extends Icc) ½ Représente la carte GemXpresso ½ Gère le protocole DMI : invokeConstructor(...) et invokeMethod(...) u Classes DmiOutputStream et DmiInputStream pour codage et décodage des messages DMI u Classes ConnectionException, CommunicationException et CardError pour les erreurs de communication ou carte u Classe CardVMUnexpectedException pour une exception retournée par la JCVM 129 Client «Compteur» : proxy (entête) import nouveauCompteur.carte.gemplus.fr.ICompteur; import com.gemplus.gcr.toolkit.gemxpresso.*; public class GxCabCompteur extends GxCab implements ICompteur { public static final GxAID GXAID = GxAID.create(...); public GxAID __getAID() { return GXAID; } public GxCabXCompteur( GxCard carte ) { super(carte); } // Installation de l?applet public void Compteur() { this.gemXpresso.invokeConstructor(-2, // #contructeur null); // Valeur des paramètres } // Autres constructeurs // Méthodes } 130 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Client «Compteur» : proxy (méthode) public int decrementer( int montant ) throws UserException { try { // Construit les paramètres DMI DmiOutputStream __dmiParameters = new DmiOutputStream() ; __dmiParameters.write( montant ) ; // Invoque la méthode byte[] __b = this.gemXpresso.invokeMethod(3, // #Méthode DMITYPE.INT, // Type de la valeur de retour __dmiParameters.toByteArray()); // Valeur paramètres __dmiParameters.close() ; // Retourne la valeur de retour DmiInputStream __dmiRV = new DmiInputStream( __b ) ; return __dmiRV.readInt() ; } // Propage seulement les exceptions déclarées et sous-types catch ( CardVMUnexpectedException __exc ) { if (__exc.getCardVMException() instanceof UserException) throw (UserException)__exc.getCardVMException() ; // Les autres exceptions restent encapsulées throw __exc ; } } 131 Client «Compteur» CardReader lecteur = new new Gcr410(SERIALPORT.G_COM1); GxCard carte = new GxCard(lecteur); try { // Connexion à la carte via lecteur GCR410 reader.connect(); AnswerToReset atr = carte.connect(); // Communication avec l?applet via le proxy GxCabCompteur compteur = new GxCabCompteur(carte); compteur.select(); System.out.println(??Montant du compteur = ?? + compteur.decrementer( 100 ) ); /* etc */ // Fin de la connexion carte.dispose(); lecteur.dispose(); } catch ( UserException e1 ) { System.out.println(??UserException : ?? + e1.getReason()); } catch ( Exception e2 ) { System.out.println(??Problème : ?? + e2.getMessage()); } 132 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Conclusion GemXpresso ? Méthodologie de développement d?applications carte u Basée sur Java Card pour programmer la carte u Basée sur RPC pour communication client-applet ? Points positifs u Environnement ouvert u Pas de codes spécifiques à la carte u Intégration dans les systèmes d?informations 133 Sujets de recherche Encore mieux intégrer la carte dans les applications réparties (des pistes) J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Améliorations ? Java Card u Normalisation format de Bytecode et procédure de chargement u Politiques de sécurité et de partage d?objets u Ramasse-miettes u APIs : String, etc. ? DMI u «Normalisation» du concept u Passage d?objets par référence ou valeur u Appel de méthodes depuis la carte vers le client u Sécurisation du protocole 135 Intégration dans les systèmes ? Voir la carte comme... u Un serveur RMI ou CORBA ou DCOM ? Services des applications réparties et carte u Nommage et AIDs carte u Sécurité et accès à la carte ou carte participant au service de sécurité u Transactions distribuées (voir après) u etc. ? Méthodes formelles pour certification des applets carte u3 travaux (avec la méthode B) présentés ci-après 136 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Transactions avec des cartes ? Permettre d?intégrer les cartes dans les schémas transactionnels distribués (OTS) class banque{ class Client { // Dans le serveur bancaire // Sur le terminal bancaire ? Propriétés ACID ? public void debit(int i) public void main(String args[]) { solde = solde - i; { ? Control IDT; ? //beginTransaction IDT=TransacationFactory.create(); class pme{ //Operations distribuées // Dans la carte PME banque.debit(100); ? pme.credit(100); public void credit(int i) //commitTransaction { solde = solde + i; IDT.getTerminator().commit(); ? ? 137 Vérification de l'interpréteur JC (1/3) ? Garantir que l ?interpréteur est conforme aux spécifications JC u En modélisant une machine défensive u En rétirant les test dynamiques pour les factoriser dans une phase initiale (par raffinements successifs) u En désynchronisant la vérification de l?exécution ? Résultats u Spécification du vérifieur (statique) u Implémentation partielle de l?interpréteur 138 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Spécification du Firewall (2/3) ? Le firewall est le mécanisme qui implémente la politique de sécurité ? Objectif : prouver que son implémentation garantit l?accès conforme à la mémoire u Gestion des contextes u Gestion des objets u Interprétation correcte du bytecode ? Nécessite la modélisation d'autres éléments u JCRE, Interpréteur, Pile Java, Objets ? Prouvé à 100% 139 Vérification politique de sécurité (3/3) ? Dans JC, absence de contrôle pour les flux transitifs d'information ? Nécessité d'une politique de sécurité globale u contrôle de flux et de consommation de ressources ? Pour une configuration donnée, analyse statique du flux d?information u Associer des niveaux aux informations et aux utilisateurs u Vérification à l'aide d'un "model checker" (SMV) ? Prototype développé avec l'ONERA pour serveurs d'applets 140 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Conclusion Où en sommes-nous ? Résumé : applications avec Java Card ? Langage Java pour programmer la carte ? Client-serveur bas niveau (échange d?APDUs) Terminal Commandes JCRE (masque) Applications clientes (APDUs) API Java Card Applets Carte Réponses 142 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Résumé : applications avec GemXpresso ? Techniques des applications réparties pour carte u Protocole d?invocation de méthodes u Méthodologie de développement client-serveur Terminal Invocation de Applications clientes méthodes JCRE (masque) Interfaces API Java Card (APDUs) Proxys d?applets Interfaces Applets Carte Réponses 143 Tendances de la carte à puce Carte Client u ISO 7816-4 (APDU) u Orienté protocole u ISO 7816-7 (SCQL) u SQL, ODBC, JDBC u Java Card (Java + DMI) u RMI, CORBA, DCOM ? Carte à puce = élément informatique comme les autres u Programmable u Intégrable dans les applications (réparties) u Potentialités d?applications carte de plus en plus importantes 144 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Discussion Des idées pour débattre Cartes à puce et applications réparties ? La carte devient un élément comme les autres des systèmes d'informations u Environnement d'exécution Java dans la carte u Serveur d'objets dans les applications réparties ½ Objets personnels sécurisés ½ Objets distribués à chaque porteur u Serveur sécurisé dans les applications réparties ½ Données sensibles (clés cryptographiques) stockées et utilisées (algorithmes cryptographiques) dans un support "sûr" ? Microcontrôleur encarté (sécurité physique) ? Accès logique sévèrement contrôlé (sécurité logique) 146 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Cartes à puce et applications réparties ? La construction d?applications carte utilise les même techniques que celles des applications réparties u Description IDL des services carte u Génération des souches clientes et serveurs u Protocole d'invocation de méthodes distantes au dessus du substrat de communication u Services horizontaux ½ Sécurité ½ Transactions distribuées ½ Nommage, etc. 147 Pour obtenir plus d?informations (1/4) ? Livres carte. Pas vraiment de bons livres mais les plus récents sont : u DreifusH. et Monk J. T., Smart cards, Wiley, 1998. u Guthery S. B. et Jurgensen T. M., Smart Card Developer?s Kit, Macmillan, 1998. http://ww.scdk.com u Rankl W. et Effing W., Smart Card Handbook, Wiley, 1997. ? Java Card u Site Sun : http://java.sun.com/products/javacard u Java Card Forum : http://www.javacardforum.com/ 148 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Pour obtenir plus d?informations (2/4) ? Articles et présentations u Articles dans JavaWorld http://www.javaworld.com/javaworld/ ½ Smart Cards: A Primer jw-12-1997/jw-12-javadev.html ½ Understanding Java Card 2.0 jw-03-1998/jw-03-javadev.html u Présentations à Java One 98 http://java.sun.com/javaone/javaone98/sessions/ ½ Java Card Technology: The Java Card Platform and APIs T802/index.html ½ JavaTechnology: Using Smart Cards with Java Technology T800/index.html 149 Pour obtenir plus d?informations (3/4) ½ Gemplus: Developing Smart Card-based Java Applications T908/index.html ? Produits Java Card u GemXpresso : http://www.gemplus.com/gemxpresso/ u CyberFlex : http://www.cyberflex.austin.et.slb.com/ u Odyssey : http://www.cp8.bull.net/products/javacara.htm u C@ppuccino : http://www.gdm.de/products/terminal/software/jav acap1.htm u iButton : http://www.ibutton.com/ 150 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce École d?été IMAG, INRIA, LIFL Autrans, du 23 au 28 août 1999 « Constructions d?applications réparties » Vendredi 27, 9h00-12h00 Pour obtenir plus d?informations (4/4) ? API d?accès aux cartes à puce u Open Card Framework (OCF) http://www.opencard.org/ u PC/SC http://www.smartcardsys.com/ http://www.microsoft.com/smartcard/ u Gemplus Smartcard Development Kit (SDK) : ½ Pas de version publique ½ Livrée avec le kit GemXpresso ? Recherche u Actes de Cardis 1996 et Cardis 1998 151 J.-Jacques Vandewalle, Gemplus Research Lab Construction d?applications avec la carte à puce

PARTAGER SUR

Envoyer le lien par email
1971
READS
20
DOWN
7
FOLLOW
2
EMBED
DOCUMENT # TAGS
#carte à puce  #sécurité  #architecture  #applications 

licence non indiquée


DOCUMENT # INDEX
Technologies, Informatique 
img

Partagé par  nova

 Suivre

Auteur:Jean-Jacques Vandewalle
Source:Gemplus Research Lab