Carte à puce. Partie 4. JavaCard

Bonjour Giktayms!

Aujourd'hui, je voudrais parler de JavaCard. Cet article se concentrera sur le concept de JavaCard et un aperçu de son architecture. S'il y a un intérêt pour ce sujet, alors je pourrais écrire une série séparée d'articles dans lesquels tous les aspects de JavaCard seront discutés en détail. Je dirai tout de suite que je ne vais pas vous apprendre à écrire votre première application en JavaCard, car il y a déjà trop d'articles sur Internet à ce sujet. Aujourd'hui, nous parlerons principalement du fonctionnement de JavaCard.

Ainsi, une carte à puce basée sur JavaCard est une carte sur laquelle les applications s'exécutent sur la machine virtuelle JavaCard (une version limitée de la machine virtuelle Java adaptée aux cartes à puce) dans ce que l'on appelle l'environnement d'exécution JavaCard (qui a très peu en commun avec l'environnement d'exécution Java) .

En termes de terminologie, les applications sont appelées applets et sont contenues dans des packages. Les packages sont distribués dans des fichiers CAP (au lieu de fichiers Jar). Les packages et les applications ont leur propre AID (Application Identifier). Cela est nécessaire pour qu'ils puissent être identifiés de manière unique dans des commandes telles que: SELECT, INSTALL, DELETE, etc. (SELECT est décrit dans ISO7816-4, et JavaCard et d'autres commandes sont décrites dans la plate-forme globale).

Le cycle de vie des applets est légèrement différent du cycle de vie habituel des applications informatiques. Une applet est une classe qui hérite de la classe de base Applet. Lors de l'installation d'applications, sa méthode d'installation statique est appelée. Cette méthode doit créer un objet de la classe correspondante et appeler la méthode register dessus. Par la suite, l'objet sera enregistré dans le système et recevra son propre AID, qui sera utilisé pour une communication ultérieure avec l'application. L'objet et ses champs de données sont stockés dans NVM (mémoire non volatile). Chaque objet ou tableau créé par l'application à l'aide de l'opérateur «nouveau» sera également dans NVM. Cela signifie que, contrairement aux programmes informatiques traditionnels, l'état des applications JavaCard est constant et n'est pas perdu même lorsque la carte est éteinte.

Communication avec l'application

À tout moment, chaque canal logique ouvert a une application active. Une application active est une application qui reçoit tous les APDU envoyés par le terminal. Lorsqu'une APDU est reçue, la JavaCard appelle la méthode de processus de l'application active, qui prend l'APDU reçue comme seul paramètre. Cette méthode est au cœur de l'applet, car elle traite les requêtes du terminal. L'APDU résultante est également utilisée pour envoyer des réponses.

Une applet peut être activée de deux manières:

• lors de la réinitialisation de la carte ou lors de l'ouverture d'un canal logique, le système active généralement l'application marquée comme application par défaut
• en utilisant la commande SELECT avec P1 = 0x04 et l'AID (complet ou partiel) de l'application dans Data

Lorsque l'application est activée à l'aide de la commande SELECT, immédiatement après l'activation, la méthode de processus avec l'APDU contenant cette commande sera appelée. Ainsi, l'applet est capable d'envoyer des informations en réponse à une commande SELECT lorsqu'elle est activée. La classe Applet fournit la méthode selectionApplet () pour déterminer si la commande reçue a provoqué l'activation de l'application.

L'application a également la possibilité de réécrire les méthodes select () et deselect () afin d'initialiser respectivement lors de l'activation et de désinitialiser lors de la désactivation. Ces méthodes seront appelées quelle que soit la façon dont l'application a été activée.

Les canaux logiques peuvent être ouverts et fermés à l'aide de la commande GÉRER LE CANAL. Grâce à des canaux logiques ouverts, vous pouvez envoyer toutes les commandes, y compris SELECT. Ce sont SELECT et MANAGE CHANNEL qui sont les seules commandes qui sont traitées directement par le système, et non par l'application active. Bien que dans le cas de la commande SELECT, nous pouvons dire qu'elle est traitée à la fois par le système et l'application active.

Les règles complètes pour appeler l'application et traiter la commande SELECT sont assez complexes, et il y a peu de contradictions entre JavaCard et Global Platform. Cependant, je couvrirai ce sujet dans un de mes prochains articles. Maintenant, il vaut la peine de dire que les cartes suivent souvent les règles décrites dans la plate-forme mondiale.

Gestion de la mémoire

NVM. NVM, JavaCard RAM JCSystem. 2 : Clear on Reset Clear on Deselect. reset . , Applet (.: SELECT , , reset, ..). , , (.. false), , , , .

NVM:

• .
• .
• , new.

RAM (CLEAR_ON_RESET CLEAR_ON_DESELECT):

• , JCSystem.makeTransient<>Array. , , , JCSystem.makeTransientObjectArray(), NVM. RAM.
• Global Arrays: (APDU Install Parameters ), Global Arrays, JCSystem.makeGlobalArray().
• . .

, , , . , , :

1) , , , - .
2) — ( ) . , , . . , , (JCSystem.requestObjectDeletion()).

Par la suite, le code d'application est rarement obtenu «propre» en termes de programmation orientée objet. L'utilisation d'octets communs [] pour de nombreuses opérations différentes est une pratique très courante. Les classes constituées uniquement de méthodes statiques et s'exécutant sur l'octet [] ne sont pas non plus rares. De plus, la création de classes et d'objets est minimisée. Peu de mémoire et elle doit être protégée à tout prix.

Il convient également de noter le rôle de l'objet APDU. Son tampon situé en RAM est effacé avant de recevoir chaque commande. Il est d'usage de l'utiliser non seulement pour former une réponse, mais souvent même comme tampon temporaire. Sa taille est d'au moins 256 octets ou beaucoup plus grande si la carte prend en charge la longueur étendue.

Pare-feu d'applet

JavaCard, , Applet Firewall. Firewall — , - Applet . , JavaCard Shareable Interfaces, , . firewall. Applet Firewall :

• . .
• .
• () . , .
• .
• (/ ) , .
• .
• . . , , firewall.
• CLEAR_ON_DESELECT , .

Shareable Interface . , , , Shareable Interface. , , , , , byte[] , . .

L'application a également accès à certains objets appartenant au système. Ces objets sont appelés points d'entrée. Il existe deux types de points d'entrée: temporaires et permanents. Les points d'entrée permanents sont simples, leur accès est autorisé dans n'importe quel contexte. Un exemple de ceci est les objets de la classe AID. Les points d'entrée temporaires, en revanche, ont une restriction qui les empêche d'être stockés dans les champs de données de l'objet ou les champs statiques de la classe. Un exemple de point d'entrée temporaire est un objet APDU.

À partir de JavaCard 3.0.4, il est également possible de créer des tableaux globaux à l'aide de la méthode JCSystem.makeGlobalArray (). Leur comportement est exactement le même que celui des points d'entrée temporaires. Ils sont principalement nécessaires comme paramètre pour les méthodes appelées à l'aide de la technique de l'interface partageable.

Atomicité et transactions

JavaCard garantit les opérations atomiques lors de la modification des champs de données d'objets ou de classes. L'atomicité est également fournie par des méthodes de travail sur des tableaux (à l'exception de ceux qui ont le suffixe NonAtomic dans le nom). Cela signifie que, par exemple, Util.arrayCopy copiera tous les octets (s'il est exécuté avec succès) ou laissera le tableau inchangé en cas d'erreur ou de perte d'énergie.

, JavaCard JCSystem.beginTransaction() JCSystem.commitTransaction() . , JCSystem.beginTransaction() JCSystem.commitTransaction(), . - , JCSystem.abortTransaction(), . , . , TransactionException.

RMI

JavaCard RMI (Remote Metod Invocation). . , , .

API

JavaCard API . , , , , . JavaCard PIN . , , , TLV .. API, .

JavaCard Java

JavaCard — Java. Java. , char, float, double, long enum . int ( ) , , CAP-file. for, lambda. Generics, import ( Runtime Invisible) , 3.0.0, .. .

JDK. CAP-file IDE JavaCard.

Le plus gros problème pour les programmeurs, en fait, est le manque d'un int par défaut. Habituellement, ils ne sont vraiment pas nécessaires, donc je ne veux pas les activer inutilement. Cependant, le compilateur Java a l'habitude de convertir automatiquement le résultat de toutes les opérations arithmétiques en int. Pour éviter cela, vous devez utiliser un transtypage de type explicite en short ou byte dans le code, ce qui rend le code moins lisible.

Une autre limitation se produit dans l'initialisation des champs statiques, à savoir qu'ils ne peuvent être initialisés qu'avec des constantes et des tableaux contenant des constantes, mais pas avec des objets.

Conclusion

JavaCard. , , , , . JavaCard. , Global Platform, .