6 LA PLATAFORMA JAVA MEbibing.us.es/proyectos/abreproy/11458/fichero/PFC%2FCapitulo06+-+L… · El...

La plataforma Java ME Página 113

6 LA PLATAFORMA JAVA ME

6.1 INTRODUCCIÓN

Si atendemos un poco a la historia, nos daremos cuenta de que el lenguaje Java, que se utiliza en las aplicaciones de los ordenadores personales y servidores de red, fue diseñado con el objetivo de ser aplicado sobre dispositivos de reducidas prestaciones, tales como televisores y lavadores.

El objetivo de los creadores de Java fue el diseño de un nuevo lenguaje de alto nivel y elevadas prestaciones, que permitiese controlar dispositivos hardware de prestaciones más o menos reducidas.

Se buscaba un lenguaje totalmente portable e independiente de la plataforma de ejecución, es decir, que una vez desarrollado un único programa, éste pudiera ejecutarse en cualquier dispositivo independientemente de sus características específicas.

Como resultado de esto nace la tecnología J2ME (Java Micro Edition), que consiste en la adaptación del lenguaje Java para la programación de dispositivos de escasos recursos como teléfonos móviles.

Algunas características que hacen que Java sea buena plataforma para el desarrollo de aplicaciones para dispositivos inalámbricos son las siguientes:

• Java es independiente del tipo de red usada, se puede descargar cualquier aplicación o contenido sin preocuparse de la red usada.

• El uso de la verificación de ficheros de clase aporta una gran seguridad de que las aplicaciones desarrolladas funcionen correctamente.

• La portabilidad hace este lenguaje adecuado para implementar aplicaciones que serán en dispositivos de distintos fabricantes.

• Las aplicaciones Java ME tienen vida propia y no requieren una conexión permanente a la red. Estas aplicaciones residen en el dispositivo y no tienen por qué ser descargadas cada vez que vayan a ser ejecutadas.

• Existe una amplia comunidad de desarrolladores trabajando en este campo.

La idea principal de Java ME es proporcionar aplicaciones de desarrollo sencillas, que permitan al programador desarrollar aplicaciones de usuario para el consumidor de dispositivos móviles y portátiles. De esta forma se abre un amplio mercado para todas aquellas empresas que deseen cubrir las necesidades que los usuarios demandan en sus dispositivos móviles, tales como teléfonos móviles o agendas personales.

Java ME está orientada a dos categorías muy concretas de productos, como son:

• Dispositivos de información compartidos y conectados de forma permanente. Esta categoría se conoce con la denominación CDC (Connected Device Configuration). Ejemplos típicos de estos son


televisores, teléfonos conectados a Internet y sistemas de navegación y entretenimiento para el automóvil. Estos dispositivos se caracterizan por tener un amplio rango de interfaces de usuario, conexión permanente a Internet de banda ancha de tipo TCP/IP y unos rangos de capacidad de memoria entre 2 y 16 MB.

• Dispositivos de información personales móviles. Categoría conocida como CLDC (Connected Limited Device Configuration). De entre todos estos los más representativos son los teléfonos móviles y las agendas personales PDAs. Caracterizados por disponer de interfaces simples, conexión no permanente a Internet, de menor ancho de banda, normalmente no basada en TCP/IP y con rangos de memoria reducidos, entre 128KB y 2MB

Claro está con el paso de los años la línea fronteriza, que separa ambos grupos, es cada vez más fina y cada vez está más difuminada lo cual, a medida que la tecnología avanza, y van apareciendo nuevos tipos de dispositivos, y van evolucionando los ya existentes, va potenciándose aún más. De esta forma hoy se “confunden” los ordenadores y los dispositivos de comunicaciones y cada vez se va haciendo mayor uso de conexiones sin cables, lo cual nos lleva a realizar en la práctica una agrupación de equipos basándonos únicamente en sus capacidades de memoria, sus consumos de batería y el tamaño de su pantalla.

6.2 ARQUITECTURA JAVA ME

Aunque los dispositivos mencionados tales como teléfonos móviles, agendas personales (PDAs) o televisores tienen muchos aspectos en común, también son muy diferentes en cuanto a forma y función. Estos contarán con diferentes configuraciones hardware, diferentes modos de uso (uso de teclados, voz, etc.), diferentes aplicaciones y características software, así como todo un amplio rango de futuras necesidades a cubrir.

Ilustración 34: Arquitectura Java ME

Para considerar esta diversidad la arquitectura Java ME está diseñada de forma modular y extensible de tal forma que se de cabida a esta extensa variedad de dispositivos así como a aquellos que sean desarrollados en un futuro. La arquitectura Java ME tiene en cuenta todas aquellas consideraciones relativas a los dispositivos sobre los que tendrá que trabajar. De esta forma, son tres los conceptos básicos en los que se fundamenta.


• Máquina Virtual: Por un lado máquinas virtuales Java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.

• Configuración: conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas.

Perfil: bibliotecas Java de clases específicas orientadas a implementar funcionalidades de más alto nivel para familias específicas de dispositivos.

6.2.1 MÁQUINA VIRTUAL JAVA ME

Una máquina virtual de Java (JVM) es un programa encargado de interpretar código intermedio (bytecode) de los programas Java precompilados a código máquina ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar las reglas de seguridad y corrección de código definidas para el lenguaje Java. De esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto al hardware y al sistema operativo subyacente. Las implementaciones tradicionales de JVM son, en general, muy pesadas en cuanto a memoria ocupada y requerimientos computacionales. Java ME define varias JVMs de referencia adecuadas al ámbito de los dispositivos electrónicos que, en algunos casos, suprimen algunas características con el fin de obtener una implementación menos exigente.

Cada una de las configuraciones CLDC y CDC requiere su propia máquina virtual. La VM (Virtual Machine) de la configuración CLDC se denomina KVM y la de la configuración CDC se denomina CVM. Las características principales de cada una de ellas:

6.2.1.1 KVM

Se corresponde con la Máquina Virtual más pequeña desarrollada por Sun. Su nombre KVM proviene de Kilobyte (haciendo referencia a la baja ocupación de memoria, entre 40Kb y 80Kb). Se trata de una implementación de Máquina Virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria. La KVM está escrita en lenguaje C, aproximadamente unas 24000 líneas de código, y fue diseñada para ser:

• Pequeña, con una carga de memoria entre los 40Kb y los 80Kb, dependiendo de la plataforma y las opciones de compilación.

• Alta portabilidad.

• Modulable.

• Lo más completa y rápida posible y sin sacrificar características para las que fue diseñada.

Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones con respecto a la clásica Java Virtual Machine (JVM):


• No hay soporte para tipos en coma flotante. No existen por tanto los tipos double ni float. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas operaciones.

• No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria.

• No existen cargadores de clases (class loaders) definidos por el usuario. Sólo existen los predefinidos.

• No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en el ámbito de la aplicación.

• No existe la finalización de instancias de clases. No existe el método Object.finalize().

• No hay referencias débiles.

• Limitada capacidad para el manejo de excepciones debido a que el manejo de éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos los que controlan la mayoría de las excepciones.

• Reflexión.

El verificador de clases estándar de Java es demasiado grande para la KVM. De hecho es más grande que la propia KVM y el consumo de memoria es excesivo, más de 100Kb para las aplicaciones típicas. Este verificador de clases es el encargado de rechazar las clases no válidas en tiempo de ejecución. Este mecanismo verifica los bytecodes de las clases Java realizando las siguientes comprobaciones:

• Ver que el código no sobrepase los límites de la pila de la VM.

• Comprobar que no se utilizan las variables locales antes de ser inicializadas.

• Comprobar que se respetan los campos, métodos y los modificadores de control de acceso a clases.

Por esta razón los dispositivos que usen la configuración CLDC y KVM introducen un algoritmo de verificación de clases en dos pasos.

6.2.1.2 CVM

La CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de referencia para la configuración CDC y soporta las mismas características que la Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que presenta esta Máquina Virtual son:

• Sistema de memoria avanzado.

• Tiempo de espera bajo para el recolector de basura.

• Separación completa de la VM del sistema de memoria.


• Recolector de basura modularizado.

• Portabilidad.

• Rápida sincronización.

• Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM).

• Soporte nativo de hilos.

• Baja ocupación en memoria de las clases.

• Proporciona soporte e interfaces para servicios en Sistemas Operativos de Tiempo Real.

• Conversión de hilos Java a hilos nativos.

• Soporte para todas las características de Java2 v1.3 y biblioteca de seguridad,

• referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos (RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).

6.2.2 CONFIGURACIÓN.

Ya hemos mencionado algo anteriormente relacionado con las configuraciones. Para tenerlo bien claro diremos que una configuración es el conjunto mínimo de API’s Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas API’s describen las características básicas, comunes a todos los dispositivos:

• Características soportadas del lenguaje de programación Java.

• Características soportadas por la máquina virtual Java.

• Bibliotecas básicas de Java y API’s soportadas.

Ilustración 35: Configuraciones Java ME

Por tanto, todos los dispositivos que se encuadren dentro de una Configuración concreta deben cumplir todas las características de ésta, y todas las aplicaciones que


corran sobre estos dispositivos deben cumplir las restricciones del Perfil que se monta sobre esta configuración.

El objetivo de esto es evitar la fragmentación y limitar en lo posible el número de Configuraciones estándar permitidas, que son: CLDC (Connected Limited Device Configuration) y CDC (Connected Device Configuration).

6.2.2.1 Configuración CDC

La CDC está enfocada a dispositivos con las siguientes capacidades:

• Procesador de 32 bits.

• Disponer de 2MB o más de memoria total, incluyendo RAM y ROM.

• Poseer la funcionalidad completa de la Máquina Virtual Java 2.

• Conectividad a algún tipo de red

La CDC está basada en J2SE v1.3 e incluye varios paquetes Java de la edición estándar. Las peculiaridades de la CDC están contenidas principalmente en el paquete javax.microedition.io, que incluye soporte para las comunicaciones http y basadas en datagramas. La siguiente tabla nos muestra las librerías incluidas en la CDC:

Tabla 9: Librerías de configuración CDC Nombre de Paquete CDC Descripción Java.io Clases e interfaces estándar de E/S Java.lang Clases básicas del lenguaje Java.lang.ref Clases de referencia Java.lang.reflect Clases e interfaces de reflexión Java.math Paquete de matemáticas Java.net Clases e interfaces de red Java.security Clases e interfaces de seguridad Java.security.cert Clases de certificados de seguridad Java.text Paquete de texto Java.util Clases de utilidad estándar Java.util.jar Clases y utilidades para archivos JAR Java.util.zip Clases y utilidades para archivos comprimidos Javax.microedition.io Clases e interfaces para conexión genérica CDC

6.2.2.2 Configuración CLDC

Los requisitos mínimos hardware que definen a un dispositivo englobado en la configuración CLDC son disponer de:

• Al menos 160Kb de memoria disponible para Java. Esta memoria está dividida en dos áreas: 128Kb de memoria no volátil para la máquina virtual Java y las librerías del API CLDC, y 32Kb de memoria volátil para el entorno de ejecución.

• Un procesador de 16 bits o más, con al menos 25MHz de velocidad..

• Bajo consumo, por regla general por medio del uso de baterías.


• Conexión a red, normalmente con un ancho de banda de 9.600 bps o inferior (típico de conexiones GSM).

La configuración CLDC aporta las siguientes funcionalidades a los dispositivos:

• Un subconjunto de las bibliotecas del núcleo Java.

• Soporte para E/S básica.

• Soporte para acceso a redes.

• Seguridad.

En la siguiente tabla observamos las librerías incluidas en la configuración CLDC.

Tabla 10: Librerías de configuración CLDC Nombre de paquete CLDC Descripción

Java.io Clases y paquetes estándar de E/S. Subconjunto de J2SE Java.lang Clases e interfaces de la Máquina Virtual. Subconjunto de J2SE Java.util Clases, interfaces y utilidades estándar. Subconjunto de J2SE Java.microedition.io Clases e interfaces de conexión genérica de CLDC

6.2.3 PERFIL

El perfil es el que define las APIs que controlan el ciclo de vida de la aplicación, interfaz de usuario, etc. Más concretamente, un perfil es un conjunto de APIs orientado a un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y por el tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un componente muy importante en la definición de un perfil. Aquí nos podemos encontrar grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de los PDAs.

Ilustración 36: Arquitectura del entorno de ejecución Java ME

El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con la familia de ellos. Esto hace que a la


hora de construir una aplicación se cuente tanto con las APIs del perfil como con las de la configuración. Tenemos que tener en cuenta que un perfil siempre se construye sobre una configuración determinada. De este modo, podemos pensar en un perfil como un conjunto de APIs que dotan a una configuración de funcionalidad específica.

Vemos en la figura los distintos perfiles que podemos encontrarnos, distinguidos por la configuración a la que complementan.

Analizamos en detalle el perfil que utilizan los teléfonos móviles, puesto que es el que nos atañe en este proyecto.

6.2.3.1 Perfil MIDP

En la jerarquía definida en Java ME, los perfiles (profiles) se apoyan sobre las configuraciones, CLDC en este caso. Un perfil es una concreción aún más restrictiva de las APIs para centrarse en un conjunto muy reducido de dispositivos (incluso uno solo). Es decir, el perfil añade unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicación se cuente tanto con las APIs del perfil como con las de la configuración.

CLDC es la primera configuración definida en Java ME. MIDP (de Mobile Information Device Profile, o "Perfil de Dispositivo Móvil de información") es el primer perfil, hecho para describir dispositivos similares a teléfonos móviles o pagers. Estos dispositivos se describen a través de unos requisitos mínimos que se aplican a algunas de sus características:

Memoria:

• Al menos 128Kb de memoria no volátil para almacenar el API MIDP.

• Al menos 32Kb de memoria volátil para el sistema de ejecución Java.

• Un mínimo de 8Kb de memoria persistente para el almacenamiento de información por parte de los programas.

Entrada de datos: un dispositivo MIDP debe tener un teclado o una pantalla táctil, o ambos. Aunque el ratón no forma parte de los medios de entrada reconocidos, un puntero (como en las PDAs) sí es un sistema de entrada válido ya que se aplica sobre una pantalla táctil.

Pantalla: al referirse a un tipo de dispositivos con grandes limitaciones de visualización, el perfil MIDP es muy restrictivo en este capítulo. La pantalla mínima es de 96x54 píxeles, con dos colores (blanco y negro, o activado y desactivado). Además con una relación entre altura y anchura de 1:1, es decir que la pantalla debe parecer cuadrada, lo que supone usar unos píxeles alargados (en un monitor son generalmente cuadrados, no rectangulares). Ello no impide que la mayor parte de los dispositivos rebasen ampliamente estas restricciones tanto en dimensiones como en colores.

Red: deben contar con acceso a una red bidireccional (para enviar y recibir) inalámbrica. Las exigencias mínimas de ancho banda son muy humildes: 9.600 bps.


Plataforma software: los dispositivos MIDP, no importa el hardware o el sistema operativo en el que se basen (uno de los grandes beneficios de Java) requieren la presencia de una serie de elementos en la gestión de la plataforma como son:

• La presencial de un kernel (núcleo de sistema operativo) capaz de hacerse cargo de tareas de bajo nivel como la gestión de interrupciones, excepciones y temporizadores.

• Un mecanismo para leer y escribir en memoria no volátil.

• Gestión del tiempo para fijar temporizadores y añadir marcas temporales a la información persistente.

• Acceso de lectura escrita a la conexión inalámbrica del dispositivo.

• Medios para obtener la información introducida por el usuario a través de los dispositivos de entrada.

• Soporte a gráficos basados en mapas de bits.

• Medios para gestionar el ciclo de vida de una aplicación (inicio, interrupción, reactivación y destrucción).

Las aplicaciones que realizamos utilizando MIDP reciben el nombre de MIDlets (por simpatía con APPlets). Decimos así que un MIDlet es una aplicación Java realizada con el perfil MIDP sobre la configuración CLDC.

6.3 MIDLET

6.3.1 ¿QUE ES UN MIDLET?

Un MIDlet es una aplicación Java ME desarrollada sobre el perfil MID, es decir, una aplicación para dispositivos móviles cuyas limitaciones caen dentro de la especificación MIDP. Gracias a la filosofía Java (“write once, run anywhere”) podemos ejecutarlas sobre un amplio rango de dispositivos sin realizar ninguna modificación. Para que esta portabilidad sea realidad la especificación MIDP ha definido los siguientes requisitos:

Todos los dispositivos de información móviles deben contar con un módulo software encargado de la gestión de los MIDlets (cargarlos, ejecutarlos…). Este software es denominado gestor de aplicaciones. El gestor de aplicaciones recibe diversos acrónimos, entre ellos: AMS (Application Management System), JAM (Java Application Management) o GAJ (Gestor de Aplicaciones Java)..

Todos los MIDlet deben ofrecer la misma interfaz a todos los gestores de aplicaciones. Así, independientemente de la funcionalidad interna que implementen (un juego, una agenda,…), a los dispositivos pueden identificar a los MIDlet y realizar acciones sobre ellos. Este comportamiento se consigue mediante el mecanismo de herencia: todos los MIDlets heredan de la misma clase, javax.microedition.midlet.MIDlet.


6.3.2 GESTOR DE APLICACIONES

El gestor de aplicaciones es el software encargado de gestionar los MIDlets. Este software reside en el dispositivo y es el que nos permite ejecutar, pausar o destruir nuestras aplicaciones Java ME.

En la especificación no se indica que implementación concreta debe tener un gestor de aplicaciones. En su lugar, se describen las principales funciones que debe realizar, siendo finalmente los fabricantes quienes se encarguen de desarrollar gestores de aplicaciones específicos para sus dispositivos.

El gestor de aplicaciones realiza dos grandes funciones:

• Gestión de las aplicaciones.

• Gestión de estados de las aplicaciones.

6.3.2.1 Gestión de las aplicaciones

Las principales funciones que realiza un gestor de aplicaciones son la carga, instalación, ejecución, actualización y desinstalación del MIDlet.

1. Carga Los gestores de aplicaciones proporcionan mecanismos para obtener MIDlet de distintas fuentes, bien sea Internet o desde un sistema de ficheros local. Sin esta funcionalidad solo tendríamos los MIDlet incluidos por el fabricante.

Entre los posibles mecanismos de carga que podemos encontrar tenemos:

• El cable.

• La tecnología inalámbrica.

Se puede tener un dispositivo con más de un método para cargar MIDlet. En este caso, el proceso de carga incluye una fase intermedia de selección, donde podemos elegir cual usar.

2. Instalación Una vez obtenido el MIDlet, el gestor de aplicaciones se encarga de su instalación. Este proceso puede variar dependiendo del tipo de dispositivo aunque suele incluir comprobaciones de seguridad y adaptaciones del modelo de almacenamiento concreto del dispositivo.

3. Ejecución El gestor de aplicaciones es el encargado de iniciar la ejecución de los MIDlet. Además cuenta con facilidades para interrumpir y reanudar esta ejecución en función del estado del dispositivo.

4. Actualización Para poder disfrutar de nuevas versiones de un MIDlet el gestor de aplicaciones proporciona facilidades de actualización y gestión de las versiones. Antes de instalar una nueva versión preguntara al usuario si este desea actualizar recuperando la antigua.

5. Desinstalación Los gestores de aplicaciones permiten desinstalar los MIDlet, liberando los recursos reservados (memoria ocupada por el MIDlet y datos almacenados durante su utilización).


6.3.2.2 Gestión de estados del MIDlet

Los gestores de aplicaciones adaptan el funcionamiento de los MIDlet a los entornos concretos de ejecución de los dispositivos móviles. Los dispositivos se dedican a otras actividades además de ejecutar aplicaciones (por ejemplo por una llamada telefónica, enviar sms…). La especificación MIDP ha tenido en cuenta esta situación y ha dotado a los MIDlet de la capacidad de ser interrumpidos y lanzados repetidas veces sin que se vea afectado su comportamiento.

La interacción del entorno de ejecución con los MIDlet se realiza mediante llamadas que el gestor de aplicaciones realiza a unas funciones predeterminadas comunes a todos los MIDlet. Estas llamadas permiten que el MIDlet pase de un estado de ejecución a otro de forma controlada, manteniendo la integridad de la información y siempre de acuerdo a unas transiciones establecidas en el denominado ciclo de vida de los MIDlet. En cada una de estas transiciones el gestor de aplicaciones es el encargado de almacenar el estado de los MIDlet.

6.3.3 CICLO DE VIDA DE UN MIDLET

Los MIDlet pasan por distintos estados a lo largo de su ejecución, desde su inicio hasta su finalización. El ciclo de vida de un MIDlet describe todos sus estados, así como los eventos que disparan las transiciones entre ellos.

Los tres estados por los que pasa un MIDlet durante un ciclo de vida son:

Ilustración 37: Estados de un MIDlet

1. Estado de Espera: Un MIDlet se encuentra en estado de espera cuando es interrumpido por el gestor de aplicaciones y también durante un breve periodo de tiempo al inicio de la aplicación, entre la llamada al método de creación del MIDlet y el inicio de la ejecución.

2. Estado Activado: Un MIDlet se encuentra activado durante su ejecución normal. Se puede llegar aquí tanto al inicio de una ejecución como después de una interrupción.


3. Estado Destruido: Cuando un MIDlet termina su ejecución pasa al estado de destruido.

Todos los cambios de estado de un MIDlet son realizados por el gestor de aplicaciones. Sin embargo, también los MIDlet pueden solicitar un cambio de estado al gestor de aplicaciones como consecuencia, por ejemplo, de una acción de usuario. Para facilitar estos cambios de estado los MIDlet cuentan con los siguientes métodos.

Tabla 11: Funciones de cambio de estado Estado Llamar antes de pasar a… Solicitud de cambio al estado…

Activo startApp() resumeRequest() Espera pauseApp() notifyPause() Destruido destroyApp() notifyDestroy()

Es responsabilidad del programador incluir en estos métodos el código necesario para mantener la consistencia de la aplicación (borrar registros, inicializar variables, abrir o cerrar conexiones…).

6.3.3.1 Pasos que constituyen el ciclo de vida habitual de un MIDlet.

Paso 1: La aplicación es creada por el gestor de aplicaciones, y tras pasar por el estado de espera, es movido inmediatamente al estado activado al retornar correctamente la llamada al método startApp().

Paso 2: El MIDlet se ejecuta normalmente hasta que surge un evento externo que obliga al gestor de aplicaciones a pararlo, justo después del retorno sin problemas de la función pauseApp().

Paso 3: El gestor de aplicaciones decide continuar con la ejecución de la aplicación por lo que llama de nuevo al método startApp(), y cambia el estado del MIDlet a activado.

Paso 4: El usuario selecciona la opción de salir del programa por lo que el MIDlet libera sus recursos e informa al gestor de aplicaciones que desea pasar al estado de destruido, mediante una llamada a notifyDestroyed(). Inmediatamente después el gestor finaliza la ejecución del MIDlet.

6.3.3.2 Estructura de un MIDlet

Una vez comprendidos los conceptos del gestor de aplicaciones y del ciclo de vida se puede ver el aspecto que tiene un MIDlet real.

Los MIDlet tienen la siguiente estructura: import javax.microedition.midlet.* public class MiMidlet extends MIDlet { public MiMidlet() { /* Éste es el constructor de clase. Aquí debemos


inicializar nuestras variables. */ } public startApp(){ /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo se active. */ } public pauseApp(){ /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo entre en el estado de pausa (Opcional). */ } public destroyApp(){ /* Aquí incluiremos el código que queremos que el MIDlet ejecute cuándo sea destruido. Normalmente aquí se liberaran los recursos ocupados por el MIDlet como memoria, etc. (Opcional) */ } }

Del código anterior, se puede destacar los siguientes elementos de código, comunes a todo MIDlet:

Se importan todas las clases del paquete javax.microedition.midlet (MIDlety MIDletStateChangeExeption)

Todos los MIDlet heredan de la clase javax.microedition.midlet.MIDlet. Gracias a esta herencia, todos presenta un mismo interfaz que permite su gestión independientemente del entorno de ejecución.

Los MIDlets, al igual que los applets carecen de la función main(). Aunque existiese, el gestor de aplicaciones la ignoraría por completo.

Un MIDlet tampoco puede realizar una llamada a System.exit(). Una llamada a este método lanzaría la excepción SecurityException.

Debemos implementar obligatoriamente las funciones abstractas startApp(), pauseApp()y destroyApp().

Tabla 12: Métodos de la clase MIDlet Método Descripción

protected MIDlet() Constructor de la clase Protected abstract void destroyApp(bolean unconditional)

Llamada previa a la finalización de la ejecución

Public final String getAppProperty(String key)

Recupera el valor de una variable del fichero descriptor

public final void notifyDestroy() Solicita al gestor de aplicaciones pasar al estado Destruido public void notifyPaused() Solicita al gestor de aplicaciones pasar al estado de Espera


protected abstract void pauseApp() Llamada previa al paso de Espera public final void resumeRequest() Solicita al gestor de aplicaciones volver al estado Activado protected abstract void starApp() Llamada previa al paso al estado Activado

6.3.3.3 Descripción de los métodos más importantes de la clase MIDlet. protected abstract void startApp() throws MIDletstateChangeException

Este método indica al MIDlet que ha entrado en el estado “Activo”. Este método sólo puede ser invocado cuándo el MIDlet está en el estado de “Pausa”. En el caso de que el MIDlet no pueda pasar al estado “Activo” en este momento pero si pueda hacerlo en un momento posterior, se lanzaría la excepción MIDletstateChangeException. A través de los métodos anteriores se establece una comunicación entre el gestor de aplicaciones y el MIDlet. Por un lado tenemos que los métodos startApp(), pauseApp() y destroyApp() los utiliza el gestor de aplicaciones para comunicarse con el MIDlet, mientras que los métodos resumeRequest(), notifyPaused() y notifyDestroyed() los utiliza el MIDlet para comunicarse con el gestor de aplicaciones. protected abstract void pauseApp()

Indica al MIDlet que entre en el estado de “Pausa”. Este método sólo debe ser llamado cuándo el MIDlet esté en estado “Activo”. Este método se puede aprovechar para guardar información que pudiera perderse durante la interrupción del MIDlet. Si ocurre una excepción RuntimeExceptiondurante la llamada a MIDlet.pauseApp(), el MIDlet será destruido inmediatamente. Se llamará a su método MIDlet.destroyApp() para liberar los recursos ocupados. protected abstract void destroyApp(boolean incondicional) throws MIDletstateChangeException

Indica la terminación del MIDlet y su paso al estado de “Destruido”. En el estado de “Destruido” el MIDlet debe liberar todos los recursos y salvar cualquier dato en el almacenamiento persistente que deba ser guardado. Este método puede ser llamado desde los estados “Pausa” o “Activo”.

Si el parámetro ‘incondicional’ es false, el MIDlet puede lanzar la excepción MIDletstateChangeException para indicar que no puede ser destruido en este momento. Si es true, el MIDlet asume su estado de destruido independientemente de como finalice el método.

6.3.3.4 Otros métodos de la clase MIDlet.

Estos métodos que proporcionan mecanismos adicionales se pueden dividir en dos grupos:


• Peticiones de cambio de estado: estos métodos permiten a los MIDlet solicitar al gestor de aplicaciones un cambio de estado. Son: notifyPaused(), notifyDestroyed()y resumeRequest().

• Acceso a variables de entorno: gracias a la función getAppProperty() los MIDlet pueden recuperar variables almacenadas en el fichero descriptor (.jad). La gran utilidad que nos aporta este método es poder configurar el comportamiento de un MIDlet sin necesidad de recompilarlo y empaquetarlo de nuevo. Basta con sacar al fichero descriptor las variables que determinan el comportamiento y recuperarlas al inicio de la ejecución. Se puede cambiar el funcionamiento del MIDlet, cambiando el valor de las variables editando el fichero descriptor.

6.4 INTERFACES DE USUARIO

6.4.1 INTRODUCCIÓN A LAS INTERFACES DE USUARIO

• Los dispositivos MIDP tienen unas características que hace que sus interfaces gráficas difieran de los ordenadores de sobremesa:

• Cuentan con grades limitaciones en capacidad de proceso, tamaño de ventana y memoria.

• Los MIDlet deben de ser fáciles de usar. No se puede suponer que todos los usuarios están habituados al manejo de ordenadores. En general un MIDlet no debería ser muy distinto a las aplicaciones presentes en un teléfono móvil.

• Los MIDlet conviven en los dispositivos con otras aplicaciones. Para no confundir al usuario, deben ofrecer un aspecto similar tanto en el interfaz como en el modo de interacción.

• Los dispositivos móviles se utilizan en entornos donde no es posible mantener toda la atención sobre ellos. Por ello los programas deben facilitar su uso en estas situaciones.

Durante el proceso de especificación del MIDP, el lenguaje Java ya contaba (en su versión estándar, J2SE) con una completa API para generar interfaces de usuario, AWT (Application Windows Toolkit), además de las clases Swing. Sin embargo el MIDP Expert Group decidió definir una API especifica, ya que AWT fue ideada para su uso en ordenadores de sobremesa. Para ofrecer máxima flexibilidad a los desarrolladores esta API se dividió en dos partes: una de alto nivel (High Level API) y otra de bajo nivel (Low Level API).

6.4.1.1 API de alto nivel

Esta API fue diseñada pensando en aplicaciones de negocio, donde el MIDlet actuaría como cliente de una aplicación servidora, y teniendo como principal objeto la portabilidad. Por este motivo, incluye un conjunto de elementos genéricos (formularios, etiquetas…) que se encuentran presentes en todos los dispositivos MIDP. El precio a


pagar por esta compatibilidad es la imposibilidad de controlar aspectos estéticos, el modo de funcionamiento interno y el acceso a los mecanismos de entrada de bajo nivel.

6.4.1.2 API de bajo nivel

Esta API esta diseñada para aplicaciones, principalmente juegos, que requieren de un control total de lo que aparece por pantalla y de los mecanismos de entrada de bajo nivel del dispositivo (teclas, coordenadas del cursor…). Exprimir al máximo las capacidades de los MIDP acarrea en muchos casos problemas de compatibilidad. La API de bajo nivel nos ofrece un control casi absoluto sobre los recursos de la interfaz, con un nivel de abstracción mínimo. A cambio recae sobre el programador asegurar la compatibilidad de los programas, haciendo uso de las facilidades que la API ofrece para identificar las capacidades de cada dispositivo.

6.4.1.3 Estructura general de la API de interfaz de usuario

Las principales clases para crear interfaces de usuario en MIDP, tanto de alto como de bajo nivel, se agrupan dentro del paquete javax.microedition.lcdui y se recogen en la siguiente tabla.

Tabla 13: Clases para crear interfaces de usuario en MIDP Clase / Interfaz Descripción

Display Gestor de recursos gráficos Displayable Pantalla genérica de la interfaz de usuario Screen Pantalla genérica de la API de alto nivel TextBox Pantalla de introducción de texto List Pantalla de selección de opciones Alert Pantalla de aviso Form Pantalla de formulario Item Elemento genérico de un formulario ChoiceGroup Elemento de formulario para seleccionar opciones DataField Elemento de formulario para introducir fechas TextField Elemento de formulario para introducir texto

Gauge Elemento de formulario con forma de diagrama de barras, para introducir valores enteros pequeños

ImageItem Elemento de formulario que representa una imagen descriptiva StringItem Elemento de formulario que representa un texto descriptivo Canvas Pantalla genérica de la API de bajo nivel Command Acción genérica realizada sobre la interfaz por el usuario Ticket Texto deslizante disponible en todas las pantallas de la API de alto nivel Graphics Conjunto de herramientas para dibujar dentro de una pantalla de tipo canvas Choice Interfaz genérico que implementan las clases que permiten seleccionar opciones

La siguiente figura muestra la relación y jerarquía existente en entre las clases de la tabla anterior.


Ilustración 38: Relación entre clases de interfaz de usuario

6.4.2 FUNCIONAMIENTO DE LA INTERFAZ DE USUARIO

6.4.2.1 Una interfaz compuesta de pantallas

Las interfaces de usuario en MIDP se componen de pantallas, cada una de las cuales agrupa elementos gráficos que permite la interacción con el usuario (listas, formularios…). Existen dos tipos de pantallas en MIDP, todas ellas descendientes de la clase Displayable:

Pantallas de la API de alto nivel. Todas estas clases descienden de la clase Screen. No proporcionan ningún tipo de control sobre su apariencia, que es responsabilidad concreta de cada dispositivo. Además, encapsulan toda la gestión de eventos de bajo nivel. Se pueden dividir en predefinidas (TextBox, List y Alert) a las que no se le pueden añadir componentes adicionales y genéricas (Form) que permiten la adición de componentes como imágenes, etiquetas de texto…

Pantallas de la API de bajo nivel. Todas las pantallas de la API de bajo nivel descienden de la clase Canvas. Ofrecen al programador un control casi absoluto sobre lo que aparece en la ventana del MID. Además, dan acceso al manejo de eventos de bajo nivel.

6.4.2.2 Navegación guiada por eventos

Las interfaces de usuario en MIDP funcionan guiadas por eventos, asociadas a las acciones de los usuarios.


El funcionamiento se divide en varias fases:

1. Creación e iniciación: en esta fase se crean y se inicializan los elementos de la interfaz de usuario. Entre las acciones realizadas destacan las siguientes:

• Creación de pantallas: estas pantallas pueden ser tanto de la interfaz de alto nivel como de la de bajo nivel.

• Creación de comandos y asignación a pantallas: se crean comandos que representan acciones de usuario, mediante llamadas al constructor de la clase Command. Estos comandos se asignan a las diferentes pantallas. Finalmente, se designa un manejador de eventos para cada pantalla, al que se enviarán notificaciones cuando el usuario ejecute un comando.

2. Visualización de la primera pantalla: en esta segunda fase, se selecciona la primera pantalla a mostrar al usuario, mediante una llamada al método setCurrent() del objeto Display. Esta selección se realiza dentro del método startApp() mostrándose la pantalla inmediatamente después de que startApp() retorne correctamente.

3. Captura de eventos y toma de decisiones: después de que se muestre la pantalla inicial, los MIDlet quedan a la espera de las acciones que realice el usuario. Cuando esto sucede, el gestor de aplicaciones llama al manejador de eventos asociado a la pantalla. Este manejador identifica la acción del usuario y actúa en consecuencia. En otros, casos los eventos pueden dar paso a otra pantalla.

6.5 ALMACENAMIENTO PERSISTENTE: RMS

RMS (Record Management System o Sistema de Gestión de Registros) es el mecanismo que proporciona la especificación MIDP para que los MIDlet almacenen información persistente entre distintas ejecuciones. Esta información será guardada en el dispositivo en una zona de memoria dedicada para este propósito. La cantidad de memoria y la zona asignada para ello dependerán de cada dispositivo. RMS se ha diseñado pensando en la importancia de un sistema de almacenamiento para los MIDlet, pero teniendo en cuenta las limitaciones propias de un MID.


El concepto fundamental en RMS es el de RecordStore, que puede verse como un almacén de registros de información. Estableciendo una analogía con los sistemas de bases de datos, un RecordStore equivaldría a una tabla dentro de un modelo de datos. Algunas de sus principales características son:

• Persistencia entre ejecuciones: Un RecordStore proporciona a los MIDlet la posibilidad de almacenar información persistente entre distintas ejecuciones. Es responsabilidad del MID guardar esta información y mantener su integridad durante las operaciones de uso normales (arranque, descarga de batería, llamadas,...). También depende del MID proporcionar el lugar de almacenamiento, que es transparente para las aplicaciones.

• Asociados a suites del MIDlet: Una suite de MIDlet puede tener asociados varios RecordStore (varias tablas), los cuales pueden ser compartidos por todos los MIDlet incluidos en ella. La eliminación de una suite produce el borrado de los RecordStore asociados (no tiene sentido mantenerlos cuando no son accesibles desde ninguna otra suite). En cierto modo, el conjunto de RecordStore de una suite equivaldría a su modelo de datos.

• Identificador único y control de versiones: Cada RecordStore tiene un nombre único dentro de la suite (aunque suites distintas pueden tener RecordStore del mismo nombre). Adicionalmente, un RecordStore tiene asociados fecha y hora de la última actualización (lo que conoce como marca temporal o time stamp), además de un número de versión, actualizado con cada cambio efectuado. Esta información facilita la correcta gestión de la información almacenada tanto por los MIDlet como por la implementación.

El otro concepto clave al hablar de RMS es el de registro. Un registro en RMS es un vector de bytes de longitud variable, con un identificador numérico asociado, que se almacena en un RecordStore. Siguiendo con la comparación con una base de datos, un registro RMS equivaldría a un registro dentro de una tabla, aunque con una estructura bastante sencilla: un campo identificador y un campo de información con formato de vector de bytes.

Las propiedades de estos almacenes de registros son:

• Cada RecordStore está compuesto por cero o más registros.

• Un nombre de RecordStore es sensible a mayúsculas y minúsculas y está formado por un máximo de 32 caracteres Unicode.

• Dentro de una suite no pueden coexistir dos RecordStorecon el mismo nombre.

• Si una suite de MIDlets es borrada del dispositivo MID, todos los RecordStore pertenecientes a esa suite se borrarán.

• Es posible que un MIDlet acceda a un RecordStore creado por otra suite, siempre que ésta de permiso para ello.


6.5.1 ESTRUCTURA DE LA API DE RMS

La API de RMS cuenta con apenas diez componentes, entre clases e interfaces, que se agrupan en el paquete javax.microedition.rms.

Tabla 14: Clases que componen el paquete javax.microedition.rms Clase / Interfaz Descripción

RecordStore Clase que representa un RecordStore RecordEnumeration Interfaz que define métodos para desplazarse por los registros de

un RecordStore RecordComparator Interfaz que define un método para comparar registros RecordFilter Interfaz que define un método para seleccionar registros RecordListener Interfaz para crear un manejador de eventos asociados a las

modificaciones en un RecordStore RecordStoreException Excepción de la que derivan todas las demás de RMS InvalidRecordIDException Excepción lanzada cuando un identificador de registro no existe

RecordStoreFullException Excepción lanzada cuando se llena el espacio de almacenamiento RecordStoreNotFoundException Excepción lanzada cuando un RecordStore no se encuentra RecordStoreNotOpenException Excepción lanzada cuando se intenta realizar una operación

sobre un RecordStore que este cerrado

Se pueden distinguir tres tipos de clases dentro de RMS:

• La clase RecordStore: Es la clase más importante del paquete y proporciona todos los métodos necesarios para manejar un RecordStorey sus registros asociados.

• Interfaces de soporte: RecordEnumeration, RecordComparator, RecordFilter y RecordListener son interfaces que definen métodos de ayuda al manejo de RecordStore. Los tres primeros facilitan el recorrido por los registros, permitiendo establecer ordenaciones y filtros de selección entre ellos. Por su parte, RecordListener permite crear manejadores de eventos, asociados a las modificaciones realizadas sobre un RecordStore.

• Excepciones: RMS proporciona un conjunto de excepciones específicas para tratar las situaciones anómalas que se puedan presentar durante la ejecución de un programa, desde el acceso a un RecordStore cerrado a la falta de espacio de almacenamiento.

6.5.1.1 Métodos generales de la RecordStore

La clase RecordStore representa un conjunto de registros de información, que sirven a los MIDlet de mecanismo de almacenamiento persistente entre distintas ejecuciones. Para facilitar el acceso y la gestión de toda esta información la clase RecordStore proporciona diversos métodos que permite desde la creación de registros hasta su eliminación, pasando por operaciones de lectura y modificación. Estos métodos se pueden dividir en cuatro grupos: métodos generales, operaciones básicas con registros, desplazamiento entre registros y gestión de eventos.


Los métodos generales permiten crear, cerrar y obtener información de un RecordStore. Además, se incluyen métodos de clase (no asociados a ningún objeto) para obtener la lista de los RecordStore existentes en el MID y permitir el borrado de estos almacenes de información.

La clase RecordStore no tiene un método constructor. En su lugar se proporciona un método de clase openRecordStore(), que abre un RecordStore o lo crea en caso de que no exista. Una vez abierto un RecordStore, se pueden realizar sobre él varias operaciones relacionadas con registros (operaciones básicas con registros) finalizando con una llamada a closeRecordStore(), que lo cierra.

Existen métodos que devuelven información sobre el RecordStore. La API proporciona métodos para las siguientes propiedades:

Nombre: Los RecordStore tienen asociados un nombre único dentro de cada suite. Este puede obtenerse con el método getName().

Versión: Los RecordStore tienen asociado un número de versión (un entero positivo), que se actualiza con cada operación de modificación realizada sobre él. Este valor cobra especial importancia en entornos donde varios MIDlet de una misma suite accedan a un mismo RecordStore, y necesiten saber si se han producido o no modificaciones. El acceso al número de versión se realiza con el método getVersion().

Fecha y hora de la última modificación: Esta propiedad almacena la fecha y hora de la última modificación del RecordStore, en formato de entero largo (milisegundos transcurridos desde el 1 de enero de 1970). Este valor es accesible mediante el método getLastModified().

Tamaño: Número de bytes del espacio de almacenamiento ocupados por el RecordStore. Este valor incluye tanto el espacio ocupado por los registros como por las estructuras de datos asociadas, obteniéndose mediante el método getSize().

Espacio libre: Espacio libre disponible (en bytes) para añadir más registros al RecordStore, obtenido mediante una llamada a getSizeAvailable().

6.5.2 OPERACIONES BÁSICAS CON REGISTROS

La principal utilidad de un RecordStore reside en las posibilidades que ofrece para almacenar y gestionar registros de información. Entre las operaciones que proporciona están la inserción y eliminación de registros y su modificación y lectura.

Para trabajar con registros hay que tener en cuenta las siguientes observaciones:

Cuando se añade un registro a un RecordStore, recibe un identificador único (un entero positivo), que es devuelto por el método addRecord(). El primer registro recibe como identificador el valor 1, y los sucesivos aumentan en una unidad cada vez que se insertan, no pudiendo reutilizarse cuando se producen operaciones de borrado. Gracias a este identificador, es posible acceder de forma directa a cualquier registro.


Los RecordStore no proporcionan ningún mecanismo de bloqueo para acceder a los registros. La especificación simplemente asegura que las operaciones se realizan de forma secuencial, síncrona y atómica. Es responsabilidad del programador establecer los mecanismos de bloqueo necesarios para mantener la consistencia de los datos cuando varios threads accedan simultáneamente a un mismo RecordStore.

Los métodos más importantes son aquellos que permiten manejar registros directamente, utilizando vectores de bytes para almacenar la información.

Más factible que trabajar con vectores de bytes es trabajar con la clases Stream, estas clases se encargan de la conversión de los formatos, permitiendo al programador trabajar directamente con los tipos originales (string, int, long…) utilizados en el programa.

6.5.3 DESPLAZAMIENTO ENTRE REGISTROS DE UN RECORDSTORE

Esta es la funcionalidad más potente que proporciona el RMS. Para ello, la especificación ha definido la interfaz RecordEnumeration cuyos métodos proporcionan facilidades para moverse entre los registros de un RecordStore.

Para poder utilizar los métodos de RecordEnumeration es necesario obtener previamente un objeto que implemente esta interfaz. Para ello, la clase RecordStore nos ofrece un método específico (enumerateRecord) para devolver objetos de este tipo. Un objeto RecordEnumeration obtenido de esta forma mantiene internamente una lista de identificadores de los registros del RecordStore, incluyendo un puntero que permite un rápido desplazamiento bidireccional.

Se puede decidir que registros del RecordStore aparecen en RecordEnumeration usando la interfaz de RecorFilter, filtrando los registros no deseados. Por otro lado, es posible establecer criterios de ordenación sobre los registros del RecordStore que aparecen en RecordEnumeration. Para tal efecto se hace uso de la interfaz RecordComparator.

6.5.4 GESTIÓN DE EVENTOS DE UN RECORDSTORE

Hay ocasiones en que interesa realizar acciones asociadas a los cambios producidos en un RecordStore. Para ello RMS nos proporcional una interfaz, RecordListener, que permite crear manejadores de eventos asociados a un RecordStore. Es posible añadir y eliminar manejadores del RecordStore. Los manejadores asociados a un RecordStore facilitan un mantenimiento de la consistencia de la información entre distintas operaciones.

Estas son los elementos que ofrecen el paquete javax.microedition.rms para la gestión de la información persistente de un MIDlet.


6.6 ACCESO A REDES DESDE MIDP

6.6.1 INTRODUCCIÓN

La posibilidad de llevar un dispositivo que ocupa poco espacio y que permite además comunicarse en cualquier momento y lugar abre un abanico de posibles aplicaciones que no se podrían disfrutar en un PC de sobremesa, ni tan siquiera en un ordenador portátil.

El gran potencial de los dispositivos MID es la posibilidad de conexión en cualquier momento y transferir cualquier tipo de información mientras dure esa conexión.

6.6.2 GENERIC CONNECTION FRAMEWORK

Proporcionar conectividad en un entorno de recursos tan limitados como son los dispositivos con configuración CLDC no es una tarea sencilla. Destacan dos problemas:

El tamaño de la API de conectividad de J2SE (java.io.* y java.net.*): es demasiado grande para ajustarse a las limitaciones de memoria de los dispositivos abarcados en la especificación CLDC.

Hay una gran variedad de dispositivos móviles con capacidades y protocolos de conectividad distintos, dependiendo en gran medida de las infraestructuras inalámbricas disponibles. Además este número no deja de aumentar.

Además hay que añadir ciertas restricciones propias de la filosofía de diseño seguida en Java ME, como con la definición de interfaces de programación sencillas y estables y la eliminación de ambigüedades que abran la puerta a incompatibilidades entre los programas. El resultado final ha sido la definición de una nueva API, el Generic Connection Framework (GCF), basado en:

En lugar de múltiples clases adaptadas a diferentes protocolos y mecanismos de comunicación, el GCF define una abstracción del concepto de conexión, que oculta al programador los detalles concretos de los distintos protocolos.

El núcleo del GCF se localiza en la capa de configuración y se compone de elementos genéricos, sin sugerir ni proporcionar protocolos de comunicación específicos. Son los perfiles quienes extienden el GCF con interfaces adicionales y proporcionan implementaciones concretas de protocolos.

6.6.3 ESTRUCTURA DE LA GENERIC CONECTION FRAMEWORK

El GCF se basa en el concepto de conexión, que puede definirse como un canal de comunicación, independientemente del protocolo de bajo nivel utilizado. Las conexiones se crean mediante una única llamada al método estático open() de la clase Connector. Como resultado de esta llamada, la clase Connector devuelve un objeto que implementa una de las interfaces genéricas de conexión definidas en el GCF, con capacidad de manejar el protocolo seleccionado.


A continuación, se muestra la jerarquía de las interfaces de conexión del GCF incluidas en el CLDC

Ilustración 39: jerarquía de las interfaces de conexión del GCF

6.6.4 CONECTIVIDAD EN MIDP

MIDP amplia el GCF con la interfaz HttpConnection. Además, MIDP incluye en su especificación la exigencia de que todas las implementaciones incluyan soporte al protocolo HTTP 1.1 abriendo las puertas a la conectividad en los MIDlet.

La disponibilidad de implementaciones de HTTP en todos los MID compatibles MIDP tiene las siguientes consecuencias:

Cualquier MIDlet que utilice las conexiones basadas en HTTP y las interfaces definidas en GCF es portable entre distintos dispositivos MIDP. La disponibilidad del protocolo HTTP no impide que los fabricantes añadan otros adicionales (como sockets o datagram) que pueden ser utilizados en programas a costa de sacrificar portabilidad.

Si se desea mantener compatibilidad y, al mismo tiempo, acceder a servicios que utilicen protocolos distintos de HTTP (como el correo electrónico), es necesario colocar una pasarela en la parte servidora (gateway).


6.7 ACCESO A LA TARJETA SIM: SATSA API

En este capítulo se describe la API de Seguridad y Servicios de Confianza (SATSA, Security And Trust Services API). Esta API nos va a permitir, entre otras cosas, establecer una comunicación entre el móvil y la tarjeta SIM.

6.7.1 INTRODUCCIÓN

Introducido con el JSR (Java Specification Request) 177, la API de seguridad y servicios de confianza (SATSA) proporciona APIs para la comunicación con todos los elementos de seguridad, así como APIs de seguridad para la gestión de firmas digitales, de certificados digitales, y de operaciones criptográficas.

SATSA acerca los dispositivos Java ME a los dispositivos Java Card. Se definen cuatro paquetes opcionales según lo ilustrado en el cuadro siguiente:

Ilustración 40: SATSA APIs

Dos de paquetes de SATSA, junto con el marco de conexión genérica (GCF, Generc Connection Framework), proporcionan un API que permite que las aplicaciones de Java ME se comuniquen con los elementos de seguridad tales como Java Cards, el módulo de identificación universal del suscriptor (USIM) y las Smart Cards de seguridad.

Los otros dos paquetes opcionales proporcionan la seguridad APIs para manejar las firmas digitales, credenciales del usuario (certificados digitales), y realizan operaciones de la criptografía. Las tablas siguientes resumen las APIs de SATSA:

Tabla 15: API de comunicación, SATSA-APDU Nombre del paquete Descripción

javax.microedition.apdu Define la interfaz de APDUConnection, para la comunicación basada en ISO7816-4-APDU.


Tabla 16: API de comunicación, SATSA-JCRMI Nombre del paquete Descripción

java.rmi Subconjunto del paquete de J2SE java.rmi, define el interfaz Remote y el RemoteException.

javacard.framework Subconjunto de la API Java Card, incluye un número de excepciones del marco del API de Java Card.

javacard.framework.service Subconjunto de la API Java Card, incluye una excepción de servicio del API de Java Card.

javacard.security Subconjunto de la API Java Card, incluye una excepción de criptografia del API de Java Card.

javax.microedition.jcrmi Define la interfaz JavaCardRMIConnection, para la comunicación basada en RMI, la interfaz RemoteRef, una manija para un objeto remoto, y la clase RemoteStub, una super-clase para stubs.

Tabla 17: API de Servicios de firma SATSA-PKI Nombre del paquete Descripción

javax.microedition.pki Define la clase UserCredentialManager, encargada de los credenciales / certificado, y UserCredentialManagerException.

javax.microedition.securityservice Define la clase CMSMessageSignatureService, que proporciona métodos para crear firmas y contenidos firmados, y el CMSMessageSignatureServiceException.

Tabla 18: API de criptografía SATSA-CRYPTO Nombre del paquete Descripción

java.security Un subconjunto del paquete de J2SE java.security, define clases e interfaces para el marco de seguridad tales como las interfaces Key y PublicKey, y las clases KeyFactory, MessageDigest y Signature.

java.security.spec Un subconjunto del paquete de J2SE java.security.spec, define clases e interfaces para las especificaciones de claves y de algoritmos de parámetro tales como EncodedKeySpec, X509EncodedKeySpec, AlgorithmParameterSpec y KeySpec.

javax.crypto Un subconjunto del paquete de J2SE javax.crypto, define la clase Cipher para el cifrado / descifrado, y varias excepciones criptográficas.

javax.crypto.spec Un subconjunto del paquete de J2SE javax.crypto.spec, define las clases para las especificaciones de clave.

Tabla 19: Marco de conexión genérica Nombre del paquete Descripción

javax.microedition.io Conector de GCF con soporte específico para conexión jcrmi: y apdu:

6.7.2 DESCRIPCIÓN DE LAS API’S DE COMUNICACIÓN

La API de comunicación de SATSA soporta la comunicación con las smart cards usando los métodos siguientes:


• Protocolo APDU (Application Protocol Data Unit).

• Protocolo JCRMI de Java Card 2.2.

Además, SATSA soporta la comunicación con el pack de aplicaciones del módulo de identificación universal de usuario (USIM), USAT (USIM Application Toolkit), usando el protocolo APDU. Las tarjetas (U)SIM son las pequeñas smart cards usadas en los teléfonos móviles, que contienen los detalles del suscriptor, la información de la seguridad e incluso memoria del almacenaje. Con los permisos apropiados, una aplicación Java ME puede tener acceso a una funcionalidad que reside en la tarjeta SIM tal como la agenda del teléfono o applets

La comunicación entre una aplicación Java ME y una smart card se basa en un modelo de petición/respuesta síncrona, donde la aplicación Java ME es el cliente, y la aplicación Java Card es el servidor:

Ilustración 41: Modelo de comunicación de SATSA

La pila de la comunicación en el teléfono y la tarjeta, ambas soportan la ISO 7816 (1-4). La API de SATSA se basa en ISO 7816-4 APDU, los paquetes lógicos de datos que se intercambian entre la aplicación Java ME y el marco de Java Card. El marco de Java Card recibe y remite a la aplicación Java Card apropiada de la tarjeta cualquier APDU de comando entrante enviada por la aplicación Java ME. La aplicación Java Card procesa la APDU de comando, y devuelve una APDU de respuesta. Este modelo de intercambio de mensajes comando/respuesta es la base para todas las comunicaciones con smart cards.

SATSA utiliza el marco de conexión genérica (GCF, Generis Conection Framework) para la entrada-salida, para lo cual introduce dos interfaces de conexión de GCF, según lo ilustrado seguidamente.

Los desarrolladores experimentados en Java Card encontrarán las comunicaciones de la API de SATSA un territorio familiar. Con sus dos interfaces de GCF, SATSA abastece a ambos modelos de programación totales para las aplicaciones de las Java Cards: el modelo de mensaje APDU y el modelo distribuido, orientado a objeto, Java Card RMI:

• APDUConnection permite que una aplicación Java ME intercambie APDUs por una aplicación de una smart card usando la ISO 7816-4 APDUs.

• JavaCardRMIConnection permite que una aplicación Java ME utilice la API de cliente Java Card RMI para invocar métodos remotos en una Java Card permitida.


Ilustración 42: El marco de conexión genérica y conexiones de SATSA

6.7.2.1 Especificación de los tipos de conexión de SATSA

Las conexiones de GCF son creadas llamando el método de fábrica Connector.open(). Una de los argumentos de Connector.open() es la URL de la conexión que indica el tipo de conexión para crear. La secuencia de la conexión del URL de SATSA tiene el formato siguiente:

protocolo: [slotID]; destino

Donde:

• protocolo es “apud” para una conexión basada en APDU, o “jcrmi” para una conexión basada en JCRMI.

• slotID es el número que indica la ranura en la cual se inserta la tarjeta. El campo del slotID es opcional; por defecto se toma la ranura número 0, y puede ser descubierto como se describe más abajo.

• destino es un identificador de aplicación (AID, Application Identifier) para una smart card, o es la palabra “SAT”. Un AID es una cadena de cinco a 16 bytes hexadecimales separados por períodos; por ejemplo, “0.0.0.67.4.7.1F.3.2C.3”. El AID se debe saber de antemano. SAT indica una conexión con el SIM Aplication Toolkit.


Puesto que un teléfono móvil puede soportar más de una tarjeta SIM, SATSA define una característica especial para descubrir las ranuras de tarjetas disponibles. Esta característica, llamada microedition.smartcardslots, puede ser preguntada llamando el método System.getProperty() que vuelve una lista de ranuras disponibles delimitadas por comas, por ejemplo:

microedition.smartcardslots: 0C, 1H

La información de la ranura devuelta consiste en dos caracteres por ranura disponible. El primer carácter es el número de la ranura que se utiliza en la secuencia del URL de la conexión. El segundo carácter indica si la ranura de tarjeta elegante es intercambiable, y si es lo es, si es intercambiable en caliente (H) o en frío (C); los medios con intercambio en caliente permiten que la tarjeta se pueda cambiar mientras que el teléfono está funcionando, en los medios intercambiables en frio, el dispositivo se debe apagar primero. En el ejemplo anterior, “0C,1H” indica la existencia de dos ranuras, de la ranura de intercambio-frío 0 y de la ranura de intercambio caliente 1.

6.7.2.2 Usando la API de comunicación de SATSA-APDU

Las comunicaciones API de SATSA realmente simplifican cómo realizar la entrada-salida con las smart cards; se basa en el fácilmente utilizable GCF, y maneja cosas tales como intercambio de comandos de selección del canal y de aplicación entre la aplicación Java ME y el dispositivo smart card.

La API de comunicaciones ISO 7816 APDU de SATSA consiste en un solo interfaz de GCF, el javax.microedition.apdu.APDUConnection. Este interfaz define métodos para introducir, cambiar, inhabilitar, y bloquear los números de identificación personal (PIN), para intercambiar APDUs con una aplicación smart card, y para leer el mensaje Answer To Reset (ATR) enviado por la tarjeta cuando esta es encendida o reseteada.

Las conexiones GCF se crean llamando el método de fábrica Connector.open(); para las conexiones de SATSA el AID y el número de la ranura se pasa opcionalmente en la secuencia del URL de la conexión. Durante la llamada del método de Connector.open(), la implementación de SATSA maneja las actividades de la aplicación Java ME tales como selección del canal y de la aplicación, enviando los comandos APDU apropiados a la smart card.

Para intercambiar APDUs de comando con una aplicación de la tarjeta, se utiliza el método exchangeAPDU(). Este método fija automáticamente el número de canal del canal asociado en el byte CLA del comando APDU, envía el comando APDU, y se bloquea hasta que se recibe una respuesta de la tarjeta o se interrumpe el proceso (InterruptedIOException). Observese que hay restricciones en los comandos APDU que se intercambian: los comandos APDU card application selection y MANAGE CHANNEL no están permitidos para ser enviados (los maneja la propia implementación de SATSA), y a fin de que así se haga, su uso nos devolverá una IllegalArgumentException.

Cuando la comunicación con la Java Card no se requiere por más tiempo, lac conexión debe ser cerrada llamando el método Connector.close(); este suelta el


canal lógico que fue adquirido cuando la conexión fue abierta para comunicarse con la tarjeta. Durante la llamada del método de Connector.close(), la implementación de SATSA maneja actividades en nombre de la aplicación Java ME, tal como la gestión del canal, enviando los comandos APDU apropiados.

El siguiente código demuestra cómo utilizar un APDUConnection para comunicarse con la aplicación de la Java Card con un AID igual a A “1.0.0.67 .4.7.1F.3.2C.5” que resida en el slot 0: // Setup the command APDU byte[] commandAPDU = ...; try { // Create an APDUConnection String url = "apdu:0;AID=A1.0.0.67.4.7.1F.3.2C.5"; APDUConnection ac = (APDUConnection) Connector.open(url); // Send a command APDU and receive a response APDU byte[] responseAPDU = ac.exchangeAPDU(commandAPDU); // Process the response ... } catch(Exception e){ // Handle Exception ... } finally { ... if (ac != null) { // Close connection. ac.close(); } }

Mientras que el formato del comando y de la respuesta APDUs es estándar y descrito en la especificación de ISO/IEC 7816, el contenido de las APDUs es específico de la aplicación

Las excepciones siguientes se pueden lanzar durante el establecimiento de la conexión de APDUConnection:

• ConnectionNotFoundException si no hay tarjeta o no está encendida.

• SecurityException si la aplicación Java ME no tiene permiso para acceder a la aplicación con el AID seleccionado.

• IOException si no hay canal lógico disponible.

• InterruptedIOException si la tarjeta fue quitada/reinsertada.

Las excepciones siguientes pueden ser lanzadas al intercambiar APDUs:

• IllegalArgumentException si el APU de comando es nulo o malformado, o contiene un comando card application selection y MANAGE CHANNEL.


• SecurityException si la aplicación Java ME no tiene los permisos para utilizar la API.

• IOException si la conexión se cierra o se encuentran errores.

• InterruptedIOException si la tarjeta fue quitada/reinsertada.

6.7.2.3 Usando la API cliente Java Card RMI de SATSA-APDU

La API cliente Java Card RMI (JCRMI) de SATSA Java (JCRMI) esta basada en la especificación 2.2 Java Card, que es un subconjunto de la API RMI de J2SE. JCRMI proporciona un modelo distribuido, en el cual se abstrae la comunicación APDU; en vez de tratar APDUs, manejas objetos. Esto simplifica la programación y la integración con dispositivos basados en tecnología Java Card.

6.7.2.3.1 Arquitectura JCRMI basada en proxy

Como con los típicos sistemas de invocación remota, la API Cliente JCRMI se basa en un patrón proxy donde los objetos remotos se representan por un tubo local y un esqueleto remoto.

Ilustración 43: del objeto remoto en el API cliente JCRMI

En este modelo, el uso de Java ME invoca métodos remotos vía tubo (stub) local y un esqueleto alejado.

El stub local es responsable de lo siguiente:

• Inicialización de la llamada al método remoto.

• Formar los parámetros del método.

• Transferir la petición y esperar el resultado del método.

• distinguir el valor o la excepción de vuelta.

• Devolver el valor al llamador. Si el valor devuelto es un objeto remoto, se devuelve una referencia a su stub local.

El esqueleto del objeto remoto es responsable de lo siguiente:

• distinguir los parámetros del método.

• Invocar el método apropiadamente.

• Formar el valor o la excepción de vuelta.


• Transferencia del resultado del método o de la excepción apropiada.

En el modelo del RMI una aplicación del servidor crea y hace accesible a los objetos remotos, y la aplicación cliente obtiene referencias remotas a los objetos remotos del servidor, y después invoca métodos remotos en ellos. En SATSA JCRMI, el applet de la Java Card es el servidor, y la aplicación Java ME es el cliente. La imagen siguiente describe más detalladamente los elementos y el flujo de JCRMI:

Ilustración 44: Elementos y flujo de la API cliente JCRMI

La ilustración anterior muestra un entorno Java ME con una aplicación cliente de Java ME, stubs de objetos remotos, y un entorno de ejecución JCRMI que junto con el stub traduce una invocación remota a APDUs. En la Java Card, las APDUs son recibidas y enviadas al servicio JCRMI RMI, que traduce APDUs a llamadas de métodos en objetos poseídos por la aplicación de la Java Card.

Una herramienta generadora de stubs se utiliza típicamente para generar el stub de JCRMI. Los generadores del stubs no se discuten en este artículo, sino que es suficiente decir que eso crear clases alejadas y sus trozos relacionados es similar al método en J2SE RMI: Se escribe una interfaz específica de aplicación que implementa java.rmi.Remote. Se escribe una clase concreta que implemente lo expuesto anteriormente, y el generador de stub de JCRMI se invoca para generar el stub y el esqueleto.

6.7.2.3.2 JCRMI APIs

Desde la perspectiva del API, el API cliente JCRMI de SATSA consiste en interfaces de stubs y de aplicación:

• Los interfaces de stub, usados principalmente por los stubs locales y usados raramente por las aplicaciones Java ME directamente, definen la interfaz referencia remota (RemoteRef) y la super clase stub remoto (RemoteStub), ambas definidas en el paquete javax.microedition.jcrmi.

• Las interfaces de aplicación incluyen la interfaz GCF javax.microedition.jcrmi.JavaCardRMIConnection para la


invocación remota del método de JCRMI, un subconjunto de GCF del paquete de J2SE java.rmi.

• Otras clases o interfaces incluyen la interfaz Remote y la clase RemoteException, así como algunas clases de excepción específicas de la tarjeta, que puedan ser lanzadas al invocar el método remoto en la Java Card.

La clase de JavaCardRMIConnection define, como el nombre indica, un tipo de conexión GCF del tipo RMI Java Card (JCRMI). JavaCardRMIConnection define métodos para establecer, cambiar, inhabilitar y bloquear los números de identificación personales (PIN). También define el método getInitialReference(), que devuelve el stub del applet seleccionado de la para una referencia remota inicial.

El código siguiente muestra cómo crear un JavaCardRMIConnection para comunicarse con una aplicación de la tarjeta con un AID igual a “A1.0.0.67 .4.7.1F.3.2C.5” que resida en la ranura 0. Una vez que se haya instanciado un JavaCardRMIConnectio, y obtenida la referencia al objeto remoto, los métodos remotos apropiados puede ser invocados: import com.j2medeveloper.MyRemoteObject; ... try { // Create a JavaCardRMIConnection String url = "jcrmi:0;AID=A0.0.0.67.4.7.1F.3.2C.3"; JavaCardRMIConnection jc=(JavaCardRMIConnection)Connector.open(url); MyRemoteObject robj = (MyRemoteObject) jc.getInitialReference(); : short result = robj.myRemoteMethod(); : } catch(Exception e){ // Handle Exception ... } finally { ... if (jc != null) { // Close connection jc.close(); } }

El anterior código, muestra cómo conseguir una referencia a MyRemoteObject llamando al método getInitialReference(), y haciendo el correspondiente casting a la referencia devuelta. El método myRemoteMethod() entonces se invoca, que devuelve un short. Todos los detalles relacionados con la forma de los datos y los intercambios subyacentes de APDUs son llevados por la implementación de SATSA JCRMI. Finalmente la conexión se cierra, liberando el canal lógico que fue adquirido para comunicarse con la Java Card cuando se abrió la conexión; según lo mencionado previamente, cuando se cierra la conexión, SATSA gestiona automáticamente el intercambio de comandos APDU para la gerencia de canal.

Debido a la naturaleza restringida del entorno Java Card, hay algunos requisitos a ser tenidos en cuenta:


• Hasta 15 interfaces pueden ser implementadas por una clase remota, directamente o indirectamente.

• Solamente los tipos de datos siguientes se pueden utilizar como parámetros o datos devueltos durante la invocación remota del método: boolean, byte, short, int, y arrays de una dimensión de los mismos tipos. Además, para los valores de retorno, las interfaces void y Remote son válidas. Observar que el soporte para int es opcional, según lo definido por la especificación Java Card. Todos los parámetros y valores de la vuelta son intercambiados por valor, a excepción de referencias remotas de objeto, que están por referencia (al stub local).

Las excepciones siguientes se pueden lanzar durante el establecimiento de la conexión de JCRMI:

• ConnectionNotFoundException si no hay tarjeta o no está encendida.

• SecurityException si la aplicación Java ME no tiene permiso de acceso a la aplicación Java Card con el AID especificado.

• IOException si no hay canal lógico disponible.

• RemoteException si la referencia inicial al objeto remoto no puede ser creada.

6.7.2.4 Permisos de MIDP 2.0

Para la comunicación de SATSA, SATSA define los permisos siguientes de MIDP 2.0:

• Para abrir una conexión de APDU: javax.microedition.apdu.aid. Este permiso se concede solamente a las aplicaciones en el operador, el fabricante, y un dominio con garantia de tercera persona.

• Para abrir una conexión de JCRMI: javax.microedition.jcrmi. Este permiso se concede solamente a las aplicaciones en el operador, el fabricante, y un dominio con garantía de tercera persona.

• Para abrir una conexión de APDU a una SIM Aplication Toolkit: javax.microedition.apdu.sat. Este permiso se concede solamente a las aplicaciones en el dominio del operador.

Las aplicaciones solicitan los permisos apropiados haciendo una entrada en el archivo JAD o MANIFEST, por ejemplo:

• MIDlet-Permisions: javax.microedition.apdu.aid, javax.microedition.apdu.sat, javax.microedition.jcrmi

Un SecurityException será lanzado al intentar utilizar una conexión sin los permisos apropiados


6.7.3 DESCRIPCIÓN DE LAS API’S DE SEGURIDAD

LasAPIs de seguridad SATSA es en parte un subconjunto de las APIs de seguridad y de criptografía de J2SE, con mucha influencia de la API de seguridad de Java Card. Las APIs de seguridad de SATSA consisten en dos paquetes separados pero relacionados opcionales de Java ME:

• El paquete opcional Infraestructura de clave pública (PKI, Public Key Infraestructure).

• El paquete opcional Criptográfico (CRYPTO).

Estas APIs permiten a las aplicaciones Java ME:

• Trabajar con certificados digitales públicos, claves públicas y privadas, resúmenes del mensaje y firmas digitales.

• Crear, almacenar, y utilizar los credenciales de usuario basados en certificados digitales X. 509.

• Cifrar los datos usando la criptografía asimétrica y simétrica.

Las dos tablas siguientes resumen los paquetes de SATSA Java. La primera tabla resume los paquetes dominantes públicos de la infraestructura de SATSA que contienen el APIs para los certificados digitales y las firmas:

Tabla 20: Paquetes de PKI, API de seguridad de SATSA Nombre del paquete Descripción

javax.microedition.pki

Clases para soportar yar la gestión básica del usuario-certificado. Define la clase UserCredentialManager que proporciona métodos para solicitar una firma de certificado (CSR), y agregar y quitar certificados del almacén de certificados. También define la clase UserCredentialManagerException de la excepción se lanza que si se encuentra un error al manejar certificados.

javax.microedition.securityservice

Clases para generar las firmas digitales a nivel de aplicación que se conforman con el formato criptográfico del sintaxis del mensaje (CMS). Define la clase CMSMessageSignatureService que proporciona métodos para generar las firmas digitales basadas en certificados. También define la clase CMSMessageSignatureServiceException de la excepción se lanza que si se encuentra un error al manejar firmas.

La tabla siguiente resume los paquetes CRYPTO de SATSA que contienen el APIs para las claves, la verificación de la firma, los resúmenes de mensaje, y el cifrado de datos públicos/privados:

Tabla 21: Paquetes de CRYPTO, API de seguridad de SATSA Nombre del paquete Descripción

java.security

Clases e interfaces para el marco de la seguridad. Un subconjunto del paquete de J2SE java.security. Define la llave y el PublicKey y las clases KeyFactory, MessageDigest, y la firma de los interfaces que proporcionan la ayuda básica para las claves públicas, los resúmenes del mensaje, y las firmas digitales.


java.security.spec

Clases e interfaces para las especificaciones de clave y las especificaciones de parámetros de algoritmo. Un subconjunto del paquete de J2SE java.security.spec. Define los interfaces AlgorithmParameterSpec y KeySpec, y las clases EncodedKeySpec y X509EncodedKeySpec para las especificaciones de clave y de parámetro de algoritmo.

javax.crypto

Clases e interfaces para las operaciones criptográficas. Un subconjunto del paquete de J2SE javax.crypto. Define la clase cipher que proporciona el soporte básico para el cifrado y el desciframiento de datos, y varias excepciones criptográficas.

javax.crypto.spec

Clases e interfaces para las especificaciones de clave. Un subconjunto del paquete de J2SE javax.crypto.spec. Define las clases IvParameterSpec y SecretKeySpec para las especificaciones de clave y de parámetro de algoritmo..

La criptografía en general tiene cuatro metas principales, todas ellas tratadas con SATSA:

• Confidencialidad o asegurar que solamente receptores autorizados puede tener acceso a la información. Esto se logra usando el cifrado de datos.

• Integridad de datos o la capacidad de detectar si la información ha cambiado. Esto es lograda usando firmas digitales.

• No-repudio o la capacidad de asegurarse de que una transacción no pueda ser negada. Esto es logrado usando el tipo de firmas de no-denegación.

• Autentificación o la capacidad de verificar la fuente de la información. Esto lograda usando el cifrado de datos y firmas digitales.

La criptografía en general se basa en el uso de las claves para la transformación del texto plano al texto cifrado y viceversa. Hay dos modelos de la criptografía: simétrica y asimétrica. La criptografía simétrica utiliza una sola llave privada, mientras que aplicaciones asimétricas dos llaves, un par de claves pública y privada. Cada modelo de la criptografía tiene pros y contras, por ejemplo, en la eficiencia o en la distribución de las claves. De la perspectiva de la eficiencia, la criptografía simétrica es más eficiente (de cómputo más rápido) que sus contrapartes asimétricas, pero de la perspectiva de la distribución de claves (cómo se comparten las llaves), la criptografía asimétrica proporciona un modelo más conveniente y más seguro porque las llaves públicas se pueden compartir según lo necesitado sin miedo de comprometer la seguridad (puesto que la llave privada puede ser guardada en secreto). Esto es contrario a la criptografía simétrica donde debemos poner cuidado especial en la distribución secreta de la clave, para no comprometer la seguridad. Debido a estas razones, la criptografía simétrica es más adecuada para el cifrado de datos, mientras que la criptografía asimétrica es más adecuada para la autentificación, las firmas digitales nos aportan la no-denegación y la integridad de datos.

Las APIs de seguridad de SATSA tratan la criptografía asimétrica para las firmas digitales, la autentificación y la no-denegación, mientras que el cifrado SATSA se encarga principalmente de la criptografía simétrica.

Hay muchos elementos e interacciones funcionales en PKI, como se muestra en la ilustración:


Ilustración 45: Elementos funcionales de PKI

1.- Entidad-extremo: un término genérico que describe al cliente del servicio PKI. En SATSA el teléfono Java ME es una entidad-extremo

2.- Certificado de autoridad (CA): una tercera parte de confianza responsable de la gestión de certificados digitales.

3.- Petición de firma del certificado (CSR): un documento generado por una entidad-extremo para la inscripción del certificado. Un CSR contiene la información sobre el usuario tal como su nombre distinguido, la clave pública (firma), y otra información. Se codifica el CSR usando las reglas de codificación distinguidas para ASN.1. Una vez que el CSR haya sido verificado por un CA, el CA genera un certificado firmado.

4.- Certificado Digital Público y ruta del certificado: un certificado digital, también designado certificado de clave pública, es el componente público en PKI. Un certificado público representa las credenciales para una entidad-extremo dada atando a un usuario específico a una clave pública. La entidad-extremo representada por un certificado mantiene la llave privada que corresponde a ese certificado. Los certificados se utilizan sobre todo para las firmas digitales para verificar el origen (autentificación), y la integridad de la información, y se pueden también utilizar para el no-repudio.

5.- Una lista de revocación de certificado (CRL): una lista de certificados revocados. Durante la validación del certificado un sostenedor del certificado comprueba con el CRL del CA apropiado para verificar el estado de la revocación para un certificado dado.


6.7.3.1 Usar las APIs de seguridad de SATSA para el cifrado de datos

Puedes pretender conectar a recursos corporativos, o intercambiar información personal; en ambos casos mantener la información en secreto, o encriptar los datos, es de vital importancia. En la web, la confidencialidad de datos se alcanza usando protocolos de red seguros, como HTTPS y TSL/SSL. En SATSA, la encriptación es completada utilizando un subconjunto de la API CRYPTO de J2SE y la clase Cipher.

Como ya se ha mencionado, la criptografía simétrica se ajusta mejor para la encriptación de datos, mientras que la criptografía asimétrica se ajusta mejor a la autenticación, no repudio e integridad de datos a través del uso de firmas digitales. La API de encriptación de SATSA soporta ambos tipos de encriptación.

6.7.3.1.1 Cifrado de clave pública (asimétrico).

Revisemos algunos conceptos. En criptografía de clave asimétrica o pública las claves públicas se distribuyen libremente según lo necesitado. En este modelo los datos se cifran usando una clave pública, y se descifran usando la clave privada correspondiente, y viceversa. La idea es que si necesito enviar un mensaje confidencial corto a alguien, cifraría el mensaje usando su clave pública. Posteriormente él utilizaría su clave privada para descifrar el mensaje.

El diagrama siguiente muestra la firma y el cifrado, que son pasos separados pero relacionados, y los resultados de estos pasos combinados en un solo mensaje cifrado y firmado.

Ilustración 46: Creación de un mensaje cifrado y firmado, usando clave pública

El descifrado es lo opuesto al cifrado. Aquí un mensaje cifrado se descifra usando la clave privada del receptor, y se descifra el resumen del mensaje (firma digital)


usando la clave pública del remitente, entonces verificada por comparación de las firmas según lo cubierto previamente:

Ilustración 47: Descifrado de un mensaje firmado con criptografía de clave pública

Observar que mientras que SATSA proporciona soporte para el cifrado asimétrico, no proporciona soporte para PrivateKey ni el descifrado asimétrico (de clave pública). Como en J2SE, el proceso de cifrado/descifrado de mensaje en SATSA también consta de tres pasos de alto nivel:

• Se genera y se inicializa un Cipher usando un algoritmo y opcionalmente un modo y un esquema de relleno. El modo de Cipher se fija para en cifrado o descifrado.

• Se llama al método Cipher.update() si se cifran o descifran en partes múltiples.

• Se llama al método Cipher.doFinal() si cifra o descifra un parte única, o la ultima del conjunto de multiples partes.


Un Cipher se genera llamando al método Cipher.getInstance(String transformation), pasando como argumento la transformación (el algoritmo y opcionalmente un modo y un esquema de relleno) a utilizar. Los nombres de la transformación se especifican en la especificación, y usan el formato siguiente:

algoritmo/modo/relleno - ó - algoritmo

Aquí, la primera forma describe completamente el algoritmo, el modo y el relleno del Cipher a utilizar, y el último describe un algoritmo con los valores prefijados de las aplicaciones para el modo y el relleno. El siguiente código demuestra brevemente cómo cifrar datos usando una clave pública: // Message to encrypt byte[] plainText = "..."; // Public Key String keyAlgo = "RSA"; byte[] someonesEncodedPublicKey = "..."; try { // Create an X.509 encoded Key specification from the // encoded public key. X509EncodedKeySpec pks; pks = new X509EncodedKeySpec(someonesEncodedPublicKey); // Get an instance of the key factory to generate a // public key object KeyFactory kf = KeyFactory.getInstance(keyAlgo); PublicKey publicKey = kf.generatePublic(pks); // Encrypt byte[] cipherText = new byte[1024]; Cipher cipher; cipher = Cipher.getInstance(publicKey.getAlgorithm()); cipher.init(Cipher.ENCRYPT_MODE, publicKey); cipher.doFinal(plainText, 0, plainText.length, cipherText, 0); } catch (Exception e) { // Handle BadPaddingException or // InvalidKeyException or // IllegalStateException or // InvalidKeySpecException or // IllegalBlockSizeException or // InvalidAlgorithmParameterException or // NoSuchPaddingException or // NoSuchAlgorithmException or // ShortBufferException ... }

Mientras que la clase Cipher de J2SE provee del método getOutputSize() que devuelve el tamaño de búfer que sería necesario para almacenar los datos encriptados, este método no se incluye en SATSA. Guardar en un buffer de texto cifrado demasiado pequeño genera una ShortBufferException.


6.7.3.1.2 Cifrado de clave privada (simétrico)

En principio, la encriptación simétrica parece más simple que su contraparte asimétrica porque el encriptado y desencriptado están basados en una única clave secreta.

Ilustración 48: Proceso de encriptado-desencriptado simétrico

Pero el uso de encriptación simétrica puede implicar más debido al número de detalles a ser considerados, como tipos de código, transformaciones (algoritmos, modos y rellenado), y el número de bits a ser procesados en un momento. Por ejemplo, los cifrados simétricos pueden ser por códigos en flujo o en bloque. Los códigos de flujo, que pueden ser más rápidos que los de bloque, operan típicamente en pequeñas unidades de texto plano, como bits. Por otra parte, los códigos de bloque operan en grandes bloques de datos. Y hay modos que tienen implicaciones de relleno, y uso de vectores de inicialización.

Y hay otras consideraciones cuando usamos criptografía simétrica como el error común en criptografía amateur señalado por Bruce Scheiner, donde el mismo keyStream nunca debe ser usado para encriptar dos documentos diferentes, de otro modo la encriptación puede romperse haciendo un XOR de los dos textos cifrados.

Una cuestión clave relacionada con la criptografía simétrica es la distribución de claves, donde se necesita un modo seguro para compartir la clave secreta. Debido a la flexibilidad ofrecida por los sistemas de clave pública en este sentido, la típica forma de compartir las claves privadas es usando encriptación de clave pública

Desde la perspectiva de la API, la encriptación simétrica se hace de forma similar a la asimétrica, vista en el apartado anterior, salvo por lo siguiente:

• El uso del objeto SecretKey, para encapsular la clave simétrica secreta.


• Dependiendo del tipo de código y del modo, se usa un Vector de Inicialización (IV, Inicialization Vector) para asegurar la correcta generación del texto cifrado.

El siguiente código muestra brevemente como encriptar datos usando una clave privada. String algo= "..."; // Symm. Cipher algorithm (DES, etc) byte[] secretKey = "..."; // Secret key bytes String secretKeyAlgorithm = "..."; // Secret key algo. byte[] iv = "..."; // The initialization vector byte[] plainText = "..."; // The plain text try { // Create the (secret) key. This method assumes // secretKey is a raw secret key represented as a byte // array, with no key parameters associated, such as // DES or Triple DES keys. Key key = new SecretKeySpec( secretKey, 0, secretKey.length, secretKeyAlgorithm); // Create the cipher. If an initialization vector was // specified, use it. Cipher cipher; cipher = Cipher.getInstance(algo); if (iv == null) { cipher.init (Cipher. ENCRYPT_MODE, key); } else { IvParameterSpec ivps; ivps = new IvParameterSpec(iv, 0, iv.length); cipher.init(Cipher.ENCRYPT_MODE, key, ivps); } // Encrypt the single-part plaintext - i.e. for multi- // part plaintext, the update() method would be called // as necessary before finishing by calling doFinal(). int ciphertextLength = ...; byte[] cipherText = new byte[ciphertextLength]; cipher.doFinal(plainText, 0, plainText.length, cipherText, 0); } catch (Exception e) { // Handle BadPaddingException or // InvalidKeyException or // IllegalStateException or // InvalidKeySpecException or // IllegalBlockSizeException or // InvalidAlgorithmParameterException or // NoSuchPaddingException or // NoSuchAlgorithmException or // ShortBufferException ... }

El anterior código debe manejar las mismas excepciones que vimos en el anterior apartado de encriptación asimétrica.

El desencriptado se hace de forma similar, excepto por:

• El Cipher se establece en decrypt mode durante su inicialización.


• Los argumentos de entrada y salida de los métodos update() y doFinal() están al revés si los comparamos con la encriptación: para la entrada tenemos el texto cifrado, y para la salida tenemos el texto plano.

: : // Create the cipher. If an initialization vector was // specified, use it. Cipher cipher = Cipher.getInstance(algo); if (iv == null) { cipher.init (Cipher. DECRYPT_MODE, key); } else { IvParameterSpec ivps; ivps = new IvParameterSpec(iv, 0, iv.length); cipher.init(Cipher.DECRYPT_MODE, key, ivps); } // Decrypt byte[] plainText = new byte[...]; cipher.doFinal(ciphertext, 0, ciphertext.length, plainText, 0);

En general, cuando usamos códigos, se deben manejar las siguientes excepciones: BadPaddingException, InvalidKeyException, IllegalStateException, InvalidKeySpecException, IllegalBlockSizeException, InvalidAlgorithmParameterException, NoSuchPaddingException, NoSuchAlgorithmException, ShortBufferException.

6.8 CONCLUSIONES

Este capítulo muestra la plataforma de programación Java usada en dispositivos de pequeña capacidad, es decir, la plataforma Java ME.

Tras una introducción en la que se muestra la arquitectura que sigue la plataforma, entramos en como se programan las aplicaciones mediante los MIDlets.

Se analiza en el quinto punto el modo de conseguir almacenamiento persistente en los dispositivos móviles, cosa que nos será necesaria en la aplicación que se desarrolla en este proyecto fin de carrera.

Para finalizar se describe lo necesario para conseguir el acceso a la tarjeta SIM desde la plataforma Java ME, la API de seguridad y servicios de confianza (SATSA). Se han visto como utilizar la API para conseguir la comunicación con la tarjeta SIM.

6 LA PLATAFORMA JAVA MEbibing.us.es/proyectos/abreproy/11458/fichero/PFC%2FCapitulo06+-+L… · El...

Documents

Transcript of 6 LA PLATAFORMA JAVA MEbibing.us.es/proyectos/abreproy/11458/fichero/PFC%2FCapitulo06+-+L… · El...