Pour un article plus général, voirSystème d'exploitation pour carte à puce.
Java Card est unsystème d'exploitation pour carte à puce qui fournit essentiellement unenvironnement d'exécution pour un sous-ensemble du langageJava spécifiquement destiné aux applications pourcarte à puce. Java Card permet l'exécution d'applications au sein des cartes à puce, qui offrent des capacités de mémoire et de traitement limitées. De multiples applications peuvent être déployées avant et même après que lacarte à puce a été fournie à l'utilisateur final. Les applications écrites dans lelangage de programmation Java peuvent être exécutées en toute sécurité sur l’ensemble des types de cartes disponibles sur le marché.
En 1996, les ingénieurs de la division carte deSchlumberger[1] auTexas (qui a fusionné plus tard avecGemplus international pour formerGemalto) ont souhaité simplifier la programmation des cartes à puces tout en préservant lasécurité des données dans le respect de la norme ISO 7816.
La solution retenue fut le langage de programmationJava. En raison de la faible capacité mémoire disponible sur uneCarte à puce seulement un sous-ensemble deJava pouvait être utilisé. Ainsi fut créé Java Card 1.0 en, le premier langage orienté objet adapté aux cartes à puce.
,Schlumberger etGemplus fondent Java Card Forum qui recommande des spécifications à JavaSoft (la division de Sun à qui appartient Java Card) en vue d'obtenir une standardisation du langage et promeut les APIs de Java Card pour qu'elle devienne la plate-forme standard de développement des applications pour lescartes à puce[1].
, les producteurs de Cartes à puce commeDe La Rue,Bull,Giesecke & Devrient(G&D) rejoignent Java Card Forum qui édite une nouvelle version de spécifications Java Card 2.0[1].
Par la suite, Sun éditera alors quatre nouvelles spécifications : en édition de Java Card 2.1[1], en Java Card 2.2, en Java Card 3.0 et enfin la plus récente Java Card 3.0.1 en[2].
La sociétéOracle Corporation acquiert en l'entrepriseSun Microsystems.
La carte à puce représente une des plates-formes informatiques les plus réduites[3]. Le plus grand défi de conception de la technologie de Java Card est d'embarquer le logiciel de baseJava dans unecarte à puce en conservant l'espace mémoire nécessaire pour stocker des applications. La solution retenue par Sun, issue des travaux de Schlumberger[1], est d’implémenter un sous-ensemble des fonctionnalités du langageJava et d’appliquer un modèle réduit de la JVM (Java Virtual Machine) appelé JCVM (Java Card Virtual Machine)[3].En plus de fournir le support de langageJava, 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[4].
La plate-forme Java Card est articulée autour[5] :
La caractéristique la plus significative du JCRE est qu'il fournit une séparation claire entre le système et les applications[6].La technologie de Java Card définit une plate-forme sur laquelle les applications écrites dans le langage de programmationJava peuvent fonctionner sur carte à puce et autres périphériques avec mémoire[6].Les applications Java Card sont vues comme desapplets[6] ou desservlets[7].
À partir de la version 3.0, éditée par Sun en, à la suite des évolutions des cartes à puces, la plate-forme Java Card se décline en 2 versions[8].
Java Card est donc l'adaptation de la technologieJava pour lescartes à puce. Lesapplets sont développées dans le langageJava, elles sont ensuite transformées afin de satisfaire les contraintes de mémoire, puis sont chargées dans la carte[3]. Une fois installé sur la plate-forme et sélectionné, lebytecode[note 4], de l'applet est exécuté par la machine virtuelle embarquée JCVM[10].
La JCVM exécute lebytecode, 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 Java, vérificateur decode objet, la JVCM est donc implémentée en deux parties distinctes (principale différence entre la JVM et la JCVM)[11] :
Ensemble, ils implémentent le chargement des fichiers de classe Java par l’intermédiaire du vérificateur et convertisseur pour enfin exécuter l'applet à l'aide de l’interpréteur.
En plus de la création d'un fichier CAP, le convertisseur produit un fichier d'exportation[note 9] contenant des informations API publiques pour un ou plusieurs fichiers de classe[15].Il définit le niveau d'accès et le nom d'une classe ainsi que le niveau d'accès et les signatures des méthodes et champs de la classe. Un fichier d'exportation contient aussi des informations utilisées pour résoudre des jonctions de référence entre différentes applets sur la carte[10].
L’interpréteur de Java Card fournit le support d'exécution du langage Java, il exécute les tâches suivantes[16] :
L’interpréteur de Java Card ne charge pas de fichier de classe ou fichier CAP, il en exécute seulement le code[16]. Dans la technologie de Java Card, les mécanismes de téléchargement et d'installation sont inclus dans une unité appelée l'installateur résidant dans la carte à puce[16]. Il coopère avec un programme d'installation non-implémenté sur la carte. Le programme d'installation transmet le(s) fichier(s) à l'installateur sur la carte via un dispositif d'acceptation de carte (CAD[note 10]). L'installateur écrit le(s) fichier(s) dans la mémoire de carte à puce pour être lu avec les autres classes qui sont déjà embarquées sur la carte. Il crée et initialise les structures de données qui sont utilisées par la JCRE.
Le JCRE est responsable de la gestion des ressources de la carte, des communications réseaux, de l'exécution et la sécurité des applets[17]. Il est implémenté sur la carte à puce et sert essentiellement au système d'exploitation présent sur la carte[17].Le JCRE est composé de la JCVM, des APIs, d'extensions spécifiques à une industrie[note 11]. et des systèmes de classes[17].
Le JCRE distingue les applets des propriétés techniques de la carte à puce. Il fournit le système standard et les APIs pour les applets. Celles-ci sont donc plus simples à écrire et sont donc facilement portables sur différentes architectures de cartes à puce[17].
La couche inférieure du JCRE contient la JCVM et les méthodes natives[note 12]. Elles fournissent le support à la JCVM et le système de classes pour la couche suivante.Le système de classes cadre le fonctionnement du JCRE[18] et son rôle est similaire à un système d'exploitation. Il est responsable :
Le système de classes invoque les méthodes natives[20]. Elles contiennent un ensemble de fonctions bas niveau qui permettent au JCRE de gérer les ressources physiques de la carte telles que lesentré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[17].
La structure de classes API définit les interfaces de programmation d'application,API[18]. L'avantage majeur est qu'elle rend plus facile la création d'applet. Les développeurs d'applet peuvent concentrer leurs efforts sur la programmation vis-à-vis des contraintes de l'infrastructure de système de carte à puce grâce aux extensions d'API disponibles[20]. Les applets ont accès aux services JCRE par des classes API.
La structure extension spécifique à une industrie fournit les bibliothèques complémentaires de services supplémentaires ou des modèles de système et de sécurité (ex : industries financières)[18].
L'installateur permet le téléchargement sécurisé de logiciels et d’applets sur la carte après que la carte a été produite et fournie à l'utilisateur[18]. L'installateur interne coopère avec l'installateur externe à la carte. Ensemble, ils accomplissent la tâche de charger le contenu binaire du fichier CAP ou fichier de(s) classe(s). Cependant, l'installateur est un composant JCRE facultatif, mais sans lui tous logiciels de carte, y compris lesapplets, devraient être écrits dans la mémoire de la carte pendant le procédé de fabrication[17].
L’interface de programmation d'applicationAPI disponible permet de développer des applications et fournir des services à ces applications[21] :Ces classes définissent les conventions selon lesquelles une Applet Java Card 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 les opérations d'entrée-sortie. Les API utilisées par la carte sont :
La version 3 « Connectée » des spécifications de la plateforme Java Card présente des différences profondes avec les autres versions existantes.
Tout d'abord, alors que les versions antérieures ne pouvaient charger que desfichiers binaires spécifiques (les fichiers CAP), les applications Java Card 3 « Connectées » sont déployées sous forme de fichiers java compilés de façon conventionnelle (des fichiers.class) regroupés dans des fichiers.jar, à l'instar des machines virtuelles java conventionnelles[24]. Il n'est alors plus nécessaire d'avoir recours à des outils de conversions de code.
Par ailleurs Java Card 3 « Connectée » privilégie le mode de communication de l'internet : lesprotocoles internet via norme IP ISO 7816-4 pour les interfaces « avec contacts ». La norme ISO 14443 est elle utilisée pour les interfaces «sans contact»[9]. Les applications Java Card 3 « Connectées » sont en fait, desServlets, c'est-à-dire de véritablesServices Web, qui respectent, à ce titre, le protocoleHTTP.
La machine virtuelle Java Card 3 est basée sur le CLDC[note 13] largement utilisé dans le monde de la téléphonie mobile[25]. Cette plate-forme donne accès aux fonctionnalités les plus riches du langage JAVA[9]. La plate-forme CLDC a été réduite en taille, les protocoles et les systèmes sécurités de cartes à puce ont été intégrés[9].
Évolution des périphériques supportant la technologie Java Card[26]
| Carte à puce traditionnelle | Carte à puce récente compatible V3 |
|---|---|
| 8/16-bit CPU | 32-bit CPU |
| 2 kb RAM | 24 kb RAM |
| 48 kb - 64 kb ROM | >256 kb ROM |
| 8–32 kb EEPROM | >128 kb EEPROM |
| Serial I/O interface | High-speed interfaces |
| 9,6 kb/s - 30 kb/s | 1,5 Mb/s - 12 Mb/s |
| Full duplex | Half duplex |
Amélioration apportée par la version 3 connectée[24].
| Spécificités |
| Générics[30] |
| Métadonnées |
| Autoboxing[31] |
| Amélioration de la boucle for |
| Assert (test unitaire) |
| Énumération[32] |
| Utilisation de méthodes à argument Variables[31] |
| Import static[33] |
Limitation du moteur de servlet de java card V3[34]
Liste des principales caractéristiques présentes dans les spécifications Java Serlet 2.4[35] qui ne sont pas supportées par la plate-forme Java Card V3.
La gestion de la sécurité développée pour les cartes à puce est implémentée par la JCVM qui fournit les règles de sécurité suivantes[37] :
Au-delà de la vérification de code objet implémentée par la JCVM, la plate-forme de Java Card 3 implémente des mécanismes de sécurité qui fournissent le niveau d'application et la sécurité des communications[38].
La plate-forme de Java Card supporte un mécanisme d'isolement de code. L'isolement de code assure que le code chargé d'une application ne se heurte pas au code d'autres applications[39].
La plate-forme de Java Card supporte l'isolement de contexte[note 15] et d’applications. L'isolement de contexte assure que les objets créés, donc en possession d’applications fonctionnant dans un même contexte, ne peuvent pas être accédés par des applications d'un autre contexte à moins que ces applications possédant ces objets ne fournissent explicitement des interfaces pour l'accès. De telles interfaces sont appelées des interfaces en commun et des objets implémentant ces interfaces, appeléscommun interface objets, constituent des points d'entrée légaux à ces applications[39].
La sécurité à base de rôles permet à la politique de sécurité d'une application de limiter l'accès aux ressources protégées de l’application. Les restrictions sont basées sur les caractéristiques de l'application demandant l'accès, comme son identité et l'identité de l'utilisateur sur lequel la défense d’accès est demandée[39].
L'authentification de l'utilisateur est le processus par lequel un utilisateur prouve son identité à la carte. Cette identité authentifiée est alors utilisée par la plate-forme pour exécuter des décisions d'autorisation, comme celles requises par la sécurité à base de rôles, pour avoir accès aux ressources protégées[40].
L'authentification d'application client est le processus par lequel une application cliente prouve son identité à une application serveuse. Cette identité authentifiée est alors utilisée par l'application serveuse pour exécuter des décisions d'autorisation dans le but d'avoir accès aux ressources protégées[40].
Avec la plate-forme java Card, les applications peuvent interagir avec des applications à distance par des communications de réseaux sécurisées (TLS, SSL)[41].
Un développeur d'application Web peut déclarer des prérequis pour l'intégrité et la confidentialité lors du déploiement d'une application Web. Le développeur d'application ou le fournisseur peut aussi exiger que l'on héberge l'application sur un port sécurisé dédié avec des connexions HTTPS ouvertes[41].
La plate-forme Java Card supporte une structure de cryptographie. Un développeur d'application ou un fournisseur peut choisir l'algorithme de cryptographie qui répond le mieux aux besoins de son application[42].
Un Applet Java Card respecte la norme ISO 7816. C’est-à-dire qu’elle répond à des requêtes de la même manière qu’elle les reçoit sous la forme de commandes en byte codes. Ceci simplifie considérablement le développement d’une application, car il n’y a plus besoin de coder en bas niveau l’envoi et la réception des commandes. En effet cette partie est maintenant encapsulée dans unframework java.
Les commandes en byte code sont appelées des APDU (Application Protocol Data Unit). Celles-ci sont codées différemment en fonction de l’envoi et de la réception[43].
Une commande APDU telle qu'elle est envoyée depuis le lecteur à la carte Java est une série de cinq octets éventuellement suivis d'un nombre variable d'octets, formatés comme suit :
Une réponse APDU telle qu'elle est envoyée depuis la carte Java au lecteur, est une série d'octets, retournée en réponse à une commande et formatée comme suit :
_waving.svg)
0x90 et0x9F indique que la commande a été correctement exécutée. Une valeur entre0x60 et0x6F indique que la commande n'a pas pu être exécutée par le programme placé dans la carte[43].Lorsque la commande au niveau de l’applet s’exécute normalement, la valeur du statut renvoyé correspond à90 00.
Si une instruction INS prévoit à la fois d'envoyer et de recevoir des données, Java Card normalise un système d'APDU en deux phases. Dans un premier temps, l'APDU est envoyée avec pour <Ln> un nombre d'octets à envoyer, puis lorsque la carte répond 0x91 <Le> (indiquant que <Le> octets sont prêts à être retournés par la carte, en réponse à la commande) une APDUGet Response est transmise pour déclencher la réception de ces <Le> octets sortants[43].
En résumé, le champ de donnée(s) est optionnel dans les deux cas, APDU de commande et APDU de réponse. Par conséquent, il y a quatre cas possibles de communication entre le client et la plateforme Java Card Platform, Version 2.2.2 (ou Version 3.0.1Classic Edition) :
| Cas 1 | APDU de commande sans donnée | APDU de réponse sans donnée |
| Cas 2 | APDU de commande avec donnée(s) | APDU de réponse sans donnée |
| Cas 3 | APDU de commande sans donnée | APDU de réponse avec donnée(s) |
| Cas 4 | APDU de commande avec donnée(s) | APDU de réponse avec donnée(s) |
Avant de pouvoir transmettre une commande à une Applet déployée dans une Java Card, il est nécessaire de la sélectionner par l’envoi d’une commande APDU spécifique en précisant l’identifiant de l’applicationAID[note 16]. L’identifiant d’application est composé de deux parties. La première sur 5 octets, leRID[note 17], est assigné par la norme ISO. Celui-ci correspond à l’identifiant propre à l’entreprise. Le second,PIX[note 18] est quant à lui composé entre 0 et 11 octets. L’assignation de celui-ci reste à la charge de l’entreprise qui développe l'application Java Card[44].
Pour la programmation d’une Java Card, il y a cinq étapes importantes :
.class en.cap ;.cap (optionnel) ;.cap dans la Java Card.Le point fort du développement Java Card est que les deux premières étapes peuvent être réalisées avec un environnement de développement JAVA classique.
Voici un exemple de code renvoyant tout simplement la chaine de caractères ‘Hello World’ sur la demande liée à l’instruction0x10. Dans cet exemple le AID est composé des valeurs de RID = DA8EF6DD26 et de PIX = 86E899.
Exemple d’applet ‘Hello World’[45].
importjavacard.framework.*;publicclassHelloWorldextendsApplet{// Initialisation de la variable avec ‘H’, ‘e’, ‘l’, ‘l’, ‘o’, ' ', 'W', 'o', 'r', 'l', 'd'.privatefinalstaticbyte[]message={0x48,0x65,0x6c,0x6c,0x6f,0x20,0x77,0x6f,0x72,0x6c,0x64};publicstaticvoidinstall(byte[]bArray,shortbOffset,bytebLength){newHelloWorld();}protectedHelloWorld(){register();}publicvoidprocess(APDUapdu){if(selectingApplet()){// Retourne le statut à OKreturn;}byte[]buffer=apdu.getBuffer();if(buffer[ISO7816.OFFSET_CLA]!=(byte)(0x80))ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);// Retourne le status word CLA NOT SUPPORTEDswitch(buffer[ISO7816.OFFSET_INS]){case0x10:// Copie du contenu du message dans le buffer de la reponseUtil.arrayCopy(message,(byte)0,buffer,ISO7816.OFFSET_CDATA,(byte)message.length);// Envoi de la réponseapdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA,(byte)message.length);break;default:// Retourne le statut à la valeur INS NOT SUPPORTEDISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);}}}
Pour cet exemple, deux échanges d'APDU sont nécessaires entre le client et la Java Card :Le premier envoi correspond à la sélection de l'application en précisant l'AID :
Commande : 0x00 0xA4 0x04 0x00 0X08 0XDA 0X8E 0XF6 0XDD 0X26 0X86 0XE8 0X9A
Réponse : 90 00
Le second appel, envoi le code instruction 0x10 correspondant à la fonction 'char* hello()' sans données supplémentaires
Commande : 0x80 0x10 0x00 0x00 0x00
Réponse : 48 65 6C 6C 6F 20 77 6F 72 6C 64 90 00
Le contenu de l'APDU de réponse contient les données envoyées par l'Applet suivies du code de retour qui a pour valeur 90 00. Celle-ci nous indique que la fonction a été exécutée sans problème. Les données sont composées d'une série d'octets contenant les 11 caractères de lachaîne de caractères 'Hello World'.
Voici un exemple de code renvoyant la chaine de caractères ‘Hello World from Java Card’ lors de l'appel à la Servlet.
Exemple de Servlet ‘Hello World’
Contenu du fichier .java
packageorg.carte.web;importjava.io.IOException;importjava.io.PrintWriter;importjavax.servlet.http.HttpServlet;importjavax.servlet.http.HttpServletRequest;importjavax.servlet.http.HttpServletResponse;publicclassHelloWorldWebextendsHttpServlet{@OverridepublicvoiddoGet(HttpServletRequestrequest,HttpServletResponseresponse)throwsIOException{response.setContentType("text/html");PrintWriterout=response.getWriter();try{out.println("<html><head><title>HelloWorldWeb</title></head>");out.println("<body><h1>HelloWorldWeb</h1>");out.println("Hello World from Java Card</body></html>");}finally{out.close();}}}
Contenu du fichier web.xml
<web-appxmlns="http://java.sun.com/xml/ns/j2ee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"version="2.4"xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/javacard/jcweb-app_3_0.xsd"><description>Thewebapplicationdeploymentdescriptorconveyswebapplicationmodelelementsandconfigurationinformationofanapplicationbetweenapplicationdevelopers,applicationassemblers,anddeployers.</description><display-name>HelloWorldWeb</display-name><servlet><servlet-name>HelloWorldWeb</servlet-name><servlet-class>org.carte.web.HelloWorldWeb</servlet-class></servlet><servlet-mapping><servlet-name>HelloWorldWeb</servlet-name><url-pattern>/helloworldweb</url-pattern></servlet-mapping></web-app>
L'appel de la Servlet se fait par l’intermédiaire d'un navigateur web en précisant l'URL suivante :
http://adresse_de_la_carte/helloworldweb
L'utilisation des Servlets sur une Java card se fait exactement de la même manière que sur une plate-forme JAVA EE.
Les producteurs de cartes à puces (tel queGemalto,Idemia...) implémentent les fonctionnalités de Java Card suivantes[46] :
L'utilisation du langage de programmation Java apporte un gain pour les développeurs d'applications[46] :
De nombreux types decartes à puce peuvent profiter de la technologie de Java Card[47]:
Sur la majorité de réseaux téléphoniques cellulaires, un abonné utilise unecarte à puce généralement appelée unecarte SIM pour activer le téléphone. La carte authentifie l'utilisateur et fournit desclés de chiffrement pour le transport de la voix numérique. lescartes SIM implémentées de la technologie de Java Card peuvent aussi fournir des services transactionnels bancaires à distance. Des centaines de millions decartes SIM basées sur la technologie de Java Card fonctionnent déjà avec des services innovants sur lestéléphones cellulaires.
Dans le secteur bancaire, lescartes à puce donnent l'accès sécurisé aux utilisateurs à une large gamme de services financiers incluant les distributeurs automatiques de billets, le paiement de factures et de péages. La technologie de Java Card permet à une seulecarte à puce d'héberger de multiples applications financières et de livrer des services tiers ou de sécuriser sur lecommerce en ligne.
De nombreuses applications sont disponibles dans les domaines où la sécurité et l'authentification sont importantes tel que l'accès sécurisé à des installations, dossiers médicaux.
La technologie de Java Card améliore l'accès grand public aux nouveaux services decommerce en ligne par l’intermédiaire d'appareils connectés. En effet, lestéléphones cellulaires 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 decarte à puce.
Acteurs du marché[48].
| Fabricant | Gamme de Produits |
|---|---|
| STMicroelectronics, Atmel, Infineon, Samsung, NXP, Inside Contactless | Semi-Conducteur et Micro-Processeur |
| Thales, IDEMIA, Safran Morpho, Giesecke & Devrient | Cartes |
| Ingenico, Verifone, Hypercom, Nokia | Terminaux et lecteurs |
| Orange, RATP, Véolia, BNP Paribas | Opérateur de services et e-Gouvernement |
| Trusted Logic, Prism, Multos | Logiciel embarqués OS et Applications |
| Cesti, Fime | Évaluation et Test |
| Experian, Atos Worldline, First Data, Sopra | Intégration et systèmes |
Chiffres
Selon le rapport gouvernemental «Dimension économique et industrielle des cartes à puces» de, le marché mondial des cartes à puces a dépassé les 5 milliards d'unités. (Source Nodal)[49].
| Apple |
| ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Dérivés deBeOS | |||||||||||
| DOS | |||||||||||
| IBM | |||||||||||
| Microsoft Windows |
| ||||||||||
| ReactOS Foundation |
| ||||||||||
| POSIX /Unix |
| ||||||||||
| Dérivés d'AmigaOS | |||||||||||
| Dérivés duTOS | |||||||||||
| D’importance historique | |||||||||||
| Mobile |
| ||||||||||
| Embarqués |
| ||||||||||
| Autres systèmes | |||||||||||
| Pour une liste complète, voir laliste des systèmes d’exploitation et lacatégorie « Système d’exploitation ». | |||||||||||
