Diseño y desarrollo de un sistema para guardar

facturas electrónicas de manera privada y

segura en la nube

Nom Estudiant: José Luis Herranz Martín

Programa: Máster Universitario en Seguridad de las Tecnologías de la

Información y de las Comunicaciones (MISTIC)

Nombre Consultor: Jordi Castellà

Roca Centro: Universitat Oberta de

Catalunya Data Entrega:

11/06/2019
i
 FICHA DEL TRABAJO FINAL

Diseño y desarrollo de un sistema para

guardar facturas electrónicas de manera
Título del trabajo:
privada y segura en la nube

Nombre del autor: José Luis Herranz Martín

Nombre del consultor: Jordi Castella Roca

Fecha de entrega (mm/aaaa): 06/2019

Área del Trabajo Final: Seguridad en aplicaciones web

Máster Universitario en Seguridad de las

Titulación: Tecnologías de la Información y de las
Comunicaciones (MISTIC)

Resumen del Trabajo (máximo 250 palabras):

Las empresas están cambiando las facturas en papel por facturas

electrónicas con el fin de reducir costes y mejorar la eficiencia. En España
tras la publicación de la orden PRE/2971/2007 donde se define el formato
de factura electrónica "Facturae", las administraciones públicas obligan a
sus proveedores a presentar las facturas en este formato. Las facturas
electrónicas tienen un formato XML y están firmadas electrónicamente
según el formato XMLDSig Enveloped con extensiones XADES-EPES.

Este trabajo tiene como objetivo cubrir una necesidad como es la de

validar y guardar, de manera segura y en un único punto accesible sólo
por el usuario, todas las facturas electrónicas de los gastos que ha
realizado. Además se quiere que el usuario pueda guardar una copia de
las facturas en un servicio en la nube en la que se garantice la privacidad
de los datos del usuario de manera que para el proveedor del servicio no
sea posible saber cuáles son los gastos de los usuarios.

El sistema desarrollado tendrá dos partes: una aplicación servidor que

cubrirá la necesidad de guardar de manera segura las facturas en la nube
garantizando al usuario la integridad, privacidad y disponibilidad de las
mismas, y una aplicación para dispositivos móviles que permitirá
gestionar, validar y guardar en la nube las facturas del usuario.

ii
 Abstract (in English, 250 words or less):

Las empresas están cambiando las facturas en papel por facturas

electrónicas con el fin de reducir costes y mejorar la eficiencia. En España
tras la publicación de la orden PRE/2971/2007 donde se define el formato
de factura electrónica "Facturae", las administraciones públicas obligan a
sus proveedores a presentar facturas en este formato. Las facturas
electrónicas tienen un formato XML y se firman electrónicamente en
formato XMLDSig Enveloped con extensiones XADES-EPES.

Este trabajo pretende cubrir una necesidad como es la de validar y

guardar, de forma segura y en un único punto accesible únicamente para
el usuario, todas las facturas electrónicas por los gastos que el usuario
haya realizado. Además, el usuario podría guardar una copia de las
facturas en un servicio en la nube que garantice la privacidad de los datos
del usuario para que no sea posible que el proveedor del servicio conozca
cuáles son los costes de los usuarios.

El sistema desarrollado constará de dos partes: una aplicación servidor

que cubrirá la necesidad de almacenar de forma segura las facturas en
la nube garantizando al usuario la integridad, privacidad y disponibilidad
de sus facturas, y una aplicación para dispositivos móviles que permitirá
gestionar, validar y guardar las facturas del usuario en la nube.

Palabras clave (entre 4 y 8):

Facturas electrónicas, almacenamiento remoto, seguro, privado,

iii
 Agradecimientos

Quiero agradecer la ayuda y el apoyo de mi tutor del TFM. Por segunda vez nos
encontramos en una situación como esta después de 12 años. Gracias por sus
ideas, argumentos y retos.

Gracias a todas las personas a las que he explicado de qué iba el trabajo y cuáles
eran mis dudas, y que sin saberlo me han respondido a mis preguntas.

Y sobre todo gracias a mi mujer y a mi hija por todo el apoyo, apoyo, y ánimos
para poder llevar a cabo este trabajo. Sin ellas no hubiera sido posible.

iv
 Índice

1. Introducción ................................................................................................. 1
1.1 Objetivos del Trabajo .............................................................................. 2
1.2 Enfoque y método seguido ..................................................................... 2
1.3 Planificación del Trabajo ......................................................................... 3
1.4 Breve sumario de productos obtenidos .................................................. 4
1.5 Breve descripción de los otros capítulos de la memoria ......................... 4
2. Tecnologías utilizadas ................................................................................. 5
2.1 Servidor: ................................................................................................. 5
2.1.1 Bota de primavera ........................................................................... 5
2.1.2 MySQL............................................................................................. 5
2.2 Para la parte móvil .................................................................................. 6
2.2.1 Androide .......................................................................................... 6
2.2.2 SQLite.............................................................................................. 7
2.2.3 Factura-e ......................................................................................... 7
3. Arquitectura i disseny .................................................................................. 8
3.1 Requerimientos del proyecto .................................................................. 8
3.1.1 Servidor ........................................................................................... 8
3.1.2 Aplicación móvil ............................................................................... 9
3.2 Casos de uso ........................................................................................ 10
3.2.1 Alta de usuario en el sistema ............................................................. 11
3.2.2 Inicio de sesión .................................................................................. 13
3.2.3 Facturación de facturas y copia de seguridad en la nube .................. 14
3.2.4 Descarga de factura de la nube ......................................................... 14
3.2.5 Consultas de gastos .......................................................................... 14
3.2.6 Copia de seguridad del almacén de datos ......................................... 14
3.3 Justificació d’una infraestructura de clau pública .................................. 15
3.4 Justificación de un cifrado simétrico ..................................................... 15
4. Desarrollo de la solución ........................................................................... 17
4.1 Diagrama de components del servidor ................................................. 17
4.2 Diagrama de classes del servidor ......................................................... 18
4.3 Creació d’una infraestructura de clau pública ....................................... 25
4.4 Creación de las tablas en la base de datos del servidor ....................... 26
4.5 Diagrama de componentes de la aplicación móvil ................................ 28
4.6 Gestión de la seguridad ........................................................................ 29
4.7 Procesado de los ficheros de factura recibidos .................................... 31
4.8 Descarga de facturas del servidor ........................................................ 33
4.9 Copia de seguridad manual del almacén de datos en el servidor......... 34
5. Juego de pruebas ...................................................................................... 36
5.1 Inicio de la aplicación............................................................................ 36
5.2 Operación de activación de usuario...................................................... 38
5.3 Operación de inicio de sesión de usuario ............................................. 41

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

v
 5.4 Facturas a ser tratadas ......................................................................... 43
5.5 Facturas subidas al servidor ................................................................. 46
5.6 Facturas procesadas ............................................................................ 48
5.7 Copia de seguridad del almacén de llaves ........................................... 51
6. Conclusiones ............................................................................................. 53
7. Glosarios ................................................................................................... 54
8. Bibliografía ................................................................................................. 55
9. Anexos....................................................................................................... 56
9.1 Instalación del entorno de desarrollo .................................................... 56
9.1.1 Servidor ............................................................................................. 56
9.1.2 Aplicación móvil ................................................................................. 57
9.2 Creació de la infraestructura de clau pública ........................................ 57
9.3 Creación de base de datos y tablas en el servidor ............................... 64

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

vi
 Lista de figuras

Ilustración 1 Planificación del desarrollo del proyecto ........................................ 3

Il·lustració 2 Esquema general del sistema ........................................................ 8
Ilustración 3 Casos de uso del usuario............................................................. 10
Ilustración 4 Proceso de alta de un usuario en el sistema ............................... 11
Ilustración 5 Diagrama de secuencia de inicio de sesión ................................. 13
Il·lustració 6 Diagrama de components del servidor......................................... 17
Il·lustració 7 Diagrama de classes del servidor ................................................ 19
Ilustración 8 Detalle de las clases del módulo config ....................................... 20
Ilustración 9 Diagrama de clases del módulo controllers ................................. 21
Ilustración 10 Diagrama de clases del módulo modelo .................................... 23
Ilustración 11 Diagrama de clases del módulo repos ....................................... 23
Ilustración 12 Diagrama de clases del módulo util ........................................... 24
Ilustración 13 Diagrama de clases del módulo vo ............................................ 24
Il·lustració 14 Diagrama de taules de la base de dades del servidor ............... 27
Ilustración 15 Diagrama de paquetes de la aplicación móvil ............................ 28
Il·lustració 16 Diagrama de classes del paquet util .......................................... 29
Ilustración 17 Diagrama de secuencia parcial del procesado del fichero firmado 31
Ilustración 18 Fase de cifrado de la factura...................................................... 32
Ilustración 19 Cifrado de la factura firmada ...................................................... 32
Ilustración 20 Descifrado de una factura descargada ...................................... 33
Ilustración 21 Descifrado del fichero XML descargado .................................... 34
Ilustración 22 Envío del almacén de llaves cifrado ........................................... 35
Ilustración 24 Pantalla de inicio con el servidor fuera de línea ......................... 37
Ilustración 25 Pantalla de inicio con el servidor en línea .................................. 37
Ilustración 26 Pantalla de registro de usuario .................................................. 38
Ilustración 27 Registro de usuario: nombre de usuario no válido ..................... 39
Ilustración 28 Registro de usuario: contraseña no válida ................................. 39
Ilustración 29 Registro de usuario: usuario correctamente registrado ............. 40
Ilustración 30 Mensaje para verificar el correo del usuario .............................. 40
Ilustración 31 Respuesta a la habilitación del usuario ...................................... 41
Ilustración 32 El correo ha caducado o bien ya ha sido utilizado ..................... 41
Ilustración 33 Usuario inicia correctamente sesión .......................................... 42
Ilustración 34 Pantalla con las opciones disponibles ....................................... 43
Ilustración 35 Pantalla con los ficheros de factura disponibles en el sistema .. 44
Ilustración 36 El fichero tratado tiene una firma no válida ................................ 45
Ilustración 37 Información de la factura procesada .......................................... 45
Ilustración 38 Información de la copia de seguridad de la factura al servidor .. 45
Ilustración 39 No hay facturas al servidor ........................................................ 47
Ilustración 40 Hay facturas al servidor ............................................................. 47
Ilustración 41 Descarga de una factura del servidor ........................................ 48
Ilustración 42 Captación para procesar la factura descargada ........................ 48
Ilustración 43 Facturas cargadas al sistema .................................................... 49
Ilustración 44 Menú contextual de opciones con la factura .............................. 50
Ilustración 45 Totales por proveedor ................................................................ 51

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

vii
Ilustración 46 Gráfico totales por proveedor..................................................... 51
Ilustración 47 Opción de copia de seguridad del almacén de datos ................ 52
Ilustración 48 Código QR con los datos que permiten recuperar y descifrar el
almacén de datos ...................................................................................... 52

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

viii
 Lista de tablas

Tabla 1 Requerimientos del servidor .................................................................. 9

Tabla 2 Requerimientos de la aplicación móvil ................................................ 10
Tabla 3 Módulos que componen el servidor..................................................... 18

ix
1. Introducción

Las empresas están cambiando las facturas en papel por facturas

electrónicas con el fin de reducir costes. La Ley 56/2007 [1] de 28 de
diciembre, de "Medidas de Impulso de la Sociedad de la Información"
define en el artículo 1 una factura electrónica como un "documento
electrónico que cumple con los requisitos legales y reglamentariamente
exigibles a las facturas y que, además, garantiza la autenticidad de su
origen y la integridad de su contenido, lo que impide el repudio de la
factura por su emisor". Las facturas electrónicas están firmadas
electrónicamente con lo que se garantiza la autenticidad, integridad y no
repudio de la misma.

Hay varios formatos de factura electrónica. En España tras la publicación

de la orden PRE/2971/2007 donde se define el formato de factura
electrónica "Facturae", las administraciones públicas obligan a sus
proveedores a presentar las facturas en este formato. Las facturas
electrónicas tienen un formato XML y están firmadas electrónicamente
según el formato XMLDSig Enveloped con extensiones XADES-EPES.

Las empresas de más de 100 trabajadores o que facturen más de 6

millones de euros al año en general están obligadas por ley a emitir las
facturas en formato electrónico. Esto implicará que en un tiempo no muy
lejano todas las empresas emitirán facturas electrónicas.

Estas facturas electrónicas deben poder validarse, es decir, determinar

que se han emitido por el proveedor correcto (autenticidad), y que esta
factura no ha sido manipulada (integridad). Esta validación debe hacerse
con un dispositivo, sea un ordenador, una tableta o bien un móvil. Dada la
implantación de los móviles estos pueden hacer esta validación debido a
su capacidad de cálculo.

Con este trabajo se quiere cubrir una necesidad como es la de validar y

guardar, de manera segura y en un único punto accesible sólo por el
usuario, todas las facturas electrónicas de los gastos que ha realizado.

Actualmente estos datos se guardan en papel, si la compra se hace en un

establecimiento, o bien en cada uno de los comercios online o web de
empresas suministradoras de servicios, de manera que para poder tener
una visión global de sus gastos el usuario debe entrar con usuario y
contraseña en cada una de ellas, descargarse las facturas, homogeneizar
formatos y posteriormente hacer el análisis que necesite.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

1
 En este trabajo se quiere crear una herramienta (aplicación móvil y
servicio en la nube) que permita gestionar las facturas electrónicas en un
formato homogéneo, y tener la posibilidad de subirlas a un servicio en la
nube de manera que siempre las tengamos disponibles, evitando que el
proveedor tenga la posibilidad de saber qué y en qué nos gastamos el
dinero, ya que los datos se subirán debidamente protegidos (cifrados).

1.1 Objetivos del Trabajo

El objetivo del trabajo es diseñar e implementar un sistema que permita

validar y guardar de manera segura las facturas electrónicas.

Las necesidades a cubrir son:

 La carga de las facturas en un formato homogéneo.

 La validación de las facturas, de manera que se verifique:
o integridad, es decir, que no hayan sido manipuladas, y
o la autenticidad, que hayan sido firmadas por el proveedor que
las ha emitido.
 La conservación de manera cifrada de las facturas, evitando que el
proveedor de servicios de almacenamiento pueda ver el contenido
de las facturas, asegurando la privacidad del usuario.
 La posibilidad de recuperación en cualquier momento de las
facturas almacenadas
 La posibilidad de ver los gastos que el usuario ha realizado
agrupados por proveedor.

1.2 Enfoque y método seguido

El objetivo a cubrir es que el usuario pueda disponer de un sistema para

validar, guardar y gestionar las facturas electrónicas y además poder
disponer de una copia de las mismas en un servicio en la nube. El foco de
este trabajo es que las copias de las facturas en la nube no puedan ser
manipuladas ni analizadas por el proveedor del servicio, manteniendo la
integridad de las mismas y garantizando la privacidad de los gastos del
usuario. Un objetivo aparte es que el proveedor no pueda comerciar con
estos datos.

El método a seguir es crear una aplicación de servidor que cubre el

objetivo de guardar las facturas electrónicas de manera segura, y una
aplicación para móvil para realizar las operaciones de validación, gestión
y envío de las facturas al servidor en la nube.

Se irán creando y probando cada uno de los requerimientos de la

aplicación. Por eso se generarán una serie de facturas firmadas
digitalmente. Algunas

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

2
 de estas facturas serán erróneas o manipuladas para certificar que la
validación de las mismas funciona.

Las facturas se subirán al servidor de manera que éste no las pueda

visualizar. Para ello se necesitará cifrarlas de manera que sólo el usuario
pueda descifrarlas.

Se probará que éstas se pueden guardar en el servidor y descargarlas y

descifrarlas correctamente.

1.3 Planificación del Trabajo

En el siguiente diagrama de Gantt se muestra la planificación del

desarrollo del proyecto a grandes rasgos.

Ilustración 1 Planificación del desarrollo del proyecto

La primera parte del proyecto es la planificación del mismo. La aplicación

de servidor se dedican unas tres semanas. Se debe desarrollar tanto la
aplicación que recibirá los datos de la aplicación móvil, la persistencia de
los datos, y la seguridad. El sistema será multiusuario.

La siguiente fase es hacer la aplicación móvil, que debe poder validar las
facturas. Se valorarán las librerías disponibles y se harán las pruebas
necesarias. Para esta fase se necesitan unas facturas de ejemplo para
verificar el correcto funcionamiento.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

3
 Se diseñarán las pantallas necesarias para que el usuario pueda llevar a
cabo las tareas de validación, carga y descarga de facturas.

Se generará un juego de pruebas con el fin de validar cada una de las

características implementadas.

1.4 Breve sumario de productos obtenidos

Se obtendrá un sistema formado por dos componentes:

Una aplicación móvil para el sistema operativo Android que permitirá

validar las facturas del usuario, gestionarlas y guardar de manera segura
y encriptada en formato Facturae en un servidor, con una estructura de
clave pública/clave privada.

Una aplicación en el servidor que se encargará de guardar unos datos

básicos de las facturas y los ficheros de las facturas encriptadas de
manera que sólo el usuario pueda desencriptarlas con su clave privada.

1.5 Breve descripción de los otros capítulos de la memoria

En el capítulo 2 de esta memoria se explican las tecnologías utilizadas y

la justificación de su elección. En el capítulo 3 se detallan los requisitos a
cubrir, y se detallan los casos de uso que cubrirá el sistema desarrollado.
En el capítulo 4 se detalla la implementación del sistema. En el capítulo 5
se muestra el funcionamiento del sistema cubriendo cada uno de los
requerimientos detallados en el capítulo 3. En el capítulo 6 se explican las
conclusiones y las líneas de trabajo futuras. En el capítulo 7 se da un
glosario de los términos utilizados en esta memoria. En el capítulo 8 se
detalla la bibliografía consultada. En el capítulo 9 se indica información
que puede ser de interés.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

4
2. Tecnologías utilizadas

Las tecnologías que se han utilizado para desarrollar el proyecto son las
siguientes:

2.1 Servidor:

En la parte de servidor se ha utilizado una aplicación web sin interfaz de

usuario, y un sistema de persistencia. La aplicación web ha disponer de
la opción de conexiones seguras, la opción de poder acceder, consultar y
operar con una base de datos.
2.1.1 Spring Boot

Se debe desarrollar un sistema que permita guardar de manera segura las

facturas y además que garantice la privacidad del usuario. Para ello se
diseñará e implementará una aplicación que se pondrá en funcionamiento
en un servidor y al que se conectarán los usuarios de manera segura y
encriptada. Las conexiones se harán a través de internet por lo que se
utilizará el protocolo TCP/IP para que los usuarios accedan al servidor.

La aplicación de servidor se ha decidido desarrollarla en la plataforma

Spring [4]. La plataforma Spring es un entorno de trabajo que marca una
serie de conceptos, prácticas y criterios para crear aplicaciones de una
manera rápida basadas en el principio de convención sobre configuración
[5] que busca minimizar las decisiones que el desarrollador debe tomar,
sin perder la flexibilidad.

El proyecto Spring Boot [3] permite crear de una manera rápida

aplicaciones con la plataforma Spring [4]. Estas son aplicaciones que
pueden correr de manera autónoma, ya que contienen un servidor web
integrado, evitando así tener que depender de un determinado servidor de
aplicaciones. Simplifican mucho la puesta en marcha de aplicaciones. El
lenguaje de programación que se utiliza para el desarrollo es Java, por lo
que se necesita una máquina virtual Java.

Esta plataforma permite la conexión a diversos sistemas de base de datos.

También permite la creación de una infraestructura de seguridad de
manera que puedan acceder a diversos recursos usuarios que se hayan
autenticado en la aplicación.

2.1.2 MySQL

Los datos encriptados que debe gestionar el servidor se pueden

almacenar de diversas formas: se pueden guardar en memoria, en

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

5
 estructuras de datos que estarán vivas mientras esté el servidor
funcionando, o bien en sistemas de persistencia que nos aseguren de que
los datos se mantendrán si la aplicación se cierra o se reinicia.

Es por ello que se debe utilizar un sistema de gestión de base de datos

que permita guardar indefinidamente estos datos.

De entre los diversos sistemas de base de datos existentes en el mercado

como pueden ser PostgreSQL[6], MySQL[7], SQL Server[8], Oracle[9] se
ha decidido utilizar MySQL. Las razones:

 Es un sistema de base de datos muy popular

con mucha implantación y soportado por la
compañía Oracle,
 El entorno Spring en el que se desarrollará la
aplicación de servidor dispone de soporte para
este sistema de base de datos.
 Permite hacer consultas en formato SQL
estándar y está bien integrado con el lenguaje
de programación Java
 Es un sistema multiplataforma por lo que lo
podemos instalar en casi cualquier servidor.
 Personalmente tengo experiencia en este
sistema y lo he utilizado en otros proyectos
por lo que lo considero una ventaja.

2.2 Para la parte móvil

Se describen a continuación las tecnologías que se utilizarán en el

desarrollo de la aplicación móvil del sistema.
2.2.1 Android

Android es actualmente en 2019 el sistema operativo móvil con más

implantación en todo el mundo según los datos que provee StatCounter
[10]. Esta es una de las razones para haber elegido este sistema operativo
para desarrollar la aplicación móvil.

Android es una plataforma de software de código abierto creada para

teléfonos móviles. Se trata de un proyecto de Google realizado en
colaboración con el Open Handset Alliance [11]. Incluye un sistema
operativo basado en Linux, una interfaz de usuario, aplicaciones,
bibliotecas de código y compatibilidad multimedia, entre otros elementos.

Android se comercializa bajo dos licencias de código abierto. El núcleo

Linux se comercializa bajo la licencia General Public License (GPL) [12] y
la plataforma Android, sin el núcleo, tiene una licencia Apache Software
License (ASL) [13].

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

6
2.2.2 SQLite

Es el sistema de base de datos propio de Android. Es la base de datos

donde se desarán los datos de facturas, en el móvil.

SQLite es una base de datos relacional, al igual que lo es MySQL que se

utiliza en la parte servidor.

El fichero que contiene la base de datos está dentro del sistema de

ficheros de la aplicación con acceso de lectura y escritura sólo por la
aplicación.
2.2.3 Factura-e

Es un estándar promovido por el Ministerio de Industria, Energía y Turismo

para que las empresas proveedoras de las administraciones públicas
presenten las facturas electrónicas de una manera homogénea con un
formato estructurado.

Las facturas a tratar están en formato Factura-e, que son ficheros XML
firmados con una firma digital.

Por esta razón se necesitan librerías que puedan gestionar el formato

Facturae, los ficheros en formato XML y las firmas de estos ficheros.

Para gestionar el formato Facturae generaremos una librería para poder

manejar el documento XML como si fuera un objeto. La librería Java que
usaremos se llama JIBX [21].

Para verificar las firmas Android no dispone de librerías nativas que

puedan facilitar esta tarea. Si que están disponibles en la versión de
escritorio. Para conseguir la verificación de la firma utilizaremos la librería
Apache Santuario [14] que nos permite usarla en un dispositivo Android.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

7
 3. Arquitectura y diseño

El sistema a desarrollar consiste en una aplicación móvil donde el usuario

gestionará las facturas recibidas y una aplicación de servidor donde el usuario
podrá guardar de manera segura las facturas de sus gastos.

Il·lustració 2 Esquema general del sistema

3.1 Requerimientos del proyecto

Los requerimientos a implementar en el proyecto son los siguientes:

3.1.1 Servidor

Para la parte del servidor se definen los siguientes requisitos a

implementar:

Código Descripción
ReqSer-01 El servidor debe poder informar de su estado, si está o no
activo
ReqSer-02 El servidor debe permitir que un usuario se registre
mediante un usuario y contraseña
ReqSer-03 El servidor debe enviar por correo electrónico al usuario un
código con el fin de verificar su identidad. La respuesta al
código habilitará al usuario en el sistema
ReqSer-04 El servidor debe poder aceptar una petición de habilitación
de usuario válida
ReqSer-05 El servidor debe poder entregar un certificado firmado por
una
autoridad certificadora a petición del usuario

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

8
 ReqSer-06 El servidor debe poder guardar una serie de llaves
simétricas cifradas que el usuario le envíe
ReqSer-07 El servidor debe poder guardar una serie de datos de
factura junto con la factura en formato XML de tal
manera que estos datos no puedan ser desencriptadas
por el servidor.
ReqSer-08 El servidor debe poder enviar a petición del usuario el
listado de sus facturas cifradas
ReqSer-09 El servidor ha de poder enviar una factura concreta a
petició de l’usuari
Tabla 1 Requerimientos del servidor

3.1.2 Aplicación móvil

Para la parte de la aplicación móvil se definen los siguientes requisitos a

implementar:

Código Descripción
ReqMob-01 La aplicación debe poder consultar el estado del servidor
ReqMob-02 La aplicación debe permitir que un usuario se registre
mediante un formulario con usuario y contraseña
ReqMob-03 La aplicación debe poder crear un par de claves pública
y privada para cifrar y descifrar asimétricamente
ReqMob-04 L’aplicació ha de poder sol·licitar un CSR (Certificate
Signing Request) en el moment del primer inici de sessió
en el sistema
ReqMob-05 La aplicación móvil debe poder recibir y desarmado de
manera segura el certificado firmado por una autoridad
certificadora que envíe el servidor
ReqMob-06 La ha de poder cifrar i descifrar con clav
aplicación e
simétrica
ReqMob-07 La aplicación móvil debe poder enviar al servidor una serie
de claves simétricas cifradas para que éste las guarde de
manera segura
ReqMob-08 La aplicación móvil debe poder enviar al servidor datos de
factura cifrados para que éste los guarde de manera
segura
ReqMob-09 La aplicación debe poder descifrar una serie de datos de
factura junto con la factura en formato XML que reciba del
servidor.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

9
 ReqMob-10 La aplicación debe poder recibir el listado de sus facturas
cifradas
ReqMob-11 La aplicación debe poder desartar facturas en el móvil
ReqMob-12 La aplicación debe poder borrar facturas que haya en el
móvil
ReqMob-13 La aplicación debe poder hacer estadísticas con los
datos de las facturas que hay en el móvil
ReqMob-14 La aplicación debe poder descargarse una factura del
servidor y cargarla en el móvil.
ReqMob-15 La aplicación debe permitir al usuario cerrar la sesión
Tabla 2 Requerimientos de la aplicación móvil

3.2 Casos de uso

En la Ilustración 3 se muestran los casos de uso del usuario de la

aplicación móvil.

Ilustración 3 Casos de uso del usuario

El usuario debe poder saber en todo momento si el servidor está o no

activo según se ha establecido en los requerimientos.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

10
 Tiene que tener la posibilidad de registrarse en el servicio para poder
utilizar el sistema.
Tiene que poder iniciar sesión en el sistema. Debe poder desar las
claves de cifrado para tener una copia de seguridad de las mismas.

El usuario debe poder guardar una factura al servidor y recuperarla.

Tiene que poder recuperar todas las facturas.

El usuario debe tener la posibilidad de guardar el almacén de llaves,

donde tendrá las llaves y contraseñas.

Los casos de uso del servidor son los siguientes:

 Debe indicar si está o no activo.

 Debe disponer de una función que permita registrar al usuario, y
enviarle un correo electrónico con el fin de verificar la autenticidad
del usuario.
 Debe permitir el inicio de sesión del usuario.
 Debe permitir guardar las llaves enviadas por el usuario y que
éste las pueda recuperar.
 Debe permitir que el usuario suba datos de factura y que éste los
pueda recuperar.
 Debe permitir que el usuario suba al servidor el almacén de llaves
donde el usuario guarda las llaves y contraseñas.

3.2.1 Alta de usuario en el sistema

La Ilustración 4 describe el proceso de alta de un usuario en el sistema:

Ilustración 4 Proceso de alta de un usuario en el sistema

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

11
Para poder utilizar la aplicación el usuario debe registrarse en el servicio.
El usuario debe facilitar un correo electrónico que servirá como usuario de
la aplicación y una contraseña. La contraseña debe tener las siguientes
condiciones:

 como mínimo 12 caracteres,

 al menos una letra minúscula,
 al menos una letra mayúscula,
 al menos un número,
 al menos un carácter especial.

Estos datos se envían de manera segura mediante una conexión https al

servidor que verifica que el usuario no está dado de alta en el sistema. Si
el correo electrónico ya está dado de alta en el sistema, se envía un
mensaje de error a la aplicación móvil indicando esta situación. Si el correo
electrónico no está utilizado, el servidor guarda al usuario y la contraseña
encriptada y se devuelve a la aplicación un mensaje indicando que la
operación ha sido satisfactoria.

En el momento en que el usuario queda correctamente registrado en el

sistema el servidor envía un mensaje a la cuenta de correo del usuario
con un código de activación. Este código tiene una vida útil de 60 minutos.

Se ha decidido este tiempo para que el usuario pueda acceder a un cliente

de correo y seleccionar el enlace que se le proporciona, en el caso de que
no lo tenga disponible en el dispositivo donde tiene instalada la aplicación.
Es un tiempo lo suficientemente largo para que el usuario disponga de
tiempo para realizar esta operación. Este tiempo de validez del correo de
verificación es necesario, ya que se podría dar el caso de que un usuario
malintencionado registre un correo electrónico válido, y nunca lo verifique,
de manera que el correo del usuario legítimo quedaría bloqueado.

Una vez que el usuario ha seleccionado el enlace se valida el código y se

habilita al usuario que ya puede utilizar la aplicación.

Nota: La contraseña que se pide es de 12 caracteres. La formula para

calcular su entropía, es decir su fortaleza es la siguiente:

H = (L* log N) / log2,

Donde L es la longitud de la contraseña, y N es el número de símbolos

diferentes que se pueden poner. En el caso mostrado los símbolos pueden
ser mayúsculas (27, ABCDEFGHIJKLMNÑOPQRSTUVWXYZ),
minúsculas (27, abcdefghijklmnñopqrstuvwxyz), números (10) y símbolos
del teclado (22, abcdefghijklmnñopqrstuvwxyz, !@#$%&/()=?¿[]{},;.:-_)

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

12
 Por lo tanto, N = 86 y L = 12, y el número de bits de entropía es de 77,11.

3.2.2 Inicio de sesión

Para poder utilizar la aplicación móvil se debe iniciar la sesión en el

servidor. En la Ilustración 5 se describe la funcionalidad.

Ilustración 5 Diagrama de secuencia de inicio de sesión

La aplicación móvil envía al servidor un formulario de inicio de sesión con

el usuario y contraseña. La primera vez que el usuario inicia sesión la
aplicación crea un par de claves pública y privada que se guarda en el
almacén de llaves de la aplicación. Con ellas se genera un CSR
(Certificate Signing Request), es decir una solicitud de firma de certificado
y se envía mediante una conexión https al servidor. Este recibe el CSR y
genera un certificado que envía de manera segura a la aplicación móvil y
a la vez se vincula al usuario que lo ha solicitado. La aplicación móvil
guarda el certificado recibido en el almacén de llaves de la aplicación.

La aplicación genera una serie de claves simétricas para poder encriptar

un conjunto de campos que permitirán al usuario identificar la factura y se
guardarán en el servidor de manera segura, encriptados con la clave
pública del usuario, de manera que se necesitará la clave privada para
desencriptarlos. Estas claves simétricas se desen el almacén de llaves de
la aplicación. Se genera una clave diferente para cada campo que se
guarda en el servidor.

Ahora el usuario ya puede utilizar la aplicación.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

13
3.2.3 Facturación de facturas y copia de seguridad en la nube

La aplicación recibe por NFC o Bluetooth las facturas en formato Facturae.

Este proceso está fuera del alcance del TFM. Las facturas en este formato
se encuentran en la tarjeta SD del dispositivo.

Hay una opción que permite ver cuáles son los ficheros que hay en el
dispositivo. Los ficheros pueden haber sido procesados, es decir, validada
su firma e incorporada la factura a la base de datos local, o bien
pendientes de procesar. Se distinguen ambos casos de manera visual.

Para los ficheros que están pendientes de tratar se puede iniciar un

proceso en que se valida la firma del fichero y en caso de que la firma sea
válida se guardan los datos de la factura en una base de datos local, y por
otra parte se hace una copia de los mismos en el servidor en el caso de
que éste esté activo. Los datos que se guardan en local están en claro, de
manera que se pueden hacer consultas diversas, mientras que los datos
que se guardan en el servidor están encriptadas con una serie de claves
simétricas que se han obtenido en el punto anterior.

3.2.4 Descarga de factura de la nube

Se pueden visualizar los datos de las facturas que están en el servidor.

Los datos están encriptadas por lo que deben descargarse,
desencriptarse con las claves simétricas utilizadas para encriptarlos, y
mostrarlos al usuario.

El usuario tiene la posibilidad de descargárselas en el caso de que la

factura que está en la nube no esté en la base de datos local.

Esta factura descargada se puede incorporar a la base de datos local de

facturas.

3.2.5 Consultas de gastos

Los datos de las facturas que se desen la base de datos local son los
mínimos imprescindibles para poder hacer consultas de gastos y
proveedores. Se desa el CIF y el nombre del proveedor, el número de
factura, la fecha de la misma, y el importe total, los impuestos y la base
imponible. Estos datos nos permitirán tener estadísticas agrupadas por
estos campos.

3.2.6 Copia de seguridad del almacén de datos

Se facilita una opción que permite al usuario hacer una copia de seguridad
del almacén de llaves encriptada, y los datos de cifrado y la URL para
poder recuperarlos se guardan en un código QR [20].

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

14
 Esta opción debe permitir que un usuario guarde de manera segura el
almacén de llaves de la aplicación en el servidor, de manera que lo pueda
recuperar en caso de pérdida de la contraseña, o bien de la pérdida del
dispositivo.

El almacén de llaves de la aplicación es un fichero donde desen las claves

pública y privada del usuario, así como las claves simétricas de cifrado de
los campos identificadores de la factura que se desenvuelven en el
servidor.

3.3 Justificació d’una infraestructura de clau pública

De lo que se trata es de que las facturas que el usuario tiene en su

dispositivo móvil puedan estar guardadas en un servidor externo de
manera que el usuario pueda recuperarlas en caso de que pierda el
dispositivo o pierda los datos que en él se encuentran.

Además se necesita que los datos estén encriptadas de manera que el

operador del servidor no pueda desencriptar estos datos o le sea
especialmente costoso.

Por eso lo que se decide es que todas las operaciones de cifrado y

descifrado se hagan en el móvil con la idea de que el operador del servidor
no tenga al alcance las claves de cifrado y por lo tanto no pueda saber
qué es lo que está guardando.

Hay que notar que si en algún momento el operador del servidor tuviera
acceso a las claves podría hacer tanto el descifrado para poder hacer
estadísticas de los datos del usuario. Como contrapartida un usuario
malintencionado del operador del servidor o el propio operador dispondría
de toda la información de consumo que el usuario hubiera puesto en el
servidor por lo que podría sacar provecho económico de estos datos y
podría vulnerar la privacidad del usuario.

La solución que se ha escogido para satisfacer las necesidades expuestas

es utilizar una infraestructura de clave pública de manera que los datos
que se suben al servidor se encriptan con la clave pública del usuario de
tal manera que sólo se pueden desencriptar con la clave privada del
usuario que no sale de su móvil.

3.4 Justificación de un cifrado simétrico

El problema que nos encontramos es que queremos encriptar facturas que

tienen el formato Facturae y son por lo tanto fichero XML de una longitud
considerable. Con el sistema de cifrado RSA que queremos utilizar
podemos encriptar un fichero siempre que el tamaño del mismo sea 11
Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-
SenseObraDerivada 3.0 Espanya de Creative Commons

15
bits menos que la longitud de

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

16
la clave. Es decir que si tenemos una clave de 2048 bits, la longitud del
fichero debe ser de como mucho 2037 bits, es decir, 254 bytes. Eso nos
es totalmente insuficiente.

La solución que se propone es hacer un cifrado simétrico del fichero con

una clave aleatoria y posteriormente encriptar con la clave pública la clave
simétrica.

El objetivo a alcanzar es poder enviar o guardar de manera segura

grandes ficheros.

Esta técnica se llama sobre digital o en inglés, "digital envelope".

Esta técnica es la que se ha usado para desartijar los datos de manera

segura en el servidor. Primero se ha creado una estructura para desartijar
una serie de datos de factura que permitirán al usuario identificar una
factura que se desará al servidor.

Lo que hará la aplicación con una factura que se quiera procesar es

verificar que la firma sea válida. No se hacen más validaciones ya que ha
habido otros trabajos que han hecho este proceso y no aportaría nada
nuevo con este trabajo. Si esta firma es válida presuponemos que la
factura lo es.

Una vez validada se elimina la firma del fichero y se hace un "casting" a

una estructura Facturae. Con esta podemos extraer de una manera
sencilla los datos más relevantes de la factura: el emisor, el importe, los
impuestos, el concepto, etc...

Estos datos se encriptan de manera simétrica con las diversas claves

aleatorias que se generan la primera vez que el usuario inicia sesión en la
aplicación. Las claves se desen el almacén de llaves de la aplicación. Este
es un fichero que se encuentra dentro de los ficheros de la aplicación,
concretamente dentro del directorio de la aplicación y de manera que sólo
el grupo del usuario de y el usuario de la aplicación tiene derechos de
lectura y escritura. Un usuario o bien una aplicación que no sea ésta no
puede acceder a su contenido, que además está protegido por
contraseña. Por lo tanto, disponemos de un almacén seguro donde desar
las claves de cifrado. Por seguridad también se envían al servidor,
encriptadas con la clave pública.

Con ello conseguimos poder descargarnos del servidor un registro con los
datos de factura que una vez desencriptadas en el dispositivo móvil
permiten al usuario identificar la factura y descargársela en caso de que
haya perdido los datos en el dispositivo.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

17
4. Desarrollo de la solución
En este capítulo se explica el desarrollo de la aplicación del servidor,
explorando cada uno de los paquetes en que se organiza y las clases, con
las funciones más relevantes de cada una de ellas. Posteriormente se
explica el desarrollo de la aplicación móvil, detallando algunas de las
funciones más importantes desde el punto de vista de la seguridad.

4.1 Diagrama de components del servidor

En la Il·lustració 6 es mostra el diagrama de components del servidor:

Il·lustració 6 Diagrama de components del servidor

Descripción de los módulos que componen el servidor:

Nombre del Descripción

Módulo
config El objetivo del módulo es hacer la configuración de la
aplicación de servidor. Incluye las constantes que se
utilizarán en los otros módulos, la clase para la autenticación
de usuarios, el tipo de codificación de la contraseña de los
usuarios, y la
configuración de base de datos.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

18
 controllers Es el módulo que contiene las clases que proveen los puntos
de entrada a la aplicación. Hay puntos de entrada que están
securizados y que solo pueden ser accedidos en el caso en
que el usuario esté autenticado y disponga de los permisos
correspondientes.
util Es el módulo que contiene clases que permiten generar un
código (token) para la verificación por correo electrónico del
usuario, y la generación de un certificado a petición del
usuario.
También contiene la clase que permite hacer la
autenticación del usuario en el sistema
modelo Contiene los datos de las entidades que se persistirán, es
decir que se guardarán en una base de datos.
repos Contienen las clases que implementan los interfases de
acceso a datos. En Spring solo hay que extender un
determinado interface para implementar todos los métodos
de acceso a datos. No es necesario que el desarrollador
implemente
métodos.
vo Son clases de utilidad para pasar datos entre clases
dentro de la aplicación.
mail Clase para gestionar el envío de correos electrónicos a
el usuario
Tabla 3 Módulos que componen el servidor

4.2 Diagrama de clases del servidor

En la Ilustración 7 se muestran las clases que implementan la aplicación

del servidor y la relación entre ellas.

A continuación se hace una descripción de cada una de ellas.

La clase principal que arranca el servidor es RestServerApplication.

Como se indicaba en el punto 2.1.1 Spring es un sistema que funciona por
configuración, y en esta clase se configura un objeto, en terminología
Spring un bean, que gestiona el envío de correos electrónicos, ya que se
necesita según el requisito ReqSer-03. Spring se encarga de la creación,
inicialización y gestión de cada objeto. Es el concepto denominado
Inversión de Control [15].

La aplicación se encarga de leer un fichero application.properties que está

en la raíz de la aplicación del servidor y que contiene una serie de
parámetros preestablecidos y otros modificables que indican en el
framework Spring cómo debe iniciar la seguridad, cómo debe conectarse
a la base de datos y cómo debe gestionar los ficheros que se tengan que
subir al servidor, en el caso de que hubiera.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

19
 Il·lustració 7 Diagrama de classes del servidor

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

20
 Ilustración 8 Detalle de las clases del módulo config

En la Ilustración 8 se muestra el detalle de las clases que se incluyen en

el módulo config. La clase Constantes contiene valores que se utilizan en
diversas clases. FileStorageProperties permite configurar dónde se
desarán los ficheros que se suban al servidor. La clase BasicConfiguration
establece cuál será el encriptador de las contraseñas que se utilicen en la
mesa de usuarios. Es importante remarcar que como norma de seguridad
las contraseñas que se guardan deben estar codificadas. En este caso se
utiliza como codificador la clase del framework
org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder.

El método configureGlobal es el más significativo de esta clase ya que en

él se configuran los puntos de acceso así como los roles que deben tener
los usuarios para poder acceder.

Este punto es crucial, ya que el foco de este trabajo está en la seguridad

del servidor que es allí donde se desenvuelven las facturas encriptadas
del usuario. Los usuarios pueden acceder a diferentes puntos de entrada,
que se traducen en URLs, en función de si están o no autenticados, y del
rol que tienen. Por defecto un usuario cuando se registra en la aplicación
se le asigna directamente el rol de usuario ("USER").

Los puntos de entrada que se definen son:

 /status, es el punto de entrada que puede acceder cualquier usuario

esté o no autenticado y que permite saber si el servidor está activo
o no,
 /signup, es el punto de entrada que puede acceder cualquier
usuario esté o no autenticado y que permite al usuario registrarse
en el sistema, según se explica en el punto 3.2.1

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

21
  /token, es el punto de entrada que puede acceder cualquier usuario
esté o no autenticado y que permite al usuario habilitar al usuario
una vez seleccione el enlace que se le envía al usuario para
verificar su correo electrónico, según lo explicado en el punto 3.2.1
 /login, es el punto de entrada para usuarios. Se debe informar del
usuario (correo electrónico) y la contraseña.
 /keys, es el punto de entrada para guardar las claves simétricas
encriptadas con la clave pública del usuario, de manera que se
guardan en el servidor y únicamente el usuario con su clave privada
las puede desencriptar.
 /facturas, es el punto de entrada para desar los datos de facturas
encriptadas con las claves simétricas. Permite desartar las facturas
y recuperarlas.
 /ksb, es el punto de entrada para poder desar el fichero de
almacenamiento de llaves del móvil que contiene tanto la clave
pública como la privada y que servirá para poder recuperar las
llaves en el caso de que el usuario pierda la contraseña o bien
pierda el móvil con el almacén de llaves

Ilustración 9 Diagrama de clases del módulo controllers

En la Ilustración 9 se muestra el diagrama de clases del módulo

controllers. Este contiene las clases que dan servicio a los puntos de
entrada que se han descrito en los párrafos anteriores.

Cada punto de entrada se puede acceder con diferentes métodos HTTP.

Por ejemplo, en el punto de entrada /facturas se puede acceder con un
método GET para poder recuperar una factura o varias, y se puede
acceder con el método de entrada POST con el fin de añadir una factura
a las que guarda el servidor.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

22
 En estas clases se definen los métodos que dan servicio a estas
operaciones en los puntos de entrada.

Por ejemplo, según se puede ver en la Ilustración 9 en la clase

FacturaResource hay un método retrieveAllFacturas. Este método
tiene como anotación:

@RequestMapping(value="/facturas", method = RequestMethod.GET)

public ResponseEntity<List<Invoice>> retrieveAllFacturas(
@AuthenticationPrincipal CustomUser user) {

Esta anotación indica a Spring que configure que este método será el que
se debe ejecutar cuando la aplicación reciba una petición GET en la URL
https://nombredelservidor:port/facturas, donde nomdelservidor es la IP o
el nombre de dominio del servidor y puerto es el número de puerto donde
escucha la aplicación.

La resta de classes funciona de manera similar:

 ServerStatusResource, da servicio a las peticiones en el punto de

entrada /status, y sólo acepta peticiones de tipo GET,
 SignUpResource, da servicio a las peticiones en el punto de entrada
/signup, y sólo acepta peticiones de tipo POST, que vengan con
un objeto de tipo JSON con un campos determinados.
 TokenResource, da servicio a las peticiones en el punto de entrada
/token, y sólo acepta peticiones de tipo GET,
 LoginResource, da servicio a las peticiones en el punto de entrada
/login, y sólo acepta peticiones de tipo POST. El usuario debe estar
autenticado para poder acceder. Si no lo está el servidor rechaza
la conexión.
 SymmetricKeysResource, da servicio a las peticiones en el punto
de entrada /keys, y acepta peticiones POST y GET, para añadir y
recuperar respectivamente las claves simétricas del usuario. El
usuario debe estar autenticado para poder acceder. Si no lo está
el servidor rechaza la conexión.
 FacturaResource, da servicio a las peticiones en el punto de entrada
/facturas, y acepta peticiones POST y GET, para añadir y
recuperar respectivamente las facturas del usuario. El usuario
debe estar autenticado para poder acceder. Si no lo está el
servidor rechaza la conexión.
 KeyStoreBackUpResource, da servicio a las peticiones en el punto
de entrada /ksb, y acepta peticiones POST y GET, para añadir y
recuperar respectivamente el almacén de llaves del usuario. El
usuario debe estar autenticado para poder acceder. Si no lo está
el servidor rechaza la conexión.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

23
 Ilustración 10 Diagrama de clases del módulo modelo

En el módulo modelo se encuentran las clases de todas las entidades que

intervienen en el modelo de negocio y que se persistirán en la base de
datos. La clase central es la clase Usuario, ya que para que el sistema
pueda ser multiusuario las entidades que se desenvuelve deben estar
relacionadas con su propietario, que será el usuario.

Ilustración 11 Diagrama de clases del módulo repos

En este módulo no hay clases sino que hay interfaces. El motivo es que
como se ha explicado Spring funciona por configuración, y para poder
generar las conexiones a las tablas, se deben crear los interfaces para
que Spring implemente las clases a partir de estos. Se deben definir los
métodos especiales que no estén definidos por el interface JPARepository
que es el interface que deben extender.

Cada uno de los repositorios que se definen en una de las clases del
modelo.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

24
 Ilustración 12 Diagrama de clases del módulo util

El módulo util lo integran tres clases que dan servicio a otras clases.

 UsuarioUserDetailsService, permite localizar al usuario en la tabla,

cargar los roles que tiene asignados y validar si está o no habilitado.
Utiliza la infraestructura de seguridad de Spring implementando
uno de los interfaces (UserDetailsService) que provee el
framework.
 CreateCSR, provee de un método estático para generar un
certificado a partir de una petición CSR que llega por parte del
usuario en el momento de hacer el inicio de sesión, según se
explica en el punto 3.2.2

Ilustración 13 Diagrama de clases del módulo vo

El último de los módulos contiene las clases que sirven para pasar
información a la aplicación. Tal y como se ha explicado anteriormente en
los puntos de entrada a la aplicación se pueden utilizar dos métodos: GET
y POST. El método GET se utiliza para pedir información al servidor,
dejándolo en el mismo estado que se encontraba. El método POST [16]
se define como aquel que puede añadir información a la que ya hay en el
servidor. Por eso el llamamiento al método POST debe venir con una
estructura de datos. Esta estructura debe estar prevista por el método que
le da servicio. En la implementación se ha hecho que la información venga
en formato JSON (JavaScript Object Notation) [17], ya que es una
estructura ligera,
Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-
SenseObraDerivada 3.0 Espanya de Creative Commons

25
 fácilmente implementable en varias plataformas y que Spring entiende de
manera nativa. Simplemente se trata de definir la clase con los campos
que se espera recibir, y ponerla como parámetro en la definición del
método que da servicio. Por ejemplo, en el caso del método que permite
subir una factura encriptada al servidor, la firma del método es:

@RequestMapping(value = "/facturas", method = RequestMethod.POST)

public ResponseEntity<?> postFactura(
@AuthenticationPrincipal CustomUser user,
@RequestBody UploadObject factura) {

Como se observa hay dos parámetros que recibe el método:

 Customer user, con la anotación @AuthenticationPrincipal que
indica que sólo accederá a este método si el usuario ha sido
previamente autenticado con usuario y contraseña en el momento
de hacer la petición POST,
 UploadObject factura, con la anotación @RequestBody, que indica
que el método espera recibir en el BODY del POST un objeto con
la estructura de campos definido en la clase UploadObject.

4.3 Creació d’una infraestructura de clau pública

El objetivo es simular una estructura real de clave pública para ver cómo
funcionaría en un entorno real.

En un entorno de producción el servidor dispondría de una pareja de

claves pública/privada con un certificado emitido por una entidad
certificadora. Por ejemplo, como ciudadanos del estado español podemos
disponer de un certificado digital que lo emite la Fabrica Nacional de
Moneda y Timbre (FNMT). Para ello el proceso es generar un par de
claves, se envía la clave pública en un CSR (Certificate Signing Request)
a la FNMT, y ésta genera un certificado. Una vez verificada nuestra
identidad la primera vez de manera presencial nos podemos descargar
mediante un código el certificado digital que nos permitirá hacer una serie
de operaciones criptográficas. Este certificado se desa en un fichero de
tipo PKCS12 que permite guardar de manera segura la clave privada y el
certificado. Con ellas podemos acceder a una serie de servicios como por
ejemplo la presentación de la declaración de Hacienda, etc...

En el entorno de desarrollo lo que se hace es crear un par de claves y con

ellas un certificado autosignado. Este certificado lo utilizaremos como CA
(Certification Authority o autoridad de certificación).

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

26
 Una vez tenemos este certificado, para cada usuario de la aplicación
creamos un par de claves pública y privada y generamos un CSR que lo
firmará la CA, y generará un certificado. Este incluirá la clave pública del
usuario.

En principio se necesita uno para el servidor, y uno para cada usuario.

En el servidor se necesitan los certificados del servidor y de la CA. La

justificación es que cada usuario de la aplicación móvil creará su pareja
de claves pública y privada y enviará in CSR al servidor para que éste
genere un certificado y lo envíe al usuario. El certificado estará firmado
por la CA.

4.4 Creación de las tablas en la base de datos del servidor

Mediante un fichero de guión (script) se crea tanto la base de datos en el

servidor MySQL como las tablas y las relaciones entre ellas que permitirán
disponer de un entorno multiusuario, y permitirán que se guarden de
manera segura, encriptada, los datos básicos que permiten identificar una
factura, así como las claves que permiten desencriptarlas debidamente
encriptadas con un sistema de clave pública-privada.

Las tablas que aquí se describen corresponden a las clases del módulo
"modelo" que se ha descrito anteriormente.

La tabla tbl_usuari tiene una relación 1:N con el resto de mesas ya que
cada una de las entidades que se quieren persistir tienen una relación con
el usuario que las crea y/o pide. Esto permite crear un sistema
multiusuario.

Las tablas que guardan los datos de las facturas sólo tienen campos de
tipo cadena y no de tipo numérico o de fecha como se podría esperar. La
razón es que la información que se le envía al servidor está encriptada y
el resultado del cifrado se codifica en Base64 [18] que es una cadena de
caracteres alfanuméricos y que requiere de un campo de tipo cadena para
poder guardarse.

Aquesta obra està subjecta a una llicència de Reconeixement-NoComercial-

SenseObraDerivada 3.0 Espanya de Creative Commons

27