Aller au contenu

Java Card

Un article de Wikipedia, l'encyclopedie libre.

Pour un article plus general, voir Systeme d'exploitation pour carte a puce.

Java Card est un systeme d'exploitation pour carte a puce qui fournit essentiellement un environnement d'execution pour un sous-ensemble du langage Java specifiquement destine aux applications pour carte a puce. Java Card permet l'execution d'applications au sein des cartes a puce, qui offrent des capacites de memoire et de traitement limitees. De multiples applications peuvent etre deployees avant et meme apres que la carte a puce a ete fournie a l'utilisateur final. Les applications ecrites dans le langage de programmation Java peuvent etre executees en toute securite sur l'ensemble des types de cartes disponibles sur le marche.

En 1996, les ingenieurs de la division carte de Schlumberger[1] au Texas (qui a fusionne plus tard avec Gemplus international pour former Gemalto) ont souhaite simplifier la programmation des cartes a puces tout en preservant la securite des donnees dans le respect de la norme ISO 7816.

La solution retenue fut le langage de programmation Java. En raison de la faible capacite memoire disponible sur une Carte a puce seulement un sous-ensemble de Java pouvait etre utilise. Ainsi fut cree Java Card 1.0 en , le premier langage oriente objet adapte aux cartes a puce.

, Schlumberger et Gemplus fondent Java Card Forum qui recommande des specifications a JavaSoft (la division de Sun a 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 developpement des applications pour les cartes a puce[1].

, les producteurs de Cartes a puce comme De La Rue, Bull , Giesecke & Devrient(G&D) rejoignent Java Card Forum qui edite une nouvelle version de specifications Java Card 2.0[1].

Par la suite, Sun editera alors quatre nouvelles specifications : en edition de Java Card 2.1[1], en Java Card 2.2, en Java Card 3.0 et enfin la plus recente Java Card 3.0.1 en [2].

La societe Oracle Corporation acquiert en l'entreprise Sun Microsystems.

Architecture

[modifier | modifier le code]

La carte a puce represente une des plates-formes informatiques les plus reduites[3]. Le plus grand defi de conception de la technologie de Java Card est d'embarquer le logiciel de base Java dans une carte a puce en conservant l'espace memoire necessaire pour stocker des applications. La solution retenue par Sun, issue des travaux de Schlumberger[1], est d'implementer un sous-ensemble des fonctionnalites du langage Java et d'appliquer un modele reduit de la JVM (Java Virtual Machine) appele JCVM (Java Card Virtual Machine)[3]. En plus de fournir le support de langage Java, la technologie de Java Card definit un environnement d'execution en temps reel qui supporte la memoire, la communication, la securite et le modele d'execution de l'application. Cet environnement respecte la norme standard ISO7816[4].

presentation architecture

La plate-forme Java Card est articulee autour[5] :

  • d'une machine virtuelle Java Card appelee JCVM[note 1] dont les specifications definissent les fonctionnalites mises en oeuvre par la technologie Java Card. Elles incluent le jeu d'instruction de la Machine Virtuelle Java Card, un sous-ensemble du langage Java et les formats de fichier utilises pour installer des applets et des bibliotheques dans des cartes a puce ou autres peripheriques qui hebergent la technologie de Java Card[6].
  • d'un environnement d'execution Java Card appele JCRE[note 2] constitue de composants systemes. La JCRE est responsable de la gestion des ressources des cartes a puces, des communications reseaux, de l'execution ainsi que la securite des Applets. La JCRE sert de systeme d'exploitation de la carte a puce, celui-ci s'appuie sur la couche materielle de carte a puce et du systeme natif[6].
  • d'un ensemble de librairies accessibles APIs[note 3], un sous ensemble du JCRE, contenant les definitions de classe requises pour supporter la JVCM et la JCRE. Il decrit les fonctions de bases utiles pour programmer des applications de cartes a puce[6].

La caracteristique la plus significative du JCRE est qu'il fournit une separation claire entre le systeme et les applications[6]. La technologie de Java Card definit une plate-forme sur laquelle les applications ecrites dans le langage de programmation Java peuvent fonctionner sur carte a puce et autres peripheriques avec memoire[6]. Les applications Java Card sont vues comme des applets[6] ou des servlets[7].

A partir de la version 3.0, editee par Sun en , a la suite des evolutions des cartes a puces, la plate-forme Java Card se decline en 2 versions[8].

Version Classique [9]
Cette version est une evolution de la version 2.2 et cible les systemes limites en ressources et qui supportent les applications basees sur les Applets. Elle apporte des correctifs et offre l'exploitation de nouveaux algorithmes de securite (Exemple support des cles RSA 4096 bits). De plus, un ajustement avec les recents standards des cartes <> a ete realise.
Version Connectee [9]
Cette version apporte un environnement ameliore d'execution et une nouvelle machine virtuelle. Une nouvelle architecture a ete concue pour transformer la carte a puce en element securise de reseau. La carte a puce peut alors fournir des services reseaux IP tels que serveur web HTTP, serveur web securise HTTPS, identification, acces aux ressources d'un reseau. Cette version cible des produits moins limites en ressources incluant de nouvelles fonctionnalites orientees reseau telles que les applications web, appelees servlet. Cette version integre les fonctionnalites de la version classique.
Schema de l'architecture

Version Java Card 2.x et Java Card 3 << classique >>

[modifier | modifier le code]

Java Card est donc l'adaptation de la technologie Java pour les cartes a puce. Les applets sont developpees dans le langage Java, elles sont ensuite transformees afin de satisfaire les contraintes de memoire, puis sont chargees dans la carte[3]. Une fois installe sur la plate-forme et selectionne, le bytecode[note 4], de l'applet est execute par la machine virtuelle embarquee JCVM[10].

Machine Virtuelle Java Card

[modifier | modifier le code]

La JCVM execute le bytecode, controle l'attribution de la memoire, gere les objets et met en application la securite pendant l'execution. La capacite des cartes a puces etant trop limite pour contenir toutes les informations des fichiers de classe Java, verificateur de code objet, la JVCM est donc implementee en deux parties distinctes (principale difference entre la JVM et la JCVM)[11] :

  • Une partie externe a la carte a puce[note 5], integrant le convertisseur et verificateur fonctionnant sur un PC[note 6] ou un poste de travail distant[11].
  • Une partie interne a la carte a puce[note 7] c'est-a-dire presente sur la carte qui inclut l'interpreteur de code Java Card[11].
Java Card Virtual Machine

Ensemble, ils implementent le chargement des fichiers de classe Java par l'intermediaire du verificateur et convertisseur pour enfin executer l'applet a l'aide de l'interpreteur.

le verificateur[12]
examine un ou plusieurs fichiers de classe contenant le bytecode, pour assurer qu'il respecte la syntaxe et les regles du langage et verifie statiquement que les flux de controle et de donnees ne produiront pas d'erreur lors de l'execution[13].
le convertisseur
charge les fichiers de classe verifies par le verificateur. Il produit un fichier CAP[note 8], (contenant une representation compacte d'un ou plusieurs fichiers Java compiles) correspondant a la conversion d'une applet[14].

En plus de la creation 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 definit le niveau d'acces et le nom d'une classe ainsi que le niveau d'acces et les signatures des methodes et champs de la classe. Un fichier d'exportation contient aussi des informations utilisees pour resoudre des jonctions de reference entre differentes applets sur la carte[10].

L'interpreteur de Java Card fournit le support d'execution du langage Java, il execute les taches suivantes[16] :

  • execute des instructions de code des applets ;
  • controle la creation d'objet et l'attribution de memoire ;
  • joue un role crucial dans l'assurance de la securite pendant l'execution.
gestion transfert fichier(s)

L'interpreteur de Java Card ne charge pas de fichier de classe ou fichier CAP, il en execute seulement le code[16]. Dans la technologie de Java Card, les mecanismes de telechargement et d'installation sont inclus dans une unite appelee l'installateur residant dans la carte a puce[16]. Il coopere avec un programme d'installation non-implemente sur la carte. Le programme d'installation transmet le(s) fichier(s) a l'installateur sur la carte via un dispositif d'acceptation de carte (CAD[note 10]). L'installateur ecrit le(s) fichier(s) dans la memoire de carte a puce pour etre lu avec les autres classes qui sont deja embarquees sur la carte. Il cree et initialise les structures de donnees qui sont utilisees par la JCRE.

Environnement d'execution Java Card

[modifier | modifier le code]

Le JCRE est responsable de la gestion des ressources de la carte, des communications reseaux, de l'execution et la securite des applets[17]. Il est implemente sur la carte a puce et sert essentiellement au systeme d'exploitation present sur la carte[17]. Le JCRE est compose de la JCVM, des APIs, d'extensions specifiques a une industrie[note 11]. et des systemes de classes[17].

JCRE Architecture

Le JCRE distingue les applets des proprietes techniques de la carte a puce. Il fournit le systeme standard et les APIs pour les applets. Celles-ci sont donc plus simples a ecrire et sont donc facilement portables sur differentes architectures de cartes a puce[17].

La couche inferieure du JCRE contient la JCVM et les methodes natives[note 12]. Elles fournissent le support a la JCVM et le systeme de classes pour la couche suivante. Le systeme de classes cadre le fonctionnement du JCRE[18] et son role est similaire a un systeme d'exploitation. Il est responsable :

de la gestion des transactions
mecanisme permettant de rendre un ensemble d'operations atomiques (ex : transaction bancaire)[19].
des communications avec le serveur CAD
La gestion des communications d'Applets, se fait via l'Application Protocol Data Unit (APDU)s dont la structure est definie par la norme ISO 7816[19].
du cycle de vie des applets
Le JCRE initialise l'applet apres son installation. Il peut selectionner alors l'applet pour lui signifier de s'executer, la de selectionner ou lui transmettre un signal APDU[19].

Le systeme de classes invoque les methodes natives[20]. Elles contiennent un ensemble de fonctions bas niveau qui permettent au JCRE de gerer les ressources physiques de la carte telles que les entrees-sorties, la gestion de la memoire ou le coprocesseur cryptographique. Ces methodes sont compilees en code executable dedie au processeur de la carte[17].

La structure de classes API definit les interfaces de programmation d'application, API[18]. L'avantage majeur est qu'elle rend plus facile la creation d'applet. Les developpeurs d'applet peuvent concentrer leurs efforts sur la programmation vis-a-vis des contraintes de l'infrastructure de systeme de carte a puce grace aux extensions d'API disponibles[20]. Les applets ont acces aux services JCRE par des classes API.

La structure extension specifique a une industrie fournit les bibliotheques complementaires de services supplementaires ou des modeles de systeme et de securite (ex : industries financieres)[18].

L'installateur permet le telechargement securise de logiciels et d'applets sur la carte apres que la carte a ete produite et fournie a l'utilisateur[18]. L'installateur interne coopere avec l'installateur externe a la carte. Ensemble, ils accomplissent la tache 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 les applets, devraient etre ecrits dans la memoire de la carte pendant le procede de fabrication[17].

L'interface de programmation d'application API disponible permet de developper des applications et fournir des services a ces applications[21] : Ces classes definissent les conventions selon lesquelles une Applet Java Card a acces au JCRE et aux fonctions natales, y compris la fonction de systeme d'exploitation, l'acces a la memoire et les operations d'entree-sortie. Les API utilisees par la carte sont :

java.io
est 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 Java Card du langage de programmation Java. Les classes fournies sont tirees de java.lang dans le langage de programmation Java standard et representent la fonction principale requise par la JVCM. Cette fonction principale est representee par la classe d'Objet, qui est la super-classe pour toutes les classes de langage Java et la classe Exception, qui est la super-classe pour l'exception et les classes d'exception pendant l'execution.
Java.rmi
definit l'interface a distance qui identifie les interfaces dont les methodes peuvent etre invoquees du peripherique de reception de carte (CAD) des applications client.
Javacard.framework
fournit une structure de classes et des interfaces pour la conception et la communication des applets, contient les fonctionnalites essentielles de fonctionnement avec Java Card.
Javacard.framework.service
fournit une structure de services de classes et d'interfaces qui permettent a une Applet de Java Card d'etre concue comme une liste de composants de services.
Javacard.security
fournit les classes et les interfaces qui contiennent la fonction disponible pour implementer une securite et une structure de cryptographie sur la Java Card. Les classes du paquet Javacard.security fournissent les definitions des algorithmes qui executent cette securite et les fonctions de cryptographie[22]
  1. Mises en oeuvre de cles de chiffrement differentes par la classe KeyBuilder ;
  2. Hachage des donnees par la classe MessageDigest ;
  3. Generation de donnees aleatoires par la classe RandomData ;
  4. Signature par la classe Signature ;
  5. Echanges de cle de session par la classe KeyAgreement.
Javacardx.crypto
contient la fonction qui implemente la securite et la structure de cryptographie sur la Java Card. C'est une extension du paquet precedent. Il contient la classe Cipher et l'interface KeyEncryption. Cipher est une classe qui fournit des methodes pour chiffrer et dechiffrer des messages[23]. KeyEncryption est une interface qui fournit la fonction qui permet aux cles d'etre mises a jour d'une facon continue securisee.

Version Java Card 3 << Connectee >>

[modifier | modifier le code]

La version 3 << Connectee >> des specifications de la plateforme Java Card presente des differences profondes avec les autres versions existantes.

Tout d'abord, alors que les versions anterieures ne pouvaient charger que des fichiers binaires specifiques (les fichiers CAP), les applications Java Card 3 << Connectees >> sont deployees sous forme de fichiers java compiles de facon conventionnelle (des fichiers .class) regroupes dans des fichiers .jar, a l'instar des machines virtuelles java conventionnelles[24]. Il n'est alors plus necessaire d'avoir recours a des outils de conversions de code.

Par ailleurs Java Card 3 << Connectee >> privilegie le mode de communication de l'internet : les protocoles internet via norme IP ISO 7816-4 pour les interfaces << avec contacts >>. La norme ISO 14443 est elle utilisee pour les interfaces <>[9]. Les applications Java Card 3 << Connectees >> sont en fait, des Servlets, c'est-a-dire de veritables Services Web, qui respectent, a ce titre, le protocole HTTP.

La machine virtuelle Java Card 3 est basee sur le CLDC[note 13] largement utilise dans le monde de la telephonie mobile[25]. Cette plate-forme donne acces aux fonctionnalites les plus riches du langage JAVA[9]. La plate-forme CLDC a ete reduite en taille, les protocoles et les systemes securites de cartes a puce ont ete integres[9].

Evolution des peripheriques supportant la technologie Java Card[26]

Diagramme appel mode connecte (utilisation Http)
Carte a puce traditionnelle Carte a puce recente 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

Amelioration apportee par la version 3 connectee[24].

  • Applications de type servlets[24].
  • Gestion de multitaches (Multithreading)[24].
  • Verification par byte code interne[24](Verification de.class par la machine virtuelle interne).
  • Ramasse Miette automatique (Garbage collector) inclut dans la machine virtuelle[24].
  • Ajout des types Char, Long et String[24].
  • Tableau multidimensionnel[27].
  • Classe representant les types primitifs (Boolean, Integer,...)[27],[28]
  • Classe de la manipulation de Chaines de caracteres (StringBuilder...)[27],[29].
  • Classe pour la gestion des Entrees/Sorties (Reader, Writer et Stream)[27].
  • Classe pour la gestion du reseau[27].
  • Classe pour la gestion des collections (Vector, hashtable...)[27].
  • Classe pour la gestion des dates[27].
  • Classe pour la gestion de la localisation et de l'internationalisation[27].
  • Le langage de programmation a ete etoffe de specificites issues de Java SE[27] :
Specificites
Generics[30]
Metadonnees
Autoboxing[31]
Amelioration de la boucle for
Assert (test unitaire)
Enumeration[32]
Utilisation de methodes a argument Variables[31]
Import static[33]

Limitation du moteur de servlet de java card V3[34]

Liste des principales caracteristiques presentes dans les specifications Java Serlet 2.4[35] qui ne sont pas supportees par la plate-forme Java Card V3.

  • API non supportees (java.io.File, java.net.URL, java.util.Map, java.util.Set, java.security.cert.X509Certificate...). Par exemple, il est impossible d'effacer un fichier avec la methode delete de la classe java.io.File, impossible d'utiliser la structure hashmap, impossible d'utiliser la gestion des certificats X509 (RFC 2459[36]).
  • Nombre flottant (float). Il est impossible de realiser des operations sur des nombres a virgules.
  • Serialisation et clonage d'objets (java.io.Serializable, java.lang.Cloneable). Il impossible de convertir les objets en flux binaire pour gerer persistance. Il est impossible de creer de nouvelles instances a partir d'une reference d'objet (clone).
  • Support des Java Server Pages V2.0. Les balises JSP ne sont pas reconnues, donc obligation d'ecrire des servlets en Java.
  • Java Naming and Directory Interface. Pas d'acces aux classes de gestion d'annuaires.

Securite des applications Java Card

[modifier | modifier le code]

La gestion de la securite developpee pour les cartes a puce est implementee par la JCVM qui fournit les regles de securite suivantes[37] :

  • Chaque JCVM contient une fonction verificateur dont le role est de verifier les fichiers Java compiles (.class) issue d'un compilateur java. Cependant sur la plate-forme Java Card version 3, il est possible de charger directement des fichiers de classes sans passer par le verificateur et le convertisseur.
  • La fonction securite de la JCRE met en application des pare-feu pour isoler chaque applet ou servlet, ce qui empeche l'acces non autorise d'objets crees par une autre applet.
  • Tous les acces aux methodes et variables dans un fichier de classe se font par accesseurs[note 14]. Ces accesseurs definissent un controle de coherence du type primitif pour chaque methode. Il est possible de declarer une methode << public >>, << protected >> (accessibles par des methodes dans la meme sous-classe ou << package >>) ou << private >> (aucun acces par d'autres classes). Si aucune declaration n'est faite, la methode peut etre accessible par n'importe quelle classe dans le meme paquet.

Au-dela de la verification de code objet implementee par la JCVM, la plate-forme de Java Card 3 implemente des mecanismes de securite qui fournissent le niveau d'application et la securite des communications[38].

La plate-forme de Java Card supporte un mecanisme d'isolement de code. L'isolement de code assure que le code charge 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 crees, donc en possession d'applications fonctionnant dans un meme contexte, ne peuvent pas etre accedes par des applications d'un autre contexte a moins que ces applications possedant ces objets ne fournissent explicitement des interfaces pour l'acces. De telles interfaces sont appelees des interfaces en commun et des objets implementant ces interfaces, appeles commun interface objets, constituent des points d'entree legaux a ces applications[39].

La securite a base de roles permet a la politique de securite d'une application de limiter l'acces aux ressources protegees de l'application. Les restrictions sont basees sur les caracteristiques de l'application demandant l'acces, comme son identite et l'identite de l'utilisateur sur lequel la defense d'acces est demandee[39].

L'authentification de l'utilisateur est le processus par lequel un utilisateur prouve son identite a la carte. Cette identite authentifiee est alors utilisee par la plate-forme pour executer des decisions d'autorisation, comme celles requises par la securite a base de roles, pour avoir acces aux ressources protegees[40].

L'authentification d'application client est le processus par lequel une application cliente prouve son identite a une application serveuse. Cette identite authentifiee est alors utilisee par l'application serveuse pour executer des decisions d'autorisation dans le but d'avoir acces aux ressources protegees[40].

Avec la plate-forme java Card, les applications peuvent interagir avec des applications a distance par des communications de reseaux securisees (TLS, SSL)[41].

Un developpeur d'application Web peut declarer des prerequis pour l'integrite et la confidentialite lors du deploiement d'une application Web. Le developpeur d'application ou le fournisseur peut aussi exiger que l'on heberge l'application sur un port securise dedie avec des connexions HTTPS ouvertes[41].

La plate-forme Java Card supporte une structure de cryptographie. Un developpeur d'application ou un fournisseur peut choisir l'algorithme de cryptographie qui repond le mieux aux besoins de son application [42].

Concept de programmation

[modifier | modifier le code]

Principe de programmation d'une Applet

[modifier | modifier le code]

Un Applet Java Card respecte la norme ISO 7816. C'est-a-dire qu'elle repond a des requetes de la meme maniere qu'elle les recoit sous la forme de commandes en byte codes. Ceci simplifie considerablement le developpement d'une application, car il n'y a plus besoin de coder en bas niveau l'envoi et la reception des commandes. En effet cette partie est maintenant encapsulee dans un framework java.

Les commandes en byte code sont appelees des APDU (Application Protocol Data Unit). Celles-ci sont codees differemment en fonction de l'envoi et de la reception[43].

Une commande APDU telle qu'elle est envoyee depuis le lecteur a la carte Java est une serie de cinq octets eventuellement suivis d'un nombre variable d'octets, formates comme suit :

Format d'une commande APDU.
CLA
CLA est le nom du premier octet, dit octet de classe, defini par la norme ISO 7816, indiquant le numero de commande[43].
INS
INS est le nom du second octet, dit octet d'instruction[43].
P1
P1 est le nom du troisieme octet, dit octet de parametre 1[43].
P2
P2 est le nom du quatrieme octet, dit octet de parametre 2[43].
Ln
Ln est le nom du cinquieme octet, il indique le nombre d'octets de donnees qui vont suivre (qu'elles soient envoyees ou recues, 0x00 indiquant qu'aucune donnee additionnelle ne suivra)[43].
Donnees
Ce sont les donnees, au nombre de Ln, qui sont transmises par le lecteur a la carte. Si l'application embarquee prevoit seulement une transmission en sens inverse, aucune donnee n'est transmise ici[43].
Le
Le est le dernier octet apres les donnees indiquant la taille maximale des donnees pour la reponse[43].

Une reponse APDU telle qu'elle est envoyee depuis la carte Java au lecteur, est une serie d'octets, retournee en reponse a une commande et formatee comme suit :

Format d'une reponse APDU.
Donnees
Ce sont les donnees, au nombre de Le, qui sont envoyees par la carte au lecteur[43].
Statut
statut renvoye par la carte, code sur deux octets nommes : SW1 et SW2.
SW1
le premier octet, appele SW1 indique le type de reponse. La valeur hexadecimale une valeur entre 0x90 et 0x9F indique que la commande a ete correctement executee. Une valeur entre 0x60 et 0x6F indique que la commande n'a pas pu etre executee par le programme place dans la carte[43].
SW2
le second octet, appele SW2 rapporte eventuellement des informations supplementaires concernant la reponse[43].

Lorsque la commande au niveau de l'applet s'execute normalement, la valeur du statut renvoye correspond a 90 00.

Si une instruction INS prevoit a la fois d'envoyer et de recevoir des donnees, Java Card normalise un systeme d'APDU en deux phases. Dans un premier temps, l'APDU est envoyee avec pour un nombre d'octets a envoyer, puis lorsque la carte repond 0x91 (indiquant que octets sont prets a etre retournes par la carte, en reponse a la commande) une APDU Get Response est transmise pour declencher la reception de ces octets sortants[43].

En resume, le champ de donnee(s) est optionnel dans les deux cas, APDU de commande et APDU de reponse. Par consequent, 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.1 Classic Edition) :

Cas 1 APDU de commande sans donnee APDU de reponse sans donnee
Cas 2 APDU de commande avec donnee(s) APDU de reponse sans donnee
Cas 3 APDU de commande sans donnee APDU de reponse avec donnee(s)
Cas 4 APDU de commande avec donnee(s) APDU de reponse avec donnee(s)
Format de l'identifiant d'application.

Avant de pouvoir transmettre une commande a une Applet deployee dans une Java Card, il est necessaire de la selectionner par l'envoi d'une commande APDU specifique en precisant l'identifiant de l'application AID[note 16]. L'identifiant d'application est compose de deux parties. La premiere sur 5 octets, le RID[note 17], est assigne par la norme ISO. Celui-ci correspond a l'identifiant propre a l'entreprise. Le second, PIX[note 18] est quant a lui compose entre 0 et 11 octets. L'assignation de celui-ci reste a la charge de l'entreprise qui developpe l'application Java Card[44].

Pour la programmation d'une Java Card, il y a cinq etapes importantes :

  • Ecriture du code Java source ;
  • Compilation du code ;
  • Conversion des fichiers .class en .cap ;
  • Verification du fichier .cap (optionnel) ;
  • Installation du fichier .cap dans la Java Card.

Le point fort du developpement Java Card est que les deux premieres etapes peuvent etre realisees avec un environnement de developpement JAVA classique.

Voici un exemple de code renvoyant tout simplement la chaine de caracteres 'Hello World' sur la demande liee a l'instruction 0x10. Dans cet exemple le AID est compose des valeurs de RID = DA8EF6DD26 et de PIX = 86E899.

Exemple d'applet 'Hello World'[45].

import javacard.framework.*;

public class HelloWorld extends Applet {

// Initialisation de la variable avec 'H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd'.
private final static byte[] message = { 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64 };

public static void install(byte[] bArray, short bOffset, byte bLength) { new HelloWorld(); }

protected HelloWorld() { register(); }

public void process(APDU apdu) {
if (selectingApplet()) {
// Retourne le statut a OK
return;
}
byte[] buffer = apdu.getBuffer() ;
if ( buffer[ISO7816.OFFSET_CLA] != (byte)(0x80) )
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED); // Retourne le status word CLA NOT SUPPORTED
switch(buffer[ISO7816.OFFSET_INS]) {
case 0x10 :
// Copie du contenu du message dans le buffer de la reponse
Util.arrayCopy(message, (byte)0, buffer, ISO7816.OFFSET_CDATA, (byte)message.length);
// Envoi de la reponse
apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, (byte)message.length);
break;
default:
// Retourne le statut a la valeur INS NOT SUPPORTED
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
}
}
Diagramme d'appel de l'exemple

Pour cet exemple, deux echanges d'APDU sont necessaires entre le client et la Java Card : Le premier envoi correspond a la selection de l'application en precisant l'AID :

Commande : 0x00 0xA4 0x04 0x00 0X08 0XDA 0X8E 0XF6 0XDD 0X26 0X86 0XE8 0X9A

Reponse : 90 00

Le second appel, envoi le code instruction 0x10 correspondant a la fonction 'char* hello()' sans donnees supplementaires

Commande : 0x80 0x10 0x00 0x00 0x00

Reponse : 48 65 6C 6C 6F 20 77 6F 72 6C 64 90 00

Le contenu de l'APDU de reponse contient les donnees envoyees par l'Applet suivies du code de retour qui a pour valeur 90 00. Celle-ci nous indique que la fonction a ete executee sans probleme. Les donnees sont composees d'une serie d'octets contenant les 11 caracteres de la chaine de caracteres 'Hello World'.

Principe de programmation d'une Servlet

[modifier | modifier le code]

Voici un exemple de code renvoyant la chaine de caracteres 'Hello World from Java Card' lors de l'appel a la Servlet.

Exemple de Servlet 'Hello World'

Contenu du fichier .java

package org.carte.web;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloWorldWeb extends HttpServlet {

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
try {
out.println("HelloWorldWeb");
out.println("

HelloWorldWeb

");
out.println("Hello World from Java Card");
} finally {
out.close();
}
}
}

Contenu du fichier web.xml

xmlns="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">
The web application deployment descriptor conveys web application model
elements and configuration information of an application between application
developers, application assemblers, and deployers.

Hello World Web

HelloWorldWeb
org.carte.web.HelloWorldWeb


HelloWorldWeb
/helloworldweb


L'appel de la Servlet se fait par l'intermediaire d'un navigateur web en precisant l'URL suivante :

http://adresse_de_la_carte/helloworldweb

L'utilisation des Servlets sur une Java card se fait exactement de la meme maniere que sur une plate-forme JAVA EE.

Les producteurs de cartes a puces (tel que Gemalto, Idemia...) implementent les fonctionnalites de Java Card suivantes[46] :

  • Interoperabilite : les Applets developpees avec la technologie Java Card fonctionnent sur n'importe quel type de cartes a puce (et independamment du materiel sous-jacent).
  • Securite : la technologie de Java Card repose sur la securite du langage de programmation Java pour fournir un environnement d'execution securise.
  • Possibilite d'applications multiples[note 19] : la technologie de Java Card permet a de multiples applications de cohabiter en securite sur une seule carte a puce.
  • Dynamique : de nouvelles applications peuvent etre installees en toute securite apres qu'une carte a ete fournie a l'utilisateur, permettant aux producteurs de carte de repondre dynamiquement aux besoins de changement de leur client.
  • Compatible avec les normes existantes : l'API de Carte Java est compatible avec les standards internationaux pour Carte a puce comme ISO7816 ou Europay Mastercard Visa :

L'utilisation du langage de programmation Java apporte un gain pour les developpeurs d'applications[46] :

  • La programmation orientee objet apporte une plus grande modularite du code et sa reutilisation, augmentant la productivite du programmeur.
  • La protection figurant dans les caracteristiques du langage de programmation Java s'applique aux applets de Java Card, mettant en application des attributs de protection et de typage fort.

De nombreux types de cartes a puce peuvent profiter de la technologie de Java Card[47]:

  • Carte SIM (Subcriber Identity Module) utilisee dans les telephones cellulaire sur les reseaux sans fil.
  • Carte bancaire.
  • Carte d'identite.
  • Carte sante.
  • Les cartes qui fournissent l'acces logique et physique aux ressources d'entreprises.

Sur la majorite de reseaux telephoniques cellulaires, un abonne utilise une carte a puce generalement appelee une carte SIM pour activer le telephone. La carte authentifie l'utilisateur et fournit des cles de chiffrement pour le transport de la voix numerique. les cartes SIM implementees de la technologie de Java Card peuvent aussi fournir des services transactionnels bancaires a distance. Des centaines de millions de cartes SIM basees sur la technologie de Java Card fonctionnent deja avec des services innovants sur les telephones cellulaires.

Dans le secteur bancaire, les cartes a puce donnent l'acces securise aux utilisateurs a une large gamme de services financiers incluant les distributeurs automatiques de billets, le paiement de factures et de peages. La technologie de Java Card permet a une seule carte a puce d'heberger de multiples applications financieres et de livrer des services tiers ou de securiser sur le commerce en ligne.

De nombreuses applications sont disponibles dans les domaines ou la securite et l'authentification sont importantes tel que l'acces securise a des installations, dossiers medicaux.

La technologie de Java Card ameliore l'acces grand public aux nouveaux services de commerce en ligne par l'intermediaire d'appareils connectes. En effet, les telephones cellulaires et les equipements de television pour chaines payantes sont les exemples de marches ou la majorite de produits, deja disponibles, incluent deja des lecteurs de carte a puce.

Acteurs du marche[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, Veolia, BNP Paribas Operateur de services et e-Gouvernement
Trusted Logic, Prism, Multos Logiciel embarques OS et Applications
Cesti, Fime Evaluation et Test
Experian, Atos Worldline, First Data, Sopra Integration et systemes

Chiffres

Selon le rapport gouvernemental <> de , le marche mondial des cartes a puces a depasse les 5 milliards d'unites. (Source Nodal)[49].

  • AID (Application IDentifier) : une chaine de caracteres utilisee comme identifiant unique des Applets de la carte a puce selon la norme ISO 7816
  • APDU : Abreviation pour Application Protocol Data Units defini selon la norme ISO 7816-4.
  • APPLET : un composant simple d'une application Java Card qui s'execute dans l'environnement APDU.
  • APPLET ETENDU: Dans le contexte Java Card, Une Applet etendu possede les fonctionnalites de la version connectee. (Exemple : Manipulation de Chaine de caractere).
  • Conteneur d'Applet : Mecanisme qui manage le cycle de vie des Applets. Dans le contexte Java Card, le conteneur fournit les services de communication sur lesquels les commandes d'APDU et des reponses sont envoyes.
  • Ramasse Miette automatique (Garbage collector) : Mecanisme qui libere automatiquement la memoire utilise par des objets qui ne sont plus utilises par l'application. (Uniquement disponible dans la version 3 connectee).
  • SERVLET : Un composant generant dynamiquement du contenu web s'executant au sein d'une application web.

Notes et references

[modifier | modifier le code]
  1. | qui est nommee dans la litterature scientifique anglo-saxonne Java Card Virtual Machine
  2. | qui est nomme dans la litterature scientifique anglo-saxonne Java Card Runtime Environment
  3. | qui sont nommees dans la litterature scientifique anglo-saxonne Application Programmer Interface
  4. | bytecode ou code binaire intermediaire en francais inclus dans les fichiers de classe (extension .class ).
  5. | qui est nomme dans la litterature scientifique anglo-saxonne Off-Card
  6. | qui est nomme dans la litterature scientifique anglo-saxonne Private Computer, <> en francais.
  7. | qui est nomme dans la litterature scientifique anglo-saxonne On-Card
  8. | qui est nomme dans la litterature scientifique anglo-saxonne CAP file (Converted APplet)
  9. | qui est nomme dans la litterature scientifique anglo-saxonne Export File
  10. | qui est nomme dans la litterature scientifique anglo-saxonne Card Acceptance Device
  11. | qui est nommee dans la litterature scientifique anglo-saxonne industry-specific extensions
  12. | methodes de bases qui sont nommees dans la litterature scientifique anglo-saxonne natives method
  13. | qui est nommee dans la litterature scientifique anglo-saxonne Connected Limited Device Configuration
  14. | . Un accesseur est une methode permettant de recuperer le contenu d'une donnee membre protegee
  15. | contexte : Un service de nom associe des noms avec des objets. Une association entre un nom et un objet est appelee une attache et des jeux d'attaches sont appeles un contexte. Un nom dans un contexte peut devoir necessairement un autre contexte qui utilise les memes conventions de nommage ; le contexte attache est appele un sous-contexte.
  16. | Application IDentifiant Identifiant d'application en francais
  17. | Ressource IDentifier Identifiant de la ressource en francais
  18. | Proprietary IDentifier extension extension de l'identifiant proprietaire en francais
  19. | qui est nomme dans la litterature scientifique anglo-saxonne Application multi capability.
  1. | a b c d et e Baentsch 1999, p. 37
  2. | Oracle : Specifications des versions
  3. | a b et c Zhiqun 2000, p. 29
  4. | ISO7816
  5. | Oracle : Chapitre Composants
  6. | a b c d e et f Zhiqun 2000, p. 30
  7. | Sun 2008, p. 7
  8. | Sun 2008, p. 1
  9. | a b c d et e Sun 2008, p. 2
  10. | a et b Zhiqun 2000, p. 34
  11. | a b et c Zhiqun 2000, p. 31
  12. | Oracle 2002, p. 1
  13. | Casset 2002, p. 209
  14. | Zhiqun 2000, p. 32
  15. | Zhiqun 2000, p. 33
  16. | a b et c Zhiqun 2000, p. 35
  17. | a b c d e et f Zhiqun 2000, p. 36
  18. | a b c et d Zhiqun 2000, p. 37
  19. | a b et c Dufay,2003, p.28
  20. | a et b Zhiqun 2000, p. 38
  21. | Gemalto : Chapitre APIs
  22. | Sun 2002, p. 147
  23. | Ghindici 2006, p. 6
  24. | a b c d e f et g Sun 2008, p. 5
  25. | Sun CLDC : Introduction
  26. | Sun 2008, p. 4
  27. | a b c d e f g h et i Sun 2008, p. 6
  28. | Type utilise dans la programmation Java
  29. | Classe StringBuilder
  30. | Types generiques du langage Java
  31. | a et b Autoboxing en Java
  32. | Enumeration du langage Java
  33. | Import statique du langage Java
  34. | Java Servlet Specification : Java Card Platform, Version 3.0.1 Connected Edition, p. 3-1
  35. | Java Servlet V2.4
  36. | (en) << Internet X.509 Public Key Infrastructure / Certificate and CRL Profile >>, Request for comments no 2459,
  37. | Gemalto : Chapitre securite
  38. | Sun 2008, p. 13
  39. | a b et c Sun 2008, p. 14
  40. | a et b Sun 2008, p. 16
  41. | a et b Sun 2008, p. 17
  42. | Sun 2008, p. 19
  43. | a b c d e f g h i j k et l ISO : norme ISO7816-4
  44. | ISO : norme ISO7816-5
  45. | Gemalto 2009, p. 19
  46. | a et b Oracle : Chapitre benefices
  47. | Oracle : Chapitre Industries
  48. | Dimension economique et industrielle des cartes a puces, p. 29
  49. | Dimension economique et industrielle des cartes a puces, p. 19

Bibliographie

[modifier | modifier le code]
  • (en) Zhiqun Chen, Java Card Technology for Smart Cards : Architecture and Programmer's Guide, Addison Wesley, (lire en ligne)
  • (en) M. Baentsch, P. Buhler, T. Eirich, F. Horing et M. Oestreiche, << JavaCard-from hype to reality >>, IEEE Concurrency, vol. 7, no 4, , p. 36-43 (ISSN 1092-3063, DOI 10.1109/4434.806977)
    Secure Syst. Group, IBM Res. Div. Zurich
  • (en) L. Casset et JL. Lanet, << Increasing smart card dependability >>, ACM, , p. 209 - 212 (DOI 10.1145/1133373.1133416)
    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 >>, ACM Computing Surveys (CSUR), vol. 33, no 4, , p. 517-558 (ISSN 0360-0300, e-ISSN 1557-7341, DOI 10.1145/503112.503115)
  • (en) Dorina Ghindici, Gilles Grimaud et Isabelle Simplot-Ryl, << Embedding verifiable information flow analysis >>, ACM Computing Surveys (CSUR), , p. 1-9 (ISBN 1-59593-604-1, DOI 10.1145/1501434.1501481)
  • Guillaume Dufay, Verification formelle de la plate-forme Java Card, (lire en ligne)
  • (en) Java Card(tm) 2.2 Application Programming Interface : Revision 1.1 for the 2.2_01 Release, 901 San Antonio Road Palo Alto, CA 94303 USA, Sun Microsystems, Inc, , 2.2_01 ed., 278 p. (lire en ligne)
  • (en) THE JAVA CARD(tm) 3 PLATFORM, 901 San Antonio Road Palo Alto, CA 94303 USA, Sun Microsystems, Inc, , 34 p. (lire en ligne)
  • (en) Gemalto, Java Card(tm) & STK Applet Development Guidelines : version 2, , WG.GGS.4.0042 ed., 53 p. (lire en ligne)
  • (en) Oracle, Java Card 2.2 Off-Card Verifier : version 2.2, 901 San Antonio Road Palo Alto, CA 94303 USA, , 24 p. (lire en ligne)
  • (en) Java(tm) Servlet Specification : Java Card(tm) Platform, Version 3.0.1 Connected Edition, 901 San Antonio Road Palo Alto, CA 94303 USA, Sun Microsystems, Inc, , 162 p.
  • (en) ISO7816-4 Cartes d'identification -- Cartes a circuit integre : Partie 4 : Organisation, securite et commandes pour les echanges, , 2e ed.
  • Dimension economique et industrielle des cartes a puces, www.industrie.gouv.fr, , 1re ed. (lire en ligne), p. 74

Liens externes

[modifier | modifier le code]
v * m
Apple
Mac OS Classic
Derives de NeXTSTEP
Derives de BeOS
DOS
IBM
Microsoft Windows
Fondes sur MS-DOS
Branche NT
ReactOS Foundation
Branche NT (GPL/LGPL/AGPL) non-Microsoft
POSIX / Unix
AT&T / Laboratoires Bell
BSD
GNU Hurd
Linux (liste)
Autres derives
Derives d'AmigaOS
Derives du TOS
D'importance historique
Mobile
Noyau Linux
Autres noyaux
Embarques
Pour capteur en reseau
Pour carte a puce
Temps reel
Autres systemes
Pour une liste complete, voir la liste des systemes d'exploitation et la categorie << Systeme d'exploitation >>.