Voir la source de Java Card

{{Article général|Système d'exploitation pour carte à puce}}
{{Plate-forme Java}}
'''Java Card''' est un [[système d'exploitation pour carte à puce]] qui fournit essentiellement un [[environnement d'exécution]] pour un sous-ensemble du langage [[Java (langage)|Java]] spécifiquement destiné aux applications pour [[carte à 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 la [[carte à puce]] a été fournie à l'utilisateur final. Les applications écrites dans le [[langage de programmation]] Java peuvent être exécutées en toute sécurité sur l’ensemble des types de cartes disponibles sur le marché.

== Historique ==
En 1996, les ingénieurs de la division carte de [[Schlumberger (entreprise)|Schlumberger]]<ref name="havsp Baentsch p37"/> au [[Texas]] (qui a fusionné plus tard avec [[Gemplus international]] pour former [[Gemalto]]) ont souhaité simplifier la programmation des cartes à puces tout en préservant la [[sécurité des données]] dans le respect de la norme ISO 7816.

La solution retenue fut le langage de programmation [[Java (langage)|Java]]. En raison de la faible capacité mémoire disponible sur une [[Carte à puce]] seulement un sous-ensemble de [[Java (langage)|Java]] pouvait être utilisé. Ainsi fut créé Java Card 1.0 en {{date-|novembre 1996}}, le premier langage orienté objet adapté aux cartes à puce.

{{date-|Février 1997}}, [[Schlumberger (entreprise)|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]]<ref name="havsp Baentsch p37"/>.

{{date-|Novembre 1997}}, les producteurs de Cartes à puce comme [[De La Rue]], [[Bull (entreprise)|Bull]]
, [[Giesecke & Devrient|Giesecke & Devrient(G&D)]] rejoignent Java Card Forum qui édite une nouvelle version de spécifications Java Card 2.0<ref name="havsp Baentsch p37"/>.

Par la suite, Sun éditera alors quatre nouvelles spécifications : en {{date-|mars 1999}} édition de Java Card 2.1<ref name="havsp Baentsch p37"/>, en {{date-|juin 2002}} Java Card 2.2, en {{date-|mars 2008}} Java Card 3.0 et enfin la plus récente Java Card 3.0.1 en {{date-|mai 2009}}<ref>[[#oracle_spécifications|Oracle : Spécifications des versions]]</ref>.

La société [[Oracle Corporation]] acquiert en {{date-|janvier 2010}} l'entreprise [[Sun Microsystems]].

== Architecture ==
La carte à puce représente une des plates-formes informatiques les plus réduites<ref name=Chen2000_29>{{harvsp|Zhiqun|2000|p=29|id=Chen2000}}</ref>. Le plus grand défi de conception de la technologie de Java Card est d'embarquer le logiciel de base [[Java (langage)|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<ref name="havsp Baentsch p37">{{harvsp|Baentsch|1999|p=37|id=Baentsch1999}}</ref>, est d’implémenter un sous-ensemble des fonctionnalités du langage [[Java (langage)|Java]] et d’appliquer un modèle réduit de la JVM (''Java Virtual Machine'') appelé JCVM (''Java Card Virtual Machine'')<ref name=Chen2000_29/>.
En plus de fournir le support de langage [[Java (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<ref>[[#ISO7816|ISO7816]]</ref>.

[[Fichier:SCO présentation architecture.jpg|vignette|300px|présentation architecture]]
La plate-forme Java Card est articulée autour<ref>[[#Oracle|Oracle : Chapitre Composants]]</ref> :
* d’une [[machine virtuelle Java]] Card appelée JCVM<ref group=note>qui est nommée dans la littérature scientifique anglo-saxonne ''Java Card Virtual Machine''</ref> 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 (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<ref name=Chen2000_30/>.
* d’un environnement d’exécution Java Card appelé JCRE<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Java Card Runtime Environment''</ref> 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<ref name=Chen2000_30/>.
* d’un ensemble de librairies accessibles APIs<ref group=note>qui sont nommées dans la littérature scientifique anglo-saxonne ''Application Programmer Interface''</ref>, 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<ref name=Chen2000_30/>.

La caractéristique la plus significative du JCRE est qu'il fournit une séparation claire entre le système et les applications<ref name=Chen2000_30>{{harvsp|Zhiqun|2000|p=30|id=Chen2000}}</ref>.
La technologie de Java Card définit une plate-forme sur laquelle les applications écrites dans le langage de programmation [[Java (langage)|Java]] peuvent fonctionner sur carte à puce et autres périphériques avec mémoire<ref name=Chen2000_30/>.
Les applications Java Card sont vues comme des [[Applet Java|applets]]<ref name=Chen2000_30/> ou des [[servlet]]s<ref name="havsp Sun White Paper 7">{{harvsp| Sun |2008|p=7|id= SUN_PLATFORM }}</ref>.

À partir de la version 3.0, éditée par Sun en {{date-|mars 2008}}, à la suite des évolutions des cartes à puces, la plate-forme Java Card se décline en 2 versions<ref name="havsp Sun White Paper 1">{{harvsp| Sun |2008|p=1|id= SUN_PLATFORM }}</ref>.

;Version Classique <ref name="havsp Sun White Paper 2">{{harvsp| Sun |2008|p=2|id= SUN_PLATFORM }}</ref>:Cette version est une évolution de la version 2.2 et cible les systèmes limités en ressources et qui supportent les applications basées sur les Applets. Elle apporte des correctifs et offre l’exploitation de nouveaux algorithmes de sécurité (Exemple support des clés RSA 4096 bits). De plus, un ajustement avec les récents standards des cartes «sans contact» a été réalisé.

;Version Connectée <ref name="havsp Sun White Paper 2"/> : Cette version apporte un environnement amélioré d’exécution et une nouvelle machine virtuelle. Une nouvelle architecture a été conçue pour transformer la carte à puce en élément sécurisé de réseau. La carte à puce peut alors fournir des services réseaux IP tels que [[serveur web]] HTTP, serveur web sécurisé HTTPS, identification, accès aux ressources d'un réseau. Cette version cible des produits moins limités en ressources incluant de nouvelles fonctionnalités orientées réseau telles que les [[Application web|applications web]], appelées [[servlet]]. Cette version intègre les fonctionnalités de la version classique.

[[Fichier:Architecture Java card Platform V3.png|centré|550px|vignette|Schéma de l'architecture]]

=== Version Java Card 2.x et Java Card 3 « classique » ===
Java Card est donc l'adaptation de la technologie [[Java (technique)|Java]] pour les [[cartes à puce]]. Les [[Applet Java|applets]] sont développées dans le langage [[Java (langage)|Java]], elles sont ensuite transformées afin de satisfaire les contraintes de mémoire, puis sont chargées dans la carte<ref name=Chen2000_29/>. Une fois installé sur la plate-forme et sélectionné, le [[Bytecode Java|''bytecode'']]<ref group=note>''bytecode'' ou code binaire intermédiaire en français inclus dans les fichiers de classe (extension .class ).</ref>, de l'applet est exécuté par la machine virtuelle embarquée JCVM<ref name=Chen2000_34>{{harvsp|Zhiqun|2000|p=34|id=Chen2000}}</ref>.
==== Machine Virtuelle Java Card ====
La JCVM exécute le [[Bytecode Java|''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)<ref name=Chen2000_31>{{harvsp|Zhiqun|2000|p=31|id=Chen2000}}</ref> :
* Une partie externe à la [[carte à puce]]<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Off-Card''</ref>, intégrant le convertisseur et vérificateur fonctionnant sur un [[Ordinateur personnel|PC]]<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Private Computer'', «Ordinateur personnel» en français.</ref> ou un poste de travail distant<ref name=Chen2000_31/>.
* Une partie interne à la [[carte à puce]]<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''On-Card''</ref> c'est-à-dire présente sur la carte qui inclut l’interpréteur de code Java Card<ref name=Chen2000_31/>.
[[Fichier:SCO-JCVM.jpg|vignette|400px|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<ref name="havsp Oracle 1">{{harvsp| Oracle |2002|p=1|id= Oracle_OCV }}</ref> : examine un ou plusieurs fichiers de classe contenant le [[Bytecode Java|''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<ref>{{harvsp|Casset|2002|p=209|id=Casset2002}}</ref>.

;le convertisseur : charge les fichiers de classe vérifiés par le vérificateur. Il produit un fichier CAP<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''CAP file'' ('''C'''onverted '''AP'''plet)</ref>, (contenant une représentation compacte d'un ou plusieurs fichiers Java compilés) correspondant à la conversion d’une applet<ref name=Chen2000_32>{{harvsp|Zhiqun|2000|p=32|id=Chen2000}}</ref>.

En plus de la création d'un fichier CAP, le convertisseur produit un fichier d'exportation<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Export File''</ref> contenant des informations API publiques pour un ou plusieurs fichiers de classe<ref name=Chen2000_33>{{harvsp|Zhiqun|2000|p=33|id=Chen2000}}</ref>.
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<ref name=Chen2000_34/>.

L’interpréteur de Java Card fournit le support d'exécution du langage Java, il exécute les tâches suivantes<ref name=Chen2000_35>{{harvsp|Zhiqun|2000|p=35|id=Chen2000}}</ref> :
* exécute des instructions de code des [[Applet Java|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.
[[Fichier:SCO gestion CAD.jpg|vignette|400px|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<ref name=Chen2000_35/>. 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<ref name=Chen2000_35/>. 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<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Card Acceptance
Device''</ref>). 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.

==== Environnement d'exécution Java Card ====
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<ref name=Chen2000_36>{{harvsp|Zhiqun|2000|p=36|id=Chen2000}}</ref>. Il est implémenté sur la carte à puce et sert essentiellement au système d'exploitation présent sur la carte<ref name=Chen2000_36/>.
Le JCRE est composé de la JCVM, des APIs, d'extensions spécifiques à une industrie<ref group=note>qui est nommée dans la littérature scientifique anglo-saxonne ''industry-specific extensions''</ref>. et des systèmes de classes<ref name=Chen2000_36/>.
[[Fichier:SCO-architecture.jpg|vignette|400px|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<ref name=Chen2000_36/>.

La couche inférieure du JCRE contient la JCVM et les méthodes natives<ref group=note>méthodes de bases qui sont nommées dans la littérature scientifique anglo-saxonne ''natives method''</ref>. 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<ref name=Chen2000_37>{{harvsp|Zhiqun|2000|p=37|id=Chen2000}}</ref> 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)<ref name="Dufay 2003 p28">[[#Dufay|Dufay,2003]], p.28</ref>.
;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<ref name="Dufay 2003 p28"/>.
;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<ref name="Dufay 2003 p28"/>.

Le système de classes invoque les méthodes natives<ref name=Chen2000_38>{{harvsp|Zhiqun|2000|p=38|id=Chen2000}}</ref>. 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<ref name=Chen2000_36/>.

La structure de classes API définit les interfaces de programmation d'application, [[Interface de programmation|API]]<ref name=Chen2000_37/>. 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<ref name=Chen2000_38/>. 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)<ref name=Chen2000_37/>.

L'installateur permet le téléchargement sécurisé de logiciels et d’[[applet]]s sur la carte après que la carte a été produite et fournie à l'utilisateur<ref name=Chen2000_37/>. 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 [[applet]]s, devraient être écrits dans la mémoire de la carte pendant le procédé de fabrication<ref name=Chen2000_36/>.

==== API ====
L’interface de programmation d'application [[Interface de programmation|API]] disponible permet de développer des applications et fournir des services à ces applications<ref>[[#Gemalto|Gemalto : Chapitre APIs]]</ref> :
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 (langage)|Java]] standard.
;Java.lang : fournit les fondamentaux pour la conception du sous-ensemble de technologie de Java Card du langage de programmation [[Java (langage)|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 (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<ref name="SUN API">{{harvsp|Sun|2002|p=147|id=SUN_API}}</ref>
::# Mises en œuvre de clés de chiffrement différentes par la classe KeyBuilder ;
::# Hachage des données par la classe MessageDigest ;
::# Génération de données aléatoires par la classe RandomData ;
::# Signature par la classe Signature ;
::# É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<ref name="havsp Ghindici 6">{{harvsp| Ghindici |2006|p=6|id= Ghindici }}</ref>. 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.

=== Version Java Card 3 « Connecté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 [[Fichier binaire|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 <code>.class</code>) regroupés dans des fichiers <code>.jar</code>, à l'instar des machines virtuelles java conventionnelles<ref name="havsp Sun White Paper 5"/>. 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 [[Internet Protocol|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»<ref name="havsp Sun White Paper 2"/>. Les applications Java Card 3 « Connectées » sont en fait, des [[Servlet]]s, c'est-à-dire de véritables [[Service Web|Services Web]], qui respectent, à ce titre, le protocole [[Hypertext Transfer Protocol|HTTP]].

La machine virtuelle Java Card 3 est basée sur le CLDC<ref group=note>qui est nommée dans la littérature scientifique anglo-saxonne ''Connected Limited Device Configuration ''</ref> largement utilisé dans le monde de la téléphonie mobile<ref>[[#Sun_CLDC|Sun CLDC : Introduction]]</ref>. Cette plate-forme donne accès aux fonctionnalités les plus riches du langage JAVA<ref name="havsp Sun White Paper 2"/>. 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<ref name="havsp Sun White Paper 2"/>.

Évolution des périphériques supportant la technologie Java Card<ref name="havsp Sun White Paper 4">{{harvsp| Sun |2008|p=4|id= SUN_PLATFORM }}</ref>
[[Fichier:Diagramme_mode_connecte_JavaCard.png|vignette|450px|Diagramme appel mode connecté (utilisation Http)]]

{|class="wikitable"
|-
!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'''<ref name="havsp Sun White Paper 5">{{harvsp| Sun |2008|p=5|id= SUN_PLATFORM }}</ref>.
* Applications de type [[servlet]]s<ref name="havsp Sun White Paper 5"/>.
* Gestion de multitâches (Multithreading)<ref name="havsp Sun White Paper 5"/>.
* Vérification par byte code interne<ref name="havsp Sun White Paper 5"/>(Vérification de.class par la machine virtuelle interne).
* Ramasse Miette automatique (Garbage collector) inclut dans la machine virtuelle<ref name="havsp Sun White Paper 5"/>.
* Ajout des types Char, Long et String<ref name="havsp Sun White Paper 5"/>.
* Tableau multidimensionnel<ref name="havsp Sun White Paper 6">{{harvsp| Sun |2008|p=6|id= SUN_PLATFORM }}</ref>.
* Classe représentant les types primitifs (Boolean, Integer,…)<ref name="havsp Sun White Paper 6"/>{{,}}<ref>[[#Type_Java|Type utilisé dans la programmation Java]]</ref>
* Classe de la manipulation de Chaines de caractères (StringBuilder…)<ref name="havsp Sun White Paper 6"/>{{,}}<ref>[[#StringBuilder|Classe StringBuilder]]</ref>.
* Classe pour la gestion des Entrées/Sorties (Reader, Writer et Stream)<ref name="havsp Sun White Paper 6"/>.
* Classe pour la gestion du réseau<ref name="havsp Sun White Paper 6"/>.
* Classe pour la gestion des collections (Vector, hashtable…)<ref name="havsp Sun White Paper 6"/>.
* Classe pour la gestion des dates<ref name="havsp Sun White Paper 6"/>.
* Classe pour la gestion de la localisation et de l’internationalisation<ref name="havsp Sun White Paper 6"/>.
* Le langage de programmation a été étoffé de spécificités issues de Java SE<ref name="havsp Sun White Paper 6"/> :

{|class="wikitable alternance left"
 | '''Spécificités'''
 |-
 | Générics<ref>[[#Generics|Types génériques du langage Java]]</ref>
 |-
 | Métadonnées
 |-
 | Autoboxing<ref name="Autoboxing">[[#Autoboxing|Autoboxing en Java]]</ref>
 |-
 | Amélioration de la boucle for
 |-
 | Assert ([[test unitaire]])
 |-
 | Énumération<ref>[[#Enumération|Énumération du langage Java]]</ref>
 |-
 | Utilisation de méthodes à argument Variables<ref name="Autoboxing"/>
 |-
 | Import static<ref>[[#Static_Imports|Import statique du langage Java]]</ref>
 |}

'''Limitation du moteur de servlet de java card V3'''<ref name=SUN_SERVET>{{harvsp||Java Servlet Specification : Java Card Platform, Version 3.0.1 Connected Edition|p=3-1|id=SUN_SERVLET}}</ref>

Liste des principales caractéristiques présentes dans les spécifications Java Serlet 2.4<ref>[[#Servlet_2_4|Java Servlet V2.4]]</ref> 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|titre=Internet X.509 Public Key Infrastructure / Certificate and CRL Profile|date=janvier 1999}}).
* 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.

== Sécurité des applications Java Card ==
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<ref>[[#Gemalto|Gemalto : Chapitre sécurité]]</ref> :
* Chaque JCVM contient une fonction vérificateur dont le rôle est de vérifier les fichiers Java compilés (.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 vérificateur et le convertisseur.
* La fonction sécurité de la JCRE met en application des pare-feu pour isoler chaque applet ou servlet, ce qui empêche l'accès non autorisé d'objets créés par une autre applet.
* Tous les accès aux méthodes et variables dans un fichier de classe se font par accesseurs<ref group=note>. Un accesseur est une méthode permettant de récupérer le contenu d'une donnée membre protégée</ref>. Ces accesseurs définissent un contrôle de cohérence du type primitif pour chaque méthode. Il est possible de déclarer une méthode « public », « protected » (accessibles par des méthodes dans la même sous-classe ou « package ») ou « private » (aucun accès par d'autres classes). Si aucune déclaration n'est faite, la méthode peut être accessible par n'importe quelle classe dans le même paquet.

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<ref name="Sun 13">{{harvsp|Sun|2008|id=SUN_PLATFORM|p=13}}</ref>.

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<ref name="Sun 14">{{harvsp|Sun|2008|id=SUN_PLATFORM|p=14}}</ref>.

La plate-forme de Java Card supporte l'isolement de contexte<ref group=note>contexte :  Un service de nom associe des noms avec des objets. Une association entre un nom et un objet est appelée une attache et des jeux d'attaches sont appelés un contexte. Un nom dans un contexte peut devoir nécessairement un autre contexte qui utilise les mêmes conventions de nommage ; le contexte attaché est appelé un sous-contexte.</ref> 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és ''commun interface objets'', constituent des points d'entrée légaux à ces applications<ref name="Sun 14"/>.

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<ref name="Sun 14"/>.

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<ref name="Sun 16">{{harvsp|Sun|2008|id=SUN_PLATFORM|p=16}}</ref>.

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<ref name="Sun 16"/>.

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)<ref name="Sun 17">{{harvsp|Sun|2008|id=SUN_PLATFORM|p=17}}</ref>.

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<ref name="Sun 17"/>.

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
<ref name="Sun 19">{{harvsp|Sun|2008|id=SUN_PLATFORM|p=19}}</ref>.

== Concept de programmation ==

=== Principe de programmation d'une Applet ===

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<ref name="ISO 7816-4" />.

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 :
[[Fichier:APDU de commande.gif|vignette|droite|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<ref name="ISO 7816-4">[[#ISO7816|ISO : norme ISO7816-4]]</ref>.
; INS : INS est le nom du second octet, dit octet d’instruction<ref name="ISO 7816-4"/>.
; P1 : P1 est le nom du troisième octet, dit octet de paramètre 1<ref name="ISO 7816-4"/>.
; P2 : P2 est le nom du quatrième octet, dit octet de paramètre 2<ref name="ISO 7816-4"/>.
; 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)<ref name="ISO 7816-4"/>.
; 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<ref name="ISO 7816-4"/>.
; Le : Le est le dernier octet après les données indiquant la taille maximale des données pour la réponse<ref name="ISO 7816-4"/>.

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 :
[[Fichier:ADPU_Réponse.png|vignette|droite|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<ref name="ISO 7816-4"/>.
; 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 <code>0x90</code> et <code>0x9F</code> indique que la commande a été correctement exécutée. Une valeur entre <code>0x60</code> et <code>0x6F</code> indique que la commande n'a pas pu être exécutée par le programme placé dans la carte<ref name="ISO 7816-4"/>.
; SW2 : le second octet, appelé SW2 rapporte éventuellement des informations supplémentaires concernant la réponse<ref name="ISO 7816-4"/>.

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<ref name="ISO 7816-4"/>.

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) :
{| class="wikitable"
|-
| 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)
|}

[[Fichier:AID_identification_d'application.png|vignette|droite|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'''<ref group=note>''Application IDentifiant'' Identifiant d'application en français</ref>. L’identifiant d’application est composé de deux parties. La première sur 5 octets, le '''RID'''<ref group=note>''Ressource IDentifier'' Identifiant de la ressource en français</ref>, est assigné par la norme ISO. Celui-ci correspond à l’identifiant propre à l’entreprise. Le second, '''PIX'''<ref group=note>''Proprietary IDentifier extension'' extension de l'identifiant propriétaire en français</ref> 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<ref>[[#ISO7816|ISO : norme ISO7816-5]]</ref>.

Pour la programmation d’une Java Card, il y a cinq étapes importantes :
* Écriture du code Java source ;
* Compilation du code ;
* Conversion des fichiers <code>.class</code> en <code>.cap</code> ;
* Vérification du fichier <code>.cap</code> (optionnel) ;
* Installation du fichier <code>.cap</code> 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’'''<ref name="Gemalto 19">{{harvsp|Gemalto|2009|id=Gemalto_developper
|p=19}}</ref>.

<syntaxhighlight lang="java">
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);
        }
    }
}
</syntaxhighlight>

[[Fichier:Diagramme_appels_JavaCard.png|vignette|droite|upright=2|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'.

=== Principe de programmation d'une Servlet ===
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
<syntaxhighlight lang="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();
        }
    }
}
</syntaxhighlight>

Contenu du fichier web.xml
<syntaxhighlight lang="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>
</syntaxhighlight>

L'appel de la Servlet se fait par l’intermédiaire d'un navigateur web en précisant l'URL suivante :
<pre>http://adresse_de_la_carte/helloworldweb</pre>
L'utilisation des Servlets sur une Java card se fait exactement de la même manière que sur une plate-forme JAVA EE.

== Intérêts ==
Les producteurs de cartes à puces (tel que [[Gemalto]], [[Idemia]]...) implémentent les fonctionnalités de Java Card suivantes<ref name="Oracle">[[#Oracle|Oracle : Chapitre bénéfices]]</ref> :
* Interopérabilité : les Applets développées avec la technologie Java Card fonctionnent sur n'importe quel type de cartes à puce (et indépendamment du matériel sous-jacent).
* Sécurité : la technologie de Java Card repose sur la sécurité du langage de programmation Java pour fournir un environnement d'exécution sécurisé.
* Possibilité d'applications multiples<ref group=note>qui est nommé dans la littérature scientifique anglo-saxonne ''Application multi capability''.</ref> : la technologie de Java Card permet à de multiples applications de cohabiter en sécurité sur une seule carte à puce.
* Dynamique : de nouvelles applications peuvent être installées en toute sécurité après qu'une carte a été fournie à l'utilisateur, permettant aux producteurs de carte de répondre dynamiquement aux besoins de changement de leur client.
* Compatible avec les normes existantes : l'API de Carte Java est compatible avec les standards internationaux pour [[Carte à puce]] comme ISO7816 ou [[Europay Mastercard Visa]] :

L'utilisation du langage de programmation Java apporte un gain pour les développeurs d'applications<ref name="Oracle"/> :
* La [[programmation orientée objet]] apporte une plus grande modularité du code et sa réutilisation, augmentant la productivité du programmeur.
* La protection figurant dans les caractéristiques du langage de programmation Java s'applique aux applets de Java Card, mettant en application des attributs de protection et de typage fort.

== Marché ==
De nombreux types de [[carte à puce|cartes à puce]] peuvent profiter de la technologie de Java Card<ref>[[#oracle_overview|Oracle : Chapitre Industries]]</ref>:
* [[Carte SIM]] (Subcriber Identity Module) utilisée dans les téléphones cellulaire sur les réseaux sans fil.
* Carte bancaire.
* Carte d'identité.
* Carte santé.
* Les cartes qui fournissent l'accès logique et physique aux ressources d'entreprises.

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

Dans le secteur bancaire, les [[cartes à 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 seule [[carte à puce]] d'héberger de multiples applications financières et de livrer des services tiers ou de sécuriser sur le [[Commerce électronique|commerce 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 de [[commerce en ligne]] par l’intermédiaire d'appareils connectés. En effet, les [[Téléphonie mobile|té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 de [[carte à puce]].

'''Acteurs du marché'''<ref name=Marche1>{{harvsp||Dimension économique et industrielle des cartes à puces|p=29|id=Marche}}</ref>.

{| class="wikitable"
|-
! 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 {{date-|novembre 2009}}, le marché mondial des cartes à puces a dépassé les {{Unité|5|milliards d'unités}}. (Source Nodal)<ref name=Marche2>{{harvsp||Dimension économique et industrielle des cartes à puces|p=19|id=Marche}}</ref>.

== Glossaire ==

* '''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.

== Notes et références ==

=== Notes ===
{{Références|groupe=note}}

=== Références ===
{{Références|colonnes=4}}

== Bibliographie ==
* {{Ouvrage
    | id            = Chen2000
    | langue        = en
    | prénom1       = Zhiqun
    | nom1          = Chen
    | titre         = Java Card Technology for Smart Cards : Architecture and Programmer's Guide
    | éditeur       = Addison Wesley
    | lien éditeur  = Addison–Wesley
    | jour          = 18
    | mois          = septembre
    | année         = 2000
    | pages totales = <!-- à renseigner -->
    | isbn          = <!-- à renseigner -->
    | lire en ligne = http://java.sun.com/developer/Books/consumerproducts/javacard/
   }}
* {{article | lang = en | id = Baentsch1999 | prénom1 = M. | nom1 = Baentsch | prénom2 = P. | nom2 = Buhler | prénom3 = T. | nom3 = Eirich | prénom4 = F. | nom4 = Horing | prénom5 = M. | nom5 = Oestreiche | titre = JavaCard-from hype to reality | périodique = IEEE Concurrency | volume = 7 | numéro = 4 | issn = 1092-3063 | année = 1999 | mois = octobre-décembre | pages = 36-43 | doi = 10.1109/4434.806977 | commentaire = Secure Syst. Group, IBM Res. Div. Zurich }}
* {{article | lang = en | id = Casset2002 | prénom1 = L. | nom1 = Casset | prénom2 = JL. | nom2 = Lanet | titre = Increasing smart card dependability | périodique = ACM | année = 2002 | pages = 209 - 212 | doi = 10.1145/1133373.1133416 | commentaire = EW 10 Proceedings of the 10th workshop on ACM SIGOPS European workshop }}
* {{article | lang = en | id = Hartel2001 | prénom1 = P.H. | nom1 = Hartel | prénom2 = L. | nom2 = Moreau | titre = Formalizing the safety of Java, the Java virtual machine, and Java card | périodique = ACM Computing Surveys (CSUR)| volume = 33 | numéro=4 | issn = 0360-0300 | e-issn = 1557-7341 | année = 2001 |  pages = 517-558| doi = 10.1145/503112.503115 }}
* {{article | lang = en | id = Ghindici | prénom1 = Dorina | nom1 = Ghindici | prénom2 = Gilles | nom2 = Grimaud | prénom3 = Isabelle | nom3 = Simplot-Ryl | titre = Embedding verifiable information flow analysis | périodique = ACM Computing Surveys (CSUR)| isbn = 1-59593-604-1 |année = 2006 |  pages = 1-9| doi = 10.1145/1501434.1501481 }}
* {{Ouvrage
| langue=fr
| prénom1=Guillaume
| nom1=Dufay
| titre=Vérification formelle de la plate-forme Java Card
| éditeur=
| année=2003
| isbn=
| lire en ligne=http://www.irisa.fr/lande/gdufay/these-gdufay.pdf
| id=Dufay
}}
* {{Ouvrage
| langue=en
| prénom1=Sun
| titre=Java Card™ 2.2 Application Programming Interface
| sous-titre=Revision 1.1 for the 2.2_01 Release
| lieu=901 San Antonio Road Palo Alto, CA 94303 USA
| éditeur=Sun Microsystems, Inc
| année=2002
| numéro d'édition=2.2_01
| pages totales=278
| isbn=
| lire en ligne=http://java.sun.com/j2se/javadoc/mifdoclet/samples/JavaCard22API.pdf
| id=SUN_API
}}
* {{Ouvrage
| langue=en
| prénom1=Sun
| titre=THE JAVA CARD™ 3 PLATFORM
| lieu=901 San Antonio Road Palo Alto, CA 94303 USA
| éditeur=Sun Microsystems, Inc
| année=2008
| pages totales=34
| isbn=
| lire en ligne=http://java.sun.com/javacard/3.0/javacard3_whitepaper.pdf
| id=SUN_PLATFORM
}}
* {{Ouvrage
| langue=en
| nom1=Gemalto
| titre=Java Card™ & STK Applet Development Guidelines
| sous-titre=version 2
| éditeur=
| année=2009
| numéro d'édition=WG.GGS.4.0042
| pages totales=53
| isbn=
| lire en ligne=http://developer.gemalto.com/fileadmin/contrib/downloads/pdf/Java%20Card%20%26%20STK%20Applet%20Development%20Guidelines.pdf
| id=Gemalto_developper
}}
* {{Ouvrage
| langue=en
| nom1=Oracle
| titre=Java Card 2.2 Off-Card Verifier
| sous-titre=version 2.2
| lieu=901 San Antonio Road Palo Alto, CA 94303 USA
| éditeur=
| année=2002
| pages totales=24
| isbn=
| lire en ligne=http://www.oracle.com/technetwork/java/javacard/offcardverifierwp-150021.pdf
| id=Oracle_OCV
}}
* {{Ouvrage
| langue=en
| prénom1=Sun
| titre=Java™ Servlet Specification
| sous-titre=Java Card™ Platform, Version 3.0.1 Connected Edition
| lieu=901 San Antonio Road Palo Alto, CA 94303 USA
| éditeur=Sun Microsystems, Inc
| année=2009
| pages totales=162
| isbn=
| id=SUN_SERVLET
}}
* {{Ouvrage
| langue=en
| prénom1=Iso
| titre=ISO7816-4 Cartes d'identification -- Cartes à circuit intégré
| sous-titre=Partie 4 : Organisation, sécurité et commandes pour les échanges
| éditeur=
| année=2005
| numéro d'édition=2
| isbn=
| id=ISO7816-4
}}
* {{Ouvrage
| langue=fr
| titre=Dimension économique et industrielle des cartes à puces
| éditeur=www.industrie.gouv.fr
| année=2009
| numéro d'édition=1
| passage=74
| isbn=
| lire en ligne=http://www.industrie.gouv.fr/p3e/etudes/cartes_puces/cartes_puces.pdf
| id=Marche
}}

== Voir aussi ==
* [[Système d'exploitation pour carte à puce]]

=== Liens externes ===
* {{Lien web|langue=en |id=JavaCard3.0.1 | url = http://java.sun.com/javacard/3.0.1/specs.jsp | titre =Spécifications de Java Card Version 3.0.1}}
* {{Lien web|langue=en |id=Oracle | url = http://www.oracle.com/technetwork/java/javacard/overview/overview-jsp-135353.html| titre =Oracle Javacard Overview }}
* {{Lien web|langue=en |id=ISO7816 | lang=en | url= http://www.iso.org/iso/fr/search.htm?qt=7816&searchSubmit=Rechercher&sort=rel&type=simple&published=true | titre= Organisation internationale de normalisation}}
* {{Lien web|langue=en |id=Gemalto | url = http://developer.gemalto.com/home/technology/java-card.html| titre = Gemalto Java Card™}}
* {{Lien web|langue=en |id=oracle_spécifications | url = http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javame-419430.html#java_card_kit-3.0.1-rr-spec-oth-JPR| titre = Oracle Java Card Spécifications }}
* {{Lien web|langue=en |id=oracle_features | url=http://www.oracle.com/technetwork/java/javacard/releasenotes-jsp-137685.html#Classic_Features Java Card Release Note | titre= Classic_Features Java Card Release Note}}
* {{Lien web|langue=en |id=oracle_release2.2.2  | url=http://www.oracle.com/technetwork/java/javacard/documentation/releasenotes-jcspecspw-2-2-2-142671.html  | titre= Oracle Java Card 2.2.2| année = 2006 | mois = mars}}
* {{Lien web|langue=en |id=oracle_overview  | url=http://www.oracle.com/technetwork/java/javame/javacard/overview/about/index.html | titre= Oracle Java Card Industries}}
* {{Lien web|langue=en |id=Sun_CLDC| url=http://java.sun.com/products/cldc/| titre= Sun CLDC}}
* {{Lien web|langue=en |id=Servlet_2_4| url=http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html| titre= Java Servlet V2.4}}
* {{Lien web|langue=en |id=Type_Java| url=http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html| titre= Type utilisé dans la programmation Java}}
* {{Lien web|langue=en |id=StringBuilder| url=http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuilder.html| titre= Classe StringBuilder}}
* {{Lien web|langue=en |id=Generics| url=http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf| titre= Types génériques du langage Java}}
* {{Lien web|langue=en |id=Autoboxing| url=http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html| titre= Autoboxing en Java}}
* {{Lien web|langue=en |id=Enumération| url=http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Enumeration.html| titre= Énumération du langage Java}}
* {{Lien web|langue=en |id=Varargs| url=http://docs.oracle.com/javase/1.5.0/docs/guide/language/varargs.html| titre= Méthodes à arguments multiples du langage Java}}
* {{Lien web|langue=en |id=Static_Imports| url=http://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html| titre= Import statique du langage Java}}

{{Palette|Systèmes d'exploitation}}

{{Portail|informatique|programmation informatique}}

[[Catégorie:Plateforme Java]]
[[Catégorie:Système d'exploitation pour carte à puce]]