Comprendre Java Card 2.0

Cet article commence par un aperçu des cartes à puce et un bref examen de la norme ISO 7816, la norme relative aux cartes à puce. Compte tenu de l'historique des cartes à puce dans les colonnes précédentes de Java Developer , cet épisode commencera par une réponse à la question "Qu'est-ce qu'une Java Card?" et un aperçu de l'architecture du système Java Card. Ensuite, nous nous concentrerons sur les nombreux problèmes spécifiques à la Java Card, y compris le cycle de vie de la Java Card; le sous-ensemble de langage Java Card 2.0 et les classes de bibliothèque d'API; et la sécurité Java Card. Ensuite, nous discuterons de l'environnement d'exécution Java Card et montrerons comment une Java Card s'exécute. Nous terminerons par un exemple éclairant: une application de portefeuille électronique écrite uniquement pour la Java Card.

À partir de là, toutes les références à Java Card renvoient implicitement à la Java Card 2.0.

Qu'est-ce qu'une carte à puce?

Identique à la taille d'une carte de crédit, une carte à puce stocke et traite des informations à travers les circuits électroniques embarqués dans du silicium dans le substrat plastique de son corps. Il existe deux types de cartes à puce: Une carte à puce intelligente contient un microprocesseur et offre des capacités de lecture, d'écriture et de calcul, comme un petit micro-ordinateur. Une carte mémoire , en revanche, ne possède pas de microprocesseur et est uniquement destinée au stockage d'informations. Une carte mémoire utilise une logique de sécurité pour contrôler l'accès à la mémoire.

Toutes les cartes à puce contiennent trois types de mémoire: une mémoire persistante non mutable; mémoire mutable persistante; et mémoire mutable non persistante. La ROM, l'EEPROM et la RAM sont la mémoire la plus largement utilisée pour les trois types respectifs des cartes à puce actuelles. La mémoire persistante est également appelée mémoire non volatile. Nous utiliserons les termes persistante et non volatile de manière interchangeable dans cet article.

L'ISO 7816 partie 1-7, définie par l'Organisation internationale de normalisation, contient un ensemble de normes qui couvre divers aspects des cartes à puce. L'ISO 7816 comprend:

  • Caractéristiques physiques (partie 1)

  • Dimensions et emplacement des contacts (partie 2)

  • Signaux électroniques et protocoles de transmission (partie 3)

  • Commandes inter-industries pour l'échange (partie 4)

  • Identificateurs d'application (partie 5)

  • Éléments de données intersectoriels (partie 6)

  • Commandes inter-industries pour SCQL (partie 7)

Le diagramme suivant illustre les caractéristiques physiques d'une carte à puce, qui sont définies dans l'ISO 7816, partie 1.

Pour plus d'informations sur l'ISO 7816 et les cartes à puce, voir «Cartes à puce: une introduction».

Normalement, une carte à puce ne contient pas de bloc d'alimentation, d'écran ou de clavier. Il interagit avec le monde extérieur à l'aide de l'interface de communication série via ses huit points de contact. Les dimensions et l'emplacement des contacts sont traités dans la partie 2 de l'ISO 7816. Ce schéma montre les contacts sur une carte à puce.

Une carte à puce est insérée dans un dispositif d'acceptation de carte (CAD), qui peut se connecter à un autre ordinateur. Les autres termes utilisés pour le périphérique d'acceptation de carte sont terminal , lecteur et IFD (périphérique d'interface). Ils assurent tous les mêmes fonctions de base, à savoir alimenter la carte et établir une connexion porteuse de données.

Lorsque deux ordinateurs communiquent entre eux, ils échangent des paquets de données, qui sont construits selon un ensemble de protocoles. De même, les cartes à puce parlent au monde extérieur en utilisant leurs propres paquets de données - appelés APDU (Application Protocol Data Units). APDU contient une commande ou un message de réponse. Dans le monde des cartes, le modèle maître-esclave est utilisé dans lequel une carte à puce joue toujours le rôle passif. En d'autres termes, une carte à puce attend toujours une commande APDU d'un terminal. Il exécute alors l'action spécifiée dans l'APDU et répond au terminal par une APDU de réponse. Les APDU de commande et les APDU de réponse sont échangés alternativement entre une carte et un terminal.

Les tableaux suivants illustrent respectivement les formats APDU de commande et de réponse. La structure de l'APDU est décrite dans l'ISO 7816, partie 4.

Commande APDU
En-tête obligatoire Corps conditionnel
CLA INS P1 P2 Lc Champ de données Le

L'en-tête code la commande sélectionnée. Il se compose de quatre champs: classe (CLA), instruction (INS) et paramètres 1 et 2 (P1 et P2). Chaque champ contient 1 octet:

  • CLA: octet de classe. Dans de nombreuses cartes à puce, cet octet est utilisé pour identifier une application.

  • INS: octet d'instruction. Cet octet indique le code de l'instruction.

  • P1-P2: octets de paramètres. Ceux-ci fournissent une qualification supplémentaire à la commande APDU.

Lc désigne le nombre d'octets dans le champ de données de la commande APDU; Le désigne le nombre maximal d'octets attendu dans le champ de données de l'APDU de réponse suivante.

APDU de réponse
Corps conditionnel Bande-annonce obligatoire
Champ de données SW1 SW2

Les octets d'état SW1 et SW2 indiquent l'état de traitement de la commande APDU dans une carte.

Qu'est-ce qu'une Java Card?

Une Java Card est une carte à puce capable d'exécuter des programmes Java. La spécification Java Card 2.0 a été publiée sur //www.javasoft.com/javacard. Il contient des informations détaillées sur la création de la machine virtuelle Java Card et de l'interface de programmation d'application (API) dans les cartes à puce. La configuration système minimale requise est de 16 kilo-octets de mémoire morte (ROM), 8 kilo-octets d'EEPROM et 256 octets de mémoire vive (RAM).

L'architecture du système sur la Java Card est illustrée dans la figure suivante.

Comme le montre la figure, la machine virtuelle Java Card est construite sur un circuit intégré spécifique (IC) et une implémentation de système d'exploitation natif. La couche JVM cache la technologie propriétaire du fabricant avec un langage et une interface système communs. La structure Java Card définit un ensemble de classes API (Application Programming Interface) pour développer des applications Java Card et pour fournir des services système à ces applications. Un secteur ou une entreprise spécifique peut fournir des bibliothèques complémentaires pour fournir un service ou pour affiner le modèle de sécurité et de système. Les applications Java Card sont appelées applets . Plusieurs applets peuvent résider sur une seule carte. Chaque applet est identifiée de manière unique par son AID (identifiant d'application), tel que défini dans l'ISO 7816, partie 5.

Un point important à garder à l'esprit est ce que les cartes à puce ne sont pas : ce ne sont pas des ordinateurs personnels. Ils ont des ressources mémoire et une puissance de calcul limitées. Les utilisateurs ne doivent pas considérer Java Card 2.0 comme une simple version allégée du JDK.

La durée de vie d'une Java Card

La durée de vie de la Java Card commence lorsque le système d'exploitation natif, la machine virtuelle Java Card, les bibliothèques de classes API et éventuellement les applets sont gravés dans la ROM. Ce processus d'écriture des composants permanents dans la mémoire non mutable d'une puce pour exécuter des commandes entrantes est appelé masquage .

Avant d'atterrir dans votre portefeuille, une Java Card doit passer par l'initialisation et la personnalisation. L'initialisation fait référence au chargement de données générales dans la mémoire non volatile d'une carte. Ces données sont identiques sur un grand nombre de cartes et ne sont pas spécifiques à un individu; un exemple pourrait être le nom de l'émetteur ou du fabricant.

L'étape suivante, la personnalisation, consiste à attribuer une carte à une personne. Cela peut se produire par personnalisation physique ou par personnalisation électronique. La personnalisation physique fait référence au gaufrage ou à la gravure au laser de votre nom et numéro de carte sur la surface en plastique d'une carte. La personnalisation électronique fait référence au chargement de données personnelles dans la mémoire non volatile d'une carte, par exemple, votre clé personnelle, votre nom et votre code PIN.

L'initialisation et la personnalisation varient d'un fournisseur à l'autre et d'un émetteur à l'autre. Dans les deux cas, l'EEPROM (un type de mémoire non volatile) est souvent utilisée pour stocker des données.

À ce stade, la Java Card est prête à être utilisée. Vous pouvez obtenir une Java Card auprès d'un émetteur ou l'acheter auprès d'un revendeur. Les cartes vendues par un détaillant sont à usage général, auquel cas la personnalisation est souvent omise.

Vous pouvez maintenant insérer votre Java Card dans un lecteur et envoyer des commandes APDU aux applets résidant sur la carte ou télécharger plus d'applets ou de données sur la carte.

Une Java Card reste active jusqu'à ce qu'elle expire ou soit bloquée en raison d'une erreur irrémédiable.

Durée de vie d'une machine virtuelle Java Card

Contrairement à la machine virtuelle Java (JVM) dans un PC ou un poste de travail, la machine virtuelle Java Card fonctionne indéfiniment.

La plupart des informations stockées sur la carte doivent être conservées même lorsque l'alimentation est coupée, c'est-à-dire lorsque la carte est retirée du lecteur. La machine virtuelle Java Card crée des objets dans l'EEPROM pour contenir les informations persistantes. La durée de vie d'exécution de la machine virtuelle Java Card correspond à la durée de vie de la carte. Lorsque l'alimentation n'est pas fournie, la VM s'exécute selon un cycle d'horloge infini.

La durée de vie des applets et objets Java Card

La vie d'une applet commence lorsqu'elle est correctement installée et enregistrée dans la table de registre du système et se termine lorsqu'elle est supprimée de la table. L'espace d'une applet supprimée peut cependant être réutilisé ou non, selon que le garbage collection est implémenté sur la carte. Une applet sur une carte est à un stade inactif jusqu'à ce qu'elle soit explicitement sélectionnée par le terminal.

Les objets sont créés dans la mémoire persistante (par exemple, EEPROM). Ils peuvent être perdus ou récupérés si d'autres objets persistants ne les référencent pas. Cependant, il est mille fois plus lent d'écrire dans l'EEPROM que dans la RAM.

Certains objets sont fréquemment consultés et le contenu de leurs champs n'a pas besoin d'être persistant. La Java Card prend en charge les objets transitoires (temporaires) dans la RAM. Une fois qu'un objet a été déclaré comme transitoire, son contenu ne peut pas être déplacé vers la mémoire persistante.

Sous-ensemble de langage Java Card 2.0

Les programmes Java Card sont, bien entendu, écrits en Java. Ils sont compilés à l'aide de compilateurs Java courants. En raison des ressources mémoire limitées et de la puissance de calcul, toutes les fonctionnalités de langage définies dans la spécification du langage Java ne sont pas prises en charge sur la Java Card. Plus précisément, la Java Card ne prend pas en charge:

  • Chargement de classe dynamique

  • Responsable de la sécurité

  • Threads et synchronisation

  • Clonage d'objets

  • Finalisation

  • Grands types de données primitifs (float, double, long et char)

Il n'est pas surprenant que les mots clés qui prennent en charge ces fonctionnalités soient également omis de la langue. Les implémenteurs de VM peuvent décider de prendre en charge le type entier 32 bits ou les méthodes natives pour les applets de post-émission s'ils travaillent sur une carte à puce plus avancée avec plus de mémoire. Les applets post-émission sont les applets qui sont installés sur une Java Card après que la carte est émise à un titulaire de carte.

Le framework Java Card 2.0

Les cartes à puce sont sur le marché depuis 20 ans et la plupart d'entre elles sont généralement compatibles avec la norme ISO 7816, parties 1-7 et / ou EMV. Nous avons déjà examiné ISO 7816. Qu'est-ce que l'EMV? La norme EMV, définie par Europay, MasterCard et Visa, est basée sur la série de normes ISO 7816 avec des caractéristiques exclusives supplémentaires pour répondre aux besoins spécifiques du secteur financier. Le Java Card Framework est conçu pour prendre en charge facilement les systèmes et applications de cartes à puce. Il masque les détails de l'infrastructure de la carte à puce et fournit aux développeurs d'applications Java Card une interface de programmation relativement simple et directe.

Le framework Java Card contient quatre packages:

Nom du paquet La description
javacard.framework Il s'agit du package principal de la carte. Il définit des classes telles que et , qui sont les blocs de construction fondamentaux pour les programmes Java Card et , et , qui fournissent des services d'exécution et système aux programmes Java Card, tels que la gestion des APDU et le partage d'objets.
javacardx.framework Ce package fournit une conception orientée objet pour un système de fichiers compatible ISO 7816-4. Il prend en charge les fichiers élémentaires (EF), les fichiers dédiés (DF) et les APDU orientés fichier comme spécifié dans ISO7816
javacardx.crypto et javacardx.cryptoEnc Ces deux packages prennent en charge la fonctionnalité cryptographique requise dans les cartes à puce

Conformément à la convention de dénomination Java, les packages Java Cardx sont des extensions du framework Java Card. Il n'est pas nécessaire que vous les souteniez sur la carte.

Sécurité de la Java Card

Les applets Java sont soumises à des restrictions de sécurité Java, cependant, le modèle de sécurité des systèmes Java Card diffère de Java standard à bien des égards.

La classe Security Manager n'est pas prise en charge sur Java Card. Les politiques de sécurité linguistique sont implémentées par la machine virtuelle.

Les applets Java créent des objets qui stockent et manipulent des données. Un objet appartient à l'applet qui le crée. Même si une applet peut avoir la référence à un objet, elle ne peut pas appeler les méthodes de l'objet, sauf si elle possède l'objet ou si l'objet est explicitement partagé. Une applet peut partager n'importe lequel de ses objets avec une applet particulière ou avec toutes les applets.

Une applet est une entité indépendante au sein d'une Java Card. Sa sélection, son exécution et ses fonctionnalités ne sont pas affectées par les autres applets résidant sur la même carte.

Comment les choses fonctionnent ensemble dans une Java Card

Dans une Java Card, JCRE (Java Card Runtime Environment) fait référence à la machine virtuelle Java Card et aux classes du Java Card Framework. Chaque applet d'une Java Card est associée à un AID unique attribué par JCRE.

Une fois qu'une applet est correctement chargée dans la mémoire persistante de la carte et liée à Java Card Framework et aux autres bibliothèques de la carte, JCRE appelle la méthode d'installation de l'applet comme dernière étape du processus d'installation de l'applet. Une méthode statique publique,, installdoit être implémentée par une classe d'applet pour créer une instance de l'applet et l'enregistrer auprès de JCRE. Comme la mémoire est limitée, il est recommandé, à ce stade, de créer et d'initialiser les objets dont l'applet aura besoin pendant sa durée de vie.