capítulo ii. desarrollo de las aplicacionesbibing.us.es/proyectos/abreproy/11722/descargar... ·...

Desarrollo de aplicaciones de firma digital para terminales móviles J2ME

54

Capítulo II. Desarrollo de las Aplicaciones

1. Arquitectura General

1.1. Introducción

El objetivo principal del proyecto se centra en el desarrollo de un conjunto de aplicaciones que ofrezcan servicios de firma digital en terminales móviles.

El campo de la firma digital es muy amplio y los desarrollos enfocados al uso de dispositivos móviles dentro de una infraestructura de clave pública, muy escasos. Por lo que desde el inicio de la investigación se han tenido que tomar diferentes decisiones en torno a la arquitectura de la solución y todo lo que ello comprende, como pueden ser el lenguaje de programación, el tipo de certificado digital y el protocolo de intercambio de datos entre cliente y servidor.

En los siguientes apartados se explican las bases de la solución adoptada con el fin de exponer claramente los distintos bloques de los que se compone, así como se justifican las decisiones tomadas a lo largo de la investigación.

1.2. Esquema

Figura 14. Arquitectura Teórica de la Solución.


55

En la anterior figura se muestra la arquitectura general que siguen las aplicaciones desarrolladas. En realidad, la arquitectura se ha empleado como modelo teórico puesto que cada aplicación dispone de particularidades que se detallarán en capítulos posteriores.

A continuación se divide la arquitectura funcional en tres grandes bloques, y la explicación de cada uno de estos bloques servirá para introducir una idea general del funcionamiento y de las tecnologías adoptadas en la solución final. No obstante, en los apartados siguientes se comentan los motivos que provocaron las decisiones tomadas durante el desarrollo del proyecto.

1.3. Material Empleado

Básicamente, para llevar a cabo el desarrollo de las aplicaciones finales de este proyecto, se han empleado los siguientes elementos:

Teléfono móvil N95. Dotado con Java VM 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 5.5 de Tomcat instalada.

Entorno de desarrollo NetBeans IDE 6.0.1.

Software de verificación de firma digital de Indenova S.L.

Adaptador de conectividad Bluetooth para puerto USB.

1.4. Generación y Exportación del Certificado de Usuario

En primer lugar se debe disponer de un certificado digital personal. En este caso se ha optado por la FNMT como autoridad certificadora [15] por motivos que se expondrán más adelante.

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 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 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 sistema operativo. Se almacena la clave privada, el certificado de usuario y el certificado de la autoridad certificadora. La primera vez que se instala un certificado personal en el contenedor del teléfono se solicita la creación de un


56

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.

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.

1.5. Instalación de la Aplicación y Proceso de Firma Digital

Las aplicaciones desarrolladas están formadas por la parte cliente, que reside en el terminal móvil, y por la parte servidora alojada en un PC designado para tal función.

De las dos aplicaciones desarrolladas, la aplicación más básica está basada en un servicio de Hoja de Quejas simplificado en el que el usuario introduce sus datos personales junto con la reclamación deseada; estos datos se envían firmados digitalmente al servidor, que recibe los datos y confirma la correcta recepción de los mismos. La explicación del servicio de Hoja de Quejas, al ser más básico, tiene un carácter introductorio que puede valer para ofrecer una idea general de lo que ofrecen las aplicaciones desarrolladas. No obstante, cada aplicación será explicada de forma pormenorizada más adelante.

La aplicación móvil está desarrollada en J2ME y consta de un solo MIDlet que realiza todas las funciones necesarias para llevar a cabo tanto la toma de datos del usuario como la gestión del certificado digital para realizar la firma, así como la gestión de la conexión HTTP para el envío/recepción de datos hacia/desde el servidor. Realmente, el único camino que se ha tenido claro desde un principio ha sido el uso de la tecnología Java, y en particular, el de la plataforma limitada Java ME.

Para llevar a cabo las pruebas dentro del proyecto, la instalación de la aplicación J2ME se ha realizado exportándola en formato JAR directamente desde un PC. Como trabajo futuro se podría utilizar la plataforma RedBOX para la distribución masiva de la aplicación móvil dentro de un marco comercial.

Al iniciar el MIDlet instalado en el teléfono móvil se solicitan los datos personales del usuario y la queja que se desee efectuar. En el momento en el que el usuario confirma los datos, se procede a realizar la firma digital de éstos. En ese momento se despliega el contenedor de certificados del teléfono móvil para que el usuario seleccione el que proceda. Para realizar la firma digital de los datos, el MIDlet debe acceder a la clave privada del usuario y por ello se solicita la inserción del código PIN establecido para el almacén de claves del sistema operativo.


57

1.6. Envío y Verificación de la Firma Digital

Una vez realizada la firma digital la aplicación establece una conexión HTTP con el servidor para poder llevar a cabo el intercambio de datos. La conexión es del tipo application/octet-stream, que es la más adecuada para el intercambio de octetos. Cuando el servidor recibe los datos correctamente manda un asentimiento al cliente para finalizar el proceso.

Se ha dotado de un nivel superior de seguridad al entorno de las aplicaciones mediante el encapsulamiento de las comunicaciones entre cliente y servidor usando el protocolo de seguridad SSL.

El servidor está compuesto por un Java Servlet que recibe la firma digital generada por el cliente, y crea un fichero CMS/PKCS#7 que contiene dicha firma para poder llevar a cabo un procesamiento ulterior. El Servlet está preparado para atender tanto peticiones POST (efectuadas por el teléfono móvil) como peticiones GET (para acceder desde un navegador al archivo de firma digital recibido).

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 [16] desarrollada por inDenova S.L. Esta aplicación es un visor de archivos firmados electrónicamente compatible con los formatos CMS/PKCS#7 y XMLDsig, que muestra los datos firmados así como el estado de la firma, es decir, validez del certificado personal e integridad de los datos firmados.

2. Solución Adoptada

A continuación se explican las bases tecnológicas y decisiones tomadas en las que se fundamenta la solución final del proyecto, tanto a nivel estructural como técnico.

2.1. Certificados Digitales

En un proyecto de investigación sobre firma digital juegan un papel muy importante los certificados digitales. En este aspecto, se han tenido que tomar decisiones relativas a:

• Tipo de certificados a utilizar.

• Vía de integración de certificados personales en terminales móviles.

2.1.1. Tipos de Certificados

Los certificados digitales utilizados en las pruebas de este proyecto han sido expedidos por la autoridad certificadora (AC) de la Fábrica Nacional de Moneda y Timbre (FNMT).


58

Los certificados de la FNMT se han tomado como referencia en la investigación puesto que se trata de la AC con mayor penetración entre la población y su uso está muy extendido en los servicios telemáticos de la Administración. No obstante, existen otras AC cuyos certificados serían igualmente compatibles con la aplicación desarrollada, como pueden ser CamerFirma, CatCert, Ancert, etc.

Una vez obtenido el certificado digital, se dispone de un archivo en formato PKCS#12 que contiene tanto el certificado digital personal, incluyendo su clave privada asociada, como el certificado digital de la AC, en este caso el correspondiente a la FNMT.

2.1.2. Vías de Integración

El paso siguiente sería la integración de dicho certificado en un terminal móvil. La solución final se fundamenta en el uso de la tecnología Bluetooth además de las capacidades del sistema operativo Symbian S60 disponible en el teléfono móvil. Pero en un principio se barajaron distintas posibilidades tecnológicas para hacer llegar el certificado digital con su parte segura (clave privada).

Las principales posibilidades estudiadas se basan en la búsqueda de una solución de carácter universal que se adapte a la mayor parte de los teléfonos existentes pero teniendo en cuenta el alcance del proyecto.

Mediante tarjetas SIM/WIM Duales

Existen soluciones en funcionamiento en distintos países basadas en esta opción. En la gran mayoría de casos una empresa privada se encarga de la distribución de tarjetas específicas para el manejo de certificados.

Adquiriendo una tarjeta de estas características y siguiendo un procedimiento similar al de expedición de un certificado digital para PC se pueden realizar los mecanismos básicos relacionados con el esquema PKI desde un teléfono móvil.

Esta posibilidad de distribución de certificados digitales es una solución propietaria, generalmente asociada a un solo operador, y que además tendría una fuerte barrera de entrada debido a las complicaciones que supone la necesidad de sustituir obligatoriamente la tradicional tarjeta SIM de GSM por una tarjeta dual.


59

Generación “OnBoard” del Certificado

El mecanismo “OnBoard” funciona exactamente igual que el que se lleva a cabo en un ordenador personal en el momento de la creación de un certificado digital a través de Internet.

El usuario accede con su terminal mediante tecnología WAP al sitio de la Autoridad de Certificación. Se establece un diálogo entre el móvil y la AC por el cual se lleva a cabo la solicitud de expedición de certificado. Una vez identificado físicamente (como se haría en el procedimiento habitual) se completa el proceso llevando a cabo la generación del par de claves directamente en el terminal móvil. Una vez enviada la solicitud firmada por el usuario, el certificado entraría en vigor.

El principal problema de esta solución es que ni todos los terminales móviles existentes ni las tarjetas SIM actuales soportan este servicio, así como que pocas entidades de certificación ofrecen la posibilidad de realizar el proceso de emisión de certificados de esta manera.

A través del Operador Móvil

Este esquema se basa en el uso del procedimiento habitual de obtención de un certificado digital para PC. El certificado digital, incluyendo la parte privada (información sensible), sería enviado hacia algún servidor del operador encargado de esa tarea, y una vez ahí sería reenviado convenientemente hacia el terminal móvil a través de la red celular.

Evidentemente esta solución presenta una clara vulnerabilidad debido a que la clave privada circula por la red y podría extraviarse. Además supondría un coste adicional para el operador al tener que dotar a la red de capacidades específicas de seguridad.

Uso de JKS

La plataforma J2ME contiene una base de datos destinada al almacenamiento de certificados digitales y sus claves privadas asociadas. Esta base de datos se denomina Java KeyStore y se trata de una forma segura de guardar toda la información del certificado en el entorno Java.

Por lo tanto, en este caso, los archivos pfx provenientes del PC han de ser convertidos a Java KeyStore (en adelante jks) para su manejo por parte de la aplicación Java que demande su uso posteriormente. También existe la posibilidad de convertir los archivos pfx en otros formatos diferentes para su traspaso al espacio de Java, según las APIs y los Toolkits de desarrollo que se usen, como puede ser bks (BouncyCastle KeyStore) aunque son muy similares todos entre sí.

A continuación se detallan los distintos formatos mencionados sobre almacenamiento de certificados digitales.


60

• Formato PFX

Conocido también como PKCS#12 (en realidad pfx es su predecesor), es un archivo autoprotegido mediante contraseña que ha sido concebido para el transporte de claves. Contiene la clave privada del certificado y por ello debe guardarse una escrupulosa seguridad sobre el mismo y evitar su distribución a personas distintas del suscriptor del certificado. Este formato está muy extendido debido a su utilización en plataformas Windows y a su interoperabilidad con Internet Explorer.

• Formato JKS/BKS

El archivo de almacén de claves Java KeyStore es un archivo de base de datos de claves que contiene tanto las claves públicas como las claves privadas. Las claves públicas se almacenan como certificados de firmantes mientras que las claves privadas se almacenan en los certificados personales. Las claves se utilizan con distintos objetivos, entre los que se incluye la autenticación y la integridad de datos.

El formato compatible con las entradas de la base de datos es el JKS, aunque en algunos casos puede usarse el formato PKCS#12 visto anteriormente. Los archivos BKS son similares a los JKS pero optimizados para su manejo con la BouncyCastle KeyStore, base de datos análoga a la Java KeyStore.

• Contenedor de Certificados Symbian Se trata de un espacio de almacenamiento seguro del propio sistema operativo Symbian. En este caso, el certificado digital del usuario se almacenaría en el contenedor de certificados personales de Symbian protegido por un código PIN.

Este sistema está integrado con el formato de archivos pfx, puesto que si se sincroniza el terminal móvil con el PC, mediante cable o Bluetooth, el sistema operativo Symbian al recibir el certificado digital lo reconoce y procede a instalarlo en un espacio seguro de almacenamiento de forma automática. Durante el proceso de instalación, el usuario puede introducir el código PIN que desee con el fin de proteger el acceso a la clave privada.

Esta opción es muy adecuada por diferentes motivos:

El proceso de exportación del certificado digital al teléfono móvil es muy intuitivo para el usuario, ya que es similar al traspaso de cualquier otra información como pueden ser fotos o música.

La seguridad en el almacenamiento de la clave privada es superior a las

otras opciones, debido a que la parte sensible del certificado digital (clave privada) se almacena en un elemento de seguridad del sistema operativo.

Es cierto que esta opción limita la extensión de la solución a terminales Symbian S60, lo que puede ser un inconveniente de cara a un camino comercial inmediato. Pero la


61

evolución constante de los teléfonos móviles existentes en el mercado hace pensar que en un futuro a medio plazo esta vía de integración sea muy realista.

2.2. Proveedor de Seguridad

Al basar el desarrollo de las aplicaciones en la plataforma limitada de Java, Java ME, las opciones respecto a los proveedores de seguridad eran amplias. En particular, se ha trabajado con dos APIs de Java para JME, Security and Trust Services API (SATSA) y BouncyCastle LightWeight API, anteriormente comentadas en el apartado correspondiente del estado del arte.

La solución final está basada en SATSA por diversos motivos, entre los cuales destacan su extensa documentación y su nivel de integración con el sistema operativo Symbian del teléfono móvil empleado.

2.2.1. Security and Trust Services API

De SATSA se puede decir que es una API de Java que establece la posibilidad de abrir un canal de comunicación entre una aplicación J2ME y un Elemento de Seguridad (SE). De esta forma se pueden realizar operaciones de seguridad (firma y autenticación de usuarios) en aplicaciones J2ME.

En un teléfono móvil se distingue básicamente entre dos tipos de SE, por un lado se dispone de un espacio de almacenamiento seguro proporcionado por el propio sistema operativo Symbian, y por otro se encuentran las tarjetas inteligentes criptográficas WIM. Se aprecia que la principal diferencia entre ambas opciones radica en su propia naturaleza, software o hardware. En nuestro caso se ha optado por la primera opción ya que presenta más flexibilidad para el desarrollo software.

SATSA dispone de cuatro paquetes opcionales que se ajustan a las distintas necesidades que se puedan tener en esta materia. Son los siguientes:

• SATSA – PKI. Proporciona herramientas para realizar firmas digitales.

• SATSA – CRYPTO. Proporciona soporte para operaciones criptográficas.

• SATSA – APDU, SATSA – JCRMI. Se emplea para soportar la comunicación entre la aplicación J2ME y las aplicaciones relacionadas con Smart Cards.

Independientemente de los modelos de seguridad que ya ofrecen las aplicaciones sobre Java ME, SATSA facilita a los desarrolladores la implementación de servicios adicionales de seguridad como pueden ser la identificación de usuario y la integridad de los datos.


62

2.2.2. Módulos Empleados

Como se ha comentado anteriormente, en la solución adoptada se emplea como SE el espacio de almacenamiento seguro del sistema operativo Symbian S60 existente en el teléfono móvil. En este caso no se utilizan los paquetes APDU y JCRMI, puesto que es innecesario comunicarse con tarjetas criptográficas. A continuación se detallan los paquetes opcionales utilizados en el desarrollo de la aplicación.

javax.microedition.pki

Este paquete solo incluye las clases javax.microedition.pki.UserCredentialManager y javax.microedition.securityservice.CMSMessageSignatureService, y permite a las aplicaciones 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.

Una aplicación J2ME puede utilizar el CMSMessageSignatureService para firmar datos con una clave privada almacenada en un SE. Dichos datos pueden ser firmados con el objetivo de conseguir autenticación y no repudio. La autorización para utilizar una clave concreta del SE 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.

En el desarrollo del cliente Java ME, se ha configurado la función autentícate para que la firma sea del 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. Si el teléfono no tiene previamente instalado un certificado digital convencional de la Fábrica Nacional de Moneda y Timbre, se produciría un error en ejecución al no encontrarse ningún certificado instalado de la FNMT en el elemento de seguridad, puesto que también las aplicaciones han sido programadas para admitir únicamente los certificados emitidos por esta autoridad de certificación.

Por otra parte, una aplicación puede utilizar el UserCredentialManager para llevar a cabo las siguientes tareas: formular una petición de registro de certificado (CSR), que puede ser


63

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.

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

javax.crypto

El paquete CRYPTO provee a las aplicaciones J2ME 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 SE en las operaciones criptográficas más que para extraer las claves y certificados digitales necesarios para llevar a cabo dichas operaciones.

2.3. Verificación de la Firma Digital

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 inDenova S.L.

Esta aplicación es un visor de archivos firmados electrónicamente compatible con los formatos CMS/PKCS#7 y XMLDsig, que muestra los datos firmados así como el estado de la firma, es decir, validez del certificado personal e integridad de los datos firmados.

El motivo por el que se ha optado por el uso de esta herramienta se basa en que no parecía apropiado centrar gran parte de la investigación en el desarrollo de un servidor propio de verificación de firma, ya que el objetivo del proyecto pretende integrar la aplicación residente en el móvil con algún servicio genérico existente en la actualidad.

Al utilizar eSigna Viewer se ha podido comprobar la correcta generación de la firma en un terminal móvil, que es lo que se pretendía en los objetivos iniciales del proyecto. No obstante, unas de las mejoras posibles que se pueden realizar sobre la solución final es el desarrollo de un verificador propio.


64

2.4. Uso del protocolo HTTP

Para el intercambio de información entre cliente y servidor se ha optado por el uso del protocolo de comunicaciones HTTP. Su integración en una aplicación JME es relativamente fácil por lo que no presenta gran interés detallar mucho el desarrollo.

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 cliente 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).

2.5. Conexiones Seguras SSL

En el capítulo correspondiente del Estado del Arte se explicaron las bases de este protocolo para soporte de conexiones seguras. En las aplicaciones desarrolladas su uso está justificado por dos motivos.

Primero, el uso de procedimientos de firma digital no establece necesariamente un entorno seguro de intercambio de información entre cliente y servidor, puesto que se garantiza la autenticación, el no repudio y la integridad de los datos, pero en ningún momento se asegura la confidencialidad de la información. Por lo tanto, el uso de SSL en las comunicaciones de las aplicaciones desarrolladas aporta un grado más de seguridad, consiguiendo que la información sensible sea confidencial y no accesible para terceros.

Por otro lado, se emplea como una herramienta de intercambio de certificados. Es decir, en el inicio de la comunicación entre cliente y servidor, al tratarse de una conexión segura, se produce un proceso de autenticación mediante el uso de certificados digitales.

Se ha desarrollado y configurado el servidor para que exija autenticación y obtenga los certificados digitales de los clientes que le hagan peticiones. De esta forma, el servidor puede extraer los datos personales del cliente contenidos en el certificado digital recibido y enviarlos de nuevo al cliente para autocompletar cualquier formulario que necesite dichos datos. Con este proceso, el cliente sólo tiene que introducir los datos estrictamente necesarios para realizar los trámites pertinentes, como se verá más adelante.

La obtención de los datos personales del cliente se realiza mediante el acceso a campo estándar Nombre Alternativo del Sujeto, en el que se encuentran por separado nombre, primer apellido, segundo apellido y dirección de correo electrónico. Mediante código Java en servidor se extrae dicho campo del certificado digital y se recorre su jerarquía para extraer todos y cada uno de los datos significativos del usuario.


65

2.6. Uso de MySQL

En el desarrollo de la aplicación de Gestión de Trámites, cuyos detalles serán explicados más adelante, juega un papel muy importante la base de datos que recoge los trámites pendientes del usuario. En todo momento se tuvo claro que el gestor de base de datos a utilizar sería mySQL por su buen rendimiento, su facilidad de uso y por disponer de licencia pública GNU GPL.

Sobre mySQL podemos decir que es uno de los Sistemas Gestores de Bases de Datos más populares desarrollado bajo la filosofía de código abierto. Según las cifras de sus desarrolladores y distribuidores, existen más de seis millones de copias de mySQL funcionando en la actualidad, lo que supera las cifras de cualquier otra herramienta de bases de datos. Se trata de un servidor de Bases de Datos multiplataforma, por lo que en principio no necesitamos disponer de un sistema operativo específico para soportarlo.

La versión del servidor de base de datos utilizado es la 5.0.51. Para su instalación se ha usado el paquete Xampp, que contiene también otras utilidades que sirven de ayuda para la gestión de la base de datos.

2.6.1. Paquete Xampp

XAMPP es un servidor independiente que consiste principalmente en la base de datos mySQL, el servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl.

Lo más importante es que dispone de la utilidad phpMyAdmin, que proporciona un entorno amigable para la creación y gestión de bases de datos existentes en un servidor mySQL. El servidor Xampp se puede descargar de su página web oficial. La instalación es inmediata y no necesita ninguna configuración especial.


66

3. Servicio de Hoja de Quejas y Reclamaciones

3.1. Descripción

El servicio de Hoja de Quejas y Reclamaciones está formado por dos aplicaciones desarrolladas en tecnología Java, una aplicación cliente implementada en Java ME y una aplicación servidor desarrollada en Java SE.

Este servicio permite al usuario interponer una reclamación de forma telemática. El hecho de que el usuario envíe dicha reclamación firmada digitalmente le da un carácter de oficialidad al proceso. Evidentemente, se trata de una versión móvil del servicio de Libro de Quejas y Reclamaciones de la Junta de Andalucía donde, mediante el uso de la infraestructura de clave pública, se puede interponer una reclamación totalmente oficial disponiendo de un certificado digital personal.

En los siguientes apartados se describen por separado los desarrollos en la parte cliente y en la parte servidor, con el fin de caracterizar las funcionalidades que aporta cada una de ellas.

3.2. Cliente

A continuación se describen aspectos técnicos y de uso de la aplicación MidletQuejas. Se trata de una aplicación J2ME que permite al usuario interponer una reclamación firmada digitalmente usando un teléfono móvil.

Este MIDlet ha sido desarrollado con el fin de realizar la firma digital de una queja, con propósitos de autenticación y no repudio por parte del firmante. La reclamación se envía al servidor, el cual archiva el fichero de firma para su procesamiento posterior. La aplicación está desarrollada en J2ME empelando el entorno de desarrollo NetBeans IDE 6.0.1.

3.2.1. Estructura de Paquetes

La aplicación se compone de 3 paquetes como se puede observar en la ilustración.

Figura 15. Estructura de paquetes de MidletQuejas.


67

Éstos son:

• Paquete de Configuración. En él se incluye la clase infoData mediante la cual se accede al archivo mozart.properties que contiene la dirección IP del servidor, así como otros atributos configurables.

• Paquete de Negocio. Contiene la clase Firma que realiza la firma digital y la clase

Red que proporciona métodos para el establecimiento de las conexiones de red HTTP y SSL.

• Paquete de Presentación. En este paquete se encuentra el MIDlet de la aplicación.

El único parámetro configurable de las aplicaciones J2ME es la url del servidor. Debido a que la dirección del servidor puede ser distinta dependiendo del entorno donde se haga la prueba, se incluye un archivo .properties en cada aplicación con el fin de poder modificar ese parámetro sin necesidad de acceder al código fuente. El fichero mozart.properties se encuentra en la carpeta res de cada aplicación.

3.2.2. Dependencias

Las librerías más importantes de las que hace uso la aplicación son las pertenecientes a la API de Sun: Security and Trust Services (Satsa). Estas clases están incluidas en el Mobility Pack existente en NetBeans, por lo que no hace falta añadirlas explícitamente. El resto de librerías son comunes de J2ME.

3.2.3. Funcionamiento

La navegación a través de la aplicación es bastante intuitiva, por lo que no hace falta detallar exhaustivamente todas las pantallas que la componen. Una vez iniciada se dispone de un menú de ayuda, donde se informa del servicio que se ofrece, así como de una breve guía de uso.

Una vez ejecutada la aplicación, aparece una pantalla de bienvenida. Pulsando inicio se comienza el proceso. Mientras se establece la conexión SSL con el servidor y se produce el intercambio de certificados digitales pueden transcurrir varios segundos.

Una vez seleccionado el certificado digital personal se muestran por pantalla los datos personales del usuario y se proporciona un cuadro de texto para redactar el contenido de la queja.

Una vez escrita la reclamación, se muestra por pantalla un resumen de los datos que se van a firmar digitalmente. Al realizar la firma digital se solicita de nuevo el certificado digital personal. Cuando los datos se han firmado se procede con el envío de la firma digital al servidor, y se recibe la respuesta del mismo. Con esto finaliza la aplicación.


68

3.3. Servidor

En este apartado se describen aspectos técnicos y de funcionamiento de la aplicación hojadequejas. Se trata de una aplicación Java 2 SE que consta de un Servlet encargado de la interacción con MidletQuejas, que permite al usuario interponer una reclamación de forma telemática.

El Servlet ha sido desarrollado para interaccionar con su MIDlet correspondiente. Lo primero que recibe es un intento de conexión SSL, por lo que inicia el intercambio de certificados con el cliente. Tras eso, permanece a la espera para recibir el archivo con la queja, que ha sido firmada digitalmente por parte del usuario del servicio, y una vez recibida, la almacena convenientemente para ser procesada y verificada con posterioridad por un tercero. La aplicación está desarrollada en J2SE empleando el entorno de desarrollo NetBeans IDE 6.0.1.


La aplicación se compone de dos paquetes como se puede observar en la ilustración.

Figura 16. Estructura de paquetes de hojadequejas.

Éstos son:

• Paquete de Negocio. Este paquete está divido a su vez en:

Paquete servlet. Contiene el servlet que gestiona la interacción con el cliente.

Paquete x509. Conjunto de clases que proporcionan capacidades para la

extracción de datos de un certificado digital. Se utilizan para extraer los datos del certificado digital del usuario que se conecta con el servidor. Se extraen los datos personales para que el formulario que se presenta en el terminal móvil contenga dichos datos.

3.3.2. Dependencias

Las librerías de la que hace uso la aplicación es la siguiente:


69

• BouncyCastle Provider. Proveedor de seguridad de BouncyCastle. El archivo que contiene la librería se denomina bcprov-jdk14-138.jar.

• Librería de Apache Codecs. Utilizada para la de/codificación de formatos

Hexadecimal y base64. Se denomina org.apache.commons.codec.jar.


El Servlet se compone de una página web JSP (hojadequejas/index.jsp) que incluye dos hipervínculos. Uno de ellos conduce a la última queja recibida, para ser descargada; y el otro es un enlace para comprobar el correcto funcionamiento del servidor. Este último es hojadequejas/mozart.

Una vez se inicia la aplicación móvil, por parte del usuario del servicio, el servidor comienza a interactuar con dicho MIDlet para establecer la conexión segura sobre SSL. Mientras se esté produciendo dicha operación, con el intercambio de certificados digitales, pueden transcurrir varios segundos.

Una vez establecida la conexión HTTPS, el Servlet queda a la espera de recibir la firma digital al final del proceso.

Una vez que el usuario ha escrito la reclamación, y la ha firmado, éste procede al envío hacia el servidor por lo que, de esta forma, la operación queda almacenada y registrada. Si esto se produce con éxito se envía una respuesta de “OK” al MIDlet y el proceso se da por concluido.

El proceso realmente finalizaría con la descarga por parte de un tercero del archivo que contiene la firma, estando dicho archivo alojado en hojadequejas/Signature.esig.


70

4. Servicio de Gestión de Trámites

4.1. Descripción

El servicio de Gestión de Trámites es el más completo de los dos desarrollados en el proyecto. Ofrece todas las capacidades de firma digital que ofrecía el servicio de Hoja de Quejas además de gestionar una base de datos donde se almacenan los trámites relativos a cada usuario, así como el estado en el que se encuentran.

Se trata de un servicio parecido al que puede ofrecer la plataforma Port@firmas de la Junta de Andalucía. Como se puede apreciar, los desarrollos realizados se encuentran muy integrados en las necesidades comerciales actuales. Tanto el servicio de Hoja de Quejas como el de Gestión de Trámites han sido desarrollados con objetivos funcionales y no por mera investigación y documentación.

El usuario, mediante el uso de su certificado digital, obtiene un resumen de trámites pendientes con la administración o cualquier otra entidad. En ese punto decide a qué trámite desea dar su consentimiento mediante la firma digital de los datos relativos a dicha operación. Toda esa información se encuentra almacenada y custodiada en una base de datos.

Como gestor de base de datos se ha empleado MySQL por motivos explicados en el apartado correspondiente a la descripción de la solución adoptada. En los siguientes apartados se describen por separado los desarrollos en la parte cliente y en la parte servidor, con el fin de caracterizar las funcionalidades que aporta cada una de ellas.

4.2. Cliente

A continuación se describen aspectos técnicos y de uso de la aplicación MidletTrámites. Se trata de una aplicación J2ME que permite al usuario realizar una consulta de trámites pendientes, multas o facturas, para posteriormente generar una firma digital de los mismos con el fin de confirmar su consentimiento.

El MIDlet ha sido desarrollado con el fin de realizar la firma digital de un trámite administrativo o factura empresarial, con propósitos de autenticación y no repudio por parte del firmante. El trámite se recupera de la Base de Datos alojada en el servidor, en función de la identidad del usuario, y se presenta por pantalla solicitando su firma. La aplicación está desarrollada en J2ME empleando el entorno de desarrollo NetBeans IDE 6.0.1.


71



Figura 17. Estructura de paquetes de MidletTramites.

Éstos son:

• Paquete de Configuración. En él se incluye la clase infoData mediante la cual se accede al archivo mozart.properties que contiene la dirección IP del servidor, así como otros atributos configurables.

• Paquete de Negocio. Contiene la clase Firma que realiza la firma digital y la

clase Red que proporciona métodos para el establecimiento de las conexiones de red HTTP y SSL.

• Paquete de Presentación. En este paquete se encuentra el MIDlet de la

aplicación. El único parámetro configurable de las aplicaciones J2ME es la url del servidor. Debido a que la dirección del servidor puede ser distinta dependiendo del entorno donde se haga la prueba, se incluye un archivo .properties en cada aplicación con el fin de poder modificar ese parámetro sin necesidad de acceder al código fuente. El fichero mozart.properties se encuentra en la carpeta res de cada aplicación.

4.2.2. Dependencias

Las librerías más importantes de las que hace uso la aplicación son las pertenecientes a la API de Sun: Security and Trust Services (Satsa). Estas clases están incluidas en el Mobility Pack existente en NetBeans, por lo que no hace falta añadirlas explícitamente. El resto de librerías son comunes de J2ME.


Una vez ejecutada la aplicación, aparece una pantalla de bienvenida. Pulsando inicio se comienza el proceso. Mientras se establece la conexión SSL con el servidor y se produce el intercambio de certificados digitales pueden transcurrir varios segundos.


72

Una vez seleccionado el certificado digital personal, aparece un resumen con los trámites pendientes. Se elige el tipo de trámite que se desea realizar y se confirma para hacer la petición al servidor.

El servidor envía el concepto del trámite elegido para que el usuario lo firme si desea. Al realizar la firma digital se solicita de nuevo el certificado digital personal. Cuando los datos se han firmado se procede con el envío de la firma digital al servidor, y se recibe la respuesta del mismo. Con esto finaliza la aplicación.

4.3. Servidor

En este apartado se describen aspectos técnicos y de funcionamiento de la aplicación multasyfacturas. Se trata de una aplicación Java 2 SE que consta de un Servlet encargado de la interacción con MidletTramites, que permite al usuario del servicio recuperar sus trámites pendientes con la administración y las facturas y recibos pendientes, para proceder a firmarlos digitalmente si lo desea.

Este Servlet ha sido desarrollado para interaccionar con su MIDlet correspondiente. Lo primero que recibe es un intento de conexión SSL, por lo que inicia el intercambio de certificados con el cliente. Tras eso, procede a realizar la consulta a la Base de Datos de trámites mediante SQL. Dicha consulta la hace en base al NIF del usuario, y de éste modo recupera los trámites que tiene pendiente. Una vez realizado esto, queda a la espera para recibir el archivo con la notificación del trámite, que ha sido firmada digitalmente por parte del usuario del servicio.

De este modo, una vez recibida, la almacena convenientemente para ser procesada y verificada con posterioridad por un tercero. La aplicación está desarrollada en J2SE empleando el entorno de desarrollo NetBeans IDE 6.0.1.



Figura 18. Estructura de paquetes de multasyfacturas.


73

• Paquete de Datos. Contiene la clase que proporciona los métodos para interaccionar con una base de datos mySQL.

• Paquete de Negocio. Dividido en:

Subpaquete servlet. Contiene el servlet que gestiona las peticiones del

cliente.

Subpaquete x509. Conjunto de clases que proporcionan capacidades para la extracción de datos de un certificado digital. Se extraen los datos personales para que el formulario que se presenta en el terminal móvil contenga dichos datos.

4.3.2. Dependencias

Las librerías de las que hace uso la aplicación son las siguientes:

• BouncyCastle Provider. Proveedor de seguridad de BouncyCastle. El archivo que contiene la librería se denomina bcprov-jdk14-138.jar.

• Librería de gestión de conexiones con la Base de Datos mediante SQL. Se

trata del archivo mysql-connector-java-3.1.8-bin.jar.

• Librería de Apache Codecs. Utilizada para la de/codificación de formatos Hexadecimal y base64. Se denomina org.apache.commons.codec.jar.


El Servlet se compone de varias páginas web JSP:

• multasyfacturas/index.jsp: incluye dos hipervínculos.

Uno de ellos conduce a una tabla que muestra todas las entradas de la Base de Datos de los trámites existentes, en la que es posible acceder a las firmas digitales que se hayan realizado para el trámite correspondiente; y así poder ser descargada. Esta página se denomina: multasyfacturas/consulta.jsp.

El otro es un enlace para comprobar el correcto funcionamiento del servidor: multasyfacturas/mozart.

Una vez se inicia la aplicación móvil, por parte del usuario del servicio, el servidor comienza a interactuar con dicho MIDlet para establecer la conexión segura sobre SSL. Mientras se esté produciendo dicha operación, con el intercambio de certificados digitales, pueden transcurrir varios segundos.

Una vez establecida la conexión SSL, el Servlet realiza una consulta SQL a la Base de Datos para buscar los trámites pendientes del usuario, en función de su NIF, y se los envía


74

al MIDlet. A partir de ahí, queda a la espera de recibir la firma digital del trámite correspondiente.

Una vez que el usuario ha leído su trámite y desea enviar su firma digital para confirmar la notificación al tercero (prestador del servicio), éste procede al envío hacia el servidor por lo que, de esta forma, la operación queda almacenada y registrada. Si esto se produce con éxito se envía una respuesta de “OK” al MIDlet, se actualizan las entradas implicadas en la Base de Datos, y el proceso se da por concluido.

El proceso realmente finalizaría con la descarga por parte de un tercero del archivo que contiene la firma, pudiendo ser consultado en la tabla de estado de la Base de Datos que se encuentra en la siguiente URL: multasyfacturas/consulta.jsp.

4.4. Estructura de la Base de Datos

A continuación se detalla la estructura que debe tener la base de datos de la aplicación de gestión de trámites. La tabla lista_tramites está compuesta por seis columnas y por un número de filas dependiente del número de trámites introducidos en la base de datos.

Las columnas son las siguientes:

• id. Se usa como clave de la tabla y es única para cada entrada. Enumera los trámites.

• nif. Identifica al usuario.

• tramite. Los posibles valores son multa o factura. Sirve para diferenciar el tipo de trámite.

• concepto. Información del trámite.

• firmado. Indica si se tiene la versión firmada por el usuario. Los posibles valores son si o no.

• ruta_firma. Se guarda la ruta del archivo de firma digital recibida.

La etiqueta de cada columna debe estar escrita en minúsculas y sin tildes. Para poder utilizar la aplicación usando un certificado digital distintos de los usados en las pruebas, sería necesario modificar la columna nif de la tabla lista_tramites.


75

5. Servicio Desarrollado

La arquitectura final de las aplicaciones desarrolladas proporciona un Servicio de Notificación de Trámites Administrativos y Recibos al Ciudadano, utilizando las facilidades que ofrecen los certificados de la FNMT y la firma digital desde el teléfono móvil. A continuación se resumen sus aspectos fundamentales.

5.1. Arquitectura

El proceso de funcionamiento del servicio atraviesa fundamentalmente por cuatro entidades necesarias. Estas entidades son el teléfono móvil, un servidor para la gestión de certificados y las firmas realizadas y su almacenamiento, una base de datos para el procesamiento de los trámites, y un portal Web móvil.

Figura 19. Arquitectura del Servicio de Trámites Administrativos y Hoja de Quejas.

A continuación se detallan de forma somera (en apartados posteriores se comentará con más profundidad el flujo de trabajo):

• Terminal móvil. Se trata del Nokia N95 que se ha utilizado durante todo el desarrollo del proyecto. El móvil dispone de un certificado de la F.N.M.T. instalado correctamente en su sistema operativo Symbian.

• Sistema de gestión de la firma y de almacenamiento. Consta de dos Servlets Java. Uno de ellos se ha diseñado para el servicio de recogida de quejas firmadas


76

digitalmente por el usuario; el otro para interactuar con el MIDlet de trámites administrativos y su Base de Datos asociada.

• Base de datos para gestionar los trámites. Implementada en MySQL, con el propósito de gestionar el correcto funcionamiento y almacenamiento de los trámites iniciados por la Administración y por otras entidades que requieran su uso. En esta demostración se incluyen varias facturas a modo de ejemplo.

• Portal Web Móvil. A través del navegador del teléfono se accede al portal para la descarga de la aplicación necesaria en cada caso. Este proceso abarca el primer paso del flujo de trabajo.

5.2. Funcionamiento

Como requisito se establece que el terminal móvil contenga instalado un certificado válido de la FNMT en el elemento de seguridad que integra el sistema operativo Symbian.

A partir de ahí, un primer paso consiste en la conexión al Portal Mozart Móvil, creado en HTML estático por lo que no procede entrar en más detalle, en el que se presentan las utilidades que ofrece. Básicamente se ofrece una pantalla en la que el usuario debe elegir el trámite que desea realizar, bien sea una consulta para recibir las notificaciones que la Administración quiera enviarle y firmarlas (si así lo quiere el usuario) o bien interponer una queja firmada digitalmente ante el servicio prestador de Quejas.

Según el servicio elegido, el usuario obtendrá un prompt en el que se le insta a aceptar la descargar del MIDlet correspondiente a cada trámite. Una vez instalado el MIDlet, se procede a su ejecución desde el menú de aplicaciones del teléfono.

En este capítulo se procede a describir el flujo de trabajo de la solución final empleando el MIDlet del Servicio de Notificación de Trámites (midletTramites.jar), debido a que su funcionamiento abarca todas las funcionalidades que presenta la aplicación de Hoja de Quejas.

Al ejecutar el MIDlet se solicita al usuario que seleccione su certificado digital personal para el acceso a la aplicación. Tras ello se comienza el proceso de establecimiento de una conexión segura sobre SSL entre el teléfono y el servidor de gestión de firmas y almacenamiento (en adelante “servidor”). De esta forma el servidor obtiene del certificado del usuario los datos necesarios para llevar a cabo la consulta a la Base de Datos mediante SQL. Con esto se establece la conexión entre servidor y Base de Datos, descargándose toda la información relativa a los trámites que tiene pendientes el usuario del Servicio.

Teniendo conocimiento el servidor de los trámites que ya puede presentar al usuario, se recupera la conexión con el MIDlet y se le envían los mismos para que seleccione aquel del que quiera mayor detalle, así como la posibilidad de firmarlo digitalmente para indicar


77

a la Administración que se ha recibido la notificación o a la compañía eléctrica que proceda al cobro de una factura, por ejemplo.

Las aplicaciones que componen el nuevo Servicio tienen como núcleo, para la realización de la firma digital móvil, el desarrollo que permitió llevar a cabo el primer MIDlet desarrollado en el proyecto (MozartPKI), por lo que a partir de ahí el proceso es el mismo excepto en un detalle.

El MIDlet MozartPKI fue el primer prototipo creado en el proyecto. Se trata de una aplicación Java ME básica en la que se realiza la firma digital de un texto de prueba y se envía el resultado a un servidor para su validación posterior. Realmente, fue el primer resultado satisfactorio del proyecto, ya que hasta entonces, las posibilidades de firmar digitalmente mediante el uso de un teléfono móvil parecían escasas.

Volviendo a la explicación del servicio desarrollado, una vez realizada la firma digital de los datos se envía el archivo que contiene dicha firma al servidor, y tras ello se actualiza la correspondiente entrada en la Base de Datos, indicándose con ello que el trámite ha sido notificado correctamente y el archivo que contiene la firma digital se custodia en el servidor para su validación.

Para llevar a cabo la validación se ha propuesto el uso de la aplicación de verificación eSigna Viewer de Indenova S.L. a través de la interfaz Web de “Estado de la Base de Datos” que ofrece el servidor.

5.3. Flujo de Trabajo

En este apartado se mostrará un ejemplo de funcionamiento, mediante capturas de pantalla, de la versión final de la aplicación del proyecto, desde que el usuario se conecta por Internet al Portal Móvil de Mozart hasta que la firma es correctamente verificada por parte de un tercero (proveedor del Servicio).

5.3.1. Conexión al Portal Mozart para la descarga de la aplicación

Lo primero que debe cumplir el teléfono Nokia N95, es que tenga correctamente instalado algún certificado digital personal de la FNMT en el Elemento de Seguridad (SE) del sistema operativo Symbian. Se puede comprobar navegando por los menús del teléfono:

Menú > Herramientas > Ajustes > Generales > Seguridad > Gestión de Certificados > Personales

Y ahí debería aparecer al menos un Certificado válido de la FNMT, en el caso de la demostración tenemos la siguiente pantalla:


78

Figura 20. Certificados instalados en el SE del teléfono.

Tras esta comprobación ya se puede iniciar el navegador para acceder al Portal Web Móvil del Proyecto Mozart, para así seleccionar y descargar el MIDlet del servicio que se desea utilizar (como se dijo anteriormente, para esta prueba se utilizará el Servicio de Notificación de Trámites).

Figura 21. Selección y descarga de la aplicación en el teléfono.

Figura 22. Aplicación instalada en el teléfono.

Como se observa, en el menú de aplicaciones aparece correctamente instalada la aplicación del Servicio de Notificación de Trámites. El siguiente paso consiste en la ejecución del propio MIDlet para iniciar el servicio.


79

5.3.2. Ejecución del MIDlet: Pantallas de inicio

Figura 23. Pantallas de Bienvenida y de información del Servicio.

Al pulsar sobre el botón de inicio, la aplicación inicia el proceso de establecimiento de la conexión segura SSL, con el consiguiente intercambio de certificados entre cliente y servidor.

Figura 24. Intercambio de Certificados Cliente – Servidor.

A partir de aquí ya se tiene establecida la conexión segura SSL y el servidor, a partir de los datos del certificado del usuario, realiza una consulta SQL a la Base de Datos para recuperar los trámites que tiene pendientes de firmar. De ésta forma, el servidor ya está en condiciones de mostrar al usuario dicha información.

5.3.3. Ejecución del MIDlet: Consulta de trámites pendientes y firma

Figura 25. Trámites pendientes para el usuario y selección de uno de ellos.


80

En esta demostración se observa que el usuario dispone de dos multas de tráfico y de una factura o recibo pendiente. Se posiciona sobre el menú de selección y se confirma el tipo de trámite que se desea realizar para que el servidor proceda con su envío, en este caso se trata de una multa:

Figura 26. Trámite recibido en pantalla del usuario y proceso de Firma Digital.

Una vez el usuario ha leído el concepto de la sanción, puede firmar digitalmente la notificación. Tras ello, dicha firma se envía al servidor y éste actualiza la correspondiente entrada de la Base de Datos, y además almacena el archivo que contiene la firma digital para su posterior verificación.

5.3.4. Ejecución del MIDlet: Envío de datos al servidor

Figura 27. Pantallas de confirmación del Servidor y de despedida.

A partir de aquí el usuario móvil ya ha concluido el proceso. Corresponde a un tercero, el proveedor del Servicio, la verificación del archivo PKCS#7/CMS para su validación. En esta demostración se utiliza el programa eSigna Viewer de Indenova S.L. para su verificación.

5.3.5. Comprobación del estado de la Base de Datos y de la firma

Antes de comprobar la firma, se puede comprobar en el servidor que la entrada correspondiente de la Base de Datos ha sido actualizada y que el trámite se ha realizado correctamente, mediante la consulta a la página consulta.jsp:


81

Figura 28. Tabla con las entradas de la Base de Datos.

El archivo Signature1.esig se corresponde con la firma digital que el usuario ha generado sobre esa notificación. Puede ser descargado desde esta misma pantalla para su verificación, siendo en este caso mediante eSigna Viewer.

Figura 29. Verificación del archivo que contiene la firma digital.

Como se puede comprobar, la firma es válida. Pues se mantiene la integridad, el certificado de la firma es válido (no caducado) y está emitido por una Autoridad de Certificación de Confianza (en este caso la FNMT).

También se muestra como información la fecha y hora de la Firma, y que no se ha consultado la CRL (Certificate Revocation List) de la FNMT (algo lógico ya que no se dispone de acceso a su directorio LDAP). Como adjunto se muestra el contenido del mensaje que se ha firmado, aquí se trata de una supuesta infracción de tráfico por exceso de velocidad.

capítulo ii. desarrollo de las aplicacionesbibing.us.es/proyectos/abreproy/11722/descargar... ·...

Documents