Capítulo III. Desarrollo de la aplicación

1. Introducción

Tras el Capítulo II, en el que se han detallado los conceptos necesarios para comprender la firma digital móvil y las tecnologías existentes en esta materia, en el presente Capítulo se pasarán a desgranar los pormenores del desarrollo de la aplicación resultante. A modo de recordatorio se muestra el esquema general del proyecto que ya se presentó en el Capítulo I:

Ilustración 24. Esquema general del Proyecto Fin de Carrera.

El objetivo básico de este proyecto es conseguir implementar algún mecanismo de firma digital en un teléfono móvil. De entre todas las tecnologías existentes se optó por Java, para tratar de garantizar la mayor profusión posible entre los terminales existentes. Para ello se ha hecho un desarrollo de una aplicación Java ME (MIDlet) para un teléfono Nokia N95, que hace uso de la clave privada de un certificado digital personal de la Fábrica Nacional de Moneda y Timbre, expedido de la manera convencional, y así realizar las tareas criptográficas de firma digital en el móvil. Se eligió un certificado de esta Autoridad de Certificación ya que es la más extendida y reconocida entre las Administraciones Públicas españolas.

En el Capítulo II se comentaron todas las tecnologías existentes, dentro de las cuales está presente la solución adoptada: se trata de Java Mobile Edition con la API de Seguridad y Servicios de Confianza (SATSA). Esta solución adoptada tiene 5 razones de ser:

1. La gran cantidad de teléfonos y terminales móviles que implementan la máquina virtual de Java.

2. Las grandes capacidades de seguridad y firma electrónica que proporciona la API JSR-177 (SATSA). Entre estas funcionalidades hay que destacar la gestión de certificados y la generación de la firma digital en el estándar PKCS#7 / CMS.

3. La capacidad de SATSA de interaccionar con el elemento de seguridad, que, como se dijo en su apartado, puede ser una tarjeta inteligente criptográfica o bien un elemento interno del sistema operativo.

4. La mayoría de los nuevos terminales móviles vienen de fábrica con la arquitectura MSA (Mobile Service Architecture) para los nuevos servicios telemáticos y multimedia, entre los que se encuentra la JSR-177.

5. La sencillez en la modularidad y posibilidad de ampliación futura de la aplicación desarrollada.

Así pues, según el esquema del Proyecto, con el MIDlet desarrollado se generará una firma digital de unos datos, a partir de la clave privada del usuario recogida de un certificado convencional de la FNMT, que será enviada a un servidor para su custodia y posterior verificación por parte de un tercero (software de verificación).

2. Desarrollo de la aplicación

2.1 Material empleado

Para desarrollar la aplicación final del este Proyecto se han empleado los siguientes elementos:

• Teléfono móvil N95. Con Java y la JSR-177 instalada de fábrica.

• Certificado convencional en formato PKCS#12 expedido por la Fábrica Nacional de Moneda y Timbre (archivo con extensión PFX o P12).

• Servidor con la versión 6 de Tomcat instalada.

• Entorno de desarrollo NetBeans IDE 6.0.1.

• Software de verificación de firma digital de Indenova S.L.[30]

• Adaptador de conectividad Bluetooth para puerto USB.

2.2 Desarrollo del cliente

La aplicación en el lado del cliente consta de un MIDlet denominado MozartPKI. Dicho MIDlet ha sido desarrollado para terminales con perfil MIDP 2.0 y configuración de conexión limitada CLDC 1.0, acorde al teléfono disponible para la realización del Proyecto como es el Nokia N95.

El MIDlet ha sido desarrollado con el fin de que, haciendo uso de los servicios criptográficos de SATSA, un usuario pueda enviar al servidor un mensaje de texto plano firmado digitalmente por él, y que otra persona pueda recuperarlo del servidor y verificarlo posteriormente. El diagrama de flujo del MIDlet se muestra a continuación:

INICIO

Ilustración 25. Diagrama de flujo del MIDlet del cliente.

El MIDlet consta de 2 clases dentro del paquete es.minerva.mozart. Una clase es el MIDlet en sí, llamado MozartPKI.java y la otra es Infodata.java. La estructura de la aplicación cliente se muestra a continuación, tal y como se ve en el NetBeans:

Pantalla Bienvenida

Pulsar tecla ¿acción?

Pantalla datosMensaje

Pulsar tecla ¿acción?

Pantalla datosIntroducidos

Pulsar tecla ¿acción?

Pantalla datosFirmados

¿Generación Firma OK?

Envío por HTTP al servidor

FIN

SI

NO

SALIR

OK, comienzo

Pantalla Acerca de...

Pantalla de info del servicio

¿ Inf o Sobre?

Sobre

INF.

SALIR

OK

VOLVER

FIRMAR

Ilustración 26. Estructura de paquetes y clases del MIDlet.

La clase Infodata.java de lo único que se encarga es de leer la dirección IP del servidor de un fichero externo que se le da al MIDlet como recurso, así si se desea cambiar la IP de envío del archivo de firma (del servidor), no haría falta retocar el código fuente, tan solo bastaría con cambiar el archivo properties que se encuentra dentro del JAR. Éste archivo no es mas que un archivo de texto plano (TXT) que contiene la siguiente información, como se observa en la ilustración 27:

Ilustración 27. Contenido del archivo de propiedades.

Este archivo, como se ha descrito anteriormente, se encuentra dentro del fichero empaquetado instalable MozartPKI.JAR. Por lo que para editarlo simplemente bastaría desempaquetarlo con un descompresor como es WinRar y modificarlo, teniéndose lo siguiente:

Ilustración 28. Desempaquetado del archivo JAR.

Dentro del archivo JAR se observan las dos clases (archivos .class) que componen el MIDlet. Estas clases se encuentran ofuscadas, ya que así se consigue reducir el tamaño del JAR, de ahí que su nombre sean simples letras. La ofuscación del código la efectúa NetBeans de manera transparente para el programador, si se le ordena que la haga. Se dice que un código está ofuscado si está escrito de manera “enrevesada” de forma que es imposible entenderlo para un humano. En este MIDlet el fin no era hacer el código ininteligible, sino reducir el tamaño del archivo JAR.

También dentro del JAR se encuentran los demás recursos que utiliza el MIDlet, como son las imágenes que se muestran por la pantalla de la aplicación. Se verán en el apartado de “flujo de trabajo”.

Así pues, el funcionamiento del MIDlet es recoger a través de una TextBox el mensaje que el usuario desea enviar firmado al servidor, para que éste lo custodie hasta que un tercero lo descargue para su verificación. Dicho mensaje se muestra por pantalla al usuario , para que éste compruebe que realmente es lo que quiere transmitir bajo su firma digital. Si está de acuerdo, pulsando el botón de confirmación se lanzaría el método de la librería de SATSA para firmar los datos.

A partir de aquí entraría en funcionamiento todo el sistema criptográfico de SATSA, que debería concluir si todo va bien, con la firma digital de los datos introducidos en formato PKCS#7 / CMS. Los módulos que se emplean de la API no son todos los que se presentaron en el Capítulo anterior, puesto que son opcionales y, además, hay alguno que solo se emplea para comunicaciones con una tarjeta inteligente. En esta aplicación se utilizan los siguientes:

• Paquete PKI. Este paquete solo incluye las clases Javax.microedition.pki y Javax.microedition.SecurityService. Se emplea para permitir a la aplicación J2ME solicitar acceso al elemento de seguridad para llevar a cabo operaciones de firma digital. También incluye algunos métodos de gestión básica de certificados. La aplicación utiliza el método CMSMessageSignatureService para firmar datos con la clave privada almacenada en el elemento de seguridad. La autorización para utilizar una clave concreta del elemento de seguridad vendrá dada por la política de seguridad del terminal. En el caso del N95 se solicita al usuario que introduzca el PIN de acceso al almacén de claves privadas. Aunque esto se comentará más adelante.

Por otra parte, una aplicación puede utilizar el método UserCredentialManager para llevar a cabo las siguientes tareas: formular una petición de registro de certificado (CSR), que puede ser enviada a una autoridad de registro de certificados; añadir la parte pública de un certificado, o la URI del mismo a un almacén de certificados; eliminar un certificado, o la URI del mismo de un almacén de certificados, etc.

Sin duda, este es el paquete de SATSA que más importancia tiene en el desarrollo de la aplicación.

• Paquete CRYPTO. Este paquete provee al MIDlet de una serie de herramientas criptográficas que permiten realizar operaciones como resumen digital, firma digital o cifrado. Este paquete es un subconjunto de la JCE (Java Cryptography Extension). Así, todas las clases e interfaces de este paquete se encuentran en los mismos paquetes que en la JCE de la plataforma J2SE: java.security, java.security.spec, javax.crypto y javax.crypto.spec.

Este paquete, sin embargo, no implica al elemento de seguridad en las operaciones criptográficas más que para extraer las claves y certificados digitales necesarios para llevar a cabo la firma digital.

El MIDlet está configurado para que la firma sea de tipo SignedData, incluyendo el certificado (parámetro INCLUDE_CERTIFICATE) y el mensaje original (parámetro INCLUDE_CONTENT) que se firma. Se trata de datos firmados, usados para autentificación del remitente. Los datos estarán firmados mediante un resumen de los datos y su posterior encriptación utilizando la clave privada sobre el hash de los datos. El resumen del mensaje encriptado y otra información específica del remitente se agrupan en un campo del objeto llamado SignerInfo.

El MIDlet, con las funciones criptográficas de SATSA, recorre los diferentes elementos de seguridad que posee el sistema, que en este caso sólo es 1, ya que no hay tarjetas inteligentes con módulo WIM instaladas, ni tampoco otra smartcard externa, y no es otro que el interno que tiene el sistema operativo Symbian. Aunque se detallará posteriormente en el apartado de “Flujo de trabajo”, hay que decir que previamente al teléfono se le debe instalar un certificado digital convencional de la Fábrica Nacional de Moneda y Timbre, ya que de lo contrario el MIDlet daría un error en ejecución al no encontrar ningún certificado instalado de la FNMT en el elemento de seguridad, puesto que también ha sido programado para admitir únicamente los certificados emitidos por esta autoridad de certificación.

Así pues, se obtendría un array de byte con la firma digital, con el que se compondrá un archivo PKCS#7 / CMS. Dicho archivo se procede a enviar al servidor mediante una conexión HTTP, para que lo custodie hasta que un tercero lo descargue para su verificación.

La conexión HTTP se realiza utilizando el método POST para las peticiones, ya que para enviar un archivo completo como en este caso es mucho más adecuado que hacerlo por GET. El MIDlet escribe las cabeceras necesarias para establecer la comunicación con el servidor (la conexión es del tipo application/octet-stream, que es la más adecuada para el intercambio de octetos) , abre el flujo de salida y sobre él escribe el fichero de la firma. A continuación abre un flujo de entrada y se queda a la espera de recibir a través de él un asentimiento o mensaje de error por parte del servidor. Este proceso queda esquematizado en la siguiente figura:

Ilustración 29. Conexión HTTP entre el MIDlet y el servidor.

2.3 Desarrollo del servidor

De la descripción del MIDlet del cliente, se deduce que en el sistema interviene una máquina servidora que se encarga de “recoger” el archivo que contiene la firma digital del usuario.

Este servidor consta de un Servlet Java, ServerPKI, con una página web, index.jsp.

Los Servlets de Java [31] son objetos que corren dentro del contexto de un contenedor de Servlets (en este Proyecto será Tomcat 6). También pueden correr dentro de un servidor de aplicaciones (p.ej: OC4J Oracle). Un Servlet es pues, un programa que se ejecuta en un servidor.

La página web index.jsp tiene como misión hacer de portada del servidor cuando se accede a su URL. En esta página se muestra una imagen de bienvenida y los enlaces de acceso, con petición GET, al Servlet. Estos enlaces son los llamados “estado del servidor” y otro enlace para la descarga del “Mensaje firmado recibido”. El primero de ellos conduce al Servlet mediante GET, por lo que si el servidor está funcionando correctamente se muestra por pantalla una imagen de “OK”. El segundo contiene la ruta para la descarga del último archivo firmado digitalmente que el servidor haya recibido.

El diagrama de flujo de funcionamiento del Servlet se puede esquematizar de la siguiente manera:

INICIO ESTADO DE ESPERA

Ilustración 30. Diagrama de flujo del Servlet que corre en el servidor.

El Servlet funciona de manera muy parecida al MIDlet, en lo que respecta a la conexión HTTP. Hace un trabajo similar pero a la inversa, es decir cuando el cliente que corre en el teléfono establece la conexión con el servidor y le envía la petición POST, el Servlet reacciona tratando de guardar el flujo de entrada que recibe como array de bytes en un archivo de su disco. Si el proceso se concluye correctamente, se abre un flujo de salida para enviar al MIDlet un mensaje de asentimiento, indicando que el proceso ha terminado de forma exitosa. Si el proceso falla por alguna razón, se envía por el flujo de salida un mensaje que contiene la excepción lanzada por el Servlet, para que el cliente tenga constancia del error que se ha producido.

¿TIPO PETICIÓN?

GET POST

Muestra la imagen de “Servicio Activo”

Almacena el archivo recibido

FIN

¿Almacena-miento OK?

Envía mensaje de error al cliente

FIN

Envía mensaje OK al cliente

SÍ

NO

LLEGA UNA PETICIÓN

Las peticiones GET, orientadas al acceso desde un navegador web, simplemente muestran por pantalla un aviso indicando que el servidor funciona correctamente.

3. Pruebas, resultados y flujo de trabajo

3.1 Introducción

Una vez se han desarrollado las aplicaciones cliente y servidora se pasa a realizar una prueba de concepto que valide estos desarrollos. En este apartado se mostrarán las capturas de pantalla realizadas durante el proceso de ejecución. A modo de prólogo, estos serán los pasos fundamentales por los que transcurrirá la prueba:

1. Instalación del certificado digital. En este primer paso se indicará cómo se obtiene e instala un certificado digital personal de la Fábrica Nacional de Moneda y Timbre en el teléfono Nokia N95.

2. Instalación del MIDlet en el teléfono. Con el archivo JAR que contiene las clases compiladas se procederá a su instalación en el teléfono móvil.

3. Instalación del Servlet. Con el archivo WAR (Web Application Archive), generado por el NetBeans, del Servlet se despliega en el contenedor Tomcat residente en la máquina servidora.

4. Ejecución del MIDlet. Con el MIDlet instalado en el terminal móvil, se procede a su ejecución.

5. Verificación del archivo firmado. Una vez el servidor ha almacenado el archivo CMS que contiene la firma digital, se puede proceder a su verificación por parte de una aplicación externa para comprobar que dicho archivo contiene información válida, tanto en sintaxis ASN.1 como en validez de la firma digital.

3.2 Entorno de ejecución

El entorno de ejecución en el que se desarrollará la prueba es en las instalaciones del Laboratorio de Telemática de la Escuela Superior de Ingenieros de la Universidad de Sevilla.

Se dispone, como se comentó en el apartado introductorio del presente Capítulo, de:

• Un terminal móvil Nokia N95.

• Servidor con la versión 6 de Tomcat instalada. Sistema operativo Ubuntu 6. Para conectar el servidor a Internet se ha hecho uso de una IP pública fija (193.147.162.65) facilitada por el Departamento de Telemática de la Escuela Superior de Ingenieros. En la ilustración 31 se presenta un esquema general del conexionado de la red y del servidor. El servidor tiene una IP estática dentro de la red local (192.168.0.6).

• Router inalámbrico. Se deberá configurar adecuadamente para que redireccione todas las peticiones al puerto 80 y 8080 (web) al servidor, mediante la utilidad de Virtual Server. Posee una IP estática en internet y en la red local. Tiene DHCP (Dynamic Host Configuration Protocol) activado, para que el móvil cuando se conecte a través de la interfaz inalámbrica reciba la asignación de una dirección IP automáticamente (si se quiere hacer la prueba a través de red local).

Ilustración 31. Conexionado del Servidor.

3.3 Instalación del certificado digital

Para poder instalar el certificado digital en el teléfono, lo primero será disponer de un certificado digital personal expedido por la Fábrica Nacional de Moneda y Timbre. Los pasos que hay que seguir para obtenerlo son los siguientes [32]:

1. Solicitud por Internet del certificado. En la página web de la Fábrica Nacional de Moneda y Timbre (http://www.cert.fnmt.es) existe una sección llamada “Solicitud del Certificado”. Con el Número de Identificación Fiscal del usuario (NIF) se obtiene un código que será necesario utilizar en el siguiente paso.

2. Acreditación de la identidad en una oficina de Registro. Con el código obtenido en el paso anterior, es necesario acudir a una oficina de Registro. Este es el único momento en el que se requiere la presencia de la persona física para comprobar su identidad mediante el Documento Nacional de Identidad (DNI).

3. Descarga del certificado digital de usuario. Tras haber acreditado la identidad haciendo uso del código de solicitud obtenido en el paso 1, se procede a descargar el archivo que contiene el certificado desde la página web de la FNMT. Con este paso queda instalado el certificado en el navegador del PC del usuario.

4. Exportación del certificado. Para poder utilizar en otro sitio el certificado digital es necesario exportarlo. Para ello, desde la pestaña de Certificados del navegador se hace clic sobre “Exportar...”, como se muestra en la siguiente ilustración: (en esta prueba se ha utilizado Internet Explorer 7.0 para hacer la exportación)

Ilustración 32. Exportación del Certificado de usuario (I).

Al pulsar sobre “Exportar...” , se muestra la pantalla de elección sobre si se desea exportar la clave privada o no, hay que marcar que se desea exportar la clave, como muestra la figura 33, ya que el MIDlet necesitará hacer uso de ella para poder firmar convenientemente los datos que se le introduzcan:

Ilustración 33. Exportación del Certificado de usuario (II).

Como no podía ser de otra forma, solo se permite el tipo de archivo PKCS#12 para la exportación, ya que es el único que el estándar reconoce para albergar certificado personal y clave privada en un solo archivo. Es recomendable marcar que incluya toda la ruta de certificación, si es posible, ya que entonces también se guardará el certificado raíz de la FNMT que acredita que el certificado es válido y reconocido por una Autoridad Certificadora de Confianza. Esta ventana se muestra en la ilustración 34:

Ilustración 34. Exportación del Certificado de usuario (III).

A continuación, se muestra la ilustración con la ventana en la que que el asistente de exportación solicita la introducción de una contraseña de seguridad para futuras importaciones en otros sistemas, que será la que evite que el certificado pueda ser instalado sin el consentimiento del usuario propietario.

Ilustración 35. Exportación del Certificado de usuario (IV)

Tras este paso, se solicita un nombre de archivo para guardarlo como archivo PFX/PKCS#12 y el proceso de exportación habrá concluido. Se le llamará “Jid.pfx” para la prueba.

En el momento en el que se dispone del certificado digital personal en formato PFX/PKCS#12, se procede a su exportación al terminal móvil. Para ello se ha utilizado, en esta prueba, la transferencia de archivos por vía Bluetooth desde el PC aunque también se podría utilizar para ello un cable USB.

En el caso del sistema operativo Symbian S60 del Nokia N95, al abrir el archivo recibido lo reconoce como formato de certificado digital personal y procede con la instalación en el almacén de certificados de usuario del elemento de seguridad del sistema operativo. Esto se muestra paso a paso en las siguientes figuras:

Ilustración 36. Recepción del archivo PKCS#12 en el móvil, y apertura con contraseña.

En el buzón de entrada se almacena el mensaje recibido por Bluetooth, que contiene el archivo con el certificado digital personal y la clave privada. Al tratar de abrirlo se solicita la clave de importación, que no es otra que la que se insertó durante la anterior fase de exportación (ilustración 35). Al introducir la contraseña correctamente el teléfono detecta lo que contiene el archivo y procede a la instalación del certificado, como se muestra en la ilustración 37:

Ilustración 37. Symbian procede a guardar el certificado de usuario en su almacén de certificados.

Así pues, se almacena la clave privada en el elemento de seguridad y el certificado de usuario y el certificado de la autoridad certificadora, en el almacén de certificados. La primera vez que se instala un certificado personal en el contenedor del teléfono se solicita la creación de un código PIN para la

gestión del acceso a dicho contenedor, y que servirá para proteger el uso de la clave privada ante accesos no deseados. Es decir, como se verá durante la ejecución del MIDlet, cada vez que una aplicación desee hacer uso de la clave privada de un usuario, presente en el elemento de seguridad, se solicitará la introducción de dicho código PIN para salvaguardar la seguridad de la clave. No hay que confundir esta clave del elemento de seguridad con la clave de exportación.

Tras el proceso de instalación del certificado, se puede comprobar que la instalación se ha realizado correctamente si se consulta el almacén de certificados en el menú de Seguridad del Nokia N95, como se muestra a continuación:

Ilustración 38. Comprobación de la correcta instalación del certificado en el móvil.

Con esto ya se tiene instalado el certificado de la FNMT en el teléfono móvil, listo para ser usado por cualquier aplicación que lo requiera, en este caso una aplicación Java ME con la API SATSA.

3.4 Compilación e instalación del MIDlet

3.4.1 Compilación

Para poder instalar el MIDlet lo primero que hay que hacer es compilar y empaquetar el código fuente y los recursos de la aplicación cliente. De ello se encarga el entorno de desarrollo utilizado, el NetBeans 6.0. Al hacer la compilación y construcción del archivo JAR también se hace ofuscación de código, como se comentó en el apartado de “Desarrollo del cliente”, y así el archivo JAR pasa a reducirse considerablemente. Sin ofuscar, su tamaño rondaba los 900 KB, mientras que estando ofuscado su tamaño es de 137 KB. Como resultado de la construcción, en la carpeta dist del proyecto NetBeans se crea lo siguiente:

Ilustración 39. Resultado de la compilación.

Precisamente ese archivo MozartPKI.jar será el que se envíe vía Bluetooth al teléfono para ser instalado.

También se crea un archivo de descripción de contenido JAD que muestra todas las propiedades del MIDlet. En la siguiente tabla se puede ver el contenido de dicho archivo:

MIDlet-1: MozartPKI,/logo.png,es.minerva.mozart.MozartPKI

MIDlet-Icon: /logo.png

MIDlet-Jar-Size: 139437

MIDlet-Jar-URL: MozartPKI.jar

MIDlet-Name: MozartPKI

MIDlet-Vendor: Vendor

MIDlet-Version: 1.0

MicroEdition-Configuration: CLDC-1.1

MicroEdition-Profile: MIDP-2.0

Tabla 8. Contenido del archivo JAD.

Además de los campos que aparecen aquí podrían aparecer otros, por ejemplo si el MIDlet estuviese firmado aparecería un campo con la firma digital del vendedor y el algoritmo de firma empleado.

3.4.2 Instalación del MIDlet

Para instalarlo en el teléfono móvil basta con enviarle el archivo JAR, que es el MIDlet en sí. El archivo descriptor no es necesario ya que la aplicación cliente no está firmada. Para esta prueba se realizará el envío mediante la tecnología Bluetooth, al igual que se hizo para enviar al terminal móvil el certificado digital.

Así pues, una vez el móvil ha recibido el archivo JAR, está en condiciones de instalar el MIDlet. Durante la instalación se muestran pantallas de aviso que indican que el MIDlet puede no ser seguro, esto es absolutamente normal ya que detecta que la aplicación no está firmada, como se ha indicado anteriormente.

Con el MIDlet instalado en el Nokia N95, ya se puede comprobar que el proceso ha finalizado correctamente. Para ello basta con entrar en el menú de aplicaciones del teléfono, pudiendo observarse que el MIDlet se encuentra entre el resto de aplicaciones que ya estaban instaladas en el terminal, como se observa en la ilustración 40:

Ilustración 40. Instalación correcta del MIDlet “MozartPKI”.

3.5 Instalación del Servlet

El Servlet Java, que se ha desarrollado para que lo corra el servidor, tras ser compilado por NetBeans debe ser instalado en el contenedor de Servlets, que en este caso no es otro que Tomcat 6.0.

Como resultado de la compilación y construcción de la aplicación Web, en la carpeta de proyecto de NetBeans se tiene lo siguiente:

Ilustración 41. Resultado de la compilación del Servlet.

Ese archivo WAR es el equivalente al JAR para el móvil, por lo que basta con desplegarlo en un contenedor de Servlets (Tomcat). Para ello se accede a la consola de administración de Tomcat y se selecciona el archivo WAR correspondiente para desplegarlo en él. Para más detalles sobre la instalación del servidor, se puede consultar el anexo correspondiente.

3.6 Ejecución de la aplicación

A continuación se procede a detallar el proceso completo de la prueba de concepto, es decir, desde que se arranca la aplicación MozartPKI, hasta que se verifica la firma recibida por un tercero. Este proceso sería el que un usuario debería hacer para enviar un mensaje firmado con su certificado digital personal de la FNMT.

3.6.1 Lanzamiento del MIDlet

Lo primero que debe hacer el usuario es acceder al menú de aplicaciones del terminal y lanzar la aplicación. Una vez lanzada, aparece la pantalla de bienvenida que se puede ver en la ilustración 42:

Ilustración 42. Pantalla de bienvenida del MIDlet.

En esta pantalla de bienvenida, como se indicó en el diagrama de flujo, el usuario puede optar por abandonar la aplicación (“Salir”) o pulsar sobre las opciones existentes:

1. Inicio. Para comenzar con el proceso de firma de un mensaje de texto.

2. Servicio. Conduce a una pantalla en la que se informa sobre el servicio que ofrece este MIDlet.

3. Acerca de... Nombre del Proyecto Fin de Carrera y autor.

Al pulsar sobre la tecla “Opciones” se visualiza de la siguiente manera:

Ilustración 43. Opciones en la pantalla de bienvenida.

La información sobre el Servicio y la pantalla de “Acerca de...” se muestran a continuación:

Ilustración 44. Pantallas de información de servicio y “Acerca de...”.

Así pues, el usuario que desea enviar el mensaje firmado con su clave privada al servidor, pulsa sobre la tecla de “Inicio” y se comienza con el proceso que realmente interesa. Lo primero que el MIDlet solicita al usuario del servicio, es la inserción del mensaje que quiere firmar, y una vez lo tiene escrito lo confirma pulsando la tecla correspondiente. El mensaje que se va a firmar a modo de ejemplo es “He recibido tu regalo.”, en un supuesto de que el usuario quisiera comunicar, fehacientemente mediante su firma digital, a un tercero sobre la recepción de un envío que éste le hubiese hecho.

De este modo el usuario introduce su mensaje y pulsa la tecla de confirmación, visionando lo siguiente:

Ilustración 45. Pantallas de inserción del mensaje de texto y previsualización.

La pantalla que se observa a la derecha de la ilustración 45, muestra el mensaje introducido y permite la posibilidad de modificarlo por si el cliente detecta algún fallo en la escritura; en ese caso se retrocedería a la pantalla de inserción del mensaje.

Si el usuario comprueba que el mensaje introducido es correcto, pulsa sobre el botón de “Firmar” y se inicia el proceso criptográfico con los métodos de la API de SATSA. Lo primero que indicaría el elemento de seguridad de Symbian es que una aplicación (este MIDlet) está solicitando el acceso a él, y se hace un prompt al usuario para que acepte si está de acuerdo, como se observa en la imagen 46:

Ilustración 46. El MIDlet solicita acceso al elemento de seguridad.

Una vez el usuario ha aceptado la petición del MIDlet para el acceso al elemento de seguridad, SATSA hace un “barrido” por los elementos de seguridad que encuentre en el dispositivo, que, en el caso del

Nokia N95, es el interno del sistema operativo Symbian. En él encuentra instalado el certificado del usuario y lo muestra por pantalla (por si hubiese más de uno) para que seleccione el que le interese utilizar. Esta lista sólo puede mostrar los emitidos por la Fábrica Nacional de Moneda y Timbre ya que el MIDlet ha sido desarrollado así, limitando el uso a los emitidos por esta entidad certificadora. Si SATSA no encontrase ningún certificado de la FNMT instalado, daría un error de “No se encuentra certificado”. Este paso se realiza del modo en que se muestra en la ilustración 47:

Ilustración 47. Selección del certificado digital.

Cuando el usuario selecciona el certificado que desea, SATSA trata de acceder a la clave privada. Por motivos de una mayor seguridad, ésta se encuentra bajo una contraseña de uso (PIN del elemento de seguridad) que se comentó anteriormente en el apartado de “Instalación del certificado”.

Ilustración 48. Petición de la contraseña de acceso a la clave privada.

Si la clave se introduce erróneamente, se disponen de 2 intentos más, y si todos son fallidos entonces el MIDlet dará un error de “PIN incorrecto”. Si la clave se introduce de manera correcta (ilustración 48),

SATSA procede a realizar la firma digital de los datos insertados con el formato CMS / PKCS#7 SignedData, conteniendo el certificado del firmante, los datos que se han firmado y la propia firma digital. Estos pasos, en los que se genera la firma digital, se muestran en la siguiente ilustración:

Ilustración 49. Pantallas del proceso de generación de la firma digital.

Si el proceso concluye de forma correcta se muestra por pantalla la longitud del archivo CMS generado, que en este caso es de 979 Bytes. A partir de aquí la firma digital ya está realizada, tan solo falta enviarla al servidor que la custodiará hasta que un tercero acceda al archivo y lo descargue para comprobar la veracidad de la firma.

3.6.2 Conexión HTTP con el servidor

Una vez se ha concluido en proceso de firma, el archivo que contiene dicha firma digital procede a ser enviado al servidor que tiene corriendo el Servlet desarrollado.

Cuando el usuario pulsa sobre la tecla de “Enviar” se inicia el proceso, entonces el MIDlet recupera del archivo properties, mediante los métodos de la clase InfoData.java, la dirección URL del servidor y se muestra por pantalla para que el usuario confirme. El usuario debe confirmar también la petición del MIDlet de conectarse a Internet para el envío del archivo al servidor, ya que esta conexión podría conllevar costes asociados al realizarse a través de la red GPRS/UMTS. Una vez queda establecida la conexión HTTP el MIDlet queda a la espera de recibir el asentimiento del servidor. Este proceso se realiza de la manera en que se muestra en la siguiente figura:

Ilustración 50. Proceso de conexión HTTP con el servidor, vía Internet.

El MIDlet, como se ha detallado anteriormente, envía el archivo CMS y queda a la espera de recibir el asentimiento o el error por parte del servidor. En el caso de que todo funcione de manera correcta, se recibe por pantalla el mensaje de “OK” como se muestra en la siguiente imagen:

Ilustración 51. Confirmación del servidor de que el archivo fue recibido correctamente.

Tras esto, el proceso ha finalizado para el MIDlet ya que el mensaje firmado ha sido almacenado correctamente tal y como indica el asentimiento del Servlet. Así pues, el usuario pulsa la tecla de “Terminar” y se visualiza la pantalla de despedida de la siguiente manera:

Ilustración 52. Pantalla de despedida.

Y al pulsar el botón de “Salir”, se cierra el MIDlet definitivamente.

El siguiente paso consiste en la verificación de la firma, algo que debe realizar la tercera persona que sea destinataria del mensaje firmado.

3.7 Verificación del archivo firmado

3.7.1 Acceso al servidor

El servidor está accesible desde Internet, por lo que desde un navegador web se puede entrar y descargar el archivo de la firma digital. La URL del servidor es: http://enfoca.us.es:8080/MozartServer.

Si se accede a ella, se presenta por pantalla la página web de portada del Servlet index.jsp (ilustración 53). En ella se observa el título del Proyecto Fin de Carrera y dos enlaces:

• Estado del servidor. Muestra una imagen que simboliza el correcto funcionamiento del Servlet. Se obtiene con el acceso GET.

• Mensaje recibido. Enlace a la URL en la que se ha almacenado el último mensaje recibido. Si se hace clic sobre este enlace se procede a la descarga del archivo que contiene el mensaje firmado digitalmente.

Ilustración 53. Portada del Servidor.

Al hacer clic sobre el enlace de estado del servidor, se obtiene la siguiente imagen:

Ilustración 54. Imagen de servidor activo.

3.7.2 Descarga del archivo

Para descargar el archivo firmado, se hace clic sobre el enlace correspondiente y se abre la ventana de descarga. Para esta prueba de concepto se utilizó el navegador Safari de Apple. En la ilustración 55 se muestra la ventana de descarga:

Ilustración 55. Ventana de descarga del archivo firmado.

Como se observa en la imagen, al archivo se le nombró con extensión “.esig” al crearlo como flujo de entrada HTTP en el Servlet. Esto se hizo así para facilitar su apertura posterior con el software de verificación que se va a emplear, el eSigna Viewer de Indenova, que se comentará en el subapartado siguiente.

3.7.3 Verificación

Como se ha comentado, el archivo PKCS#7 / CMS que contiene los datos firmados necesita verificarse para concluir el proceso y comprobar que la firma la ha generado el móvil correctamente.

Para llevar a cabo el proceso de verificación de la firma digital, realizada por el cliente en su terminal móvil, se ha empleado la herramienta gratuita eSigna Viewer desarrollada por la empresa valenciana inDenova S.L. Esta aplicación es un visor de archivos firmados electrónicamente compatible con los formatos estándar CMS/PKCS#7 y XMLDsig, por lo que es válida para verificar el archivo generado con el terminal móvil de este Proyecto.

La aplicación eSigna Viewer [33] posibilita trabajar con archivos firmados electrónicamente desde el PC del usuario. Permite por un lado visualizar el contenido del archivo firmado y por otro las firmas y la validez de las firmas aplicadas al mismo. Se muestran los datos firmados así como el resto de atributos de la firma digital (estado de la firma , validez del certificado personal, integridad de los datos firmados, etc...). El motivo por el que se ha optado por el uso de esta herramienta se basa fundamentalmente en su gratuidad y en que tan solo se quería comprobar la validez sintáctica y la correcta generación de la firma en el terminal móvil. Y efectivamente, al utilizar eSigna Viewer se ha podido comprobar la correcta generación de la firma en un terminal móvil J2ME, que era el objetivo fundamental de este Proyecto Fin de Carrera.

Al abrir el archivo que se ha descargado del servidor, el programa de Indenova S.L. muestra la siguiente información sobre la firma digital:

Ilustración 56. eSigna Viewer mostrando el contenido del archivo firmado digitalmente.

En la ilustración 56 se puede observar la descodificación del archivo de firma digital en formato CMS. Lo que hace el programa es tomar del certificado del firmante su clave pública, posteriormente le aplica el algoritmo RSA al campo que contiene la propia firma digital y así obtiene el hash de los datos firmados. Tras obtener el resumen de los datos firmados, a raíz de la aplicación de la clave pública del firmante a la firma digital, procede a separar los datos originales y a aplicarles el algoritmo de hashing SHA-1. Si el resultado de esta operación coincide con lo que se tenía procedente de la firma digital, entonces la firma es correcta.

En la imagen se observa como a la derecha aparece correctamente separado el mensaje enviado de su firma digital. A la izquierda el programa muestra el informe con los resultados de la apertura del archivo y comprobaciones de corrección de la firma. Entre estos resultados se observa lo siguiente:

• Nombre del sujeto firmante. Es el del certificado digital que se seleccionó para realización de la firma.

• Autoridad Certificadora que emite el certificado de usuario. En este caso es la FNMT cuyo certificado raíz es el Clase 2 CA.

• El estampado de tiempo (TimeStamp) con la fecha y hora en que se realizó la firma. Este estampado lo hace el móvil en base al reloj propio ya que SATSA no ofrece TimeStamping. Nada impediría la posibilidad de combinar la firma digital con el estampado de tiempo de una autoridad (Time Stamping Authority – TSA). Es útil para comprobar si cuando la firma se realizó el certificado del firmante estaba revocado o caducado.

• La huella digital o hash.en formato Base64.

• El algoritmo utilizado en la computación del resumen (SHA-1).

• Se indica que el documento no ha sido modificado (integridad de los datos). Se refiere a que la comparación de la firma digital, desencriptada con la clave pública del certificado, con el hash de los datos aplicándoles el SHA-1 ha coincidido.

• El certificado de la firma es válido. Quiere decir que su formato es correcto y que no está caducado.

• Comprobación de las listas de certificados revocados (CRL). El programa eSigna Viewer da una advertencia en este paso ya que no se comprueba el estado de revocación del certificado firmante, puesto que este software no tiene acceso a la CRL de la FNMT. Su acceso está limitado a las Administraciones y otros organismos autorizados.

• Por último se indica que ha sido emitido por una entidad certificadora de confianza, ya que es la Fábrica Nacional de Moneda y Timbre.

Por toda esta información que muestra el verificador de firma digital se comprueba que la firma realizada por la aplicación J2ME en el terminal móvil es válida y cumple con el formato PKCS#7 / CMS; y un tercer usuario que desee comprobar la autoría del mensaje puede realizarlo y estar seguro de que lo envió quien dice enviarlo.

Para mayor seguridad también se ha verificado la estructura ASN.1 del archivo con un editor de esta sintaxis, aunque queda reflejada en el Anexo de este Proyecto.