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 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 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. En raison de la faible capacité mémoire disponible sur une carte à puce, seulement un sous-ensemble de Java pouvait être utilisé. Ainsi fut créé Java Card 1.0 en , le premier langage orienté objet adapté aux cartes à puce.
, 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.
, les producteurs de cartes à puce comme De La Rue, Bull, Giesecke+Devrient rejoignent Java Card Forum qui édite une nouvelle version des spécifications Java Card 2.0.
Par la suite, Sun éditera quatre nouvelles spécifications : en édition de Java Card 2.1, en Java Card 2.2, en Java Card 3.0 et enfin la plus récente Java Card 3.0.1 en Oracle : Spécifications des versions.
La société Oracle Corporation acquiert en l'entreprise Sun Microsystems.
Architecture 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 ISO7816ISO7816.
vignette|300px|présentation architecture La plate-forme Java Card est articulée autourOracle : Chapitre Composants : d’une machine virtuelle Java Card appelée JCVMqui est nommée dans la littérature scientifique anglo-saxonne Java Card Virtual Machine 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é JCREqui est nommé dans la littérature scientifique anglo-saxonne Java Card Runtime Environment 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 APIsqui sont nommées dans la littérature scientifique anglo-saxonne Application Programmer Interface, 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 , à la suite des évolutions des cartes à puces, la plate-forme Java Card se décline en 2 versions.
Version Classique 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 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 applications web, appelées servlet. Cette version intègre les fonctionnalités de la version classique.
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 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. Une fois installé sur la plate-forme et sélectionné, le bytecodebytecode ou code binaire intermédiaire en français inclus dans les fichiers de classe (extension .class )., de l'applet est exécuté par la machine virtuelle embarquée JCVM. Machine Virtuelle Java Card 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) : Une partie externe à la carte à pucequi est nommé dans la littérature scientifique anglo-saxonne Off-Card, intégrant le convertisseur et vérificateur fonctionnant sur un PCqui est nommé dans la littérature scientifique anglo-saxonne Private Computer, «Ordinateur personnel» en français. ou un poste de travail distant. Une partie interne à la carte à pucequi est nommé dans la littérature scientifique anglo-saxonne On-Card c'est-à-dire présente sur la carte qui inclut l’interpréteur de code Java Card. 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 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.
le convertisseur charge les fichiers de classe vérifiés par le vérificateur. Il produit un fichier CAPqui est nommé dans la littérature scientifique anglo-saxonne CAP file (Converted APplet), (contenant une représentation compacte d'un ou plusieurs fichiers Java compilés) correspondant à la conversion d’une applet.
En plus de la création d'un fichier CAP, le convertisseur produit un fichier d'exportationqui est nommé dans la littérature scientifique anglo-saxonne Export File contenant des informations API publiques pour un ou plusieurs fichiers de classe. 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.
L’interpréteur de Java Card fournit le support d'exécution du langage Java, il exécute les tâches suivantes : 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. 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. 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. 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 (CADqui est nommé dans la littérature scientifique anglo-saxonne Card Acceptance Device). 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. Il est implémenté sur la carte à puce et sert essentiellement au système d'exploitation présent sur la carte. Le JCRE est composé de la JCVM, des APIs, d'extensions spécifiques à une industriequi est nommée dans la littérature scientifique anglo-saxonne industry-specific extensions. et des systèmes de classes. 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.
La couche inférieure du JCRE contient la JCVM et les méthodes nativesméthodes de bases qui sont nommées dans la littérature scientifique anglo-saxonne natives method. 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 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)Dufay,2003, p.28. 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. 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.
Le système de classes invoque les méthodes natives. 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.