Java Card

Java Card est un environnement d'exécution Java destiné aux applications pour Carte à puce. Cette technologie fournit un environnement sécurisé pour les applications qui fonctionnent sur ce support de capacité mémoire et de traitement limitées. De multiples applications peuvent être déployées avant et même après que la Carte à puce a été fournie à l'utilisateur final. Les applications écrites dans le langage de programmation Java peuvent être exécutées en toute sécurité sur l’ensemble des types de cartes disponible sur le marché.

Architecture

La carte à puce représente une des plate-formes informatiques la plus réduite^[1]. La configuration mémoire d'une carte à puce est de l’ordre d’1Ko de RAM (mémoire vive), 16Ko d'EEPROM et 24Ko de ROM (mémoire morte)^[1]. Le plus grand défi de conception de la technologie de Java Card est d'embarquer le logiciel de base Java dans une carte à puce en conservant l'espace mémoire nécessaire pour stocker des applications. La solution retenue par Sun, issue des travaux de Schlumberger ^[2], est d’implémenter un sous-ensemble des fonctionnalités du langage Java et d’appliquer un modèle réduit de la JVM (Java Virtual Machine) appelé JCVM (Java Card Virtual Machine)^[1]. En plus de fournir le support de langage Java, la technologie de Java Card définit un environnement d'exécution en temps réel qui supporte la mémoire, la communication, la sécurité et le modèle d'exécution de l’application. Cet environnement respecte la norme standard ISO7816^[3].

La plateforme Java Card est articulée autour^[4]:

• d’un sous-ensemble du langage Java.
• d’une machine virtuelle appellée Java Card Virtual Machine (JCVM)^{[note 1]}.
• d’un environnement d’exécution appelé Java Card Runtime Environment (JCRE)^{[note 2]}.
• d’un ensemble de librairies accessibles par des Application Programmer Interface (API)^{[note 3]}.

La caractéristique la plus significative du JCRE est qu'il fournit une séparation claire entre le système et les applications^[5]. La technologie de Java Card définit une plate-forme sur laquelle les applications écrites dans le langage de programmation Java peuvent fonctionner sur carte à puce et autres périphériques avec mémoire^[5]. Les Applications Java card sont vues comme des applets^[5]. Cette plateforme est découpée en 3 parties, chacune définie dans des spécifications^[6] :

Les spécifications JCVM

définissent les fonctionnalités mise en œuvre par la technologie Java Card. Elles incluent le jeu d'instruction de la Machine Virtuelle (VM) Java Card, un sous-ensemble du langage Java et les formats de fichier utilisé pour installer des applets et des bibliothèques dans des cartes à puce ou autres périphériques qui hébergent la technologie de Java Card^[5].

Les spécifications JCRE

définissent le comportement nécessaire de l'environnement d’exécution de la technologie de Java Card. Il inclut les mises en œuvre de la Virtual Machine Java Card, des classes d'API de Java Card, des services d'assistance pendant l'exécution comme la sélection d'applets et la gestion mémoire^[5].

Les spécifications API

est un complément du JCRE qu contient les définitions de classe requises pour supporter la JVCM et la JCRE. Il décrit les fonctions de bases utiles pour programmer des applications de carte à puce^[5].

Composants

Java Card est donc l'adaptation de la technologie Java pour les cartes à puce . Les applets sont développées dans le langage Java, elles sont ensuite transformées afin de satisfaire les contraintes de mémoire puis sont chargées dans les cartes^[1]. Une fois installée sur la plate-forme et sélectionnée, le bytecode de l'applet est exécuté par la machine virtuelle embarquée JCVM^[7].

Java Card Virtual Machine

La JCVM exécute le bytecode^{[note 4]}, contrôle l'attribution de la mémoire, gère les objets et met en application la sécurité pendant l'exécution. La capacité des cartes à puces étant trop limité pour contenir toutes les informations des fichiers de classe de Java, vérificateur de code objet, la JVCM est donc implémenté en deux partie distincts (principale différence entre la JVM et la JCVM )^[8]:

• Une partie Off-Card^{[note 5]}, intégrant le convertisseur et vérificateur fonctionnant sur un PC^{[note 6]} ou un poste de travail distant^[8].
• une partie On-Card^{[note 7]} c'est-à-dire présente sur la carte qui inclut l'interprèteur de code Javacard^[8].

Java Card Virtual Machine

Ensemble, ils implémentent le chargement des fichiers de classe Java par l'intermédiare du vérificateur et convertisseur pour enfin éxécuter l'applet à l'aide de l'interprèteur.

Le vérificateur examine le byte code, pour assurer qu'il respecte la syntaxe et les règles du langage. Le vérificateur vérifie statiquement que les flux de contrôle et de données ne produiront pas d'erreur lors de l'éxécution^[9].

Le convertisseur charge les fichiers de classe vérifiés par le vérificateur . Il produit un fichier CAP file^{[note 8]}, (contenant une représentation compacte d'un ou plusieurs fichier Java compilé) correspondant à la conversion d’un applet^[10].

En plus de la création d'un fichier CAP, le convertisseur produit un fichier Export file^{[note 9]} contenant des informations API publiques pour un ou plusieurs fichier de classes)^[11]. Il définit le niveau d'accès et le nom d'une classe, le niveau d'accès et les signatures des méthodes ainsi que des champs de la classe. Un fichier d'exportation contient aussi les d'informations utilisées pour résoudre des jonctions de références entre différentes applets sur la carte)^[7].

L'interprèteur de JavaCard fournit le support d'exécution du langage Java, il exécute les tâches suivantes)^[12] :

• Exécute des instructions de code des applets ;
• Contrôle la création d'objet et l'attribution de mémoire ;
• Joue un rôle crucial dans l'assurance de la sécurité pendant l'exécution.

L'interprèteur de JavaCard ne charge pas de fichiers de CAP, il en exécute seulement le code)^[12]. Dans la technologie de JavaCard, les mécanismes de téléchargement et d'installation de fichier CAP sont inclus dans une unité appelée l'installateur résidant dans la carte^[12]. Il coopère avec un programme d'installation non-implémenter sur le carte. Le programme d'installation transmet le fichier binaire exécutable dans un fichier CAP à l'installateur sur la carte via un dispositif d'acceptation de carte (la CAD). L'installateur écrit le fichier binaire dans la mémoire de carte à puce, le lie avec les autres classes qui ont déjà été placées sur la carte. Il crée et initialise les structures de données qui sont utilisées par la JCRE.

Java Card Runtime Environment

Le JCRE est responsable de la gestion des ressource de la carte, des communications réseau, de l'exécution et la sécurité des applets^[13]. Il est implémenté sur la carte à puce et sert essentiellement au système d'exploitation présent sur la carte^[14]. Le JCRE est composé de la JCVM, des API, des industry-specific extensions^{[note 10]}. et des système de classes ^[14].

Le JCRE distingue les applets des propriétés techniques de la carte à puce. Il fournit le système standard et les API pour les applets. Celles ci sont donc plus simple à écrire et sont donc facilement portables sur différentes architectures de carte à puce.

La couche inférieure du JCRE contient la JCVM et les méthodes de bases^{[note 11]}. Les méthodes natives fournissent le support à la JCVM et le système de classes pour la couche suivante.

Architecture

Le système de classes cadre le fonctionnement du JCRE^[15] et son rôle est similaire à un système d'exploitation. Il est responsable :

de la gestion des transactions 

mécanisme permettant de rendre un ensemble d’opérations atomique ( ex: transaction bancaire).

des communications avec le serveur CAD 

Ces communications se font sous forme d’Application Protocol Data Unit (APDU)s dont la structure est définie par la norme ISO 7816.

du cycle de vie des applets 

Le JCRE initialise l’applet après son installation. il peut alors sélectionner l'applet pour lui signifier qu’elle peut s’exécuter, la déselectionner ou lui transmettre un signal APDU.

Le système de classes invoquent les méthodes natives ou "native methods"^[16].

Les méthodes natives contiennent un ensemble de fonctions bas niveau qui permettent au JCRE de gérer les ressources physiques de la carte telles que les entrées-sorties, la gestion de la mémoire ou le coprocesseur cryptographique. Ces méthodes sont compilées en code exécutable dédié au processeur de la carte^[14].

La structure de classes API définit les interfaces de programmation d'application, API^[15]. L'avantage majeur est qu'elle rend plus facile la création d'applet. Les développeurs d'applet peuvent concentrer leur effort sur la programmation vis à vis des contraintes de l'infrastructure de système de carte à puce grâce au sept extensions d'API disponibles^[17].Les applets ont accès aux services JCRE par des classes API.

industry-specific extensions

La structure «industry-specific extensions» fournit des bibliothèques complémentaires de services supplémentaires ou de modèles de système et sécurité (ex :industries financières)^[15].

installer

L'installateur permet le téléchargement sécurisé de logiciel et d’applet sur la carte après que la carte a été produite et fournie son l'utilisateur^[15]. L'installateur coopère avec le programme d'installation « off-card ». Ensemble, ils accomplissent la tâche de charger le contenu binaire du CAP file. Cependant, l'installateur est un composant JCRE facultatif, mais sans lui tout logiciel de carte, y compris des applets, devraient être écrit dans la mémoire de la carte pendant le procédé de fabrication^[14].

API

L'Interface de programmation d'application API disponible permet de développer des applications et fournir des services à ces applications^[18]. Ces classes définissent les conventions selon lesquelles une applet JavaCard a accès au JCRE et aux fonctions natales, y compris la fonction de système d'exploitation, l'accès à la mémoire et des opérations d'entrée-sortie. Les API utilisées par la carte sont :

• java.io un sous-ensemble du paquet java.io dans le langage de programmation Java standard.
• Java.lang fournit les fondamentaux pour la conception du sous-ensemble de technologie de JavaCard du langage de programmation Java. Les classes fournit sont tirées de java.lang dans le langage de programmation Java standard et représentent la fonction principale requise par la JVCM. Cette fonction principale est représentée par la classe d'Objet, qui est la super-classe pour toutes les classes de langage Java et la classe Throwable, qui est la super-classe pour l'exception et les classes d'exception pendant l'exécution.
• Java.rmi définit l'interface à distance qui identifie des interfaces dont les méthodes peuvent être invoquées du périphérique de réception de carte (la CAD) des applications client. Javacard.framework fournit une structure de classes et des interfaces pour la conception et la communication des applets, contient les fonctionnalités essentielles de fonctionnement avec JavaCard.
• Javacard.framework.service fournit une structure de service de classes et d’interfaces qui permettent à une applet de JavaCard d'être conçues comme une liste de composants de service.
• Javacard.security fournit des classes et les interfaces qui contiennent la fonction disponible pour implémenter une sécurité et une structure de Cryptographie sur la JavaCard.
• Javacardx.crypto contient la fonction qui implémente la sécurité et la structure de cryptographie sur JavaCard.

Version

JavaCard par rapport à Java

Avantages

Les producteurs de cartes à puces (tel que Gemplus, Axalto, Oberthur Technologies,...) implémentent les fonctionnalités de Java Card suivantes^[19] :

Intéropérabilité 

les Applets développées avec la technologie JavaCard fonctionnent sur n'importe quelle type de Carte à puce (et indépendament du matériel sous-jacent)^[20].

Sécurité 

la technologie de Java Card repose sur la sécurité du langage de programmation Java pour fournir un environnement d'exécution sécurisé^[21].

Application multi capability^{[note 12]}

la technologie de Java Card permet à de multiples applications de cohabiter en sécurité sur une seule carte à puce^[22].

Dynamique 

de nouvelles applications peuvent être installées en toute sécurité après qu'une carte a été fournie à l'utilisateur, permettant aux producteurs de carte de répondre dynamiquement aux besoins de changement de leur client^[23].

Compatible avec les normes existantes 

l'API de Carte Java est compatible avec les standards internationaux pour Carte à puce comme ISO7816 ou Europay Mastercard Visa

Les développeurs d'applications pour Java Card approuvent l'utilisation du langage de programmation Java)^[24]:

La programmation orientée objet 

apporte une plus grande modularité du code et sa réutilisation, augmentant la productivité du programmeur^[25].

La protection 

figurant dans les caractéristiques du langage de programmation Java s'applique aux applets de Java Card, mettant en application des attributs de protection et de typage fort^[26].

Des outils de développement 

actuellement disponibles et puissants^[27].

Inconvénient

De nombreux progrès ont été réalisés avec JavaCard platform version 3 visant à éliminer certains points faibles des versions antérieurs (mono-thread, la fonction finalize(), pas de ramasse-miette (garbage collector))^{[pas clair] [réf. nécessaire]}. Cependant, il est toujours impossible d’utiliser le typage long, char ^{[réf. nécessaire]}.

Sécurité des javacard

La gestion de la sécurité développée pour les Carte à puce est implémentée par la JCVM^[28]qui fournit les règles de sécurité suivantes :

• Chaque JCVM contient une fonction vérificateur responsable de vérifier les fichiers Java compilé (.class) issue d'un compilateur java^[29].

• La fonction sécurité de la JCRE met en application des pare-feu pour isoler chaque applet, ce qui empêche l'accès non autorisé d'objets créés par une autre applet^[30].

• Tous les accès aux méthodes et variables dans un fichier de classe se font par accesseurs^{[note 13]}. Ces accesseurs définissent un contrôle de cohérence du type pour chaque méthode. il est possible de déclarer une méthode « public », « protected » (accessibles par des méthodes dans la même sous-classe ou « package ») ou « private » (aucun accès par d'autres classes). Si aucune déclaration n'est faite, la méthode peut être accessible par n'importe quelle classe dans le même paquet ^[31].

• l’accès à des variables ne peut se faire que par référence au travers de la pile. Des programmes malveillants sont empêchés d’accéder à des variables car les valeurs des variables locales sont rendu indisponibles après chaque invocation de méthode. Une méthode ne peut avoir accès qu’à ces propres ressources^{[pas clair]}.

Historique

En 1996, Les ingénieurs de la division carte de Schlumberger^[2] au Texas (qui a fusionné plus tard avec Gemplus international pour former Gemalto) ont souhaité simplifier la programmation des cartes à puces tout en préservant la sécurité des données dans le respect de la norme ISO 7816.

La solution retenu fut le langage de programmation Java. En raison de la faible capacité mémoire disponible sur une Carte à puce seulement un sous-ensemble de Java pouvait être utilisé. Ainsi fut créé JavaCard 1.0 en novembre 1996, le premier langage orienté objets adapté aux Carte à puce.

février 1997, Schlumberger et Gemplus fondent JavaCard Forum qui recommande des spécifications à JavaSoft (la division de Sun à qui appartient Java Card ) en vue d'obtenir une standardisation du langageet promouvoit les APIs (Application Programming Interface) de JavaCard pour qu'il devienne la plate-forme standard de développement des applications pour les Carte à puce^[2].

novembre 1997, Les producteurs de Carte à puce comme De La Rue, Bull , Giesecke & Devrient(G&D) rejoigne JavaCard Forum qui édite une nouvelle version de spécifications JavaCard 2.0^[2].

Par la suite, Sun éditera alors quatre nouvelles spécifications : mars 1999 édition de JavaCard 2.1^[2]., en juin 2002 JavaCard 2.2, en mars 2008' JavaCard 3.0 et enfin la plus récente JavaCard 3.0.1 en mai 2009^[32].

La société Oracle Corporation acquiert en janvier 2010 l'entreprise Sun Microsystems.

Concept de programmation

outils commerciaux adaptés à Java Card

GemXpresso Rapid Applet Development de Gemplus

Cyberflex 2.0 Multi8k de Schlumberger

Odyssey lab de Bull/CP8

Marché

Domaine d'application des cartes à puce

De nombreux type de carte à puce peuvent profiter de la technologie de JavaCard^[33] :

• Carte SIM (Subcriber Identity Module) utilisées dans les téléphones cellulaire sur les réseaux sans fil.
• Carte bancaire
• Carte d'identité
• Carte santé
• Les cartes qui fournissent l'accès logique et l'accès physique aux ressources d'entreprise.

Sur la majorité de réseaux téléphoniques cellulaires, un abonné utilise une carte à puce généralement appelée une carte SIM pour activer le téléphone. La carte authentifie l'utilisateur et fournit des clés de chiffrement pour le transport de la voix numérique. les cartes SIM implémentées de la technologie de JavaCard peuvent aussi fournir des services transactionnels bancaire à distance. Des centaines de millions de cartes SIM basées sur la technologie de Java Card fonctionnent déjà avec des services innovatants dans des téléphones cellulaire.

Dans le secteur bancaire, les cartes à puce donnent l'accès sécurisé aux utilisateurs à un large tableau de services financiers incluant les distributeurs automatiques de billets, le paiement de facture et de péages. La technologie de Java Card permet à une seule carte à puce d'héberger de multiples applications financières et livrer des services tiers ou sécuriser le commerce en ligne.

Une large variété d’applications sont disponibles dans les domaines où la sécurité et authentification sont importantes tel que l'accès sécurisé à des installations, dossiers médicaux.

La technologie de JavaCard améliore l'accès grand public aux nouveaux services d'e-commerce par l’intermédiaire d'appareils connectés. En effet, les téléphones cellulaire et les équipements de télévision pour chaînes payantes sont les exemples de marchés où la majorité de produits, déjà disponibles, incluent déjà des lecteurs de carte à puce.

Notes et Références

Notes

1. ↑ JCVM : Java Card Virtual Machine ou encore "Machine Virtuelle Java" en français.
2. ↑ JCRE : Java Card Runtime Environment ou encore "Environnement d’Exécution Java" en français.
3. ↑ API : Application Programmer Interface ou encore "Interface de Programmation Applicative" en français.
4. ↑ bytecode ou encore "code binaire intermédiaire" en français, pseudo-code issue d'un compilation Java ayant l'extension .class
5. ↑ Off-Card ou encore "partie externe à la carte à puce" en français.
6. ↑ PC (Private Computer) ou encore "Ordinateur personnel" en français.
7. ↑ On-Card ou encore "partie interne à la carte à puce" en français.
8. ↑ CAP file (Converted APplet) ou encore "fichier compacte d'application" en français.
9. ↑ Export File ou encore fichier d'export en français.
10. ↑ industry-specific extensions ou 'extension spécifiques pour une industrie" en français
11. ↑ méthodes de bases qui sont nommées dans la littérature scientifique anglo-saxonne natives method
12. ↑ Application multi capabilityou encore "possibilité d'applications multiples " en français.
13. ↑ Un accesseur est une méthode permettant de récupérer le contenu d'une donnée membre protégée

Références

1. ↑ ^{a, b, c et d} Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 29
2. ↑ ^{a, b, c, d et e} Baentsch 1999, p. 37
3. ↑ http://www.iso.org/iso/fr/search.htm?qt=7816&searchSubmit=Rechercher&sort=rel&type=simple&published=true^{[pas clair]}
4. ↑ http://www.oracle.com/technetwork/java/javame/javacard/overview/about/index.html^{[pas clair]}
5. ↑ ^{a, b, c, d, e et f} Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 30
6. ↑ http://www.oracle.com/technetwork/java/javacard/overview/overview-jsp-135353.html#^{[pas clair]}
7. ↑ ^{a et b} Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 34
8. ↑ ^{a, b et c} Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 31
9. ↑ Casset et 2002 Casset2002, p. 202
10. ↑ Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 32
11. ↑ Erreur de référence : Balise <ref> incorrecte ; aucun texte n’a été fourni pour les références nommées Chen2000_33.
12. ↑ Erreur de référence : Balise <ref> incorrecte ; aucun texte n’a été fourni pour les références nommées Chen2000_35.
13. ↑ Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 36
14. ↑ Erreur de référence : Balise <ref> incorrecte ; aucun texte n’a été fourni pour les références nommées Chen2000_36.
15. ↑ ^{a, b, c et d} Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 37
16. ↑ Technology for Smart Cards: Architecture and Programmer's Guide 2000, p. 38
17. ↑ Erreur de référence : Balise <ref> incorrecte ; aucun texte n’a été fourni pour les références nommées Chen2000_38.
18. ↑ http://developer.gemalto.com/home/technology/java-card.html
19. ↑ Oracle 2011
20. ↑ Oracle 2011
21. ↑ Oracle 2011
22. ↑ Oracle 2011
23. ↑ Oracle 2011
24. ↑ Oracle 2011
25. ↑ Oracle 2011
26. ↑ Oracle 2011
27. ↑ Oracle 2011
28. ↑ Gemalto 2011
29. ↑ Oracle 2011
30. ↑ Gemalto 2011
31. ↑ Gemalto 2011
32. ↑ Spécifications
33. ↑ http://www.oracle.com/technetwork/java/javame/javacard/overview/about/index.html

Bibliographie

• (en) Zhiqun Chen, Java Card Technology for Smart Cards: Architecture and Programmer's Guide, Addison Wesley, 18 septembre 2000 [lire en ligne] 
• (en) M. Baentsch, P. Buhler, T. Eirich, F. Horing et M. Oestreiche, « JavaCard-from hype to reality », dans IEEE Concurrency, vol. 7, n^o 4, octobre-décembre 1999, p. 36-43 (ISSN 1092-3063) [lien DOI]
  Secure Syst. Group, IBM Res. Div. Zurich
   
• (en) L. Casset et JL. Lanet, « Increasing smart card dependability », dans ACM, 2002, p. 209 - 212 [lien DOI]
  EW 10 Proceedings of the 10th workshop on ACM SIGOPS European workshop
   
• (en) P.H. Hartel et L. Moreau, « Formalizing the safety of Java, the Java virtual machine, and Java card », dans ACM Computing Surveys (CSUR), vol. 33, n^o 4, 2001, p. 517-558 (ISSN 0360-0300) [lien DOI] 

Voir aussi

Articles connexes

liens externes

• (en) About Java Card Technology. Mis en ligne le 14 novembre 2011
• (en) Java Card™ security. Mis en ligne le 22 novembre 2011
• (en) [www.oracle.com/technetwork/java/javacard/offcardverifierwp-150021.pdf offcardverifier]. Mis en ligne le 22 novembre 2011