PFC Javier Hernandez Fisac 2015

UNIVERSIDAD CARLOS III DE MADRID
ESCUELA POLITÉCNICA SUPERIOR
INGENIERÍA TÉCNICA DE TELECOMUNICACIÓN

ESPECIALIDAD: TELEMÁTICA
PROYECTO FINAL DE CARRERA
VERIFICADOR MÓVIL DE
DOCUMENTOS DE TRÁNSITO
AUTOR: Javier Hernández Fisac

TUTOR: Juan Manuel Estévez Tapiador
26 de junio de 2015
Título: VERIFICADOR MÓVIL DE DOCUMENTOS DE TRÁNSITO.
Autor: Javier Hernández Fisac
Tutor: Juan Manuel Estévez Tapiador
La defensa del presente Proyecto Fin de Carrera se realizó el día 26 de junio de 2015 siendo
calificada por el siguiente tribunal:
Presidente: Andrés Marín López
Secretario: Pedro Peris López
Vocal: Sergio Pastrana Portillo
Habiendo obtenido la siguiente calificación:
Calificación:
Presidente Secretario Vocal
3
Agradecimientos
A mis padres, Jose y Rosa. La paciencia, más que la del Santo Job, acaba teniendo recompensa.
A Inés y Ricardo, por vuestro apoyo y comprensión en todo momento. A Guille y Marcos, pequeños
pero matones.
A Ascensio, David, Fernando y Pablo por su ayuda y su inestimable (e inabarcable) cono-
cimiento. A Jorge y Ángel, por su predisposición y sus ganas de aprender; sin su ayuda este
proyecto habría sido mucho más complicado.
A Álvaro, Antonio, Celia, Dani, Dante, David, Fernando, Igeño, Jordi, Juan Carlos, Lorena y
Miguel Ángel por acompañarme en estos años de crecimiento personal y laboral.
A los viejos charlies, el tiempo pasa, la huella queda.
A la pipol de la UC3M: Alex y Manme, Almu, Anita, Bari, Barroso, Charlie, Chema, Cris,
Demi, Gabo y Merche, Irene, Jorge, Laura, Lo, Luly, Manu, Majo, Miguel, Mora, Pepe, Repi,
Rober y Nuria, Stanley Wilson, Tania, Toco, Xergio y todos los demás. Tantas horas de estudio
y muchas más de cafetería.
A los indriles y exindriles: Amaia y Karim, Deivit, Diego GG, Ibone, Jordi y Diana, Johana,
Juanfran, Luis, Mariano, Oria, Rubs, Secre, Soto, Txomin, Yago, Yisas. Buenos ratos, que sean
por muchos años.
A los supervivientes del Curso de Noviembre, contrarios y añadidos: Carlos y Lourdes, David
y Maribel, Vero y Ferrán, Cerrato e Irene, Bea. Más de siete años y aún como el primer día.
A los segovianitas: Clara, Laura, Miguel y Javi, Pitu. Volver a casa es más fácil con vosotros.
A los Cenadores del Mundo: Diana, Irene, Luis, Adrián, Manuela, Vicente. Seguiremos
desafiando a la báscula de punta a punta del planeta Madrid.
Al much-more-than-six-pack y toda su prole: Javi, Rocío, Juli, Marina, Maite, Juan y llegados
o por venir que llenarán nuestros corazones (y pagarán nuestras pensiones).
A los weGroos: Debe, Diego y Juli. Mucho más que compañeros, más que amigos, ya sois
familia.
A mis hermanos y sus consortes: David e Inma, Jaime y María, Vicente y Maitane. Sobran
las palabras.
A toda mi familia, los que están y los que se fueron, por su apoyo y cariño incondicionales.
A todos los que no están sobre estas líneas pero sí en mis pensamientos, por acompañarme
en tantos buenos y malos momentos.
5
A Elena, mi razón de ser
A Marta, la otra mitad de mi paso
Lo que sabemos es una gota de agua; lo que ignoramos es el océano.

Sir Isaac Newton
Vale más saber alguna cosa de todo, que saberlo todo de una sola cosa.
Blaise Pascal
7
Resumen
Se implementará una solución móvil que permita a un usuario autorizado, típicamente de

los Cuerpos y Fuerzas de Seguridad del Estado, realizar una consulta y verificación de los
datos personales y de seguridad del titular de un Machine Readable Travel Document (MRTD),
normalmente un pasaporte electrónico, o de un Documento Nacional de Identidad electrónico
(DNIe).
La aplicación verificará la autenticidad e integridad del documento y accederá a los datos
personales, fotografía y huella del usuario. Además permitirá la realización de una fotografía (a
través de la cámara del dispositivo) y la obtención de una huella dactilar (a través de un lector
de huellas externo) para el cotejo biométrico con los datos del documento.
Adicionalmente, se podrán consultar datos de antecedentes penales del titular del documento
en los sistemas de los Cuerpos y Fuerzas de Seguridad del Estado.
En el proceso de lectura y verificación de documentos, intervendrán las siguientes tecnologías:
Optical Character Recognition (OCR): Para la lectura de los datos MRZ del docu-
mento a partir de una imagen preprocesada obtenida a través de la cámara del dispositivo.
Near Field Communication (NFC): Para el acceso de lectura de los elementos internos
del chip RFID del pasaporte electrónico.
Integrated Circuit Card (ICC): Para el acceso de lectura de los elementos internos del
DNIe.
Bluetooth/USB: Lectura de huellas dactilares a través de dispositivos con interfaz

Bluetooth con autenticación DSA y/o USB.
9
Biometría: Cotejo de huella dactilar e imágenes faciales.
Derivación y utilización de claves simétricas para el Control de Acceso Básico al pasaporte

(BAC) y cifrado de canal de comunicación.
Uso de firma y verificación electrónica de certificados X.509 para la Autenticación Pasiva

(PA) de documentos mediante certificados de Country Signing Certification Authority
(CSCA).
Verificación de CRL y cadenas de certificación PKIX de los certificados CSCA.
Intercambio de claves Diffie-Hellman, criptografía asimétrica mediante algoritmos de Crip-

tografía de Curva Elíptica, utilización de certificados X.509 versión 3 y Card Verifiable
Extended Access Control (CVEAC), incluyendo firmas.
Uso de Transport Layer Security (TLS) a través de HTTPS con autenticación de cliente
para la conexión con servicios externos.
En este proyecto se diseña una solución a modo de aplicación móvil para plataformas Android
implementada utilizando el lenguaje Java y empleando Maven para la gestión de dependencias
y librerías, así como para la generación de entregables y empaquetamiento. Se emplean en el
desarrollo múltiples librerías de código libre (jMRTD, tess-two, KSoap2-android, Spongy Castle,
etcétera) que permiten realizar las verificaciones lógicas de los documentos MRTD, efectuar
verificaciones biométricas y cotejar los datos del titular del documento con bases de datos
policiales para comprobar posibles antecedentes o incidencias con el documento.
Además se evalúa el código con herramientas de calidad de código (PMD, Checkstyle) y se
implementan pruebas unitarias con JUnit comprobando su alcance con Cobertura.
10
Índice general
1. Introducción 19
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2. Preliminares 23
2.1. Machine Readable Travel Document (MRTD) . . . . . . . . . . . . . . . . . . . . 23
2.1.1. Estructura lógica de los datos (LDS) . . . . . . . . . . . . . . . . . . . . . 23
2.1.2. Esquema de Data Groups definidos para LDS . . . . . . . . . . . . . . . . 24
2.1.3. Mecanismos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2. Documento Nacional de Identidad electrónico (DNIe) . . . . . . . . . . . . . . . . 31
2.2.1. Estructura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2. Mecanismo de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3. Sistemas externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4. Elementos biométricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1. Biometría facial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.2. Biometría dactilar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5. Plataforma móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.1. Arquitectura del sistema Android . . . . . . . . . . . . . . . . . . . . . . . 38
2.6. Aplicaciones existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3. Diseño del sistema 41
11
3.1. Componentes Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1. Smartphone Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2. Lector de huellas Bluefin . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. Componentes Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1. Utilidades comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2. API de inspección de documentos (InspectionService) . . . . . . . . . . . 45
3.2.3. API de consulta de documentos (DSQService) . . . . . . . . . . . . . . . . 47
3.2.4. API de antecedentes policiales (CRService) . . . . . . . . . . . . . . . . . 48
3.2.5. API de captura dactilar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.6. Módulo Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4. Implementación y pruebas 55
4.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2. Librerías de terceros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3. Implementación final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.1. Selección de modo de lectura . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.2. Verificación lógica, acceso y verificación policial . . . . . . . . . . . . . . . 59
4.3.3. Biometría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4. Calidad de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4.1. PMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.2. Reglas de Checkstyle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5. Pruebas y tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5. Presupuesto del proyecto 67

5.1. Costes de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2. Costes de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3. Costes de equipamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4. Costes en bienes fungibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.5. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.6. Costes totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12
6. Conclusiones 75
6.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Acrónimos 77
Glosario 83
Bibliografía 101
Apéndices 111
A. Reglas PMD 113

A.1. Reglas comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.2. Reglas específicas para Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B. Reglas de Checkstyle 129

B.1. Reglas comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
C. Informes de Junit 133

C.0.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
C.0.2. Lista de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
C.0.3. Casos de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
D. Informes de Cobertura 141

D.1. Todos los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
D.1.1. Informes por paquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
13
14
Lista de Figuras
2.1. Símbolo visible en pasaportes biométricos MRTD . . . . . . . . . . . . . . . . . . 23

2.2. Estructura de datos de un MRTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3. Ejemplo de jerarquía CSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4. Esquema de jerarquía CVCA de un MRTD . . . . . . . . . . . . . . . . . . . . . 30
2.5. Aspecto esquemático de un DNIe . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6. Precios de dispositivos según SO . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7. Dispositivos Android más usados . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.8. Porcentaje de prioridad de elección de plataforma por criterios de selección . . . 38
3.1. Esquema general de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2. Diagrama de flujo de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3. Diagrama de clases de API de inspección de documentos InspectionService . . . 45
3.4. Diagrama de clases de API de consulta de documentos DSQService . . . . . . . . 48
3.5. Diagrama de clases de API de registro policial ICRService . . . . . . . . . . . . . 49
3.6. Diagrama de clases de API de captura dactilar FingerprintReader . . . . . . . . 50
4.1. Selección de modo de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2. Intento de captura de MRZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3. Captura de MRZ correcta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4. Proceso de verificación de MRTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5. Resultado de verificación de MRTD . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6. Representación de datos de MRTD . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7. Resultado con señalamiento policial . . . . . . . . . . . . . . . . . . . . . . . . . . 61
15
4.8. Resultado de verificación del DNIe . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.9. Representación de datos del DNIe . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10. Intento de captura facial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11. Captura facial satisfactoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.12. Selección de lector de huellas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.13. Solicitud de huella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.14. Recuperación de huella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.15. Verificación biométrica en pantalla de estado . . . . . . . . . . . . . . . . . . . . 63
4.16. Verificación biométrica en pantalla de datos . . . . . . . . . . . . . . . . . . . . . 63
4.17. Pantalla de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
16
Lista de Tablas
2.1. Mecanismos de seguridad en MRTDs . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2. Implantación de SO en Smartphones en España . . . . . . . . . . . . . . . . . . . 36
5.1. Fases del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2. Cotizaciones 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3. Tipos de cotización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4. Costes de formación profesional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5. Bases de cotización al desempleo . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6. Coste de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.7. Costes de licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.8. Costes de equipamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.9. Costes en bienes fungibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.10. Cálculos de precio por hora de costes indirectos . . . . . . . . . . . . . . . . . . . 72
5.11. Presupuesto indirecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.12. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
17
18
Capı́tulo 1
Introducción
1.1. Motivación
En la actualidad surge cada vez más la necesidad de proporcionar mecanismos electrónicos

seguros, fiables y portables, a la par que rápidos y cómodos para casi cualquiera de las tareas
que se realizaban hasta hace muy poco de manera manual.
En este sentido, y en el ámbito del tránsito de personas a nivel doméstico o entre diferentes
países, surge la necesidad de automatizar los procesos de verificación de documentos y el paso
de fronteras, con el objetivo de facilitar y acelerar el trámite a los viajeros, reducir personal y
eliminar posibles errores humanos. Sobra decir que en este ámbito el valor de la seguridad es
crucial.
Desde hace varios años (1998), la mayoría de países del mundo, entre ellos casi todos los
europeos, han realizado un esfuerzo por mejorar sus pasaportes y otros documentos de viaje
para dotarlos de elementos electrónicos de verificación e identificación biométrica de sus titulares,
surgiendo de este trabajo los estándares de la International Civil Aviation Organization (ICAO)
que definen los documentos electrónicos de tránsito (MRTD) [1–5].
En el proceso de verificación de un documento de tránsito, aparecen varios elementos intere-
santes a verificar:
Verificación física del documento, incluyendo aquellos mecanismos de seguridad (marcas de

agua, tintas infrarrojas o ultravioletas) que garantizan su autenticidad.
Verificación lógica del documento.
19
20 CAPÍTULO 1. INTRODUCCIÓN
Existen ya en la actualidad soluciones para realizar estos controles con equipos fijos situados
en puntos estratégicos de paso de fronteras, como los controles de los aeropuertos. Valga como
ejemplo de esto el ABC System que se ha implementado en gran parte de los aeropuertos españoles
de referencia [6].
Si bien es cierto que estos sistemas solucionan gran parte de la problemática descrita, surge
naturalmente la necesidad de disponer de sistemas análogos que sean portables y se puedan utilizar
con un nivel de fiabilidad similar en lugares en los que no estuviera disponible la infraestructura
propia de un aeropuerto, de manera que su uso se pueda extender a casi cualquier lugar.
1.2. Objetivos del proyecto
El objetivo de este proyecto es desarrollar una solución móvil que permita realizar las
verificaciones lógicas de los documentos MRTD que cumplen el estándar de ICAO, además de
verificaciones biométricas tanto facial como dactilar, así como cotejar los datos del titular del
documento con bases de datos policiales para comprobar posibles antecedentes o incidencias con
el documento.
Adicionalmente se persigue la implementación de mecanismos similares para el DNIe del
estado español en sus versiones con chip por contactos (ICC).
1.3. Estructura del documento
A continuación se describen de forma resumida los diferentes capítulos de esta memoria para
facilitar su lectura y comprensión proporcionando una visión de conjunto.
Capítulo 1, Introducción: En este capítulo se describe el proyecto de forma general,

introduciendo la problemática y planteando la motivación que da lugar a él. Así mismo, se
describen los objetivos del proyecto y se proporciona un resumen general de la estructura
del documento.
Capítulo 2, Preliminares: En este capítulo se apuntan los conceptos, protocolos, están-

dares, y el resto de elementos relacionados con la solución realizada, así como las soluciones
tecnológicas elegidas y su motivación.
Capítulo 3, Diseño del sistema: Este capítulo aporta el diseño de alto nivel y la
1.3 Estructura del documento 21
arquitectura elegidas para el proyecto. Se explican las motivaciones para la elección de la

solución propuesta entre las distintas alternativas existentes.
Capítulo 4, Implementación y pruebas: Se presenta una descripción de los componen-

tes utilizados, las características del sistema resultante, aspectos de eficiencia y rendimiento,
elementos de calidad de código, pruebas, etcétera.
Capítulo 5, Presupuesto: Se trata de una sección en la que se detallan los costes totales
del proyecto, incluyendo materiales utilizados, horas de trabajo, etcétera.
Capítulo 6, Conclusiones y trabajo futuro: Sección en la que se extraen conclusiones

sobre el trabajo realizado y se proponen posibles puntos de mejora y trabajos futuros.
Acrónimos: Se muestran los acrónimos que aplican a esta memoria.
Glosario: Se muestra el glosario de términos que aplican a esta memoria.
Bibliografía: Se especifica la bibliografía utilizada en el desarrollo y documentación del

proyecto.
Apéndices: Se incluyen recursos utilizados para la evaluación de calidad de código e

informes de los procesos de pruebas.
22 CAPÍTULO 1. INTRODUCCIÓN
Capı́tulo 2
Preliminares
2.1. Machine Readable Travel Document (MRTD)
El verificador de documentos MRTD se basa principalmente en la parte 1 [1, 2] y la parte 3

[4, 5] del documento 9303 de la International Civil Aviation Organization (ICAO). Básicamente,
en ambos casos, el volumen 1 se corresponde con el acceso seguro a los pasaportes de primera
generación y el volumen 2 se corresponde con el acceso seguro a los pasaportes de segunda
generación, los cuales poseen datos de identificación biométrica como la huella y el iris.
Figura 2.1: Símbolo visible en pasaportes biométricos MRTD
En las siguientes secciones se expondrán los puntos más relevantes.
2.1.1. Estructura lógica de los datos (LDS)
Toda la información que posee el MRTD se almacena en una Estructura Lógica de Datos,
Logic Data Structure (LDS), definida por ICAO para que todos los países emisores dispongan de
los datos de la misma forma. Toda la información se encuentra organizada en grupos llamados
Data Groups (DGs) que agrupan la información relacionada. Cada uno de estos DGs se encuentra
almacenado en una serie de Ficheros Elementales, Elemental File (EF). Además existen un par
de EFs con funciones especiales. La disposición de los datos se muestra en la figura 2.2.
23
24 CAPÍTULO 2. PRELIMINARES
Figura 2.2: Estructura de datos de un MRTD [5]
2.1.2. Esquema de Data Groups definidos para LDS
Existen cuatro grupos que deben de incluirse en una LDS:
DG1 que contiene los datos registrados en la Zona de Lectura Mecánica, Machine Readable
Zone (MRZ).
DG2 que contiene al menos una imagen frontal del rostro del titular según se define en la
sección II del documento 9303, parte 3, Volumen 1 [4]. De forma opcional puede contener
imágenes secundarias como perfil izquierdo, perfil derecho, etcétera.
EF.COM que contiene información sobre el LDS, la versión, la lista de etiquetas, etcétera.
2.1 Machine Readable Travel Document (MRTD) 25
Aunque no figura en el esquema, se encuentra almacenado en un EF.
EF.SOD que contiene información sobre la integridad y autenticidad de los datos. Al igual
que EF.COM no aparece en el esquema anterior, pero se encuentra almacenado en un EF.
En la sección de medidas de seguridad se explicara con más detalle la función de éste.
El resto de los DGs desde el DG2 (incluido) en adelante son opcionales.
Para más información respecto a cómo se almacenan la información, las etiquetas que
se utilizan para identificar cada sección, la longitud de los campos, etcétera, se recomienda
encarecidamente leer la sección III del documento de ICAO 9303, parte 3, volumen 2 [5].
2.1.3. Mecanismos de seguridad
Aunque existen múltiples mecanismos de seguridad física presentes en los MRTDs como
pueden ser el uso de tinta ultravioleta, integración de la foto con los patrones del pasaporte,
Impresión Rainbow, patrones anti-escáner, etcétera, en esta sección nos vamos a centrar en los
mecanismos de seguridad lógica que se encuentran relacionados con el proyecto.
Los mecanismos de seguridad lógica que establece ICAO para los MRTDs se muestran en la
tabla 2.1.
Mecanismo Objetivo Técnica ICAO UE

BAC Confidencialidad Autenticación y Opcional Obligatorio
Canales Seguros
PA Autenticidad Firma digital Obligatorio Obligatorio
AA Originalidad Reto-Respuesta Opcional Opcional
EAC Confidencialidad Autenticación Opcional Obligatorio para
Autenticidad mediante PKI MRTDs con
Originalidad huella dactilar
Tabla 2.1: Mecanismos de seguridad en MRTDs
A continuación se analizan más en detalle estos mecanismos.

Basic Access Control (BAC)
El objetivo del Control de Acceso Básico es garantizar que, en el caso de los chips sin contacto
(lectura a distancia), el dispositivo que está inspeccionando el MRTD está teniendo contacto
visual con el interior del pasaporte. Esta es la principal contramedida para accesos no legítimos a
distancia. Por ejemplo, disponiendo de la suficiente potencia, sería posible copiar el MRTD de
una persona que estuviera sentada a nuestro lado en el autobús o el metro. El Control de Acceso
Básico es opcional según ICAO, pero obligatorio según la Unión Europea.
El proceso para el Control de Acceso Básico es el siguiente:
Lectura visual de la MRZ.
Extracción del número del documento, fecha de nacimiento y fecha de caducidad.
Generación del par de claves necesarias para el cifrado (𝐾𝐸𝑁 𝐶 ) y la autenticación mediante
Message Authentication Code (MAC) (𝐾𝑀 𝐴𝐶 ) del canal de comunicación [4].
El Control de Acceso Básico únicamente nos permite acceder a los datos menos sensibles del
pasaporte, por ejemplo DG1, DG2.
Passive Authentication (PA)
Como se ha explicado anteriormente, toda la información relevante sobre el MRTD se

encuentra almacenada en los distintos DGs. La Autenticación Pasiva permite verificar que estos
DGs no han sido alterados desde la expedición del documento. Para ello se utiliza el Security
Object Data (SOD), que es un DG que contiene los hashes de todos los DGs. El SOD a su vez
es firmado con un certificado de una jerarquía conocida como Country Signing Certification
Authority (CSCA). Es una jerarquía de certificados X.509. En la figura 2.3 se puede ver un
ejemplo de esta jerarquía.
Los certificados son emitidos para los firmantes de documentos, así como para las CSCAs.
Tras la emisión de los certificados, en contadas ocasiones, tales como el compromiso de la clave
privada correspondiente, puede producirse su revocación. Por esta razón, la CSCA también
emite una Lista de Revocación de Certificados (CRL), que identifica los certificados emitidos
previamente que han sido revocados y por lo tanto ya no son de confianza.
Certificados CSCA
Figura 2.3: Ejemplo de jerarquía CSCA [7]
Los estados emiten dos tipos de certificados CSCA: certificados autofirmados y autoemitidos.
Los certificados autofirmados -comúnmente conocidos como raíz CSCA- se emiten normal-
mente cuando un CSCA inicia sus operaciones. Sin embargo, opcionalmente, se pueden
emitir nuevos certificados autofirmados cuando las claves CSCA se reemplazan por otras
nuevas. La clave pública en un certificado raíz CSCA verifica la firma de ese certificado [7].
Los certificados autoemitidos -comúnmente conocidos como enlaces CSCA- son emitidos
cuando una CSCA existente reemplaza sus claves con un nuevo par de claves. La clave
pública contenida en un certificado de enlace CSCA es la nueva clave pública de la CSCA.
La anterior pública del CSCA es la que verifica la firma en un certificado de enlace [7].
La única diferencia entre un certificado raíz CSCA y un certificado de enlace CSCA es la

clave pública que se certifica [7].
En el certificado raíz CSCA, la clave pública que se certifica es la correspondiente a la clave

privada que firma dicho certificado. En el certificado de enlace CSCA, la clave pública que
se certifica es una clave pública nueva de que corresponde a una nueva clave privada, que
el CSCA utiliza después de la emisión del certificado de enlace. El resto del contenido en
los certificados es idéntico. Dado que los certificados CSCA son autoemitidos, la identidad
de la emisor del certificado y el asunto del certificado, que es, el propietario de la clave
pública certificada, son idénticos [7].
Certificados de firmante de documentos, DS
Son certificados emitidos por la CSCA cuyo sujeto es la identidad del firmante de documentos
cuya clave pública está contenida en el certificado [7].
Al igual que con los certificados CSCA, el elemento Key Usage restringe el uso de la clave
pública certificada. Las claves públicas de DS sólo deben utilizarse para verificar firmas
digitales [7].
Para verificar la autenticidad de los datos almacenados mediante PA el sistema de inspección

tendrá que realizar los siguientes pasos:
Leer el SOD del MRTD.
Obtener el certificado de DS, que a su vez estará firmado por la CSCA.
Verificar el certificado DS (que es el que firma el SOD), utilizando el certificado de la

CSCAs correspondiente al país.
Calcular los hashes de los DGs, es decir, calcular su propia versión del SOD. Verificar la
firma del SOD, es decir, utilizar la clave pública del DS para obtener el valor de la firma
en claro.
Comparar el valor de la firma calculado, con el obtenido a través del pasaporte. En caso de
que ambos valores sean iguales se puede asegurar la autenticidad de los DGs del pasaporte.
Como contrapartida, no se puede asegurar que todos estos datos no hayan sido clonados.
Active Authentication (AA)
La Autenticación Activa, AA, previene la clonación de todos los datos del documento mediante
la utilización de un par de claves únicos del dispositivo. La clave pública del chip es almacenada
en el DG15, y por lo tanto protegida de ser modificada por la Autenticación Pasiva y la clave
privada se encuentra en la zona de memoria segura del chip y no puede ser leída y/o modificada
de forma externa. La Autenticación Activa es opcional según ICAO.
Los pasos a seguir en este procedimiento son los siguientes:
Se obtiene la clave pública del chip leyendo el DG15.
Se envía un reto de firma al MRTD.
El MRTD firma el reto con su clave privada y lo devuelve al sistema de inspección.
Utilizando la clave pública, del DG15, se verifica que el reto enviado es el mismo que el
recibido. Si los valores son los mismos entonces se puede asegurar que el chip no ha sido
clonado, puesto que de haberlo sido no poseería la clave privada.
Extended Access Control (EAC)
Este mecanismo es utilizado en el caso en el que se quiera acceder a la información más

sensible del MRTD. El Control de Acceso Extendido es un protocolo asimétrico ideado por la UE
y que es obligatorio en los MRTD que posean información biométrica. Se basa principalmente en
dos componentes que van a ser explicados a continuación, Autenticación de Chip y Autenticación
de Terminal.
Chip Authentication (CA) La Autenticación de Chip se utiliza para autenticar el MRTD

respecto al terminal. Para la utilización de este mecanismo es necesario que se haya efectuado
BAC con anterioridad. La Autenticación de Chip establece unas claves de forma asimétrica que
se utilizaran para generar un canal seguro, este mecanismo puede ser utilizado en sustitución a
la Autenticación Activa, (AA). Los pasos a realizar son los siguientes:
El sistema de inspección lee la clave pública del MRTD del DG14.
Utilizando Diffie-Hellman (DH) o Elliptic Curve Diffie-Hellman (ECDH) se generan un par

de claves efímeras y se envía la clave pública al MRTD.
Ambos, el MRTD y el sistema de inspección, derivan nuevas claves de sesión simétricas

(𝐾𝐸𝑁 𝐶 , 𝐾𝑀 𝐴𝐶 ) mediante la utilización del secreto compartido generado.
A partir de ese momento se utilizarán las nuevas claves de sesión derivadas para establecer el
canal seguro.
Figura 2.4: Esquema de jerarquía CVCA de un MRTD
Terminal Authentication (TA) La Autenticación de Terminal asegura que el terminal ha

sido autorizado por una fuente de confianza. Esta metodología se apoya en el uso de una PKI
con la estructura descrita en la figura 2.4.
Cada uno de los países que despliegan pasaportes de segunda generación de ICAO debe
establecer su propia PKI y autorizar a los países permitidos para leer los datos sensibles de
sus pasaportes. La inspección PKI consiste en componentes de la infraestructura que procesan
peticiones de certificados, verifican la identidad de las nuevas aplicaciones, y luego emiten
certificados que otorgan permiso para inspeccionar por tiempo limitado. La cadena de certificado
resultante se verifica mediante el pasaporte electrónico. Estos componentes son:
Country Verifying Certificate Authority (CVCA)
Cada país que quiera participar en un entorno EAC necesita establecer una CVCA. La
CVCA autoriza Autoridades de Certificación de Verificación de Documentos (DVCA) que
a su vez emiten certificados de Inspección de Documentos (IS).
Document Verifier Certificate Authority (DVCA)
Las Autoridades de Certificación de Verificación de Documentos recibirán certificados de

CVCAs de todos los países que estén dispuestos a conceder el acceso a los pasaportes
2.2 Documento Nacional de Identidad electrónico (DNIe) 31
que hayan expedido. El DVCA emitirá entonces los certificados a todos los Sistemas de
Inspección (IS) del país.
Inspection System (IS)
los Sistemas de Inspección (IS) serán los encargados de realizar los procesos de acceso EAC
en los pasaportes inspeccionados.
La Autenticación de Terminal se realiza en dos fases distintas:
Verificación de la cadena de certificados
• El terminal accede al EF que contiene el Certification Authority Reference (CAR)

que identifica la CVCA del país emisor de este MRTD.
• Se envían secuencialmente desde el terminal la cadena de certificados de la CVCA del

país de emisión del MRTD, CVCA, CVCAs de enlace, DVCA e IS correspondientes.
• El MRTD se encuentra en posesión del certificado CVCA del país donde se emitió,
por lo que, utilizando dicha clave pública, verifica la cadena recibida del sistema de
inspección.
• En caso de enviarse CVCAs de enlace nuevo en la jerarquía distinto al almacenado, se

actualizan los datos del Certification Authority Reference (CAR) y certificado CVCAs
en el MRTD.
Demostración de que el sistema de inspección posee la clave privada del IS
• El MRTD envía al sistema de inspección un reto. El sistema de inspección cifra el

reto con la clave privada del IS, y lo envía al MRTD.
• El MRTD descifra el reto con la clave pública que recibió con la cadena de certificados
en el punto anterior, y compara el reto enviado con el obtenido. En caso de que ambos
retos sean iguales se puede asegurar de que el sistema de inspección se trata de un
dispositivo autorizado.
2.2. Documento Nacional de Identidad electrónico (DNIe)
El Documento Nacional de Identidad (DNI), emitido por la Dirección General de la Policía

de España, es el documento que acredita la identidad, datos personales y nacionalidad española
de su titular.
Para responder a las nuevas necesidades de la sociedad de la información se actualiza el
DNI a su versión electrónica, el Documento Nacional de Identidad electrónico (DNIe), similar al
tradicional y que incorpora un chip ICC, capaz de guardar de forma segura información y de
procesarla internamente. Esta nueva versión permite, además de su uso tradicional, acceder la
realización de firmas digitales, el acceso a servicios estatales o privados a través de Internet y la
identificación electrónica del titular [8].
Figura 2.5: Aspecto esquemático de un DNIe
2.2.1. Estructura de datos
El DNIe presenta su información distribuida en tres zonas con diferentes niveles y condiciones
de acceso [9]:
Zona pública: Accesible en lectura sin restricciones. Contiene:
• Certificado de Autoridad de Certificación intermedia emisora.
• Claves Diffie-Hellman.
• Certificado X.509 de componente.
Zona privada: Accesible en lectura por el ciudadano, mediante la utilización de un PIN.

Contiene:
• Certificado de Firma, para la realización de firmas electrónicas.
• Certificado de Autenticación, para la autenticación electrónica a través de Internet.
Zona de seguridad: Accesible en lectura por el ciudadano, en los Puntos de Actualización

del DNIe.
2.2 Documento Nacional de Identidad electrónico (DNIe) 33
• Datos de filiación del ciudadano (los mismos que están en el soporte físico).
• Imagen de la fotografía.
• Imagen de la firma manuscrita.
Entre los certificados que se almacenan en la tarjeta se encuentran los siguientes certificados
electrónicos:
Certificado de Componente. Su propósito es la autenticación de la tarjeta del DNIe

mediante el protocolo de autenticación mutua definido en CWA 14890 [10, 11]. Permite
el establecimiento de un canal cifrado y autenticado entre la tarjeta y los Drivers. Este
certificado no estará accesible directamente por los interfaces estándar de usuario.
Certificado de Autenticación. Este certificado se utiliza para el establecimiento del

Canal Seguro con autenticación de Cliente y Servidor. Es un certificado X.509 versión 3
estándar, que tiene activo en el Key Usage el indicador de Digital Signature (Firma Digital)
y que está asociado a un par de claves pública y privada, generadas en el interior del CHIP
del DNIe.
Certificado de firma. Este certificado es el que utiliza para la firma de documentos

garantizando la integridad del Documento y el No repudio de origen. Es un certificado X.509
versión 3 estándar, que tiene activo en el Key Usage el indicador de Content Commitment
(No Repudio) y que está asociado a un par de claves pública y privada, generadas en el
interior del CHIP del DNIe.
Es este Certificado expedido como certificado reconocido y creado en un Dispositivo Seguro

de Creación de Firma, el que convierte la firma electrónica avanzada en firma electrónica
reconocida, permitiendo su equiparación legal con la Firma Manuscrita [12, 13].
Si bien entre los datos que proporciona el DNIe no está la huella dactilar del titular, existe
una operativa disponible que permite un proceso de Match-On-Card de la huella dactilar
proporcionando las minucias de una huella escaneada según el formato definido en la parte 2 de
la ISO/IEC 19794-2.
2.2.2. Mecanismo de seguridad
Los accesos al chip del DNIe se rigen por los siguientes componentes de seguridad:
Autenticación de los elementos que intervienen en el proceso para asegurar que la tarjeta
que se accede ha sido emitida por la DGP española.
Establecimiento de una canal seguro de comunicaciones que garantice la confidencialidad

de los datos intercambiados entre la tarjeta y el sistema que interactúa con ellos.
Estos mecanismos se implementan mediante el proceso de autenticación interna/externa

descrito en la norma CWA 14890 [10, 11]. En este proceso el Integrated Circuit Card (ICC)
es el DNIe mientras que el Interface Device (IFD) es un sistema policial. Entre la tarjeta a
autenticar y el sistema policial tiene lugar un protocolo de desafío-respuesta en el que intervienen
los certificados Card Verificable (CV) de ambas entidades. Esto permite al sistema policial, en
primera instancia, determinar si el DNIe es legítimo y, en segunda instancia, el establecimiento
de un canal seguro entre las tarjetas y el software que accede a ellas. El canal seguro establecido
tiene vigencia de sesión por lo que si la tarjeta se extrae del lector y/o se descarga la aplicación
de inspección, será necesario volver a realizar el proceso de autenticación.
El sistema policial utilizará los Hardware Security Modules (HSMs) de la infraestructura
de certificación correspondiente, que son dispositivos criptográficos hardware que generan,
almacenan y protegen claves criptográficas, tanto para la custodia de sus propias claves como
para la aceleración de los procesos criptográficos.
El servicio de autenticación de ICC genera un token firmado que será verificado por el sistema
de inspección utilizando un servicio de verificación del sistema policial. Una vez verificado con
éxito, el sistema de inspección tiene la garantía de que la tarjeta involucrada en el proceso es
legítima dando fe de ello un servicio de seguridad policial. El token incluye el número de serie
del chip, lo que permitirá al sistema de inspección realizar comprobaciones adicionales sobre la
tarjeta autenticada.
El protocolo descrito anteriormente es transportado a su vez sobre el protocolo HTTPS.
2.3. Sistemas externos
Como se ha visto anteriormente, en el proceso de verificación de un MRTD existen una serie

de procesos y validaciones que dependen de certificados e infraestructuras propias de cada uno
de los países emisores de los documentos.
En este sentido, un sistema de verificación móvil válido deberá ser capaz de acceder a ellos.
2.4 Elementos biométricos 35
En el caso de la Autenticación Pasiva (PA) se puede mantener de manera local en la aplicación un

almacén de certificados CSCA y DS de confianza, si bien sería deseable disponer de un repositorio
centralizado y actualizado para estos menesteres.
En el caso del Control de Acceso Extendido (EAC), al requerirse la firma de un desafío con
una clave privada emitida ex profeso a estos efectos a cada país que realice las verificaciones, se
hace imprescindible disponer de algún sistema provisto por alguno de estos países para solicitar
dichas firmas.
Considerando lo dicho hasta ahora, cabrían destacar los siguientes sistemas externos:
Servicio para la realización de los mecanismos de seguridad de los MRTDs que gestiona
de forma centralizada la inspección de los documentos. En este sentido cabe señalar la
existencia del sistema Electronic Document Inspection System (EDIS) que permite estas
operaciones a nivel español [14].
Servicio para la realización de los mecanismos de seguridad de los DNIe que implementa
la autenticación interna/externa indicada en la norma CWA 14890 [10, 11] para ICC del
DNIe. Existe a estos efectos el sistema policial Servicio de Autenticación de ICC (SAI) que
permite estas operaciones a nivel español.
Consulta en bases de datos policiales de señalamientos policiales. El uso de estas con-

sultas debe permitir comprobar los señalamientos vigentes tanto del viajero como de la
documentación.
2.4. Elementos biométricos
Tanto los documentos MRTD como los DNIe contienen elementos biométricos faciales y
dactilares, en algunos casos extraíbles, en otros verificables:
2.4.1. Biometría facial
Los documentos MRTD proveen las imágenes faciales en el DG2, tras haber accedido a los
datos mediante BAC, según la estructura Common Biometric Exchange Formats Framework
(CBEFF) definida en el estándar CBEFF NISTIR 6529-A. El formato de las imágenes cumple el
estándar ISO/IEC 19794-5 y puede estar codificado en JPEG o JPEG 2000.
En el caso del DNIe la imagen facial se almacena codificada en JPEG.
2.4.2. Biometría dactilar
Las huellas dactilares de los documentos MRTD se proveen en el DG3, previa realización
del proceso EAC, en la estructura CBEFF definida en el estándar CBEFF NISTIR 6529-A. El
formato de las imágenes cumple el estándar ISO/IEC 19794-4 y el algoritmo de codificación es
WSQ que es un algoritmo de compresión desarrollado por el FBI, el Laboratorio Nacional de Los
Alamos, y el National Institute of Standards and Technology (NIST) y ampliamente utilizado
para imágenes de huellas dactilares en escala de grises. Además de éstos, se emplea el estándar
NISTIR 7151 para procesos relacionados con la calidad de la imagen.
En el caso del DNIe, como ya se ha comentado anteriormente, no existe la posibilidad de
extraer la huella del ICC, si bien es posible realizar un proceso de Match-On-Card de la huella
dactilar proporcionando las minucias de una huella escaneada según el formato definido en la
ISO/IEC 19794-2.
2.5. Plataforma móvil
Entre la gran variedad de opciones móviles disponibles en el mercado, se ha escogido la

solución Android por los siguientes motivos:
Amplia implantación del sistema en el mercado español en el que, si bien ha tocado techo
en el último año, se sitúa muy por encima del resto de sistemas con una gran diferencia
como muestra la figura 2.2.
Sistema Operativo Porcentaje

Android 83 %
iOS 12.9 %
Windows 3.8 %
BlackBerry 0%
Otros 0.3 %
Tabla 2.2: Implantación de SO en Smartphones en España (diciembre del 2014) [15]
Coste medio menor que otras plataformas, sobre todo en comparación con iOS como se
puede ver en la figura 2.6.
2.5 Plataforma móvil 37
Figura 2.6: Precios de dispositivos según SO en el segundo cuatrimestre de 2014 [16]
Variedad de dispositivos y periféricos compatibles para las diferentes funcionalidades del

proyecto. En concreto es necesario un dispositivo con cámara trasera con una calidad
razonable, capacidad de lectura NFC, Bluetooth y capacidad USB OTG. En la figura 2.7
se pueden ver algunos de los dispositivos Android más comercializados.
Figura 2.7: Dispositivos Android más usados [17]
Disponibilidad de librerías, tanto GPL como comerciales, enumeradas en la sección 4.2,

que facilitarán el desarrollo del proyecto.
En general Android destaca como opción elegida cuando se trata de desarrollos en los que
son importantes criterios como:
• Soporte de estándares abiertos.
• Facilidad de portabilidad.
• Disponibilidad de un API variada.
• Acceso a documentación completa y detallada.
En la figura 2.8 se puede ver la relación entre la elección habitual de plataforma y los
criterios comentados.
Figura 2.8: Porcentaje de prioridad de elección de plataforma por criterios de selección [18]
2.5.1. Arquitectura del sistema Android
Entre las múltiples características del sistema Android, a continuación se señalan aquellas
más importantes para el desarrollo del proyecto.
2.6 Aplicaciones existentes 39
Diseño de dispositivo: Plataforma adaptable a pantallas de mayor resolución, VGA,

biblioteca de gráficos 2D, biblioteca de gráficos 3D basada en las especificaciones de la
OpenGL y diseño de teléfonos tradicionales.
Conectividad: Android soporta tecnologías de conectividad móvil, Bluetooth, Wi-Fi,

NFC, etcétera.
Soporte Java: Aunque la mayoría de las aplicaciones están escritas en Java, no hay una
Java Virtual Machine (JVM) en la plataforma. El Java bytecode no es ejecutado, sino que
primero se compila en un ejecutable y corre en la Máquina Virtual Dalvik.
Soporte multimedia: Android soporta la mayoría de los formatos multimedia habituales,

entre ellos JPEG, PNG, GIF y BMP.
Hardware adicional: Android soporta cámaras de fotos, de vídeo, pantallas táctiles,

etcétera.
Entorno de desarrollo: Incluye un emulador de dispositivos, herramientas para depura-

ción de memoria y análisis del rendimiento del software. Inicialmente el IDE utilizado era
Eclipse con el plugin de Herramientas de Desarrollo de Android (ADT). Ahora se considera
como entorno oficial Android Studio, disponible en la página oficial de desarrolladores de
Android.
Multitarea: Las aplicaciones o procesos que no estén ejecutándose en primer plano reciben
ciclos de reloj.
2.6. Aplicaciones existentes
Existen actualmente en el Google Play Store varias aplicaciones relacionadas con la lectura de
documentos electrónicos. Son interesantes a este respecto las que se mencionan a continuación:
ajMRTD: Esta aplicación, se sirve de la librería jMRTD (que se menciona más adelante
en esta memoria) para realizar lecturas de documentos MRTD. La aplicación permite la
introducción manual de datos de diferentes documentos para la realización del BAC. Una
vez accedido el pasaporte lee los datos del DG1 y muestra la imagen facial extraída del
DG2 [19].
NFC Passport Reader: Al igual que la aplicación anterior, ésta emplea la librería jMRTD
para realizar la lectura de documentos MRTD. En este caso se ofrece la lectura a través de
OCR de los datos de la MRZ para la obtención de los datos necesarios en el BAC. Igual que
en el caso anterior, se leen los datos del DG1 y muestra la imagen facial extraída del DG2,
además de ofrecer un resumen de los elementos de seguridad presentes en el pasaporte [20].
En general se puede observar que las aplicaciones disponibles permiten la realización del BAC,
pero no del resto de mecanismos de seguridad como EAC, PA o AA y por lo tanto tampoco
permiten el acceso completo a los datos del pasaporte, incluido el DG3.
Las aplicaciones descritas no incluyen ningún tipo de verificación de señalamientos policiales,
esto es, antecedentes policiales, órdenes de búsqueda y captura, avisos de pérdida o robo del
documento, etcétera. Igualmente no proveen mecanismos para la verificación de los elementos
biométricos incluidos en el documento.
Capı́tulo 3
Diseño del sistema
Como se pudo ver en la sección 2.6, existen en el mercado algunas aplicaciones capaces de
acceder a la información principal de los documentos MRTD. Si bien dichas aplicaciones realizan
una primera aproximación a la lectura de los documentos de tránsito, no son capaces de leer
tarjetas ICC y sólo permiten gestionar el mecanismo de seguridad BAC. Sería deseable una
solución capaz de gestionar todos los mecanismos descritos en el apartado 2.1.3 y acceder a la
información biométrica completa, incluida la dactilar presente en el DG3.
En este sentido, el sistema propuesto consiste en una aplicación móvil para dispositivos
Android que permitirá:
Verificación de todos los mecanismos de seguridad (BAC, PA, EAC, AA) de los documentos
MRTD a través de sistemas externos con acceso a certificados CSCA y CVCA si fuera
necesario.
Establecimiento de canal seguro de administración con el DNIe mediante los sistemas

policiales pertinentes.
Lectura de los datos de de los documentos, incluidos los elementos biométricos faciales y
dactilares si están disponibles.
Validaciones contra sistemas policiales del titular y el documento.
Posibilidad de verificaciones biométricas faciales a través de la cámara del dispositivo y

dactilares a través de lectores de huellas externos o empotrados.
41
42 CAPÍTULO 3. DISEÑO DEL SISTEMA
3.1. Componentes Hardware
En la figura 3.1 se presenta un esquema general de la aplicación que permite aclarar cuáles
serán los componentes hardware imprescindibles para el funcionamiento de la solución.
Figura 3.1: Esquema general de componentes
3.1.1. Smartphone Android
La pieza central de la solución será un Smartphone que ejecute la plataforma Android en

el que se desplegará una aplicación encargada de gestionar todo el flujo de consulta de los
documentos, utilizando para ello componentes hardware internos y externos al teléfono. Entre
los elementos internos destacan los siguientes:
Lector NFC: El teléfono incluirá una antena NFC para realizar las comunicaciones con
los documentos MRTD.
Cámara trasera: Se empleará para la captura de la imagen de la MRZ que se procesará

con OCR y que es necesaria para la realización del Basic Access Control (BAC) descrito en
la sección 2.1.3, así como para la captura facial en el proceso de cotejo biométrico facial.
USB OTG: El móvil debe soportar el uso de USB OTG para gestionar las comunicaciones
con las tarjetas ICC del DNIe.
3.2 Componentes Software 43
Bluetooth: Se utilizarán conexiones por Bluetooth para leer las huellas dactilares (más
adelante se especifica el hardware del lector de huellas) y poder realizar la verificación
biométrica dactilar correspondiente.
Conexión a Internet: Para poder acceder a los diferentes sistemas policiales de verifica-
ción, autenticación y señalamientos.
3.1.2. Lector de huellas Bluefin
Entre las múltiples opciones disponibles, se ha elegido para la solución el lector de huellas
Bluefin del fabricante TopLink. Éste es un dispositivo portátil de escaneo de huellas dactilares
que utiliza un sensor capacitivo de silicio para capturar las huellas dactilares. Cuenta con una
interfaz Bluetooth inalámbrica para la comunicación con el teléfono. El dispositivo se identifica a
sí mismo y ofrece un puerto Serial Port Profile (SPP) con el host de conexión. Además de la clave
de acceso Bluetooth y la autenticación, se puede establecer otra sesión de comunicación segura
para los comandos y la transferencia de datos con el teléfono utilizando Advanced Encryption
Standard (AES) [21].
3.2. Componentes Software
Para el desarrollo de la solución se ha planificado la realización de componentes software que

encapsulan las funcionalidades relacionadas con la verificación de los documentos, mecanismos
de logs, consultas de señalamientos policiales, accesos a sistemas externos, etcétera.
En la figura 3.2 se puede ver un diagrama de flujo general del funcionamiento de la aplicación.
3.2.1. Utilidades comunes
Se desarrolla un componente general, de uso habitual para el resto de componentes, con una
serie de utilidades generalistas y frecuentes. Entre las utilidades a implementar se incluirán:
Utilidades de uso y tratamiento de cadenas de caracteres o arrays.
Utilidades de codificación y decodificación en base64 y hexadecimal.
Utilidades de manejo de certificados X.509.
Utilidades de manejo de recursos y clases.

Figura 3.2: Diagrama de flujo de la solución
Utilidades de manejo de listas y colecciones.
Utilidades de manejo de XML con Document Object Model (DOM).
Utilidades de manejo de ficheros y de procesos de entrada/salida.
Utilidades de manejo numérico.
Utilidades de manejo de trazas.

Utilidades de manejo de protocolos y elementos de red, incluidos HTTP, TLS, HTTPS,

proxy, etcétera.
3.2.2. API de inspección de documentos (InspectionService)
Este módulo describe un API para realizar las tareas de inspección de documentos, esencial-
mente el proceso de verificación de SOD que se produce durante la Autenticación Pasiva (PA)
y los procesos de verificación y firma durante la realización del Control de Acceso Extendido
(EAC).
En la figura 3.3 se puede ver un diagrama de clases del API de inspección de documentos
llamada InspectionService.
<<Java[Class>>
CSCACertificatesReturn
certificateMode:[byte
<<Java[Interface>>
NONE:[CSCACertificatesReturn <<Java[Class>>
IInspectionService
DS_CERTIFICATE:[CSCACertificatesReturn CVCAReference
CSCA_CERTIFICATE:[CSCACertificatesReturn getCVCertificateChainNStringLCVCAReference_:CertificateChainResponse
referenceObject:[Object
ALL_CERTIFICATES:[CSCACertificatesReturn signChallengeNStringLbyte[]LStringLString_:SignChallengeResponse
verifySODNStringLbyte[]LCSCACertificatesReturnLDate_:SODVerifyResponse CVCAReferenceNObject_
CSCACertificatesReturnNbyte_
verifySignatureNStringLbyte[]LCSCACertificatesReturnLDate_:SignatureVerifyResponse toStringN_:String
equalsNObject_:boolean
getCertificateModeN_:byte
hashCodeN_:int
<<Java[Class>> <<Java[Class>>
toStringN_:String
SignatureVerifyResponse SODVerifyResponse
signData:[byte[] sodData:[byte[]
<<Java[Class>> signature:[byte[] serialNumber:[byte[]
<<Java[Class>>
SignChallengeResponse serialNumber:[byte[] issuer:[String
CertificateChainResponse
issuer:[String signer:[String
challengeSignature:[byte[]
CertificateChainResponseN_ signer:[String cscaCertificate:[byte[]
SignChallengeResponseN_
CertificateChainResponseNErrorInfo_ crl:[byte[] dsCertificate:[byte[]
SignChallengeResponseNbyte[]_
CertificateChainResponseNList<CVCertificate>_ tokenOCSP:[byte[] crl:[byte[]
SignChallengeResponseNErrorInfo_
numCertificates:[int SODVerifyResponseN_
certificatesChain:[byte[] SODVerifyResponseNbyte[]Lbyte[]LStrinjjj
SignatureVerifyResponseN_ SODVerifyResponseNErrorInfo_
Dcertificates mjjT
SignatureVerifyResponseNbyte[]Lbjjj getCSCACertificateN_:byte[]
<<Java[Class>> SignatureVerifyResponseNErrorInfo_ getDSCertificateN_:byte[]

CVCertificate hasCSCACertificateN_:boolean
hasDSCertificateN_:boolean
certificateCHR:[String
setCSCACertificateNbyte[]_:void
certificateCAR:[String
setDSCertificateNbyte[]_:void
certificateRole:[CVCertificateRole
encoded:[byte[] <<Java[Class>>
CVCertificateN_ ErrorInfo <<Java[Class>>
CVCertificateNStringLStringLCVCertificateRoleLbyte[]_ code:[int InspectionServiceResponse
DerrorInfo
subcode:[int InspectionServiceResponseN_
mjj.
description:[String InspectionServiceResponseNErrorInfo_
ErrorInfoN_ getErrorStringN_:String
ErrorInfoNintLintLString_
Figura 3.3: Diagrama de clases de API de inspección de documentos (InspectionService)
En el diagrama se aprecia que se define como elemento principal la interfaz IInspectionService

que provee los siguientes métodos:
CertificateChainResponse getCVCertificateChain(String documentId, CVCAReference

caReference) throws InspectionServiceException
Este método debe devolver la cadena completa de certificados CVC-EAC del CAR indicado
a partir de los siguientes datos:
El identificador del documento MRTD a verificar.
La referencia de la AC del certificado CVC-EAC.
Devolverá la respuesta con la cadena completa de certificados CVC-EAC del CAR indicado o los
motivos del error.
SignChallengeResponse signChallenge(String documentId, byte[] challenge, String

inspectionSystemCAR, String inspectionSystemCHR) throws
InspectionServiceException
Este método debe realizar la firma del reto para la validación EAC a partir de los siguientes
datos:
El reto generado por el MRTD destinado al sistema de inspección.
La referencia de autoridad de certificación (CAR) del certificado CVC-EAC de IS asociado

a la clave privada con la cual se desea que se emita la firma del reto enviado según la
especificación TR-03110 [22, 23].
La referencia del titular de certificado (CHR) del certificado CVC -EAC de IS asociado
a la clave privada con la cual se desea que se emita la firma del reto enviado según la
especificación TR-03110 [22, 23].
Devolverá la respuesta con la firma del reto o los motivos del error.
SODVerifyResponse verifySOD(String documentId, byte[] sod, CSCACertificatesReturn

certificatesReturn, Date crlSODMin) throws InspectionServiceException
Este método debe verificar los datos de SOD del documento a inspeccionar a partir de los
siguientes datos:

Los datos del SOD a verificar.
La configuración de certificados de CSCA que se desean recuperar en la respuesta. Si es

nulo se considera que no se devuelve ningún certificado.
La mínima fecha de CRL a recuperar. Si es nulo se ignora.
Devolverá los datos de verificación del SOD obtenidos.
SignatureVerifyResponse verifySignature(String documentId, byte[] signature,

CSCACertificatesReturn certificatesReturn, Date crlMin) throws
InspectionServiceException, CertificateEncodingException
Este método debe verificar los datos de firma del documento a inspeccionar a partir de los
siguientes datos:
Los datos de la firma a verificar.
La configuración de certificados de CSCA que se desean recuperar en la respuesta. Si es

nulo se considera que no se devuelve ningún certificado.
La mínima fecha de CRL a recuperar. Si es nulo se ignora.
Devolverá los datos de verificación de la firma obtenidos.

Si bien este módulo tiene una vocación generalista, se desarrolla en conjunto con una
implementación específica para los sistemas policiales que realicen estos menesteres.
3.2.3. API de consulta de documentos (DSQService)
Se describe un API para lanzar las consultas sobre el estado policial de los documentos
verificados.
En la figura 3.4 se puede ver un diagrama de clases del API de inspección de documentos
llamada InspectionService.
En el diagrama se aprecia que se define como elemento principal la interfaz IDSQService que
provee el método
DSQServiceResponse checkRecord(DSQServiceRequest request) throws

DSQServiceException
<<JavaNInterface>>
IDSQService
checkRecord0DSQServiceRequest.:DSQServiceResponse
<<JavaNClass>> <<JavaNClass>>
DSQServiceResponse DSQServiceRequest
DSQServiceResponse0. DSQServiceRequest0.
DSQServiceResponse0List<DSQServiceDocument>. DSQServiceRequest0List<DSQServiceDocument>.
addResult0DSQServiceDocument.:void addDocument0DSQServiceDocument.:void
-results 0..* -documents 0..*
<<JavaNClass>>
DSQServiceDocument
idNumber:NString
supportNumber:NString
country:NString
message:NString
category:NString
DSQServiceDocument0.
DSQServiceDocument0String,String,String.
DSQServiceDocument0String,String,String,String,String.
Figura 3.4: Diagrama de clases de API de consulta de documentos (DSQService)
Este método debe realizar una consulta de estado de documentos según los datos de
entrada indicados en el tipo DSQServiceRequest que contiene una colección de elementos
DSQServiceDocument cuyos parámetros principales son:
Número de identificación del documento.
Número de soporte del documento.
País del documento.
Devolverá el resultado de la consulta de estado de los documentos indicados.

Al igual que el módulo anterior, junto con el API se realiza una implementación específica
para los sistemas policiales.
3.2.4. API de antecedentes policiales (CRService)
Se describe un API para lanzar las consultas sobre señalamientos policiales de los titulares de
los documentos verificados.
En la figura 3.5 se puede ver un diagrama de clases del API de registro policial llamada
CRService.
<<JavaOInterface>>
ICRService
checkRecordLCRServiceRequest-:CRServiceResponse
<<JavaOClass>> <<JavaOClass>>
CRServiceResponse CRServiceRequest
CRServiceResponseL- CRServiceRequestL-
CRServiceResponseLList<CRServiceSubject>*CRServiceError- CRServiceRequestLList<CRServiceSubject>-
addResultLCRServiceSubject-:void addSubjectLCRServiceSubject-:void
getErrorL-:CRServiceError getSubjectsL-:List<CRServiceSubject>
getResultsL-:List<CRServiceSubject> setSubjectsLList<CRServiceSubject>-:void
setErrorLCRServiceError-:void
setResultsLList<CRServiceSubject>-:void
1error 0..1 1results 0..0 1subjects 0..0
<<JavaOClass>> <<JavaOClass>>
CRServiceError CRServiceSubject
code:OString name:OString
description:OString surname:OString
1errors dateOfBirth:ODate
CRServiceErrorL-
CRServiceErrorLString*String- 0..0 positiveMatch:Oboolean
getCodeL-:String active:Oboolean
getDescriptionL-:String CRServiceSubjectL-
setCodeLString-:void CRServiceSubjectLString*String*Date*boolean*boolean-
setDescriptionLString-:void addErrorLCRServiceError-:void
Figura 3.5: Diagrama de clases de API de registro policial (ICRService)
En el diagrama se aprecia que se define como elemento principal la interfaz ICRService que
provee el método
CRServiceResponse checkRecord(CRServiceRequest request) throws CRServiceException
Este método debe realizar una consulta de estado de documentos según los datos de entrada
indicados en el tipo CRServiceRequest que contiene una colección de elementos CRServiceSubject
cuyos parámetros principales son:
El nombre de la persona de la que se consulta la ficha policial.
Los apellidos de la persona de la que se consulta la ficha policial.
La fecha de nacimiento de la persona de la que se consulta la ficha policial.
Devolverá el resultado de la consulta de antecedentes de los individuos indicados.

Como en los dos módulos anteriores, se desarrolla una implementación específica para el
acceso a sistemas policiales.
3.2.5. API de captura dactilar
Se describe un API de servicio para la captura de la huella dactilar a través de lectores

externos, de manera que sea sencillo integrar nuevos lectores de huellas en el sistema, además del
propuesto.
En la figura 3.6 se puede ver un diagrama de clases del API de captura dactilar llamada
FingerprintReader.
<<JavaqInterface>>
IFingerprintReader
connectDevice]Object,booleanM:void
isReaderDevice]ObjectM:boolean
listDevices]M:List<?qextendsqObject>
releaseConnection]M:void
requestFingerprint]M:void
setReaderListener]ReaderListenerM:void
stopAll]M:void
stopFingerprintRead]M:void
<<JavaqInterface>>
ReaderListener
getContext]M:Context
onConnecting]ObjectM:void
onConnectionFailed]Object,booleanM:void
onFingerprintsRead]List<byte[]>,int,boolean,booleanM:void
onFingerprintsReadFailed]M:void
onFingerprintsReading]M:void
onOperationMessage]StringM:void
onReaderConnected]ObjectM:void
onReaderDisconnected]M:void
Figura 3.6: Diagrama de clases de API de captura dactilar (FingerprintReader)
En el diagrama se aprecia que se define como elemento principal la interfaz IFingerprintReader

que provee varios elementos.
Por un lado, se permiten una serie de acciones para solicitar al lector la conexión, lectura,
desconexión, etcétera:
listDevices, para listar los dispositivos disponibles.
connectDevice, para lanzar la conexión con el dispositivo.
releaseConnection, para liberar la conexión con el dispositivo.
requestFingerprint, para solicitar la lectura de una huella.

stopFingerprintRead, para anular la lectura de huella.
stopAll, para anular cualquier proceso con el lector.
isReaderDevice, para chequear que un dispositivo corresponde a la implementación de

lector esperada.
setReaderListener, para indicar quien espera las respuestas del lector.
Por otro, se proporcionan un mecanismo de retrollamada (ReaderListener) para la notificación

de los cambios de estado del lector de huellas, como son:
onConnecting, inicio del proceso de conexión con el dispositivo.
onReaderConnected, conexión con el dispositivo realizada.
onConnectionFailed, fallo en la conexión con el dispositivo.
onReaderDisconnected, desconexión con el dispositivo realizada.
onFingerprintsReading, Inicio del proceso de lectura de huella.
onFingerprintsRead, lectura de huellas realizada.
onFingerprintsReadFailed, lectura de huellas fallida.
Se desarrollara una implementación específica de este API para el lector Bluefin.
3.2.6. Módulo Principal
El módulo principal de la solución proporciona la interfaz completa de usuario a través de

una aplicación Android que permitirá las siguientes acciones.
Selección de modo de lectura
En primer lugar, el usuario, típicamente un agente de las fuerzas y cuerpos de seguridad

del estado, tendrá que elegir qué modo de lectura desea para el documento que quiere verificar.
Según todo lo descrito hasta ahora, se proporcionarán 3 posibilidades:
Lectura mediante un lector de tarjetas ICC conectado al móvil a través de USB OTG de
un DNIe.
Lectura por OCR de la MRZ para documentos MRTD.
Introducción manual del número del documento, fecha de nacimiento y fecha de caducidad,
datos necesarios para el BAC, también para documentos MRTD.
Una vez elegida la opción deseada, se iniciarán los procesos de verificación y lectura del
documento, realizándose primero las verificaciones de seguridad correspondientes y a continuación
accediendo a todos los datos disponibles.
Verificación y acceso
En el caso de los documentos MRTD se realizarán las comprobaciones correspondientes, como

ya se explicó en la sección 2.1.3, por el siguiente orden:
Basic Access Control (BAC), que da acceso a los datos básicos de la MRZ, a la imagen
facial y a la firma manuscrita, si es que existe.
Extended Access Control (EAC), si es que está presente en el documento, que da

acceso a las imágenes dactilares. En este proceso intervendrán los sistemas policiales de
inspección de documentos para proporcionar las claves y certificados necesarios en función
de la jerarquía CVCA correspondiente, que se consumirán a través del API descrito en el
apartado 3.2.2. Adicionalmente se podrán configurar almacenes de certificados locales en el
dispositivo para CVCAs de test.
Passive Authentication (PA), que verifica la autenticidad del pasaporte a través de

la jerarquía Country Signing Certification Authority (CSCA) de certificados X.509. Para
este proceso se comprobará si se confía en los certificados presentados a través, primero de
almacenes locales de la aplicación, y en segundo lugar a través de los sistemas policiales ya
mencionados una vez más consumidos a través del API InspectionService descrito en el
apartado 3.2.2.
Active Authentication (AA), si es que está presente en el documento, que verifica la

autenticidad del chip.
En el caso del DNIe se trata de establecer un canal administrativo con la tarjeta a través del
servicio policial correspondiente. El solo hecho de establecer dicho canal ya garantiza mutuamente
la autenticidad de la tarjeta y del sistema de lectura.
Lectura de datos personales y biométricos
Tras la verificación del documento y habiendo obtenido los datos, se mostrará el resultado de
las distintas verificaciones y se presentarán los datos extraídos del documento incluidos, si son
accesibles y están presentes en el documento, fotografía facial, huella dactilar y firma manuscrita.
En el caso concreto del DNIe, se mostrará también información relacionado con los certificados
X.509 de firma y autenticación.
Verificación Policial
Con toda la información validada, extraída y presentada al usuario, se procederá a utilizar

los datos del documento y el titular para comprobar señalamientos policiales verificándolos con
dos sistemas externos al efecto:
Señalamientos del documento: Se comprobará si el documento tiene señalamientos poli-

ciales, por ejemplo extravío o robo. Para este proceso se empleará el API descrita en el
apartado 3.2.3.
Señalamientos del titular: Se comprobará si el titular tiene señalamientos policiales, por

ejemplo órdenes de búsqueda y captura. Para este proceso se empleará el API descrita en
el apartado 3.2.4.
Se mostrará la información obtenida al usuario.
Captura facial
Adicionalmente, se podrán realizar verificaciones biométricas faciales si se pudieron cargar

o utilizar los elementos correspondientes en el documento, a través de la cámara trasera del
dispositivo.
Obtención de huellas
Igualmente se podrán realizar verificaciones biométricas dactilares a través de la interfaz

correspondiente. En este caso se empleará el API descrito en el apartado 3.2.5 como interfaz de
comunicación con el lector de huellas.
Configuración
Para gestionar todos los parámetros de configuración (URLs de servicios, usuarios, contraseñas,
parámetros del lector de huellas, configuraciones de seguridad, etcétera) existirá en la aplicación
una zona de configuración al efecto.
Capı́tulo 4
Implementación y pruebas
En este capítulo se describen las herramientas y componentes utilizados, las características

del sistema resultante, los aspectos de eficiencia y rendimiento, los mecanismos de calidad de
código y pruebas unitarias utilizadas y todas las cuestiones relacionadas con la implementación
efectiva del proyecto.
4.1. Herramientas
Para el desarrollo del proyecto se han empleado las siguientes herramientas y tecnologías:
Todo el desarrollo de la aplicación se basa en Java y en muchos de sus complementos y

librerías.
La aplicación se desplegará en dispositivos móviles que utilizan el sistema Android [24].
El desarrollo de la aplicación se ha realizado utilizando el IDE Eclipse junto con Android

Development Tools (ADT) que permite la integración con Android.
Para la gestión de dependencias y librerías, así como para la generación de entregables y

empaquetamiento, se ha utilizado Maven.
Para el control de versiones de los diferentes elementos se ha empleado Subversion.
Se ha realizado un importante esfuerzo en el control de la calidad del código a través de las

siguientes herramientas:
• PMD para el análisis de eficiencia y calidad del código [25].
55
56 CAPÍTULO 4. IMPLEMENTACIÓN Y PRUEBAS
• Checkstyle (CS) para el control, estandarización, documentación y mejora de la

calidad del código [26].
• JUnit para la realización de test unitarios [27].
• Cobertura para el control de cobertura de los tests unitarios [28].
A parte de todo lo señalado anteriormente, cabe destacar el uso de una serie de herramientas
relacionadas con LATEX [29] para la redacción de esta memoria:
MiKTEX, aplicación de seguimiento para TEX/LATEX y otros programas relacionados de

Windows, en su versión 2.9, que se ha utilizado para la construcción de la memoria a partir
de los ficheros TEX [30].
TEXnicCenter, IDE de Código Abierto que integra la funcionalidad para crear, escribir,
corregir, ver e imprimir documentos LATEX, en su versión 2.02, que se ha utilizado para la
edición de los ficheros TEX [31].
JabRef, gestor de referencias bibliográficas BibTEX de Código Abierto, en su versión 2.10,

para la gestión de referencias [32].
4.2. Librerías de terceros
Para implementar la solución se ha recurrido a librerías de Código Abierto y a algunas

librerías con licencia que se enumeran a continuación.
jMRTD, implementación Java de Código Abierto de los estándares MRTD de ICAO. Esta
librería permite leer, decodificar, y validar la información de los pasaportes, si bien se han
sobrescrito ciertos comportamientos para la realización de los mecanismos de seguridad que
dependen de sistemas externos (PA y EAC descritos en la sección 2.1.3) [33]. Esta librería
emplea a su vez SCUBA para el acceso a las tarjetas Smart Card (SC) [34].
tess-two, desarrollo realizado a partir de Tesseract para el procesamiento de imágenes

con OCR y la extracción de la MRZ. Esta librería emplea a su vez la librería Leptonica
como parte del procesamiento y análisis de imágenes [35–37]. Algunos de los elementos de
la librería se han realizado en código nativo y exigen el uso de la Android NDK.
4.3 Implementación final 57
Neuro SDK, conjunto de librerías comerciales que permiten la realización de extracciones

de plantillas y cotejos biométricos, tanto dactilares como faciales [38]. Se utiliza el Android
NDK en varios de los elementos de este conjunto de librerías.
slf4j ylog4j, librerías utilizadas para la gestión de trazas de la aplicación [39, 40].
jmulticard (DNIDroid Inteco), librería que encapsula los accesos al DNIe modelándolo
como un proveedor de seguridad de Java JCA [41].
KSoap2-android para gestionar las llamadas y respuestas a Web Services SOAP [42].
Esta librería se emplea junto con Simple XML que se encarga de la serialización y
deserialización de XML.
Spongy Castle para realizar las tareas criptográficas, firmas, hashes y en general cualquier
acción relacionada con la Java Cryptography Extension (JCE).
4.3. Implementación final
A continuación se detallan las peculiaridades de la implementación final de la solución con

figuras explicativas de la aplicación real.
4.3.1. Selección de modo de lectura
Inicialmente se presenta al usuario una pantalla en la que elegir qué modo de lectura desea para
el documento que quiere verificar. Según todo lo descrito en el apartado 3.2.6, se proporcionarán
3 posibilidades que se pueden ver en la figura 4.1:
Lectura mediante un lector de tarjetas ICC conectado al móvil a través de USB OTG de
un DNIe.
Lectura por OCR de la MRZ para documentos MRTD.
Introducción manual del número del documento, fecha de nacimiento y fecha de caducidad,
datos necesarios para el BAC, también para documentos MRTD.
Si se selecciona la opción de MRZ, se activara la cámara y se mostrará una pantalla de

captura. Se repetirá la captura mientras no se tenga una lectura nítida como se ve en la figura 4.2
Figura 4.1: Selección de modo de lectura
hasta que se produzca una lectura correcta por OCR de los datos como la de la figura 4.3. El
proceso para cada lectura será:
1. Captura de la imagen a través de la cámara.
2. Recorte de la zona marcada para la selección de la MRZ.
3. Conversión a blanco y negro con un filtro que elimine todos los colores que no sean negro o
próximos al negro (es decir, que los componentes de color rojo verde y azul sean pequeños
y muy poco diferentes).
4. Aumento del contraste para resaltar las zonas de caracteres.
5. Eliminación de márgenes izquierdo, inferior y derecho para descartar las zonas que pudieran
pasar el primer recorte y que estén fuera del propio documento.
6. Procesamiento OCR con diccionario OCR-B. El resultado se analiza y procesa de la siguiente

manera:
a) Se elimina cualquier carácter de espacio en blanco, tabulación, línea en blanco o

retorno de línea.
b) Se elimina cualquier línea con una longitud menor al mínimo de línea para los tipos
de MRZ admitidos.
c) Se completan con caracteres de relleno las líneas que no llegan al tamaño de la máxima
línea encontrada.
d) Se comprueba que la longitud sea válida, es decir que sea de 88 caracteres para las
MRZ tipo ID3 de 2 líneas de los MRTDs o de 90 caracteres para las MRZ tipo ID1 de
3 líneas de los DNIe y que los dígitos de control de la MRZ sean correctos [1]. En caso
negativo, se vuelve a realizar el proceso con una nueva captura.
Figura 4.2: Intento de captura de MRZ Figura 4.3: Captura de MRZ correcta
Con los datos necesarios, ya sea MRZ, datos manuales de BAC o de manera directa para el
DNIe, se comenzará la verificación y lectura del documento.
4.3.2. Verificación lógica, acceso y verificación policial
En el siguiente paso, la aplicación desencadenará todo el proceso de verificación realizando

las comprobaciones correspondientes, como ya se explicó en las secciones 2.1.3 y 3.2.6 empleando
para ello la implementación adecuada del API InspectionService descrita en el apartado 3.2.2.
En cuanto se disponga de los datos pertinentes, se tratará paralelamente de realizar las
verificaciones policiales comentadas, a través de las implementaciones específicas de las APIs
DSQService y CRService descritas en los apartados 3.2.3 y 3.2.4. Todos los datos se irán mostrando
en pantalla de manera secuencial en cuanto estén disponibles, como se ve en la figura 4.4. Cuando
todas las verificaciones y datos estén leídos se mostrarán en pantalla como en la figura 4.5. Entre
los datos se mostrarán:
Zona de verificaciones y estado del documento (figura 4.5 y 4.8).

Datos de verificación del documento.
Datos de verificación policial.
Datos de verificación biométrica (cuando se haya producido alguna).
Figura 4.4: Proceso de verificación de MRTD Figura 4.5: Resultado de verificación de MRTD
Zona de datos (figura 4.6 y 4.9).
Datos del DG1 o datos filiación del DNIe.
Imagen facial.
Imagen dactilar (o imagen esquemática si no es accesible como en el DNIe).
Imagen de huella manuscrita si está disponible.
Acceso al detalle de certificados de usuario en el caso del DNIe.
En la pantalla de resultados se podrá pulsar para observar el detalle en caso de haberse

detectado algún tipo de señalamiento para el titular o el documento correspondiente. Un detalle
de señalamiento se puede ver en la figura 4.7.
En el caso concreto de tratarse de un DNIe, se mostrará de manera sencilla el estado de
verificación del documento y las comprobaciones policiales similares a las de los documentos
MRTD, vistos en la figura 4.8.
Se puede apreciar en la figura 4.9 cómo se mostrarán la firma manuscrita y un enlace en
la parte inferior derecha, junto a la MRZ que permitirá ver un detalle de los certificados de
autenticación y firma del usuario. La huella mostrada será una representación esquemática, ya
que la imagen no es extraíble y la verificación biométrica se realiza mediante un proceso de
Match-On-Card.
Figura 4.6: Representación de datos de MRTD Figura 4.7: Resultado con señalamiento policial
Figura 4.8: Resultado de verificación del DNIe Figura 4.9: Representación de datos del DNIe
4.3.3. Biometría
Captura facial
En caso de estar disponibles los elementos de verificación facial en el documento, típicamente

la fotografía frontal del titular. Al pulsar sobre la foto se podrán ver dichos elementos (si es
que hubiera varios) y una nueva pulsación lanzará la captura de la imagen facial a través de la
cámara trasera del dispositivo.
La captura se realizará hasta obtener una imagen clara, como se ve en la figura 4.10. Una vez
obtenida una imagen con suficiente calidad, se realizará el cotejo con los elementos biométricos
del documento y se informará de la coincidencia o de su ausencia. Un ejemplo de coincidencia
facial se ve en la figura 4.11.
Figura 4.10: Intento de captura facial Figura 4.11: Captura facial satisfactoria
Obtención de huellas
Al igual que en la captura facial, en caso de estar disponibles y ser accesibles las huellas del
documento, se podrá pulsar sobre la imagen correspondientes para ver las huellas disponibles y
pulsar una segunda vez para realizar la captura a través del lector de huellas Bluefin descrito en
el apartado 3.1.2.
Para este proceso se utilizará la implementación correspondiente del API FingerprintReader
descrito en el apartado 3.2.5 como interfaz de comunicación con el lector de huellas. La aplicación
guiará el proceso del usuario desde la elección del lector de huellas hasta la captura final como se
ven en las figuras 4.12, 4.13 y 4.14.
Los resultados de verificación biométrica, tanto facial como dactilar, podrán verse en la
pantalla de resumen de estado o en la de datos del documento, como se ve en las figuras 4.15
y 4.16.
4.3.4. Configuración
Para gestionar todos los parámetros de configuración (URLs de servicios, usuarios, contraseñas,
parámetros del lector de huellas, configuraciones de seguridad, etcétera) existe en la aplicación
una pantalla al efecto accesible desde la barra de acciones de la pantalla de bienvenida. Una
captura se puede ver en la figura 4.17.
4.4 Calidad de código 63
Figura 4.12: Selección de lector Figura 4.13: Solicitud de huella Figura 4.14: Recuperación de
de huellas huella
Figura 4.15: Verificación Figura 4.16: Verificación Figura 4.17: Pantalla de

biométrica en pantalla de estado biométrica en pantalla de datos configuración
4.4. Calidad de código
Todas las librerías desarrolladas se han validado con las herramientas de calidad de código
PMD, para el análisis de eficiencia y calidad del código y Checkstyle (CS) para el control,
estandarización, documentación y mejora de la calidad del código, superando todas las validaciones
con el 100 % de éxito. Se han utilizado para dicha validación las reglas definidas en los apéndices A y
B cuya utilización se detalla más adelante en esta sección. Además se ha realizado una verificación
de cobertura de código con la herramienta Cobertura sobre el módulo de utilidades comunes,
cuyos resultados están presentes en el apéndice D
4.4.1. Reglas PMD
Reglas PMD comunes
Estas reglas se definen como restricciones comunes para cualquier tipo de librería ((ver
apéndice A.1)). Se han aplicado a los siguientes módulos:
Módulo de utilidades comunes descrito en el apartado 3.2.1.
Módulo del API de inspección descrito en el apartado 3.2.2 junto con la librería cliente
específica para el servicio policial correspondiente y el conector de implementación de dicha
librería con la API.
Módulo del API de señalamientos policiales descrito en el apartado 3.2.4 junto con la librería
cliente específica para el servicio policial correspondiente y el conector de implementación
de dicha librería con la API.
Módulo del API de estado de documentos descrito en el apartado 3.2.3 junto con la librería
cliente específica para el servicio policial correspondiente y el conector de implementación
de dicha librería con la API.
Reglas PMD específicas de Android
Se han definido reglas específicas en función de las peculiaridades del framework de Android
(ver apéndice A.1) que se han aplicado al módulo principal de la aplicación, el componente
Android MRTDVerifier, que incluye el API de lector de huellas dactilar descrita en 3.2.5 y que
integra todo el resto de componentes y librerías mencionadas a lo largo de este capítulo.
4.4.2. Reglas de Checkstyle
Se han definido restricciones comunes para cualquier tipo de librería (ver apéndice B.1) que
se han aplicado a todos los módulos ya mencionados, a saber:
Módulo de utilidades comunes.

4.5 Pruebas y tests 65
Módulo del API de inspección descrito, librería cliente y conector.
Módulo del API de señalamientos policiales, librería cliente y conector.
Módulo del API de estado de documentos, librería y conector.
Modulo principal Android de la aplicación.
4.5. Pruebas y tests
Se han realizado tests unitarios con la herramienta JUnit en todas las librerías desarrolladas
en el proyecto. Como muestra se incluye en el apéndice C el informe de ejecución de los tests de
JUnit de la librería de utilidades comunes.
Además, se ha utilizado la herramienta Cobertura también para dicha librería, con el resultado
que se ve en el apéndice D.
Capı́tulo 5
Presupuesto del proyecto
En este capítulo se justifican los costes de la realización de este proyecto. Se detallan los
costes en gastos de personal, de material, indirectos y en general todos los gastos derivados del
proyecto.
Al haber sido suprimidos por ley los baremos orientativos de honorarios que tradicionalmente
venían publicando los Colegios Profesionales para alinearse con las directivas europeas, actual-
mente los honorarios son libres y responden al libre acuerdo entre el profesional y su cliente [43].
Debido a esto se ha realizado un cálculo razonable basado en [44]:
Costes directos del ingeniero y de sus colaboradores. Se tiene que considerar el coste de las
horas de todos los integrantes del equipo de trabajo y las empleadas en trabajos técnicos y
las visitas a realizar.
Viajes, dietas, mecanografía, reproducción y encuadernación, etcétera imputables al trabajo

encomendado.
Porcentaje del total del año de gastos generales que se repercuten a cada trabajo concreto
como los derivados de impuestos del trabajo personal, alquiler de local, amortización de
equipos, seguridad social, intereses de préstamos, etcétera.
Derechos de visado y tasas administrativas si procede (Ministerio, Jefatura, Ayuntamiento,

etcétera).
Para la realización del presupuesto, los costes se expresan en Euros (C) y las cantidades
calculadas se han redondeado a las centésimas.
67
68 CAPÍTULO 5. PRESUPUESTO DEL PROYECTO
5.1. Costes de personal
En la tabla 5.1 se muestran las fases del proyecto y el tiempo aproximado para cada una de
ellas.
Fase 1 Documentación 400 horas

Fase 2 Desarrollo del software 400 horas
Fase 3 Redacción de la memoria del proyecto 200 horas
Total 1 000 horas
Tabla 5.1: Fases del Proyecto
De los datos se desprende que el tiempo total dedicado por el proyectando ha sido de 1 000
horas, de las cuales aproximadamente un 20 % han sido compartidas con el tutor del proyecto
(200 horas), por lo que el total asciende a 1 200 horas.
Estas horas se han dedicado al proyecto durante un periodo completo aproximado de 9 meses.
Para calcular el coste de personal se pueden utilizar como referencia las bases y tipos de
cotización de 2015 de la seguridad social que se ven en la tabla 5.2.
Grupo Categoría Profesional Bases mínimas Bases máximas Base media

1 Ingenieros y Licenciados 1 056,90 C/mes 3 606,00 C/mes 2 331,45 C/mes
2 Ingenieros Técnicos 876,60 C/mes 3 606,00 C/mes 2 241,30 C/mes
Tabla 5.2: Cotizaciones 2015 [45]
A partir de los datos de cotizaciones se puede inferir una media de 2 331,45 Cal mes para
ingenieros y licenciados y de 2 241,30 C al mes para ingenieros técnicos. Si suponemos 22 días
laborables al mes con jornadas de 8 horas, podremos considerar unas 176 horas al mes. Así
obtendríamos 13,25 C por hora para ingenieros y licenciados y de 12,73 C por hora para ingenieros
técnicos.
Para el cálculo completo del coste de personal será necesario añadir a las tasas de gasto bruto
del personal, los cálculos de gasto en seguridad social del empleado en función de los datos de la
tabla 5.3, el gasto en formación profesional en función de la tabla 5.4 y el gasto por desempleo
en función de la tabla 5.5.
5.1 Costes de personal 69
Contingencias Empresa Trabajadores Total

Comunes 23,60 % 4,70 % 28,30 %
Horas Extraordinarias Fuerza Mayor 12,00 % 2,00 % 14,00 %
Resto Horas Extraordinarias 23,60 % 4,70 % 28,30 %
Tabla 5.3: Tipos de cotización [45]
Empresa Trabajadores Total

Formación profesional 0,60 % 0,10 % 0,70 %
Tabla 5.4: Costes de formación profesional [45]
Desempleo Empresa Trabajadores Total

Tipo General 5,50 % 1,55 % 7,05 %
Contrato duración determinada Tiempo Completo 6,70 % 1,60 % 8,30 %
Contrato duración determinada Tiempo Parcial 6,70 % 1,60 % 8,30 %
Tabla 5.5: Bases de cotización al desempleo [45]

A partir de estos datos se ha establecido una tarifa de 12,73 C/hora para el proyectando y
de 13,25 C/hora para el tutor. Considerando que las horas empleadas son horas ordinarias y que
los contratos son de tipo general, el cálculo completo de gastos en personal quedaría como se
refleja en la tabla 5.6.
Proyectando 1 000 horas 12,73 C/hora 12 734,66 C

Cotización a la SS 28,30 % 3 603,91 C
Gastos de formación 0,70 % 89,14 C
Cotización al desempleo 7,05 % 897,79 C
Tutor 200 horas 13,25 C/hora 2 649,38 C
Cotización a la SS 28,30 % 749,77 C
Gastos de formación 0,70 % 18,55 C
Cotización al desempleo 7,05 % 186,78 C
Coste total en personal 20 929,98 C
Tabla 5.6: Coste de personal
De todo lo anterior, se desprende que el coste de personal se sitúa en 20 929,98 C.
5.2. Costes de licencias
Para el desarrollo del proyecto se han empleado principalmente librerías y tecnologías de

Código Abierto con una excepción, las librerías de cotejo facial y dactilar de NEURO Technology
[38]. Los precios de sus licencias, para un número entre 1 y 9, se presentan en la tabla 5.7.
5.3 Costes de equipamiento 71
Tipo de licencia Coste

Embedded Face Extractor 9 C
Embedded Face Client 27 C
Embedded Face Matcher 11 C
Embedded Fingerprint Extractor 13 C
Embedded Fingerprint Client 45 C
Embedded Fingerprint Matcher 17 C
Coste total en licencias 122 C
Tabla 5.7: Costes de licencias NEURO [46, 47]
5.3. Costes de equipamiento
En la tabla 5.8 se recogen los costes de equipamiento utilizados para la realización del proyecto.
Equipamiento Coste Amortización Uso Imputable

Portátil HP EliteBook 8460p 1 000 C 36 meses 9 meses 250,00 C
Samsung Galaxy S3 300 C 24 meses 9 meses 112,50 C
Lector de huellas Bluefin 300 C 36 meses 9 meses 75,00 C
Minilector pocket USB SC 36 C 48 meses 9 meses 6,75 C
Coste total en equipamiento 444,25 C
Tabla 5.8: Costes de equipamiento
De estos datos se desprende que el gasto total en equipamiento fue de 444,25 C.
5.4. Costes en bienes fungibles
El coste computable al proyecto en material fungible se refiere esencialmente a la impresión

de las diferentes copias de la memoria así como otros gastos básicos en material de papelería.
Se concluye que el gasto total en bienes fungibles fue de 220,00 C.
Concepto Importe
Impresión de memorias 200,00 C
Gastos en papelería 20,00 C
Coste total 220,00 C
Tabla 5.9: Costes en bienes fungibles
5.5. Costes indirectos
Se considerarán como costes indirectos del proyecto aquellos relacionados con el gasto de luz,
la conexión a Internet, y los desplazamientos realizados. El cálculo de estos costes resulta difícil
de cuantificar debida a la elevada volatilidad en los precios. Aún así, se establece una estimación
razonable en la tabla 5.11. Para estas estimaciones se ha considerado:
Para el cálculo de consumos, como se apuntó anteriormente, se considerarán jornadas de 8

horas durante 22 días al mes, es decir, 176 horas al mes.
Para el coste en desplazamientos se ha considerado un gasto aproximado de 10 C por

desplazamiento con 1 desplazamiento mensual de media.
El cálculo de coste por hora del resto de gastos indirectos se realiza en la tabla 5.10.
Una vez más, se considera un periodo de 9 meses de duración de proyecto.
Concepto Coste Mensual Coste por hora

Conexión Internet 40 C 0,06 C/hora
Luz 20 C 0,03 C/hora
Tabla 5.10: Cálculos de precio por hora de costes indirectos

5.6 Costes totales 73
Concepto Coste Meses de uso Horas de uso Imputable

Conexión Internet 0,06 C/hora 9,00 meses 1 584,00 horas 88,00 C
Luz 0,03 C/hora 9,00 meses 1 584,00 horas 44,00 C
desplazamientos 10,00 C/mes 9,00 meses - 90,00 C
Coste total indirecto 222,00 C
Tabla 5.11: Presupuesto indirecto
5.6. Costes totales
A partir de estos datos, el presupuesto total es el mostrado en la tabla 5.12 considerando un

IVA del 21 %.
Concepto Importe sin IVA Importe con IVA (21 %)

Costes de personal 20 929,98 C 25 325,27 C
Costes de licencias 122,00 C 147,62 C
Costes de material 444,25 C 537,54 C
Costes en fungibles 220,00 C 266,20 C
Costes indirectos 222,00 C 268,62 C
Coste total 21 151,98 C 26 545,26 C
Tabla 5.12: Presupuesto total
Finalmente, se desprende de los datos anteriores que el coste total del proyecto ha sido de
26 545,26 C después de impuestos.
Capı́tulo 6
Conclusiones
Cabe destacar, tras la elaboración del proyecto y de esta memoria que los documentos
de identificación personal y de tránsito de personas han evolucionado en los últimos años, de
manera paralela a la revolución tecnológica de los Smartphones, permitiendo la automatización
de procesos sin intervención humana de maneras difícilmente imaginables hace 20 años.
Esta evolución junto con la vertiginosa reducción del tamaño y precio, la mejora de las
prestaciones y fiabilidad de periféricos antes en manos de muy pocos y el asentamiento y mejora
de fiabilidad de múltiples tecnologías inalámbricas (NFC, Wi-Fi, Bluetooth) permite imaginar
escenarios casi futuristas en los que las autoridades del estado o cualquier otro usuario autorizado
tiene al alcance de su bolsillo la posibilidad de identificar o identificarse de forma rápida, segura
y fiable, accediendo a sistemas centralizados.
Las ideas comentadas y este proyecto abren una puerta a soluciones e ideas variadas, que se
comentan a continuación.
6.1. Trabajo futuro
Siguiendo los avances de ICAO en el desarrollo y mejora de MRTD, aparece la necesidad de

soportar, como alternativa al BAC, un nuevo mecanismo de control de acceso llamado PACE
[48, 49]. Si bien las últimas actualizaciones de la librería jMRTD añaden funcionalidad
relacionada con PACE, sería interesante revisar dichos avances y adecuarlos a la solución
propuesta.
Tras la actualización del DNIe a su versión 3.0 se extiende igualmente su comportamiento
75
76 CAPÍTULO 6. CONCLUSIONES
alineado con los estándares MRTD de ICAO, y añadiendo también el mecanismo de control
de acceso PACE [48, 50]. Sería pertinente extender la solución para soportar esta nueva
capacidad.
Una mejora notable a la solución planteada sería la adición de mecanismos de verificación

física de elementos como marcas de agua, tintas infrarrojas o ultravioletas, etcétera. Esta
mejora exigiría un importante trabajo desde el punto de vista de carga en la aplicación a
través de un repositorio interno o algún servicio de los patrones en formatos estandarizados,
así como un avance a nivel hardware para incluir cámaras con filtros de infrarrojos y/o
ultravioletas, o bien en futuros dispositivos que soporten dichos filtros en cámaras embebidas
en el dispositivo o en cámaras externas que se comunicaran con el dispositivo a través de
Bluetooth/USB).
La evolución de la tecnología Android es vertiginosa y aporta sistemáticamente mejoras y

nuevos mecanismos para la optimización de sus aplicaciones, así como mejoras visuales y
de experiencia de usuario. En este sentido, y con la reciente liberación de la versión 5.0
de Android junto con la guía de estilos Material Design [51, 52], una posible mejora sería
la optimización de los procesos asíncronos o con alta carga de CPU así como una mejora
visual aplicando las guías de estilos Material Design.
Acrónimos
#|A|B|C|D|E|G|H|I|J|L|M|N|O|P|R|S|T|U|V|W|X
2D Dos Dimensiones. 39, 91
3D Tres Dimensiones. 39, 87, 91
AA Active Authentication. 25, 28, 29, 40, 41, 52
ABC Automatic Border Control. Ver: ABC System
AC Autoridad de Certificación. 46
ADT Android Development Tools. 39, 55, 77, Ver: Android Development Tools
AES Advanced Encryption Standard. 43, 77, Ver: Advanced Encryption Standard
API Application Programming Interface. 12, 38, 45, 47–51, 53, 59, 62, 64, 65, 77, 83, 86, 91,
Ver: Application Programming Interface
APK Application Package File. 77, 84, Ver: Application Package File
ASCII American Standard Code for Information Interchange. 77, 91, Ver: American Standard
Code for Information Interchange
77
78 Acrónimos
BAC Basic Access Control. 10, 25, 26, 29, 35, 39–42, 52, 57, 59, 75, 89
CA Chip Authentication. 29
CAR Certification Authority Reference. 31, 46, 78, Ver: Certification Authority Reference
CBEFF Common Biometric Exchange Formats Framework. 35, 36, 88, Ver: CBEFF NISTIR
6529-A
CHR Certification Holder Reference. 46, 78, Ver: Certification Holder Reference
CRL Certificate Revocation List. 10, 26, 47, 78, 92, Ver: Certificate Revocation List
CS Checkstyle. 10, 56, 63, 64, 78, 113, Ver: Checkstyle
CSCA Country Signing Certification Authority. 10, 15, 26–28, 35, 41, 47, 52, 78, Ver: Country
Signing Certification Authority
CV Card Verificable. 34, 78, Ver: Card Verificable
CVC Country Verifying Certificate. 46, 78, Ver: Country Verifying Certificate
CVCA Country Verifying Certificate Authority. 15, 30, 31, 41, 52, 78, Ver: Country Verifying
Certificate Authority
CVEAC Card Verifiable Extended Access Control. 10
DG Data Group. 23–26, 28, 29, 35, 36, 39–41, 60, 78, Ver: Data Group
DGP Dirección General de Policía. 34, 92
DH Diffie-Hellman. 10, 29, 32, 78, 87, Ver: Diffie-Hellman
DNI Documento Nacional de Identidad. 31, 32

Acrónimos 79
DNIe Documento Nacional de Identidad electrónico. 9, 11, 20, 31–36, 41, 42, 51, 52, 57, 59–61,
75, 78, 88, 92, Ver: Documento Nacional de Identidad electrónico
DOM Document Object Model. 44, 79, Ver: Document Object Model
DS Document Signer. 28, 35, 79, Ver: Document Signer
DSA Digital Signature Algorithm. 9, 79, Ver: Digital Signature Algorithm
DVCA Document Verifier Certificate Authority. 30, 31, 79, Ver: Document Verifier Certificate
Authority
EAC Extended Access Control. 25, 29, 31, 35, 36, 40, 41, 45, 46, 52, 56, 85–87
ECC Elliptic Curve Cryptography. 87, Ver: Criptografía de Curva Elíptica
ECDH Elliptic Curve Diffie-Hellman. 29, 79, Ver: Elliptic Curve Diffie-Hellman
EDIS Electronic Document Inspection System. 35
EF Elemental File. 23–25, 31, 79, Ver: Elemental File
GPL GNU General Public License. 37, 79, 89, Ver: GNU General Public License
HSM Hardware Security Module. 34, 79, Ver: Hardware Security Module
ICAO International Civil Aviation Organization. 19, 20, 23, 25, 26, 28, 30, 56, 75, 76, 89, 90,
92, Ver: ICAO
ICC Integrated Circuit Card. 9, 20, 32, 34–36, 41, 42, 51, 57, 79, 81, 88, 90, 92, Ver: Integrated
Circuit Card
80 Acrónimos
IDE Integrated Development Enviroment. 39, 55, 56, 79, 83, 84, 86, Ver: Integrated Development
Enviroment
IFD Interface Device. 34, 79, Ver: Interface Device
IS Inspection System. 30, 31, 46, 79, Ver: Inspection System
IVA Impuesto sobre el Valor Añadido. 73, 80, Ver: Impuesto sobre el Valor Añadido
JAR Java Archive. 80, Ver: Java Archive
JCA Java Cryptography Architecture. 57, 80, Ver: Java Cryptography Architecture
JCE Java Cryptography Extension. 57, 80, Ver: Java Cryptography Extension
JVM Java Virtual Machine. 39, 80, 88, Ver: Java Virtual Machine
LDS Logic Data Structure. 11, 23, 24
LGPL GNU Lesser General Public License. 80, Ver: GNU Lesser General Public License
MAC Message Authentication Code. 26, 89
MRTD Machine Readable Travel Document. 9, 10, 15, 17, 19, 20, 23–26, 28–31, 34–36, 39–42,
46, 52, 56, 57, 59–61, 75, 76, 80, 84–86, 88, 89, 91–93, Ver: Machine Readable Travel
Document
MRZ Machine Readable Zone. 9, 24, 26, 40, 42, 52, 56–60, 80, 89, 91, Ver: Machine Readable
Zone
NDK Native Development Kit. 84
NFC Near Field Communication. 9, 37, 39, 42, 75, 80, Ver: Near Field Communication
Acrónimos 81
NIST National Institute of Standards and Technology. 36, 80, 83, 84, 91, Ver: National Institute
of Standards and Technology
OCR Optical Character Recognition. 9, 40, 42, 52, 56–58, 80, Ver: Optical Character Recognition
PA Passive Authentication. 10, 25, 26, 28, 35, 40, 41, 45, 52, 56
PACE Password Authenticated Connection Establishment. 75, 76, 81, Ver: Password Authenti-
cated Connection Establishment
PIN Personal Identification Number. 32, 81, Ver: Personal Identification Number
PKI Public Key Infrastructure. 25, 30, 81, 92, Ver: Public Key Infrastructure
RFID Radio Frequency IDentification. 9, 81, Ver: Radio Frequency IDentification
RSA Rivest, Shamir y Adleman. 85, Ver: RSA
SAI Servicio de Autenticación de ICC. 35, 81, Ver: Servicio de Autenticación de ICC
SC Smart Card. 56, 71, 92, Ver: Integrated Circuit Card
SDK Software Development Kit. 57, 81, 84, Ver: Software Development Kit
SHA Secure Hash Algorithm. 81, Ver: Secure Hash Algorithm
SO Sistema Operativo. 15, 37
SOAP Simple Object Access Protocol. 57, 81, 90, Ver: Simple Object Access Protocol
SOD Security Object Data. 25, 26, 28, 45–47, 81, 85, Ver: Security Object Data
SPP Serial Port Profile. 43, 81, Ver: Serial Port Profile
82 Acrónimos
SVN Subversion. Ver: Subversion
TA Terminal Authentication. 30
TLS Transport Layer Security. 10, 45, 81, Ver: Transport Layer Security
UE Unión Europea. 25, 29
URI Uniform Resource Identifier. 82, Ver: Uniform Resource Identifier
URL Uniform Resource Locator. 54, 62, 82, Ver: Uniform Resource Locator
USB Universal Serial Bus. 9, 71, 76, 82, 90, 94, Ver: Universal Serial Bus
VGA Video Graphics Array. 39, 82, Ver: Video Graphics Array
W3C World Wide Web Consortium. 82, Ver: World Wide Web Consortium
WSQ Wavelet Scalar Quantization. 36, Ver: WSQ IAFIS IC 0110 Versión 3.1
XML eXtensible Markup Language. 44, 57, 82, 86, 90, 92, 93, Ver: eXtensible Markup Language
Glosario
A|B|C|D|E|G|H|I|J|K|L|M|N|O|P|R|S|T|U|V|W|X
ABC System Sistema automático de control de fronteras que controla el paso de personas en
los principales aeropuertos de España. 20, 77
Advanced Encryption Standard También conocido como Rijndael (pronunciado Rain Doll
en inglés), es un esquema de cifrado por bloques adoptado como un estándar de cifrado
por el gobierno de los Estados Unidos. El AES fue anunciado por el National Institute of
Standards and Technology (NIST) como FIPS PUB 197 de los Estados Unidos (FIPS 197)
el 26 de noviembre de 2001 después de un proceso de estandarización que duró 5 años. Se
transformó en un estándar efectivo el 26 de mayo de 2002. Desde 2006, el AES es uno de
los algoritmos más populares usados en criptografía simétrica [53]. 43, 77
American Standard Code for Information Interchange Código Estándar Estadouniden-

se para el Intercambio de Información, es un código de caracteres basado en el alfabeto
latino, tal como se usa en inglés moderno. Fue creado en 1963 por el Comité Estadounidense
de Estándares (ASA, conocido desde 1969 como el Instituto Estadounidense de Estándares
Nacionales, o ANSI) como una refundición o evolución de los conjuntos de códigos utilizados
entonces en telegrafía. Más tarde, en 1967, se incluyeron las minúsculas, y se redefinieron
algunos códigos de control para formar el código conocido como US-ASCII. 77
Android Sistema operativo basado en el núcleo Linux. Fue diseñado principalmente para
83
84 Glosario
dispositivos móviles con pantalla táctil, como teléfonos inteligentes o tabletas; y también
para relojes inteligentes, televisores y automóviles. Inicialmente fue desarrollado por Android
Inc., empresa que Google respaldó económicamente y más tarde, en 2005, compró [24, 54].
10, 11, 15, 36–39, 41, 42, 51, 55, 64, 65, 76, 83–85, 87, 90, 93
Android Development Tools Plugin para el IDE Eclipse que amplía las capacidades de éste
para que pueda configurar rápidamente nuevos proyectos para Android, crear una interfaz
de usuario de aplicaciones, agregar paquetes basados en la API de Android, depurar
aplicaciones usando el SDK de Android e incluso exportar firmados (o sin firmar) archivos
Application Package File (APK) con el fin de distribuir la aplicación [55]. 55, 77
Android NDK el Native Development Kit (NDK) de Android es un conjunto de herramientas

que permiten implementar partes de una aplicación utilizando lenguajes de código nativo,
como C y C++. Para ciertos tipos de aplicaciones, esto puede ser útil para reutilizar
librerías de código existentes escritas en estos lenguajes [56]. 56, 57
Android Studio IDE oficial para el desarrollo de aplicaciones Android basado en el IDE
IntelliJ-IDEA de JetBrains [57]. 39
Application Package File Formato de paquete para el sistema operativo Android, variante
del formato Java Archive de Java que se usa para distribuir e instalar componentes
empaquetados para la plataforma Android. 77, 84
Application Programming Interface Conjunto de subrutinas, funciones y procedimientos

(o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser
utilizado por otro software como una capa de abstracción. 77
Bluetooth Especificación industrial para Redes Inalámbricas de Área Personal que posibi-
lita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace por
radiofrecuencia. 9, 37, 39, 43, 75, 76, 92
Bouncy Castle Colección de APIs utilizadas en criptografía con versiones para los lenguajes
Java y C#. Nació como resultado del esfuerzo de dos colegas que sufrieron la necesidad
de recrear librerías criptográficas en cada cambio de empleo. La API de bajo nivel está
Glosario 85
optimizada para gestionar eficientemente los algoritmos criptográficos, de forma que se

puedan usar en entornos de bajos recursos o donde no es posible usar las librerías JCE
(por ejemplo en un Applet) [58]. 93
Card Verificable Siglas utilizadas para referirse a un certificado Card Verificable, de acuerdo
a la norma CWA 14890 [10, 11]. 34, 78
CBEFF NISTIR 6529-A Norma desarrollada entre 1999 y 2000 por el Equipo de Desarrollo
de CBEFF (NIST) y el Consorcio BioAPI. Esta norma proporciona la capacidad a diferentes
dispositivos y aplicaciones biométricas para el intercambio de información biométrica entre
componentes del sistema de manera eficiente de una manera común y con un conjunto
elementos de datos obligatorios [59]. 35, 36
Certificate Revocation List Lista de Revocación de Certificados. Es una lista de certificados

(más concretamente sus números de serie) que han sido revocados, ya no son válidos y en
los que no debe confiar ningún usuario del sistema. 78, 92
Certification Authority Reference Referencia que se encuentra dentro de un MRTD para

identificar a la autoridad de certificación [23]. 31, 78
Certification Holder Reference Referencia que se encuentra dentro de un MRTD para iden-
tificar al titular del certificado [23]. 78
Checkstyle Herramienta de desarrollo para ayudar a los programadores escribir código Java que
se adhiere a un estándar de codificación. Automatiza el proceso de comprobación de código
Java. Esto lo hace ideal para proyectos que quieren imponer un estándar de codificación
[26]. 10, 56, 63, 64, 78, 113
Cobertura Cobertura es una herramienta libre de Java que calcula el porcentaje de código
accedido por tests. Se puede utilizar para identificar qué partes de un programa carecen de
cobertura de tests [28]. 10, 56, 64, 65, 125
Código Abierto Expresión con la que se conoce al software distribuido y desarrollado libremente.
Se focaliza más en los beneficios prácticos (acceso al código fuente) que en cuestiones éticas
o de libertad que tanto se destacan en el software libre. 56, 70, 86, 93
86 Glosario
COM Ficheros de un Machine Readable Travel Document que contiene información sobre la
versión y la lista de rótulos. 24, 25
Complejidad ciclomática Métrica del software propuesta por Thomas McCabe en 1976 que se
basa en el diagrama de flujo determinado por las estructuras de control de un determinado
código y que proporciona una medición cuantitativa de la complejidad lógica de un programa.
Es una de las métricas de software de mayor aceptación, ya que ha sido concebida para ser
independiente del lenguaje [60, 61]. 125
Content Commitment Uno de los posibles valores del campo Key Usage de un certificado
X.509 que se determina que el certificado se puede utilizar para garantizar el no repudio
por parte del firmante de los contenidos firmados. 33
Country Signing Certification Authority Autoridades de certificación de firma de países

que emiten los certificados de firma del SOD de los documentos MRTD. 10, 26, 52, 78
Country Verifying Certificate Certificados de la jerarquía Country Verifying Certificate

Authority para la realización del proceso EAC. 78
Country Verifying Certificate Authority Autoridades de certificación de verificación entre

países para el proceso EAC. 30, 78
Criptografía de Curva Elíptica Variante de la criptografía asimétrica o de clave pública

basada en las matemáticas de las curvas elípticas. Sus autores argumentan que la CCE
puede ser más rápida y usar claves más cortas que los métodos antiguos, como RSA, al
tiempo que proporcionan un nivel de seguridad equivalente. 10, 79
Dalvik Máquina virtual especializada, diseñada específicamente para Android y optimizada

para dispositivos móviles que funcionan con batería y que tienen memoria y procesador
limitados [62]. 39
Data Group Diferentes estructuras de datos (ficheros) internos de un MRTD. 78
Elemental File Ficheros elementales que componen las estructuras de datos de un MRTD. 23,
79
Glosario 87
Diffie-Hellman Protocolo criptográfico, debido a Whitfield Diffie y Martin Hellman (autores

también del problema de Diffie-Hellman o DHP), de establecimiento de claves entre partes
que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima. 10,
29, 32, 78, 87
Digital Signature Uno de los posibles valores del campo Key Usage de un certificado X.509 que
se determina que el certificado se puede utilizar para garantizar la identidad del firmante
de los contenidos firmados. 33
Digital Signature Algorithm Estándar del Gobierno Federal de los Estados Unidos de Amé-
rica o FIPS para firmas digitales. 79
Document Object Model API que proporciona un conjunto estándar de objetos para re-
presentar documentos XML, un modelo estándar sobre cómo pueden combinarse dichos
objetos, y una interfaz estándar para acceder a ellos y manipularlos. A través del DOM, los
programas pueden acceder y modificar el contenido, estructura y estilo de los documentos
XML [63]. 44, 79
Documento Nacional de Identidad electrónico Documento emitido por la Dirección Ge-

neral de la Policía de España para permitir la identificación de la población de forma
personal o virtual. 9, 11, 31–33, 78
Document Signer Certificado emitido para un documento MRTD por una CSCA. 79
Document Verifier Certificate Authority Autoridades de certificación intermedias de veri-

ficación de documentos para el proceso EAC. 30, 79
Eclipse Programa informático compuesto por un conjunto de herramientas de programación de

Código Abierto multiplataforma para desarrollar lo que el proyecto llama Aplicaciones de
Cliente Enriquecido, opuesto a las aplicaciones Cliente-liviano basadas en navegadores. Esta
plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados
(del inglés IDE) [64, 65]. 39, 55, 83
Elliptic Curve Diffie-Hellman Protocolo de acuerdo de claves en el anonimato que permite

a dos partes, cada una de ellas con un par de claves de curva elíptica, establecer un secreto
88 Glosario
compartido por un canal inseguro. Este secreto compartido puede ser utilizado directamente
como una clave, o para derivar otra clave que luego puede ser utilizada para cifrar las
comunicaciones posteriores utilizando un sistema de cifrado de clave simétrica. Es una
variante del protocolo Diffie-Hellman usando ECC. 29, 79
eXtensible Markup Language Lenguaje de marcas desarrollado por el World Wide Web
Consortium utilizado para almacenar datos en forma legible. Deriva del lenguaje SGML y
permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a
su vez un lenguaje definido por SGML) para estructurar documentos grandes. 82
GNU General Public License Licencia más ampliamente usada en el mundo del software
que garantiza a los usuarios finales (personas, organizaciones, compañías) la libertad de
usar, estudiar, compartir (copiar) y modificar el software. Su propósito es declarar que el
software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación
que restrinjan esas libertades a los usuarios [66]. 79
GNU Lesser General Public License Licencia de software creada por la Free Software Foun-
dation que pretende garantizar la libertad de compartir y modificar el software cubierto
por ella, asegurando que el software es libre para todos sus usuarios [67]. 80
Google Play Store Es el mercado oficial de productos relacionados con la plataforma Android
que incluye contenidos multimedia, dispositivos y, sobre todo, aplicaciones [68]. 39
Hardware Security Module Dispositivo criptográfico basado en hardware que genera, alma-
cena y protege claves criptográficas y suele aportar aceleración hardware para operaciones
criptográficas. Estos dispositivos pueden aportar funcionalidad criptográfica de clave pública
(PKI) de alto rendimiento que se efectúa dentro del propio hardware. 79
hash Las funciones hash (adopción más o menos directa del término inglés hash function),
funciones resumen o funciones de digest son funciones que tiene como entrada un conjunto
de elementos, que suelen ser cadenas, y los convierte (mapea) en un rango de salida finito,
normalmente cadenas de longitud fija. 26, 28, 57, 88
Glosario 89
HTTP Hypertext Transfer Protocol (en español: Protocolo de transferencia de hipertexto), más
conocido por sus siglas HTTP, es un protocolo de aplicación utilizado de forma generalizada
en Internet para el intercambio de datos. 45, 87
HTTPS Hypertext Transfer Protocol Secure (en español: Protocolo seguro de transferencia de
hipertexto), más conocido por sus siglas HTTPS, es un protocolo de aplicación basado en
el protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir, es
la versión segura de HTTP. 10, 34, 45
ICAO Organización internacional de aviación civil que se encarga de definir los estándares
relacionados con los documentos electrónicos de tránsito. 19, 23, 79
Impresión Rainbow La impresión lenticular o Rainbow es una tecnología, también empleada

en pantallas 3D, mediante la cual se crea una ilusión de profundidad en imágenes impresas,
produciendo la sensación de movimiento, según la imagen es vista desde diferentes ángulos.
Esta tecnología fue creada en la década de 1940, pero ha evolucionado en los últimos años,
mostrando más movimiento y una mayor profundidad [69]. 25
Impuesto sobre el Valor Añadido Carga fiscal sobre el consumo, es decir financiado por el
consumidor, aplicado en muchos países, y generalizado en la Unión Europea. 80
Inspection System Certificados de sistemas de inspección de documentos para el proceso EAC.

31, 79
Integrated Circuit Card Tarjeta de bolsillo con circuitos integrados, que permite la ejecución
de cierta lógica programada. 9, 34, 56, 79, 81, 92
Integrated Development Enviroment Aplicación de software, que provee habilidades com-

prensivas para facilitar al programador el desarrollo de software. Un IDE consiste de un
editor de código fuente, construcción automática, herramientas y mecanismos de depuración
de código. La mayoría de los IDEs tienen auto-completado de código inteligente. 79
IntelliJ-IDEA IDE para el lenguaje Java desarrollado por JetBrains [70]. 84
Interface Device Dispositivo o entidad que pertenece al mundo externo (fuera de la ICC según
el estándar CWA 14890 [10, 11]). 34, 79
90 Glosario
iOS Sistema operativo móvil de la multinacional Apple Inc. Originalmente desarrollado para el
iPhone (iPhone OS), siendo después usado en dispositivos como el iPod touch y el iPad. 36
ISO/IEC 19794-2 Estándar biométrico relacionado con el formato de minucias de huellas

dactilares utilizado para el Match-On-Card en el DNIe [71]. 33, 36
ISO/IEC 19794-4 Estándar biométrico relacionado con el formato de almacenamiento de

imágenes de huellas dactilares utilizado por los documentos MRTD [72]. 36
ISO/IEC 19794-5 Estándar que define específicamente un esquema estándar para la codifica-
ción de datos que describen los rostros humanos dentro de una estructura de datos CBEFF
compatible, para su uso en sistemas de reconocimiento facial utilizado por los documentos
MRTD [73]. 35
Java Lenguaje de programación de propósito general, concurrente, orientado a objetos que

fue diseñado específicamente para tener tan pocas dependencias de implementación como
fuera posible. Su intención es permitir que los desarrolladores de aplicaciones escriban el
programa una vez y lo ejecuten en cualquier dispositivo (conocido en inglés como WORA,
o write once, run anywhere), [74]. 10, 39, 55, 57, 84, 85, 88–90, 92
Java Archive Tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java. 80
Java bytecode Tipo de instrucciones que ejecuta una Java Virtual Machine (JVM), su bytecode.
Suele ser el resultado de utilizar un compilador del lenguaje de programación Java [75]. 39
Java Cryptography Architecture Pieza de la plataforma Java, que contiene una arquitectura
de proveedor y un conjunto de APIs para firmas digitales, hashes, certificados y validación de
certificados, encriptación (simétrica, asimétrica de cifrado de bloque, etcétera), generación
y gestión de claves y generación de números aleatorios, entre otros. Estas APIs permiten a
los desarrolladores integrar fácilmente la seguridad en las aplicaciones [76]. 80
Java Cryptography Extension extensión estándar lanzado oficialmente PARA la Plataforma

Java. JCE ofrece un marco y una aplicación para el cifrado, la generación de claves y el
acuerdo clave y algoritmos de código de autenticación de mensajes. JCE complementa la
Glosario 91
plataforma Java, que ya incluye las interfaces e implementaciones de hashes de mensajes y

firmas digitales [77]. 57, 80
Java Virtual Machine La máquina virtual de Java es un elemento de ejecución específico para
cada plataforma, capaz de interpretar y ejecutar instrucciones expresadas en un código
binario especial (el bytecode Java), el cual es generado por el compilador del lenguaje Java
[75]. 39, 80, 88
jMRTD Librería GPL Java de los estándares MRTD especificados por ICAO. El pasaporte
electrónico (o ePassport) es una implementación de estos estándares [33]. 10, 39, 40, 56, 75,
92
JPEG Formato de archivo y su método de compresión de imágenes definido por el Joint Photo-
graphic Experts Group que utiliza habitualmente un algoritmo de compresión con pérdida
para reducir el tamaño de los archivos de imágenes. Esto significa que al descomprimir o
visualizar la imagen no se obtiene exactamente la misma imagen de la que se partía antes
de la compresión [78]. 35, 39
JPEG 2000 Estándar de compresión y codificación digital de imágenes. Fue creado por el Joint
Photographic Experts Group (Grupo Conjunto de Expertos en Fotografía o JPEG), en
el año 2000 con la intención de sustituir el formato original creado en 1992. El nuevo
formato se basa en la transformada wavelet, en lugar de la transformada de coseno discreta
establecida para el estándar original. La extensión de los archivos en formato JPEG 2000
es .jp2 [78]. 35
JUnit JUnit es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son
utilizadas en programación para hacer pruebas unitarias de aplicaciones Java [27, 79]. 10,
56, 65, 117
𝐾𝐸𝑁 𝐶 Clave simétrica para la encriptación derivada a partir de la MRZ de un MRTD que se
usa junto a la 𝐾𝑀 𝐴𝐶 para el establecimiento del Basic Access Control (BAC). 26, 29, 89
Key Usage Uno de los campos de un certificado X.509 que se utiliza para determinar los
posibles fines para los que se ha emitido dicho certificado. 28, 33, 85, 86
92 Glosario
𝐾𝑀 𝐴𝐶 Clave simétrica para la generación del Message Authentication Code (MAC) que autentica
el canal derivada a partir de la MRZ de un MRTD que se usa junto a la 𝐾𝐸𝑁 𝐶 para el
establecimiento del Basic Access Control (BAC). 26, 29, 89
KSoap2-android Proyecto que proporciona una biblioteca cliente SOAP ligero y eficiente para
la plataforma Android [42]. 10, 57
BibTEX Herramienta y formato de archivo que se utilizan para describir y proceso de listas de
referencias, la mayoría en conjunción con documentos LATEX [80]. 56
LATEX Sistema de preparación de documentos para la composición tipográfica de alta calidad

basado en TEX. Se utiliza con mayor frecuencia para documentos técnicos o científicos de
tamaño mediano y grande, pero se puede utilizar para casi cualquier tipo de publicación.
LATEXestá formado por un gran conjunto de macros de TeX, escrito por Leslie Lamport en
1984 [29]. 56, 90
Leptonica Software y librerías de procesamiento y análisis de imágenes [37]. 56
Machine Readable Travel Document Documento de Viaje de Lectura Mecánica, típicamen-

te un pasaporte o visado electrónico definido en el Documento 9303 de ICAO [1–5]. 9, 23,
80, 85, 92
Machine Readable Zone Zona especial de lectura mecánica en documentos electrónicos. 24,
80
Match-On-Card Es una tecnología que permite el chequeo de una huella dactilar en una llave
USB o ICC. 33, 36, 60, 88
Material Design Es una guía completa para diseño visual, de movimiento y de interacción
transversal a plataformas y dispositivos definida por Google y adoptada por Android a
partir de su versión 5.0 [52]. 76
Maven Maven es una herramienta de gestión de proyectos de software y comprensión. Basado

en el concepto de un proyecto de modelo de objetos (POM), Maven puede gestionar la
Glosario 93
construcción de un proyecto, generación de informes y documentación desde una pieza

central de la información. Se usa frecuentemente para proyectos Java y fue creada por Jason
van Zyl, de Sonatype, en 2002. Es similar en funcionalidad a Apache Ant, pero tiene un
modelo de configuración de construcción más simple, basado en un formato XML [81, 82].
10, 55
minucia En biometría y ciencia forense, son las principales características de una huella digital,
utilizando las cuales se pueden hacer comparaciones entre huellas [83]. 33, 36, 88
National Institute of Standards and Technology El Instituto Nacional de Normas y Tec-

nología llamada entre 1901 y 1988 Oficina Nacional de Normas (NBS por sus siglas del
inglés National Bureau of Standards), es una agencia de la Administración de Tecnología
del Departamento de Comercio de los Estados Unidos. La misión de este instituto es
promover la innovación y la competencia industrial en Estados Unidos mediante avances
en metrología, normas y tecnología de forma que mejoren la estabilidad económica y la
calidad de vida. 36, 80, 83
Near Field Communication Tecnología de comunicación inalámbrica de corto alcance basada

en estándares que permite el intercambio de datos entre dispositivos. Permite interacción
inalámbrica de corto alcance entre la electrónica de consumo, dispositivos móviles, ordena-
dores personales, aparatos eléctricos, y etiquetas compatibles [84]. 9, 80
NISTIR 7151 Estándar del NIST para la determinación de calidad en imágenes de huella
dactilar [85]. 36
OCR-B Fuente de espacio sencillo desarrollado en 1968 por Adrian Frutiger para Monotype
siguiendo el estándar de la European Computer Manufacturer’s Association. Su función era
facilitar las operaciones de reconocimiento de caracteres ópticos por dispositivos electrónicos
específicos. Se ha aceptado como estándar mundial en 1973.Sigue el estándar ISO 1073/II-
1976 (E) estándar, refinado en 1979 (diseño "leterpress", tamaño I). Ha sido creado para
obtener características financieras, bancarias orientadas específicamente. Incluye todos
94 Glosario
los símbolos ASCII, y otros símbolos incluidos en el entorno bancario. Es ampliamente

utilizado, entre otros para las MRZ de los MRTD /citestandard:ISO-1073-II-1976. 58
OpenGL Especificación estándar que define una API multilenguaje y multiplataforma para
escribir aplicaciones que produzcan gráficos 2D y 3D. La interfaz consiste en más de 250
funciones diferentes que pueden usarse para dibujar escenas tridimensionales complejas
a partir de primitivas geométricas simples, tales como puntos, líneas y triángulos. Fue
desarrollada originalmente en 1992 y se usa ampliamente [86]. 39
Optical Character Recognition Proceso dirigido a la digitalización de textos, los cuales

identifican automáticamente a partir de una imagen símbolos o caracteres. 9, 80
Password Authenticated Connection Establishment Mecanismo de control de acceso de

documentos MRTD de última generación que añade seguridad al acceso a los documentos
complementando o sustituyendo el acceso BAC. 81
Personal Identification Number Número de identificación personal utilizado en ciertos sis-

temas, como el teléfono móvil o el cajero automático, o las tarjetas criptográficas para
identificarse y obtener acceso al sistema. 81
PKIX Grupo de trabajo de PKI, comúnmente conocido como PKIX por infraestructura de
clave pública (X.509) o PKIX, que adaptó el estándar X.500 a la estructura más flexible de
Internet. (X.509) incluye también estándares para implementación de listas de certificados
en revocación (Certificate Revocation Lists), y con frecuencia aspectos de sistemas PKI. 10
PMD Analizador de código fuente que permite detectar defectos comunes de programación
como las variables utilizadas, bloques catch vacíos, la creación de objetos innecesarios, y
así sucesivamente. Es compatible con Java, JavaScript, XML y otros [25]. 10, 55, 63, 64, 97
proxy Servidor (un programa o sistema informático), que sirve de intermediario en las peticiones
de recursos que realiza un cliente (A) a otro servidor (C). 45
Public Key Infrastructure Es una combinación de hardware y software, políticas y procedi-

mientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas
como el cifrado, la firma digital o el no repudio de transacciones electrónicas. 81
Glosario 95
Radio Frequency IDentification Sistema remoto de almacenamiento y recuperación de datos

que usa dispositivos denominados etiquetas, tarjetas, transpondedores o tags RFID. 81
RSA En criptografía, RSA (Rivest, Shamir y Adleman) es un sistema criptográfico de clave

pública desarrollado en 1977. Es el primer y más utilizado algoritmo de este tipo y es válido
tanto para cifrar como para firmar digitalmente. 81
SCUBA Framework basado en Java para la programación aplicaciones con acceso a tarjetas
inteligentes ICC. Se separó de proyecto jMRTD y se utiliza en varios otros proyectos de
tarjetas inteligentes Java. SCUBA mejora el API Java de entrada/salida de Smart Card
(SC) con varias características, sobre todo de escucha para los eventos de inserción y
extracción de la tarjeta [34]. 56
Secure Hash Algorithm Familia de funciones hash de cifrado publicadas por el National
Institute of Standards and Technology (NIST). La primera versión del algoritmo fue creada
en 1993 con el nombre de SHA, aunque en la actualidad se la conoce como SHA-0 para
evitar confusiones con las versiones posteriores. 81
Security Object Data Fichero de un Machine Readable Travel Document que contiene infor-
mación sobre integridad y autenticidad de datos. 26, 81
Serial Port Profile Perfil de conexión que define cómo configurar puertos serie virtuales y
conectar dos dispositivos Bluetooth habilitados [87]. 43, 81
Servicio de Autenticación de ICC Aplicativo de la DGP de España, encargado de imple-

mentar, por un lado, la autenticación interna/externa indicada en la norma CWA14890
[10, 11] para los ICC del DNIe entre otros y, por otro lado, la autenticación propietaria del
ICC Pasaporte-e ICAO. 35, 81
Simple Object Access Protocol Protocolo, recomendación del W3C, que proporciona la
definición de información basada en XML que puede ser utilizada para el intercambio de
información estructurada y de tipos concretos entre puntos en un entorno descentralizado
96 Glosario
y distribuido. Se utiliza típicamente para el intercambio de mensajes en un Web Service

[88]. 81
Simple XML Proyecto que proporciona una biblioteca de serialización y deserialiación para
XML, similar a JAXB y compatible con Android [89]. 57
Smartphone Tipo de teléfono móvil construido sobre una plataforma informática móvil, con
una mayor capacidad de almacenar datos y realizar actividades similares a las de un
ordenador personal y con mayor conectividad que un teléfono móvil convencional. 36, 42,
75
Software Development Kit Conjunto de herramientas de desarrollo de software que le permite

al programador crear aplicaciones para un sistema concreto, por ejemplo ciertos paquetes
de software, frameworks, plataformas de hardware, computadoras, videoconsolas, sistemas
operativos, etcétera. 81
Spongy Castle Conjunto de librerías adaptadas a partir de Bouncy Castle con los cambios
necesarios para que funcione en Android [90]. 10, 57
Subversion Herramienta de control de versiones de Código Abierto basada en un repositorio

cuyo funcionamiento se asemeja enormemente al de un sistema de ficheros [91, 92]. 55
Tesseract Motor de OCR de código abierto capaz de leer una amplia variedad de formatos de
imagen y convertirlos a texto en más de 60 idiomas. Fue uno de los 3 mejores motores en la
prueba de precisión 1995 University of Nevada de Las Vegas. Entre 1995 y 2006 había poco
trabajo realizado sobre él, pero desde entonces se ha mejorado ampliamente por Google
[35]. 56, 93
tess-two Rama de Herramientas Tesseract para Android que añade algunas funciones adicionales
[36]. 10, 56
TEX Lenguaje de composición tipográfica desarrollado por Donald Knuth. El texto manuscrito
se introduce entrelazado con comandos de TeX en un archivo de texto plano, en lugar de
formatear visualmente el texto. A continuación, se ejecuta TeX para producir una salida
con formato, como un archivo PDF [93]. 56, 90
Glosario 97
TR-03110 Guía técnica para la implementación de mecanismos de seguridad de los MRTD

[22, 23, 94, 95]. 46
Transport Layer Security En español seguridad de la capa de transporte) y su antecesor

Secure Sockets Layer (SSL; en español capa de conexión segura) son protocolos criptográficos
que proporcionan comunicaciones seguras por una red, comúnmente Internet. 10, 81
UIT-T El UTHH Sector de Normalización de las Telecomunicaciones de la UIT (UIT-T),

con sede en Ginebra (Suiza), es el órgano permanente de la Unión Internacional de
Telecomunicaciones (UIT) que estudia los aspectos técnicos, de explotación y tarifarios, y
publica normativas sobre los mismos, con vista a la normalización de las telecomunicaciones
a nivel mundial. Fue conocido hasta 1992 como Comité Consultivo Internacional Telefónico
y Telegráfico (CCITT). 94
Uniform Resource Identifier Secuencia compacta de caracteres que identifica un recurso

abstracto o físico. La sintaxis URI define una gramática que es un superconjunto de todas
los URIs válidos, lo que permite a una aplicación analizar los componentes comunes de
una referencia URI sin conocer los requisitos del esquema específico de cada identificador
posible [96]. 82
Uniform Resource Locator Es una cadena compacta (una URI) que representa un recurso
disponible a través de Internet. Los recursos referidos por URLs pueden cambiar, esto es,
la dirección puede apuntar a recursos variables en el tiempo [97]. 82
Universal Serial Bus Bus estándar industrial que define los cables, conectores y protocolos
usados en un bus para conectar, comunicar y proveer de alimentación eléctrica entre
computadoras, periféricos y dispositivos electrónicos. 82, 94
USB OTG USB On-The-Go (también conocido por el acrónimo USB OTG y como USB host)
es una extensión de la norma Universal Serial Bus 2.0 que permite a los dispositivos
Universal Serial Bus tener mayor flexibilidad en la gestión de la interconexión, permitiendo
que ciertos dispositivos, por ejemplo: reproductor de audio digital o teléfono móvil, actúen
como host, por lo que se les puede conectar una memoria USB, un ratón, un teclado, un
disco duro, un módem, etcétera. 37, 42, 51, 57
98 Glosario
Video Graphics Array Pantalla de computadora analógica estándar con resolución 640 por
480 píxeles, conector del mismo nombre de 15 contactos y/o tarjeta gráfica comercializada
por IBM por primera vez en 1988. 82
Web Service Conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la

Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer
unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los
usuarios solicitan un servicio llamando a estos procedimientos a través de la Web [98]. 57
Wi-Fi Mecanismo de conexión de dispositivos electrónicos de forma inalámbrica. Los dispositivos

habilitados con Wi-Fi pueden conectarse a Internet a través de un punto de acceso de
red inalámbrica. Dicho punto de acceso tiene un alcance de veinte metros en interiores,
distancia que es mayor al aire libre [99]. 39, 75
World Wide Web Consortium Comunidad internacional que desarrolla estándares abiertos
para asegurar el crecimiento a largo plazo de la Web. La misión del W3C es llevar a la
World Wide Web a su máximo potencial mediante el desarrollo de protocolos y pautas que
aseguren el crecimiento a largo plazo de la Web [100]. 82
WSQ IAFIS IC 0110 Versión 3.1 Algoritmo de compresión utilizado para imágenes de hue-
llas dactilares en escala de grises. Se basa en la teoría de ondas y se ha convertido en un
estándar para el intercambio y almacenamiento de imágenes de huellas dactilares. WSQ
fue desarrollado por el FBI, el Laboratorio Nacional de Los Alamos, y el National Institute
of Standards and Technology (NIST) [101]. 82
X.500 Conjunto de estándares de redes de ordenadores de la ITU-T sobre servicios de directorio,

entendidos estos como bases de datos de direcciones electrónicas (o de otros tipos). 92
X.509 Estándar UIT-T para infraestructuras de claves públicas. X.509 específica, entre otras
cosas, formatos estándar para certificados de claves públicas y un algoritmo de validación
de la ruta de certificación. 10, 26, 32, 43, 52, 53, 85, 86, 89, 92, 94
Glosario 99
X.509 versión 3 La versión 3 de X.509 incluye la flexibilidad de soporte de nuevas tecnologías

y es la versión más utilizada en la actualidad (junio de 2015). 33
100 Glosario
Bibliografía
[1] I. C. A. Organization, “Document 9303 (machine readable travel documents), part 1

((machine readable travel documents), volume 1 (passports with machine readable data
stored in optical character recognition format).” Website. http://www.icao.int/
publications/Documents/9303_p1_v1_cons_en.pdf.

((machine readable travel documents), volume 2 (specifications for electronically enabled
passports with biometric identification capability).” Website. http://www.icao.int/
[3] I. C. A. Organization, “Document 9303 (machine readable travel documents), part 2 (machi-
ne readable visas).” Website. http://www.icao.int/publications/Documents/
9303_p2_cons_en.pdf.

(machine readable official travel documents), volume 1 (mrtds with machine readable
data stored in optical character recognition format).” Website. http://www.icao.int/

(machine readable official travel documents) volume 2 (specifications for electronically
enabled mrtds with biometric identification capability).” Website. http://www.icao.
int/publications/Documents/9303_p3_v2_cons_en.pdf.
[6] I. Company, “Indra renews the automatic border control system for barajas and el
101
102 BIBLIOGRAFÍA
prat.” Website, Septiembre 2012. http://www.indracompany.com/en/noticia/

indra-renews-the-automatic-border-control-system-for-barajas-and-el-prat.
[7] I. C. A. Organization, “Icao mrtd report vol7 no3.” Website, 2012. http://www.icao.
int/publications/journalsreports/2012/MRTD_Report_Vol7_No3.pdf.
[8] C. N. de Policía de España, “Dnie: Ideas básicas.” Website. http://www.

dnielectronico.es/Asi_es_el_dni_electronico/index.html.
[9] C. N. de Policía de España, “Dnie: Características electrónicas de la tarjeta.” Website.

http://www.dnielectronico.es/seccion_integradores/espec_uno.html.
[10] C. W. Agreement, “Application interface for smart cards used as secure signature creation
devices - part 1: Basic requirements.” Website, Marzo 2004. ftp://ftp.cenorm.be/
PUBLIC/CWAs/e-Europe/eSign/cwa14890-01-2004-Mar.pdf.
[11] C. W. Agreement, “Application interface for smart cards used as secure signature creation
devices - part 2: Additional services.” Website, Mayo 2004. ftp://ftp.cenorm.be/
PUBLIC/CWAs/e-Europe/eSign/cwa14890-02-2004-May.pdf.
[12] R. de España, “Ley 59/2003, de 19 de diciembre, de firma electrónica..” Website. http:

//www.boe.es/buscar/doc.php?id=BOE-A-2003-23399.
[13] P. Europeo, “Directiva 1999/93/ce del parlamento europeo y del consejo, de 13 de diciembre
de 1999, por la que se establece un marco comunitario para la firma electrÓnica.” Web-
site. http://www.dnielectronico.es/marco_legal/directiva_1999_93_CE.
html.
[14] U. G. S. Indra, “Border controls: Inspection systems and tools.” Website.

http://www.icao.int/Meetings/mrtd-madrid-2014/Documents/21b_
AscensioChazarra.pdf.
[15] K. Worldpanel, “Smartphone os market share.” Website. http://www.

kantarworldpanel.com/global/smartphone-os-market-share/.
[16] IDC, “Worldwide smartphone shipments edge past 300 million units in the second quarter;
android and ios devices account for 96 % of the global market, according to idc.” Website.
http://www.idc.com/getdoc.jsp?containerId=prUS25037214.
BIBLIOGRAFÍA 103
[17] A. Brain, “Top android phones.” Website, February 2015. http://www.appbrain.com/

stats/top-android-phones.
[18] A. Pappas, “Alphanumeric character sets for optical recognition – part 2:

Character set ocr-b – shapes and dimensions of the printed image.” Web-
site, Diciembre 2013. http://www.visionmobile.com/blog/2013/12/
developers-prioritise-platforms-ios-vs-android-vs-html5/.
[19] M. Günther, “ajmrtd.” Website. https://play.google.com/store/apps/

details?id=de.maxmg.mrtd.readerapp.
[20] InnoValor, “Nfc passport reader.” Website. https://play.google.com/store/apps/

details?id=nl.novay.nfcpassportreader.
[21] T. Pacific, “Bluefin bluetooth fingerprint reader.” Website. http://www.toplinkpac.

com/bluefin.html.
[22] B. für Sicherheit in der Informationstechnik, “Advanced security mechanisms for

mrtds and eidas token - part 1 - emrtds with bac pacev2 and eacv1.” Website.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/
TechGuidelines/TR03110/BSI_TR-03110_Part-1_V2-2.pdf;jsessionid=
902B2A60CBDBF78D1C83C64EB8A6ACD1.2_cid368?__blob=publicationFile.
[23] B. für Sicherheit ind der Informationstechnik, “Advanced security mecha-

nisms for mrtds and eidas token - part 3 - common specifications.” Website.
TechGuidelines/TR03110/BSI_TR-03110_Part-3-V2_2.pdf;jsessionid=
[24] Google, “Android, the world’s most popular mobile platform.” Website. http://
developer.android.com/about/index.html.
[25] PMD, “Pmd, don’t shoot the mesenger.” Website. http://pmd.sourceforge.net/.
[26] SourceForge, “checkstyle.” Website. http://checkstyle.sourceforge.net/.
[27] JUnit, “Junit.” Website. http://junit.org/.

104 BIBLIOGRAFÍA
[28] Cobertura, “Cobertura. a code coverage utility for java..” Website. http://cobertura.
github.io/cobertura/.
[29] L. Project, “Latex - a document preparation system.” Website. http://latex-project.

org/intro.html.
[30] C. Schenk, “About miktex.” Website. http://miktex.org/about.
[31] TeXnicCenter, “About texniccenter.” Website. http://www.texniccenter.org/

about/about-texniccenter/.
[32] JabRef, “About jabref reference manager.” Website. http://jabref.sourceforge.

net/.
[33] jMRTD, “Jmrtd: An open source java implementation of machine readable travel documents.”
Website. http://jmrtd.org/.
[34] T. S. team, “Project scuba.” Website. http://scuba.sourceforge.net/.
[35] G. Code, “tesseract-ocr.” Website. https://code.google.com/p/tesseract-ocr/.
[36] R. Theis, “Fork of tesseract tools for android.” Website. https://github.com/

rmtheis/tess-two.
[37] D. Bloomberg, “Leptonica.” Website. http://www.leptonica.com/.
[38] N. Technology, “Megamatcher sdk.” Website. http://www.neurotechnology.com/

megamatcher.html/.
[39] QOS.ch, “Simple logging facade for java (slf4j).” Website. http://www.slf4j.org/.
[40] A. S. Foundation, “Apache log4j 2.” Website. http://logging.apache.org/log4j/

2.x/.
[41] INCIBE, “Los usuarios pueden utilizar su dni electrónico en tablets y móviles android
por medio de una aplicación de inteco..” Website, 2012. https://www.incibe.es/
pressRoom/Prensa/Actualidad_INCIBE/Publicacion_INTECO_DNIe_Droid.
[42] S. T. Inc., “ksoap2-android. a lightweight and efficient soap library for the android platform..”
Website. https://code.google.com/p/ksoap2-android/.
BIBLIOGRAFÍA 105
[43] C. O. de Ingenieros Técnicos de Telecomunicación, “Organización del libre ejercicio.

año 2014.” Website, Febrero 2014. http://www.coitt.es/res/libredocs/OLEA%
202014_v1.pdf.
[44] C. O. de Ingenieros Técnicos de Telecomunicación, “Honorarios profesionales.” Website.

http://www.coitt.es/res/libredocs/Honorarios.pdf.
[45] M. de Empleo y Seguridad Social, “Bases y tipos de cotización 2015.” Web-

site, Enero 2015. http://www.seg-social.es/Internet_1/Trabajadores/
CotizacionRecaudaci10777/Basesytiposdecotiza36537/index.htm.
[46] N. Technology, “Prices for verifinger.” Website. http://www.neurotechnology.com/

prices-verifinger.html.
[47] N. Technology, “Prices for verilook.” Website. http://www.neurotechnology.com/

prices-verilook.html.
[48] I. C. A. Organization, “Technical advisory group on machine resadable travel docu-

ments(tag/mrtd), updated technical report supplemental access control.” Website, Mayo
2014. http://www.icao.int/Meetings/TAG-MRTD/TagMrtd22/TAG-MRTD-22_
WP05.pdf.
[49] I. C. A. Organization, “Technical report, supplemental access control for machine readable
travel documents.” Website. http://www.icao.int/security/mrtd/downloads/
technical%20reports/technical%20report.pdf.
[50] E. Pais, “Interior lanza el nuevo dni 3.0, que permite transmitir datos.” Website, Enero
2015. http://politica.elpais.com/politica/2015/01/12/actualidad/
1421059220_344934.html.
[51] Google, “Android lollipop.” Website. http://developer.android.com/about/

versions/lollipop.html.
[52] Google, “Material design.” Website. https://developer.android.com/design/

material/index.html.
[53] Wikipedia, “Advanced encryption standard.” Website. http://es.wikipedia.org/

wiki/Advanced_Encryption_Standard.
106 BIBLIOGRAFÍA
[54] Wikipedia, “Android.” Website. https://es.wikipedia.org/wiki/Android.
[55] A. Developers, “Adt plugin release notes.” Website. http://developer.android.

com/tools/sdk/eclipse-adt.html.
[56] A. Developers, “Android ndk.” Website. https://developer.android.com/tools/

sdk/ndk/index.html.
[57] A. Developers, “Android studio overview.” Website. http://developer.android.

com/tools/studio/index.html.
[58] L. of the Bouncy Castle Inc., “Bouncy castle.” Website. https://www.bouncycastle.

org/.
[59] F. L. Podio, J. S. Dunn, L. Reinert, C. J. Tilton, B. Struif, F. Herr, J. Russell, M. P.

Collier, M. Jerde, L. O’Gorman, and B. Wirtz, “Common biometric exchange formats
framework (cbeff),” Abril 2004. http://csrc.nist.gov/publications/nistir/
NISTIR6529A.pdf.
[60] T. J. McCabe, “A complexity measure.” Website. http://www.literateprogramming.

com/mccabe.pdf.
[61] Wikipedia, “Junit.” Website. http://es.wikipedia.org/wiki/Complejidad_

ciclom%C3%A1tica.
[62] Android, “Art and dalvik.” Website. http://source.android.com/devices/tech/

dalvik/.
[63] Wikipedia, “Document object model.” Website. http://es.wikipedia.org/wiki/

Document_Object_Model.
[64] eclipse, “eclipse ide.” Website. https://eclipse.org/.
[65] Wikipedia, “eclipse (software).” Website. https://es.wikipedia.org/wiki/

Eclipse_(software).
[66] G. O. System, “Gnu general public license.” Website. http://www.gnu.org/copyleft/

gpl.html.
BIBLIOGRAFÍA 107
[67] G. O. System, “Gnu lesser general public license.” Website. http://www.gnu.org/

copyleft/lgpl.html.
[68] Wikipedia, “Google play.” Website. http://es.wikipedia.org/wiki/Google_

Play.
[69] Wikipedia, “Impresión lenticular.” Website. http://es.wikipedia.org/wiki/

Impresi%C3%B3n_lenticular.
[70] JetBrains, “Intellij idea. the most intelligent java ide.” Website. https://www.
jetbrains.com/idea/.
[71] I. O. for Standardization, “Iso/iec 19794-2: Information technology – biometric data

interchange formats – part 2: Finger minutiae data.” Website. https://www.iso.org/
obp/ui/#iso:std:iso-iec:19794:-2:ed-1:v1:en.
[72] I. O. for Standardization, “Iso/iec 19794-4:2005 information technology – biometric data

interchange formats – part 4: Finger image data.” Website. https://www.iso.org/
obp/ui/#iso:std:iso-iec:19794:-4:ed-1:v1:en.
[73] I. O. for Standardization, “Iso/iec 19794-5:2005 information technology – biometric data

interchange formats – part 5: Face image data.” Website. http://www.iso.org/iso/
catalogue_detail.htm?csnumber=38749.
[74] ORACLE, “About the java technology.” Website. http://docs.oracle.com/javase/

tutorial/getStarted/intro/definition.html.
[75] Oracle, “About the java technology.” Website. http://docs.oracle.com/javase/

tutorial/getStarted/intro/definition.html.
[76] A. S. Foundation, “Oracle java documentation.” Website. http://docs.oracle.com/

javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#
Introduction.
[77] Wikipedia, “Java cryptography extension.” Website. http://en.wikipedia.org/

wiki/Java_Cryptography_Extension.
[78] J. P. E. Group, “Documentation on jpeg 2000.” Website. http://www.jpeg.org/

jpeg2000/documentation.html.
108 BIBLIOGRAFÍA
[79] Wikipedia, “Junit.” Website. https://es.wikipedia.org/wiki/JUnit.
[80] A. Feder, “Your bibtex resource.” Website, 2006. http://www.bibtex.org/.
[81] T. A. S. Foundation, “Apache maven project.” Website. http://maven.apache.org/.
[82] Wikipedia, “Maven.” Website. http://es.wikipedia.org/wiki/Maven.
[83] Wikipedia, “Minutiae.” Website. http://en.wikipedia.org/wiki/Minutiae.
[84] N. Forum, “What is nfc?.” Website. http://nfc-forum.org/what-is-nfc/.
[85] C. I. W. Elham Tabassi, Charles L. Wilson, “Nistir 7151, fingerprint image quality,” Agosto
2004. ftp://sequoyah.nist.gov/pub/nist_internal_reports/ir_7151/ir_
7151.pdf.
[86] O. Organization, “Opengl api documentation overview.” Website. https://www.opengl.

org/documentation/.
[87] B. D. Portal, “Serial port profile (spp).” Website. https://developer.bluetooth.

org/TechnologyOverview/Pages/SPP.aspx.
[88] S. T. Inc., “Soap versión 1.2 parte 0: Fundamentos.” Website. http://www.w3c.es/

Traducciones/es/TR/2003/REC-soap12-part0-20030624/#L1149.
[89] N. Gallagher, “Simple xml serialization.” Website. http://simple.sourceforge.

net/home.php.
[90] rtyley, “Spongy castle.” Website. https://rtyley.github.io/spongycastle/.
[91] T. A. S. Foundation, “Apache subversion, enterprise-class centralized version control for

the masses.” Website. https://subversion.apache.org/.
[92] Wikipedia, “Subversion(software).” Website. http://es.wikipedia.org/wiki/

Subversion_(software).
[93] T. U. Group, “Getting started with tex, latex, and friends.” Website. http://www.tug.
org/begin.html.
BIBLIOGRAFÍA 109
[94] B. für Sicherheit in der Informationstechnik, “Advanced security mechanisms for mrtds and
eidas token - part 2 - protocols for electronic identification, authentication and trust servi-
ces (eidas).” Website. https://www.bsi.bund.de/SharedDocs/Downloads/EN/
BSI/Publications/TechGuidelines/TR03110/BSI_TR-03110_Part-2-V2_2.
pdf;jsessionid=902B2A60CBDBF78D1C83C64EB8A6ACD1.2_cid368?__blob=
publicationFile.
[95] B. für Sicherheit ind der Informationstechnik, “Advanced security mechanisms for
mrtds and eidas token - part 4 - applications and document profiles.” Website.
TechGuidelines/TR03110/BSI_TR-03110_Part-4_V2-2.pdf;jsessionid=
[96] I. N. W. Group, “Uniform resource identifier (uri): Generic syntax.” Website. http:
//www.ietf.org/rfc/rfc3986.txt.
[97] I. N. W. Group, “Uniform resource locators (url).” Website. https://www.ietf.org/

rfc/rfc1738.txt.
[98] W. W. W. Consortium, “Guía breve de servicios web.” Website. http://www.w3c.es/

Divulgacion/GuiasBreves/ServiciosWeb.
[99] Wikipedia, “Wi-fi.” Website. http://es.wikipedia.org/wiki/Wi-Fi.
[100] W. W. W. Consortium, “W3c mission.” Website. http://www.w3.org/Consortium/

mission.html.
[101] C. J. I. Services, “Wsq gray-scale fingerprint image compression specification ver-

sion 3.1.” Website. https://www.fbibiospecs.org/docs/WSQ_Gray-scale_
Specification_Version_3_1_Final.pdf.
110 BIBLIOGRAFÍA
Apéndices
111
Apéndice A
Reglas PMD
A.1. Reglas comunes
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>

2 <ruleset xmlns="http://pmd.sf.net/ruleset/1.0.0" name=""
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd">
4 <description />
5 <rule ref="rulesets/java/typeresolution.xml/LooseCoupling" />
6 <rule ref="rulesets/java/typeresolution.xml/CloneMethodMustImplementCloneable"
/>
7 <rule ref="rulesets/java/typeresolution.xml/UnusedImports" />
8 <rule ref="rulesets/java/typeresolution.xml/SignatureDeclareThrowsException" />
9 <rule ref="rulesets/java/basic.xml/EmptyCatchBlock" />
10 <rule ref="rulesets/java/basic.xml/EmptyIfStmt" />
11 <rule ref="rulesets/java/basic.xml/EmptyWhileStmt" />
12 <rule ref="rulesets/java/basic.xml/EmptyTryBlock" />
13 <rule ref="rulesets/java/basic.xml/EmptyFinallyBlock" />
14 <rule ref="rulesets/java/basic.xml/EmptySwitchStatements" />
15 <rule ref="rulesets/java/basic.xml/JumbledIncrementer" />
16 <rule ref="rulesets/java/basic.xml/ForLoopShouldBeWhileLoop" />
17 <rule ref="rulesets/java/basic.xml/UnnecessaryConversionTemporary" />
18 <rule ref="rulesets/java/basic.xml/OverrideBothEqualsAndHashcode" />
19 <rule ref="rulesets/java/basic.xml/DoubleCheckedLocking" />
113
114 APÉNDICE A. REGLAS PMD
20 <rule ref="rulesets/java/basic.xml/ReturnFromFinallyBlock" />

21 <rule ref="rulesets/java/basic.xml/EmptySynchronizedBlock" />
22 <rule ref="rulesets/java/basic.xml/UnnecessaryReturn" />
23 <rule ref="rulesets/java/basic.xml/EmptyStaticInitializer" />
24 <rule ref="rulesets/java/basic.xml/UnconditionalIfStatement" />
25 <rule ref="rulesets/java/basic.xml/EmptyStatementNotInLoop" />
26 <rule ref="rulesets/java/basic.xml/BooleanInstantiation" />
27 <rule ref="rulesets/java/basic.xml/UnnecessaryFinalModifier" />
28 <rule ref="rulesets/java/basic.xml/CollapsibleIfStatements" />
29 <rule ref="rulesets/java/basic.xml/UselessOverridingMethod" />
30 <rule ref="rulesets/java/basic.xml/ClassCastExceptionWithToArray" />
31 <rule
ref="rulesets/java/basic.xml/AvoidDecimalLiteralsInBigDecimalConstructor" />
32 <rule ref="rulesets/java/basic.xml/UselessOperationOnImmutable" />
33 <rule ref="rulesets/java/basic.xml/MisplacedNullCheck" />
34 <rule ref="rulesets/java/basic.xml/UnusedNullCheckInEquals" />
35 <rule ref="rulesets/java/basic.xml/AvoidThreadGroup" />
36 <rule ref="rulesets/java/basic.xml/BrokenNullCheck" />
37 <rule ref="rulesets/java/basic.xml/BigIntegerInstantiation" />
38 <rule ref="rulesets/java/basic.xml/AvoidUsingOctalValues" />
39 <rule ref="rulesets/java/basic.xml/AvoidUsingHardCodedIP" />
40 <rule ref="rulesets/java/basic.xml/CheckResultSet" />
41 <rule ref="rulesets/java/basic.xml/AvoidMultipleUnaryOperators" />
42 <rule ref="rulesets/java/basic.xml/EmptyInitializer" />
43 <rule ref="rulesets/java/braces.xml/IfStmtsMustUseBraces" />
44 <rule ref="rulesets/java/braces.xml/WhileLoopsMustUseBraces" />
45 <rule ref="rulesets/java/braces.xml/IfElseStmtsMustUseBraces" />
46 <rule ref="rulesets/java/braces.xml/ForLoopsMustUseBraces" />
47 <rule ref="rulesets/java/unusedcode.xml/UnusedPrivateField" />
48 <rule ref="rulesets/java/unusedcode.xml/UnusedLocalVariable" />
49 <rule ref="rulesets/java/unusedcode.xml/UnusedPrivateMethod" />
50 <rule ref="rulesets/java/unusedcode.xml/UnusedFormalParameter" />
51 <rule ref="rulesets/java/unusedcode.xml/UnusedModifier" />
52 <rule ref="rulesets/java/logging-java.xml/MoreThanOneLogger" />
53 <rule ref="rulesets/java/logging-java.xml/LoggerIsNotStaticFinal" />
54 <rule ref="rulesets/java/logging-java.xml/SystemPrintln" />
55 <rule ref="rulesets/java/logging-java.xml/AvoidPrintStackTrace" />
56 <rule ref="rulesets/java/controversial.xml/UnnecessaryConstructor" />
57 
A.1 Reglas comunes 115
58 <rule ref="rulesets/java/controversial.xml/OnlyOneReturn" />

59 <rule ref="rulesets/java/controversial.xml/AssignmentInOperand" />
60 <rule ref="rulesets/java/controversial.xml/AtLeastOneConstructor" />
61 <rule ref="rulesets/java/controversial.xml/DontImportSun" />
62 <rule ref="rulesets/java/controversial.xml/SuspiciousOctalEscape" />
63 <rule ref="rulesets/java/controversial.xml/CallSuperInConstructor" />
64 <rule ref="rulesets/java/controversial.xml/UnnecessaryParentheses" />
65 <rule ref="rulesets/java/controversial.xml/DefaultPackage" />
66 <rule ref="rulesets/java/controversial.xml/BooleanInversion" />
67 <rule ref="rulesets/java/controversial.xml/AvoidFinalLocalVariable" />
68 <rule ref="rulesets/java/controversial.xml/AvoidUsingShortType" />
69 <rule ref="rulesets/java/controversial.xml/AvoidUsingVolatile" />
70 <rule ref="rulesets/java/controversial.xml/AvoidUsingNativeCode" />
71 <rule ref="rulesets/java/controversial.xml/AvoidAccessibilityAlteration" />
72 <rule
ref="rulesets/java/controversial.xml/DoNotCallGarbageCollectionExplicitly"
/>
73 <rule ref="rulesets/java/strings.xml/AvoidDuplicateLiterals" />
74 <rule ref="rulesets/java/strings.xml/StringInstantiation" />
75 <rule ref="rulesets/java/strings.xml/StringToString" />
76 <rule ref="rulesets/java/strings.xml/InefficientStringBuffering" />
77 <rule ref="rulesets/java/strings.xml/UnnecessaryCaseChange" />
78 <rule ref="rulesets/java/strings.xml/UseStringBufferLength" />
79 <rule ref="rulesets/java/strings.xml/AppendCharacterWithChar" />
80 <rule ref="rulesets/java/strings.xml/ConsecutiveLiteralAppends" />
81 <rule ref="rulesets/java/strings.xml/UseIndexOfChar" />
82 <rule ref="rulesets/java/strings.xml/InefficientEmptyStringCheck" />
83 <rule ref="rulesets/java/strings.xml/InsufficientStringBufferDeclaration" />
84 <rule ref="rulesets/java/strings.xml/UselessStringValueOf" />
85 <rule ref="rulesets/java/strings.xml/StringBufferInstantiationWithChar" />
86 <rule ref="rulesets/java/strings.xml/UseEqualsToCompareStrings" />
87 <rule ref="rulesets/java/strings.xml/AvoidStringBufferField" />
88 <rule ref="rulesets/java/strictexception.xml/AvoidCatchingThrowable" />
89 <rule ref="rulesets/java/strictexception.xml/ExceptionAsFlowControl" />
90 <rule ref="rulesets/java/strictexception.xml/AvoidCatchingNPE" />
91 <rule ref="rulesets/java/strictexception.xml/AvoidThrowingRawExceptionTypes" />
92 <rule
ref="rulesets/java/strictexception.xml/AvoidThrowingNullPointerException" />
93 <rule ref="rulesets/java/strictexception.xml/AvoidRethrowingException" />
94 <rule ref="rulesets/java/strictexception.xml/DoNotExtendJavaLangError" />

95 <rule ref="rulesets/java/strictexception.xml/DoNotThrowExceptionInFinally" />
96 <rule ref="rulesets/java/migrating.xml/ReplaceVectorWithList" />
97 <rule ref="rulesets/java/migrating.xml/ReplaceEnumerationWithIterator" />
98 <rule ref="rulesets/java/migrating.xml/AvoidEnumAsIdentifier" />
99 <rule ref="rulesets/java/migrating.xml/AvoidAssertAsIdentifier" />
100 <rule ref="rulesets/java/migrating.xml/IntegerInstantiation" />
101 <rule ref="rulesets/java/migrating.xml/ByteInstantiation" />
102 <rule ref="rulesets/java/migrating.xml/ShortInstantiation" />
103 <rule ref="rulesets/java/migrating.xml/LongInstantiation" />
104 <rule ref="rulesets/java/migrating.xml/JUnitUseExpected" />
105 <rule ref="rulesets/java/j2ee.xml/UseProperClassLoader" />
106 <rule ref="rulesets/java/j2ee.xml/MDBAndSessionBeanNamingConvention" />
107 <rule ref="rulesets/java/j2ee.xml/RemoteSessionInterfaceNamingConvention" />
108 <rule ref="rulesets/java/j2ee.xml/LocalInterfaceSessionNamingConvention" />
109 <rule ref="rulesets/java/j2ee.xml/LocalHomeNamingConvention" />
110 <rule ref="rulesets/java/j2ee.xml/RemoteInterfaceNamingConvention" />
111 <rule ref="rulesets/java/j2ee.xml/DoNotCallSystemExit" />
112 <rule ref="rulesets/java/j2ee.xml/StaticEJBFieldShouldBeFinal" />
113 <rule ref="rulesets/java/j2ee.xml/DoNotUseThreads" />
114 <rule ref="rulesets/java/optimizations.xml/MethodArgumentCouldBeFinal" />
115 
116 <rule ref="rulesets/java/optimizations.xml/SimplifyStartsWith" />
117 <rule ref="rulesets/java/optimizations.xml/UseStringBufferForStringAppends" />
118 <rule ref="rulesets/java/optimizations.xml/UseArraysAsList" />
119 <rule ref="rulesets/java/optimizations.xml/AvoidArrayLoops" />
120 <rule ref="rulesets/java/optimizations.xml/UnnecessaryWrapperObjectCreation" />
121 <rule ref="rulesets/java/optimizations.xml/AddEmptyString" />
122 <rule ref="rulesets/java/sunsecure.xml/MethodReturnsInternalArray" />
123 <rule ref="rulesets/java/sunsecure.xml/ArrayIsStoredDirectly" />
124 <rule ref="rulesets/java/coupling.xml/CouplingBetweenObjects" />
125 <rule ref="rulesets/java/coupling.xml/ExcessiveImports">
126 <properties>
127 <property name="minimum" value="60" />
128 </properties>
129 </rule>
130 <rule ref="rulesets/java/imports.xml/DuplicateImports" />
131 <rule ref="rulesets/java/imports.xml/DontImportJavaLang" />
132 <rule ref="rulesets/java/imports.xml/UnusedImports" />

133 <rule ref="rulesets/java/imports.xml/ImportFromSamePackage" />
134 <rule ref="rulesets/java/imports.xml/TooManyStaticImports">
135 <properties>
136 <property name="maximumStaticImports" value="10" />
137 </properties>
138 </rule>
139 <rule ref="rulesets/java/junit.xml/JUnitStaticSuite" />
140 <rule ref="rulesets/java/junit.xml/JUnitSpelling" />
141 <rule ref="rulesets/java/junit.xml/JUnitAssertionsShouldIncludeMessage" />
142 <rule ref="rulesets/java/junit.xml/JUnitTestsShouldIncludeAssert" />
143 <rule ref="rulesets/java/junit.xml/TestClassWithoutTestCases" />
144 <rule ref="rulesets/java/junit.xml/UnnecessaryBooleanAssertion" />
145 <rule ref="rulesets/java/junit.xml/UseAssertEqualsInsteadOfAssertTrue" />
146 <rule ref="rulesets/java/junit.xml/UseAssertSameInsteadOfAssertTrue" />
147 <rule ref="rulesets/java/junit.xml/UseAssertNullInsteadOfAssertTrue" />
148 <rule ref="rulesets/java/junit.xml/SimplifyBooleanAssertion" />
149 <rule ref="rulesets/java/naming.xml/ShortVariable" />
150 <rule ref="rulesets/java/naming.xml/LongVariable">
151 <properties>
153 </properties>
154 </rule>
155 <rule ref="rulesets/java/naming.xml/ShortMethodName" />
156 <rule ref="rulesets/java/naming.xml/VariableNamingConventions" />
157 <rule ref="rulesets/java/naming.xml/MethodNamingConventions" />
158 <rule ref="rulesets/java/naming.xml/ClassNamingConventions" />
159 <rule ref="rulesets/java/naming.xml/AbstractNaming" />
160 <rule ref="rulesets/java/naming.xml/AvoidDollarSigns" />
161 <rule ref="rulesets/java/naming.xml/MethodWithSameNameAsEnclosingClass" />
162 <rule ref="rulesets/java/naming.xml/SuspiciousHashcodeMethodName" />
163 <rule ref="rulesets/java/naming.xml/SuspiciousConstantFieldName" />
164 <rule ref="rulesets/java/naming.xml/SuspiciousEqualsMethodName" />
165 <rule ref="rulesets/java/naming.xml/AvoidFieldNameMatchingTypeName" />
166 <rule ref="rulesets/java/naming.xml/AvoidFieldNameMatchingMethodName" />
167 <rule ref="rulesets/java/naming.xml/NoPackage" />
168 <rule ref="rulesets/java/naming.xml/PackageCase" />
169 <rule ref="rulesets/java/naming.xml/MisleadingVariableName" />
170 <rule ref="rulesets/java/naming.xml/BooleanGetMethodName" />
171 <rule ref="rulesets/java/codesize.xml/NPathComplexity" />

172 <rule ref="rulesets/java/codesize.xml/ExcessiveMethodLength" />
173 <rule ref="rulesets/java/codesize.xml/ExcessiveParameterList">
174 <properties>
176 </properties>
177 </rule>
178 <rule ref="rulesets/java/codesize.xml/ExcessiveClassLength" />
179 <rule ref="rulesets/java/codesize.xml/CyclomaticComplexity" />
180 <rule ref="rulesets/java/codesize.xml/ExcessivePublicCount">
181 <properties>
183 </properties>
184 </rule>
185 <rule ref="rulesets/java/codesize.xml/TooManyFields">
186 <properties>
187 <property name="maxfields" value="40" />
188 </properties>
189 </rule>
190 <rule ref="rulesets/java/codesize.xml/NcssMethodCount" />
191 <rule ref="rulesets/java/codesize.xml/NcssTypeCount" />
192 <rule ref="rulesets/java/codesize.xml/NcssConstructorCount" />
193 <rule ref="rulesets/java/codesize.xml/TooManyMethods">
194 <properties>
195 <property name="maxmethods" value="20" />
196 </properties>
197 </rule>
198 <rule ref="rulesets/java/finalizers.xml/EmptyFinalizer" />
199 <rule ref="rulesets/java/finalizers.xml/FinalizeOnlyCallsSuperFinalize" />
200 <rule ref="rulesets/java/finalizers.xml/FinalizeOverloaded" />
201 <rule ref="rulesets/java/finalizers.xml/FinalizeDoesNotCallSuperFinalize" />
202 <rule ref="rulesets/java/finalizers.xml/FinalizeShouldBeProtected" />
203 <rule ref="rulesets/java/finalizers.xml/AvoidCallingFinalize" />
204 <rule
ref="rulesets/java/logging-jakarta-commons.xml/UseCorrectExceptionLogging"
/>
205 <rule ref="rulesets/java/logging-jakarta-commons.xml/ProperLogger" />
206 
207 <rule ref="rulesets/java/javabeans.xml/MissingSerialVersionUID" />
208 <rule ref="rulesets/java/clone.xml/ProperCloneImplementation" />

209 <rule ref="rulesets/java/clone.xml/CloneThrowsCloneNotSupportedException" />
210 <rule ref="rulesets/java/design.xml/UseSingleton" />
211 <rule ref="rulesets/java/design.xml/SimplifyBooleanReturns" />
212 <rule ref="rulesets/java/design.xml/SimplifyBooleanExpressions" />
213 <rule ref="rulesets/java/design.xml/SwitchStmtsShouldHaveDefault" />
214 <rule ref="rulesets/java/design.xml/AvoidDeeplyNestedIfStmts" />
215 <rule ref="rulesets/java/design.xml/AvoidReassigningParameters" />
216 <rule ref="rulesets/java/design.xml/SwitchDensity" />
217 <rule ref="rulesets/java/design.xml/ConstructorCallsOverridableMethod" />
218 <rule ref="rulesets/java/design.xml/AccessorClassGeneration" />
219 <rule ref="rulesets/java/design.xml/FinalFieldCouldBeStatic" />
220 
221 <rule ref="rulesets/java/design.xml/DefaultLabelNotLastInSwitchStmt" />
222 <rule ref="rulesets/java/design.xml/NonCaseLabelInSwitchStatement" />
223 <rule ref="rulesets/java/design.xml/OptimizableToArrayCall" />
224 <rule ref="rulesets/java/design.xml/BadComparison" />
225 <rule ref="rulesets/java/design.xml/EqualsNull" />
226 <rule ref="rulesets/java/design.xml/ConfusingTernary" />
227 <rule ref="rulesets/java/design.xml/InstantiationToGetClass" />
228 <rule ref="rulesets/java/design.xml/IdempotentOperations" />
229 <rule ref="rulesets/java/design.xml/SimpleDateFormatNeedsLocale" />
230 <rule ref="rulesets/java/design.xml/ImmutableField" />
231 <rule ref="rulesets/java/design.xml/UseLocaleWithCaseConversions" />
232 <rule ref="rulesets/java/design.xml/AvoidProtectedFieldInFinalClass" />
233 <rule ref="rulesets/java/design.xml/AssignmentToNonFinalStatic" />
234 <rule
ref="rulesets/java/design.xml/MissingStaticMethodInNonInstantiatableClass"
/>
235 <rule ref="rulesets/java/design.xml/AvoidSynchronizedAtMethodLevel" />
236 <rule ref="rulesets/java/design.xml/MissingBreakInSwitch" />
237 <rule ref="rulesets/java/design.xml/UseNotifyAllInsteadOfNotify" />
238 <rule ref="rulesets/java/design.xml/AvoidInstanceofChecksInCatchClause" />
239 <rule ref="rulesets/java/design.xml/AbstractClassWithoutAbstractMethod" />
240 <rule ref="rulesets/java/design.xml/SimplifyConditional" />
241 <rule ref="rulesets/java/design.xml/CompareObjectsWithEquals" />
242 <rule ref="rulesets/java/design.xml/PositionLiteralsFirstInComparisons" />
243 <rule ref="rulesets/java/design.xml/UnnecessaryLocalBeforeReturn" />
244 <rule ref="rulesets/java/design.xml/NonThreadSafeSingleton" />
245 <rule ref="rulesets/java/design.xml/UncommentedEmptyMethod" />

246 <rule ref="rulesets/java/design.xml/UncommentedEmptyConstructor" />
247 <rule ref="rulesets/java/design.xml/AvoidConstantsInterface" />
248 <rule ref="rulesets/java/design.xml/UnsynchronizedStaticDateFormatter" />
249 <rule ref="rulesets/java/design.xml/PreserveStackTrace" />
250 <rule ref="rulesets/java/design.xml/UseCollectionIsEmpty" />
251 <rule
ref="rulesets/java/design.xml/ClassWithOnlyPrivateConstructorsShouldBeFinal"
/>
252 <rule
ref="rulesets/java/design.xml/EmptyMethodInAbstractClassShouldBeAbstract" />
253 <rule ref="rulesets/java/design.xml/SingularField" />
254 <rule ref="rulesets/java/design.xml/ReturnEmptyArrayRatherThanNull" />
255 <rule ref="rulesets/java/design.xml/AbstractClassWithoutAnyMethod" />
256 <rule ref="rulesets/java/design.xml/TooFewBranchesForASwitchStatement" />
257 </ruleset>
A.2. Reglas específicas para Android
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>

2 <ruleset xmlns="http://pmd.sf.net/ruleset/1.0.0" name=""
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd">
4 <description />
5 <rule ref="rulesets/java/typeresolution.xml/LooseCoupling" />
6 <rule ref="rulesets/java/typeresolution.xml/CloneMethodMustImplementCloneable"
/>
7 <rule ref="rulesets/java/typeresolution.xml/UnusedImports" />
8 <rule ref="rulesets/java/typeresolution.xml/SignatureDeclareThrowsException" />
9 <rule ref="rulesets/java/basic.xml/EmptyCatchBlock" />
10 <rule ref="rulesets/java/basic.xml/EmptyIfStmt" />
11 <rule ref="rulesets/java/basic.xml/EmptyWhileStmt" />
12 <rule ref="rulesets/java/basic.xml/EmptyTryBlock" />
13 <rule ref="rulesets/java/basic.xml/EmptyFinallyBlock" />
14 <rule ref="rulesets/java/basic.xml/EmptySwitchStatements" />
15 <rule ref="rulesets/java/basic.xml/JumbledIncrementer" />
A.2 Reglas específicas para Android 121
16 <rule ref="rulesets/java/basic.xml/ForLoopShouldBeWhileLoop" />

17 <rule ref="rulesets/java/basic.xml/UnnecessaryConversionTemporary" />
18 <rule ref="rulesets/java/basic.xml/OverrideBothEqualsAndHashcode" />
19 <rule ref="rulesets/java/basic.xml/DoubleCheckedLocking" />
20 <rule ref="rulesets/java/basic.xml/ReturnFromFinallyBlock" />
21 <rule ref="rulesets/java/basic.xml/EmptySynchronizedBlock" />
22 <rule ref="rulesets/java/basic.xml/UnnecessaryReturn" />
23 <rule ref="rulesets/java/basic.xml/EmptyStaticInitializer" />
24 <rule ref="rulesets/java/basic.xml/UnconditionalIfStatement" />
25 <rule ref="rulesets/java/basic.xml/EmptyStatementNotInLoop" />
26 <rule ref="rulesets/java/basic.xml/BooleanInstantiation" />
27 <rule ref="rulesets/java/basic.xml/UnnecessaryFinalModifier" />
28 <rule ref="rulesets/java/basic.xml/CollapsibleIfStatements" />
29 <rule ref="rulesets/java/basic.xml/UselessOverridingMethod" />
30 <rule ref="rulesets/java/basic.xml/ClassCastExceptionWithToArray" />
31 <rule
ref="rulesets/java/basic.xml/AvoidDecimalLiteralsInBigDecimalConstructor" />
32 <rule ref="rulesets/java/basic.xml/UselessOperationOnImmutable" />
33 <rule ref="rulesets/java/basic.xml/MisplacedNullCheck" />
34 <rule ref="rulesets/java/basic.xml/UnusedNullCheckInEquals" />
35 <rule ref="rulesets/java/basic.xml/AvoidThreadGroup" />
36 <rule ref="rulesets/java/basic.xml/BrokenNullCheck" />
37 <rule ref="rulesets/java/basic.xml/BigIntegerInstantiation" />
38 <rule ref="rulesets/java/basic.xml/AvoidUsingOctalValues" />
39 <rule ref="rulesets/java/basic.xml/AvoidUsingHardCodedIP" />
40 <rule ref="rulesets/java/basic.xml/CheckResultSet" />
41 <rule ref="rulesets/java/basic.xml/AvoidMultipleUnaryOperators" />
42 <rule ref="rulesets/java/basic.xml/EmptyInitializer" />
43 <rule ref="rulesets/java/braces.xml/IfStmtsMustUseBraces" />
44 <rule ref="rulesets/java/braces.xml/WhileLoopsMustUseBraces" />
45 <rule ref="rulesets/java/braces.xml/IfElseStmtsMustUseBraces" />
46 <rule ref="rulesets/java/braces.xml/ForLoopsMustUseBraces" />
47 <rule ref="rulesets/java/unusedcode.xml/UnusedPrivateField" />
48 <rule ref="rulesets/java/unusedcode.xml/UnusedLocalVariable" />
49 <rule ref="rulesets/java/unusedcode.xml/UnusedPrivateMethod" />
50 <rule ref="rulesets/java/unusedcode.xml/UnusedFormalParameter" />
51 <rule ref="rulesets/java/unusedcode.xml/UnusedModifier" />
52 <rule ref="rulesets/java/logging-java.xml/MoreThanOneLogger" />
53 <rule ref="rulesets/java/logging-java.xml/LoggerIsNotStaticFinal" />
54 <rule ref="rulesets/java/logging-java.xml/SystemPrintln" />

55 <rule ref="rulesets/java/logging-java.xml/AvoidPrintStackTrace" />
56 <rule ref="rulesets/java/controversial.xml/UnnecessaryConstructor" />
57 
58 <rule ref="rulesets/java/controversial.xml/OnlyOneReturn" />
59 <rule ref="rulesets/java/controversial.xml/AssignmentInOperand" />
60 <rule ref="rulesets/java/controversial.xml/AtLeastOneConstructor" />
61 <rule ref="rulesets/java/controversial.xml/DontImportSun" />
62 <rule ref="rulesets/java/controversial.xml/SuspiciousOctalEscape" />
63 <rule ref="rulesets/java/controversial.xml/CallSuperInConstructor" />
64 <rule ref="rulesets/java/controversial.xml/UnnecessaryParentheses" />
65 <rule ref="rulesets/java/controversial.xml/DefaultPackage" />
66 <rule ref="rulesets/java/controversial.xml/BooleanInversion" />
67 <rule ref="rulesets/java/controversial.xml/AvoidFinalLocalVariable" />
68 <rule ref="rulesets/java/controversial.xml/AvoidUsingShortType" />
69 <rule ref="rulesets/java/controversial.xml/AvoidUsingVolatile" />
70 <rule ref="rulesets/java/controversial.xml/AvoidUsingNativeCode" />
71 <rule ref="rulesets/java/controversial.xml/AvoidAccessibilityAlteration" />
72 <rule
ref="rulesets/java/controversial.xml/DoNotCallGarbageCollectionExplicitly"
/>
73 <rule ref="rulesets/java/strings.xml/AvoidDuplicateLiterals" />
74 <rule ref="rulesets/java/strings.xml/StringInstantiation" />
75 <rule ref="rulesets/java/strings.xml/StringToString" />
76 <rule ref="rulesets/java/strings.xml/InefficientStringBuffering" />
77 <rule ref="rulesets/java/strings.xml/UnnecessaryCaseChange" />
78 <rule ref="rulesets/java/strings.xml/UseStringBufferLength" />
79 <rule ref="rulesets/java/strings.xml/AppendCharacterWithChar" />
80 <rule ref="rulesets/java/strings.xml/ConsecutiveLiteralAppends" />
81 <rule ref="rulesets/java/strings.xml/UseIndexOfChar" />
82 <rule ref="rulesets/java/strings.xml/InefficientEmptyStringCheck" />
83 <rule ref="rulesets/java/strings.xml/InsufficientStringBufferDeclaration" />
84 <rule ref="rulesets/java/strings.xml/UselessStringValueOf" />
85 <rule ref="rulesets/java/strings.xml/StringBufferInstantiationWithChar" />
86 <rule ref="rulesets/java/strings.xml/UseEqualsToCompareStrings" />
87 <rule ref="rulesets/java/strings.xml/AvoidStringBufferField" />
88 <rule ref="rulesets/java/strictexception.xml/AvoidCatchingThrowable" />
89 <rule ref="rulesets/java/strictexception.xml/ExceptionAsFlowControl" />
90 <rule ref="rulesets/java/strictexception.xml/AvoidCatchingNPE" />
91 <rule ref="rulesets/java/strictexception.xml/AvoidThrowingRawExceptionTypes" />

92 <rule
ref="rulesets/java/strictexception.xml/AvoidThrowingNullPointerException" />
93 <rule ref="rulesets/java/strictexception.xml/AvoidRethrowingException" />
94 <rule ref="rulesets/java/strictexception.xml/DoNotExtendJavaLangError" />
95 <rule ref="rulesets/java/strictexception.xml/DoNotThrowExceptionInFinally" />
96 <rule ref="rulesets/java/migrating.xml/ReplaceVectorWithList" />
97 <rule ref="rulesets/java/migrating.xml/ReplaceEnumerationWithIterator" />
98 <rule ref="rulesets/java/migrating.xml/AvoidEnumAsIdentifier" />
99 <rule ref="rulesets/java/migrating.xml/AvoidAssertAsIdentifier" />
100 <rule ref="rulesets/java/migrating.xml/IntegerInstantiation" />
101 <rule ref="rulesets/java/migrating.xml/ByteInstantiation" />
102 <rule ref="rulesets/java/migrating.xml/ShortInstantiation" />
103 <rule ref="rulesets/java/migrating.xml/LongInstantiation" />
104 <rule ref="rulesets/java/migrating.xml/JUnitUseExpected" />
105 
106 
107 
108 
109 
110 
111 
112 
113 
114 <rule ref="rulesets/java/optimizations.xml/MethodArgumentCouldBeFinal" />
115 
116 <rule ref="rulesets/java/optimizations.xml/SimplifyStartsWith" />
117 <rule ref="rulesets/java/optimizations.xml/UseStringBufferForStringAppends" />
118 <rule ref="rulesets/java/optimizations.xml/UseArraysAsList" />
119 <rule ref="rulesets/java/optimizations.xml/AvoidArrayLoops" />
120 <rule ref="rulesets/java/optimizations.xml/UnnecessaryWrapperObjectCreation" />
121 <rule ref="rulesets/java/optimizations.xml/AddEmptyString" />
122 <rule ref="rulesets/java/sunsecure.xml/MethodReturnsInternalArray" />
123 <rule ref="rulesets/java/sunsecure.xml/ArrayIsStoredDirectly" />
124 <rule ref="rulesets/java/coupling.xml/CouplingBetweenObjects" />
125 <rule ref="rulesets/java/coupling.xml/ExcessiveImports">

126 <properties>
128 </properties>
129 </rule>
130 <rule ref="rulesets/java/imports.xml/DuplicateImports" />
131 <rule ref="rulesets/java/imports.xml/DontImportJavaLang" />
132 <rule ref="rulesets/java/imports.xml/UnusedImports" />
133 <rule ref="rulesets/java/imports.xml/ImportFromSamePackage" />
134 <rule ref="rulesets/java/imports.xml/TooManyStaticImports">
135 <properties>
136 <property name="maximumStaticImports" value="10" />
137 </properties>
138 </rule>
139 <rule ref="rulesets/java/junit.xml/JUnitStaticSuite" />
140 <rule ref="rulesets/java/junit.xml/JUnitSpelling" />
141 <rule ref="rulesets/java/junit.xml/JUnitAssertionsShouldIncludeMessage" />
142 <rule ref="rulesets/java/junit.xml/JUnitTestsShouldIncludeAssert" />
143 <rule ref="rulesets/java/junit.xml/TestClassWithoutTestCases" />
144 <rule ref="rulesets/java/junit.xml/UnnecessaryBooleanAssertion" />
145 <rule ref="rulesets/java/junit.xml/UseAssertEqualsInsteadOfAssertTrue" />
146 <rule ref="rulesets/java/junit.xml/UseAssertSameInsteadOfAssertTrue" />
147 <rule ref="rulesets/java/junit.xml/UseAssertNullInsteadOfAssertTrue" />
148 <rule ref="rulesets/java/junit.xml/SimplifyBooleanAssertion" />
149 <rule ref="rulesets/java/naming.xml/ShortVariable" />
150 <rule ref="rulesets/java/naming.xml/LongVariable">
151 <properties>
153 </properties>
154 </rule>
155 <rule ref="rulesets/java/naming.xml/ShortMethodName" />
156 <rule ref="rulesets/java/naming.xml/VariableNamingConventions" />
157 <rule ref="rulesets/java/naming.xml/MethodNamingConventions" />
158 <rule ref="rulesets/java/naming.xml/ClassNamingConventions" />
159 <rule ref="rulesets/java/naming.xml/AbstractNaming" />
160 <rule ref="rulesets/java/naming.xml/AvoidDollarSigns" />
161 <rule ref="rulesets/java/naming.xml/MethodWithSameNameAsEnclosingClass" />
162 <rule ref="rulesets/java/naming.xml/SuspiciousHashcodeMethodName" />
163 <rule ref="rulesets/java/naming.xml/SuspiciousConstantFieldName" />
164 <rule ref="rulesets/java/naming.xml/SuspiciousEqualsMethodName" />

165 <rule ref="rulesets/java/naming.xml/AvoidFieldNameMatchingTypeName" />
166 <rule ref="rulesets/java/naming.xml/AvoidFieldNameMatchingMethodName" />
167 <rule ref="rulesets/java/naming.xml/NoPackage" />
168 <rule ref="rulesets/java/naming.xml/PackageCase" />
169 <rule ref="rulesets/java/naming.xml/MisleadingVariableName" />
170 <rule ref="rulesets/java/naming.xml/BooleanGetMethodName" />
171 <rule ref="rulesets/java/codesize.xml/NPathComplexity" />
172 <rule ref="rulesets/java/codesize.xml/ExcessiveMethodLength" />
173 <rule ref="rulesets/java/codesize.xml/ExcessiveParameterList">
174 <properties>
176 </properties>
177 </rule>
178 <rule ref="rulesets/java/codesize.xml/ExcessiveClassLength" />
179 <rule ref="rulesets/java/codesize.xml/CyclomaticComplexity" />
180 <rule ref="rulesets/java/codesize.xml/ExcessivePublicCount">
181 <properties>
183 </properties>
184 </rule>
185 <rule ref="rulesets/java/codesize.xml/TooManyFields">
186 <properties>
187 <property name="maxfields" value="40" />
188 </properties>
189 </rule>
190 <rule ref="rulesets/java/codesize.xml/NcssMethodCount" />
191 <rule ref="rulesets/java/codesize.xml/NcssTypeCount" />
192 <rule ref="rulesets/java/codesize.xml/NcssConstructorCount" />
193 <rule ref="rulesets/java/codesize.xml/TooManyMethods">
194 <properties>
195 <property name="maxmethods" value="35" />
196 </properties>
197 </rule>
198 <rule ref="rulesets/java/finalizers.xml/EmptyFinalizer" />
199 <rule ref="rulesets/java/finalizers.xml/FinalizeOnlyCallsSuperFinalize" />
200 <rule ref="rulesets/java/finalizers.xml/FinalizeOverloaded" />
201 <rule ref="rulesets/java/finalizers.xml/FinalizeDoesNotCallSuperFinalize" />
202 <rule ref="rulesets/java/finalizers.xml/FinalizeShouldBeProtected" />
203 <rule ref="rulesets/java/finalizers.xml/AvoidCallingFinalize" />

204 <rule
ref="rulesets/java/logging-jakarta-commons.xml/UseCorrectExceptionLogging"
/>
205 <rule ref="rulesets/java/logging-jakarta-commons.xml/ProperLogger" />
206 
207 <rule ref="rulesets/java/javabeans.xml/MissingSerialVersionUID" />
208 <rule ref="rulesets/java/clone.xml/ProperCloneImplementation" />
209 <rule ref="rulesets/java/clone.xml/CloneThrowsCloneNotSupportedException" />
210 <rule ref="rulesets/java/design.xml/UseSingleton" />
211 <rule ref="rulesets/java/design.xml/SimplifyBooleanReturns" />
212 <rule ref="rulesets/java/design.xml/SimplifyBooleanExpressions" />
213 <rule ref="rulesets/java/design.xml/SwitchStmtsShouldHaveDefault" />
214 <rule ref="rulesets/java/design.xml/AvoidDeeplyNestedIfStmts" />
215 <rule ref="rulesets/java/design.xml/AvoidReassigningParameters" />
216 <rule ref="rulesets/java/design.xml/SwitchDensity" />
217 <rule ref="rulesets/java/design.xml/ConstructorCallsOverridableMethod" />
218 <rule ref="rulesets/java/design.xml/AccessorClassGeneration" />
219 <rule ref="rulesets/java/design.xml/FinalFieldCouldBeStatic" />
220 
221 <rule ref="rulesets/java/design.xml/DefaultLabelNotLastInSwitchStmt" />
222 <rule ref="rulesets/java/design.xml/NonCaseLabelInSwitchStatement" />
223 <rule ref="rulesets/java/design.xml/OptimizableToArrayCall" />
224 <rule ref="rulesets/java/design.xml/BadComparison" />
225 <rule ref="rulesets/java/design.xml/EqualsNull" />
226 <rule ref="rulesets/java/design.xml/ConfusingTernary" />
227 <rule ref="rulesets/java/design.xml/InstantiationToGetClass" />
228 <rule ref="rulesets/java/design.xml/IdempotentOperations" />
229 <rule ref="rulesets/java/design.xml/SimpleDateFormatNeedsLocale" />
230 <rule ref="rulesets/java/design.xml/ImmutableField" />
231 <rule ref="rulesets/java/design.xml/UseLocaleWithCaseConversions" />
232 <rule ref="rulesets/java/design.xml/AvoidProtectedFieldInFinalClass" />
233 <rule ref="rulesets/java/design.xml/AssignmentToNonFinalStatic" />
234 <rule
ref="rulesets/java/design.xml/MissingStaticMethodInNonInstantiatableClass"
/>
235 <rule ref="rulesets/java/design.xml/AvoidSynchronizedAtMethodLevel" />
236 <rule ref="rulesets/java/design.xml/MissingBreakInSwitch" />
237 <rule ref="rulesets/java/design.xml/UseNotifyAllInsteadOfNotify" />
238 <rule ref="rulesets/java/design.xml/AvoidInstanceofChecksInCatchClause" />

239 <rule ref="rulesets/java/design.xml/AbstractClassWithoutAbstractMethod" />
240 <rule ref="rulesets/java/design.xml/SimplifyConditional" />
241 <rule ref="rulesets/java/design.xml/CompareObjectsWithEquals" />
242 <rule ref="rulesets/java/design.xml/PositionLiteralsFirstInComparisons" />
243 <rule ref="rulesets/java/design.xml/UnnecessaryLocalBeforeReturn" />
244 <rule ref="rulesets/java/design.xml/NonThreadSafeSingleton" />
245 <rule ref="rulesets/java/design.xml/UncommentedEmptyMethod" />
246 <rule ref="rulesets/java/design.xml/UncommentedEmptyConstructor" />
247 <rule ref="rulesets/java/design.xml/AvoidConstantsInterface" />
248 <rule ref="rulesets/java/design.xml/UnsynchronizedStaticDateFormatter" />
249 <rule ref="rulesets/java/design.xml/PreserveStackTrace" />
250 <rule ref="rulesets/java/design.xml/UseCollectionIsEmpty" />
251 <rule
ref="rulesets/java/design.xml/ClassWithOnlyPrivateConstructorsShouldBeFinal"
/>
252 <rule
ref="rulesets/java/design.xml/EmptyMethodInAbstractClassShouldBeAbstract" />
253 <rule ref="rulesets/java/design.xml/SingularField" />
254 <rule ref="rulesets/java/design.xml/ReturnEmptyArrayRatherThanNull" />
255 <rule ref="rulesets/java/design.xml/AbstractClassWithoutAnyMethod" />
256 <rule ref="rulesets/java/design.xml/TooFewBranchesForASwitchStatement" />
257 </ruleset>
Apéndice B
Reglas de Checkstyle
B.1. Reglas comunes
1 <?xml version="1.0" encoding="UTF-8"?>

2 <!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
"http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
3 
5 <module name="Checker">
6 <property name="severity" value="warning" />
7 <module name="TreeWalker">
8 <module name="AnnotationUseStyle">
9 <property name="elementStyle" value="ignore" />
10 </module>
11 <module name="JavadocMethod">
12 <property name="logLoadErrors" value="true" />
13 <property name="suppressLoadErrors" value="true" />
14 </module>
15 <module name="JavadocType" />
16 <module name="JavadocVariable" />
17 <module name="JavadocStyle" />
18 <module name="ConstantName" />
19 <module name="LocalFinalVariableName" />
20 <module name="LocalVariableName" />
21 <module name="MemberName" />
129
130 APÉNDICE B. REGLAS DE CHECKSTYLE
22 <module name="MethodName" />

23 <module name="PackageName" />
24 <module name="ParameterName" />
25 <module name="StaticVariableName" />
26 <module name="TypeName" />
27 <module name="AvoidStarImport" />
28 <module name="IllegalImport" />
29 <module name="RedundantImport" />
30 <module name="UnusedImports" />
31 <module name="MethodLength" />
32 <module name="ParameterNumber">
33 <property name="max" value="11" />
34 <property name="tokens" value="METHOD_DEF" />
35 </module>
36 <module name="LineLength">
37 <property name="severity" value="ignore" />
38 <property name="max" value="130" />
39 <metadata name="net.sf.eclipsecs.core.lastEnabledSeverity"
value="inherit" />
40 </module>
41 <module name="EmptyForIteratorPad" />
42 <module name="MethodParamPad" />
43 <module name="NoWhitespaceAfter" />
44 <module name="NoWhitespaceBefore" />
45 <module name="OperatorWrap" />
46 <module name="ParenPad" />
47 <module name="TypecastParenPad" />
48 <module name="WhitespaceAfter" />
49 <module name="WhitespaceAround">
50 
51 <property name="tokens"
52 value="ASSIGN,BAND,BAND_ASSIGN,BOR,BOR_ASSIGN,BSR,BSR_ASSIGN,BXOR,
53 BXOR_ASSIGN,COLON,DIV,DIV_ASSIGN,EQUAL,GE,GT,LAND,LCURLY,LE,
54 LITERAL_ASSERT,LITERAL_CATCH,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,
55 LITERAL_FOR,LITERAL_IF,LITERAL_RETURN,LITERAL_SYNCHRONIZED,
56 LITERAL_TRY,LITERAL_WHILE,LOR,LT,MINUS,MINUS_ASSIGN,MOD,MOD_ASSIGN,
57 NOT_EQUAL,PLUS,PLUS_ASSIGN,QUESTION,SL,SLIST,SL_ASSIGN,SR,SR_ASSIGN,
58 STAR,STAR_ASSIGN,TYPE_EXTENSION_AND" />
59 </module>
B.1 Reglas comunes 131
60 <module name="ModifierOrder" />

61 <module name="RedundantModifier" />
62 <module name="AvoidNestedBlocks" />
63 <module name="EmptyBlock" />
64 <module name="LeftCurly" />
65 <module name="NeedBraces" />
66 <module name="RightCurly" />
67 <module name="AvoidInlineConditionals">
value="inherit" />
70 </module>
71 <module name="EmptyStatement" />
72 <module name="EqualsHashCode" />
73 <module name="HiddenField">
74 <property name="ignoreConstructorParameter" value="true" />
75 <property name="ignoreSetter" value="true" />
76 </module>
77 <module name="IllegalInstantiation" />
78 <module name="InnerAssignment" />
79 <module name="MagicNumber">
80 <property name="ignoreNumbers" value="-1, 0, 1, 2, 10, 100" />
81 </module>
82 <module name="MissingSwitchDefault" />
83 <module name="RedundantThrows">
84 <property name="allowUnchecked" value="true" />
85 <property name="allowSubclasses" value="true" />
86 <property name="logLoadErrors" value="true" />
87 <property name="suppressLoadErrors" value="true" />
88 </module>
89 <module name="SimplifyBooleanExpression" />
90 <module name="SimplifyBooleanReturn" />
91 <module name="DesignForExtension">
value="inherit" />
94 </module>
95 <module name="FinalClass" />
96 <module name="HideUtilityClassConstructor" />
132 APÉNDICE B. REGLAS DE CHECKSTYLE
97 <module name="InterfaceIsType" />

98 <module name="VisibilityModifier">
99 <property name="protectedAllowed" value="true" />
100 </module>
101 <module name="ArrayTypeStyle" />
102 <module name="FinalParameters" />
103 <module name="TodoComment" />
104 <module name="UpperEll" />
105 </module>
106 <module name="JavadocPackage" />
107 <module name="NewlineAtEndOfFile" />
108 <module name="Translation" />
109 <module name="FileLength" />
110 <module name="FileTabCharacter">
112 <metadata name="net.sf.eclipsecs.core.lastEnabledSeverity" value="inherit"
/>
113 </module>
114 <module name="RegexpSingleline">
115 <property name="format" value="[^*]\s+$" />
116 <property name="message" value="Line has trailing spaces." />
117 </module>
118 </module>
Apéndice C
Informes de JUnit
A continuación se presenta un informe sobre el módulo de utilidades comunes generado por

JUnit 4.11.
C.0.1. Resumen
Tests Errores Fallos Omitidos Éxito Tiempo

137 0 0 0 100 % 25,713
C.0.2. Lista de paquetes
Paquete Tests Errores Fallos Omitidos Éxito Tiempo

mrtd.utils.ssl.test 5 0 0 0 100 % 0,640
mrtd.utils.test 117 0 0 0 100 % 4,263
mrtd.utils.http.test 15 0 0 0 100 % 20,810
mrtd.utils.ssl.test
Clase Tests Errores Fallos Omitidos Éxito Tiempo

OK TestSSLUtils 5 0 0 0 100 % 0,640
133
134 APÉNDICE C. INFORMES DE JUNIT
mrtd.utils.test

OK TestArrayUtils 10 0 0 0 100 % 0,000
OK TestBase64Utils 4 0 0 0 100 % 0,000
OK TestCertificateUtils 12 0 0 0 100 % 0,280
OK TestCharUtils 2 0 0 0 100 % 0,000
OK TestClassUtils 2 0 0 0 100 % 0,000
OK TestCollectionUtils 7 0 0 0 100 % 0,000
OK TestDOMUtils 11 0 0 0 100 % 0,360
OK TestFileUtils 2 0 0 0 100 % 0,000
OK TestHexUtils 3 0 0 0 100 % 0,000
OK TestIntegerUtils 11 0 0 0 100 % 0,000
OK TestIOUtils 9 0 0 0 100 % 0,203
OK TestLoggingUtils 7 0 0 0 100 % 0,031
OK TestLongUtils 10 0 0 0 100 % 0,000
OK TestNetUtils 3 0 0 0 100 % 0,110
OK TestResourceUtils 5 0 0 0 100 % 0,000
OK TestStringUtils 17 0 0 0 100 % 0,016
OK TestThreadUtils 2 0 0 0 100 % 3,263
mrtd.utils.http.test

OK TestHTTPSUtils 5 0 0 0 100 % 0,517
OK TestHTTPUtils 7 0 0 0 100 % 20,199
OK TestProxyUtils 3 0 0 0 100 % 0,094
C.0.3. Casos de test
TestHTTPSUtils
Método Tiempo
OK testInitGetURLConnection 0,486
OK testRequestPostForm 0,016
OK testInitPostURLConnection 0,015
OK testPrivateConstructor 0,000
OK testIsHTTPS 0,000
135
TestHTTPUtils
Método Tiempo
OK testFormInputsToByteArray 0,000
OK testcheckEmptyConnection 0,000
OK testInitGetURLConnection 0,000
OK testRequestPostForm 20,199
OK testInitPostURLConnection 0,000
OK testcheckEmptyURL 0,000
TestProxyUtils
Método Tiempo
OK testHttpProxy2Params 0,094
OK testGetHTTPProxy 0,000
TestSSLUtils
Método Tiempo
OK testGetSSLContext 0,593
OK testGetPermissiveTrustManagers 0,031
OK testGetTrustManagers 0,000
OK testGetKeyManagers 0,016
TestArrayUtils
Método Tiempo
OK testByteArraysEquals 0,000
OK testEqualsArray 0,000
OK testCollection2LongArray 0,000
OK testNotContains 0,000
OK testContains 0,000
OK testCollection2IntArray 0,000
OK testCopyOfRange 0,000
OK testIndexOf 0,000
OK testIsEmptyOrNull 0,000
TestBase64Utils
Método Tiempo
OK testDecode 0,000
OK testEncode 0,000
OK testIsBase64Encoded 0,000
TestCertificateUtils
Método Tiempo
OK testGetCertificateChain 0,171
OK testGetTrustAnchors 0,000
OK testSaveCertificate 0,000
OK testGetSubjectKeyIdentifier 0,016
OK testloadPKCS8Key 0,000
OK testJoinWithKeyStore 0,000
OK testGetCertificate 0,000
OK testHasCertificate 0,000
OK testKeystoreCreateWithOverwrite 0,000
OK testGetCertificates 0,093
OK testIsCertificateInKeystore 0,000
TestCharUtils
Método Tiempo
OK testIsNumeric 0,000
TestClassUtils
Método Tiempo
OK testIsInstance 0,000
137
TestCollectionUtils
Método Tiempo
OK testArray2List 0,000
OK testEqualsList 0,000
OK testEnumeration2Iterator 0,000
OK testEqualsEnumeration 0,000
OK testRemoveObjectFromList 0,000
OK testIsEmptyOrNull 0,000
TestDOMUtils
Método Tiempo
OK testDocumentDOM2String 0,000
OK testGetXmlDefaultDeclaration 0,000
OK testStream2Document 0,109
OK testGetElementsByTagName 0,031
OK testHasFirstNodeFirstChild 0,000
OK testSource2Document 0,000
OK testGetElementsByTagNameNS 0,000
OK testString2DOMPrintedString 0,188
OK testPrintDOMElement 0,016
OK testSetNamespaceDefinition 0,016
TestFileUtils
Método Tiempo
OK testCombinePath 0,000
TestHexUtils
Método Tiempo
OK testHexString2ByteArray 0,000
OK testByteArray2HexString 0,000
TestIntegerUtils
Método Tiempo
OK testIntegerList2IntegerArray 0,000
OK testExistsInIntegerArray 0,000
OK testIntegerArray2StringList 0,000
OK testIntegerArray2String 0,000
OK testStringArray2IntegerList 0,000
OK testEqualsIntegerArray 0,000
OK testShortList2IntegerArray 0,000
OK testIntegerArray2IntegerList 0,000
OK testRandomNumbers 0,000
OK testTryParseInt 0,000
TestIOUtils
Método Tiempo
OK testTryClosingStreams 0,000
OK testWriteStreamData 0,031
OK testWriteByteData 0,047
OK testConsumeData 0,016
OK testReadData 0,031
OK testWriteBufferData 0,078
OK testDetectEncoding 0,000
OK testCheckEncoding 0,000
TestLoggingUtils
Método Tiempo
OK testPrintWarnLog 0,000
OK testPrintDebugLog 0,015
OK testPrintInfoLog 0,000
OK testPrintTraceLog 0,000
OK testPrintErrorLog 0,016
OK testLogParameter 0,000
139
TestLongUtils
Método Tiempo
OK testLongArray2StringList 0,000
OK testTryParseLong 0,000
OK testLongList2LongArray 0,000
OK testExistsInLongArray 0,000
OK testLongArray2LongList 0,000
OK testStringArray2LongList 0,000
OK testEqualsLongArray 0,000
OK testLongArray2String 0,000
OK testRandomNumbers 0,000
TestNetUtils
Método Tiempo
OK testGetIPAddress 0,110
OK testIsLoopbackOrLocal 0,000
TestResourceUtils
Método Tiempo
OK testParamGetters 0,000
OK testLoadProperties 0,000
OK testlistKeys 0,000
OK testlistValues 0,000
TestStringUtils
Método Tiempo
OK testIsNumeric 0,016
OK testUnescapeStrings 0,000
OK testFill2Length 0,000
OK testExistsInArray 0,000
OK testClearEmpty 0,000
OK testHasNumbers 0,000
OK testIndexOfIgnoreCase 0,000
OK testReplaceLast 0,000
OK testNormalizeBlanks 0,000
OK testEmptyString 0,000
OK testInitialCase 0,000
OK testByteArray2String 0,000
OK testString2SquaredArray 0,000
OK testArray2String 0,000
OK testRemoveAccents 0,000
OK testIsAlphabetic 0,000
TestThreadUtils
Método Tiempo
OK testTrySleep 3,263
Apéndice D
Informes de Cobertura
A continuación se presenta un informe sobre el módulo de utilidades comunes generado por

Cobertura 2.0.3.
Para la interpretación del informe es importante conocer las siguientes definiciones:
Cobertura de líneas: El porcentaje de líneas ejecutadas por esta prueba de ejecución.
Cobertura de ramas: El porcentaje de ramas ejecutadas por esta prueba de ejecución.
Complejidad: La Complejidad ciclomática media del código según la definición de McCabe

[60] para todos los métodos. Esto es básicamente un recuento del número de diferentes
rutas de código en un método (incrementado en 1 para cada sentencia if, while, etcétera).
N/A: Cobertura de línea y cobertura de ramas aparecerán como No Aplicable (N/A)

cuando Cobertura no puede encontrar información de número de línea en el archivo .class.
Esto sucede para las clases stub y skeleton, las interfaces, o cuando la clase no fue compilada
en modo de depuración.
D.1. Todos los paquetes

Paquete # Clases Cobertura de líneas Cobertura de ramas Complejidad
Todos 23 98 % 1169/1184 96 % 590/609 2,979
mrtd.utils 18 98 % 963/978 97 % 521/537 3,057
mrtd.utils.http 4 100 % 173/173 95 % 61/64 2,560
mrtd.utils.ssl 1 100 % 33/33 100 % 8/8 2,600
141
142 APÉNDICE D. INFORMES DE COBERTURA
D.1.1. Informes por paquete
mrtd.utils
Clases del paquete Cobertura de líneas Cobertura de ramas Complejidad
ArrayUtils 100 % 65/65 100 % 78/78 4,700
Base64Utils 100 % 91/91 100 % 41/41 3,667
CertificateUtils 94 % 130/138 83 % 50/60 2,682
CertificateUtils$1 N/A N/A N/A N/A 2,682
CharUtils 100 % 3/3 100 % 4/4 2,000
ClassUtils 100 % 7/7 100 % 10/10 3,500
CollectionUtils 100 % 42/42 100 % 46/46 4,143
DOMUtils 98 % 76/77 93 % 30/32 2,067
FileUtils 100 % 6/6 100 % 2/2 2,000
HexUtils 100 % 25/25 100 % 6/6 3,000
IOUtils 96 % 127/131 88 % 23/26 3,800
IntegerUtils 100 % 58/58 100 % 52/52 3,083
LoggingUtils 100 % 41/41 100 % 22/22 2,000
LongUtils 100 % 51/51 100 % 48/48 3,300
NetUtils 90 % 18/20 91 % 11/12 3,333
ResourceUtils 100 % 94/94 100 % 40/40 3,385
StringUtils 100 % 121/121 100 % 58/58 2,667
ThreadUtils 100 % 8/8 N/A N/A 2,000
mrtd.utils.http

HTTPSUtils 100 % 43/43 100 % 12/12 1,700
HTTPUtils 100 % 85/85 100 % 32/32 3,000
ProxyUtils 100 % 43/43 85 % 17/20 3,400
ProxyUtils$1 100 % 2/2 N/A N/A 3,400
mrtd.utils.ssl
SSLUtils 100 % 33/33 100 % 8/8 2,600

PFC Javier Hernandez Fisac 2015

Cargado por

Copyright:

Formatos disponibles

PFC Javier Hernandez Fisac 2015

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC Javier Hernandez Fisac 2015

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD CARLOS III DE MADRID

ESCUELA POLITÉCNICA SUPERIOR

INGENIERÍA TÉCNICA DE TELECOMUNICACIÓN

PROYECTO FINAL DE CARRERA

AUTOR: Javier Hernández Fisac

Autor: Javier Hernández Fisac

Tutor: Juan Manuel Estévez Tapiador

Presidente: Andrés Marín López

Secretario: Pedro Peris López

Vocal: Sergio Pastrana Portillo

Habiendo obtenido la siguiente calificación:

Presidente Secretario Vocal

A Marta, la otra mitad de mi paso

Lo que sabemos es una gota de agua; lo que ignoramos es el océano.

Se implementará una solución móvil que permita a un usuario autorizado, típicamente de

Bluetooth/USB: Lectura de huellas dactilares a través de dispositivos con interfaz

Derivación y utilización de claves simétricas para el Control de Acceso Básico al pasaporte

Uso de firma y verificación electrónica de certificados X.509 para la Autenticación Pasiva

Verificación de CRL y cadenas de certificación PKIX de los certificados CSCA.

Intercambio de claves Diffie-Hellman, criptografía asimétrica mediante algoritmos de Crip-

3. Diseño del sistema 41

5. Presupuesto del proyecto 67

A. Reglas PMD 113

B. Reglas de Checkstyle 129

C. Informes de Junit 133

D. Informes de Cobertura 141

2.1. Símbolo visible en pasaportes biométricos MRTD . . . . . . . . . . . . . . . . . . 23

3.1. Esquema general de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1. Selección de modo de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.1. Mecanismos de seguridad en MRTDs . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1. Fases del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

En la actualidad surge cada vez más la necesidad de proporcionar mecanismos electrónicos

Verificación física del documento, incluyendo aquellos mecanismos de seguridad (marcas de

Verificación lógica del documento.

1.2. Objetivos del proyecto

1.3. Estructura del documento

Capítulo 1, Introducción: En este capítulo se describe el proyecto de forma general,

Capítulo 2, Preliminares: En este capítulo se apuntan los conceptos, protocolos, están-

arquitectura elegidas para el proyecto. Se explican las motivaciones para la elección de la

Capítulo 4, Implementación y pruebas: Se presenta una descripción de los componen-

Capítulo 6, Conclusiones y trabajo futuro: Sección en la que se extraen conclusiones

Acrónimos: Se muestran los acrónimos que aplican a esta memoria.

Glosario: Se muestra el glosario de términos que aplican a esta memoria.

Bibliografía: Se especifica la bibliografía utilizada en el desarrollo y documentación del

Apéndices: Se incluyen recursos utilizados para la evaluación de calidad de código e

2.1. Machine Readable Travel Document (MRTD)

El verificador de documentos MRTD se basa principalmente en la parte 1 [1, 2] y la parte 3

Figura 2.1: Símbolo visible en pasaportes biométricos MRTD

En las siguientes secciones se expondrán los puntos más relevantes.

2.1.1. Estructura lógica de los datos (LDS)

Figura 2.2: Estructura de datos de un MRTD [5]

2.1.2. Esquema de Data Groups definidos para LDS

Existen cuatro grupos que deben de incluirse en una LDS:

Aunque no figura en el esquema, se encuentra almacenado en un EF.

El resto de los DGs desde el DG2 (incluido) en adelante son opcionales.

2.1.3. Mecanismos de seguridad

Mecanismo Objetivo Técnica ICAO UE

Tabla 2.1: Mecanismos de seguridad en MRTDs

A continuación se analizan más en detalle estos mecanismos.