Février 1997, Schlumberger et Gemplus 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 les cartes à puce.
juin 2002 Java Card 2.2, en janvier 2010 l'entreprise Sun Microsystems.
La carte à puce représente une des plates-formes informatiques les plus réduites. 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, 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). 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.
présentation architecture
La plate-forme Java Card est articulée autour :
- d’une machine virtuelle Java Card appelée JCVM dont les spécifications définissent les fonctionnalités mises en œuvre 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 utilisés 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.
- d’un environnement d’exécution Java Card appelé JCRE constitué de composants systèmes. La JCRE est responsable de la gestion des ressources des cartes à puces, des communications réseaux, de l'exécution ainsi que la sécurité des Applets. La JCRE sert de système d'exploitation de la carte à puce, celui-ci s'appuie sur la couche matérielle de carte à puce et du système natif.
- d’un ensemble de librairies accessibles APIs, un sous ensemble du JCRE, contenant 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 cartes à puce.
La caractéristique la plus significative du JCRE est qu'il fournit une séparation claire entre le système et les applications. 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. Les applications Java Card sont vues comme des applets ou des servlets.
À partir de la version 3.0, éditée par Sun en
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.
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.
- INS
- INS est le nom du second octet, dit octet d’instruction.
- P1
- P1 est le nom du troisième octet, dit octet de paramètre 1.
- P2
- P2 est le nom du quatrième octet, dit octet de paramètre 2.
- 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).
- 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.
- Le
- Le est le dernier octet après les données indiquant la taille maximale des données pour la réponse.
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.
- 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.
- SW2
- le second octet, appelé SW2 rapporte éventuellement des informations supplémentaires concernant la réponse.
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.
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) :
| 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) |
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. L’identifiant d’application est composé de deux parties. La première sur 5 octets, le RID, est assigné par la norme ISO. Celui-ci correspond à l’identifiant propre à l’entreprise. Le second, PIX 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.
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’.
Contenu du fichier web.xml
L'appel de la Servlet se fait par l’intermédiaire d'un navigateur web en précisant l'URL suivante :
5 milliards d'unités. (Source Nodal).- AID (Application IDentifier) : une chaine de caractères utilisée comme identifiant unique des Applets de la carte à puce selon la norme ISO 7816
- APDU : Abréviation pour Application Protocol Data Units défini selon la norme ISO 7816-4.
- APPLET : un composant simple d'une application Java Card qui s'exécute dans l’environnement APDU.
- APPLET ETENDU: Dans le contexte Java Card, Une Applet étendu possède les fonctionnalités de la version connectée. (Exemple : Manipulation de Chaine de caractère).
- Conteneur d'Applet : Mécanisme 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 réponses sont envoyés.
- Ramasse Miette automatique (Garbage collector) : Mécanisme qui libère automatiquement la mémoire utilisé par des objets qui ne sont plus utilisés par l'application. (Uniquement disponible dans la version 3 connectée).
- SERVLET : Un composant générant dynamiquement du contenu web s’exécutant au sein d'une application web.
- (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, n 4, 2001, p. 517-558 (ISSN 0360-0300, e-ISSN 1557-7341, DOI 10.1145/503112.503115)
- (en) Java Card™ 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, 2002, 2.2_01 éd., 278 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, 2002, 24 p. (lire en ligne)
- (en) « Oracle Javacard Overview »
- (en) « Oracle Java Card Spécifications »
- (en) « Oracle Java Card Industries »
- (en) « Type utilisé dans la programmation Java »
- (en) « Autoboxing en Java »
- (en) « Import statique du langage Java »
| Mac OS Classic | |
|---|---|
| Dérivés de NeXTSTEP |
| Fondés sur MS-DOS | |
|---|---|
| Branche NT |
| Branche NT (GPL/LGPL/AGPL) non-Microsoft |
|---|
| AT&T / Laboratoires Bell | |
|---|---|
| BSD | |
| GNU Hurd | |
| Linux (liste) | |
| Autres dérivés |
| Noyau Linux | |
|---|---|
| Autres noyaux |
| Pour capteur en réseau | |
|---|---|
| Pour carte à puce | |
| Temps réel |
| View original on Wikipedia | Back | FazBrowse Home |