La posibilidad de programación en Java de las tarjetas trajo una nueva era en el desarrollo de aplicaciones para tarjetas inteligentes. La tarjeta soporta correr una JVM (Maquina virtual Java). Los Programas escritos en Java pueden ser almacenados y ejecutados directamente en la tarjeta. La programación en Java para Tarjetas se basa en la especificación Java Card 2.0 (http://java.sun.com/products/javacard) la cual es mantenida por Sun. A continuación presentamos las características principales de la JVM en Java card:
- Es una versión restringida de la Java Virtual Machine que soporta un sub-juego del lenguaje Java que puede aplicarse en applets para Java Card.
- Para el soporte de aplicaciones antiguas se provee una API dedicada al desarrollo de applets para smart card basados en los estándares de bajo nivel ISO 7816.
- Un entorno de ejecución abstracto que soporta funciones de administración de applets como el mecanismo de selección del applet a ejecutar. Este entorno se denomina JCRE (Java card Runtime Environment ó Entorno de Ejecución para Tarjetas Java).
Debido a limitaciones técnicas del procesador contenido en la tarjeta y algunas características como multiprocesamiento que son claramente no necesarias para las Tarjetas Java, solo se soporta un sub-juego del lenguaje Java. También existen nuevas clases en la especificación Java Card 2.0 (como javacard.framework.APDU) las cuales están relacionadas con el estándar ISO 7816 o a la criptografía. La implementación de la JVM esta constituida por un verificador de bytecode, un cargador de clase y un interprete de bytecodes. El verificador se utiliza para verificar que el archivo de clase sea un archivo clase de Java válido. El cargador de clase se utiliza para cargar las clases en el sistema. El interprete de bytecode se utiliza para ejecutar la aplicación. (recuerde que bytecode es el código independiente del hardware que generá Java a partir de su lenguaje y será interpretado por la JVM para el hardware en el que se encuentre corriendo).
Un verificador de bytecodes es una pieza larga de software que no cabe dentro de una tarjeta inteligente. Debido a ello, la implementación de la JVM para tarjetas inteligentes se divide en dos partes, como muestra la figura 1:
Figura 1. Arquitectura del Verficador de ByteCodes en la Java Card.
- La parte implementada fuera de la tarjeta se encarga de manejar la verificación de las clases y asegura que todas las clases necesarias se encuentren disponibles.
- La parte residente en la tarjeta tiene como responsabilidad primaria la ejecución del código (bytecodes).
La máquina JVM es persistente, de tal forma que el estado de los programas y objetos son preservados aunque la tarjeta sea desconectada. Todos los datos relacionados se guardarán en la memoria interna EEPROM. Otra consecuencia de la JVM, es que las clases son cargadas e inicializadas solo una vez, permaneciendo activas hasta que se las elimine.
Además de la metodología del estandar APDU comando/respuesta, la otra forma de interactuar con el programa en la tarjeta Java es utilizando el Método de Invocación Remota (RMI). RMI, tecnología de objetos distribuidos, es una arquitectura que manifiesta el principio de que un servicio provisto por un servidor (tarjeta Java) debe ser descriptos mediante una interfase. La interfase provee una lista de métodos disponibles públicamente para un determinado objeto. Una interfase de este tipo es una especie de contrato que obliga al servidor con sus clientes (terminales). El servidor garantiza que va a responder por los métodos definidos en su interfase. Por otro lado, el protocolo enlaza al servidor con sus clientes. El protocolo define la manera en que el servidor y los clientes se comunicaran. Debido a que la implementación de protocolos es un tanto complicada, frecuentemente es generada automáticamente por un determinado objeto en la JCRE. Este programa generado automáticamente, el cual implementa el lado-cliente del protocolo, se denomina proxy como se muestra en la figura 5-2. Además de contener el código para las funciones, también contiene el código requerido para acceder a las funciones desde un servidor remoto. Una tarjeta Java puede ser considerada como un Servidor que provee servicios a sus clientes (terminales) para acceder o administrar la información almacenada en la tarjeta inteligente. Además, varios de los protocolos definidos por los estándares ISO 7816-3 y 4 definen la tarjeta inteligente como un esclavo en una configuración maestro/esclavo:
- La funcionalidad provista por un programa Java (applet) en la tarjeta Java se provee mediante la interfase Java, la cual define la lista de métodos disponibles.
- Entre el applet y sus clientes (terminales) se define claramente un protocolo de alto-nivel.
- Para dar soporte al diseño y desarrollo del software cliente esta disponible un generador proxy.
Figura 5-2. El Proxy entre la aplicación y el Applet
Existen tres reglas para controlar la seguridad y visibilidad de los applets (programas) en una tarjeta Java:
|
En realidad , estas tres reglas son las mismas que en las reglas del Java estándar. Además, la mayoría de los fabricantes de tarjetas Java incluyen una característica adicional de seguridad – firewall – entre applets. Esta característica es global para la tarjeta, y el propósito es aislar cada objeto en su propio casillero para reducir el riesgo de acceso ilegal.
Luego de que el applet de una tarjeta Java ha sido creado y cargado en el terminal, el primer paso será instalarlo y registrarlo en la tarjeta Java. Debido a que este método es estático, es el encargado de alojar una nueva instancia del applet y de registrarlo con la JCRE mediante el método de registro como es mostrado en la figura 5-3 (paso 1). Una vez que el applet ha sido registrado satisfactoriamente, estará listo para ser seleccionado y activado como muestra la figura 5-3 (paso 2). Solamente un applet puede ser seleccionado y activado por vez. Si la selección del applet es satisfactoria, estará listo para procesar comandos, como muestra la figura 5-3 (paso 3). Cualquier comando enviado a la tarjeta se incrustara en un objeto APDU y será enviado al método procesar (process) del applet, mientras este se encuentre seleccionado. Esto continuará hasta que el applet se deseleccione como muestra la figura 5-3 (paso 4). El método de deseleccionar del applet actual deberá ser llamado antes que uno nuevo sea seleccionado.
Luego de que el applet de una tarjeta Java ha sido creado y cargado en el terminal, el primer paso será instalarlo y registrarlo en la tarjeta Java. Debido a que este método es estático, es el encargado de alojar una nueva instancia del applet y de registrarlo con la JCRE mediante el método de registro como es mostrado en la figura 5-3 (paso 1). Una vez que el applet ha sido registrado satisfactoriamente, estará listo para ser seleccionado y activado como muestra la figura 5-3 (paso 2). Solamente un applet puede ser seleccionado y activado por vez. Si la selección del applet es satisfactoria, estará listo para procesar comandos, como muestra la figura 5-3 (paso 3). Cualquier comando enviado a la tarjeta se incrustara en un objeto APDU y será enviado al método procesar (process) del applet, mientras este se encuentre seleccionado. Esto continuará hasta que el applet se deseleccione como muestra la figura 5-3 (paso 4). El método de deseleccionar del applet actual deberá ser llamado antes que uno nuevo sea seleccionado.
Figura 5-3. El ciclo de vida de un Applet en una tarjeta Java.
[FIN]
 | Esta obra está bajo una licencia de Creative Common |
