Java Card

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 la carte[3]. Une fois installé sur la plate-forme et sélectionné, le bytecode[note 4], de l'applet est exécuté par la machine virtuelle embarquée JCVM[10].

La JCVM exécute le bytecode, 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 de code objet, la JVCM est donc implémentée en deux parties distinctes (principale différence entre la JVM et la JCVM)[11] :

• Une partie externe à la carte à puce[note 5], intégrant le convertisseur et vérificateur fonctionnant sur un PC[note 6] ou un poste de travail distant[11].
• Une partie interne à la carte à puce[note 7] c'est-à-dire présente sur la carte qui inclut l’interpréteur de code Java Card[11].

Java Card Virtual Machine

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.

le vérificateur[12]

examine un ou plusieurs fichiers de classe contenant le bytecode, pour assurer qu'il respecte la syntaxe et les règles du langage et vérifie statiquement que les flux de contrôle et de données ne produiront pas d'erreur lors de l’exécution[13].

le convertisseur

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

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] :

• 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.

gestion transfert fichier(s)

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].

JCRE Architecture

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 :

de la gestion des transactions

mécanisme permettant de rendre un ensemble d’opérations 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 définie par la norme ISO 7816[19].

du cycle de vie des applets

Le JCRE initialise l'applet après son installation. Il peut sélectionner alors l'applet pour lui signifier de s’exécuter, la dé sélectionner ou lui transmettre un signal APDU[19].

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 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[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 les applets, devraient être écrits dans la mémoire de la carte pendant le procédé de fabrication[17].

L’interface de programmation d'application API 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 :

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 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 Exception, 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 les interfaces dont les méthodes peuvent être invoquées du périphérique de réception 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 fonctionnalités essentielles de fonctionnement avec Java Card.

Javacard.framework.service

fournit une structure de services de classes et d’interfaces qui permettent à une Applet de Java Card d'être conçue comme une liste de composants de services.

Javacard.security

fournit les classes et les interfaces qui contiennent la fonction disponible pour implémenter une sécurité et une structure de cryptographie sur la Java Card. Les classes du paquet Javacard.security fournissent les définitions des algorithmes qui exécutent cette sécurité et les fonctions de cryptographie[22]

1. Mises en œuvre de clés de chiffrement différentes par la classe KeyBuilder ;
2. Hachage des données par la classe MessageDigest ;
3. Génération de données aléatoires par la classe RandomData ;
4. Signature par la classe Signature ;
5. Échanges de clé de session par la classe KeyAgreement.

Javacardx.crypto

contient la fonction qui implémente la sécurité et la structure de cryptographie sur la Java Card. C'est une extension du paquet précédent. Il contient la classe Cipher et l'interface KeyEncryption. Cipher est une classe qui fournit des méthodes pour chiffrer et déchiffrer des messages[23]. KeyEncryption est une interface qui fournit la fonction qui permet aux clés d'être mises à jour d'une façon continue sécurisée.

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 des fichiers 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 : les protocoles 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, des Servlets, c'est-à-dire de véritables Services Web, qui respectent, à ce titre, le protocole HTTP.

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]

Diagramme appel mode connecté (utilisation Http)

Amélioration apportée par la version 3 connectée[24].

• Applications de type servlets[24].
• Gestion de multitâches (Multithreading)[24].
• Vérification par byte code interne[24](Vérification 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 représentant les types primitifs (Boolean, Integer,…)[27] - [28]
• Classe de la manipulation de Chaines de caractères (StringBuilder…)[27] - [29].
• Classe pour la gestion des Entrées/Sorties (Reader, Writer et Stream)[27].
• Classe pour la gestion du réseau[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 été étoffé de spécificités issues de Java SE[27] :

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.

• API non supportées (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 méthode 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 réaliser des opérations sur des nombres à virgules.
• Sérialisation et clonage d'objets (java.io.Serializable, java.lang.Cloneable). Il impossible de convertir les objets en flux binaire pour gérer persistance. Il est impossible de créer de nouvelles instances à partir d'une référence d'objet (clone).
• Support des Java Server Pages V2.0. Les balises JSP ne sont pas reconnues, donc obligation d'écrire des servlets en Java.
• Java Naming and Directory Interface. Pas d’accès aux classes de gestion d'annuaires.

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 un framework 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 :

Format d'une commande APDU.

CLA

CLA est le nom du premier octet, dit octet de classe, défini par la norme ISO 7816, indiquant le numéro de commande[43].

INS

INS est le nom du second octet, dit octet d’instruction[43].

P1

P1 est le nom du troisième octet, dit octet de paramètre 1[43].

P2

P2 est le nom du quatrième octet, dit octet de paramètre 2[43].

Ln

Ln est le nom du cinquième octet, il indique le nombre d'octets de données qui vont suivre (qu'elles soient envoyées ou reçues, 0x00 indiquant qu'aucune donnée additionnelle ne suivra)[43].

Données

Ce sont les données, au nombre de Ln, qui sont transmises par le lecteur à la carte. Si l'application embarquée prévoit seulement une transmission en sens inverse, aucune donnée n'est transmise ici[43].

Le

Le est le dernier octet après les données indiquant la taille maximale des données pour la réponse[43].

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 :

Format d'une réponse APDU.

Données

Ce sont les données, au nombre de Le, qui sont envoyées par la carte au lecteur[43].

Statut

statut renvoyé par la carte, codé sur deux octets nommés : SW1 et SW2.

SW1

le premier octet, appelé SW1 indique le type de réponse. La valeur hexadécimale une valeur entre 0x90 et 0x9F indique que la commande a été correctement exécutée. Une valeur entre 0x60 et 0x6F indique que la commande n'a pas pu être exécutée par le programme placé dans la carte[43].

SW2

le second octet, appelé SW2 rapporte éventuellement des informations supplémentaires concernant la réponse[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 APDU Get 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.1 Classic Edition) :

Format de l'identifiant d'application.

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’application AID[note 16]. L’identifiant d’application est composé de deux parties. La première sur 5 octets, le RID[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 :

• Écriture du code Java source ;
• Compilation du code ;
• Conversion des fichiers .class en .cap ;
• Vérification du fichier .cap (optionnel) ;
• Installation du fichier .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’instruction 0x10. Dans cet exemple le AID est composé 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 status à 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 réponse
                apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, (byte)message.length);
                break;
            default:
                // Retourne le status à la valeur INS NOT SUPPORTED
                ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
        }
    }
}

Diagramme d'appel de l'exemple

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 la chaî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

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("<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-app 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">
    <description>The web application deployment descriptor conveys web application model
elements and configuration information of an application between application
developers, application assemblers, and deployers.
    </description>
    <display-name>Hello World Web</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.

• (en) « Spécifications de Java Card Version 3.0.1 »
• (en) « Oracle Javacard Overview »
• (en) « Organisation internationale de normalisation »
• (en) « Gemalto Java Card™ »
• (en) « Oracle Java Card Spécifications »
• (en) « Classic_Features Java Card Release Note »
• (en) « Oracle Java Card 2.2.2 », mars 2006
• (en) « Oracle Java Card Industries »
• (en) « Sun CLDC »
• (en) « Java Servlet V2.4 »
• (en) « Type utilisé dans la programmation Java »
• (en) « Classe StringBuilder »
• (en) « Types génériques du langage Java »
• (en) « Autoboxing en Java »
• (en) « Énumération du langage Java »
• (en) « Méthodes à arguments multiples du langage Java »
• (en) « Import statique du langage Java »