FACULTADE DE INFORMÁTICA
Departamento de Tecnoloxías da Información e as Comunicacións
PROXECTO FIN DE CARREIRA DE ENXEÑERÍA TÉCNICA EN
INFORMÁTICA DE XESTIÓN
A mis padres, familiares, amigos y compañeros de facultad porque sin ellos nada
sería posible.
Resumen
Palabras claves
3
Sistema de Gestión de huellas Índice
dactilares en formato digital
ÍNDICE
1. INTRODUCCIÓN 6
4. METODOLOGÍA
4.1. Modelado 36
4.2. Lenguajes y herramientas 53
4.3. Diseño y desarrollo 74
6. CONCLUSIONES 113
4
Sistema de Gestión de huellas Índice
dactilares en formato digital
BIBLIOGRAFÍA 129
5
Introducción
1. INTRODUCCIÓN
Se debe tener en cuenta que gran parte de los sistemas de autenticación actuales están
basados únicamente en el uso de una tarjeta personal y, o, un PIN, con sus
consecuentes problemas de seguridad.
Sea cual sea la técnica seleccionada para una determinada aplicación, tendremos que
ponderar en cada caso las restricciones o peculiaridades que pueden tener cada una
de las técnicas, frente al grado de seguridad añadido que conseguimos y del que
anteriormente no disponíamos. Estas características vienen dadas básicamente por
los siguientes aspectos:
6
Introducción
ü Aceptación por parte del usuario de cada una de las técnicas, en función de
si son o no técnicas intrusivas, cómodas, que mantengan (o al menos lo
parezca) la privacidad, sencillas de usar, etc.
7
Introducción
8
Dominio de la aplicación
Los sistemas que habitualmente utilizamos para identificar a una persona, como el
aspecto físico o la forma de hablar, son demasiado complejos para una computadora;
el objetivo de los sistemas de identificación de usuarios no suele ser identificar a una
persona, sino autenticar que esa persona es quien dice ser realmente. Aunque
seguramente ambos términos nos parecerán equivalentes, para una computadora
existe una gran diferencia entre ellos: imaginemos un sistema de identificación
biométrico basado en el reconocimiento de la retina; una persona miraría a través del
dispositivo lector, y el sistema sería capaz de decidir si es un usuario válido, y en ese
caso determinar de quién se trata; esto es identificación.
9
Dominio de la aplicación
Además de estas características se tiene otra, no técnica sino humana, pero quizás la
más importante: un sistema de autenticación debe ser aceptada por los usuarios, que
serán al fin y al cabo quienes lo utilicen. Por ejemplo, imaginemos un potencial
sistema de identificación para acceder a los recursos de la Universidad, consistente
en un dispositivo que fuera capaz de realizar un análisis de sangre a un usuario y así
10
Dominio de la aplicación
comprobar que es quien dice ser; seguramente sería barato y altamente fiable, pero
nadie aceptaría dar un poco de sangre cada vez que desee consultar su correo.
11
Dominio de la aplicación
El proceso general de autenticación sigue unos pasos comunes a todos los modelos
de autenticación biométrica: captura o lectura de los datos que el usuario a validar
presenta, extracción de ciertas características de la muestra (por ejemplo, las
minucias de una huella dactilar), comparación de tales características con las
registradas en una base de datos, y decisión de si el usuario es válido o no.
12
Dominio de la aplicación
Obtención de
los Modelos
de la BD
Preproc. Extracción
Adquisición de
de la de
datos
Persona Señal Características
Autentificador
Incógnita Decisión
Algoritmo de
Reconocimiento
13
Dominio de la aplicación
Por lo tanto se debe fijar un parámetro o umbral que permita igualar los dos factores,
asegurando de esta manera el óptimo funcionamiento del sistema. Este umbral se
denomina tasa de error igual (Equal Error Rate, ERR), y es el que determinará,
finalmente, la capacidad de identificación del sistema. En la figura 2 se muestra la
relación dicha relación.
14
Dominio de la aplicación
15
Dominio de la aplicación
16
Dominio de la aplicación
Está demostrado que dos dedos nunca pueden poseer más de ocho minucias
comunes, y cada uno tiene al menos entre 30 y 40 de éstas. En la figura 3 se muestra
una imagen de una huella digitalizada con sus minucias. Si la comparación de las
posiciones relativas de las minucias leídas con las almacenadas en la base de datos es
correcta, se permite el acceso al usuario, denegándose obviamente en caso contrario.
17
Estado del Arte
Poner el dedo en un escáner, hablar por un micrófono o mirar de cerca a una cámara
puede ser suficiente para pasar el control de seguridad y acceder a una instalación o
sistema informático. La tecnología biométrica ha traspasado los laboratorios de
espionaje, recintos militares y gubernamentales para extender sus aplicaciones al
mercado empresarial y de consumo.
Los aeropuertos de San Francisco y Nueva York emplean sistemas que reconocen la
geometría de la mano de los empleados. El mismo sistema se utiliza en el aeropuerto
israelí de Tel Aviv para los pasajeros frecuentes de las líneas aéreas El Al. En
Heathrow (Londres) se está realizando una experiencia con 2.000 pasajeros
norteamericanos de las aerolíneas British Airways y Virgin Atlantic (deben estar
registrados y grabar el iris en una base de datos).
18
Estado del Arte
Gobierno de Estados Unidos, salió del grupo de 60 empresas y agencias para crear su
propia tecnología. El Departamento de Defensa cuenta con una organización y un
laboratorio de biométrica, donde prueba la utilidad de los más de 600 productos
existentes en el mercado. El Departamento de Energía desarrolla un escáner
holográfico que analizará, a través de ondas de radio y en tres dimensiones a los
pasajeros para comprobar si esconden armas.
Los expertos consideran que para no atentar contra la intimidad una de las mejores
opciones es usar sistemas híbridos que almacenen los datos biométricos en tarjetas
inteligentes e infraestructuras de clave pública. De esta forma se evita que la
información se encuentre en bases de datos. En la actualidad están en estudio
sistemas que analizan el olor humano, las venas de la mano o la forma de andar.
19
Estado del Arte
Este esquema funciona por ultrasonidos, lo que evita los fallos que hasta ahora se
producían con la lectura óptica por suciedad en la piel o en el dispositivo de escaneo.
La empresa valenciana especializada en tecnologías de seguridad Mundiscan
Electronic Systems ha presentado recientemente el primer sistema infalible de
identificación por huella dactilar basado en ultrasonidos.
20
Estado del Arte
El estudio se basa en conseguir una huella artificial que engañe a los sistemas de
autenticación. El profesor Matsumoto muestra como conseguir artificialmente una
huella que puede servir como la original.
21
Estado del Arte
Dependiendo del nivel de seguridad deseado se puede optar por una solución de
seguridad más efectiva, por ejemplo, el uso de biosensores, cámaras de vigilancia,
combinaciones de varias biometrías, combinaciones con smart cards y PinPad, etc.
De todas formas, todos ellos día a día siguen realizando test de otro tipo de posibles
vulnerabilidades para crear una evolución y un acercamiento asintótico al punto
limite de seguridad del 100%.
22
Estado del Arte
23
Estado del Arte
El objetivo de esta fase es disminuir el rango de variación de grises entre los valles y
las crestas de la imagen para facilitar el proceso en las siguientes etapas.
24
Estado del Arte
25
Estado del Arte
previamente). Después de esto el área de la imagen con ruido, que será excluido en
las siguientes etapas, se define por bajas variaciones en todas las direcciones. En la
figura 6 se muestran las variaciones de una huella y la región de interés obtenida a
partir de esta.
26
Estado del Arte
1 u −u
2
− 0
h1 (u, v ) = 2Πδ ⋅ e
δ
, si : u0 = E[(vc − v )ctg(θ ) + uc ]
0
, en otro caso
1
2
v −v
− 0
h2 (u , v) = ⋅e δ
, si : v0 = E [(u c − u )tg (θ ) + vc ]
2Π δ
0
, en otro caso
∀u, v ∈ [1, L]
27
Estado del Arte
Para simplificar el proceso en las siguientes etapas, se filtra la imagen para perfilar
las crestas de la huella y eliminar las manchas de ciertas áreas. Para conseguir esto,
se extraen primero los componentes de baja frecuencia y a continuación se eliminan
a la imagen original, proporcionando los componentes de alta frecuencia necesarios
para perfilar las crestas, como se deduce de:
Figura 8 . (a) Imagen después del primer filtro perfilador (b) Imagen
después del segundo filtro perfilador con máscara espacial
28
Estado del Arte
3.3.1.6 Simplificación
29
Estado del Arte
30
Estado del Arte
Con el emparejamiento se determina si dos huellas son del mismo dedo o no. Las dos
características usadas en el emparejamiento de huellas son los finales y las
bifurcaciones de las crestas (minucias).
ü Coordenadas x e y de la minucia.
ü La cresta asociada.
(
P = (x1P , y1P ,θ 1P ) ,...,(x MP , yMP ,θ MP )
T T
)
y llamando Q al conjunto de N minucias en la imagen de “entrada” (la que se va a
compara con la imagen plantilla) tenemos:
31
Estado del Arte
(
Q = (x1Q , y1Q ,θ 1Q ) ,..., (x QN , y QN ,θ NQ )
T T
)
Para cada minucia Pi (1 ≤ i ≤ M ) y Qj (1 ≤ j ≤ N ) en el conjunto de minucias de la
imagen de “entrada” y de la plantilla, denotamos rotate[i][j] como el ángulo de
rotación entre la imagen de “entrada” y la plantilla, tomando Pi y Qj como el punto
de referencia de la imagen. Si podemos tomar Pi y Qj como un par de minucias, las
crestas asociadas de Pi y Qj son iguales dentro de un cierto grado rotate[i][j], que
asumiremos de un valor entre 0 y 360, en otro caso pondremos rotate[i][j] como 400
para representar el hecho de que Pi y Qj no se corresponden con un par de minucias.
Si Pi y Qj no son del mismo tipo, se asigna 400 a rotate[i][j]. Por otra parte
denotaremos por R y r a las crestas a las que pertenecen de las minucias Pi y Qj . Se
compara R con r para obtener las diferencias de estas dos crestas de acuerdo a la
ecuación siguiente:
1 L
Diff _ dist = ∑ R( d i ) − r ( d i )
L i =0
32
Estado del Arte
1 L
Diff _ ang = ∑ R (αi ) − r (αi )
L i= 0
ri
( ) (
2
xi − x r + xi − y r
2
)
− r
[ ][ ]
y y
e = tan −1
i
+ rotate i j
i
x − xr
θi i
θi − θ
r
Donde (xr, yr, θr)T es la coordenada de la minucia de referencia, y (ri, ei, θi)T es la
representación de la minucia en el sistema de coordenadas polares (ri representa la
33
Estado del Arte
((
Pi s = r1 p , e1p , θ 1p ) ,..., (r
T
M
p
, e Mp , θ Mp )
T
)
= ((r ) (
, e1Q ,θ 1Q ,..., rNQ , e QN ,θ NQ ))
T T
Qis 1
Q
34
Estado del Arte
35
4. Metodología
Para el desarrollo del proyecto, seguiremos una metodología clásica, que incluirá los
siguientes pasos:
4.1 Modelado
Puesto que va a ser este el lenguaje que vamos a utilizar para modelar nuestra
aplicación, haremos una breve introducción y resaltaremos sus principales
características:
36
Lenguaje Unificado de Modelado
Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar
y luego desplegar tales sistemas.
37
Lenguaje Unificado de Modelado
El vocabulario y las reglas de un lenguaje como el UML indican cómo crear y leer
modelos bien formados, pero no dicen que modelos se deben crear ni cuando se
deberían crear. Esta es la tarea del proceso de desarrollo de software.
38
Lenguaje Unificado de Modelado
39
Actores del sistema
Nuestro sistema cuenta con dos tipos de usuarios, llamados actores en UML.
Usuario Administrador
Actor usuario: Representa la persona que hace el envío de la imagen de su huella así
como los datos referentes a ella, a través de la web, para pasar a formar parte de la
base de datos. Tiene también la posibilidad de autenticarse para verificar que su
huella y datos se han incorporado a la base de datos.
40
Casos de uso
Alta_admin
<<include>>
<<uses>>
<<include>> <<uses>>
Modificación Visualización
Gestión
Administrador
(from Actores)
<<include>> <<uses>>
<<uses>>
Baja
Autent_admin
41
Casos de uso
Para este caso de uso se va a usar la autenticación biométrica, que nos va a asegurar
el acceso exclusivo, por parte del administrador, a las páginas desde las que se
realizan las tareas de administración (altas, bajas, modificaciones).
El caso de uso “Alta del administrador” (Alta_admin.) tiene como fin introducir un
usuario, que previamente lo halla solicitado, en la base de datos de nuestra
aplicación. Para ello lo que realiza es el cambio de valor de un campo de la tabla de
usuarios.
Se trata de cambiar el campo Alta de ‘F’ a ‘T’, es decir de False a True. De este
modo un usuario con el campo Alta a ‘T’ estará dado de alta en la base de datos,
mientras que uno que lo tenga a ‘F’, se encontrará en espera.
El caso de uso “Baja” borrará de la base de datos a un usuario, tanto los datos
personales como los datos de las huellas enviadas. En este último punto se
eliminarán físicamente las imágenes de las huellas, así como las plantillas generadas
a partir de estas.
42
Casos de uso
Por lo tanto este proceso se realizará para altas, bajas y modificaciones con el fin de
que el administrador sepa en todo momento lo que está realizando. Así primero se
visualizarán todos los usuarios y una vez seleccionado uno, se le mostrará la
información completa referente a este, para que confirme la operación que está a
punto de realizar.
43
Casos de uso
Alta_nuevo_usu
Alta_usuario
<<use>>
Alta_existente_usu
Usuario
(from Actores)
generar_plantilla
Autenticar
El caso de uso “Alta” realizado por los usuarios vía web, se especializa en dos: en
primer lugar están los usuario que por primera vez solicita el alta en nuestra base de
datos, en segundo lugar tenemos a los usuarios que ya hayan solicitaron el alta en
algún momento y posteriormente deciden enviar alguna otra huella.
44
Casos de uso
El caso “Generar plantilla” genera una plantilla a partir de una imagen. Esta plantilla
almacena las características (minucias) extraídas de la huella, que la van a hacer
única. De esta manera guardamos información referente a la persona, pero que no la
compromete en ningún momento, utilizándose para autenticar la huella en “vivo”.
45
Lenguajes y Herramientas
La base de datos va a estar formada por tres tablas con las que mantenemos la
información sobre los usuarios en una de ellas (tabla usuarios), información sobre las
huellas en la otra (tabla huellas), y una última en la que mantendremos la
información que concierne al administrador (tabla admin).
ü Cada persona podrá hacer un envío entre una y diez imágenes de huellas,
una por cada uno de sus dedos.
ü Las huellas se asociarán a los usuarios por medio del DNI de estos.
46
Lenguajes y Herramientas
En nuestro caso mantendremos en la base de datos tanto las imágenes de las huellas
como las plantillas generadas. Este no es el procedimiento habitual ya que
precisamente la ventaja de almacenar las plantillas es la de no guardar información
relevante del usuario, como lo son sus huellas. Además, a partir de las plantillas no
hay forma de reconstruir las huellas, por lo que la identidad del usuario está
totalmente protegida.
Otra ventaja de los sistemas biométricos que almacenan las plantillas características
de las personas, es que estas plantillas son del orden de 100 veces menores que las
imágenes a partir de las que se generan. Por lo tanto, la base de datos será
considerablemente menor.
47
Lenguajes y Herramientas
Para un estudio de la estructura de los elementos del dominio, así como de sus
relaciones, utilizaremos el modelo Entidad-Relación (ER). La figura 14 muestra el
modelo entidad-relación resultante:
Persona id_persona
Dirección
CP Nombre Nombre
Plantilla
Provincia
Pais 1
email id_huella
http N
mano
Huella
dedo
plantilla
48
Lenguajes y Herramientas
Entidad Administrador
Atributos:
ID_ADMINISTRADOR Numérico. Clave principal.
NOMBRE Nombre del Administrador.
PLANTILLA Plantilla generada a partir de la huella.
Entidad Huella
Atributos:
ID_HUELLA Clave principal de la huella
ID_USUARIO Identificador del usuario al que pertenece la huella.
MANO Mano a la que pertenece la huella.
DEDO Dedo al que pertenece la huella.
PLANTILLA Plantilla que se obtiene a partir de la imagen
49
Lenguajes y Herramientas
Entidad Usuario
Persona que nos envía su/s huella/s en formato digital y que pasarán a formar parte
de nuestra base de datos.
Atributos:
ID_USUARIO Numérico. Clave principal.
NOMBRE Nombre del Usuario.
DIRECCIÓN Dirección donde reside el usuario, será una cadena de
texto.
C.P. Código Postal del lugar de residencia del usuario.
LOCALIDAD Localidad de residencia del usuario.
PROVINCIA Provincia de residencia del usuario.
PAIS País de residencia del usuario.
EMAIL Dirección correo del usuario.
WEB Página web del usuario.
ALTA Estado en el que se encuentra (T/F).
50
Lenguajes y Herramientas
El estudio del modelo entidad-relación nos lleva al siguiente esquema de tablas, que
compone un modelo relacional completo del dominio de la aplicación.
Tabla Administradores
Tabla Usuarios
51
Lenguajes y Herramientas
Dependencias Funcionales
3º Forma Normal
Tabla Huellas
Dependencias Funcionales
ID_HUELLA -> USUARIO, MANO, DEDO, PLANTILLA.
3º Forma Normal
52
Lenguajes y Herramientas
<HTML>...<HTML>
Documentos
HTML
53
Lenguajes y Herramientas
Rápidamente se hizo evidente que si una persona podía revisar los documentos
gestionados por el servidor Web, también podía hacerlo un programa de texto
procesado como una secuencia de comandos Perl. El navegador Web no aprecia la
diferencia porque el resultado de una petición HTTP sigue siendo un flujo de datos
en HTML. Más aún, el navegador puede enviar algo más que una simple petición:
puede enviar parámetros, incluyéndolos en la URL (Universe Reason Locate) o
enviando un flujo de datos con la petición. Esto sugiere que una petición HTTP
puede interpretarse como una consulta a una base de datos y los resultados de la
consulta se pueden usar para construir dinámicamente un documento HTML. Con el
desarrollo del servidor Web NCSA HTTPd llegó una nueva especificación, los CGI
(Common Gateway Interface).
54
Lenguajes y Herramientas
Programa CGI
Base
de datos
Figura 17. Contenido dinámico generado por una secuencia de comandos CGI
Los CGI normalmente generan un nuevo proceso para cada petición HTTP. Esto
supone un problema cuando el tráfico es escaso, pero provoca sobrecarga cuando el
nivel de tráfico aumenta. En esta situación, los CGI no se ajusta, a nuestras
necesidades.
55
Lenguajes y Herramientas
Los servlets y las páginas JSP operan desde un solo ejemplar o instancia que
permanece en la memoria y utiliza múltiples subprocesos para responder a distintas
peticiones de forma simultánea. La figura 17 muestra ilustra el uso de esta
tecnología.
Motor de servlets
Servicios J2EE
Otros
Base servicios
de datos
56
Lenguajes y Herramientas
57
Lenguajes y Herramientas
Para el uso de la API del lector tenemos varias posibilidades: una es el uso de la API
C/C++ que nos viene con la documentación del dispositivo de huellas dactilares
disponible, y que nos llevaría a la utilización de la tecnología CGI del lado del
servidor; la otra posibilidad con la que contamos es el uso de Java aprovechando las
clases Java (java wrappers) que nos vienen con el entorno de desarrollo para el
programador.
El uso de CGI nos llevaría a utilizar la tecnología de Microsoft ASP (Active Server
Pages) para la generación dinámica de páginas, y todo ello trabajando bajo el
Servidor de Microsoft (IIS). Por el otro lado el uso de Java como leguaje de servidor
nos llevaría a utilizar JSP (Java Server Pages) para la generación dinámica de
páginas; pudiendo optar por una serie de servidores que funcionen como
contenedores de servlets: JRun, Tomcat, etc.
Hemos optado por el uso de Java y sus tecnologías Servlets, JSP y Javabeans como
lenguaje para el desarrollo de los distintos módulos de la aplicación por
una serie de motivos que discutimos a continuación:
Java presenta una serie de ventajas frente a otros lenguajes, entre los cuales
destacamos los siguientes:
ü Seguridad
58
Lenguajes y Herramientas
ü Core API
ü Estándares abiertos
59
Lenguajes y Herramientas
ü Distribuido y dinámico
ü Orientada a objetos
ü Multitarea
Una aplicación monotarea tiene un thread (hilo de proceso) que será quien
se encargue de ejecutar todo lo que se le pida. Con este sistema únicamente
puede desarrollar una tarea cada vez.
60
Lenguajes y Herramientas
61
Lenguajes y Herramientas
ü Rendimiento
ü Simplicidad
ü Sesiones http
Al ser aplicaciones Java, los servlets tienen acceso directo a toda la gama de
características Java, como el uso de subprocesos, acceso a redes y
conectividad a base de datos.
62
Lenguajes y Herramientas
ü Comunicación
ü Seguridad
Una Página Java en servidor,o “Java Server Pages” (JSP) es una plantilla para una
página Web que emplea código Java para generar un documento HTML
dinámicamente. Las páginas JSP se ejecutan en un componente del servidor
conocido como contenedor de JSP, que las traduce a servlets Java equivalentes.
Por esta razón los servlets y las páginas JSP están íntimamente relacionados. Lo que
se puede hacer con una tecnología es, en gran medida, también posible con la otra;
aunque cada una tiene sus capacidades propias. Como son servlets, las páginas JSP
tienen todas las ventajas de los servlets, pero además tienen ventajas propias:
ü Como las páginas JSP son similares al HTML, tienen mayor compatibilidad
con las herramientas de desarrollo Web.
63
Lenguajes y Herramientas
64
Lenguajes y Herramientas
4.2.3 Herramientas
Apache ha sido desarrollado por diversos de usuarios que han tenido que reparar sus
fallos alguna vez y que han agregado funciones al software del servidor web,
disponible en los primeros días de la World Wilde Web.
Es uno de los mejores servidores de Web utilizado en la red Internet desde hace
mucho tiempo, únicamente le hace competencia un servidor de Microsoft, el IIS. Por
lo que éste servidor es uno de los mayores triunfos del software libre.
65
Lenguajes y Herramientas
ü Alto desempeño.
Para conseguir que nuestro servidor web sea un servidor seguro, es conveniente
utilizar la tecnología SSL (Secure Socket Layer) que detallamos a continuación:
SSL es una tecnología desarrollada por Netscape en 1994 junto con su primer
navegador, para asegurar la privacidad y fiabilidad de las comunicaciones entre dos
aplicaciones. Utiliza un sistema de cifrado asimétrico basado en claves
pública/privada para negociar una clave de sesión que se utilizará para establecer
una comunicación basada en cifrado simétrico. SSL es el protocolo de cifrado más
utilizado en Internet en estos momentos y es el más usado en servidores web donde
se solicita información confidencial, además es abierto y de dominio público, y su
implementación es sencilla.
66
Lenguajes y Herramientas
ü Cifrado de datos
ü Autenticación de servidores
ü Integridad de mensajes
ü Autenticación de cliente
67
Lenguajes y Herramientas
SSL puede tener una clave de sesión de 40 bits o de 128 bits, dicha clave es
generada en cada transacción. La longitud de la clave hará más difícil romper el
cifrado. La mayoría de los navegadores soportan una clave de 40 bits para sesiones
SSL, mientras que las últimas versiones soportan claves de sesión de 128 bits.
ü Verificación de la Identidad
ü Mantener la seguridad
ü Facilidad de Utilización
A pesar de la gran seguridad que debe tener, el servicio debe ser de fácil
uso para los clientes sin grandes traumatismos que ocasionen confusiones.
68
Lenguajes y Herramientas
Tomcat, uno de los proyectos de código abierto liderado por la Apache Software
Foundation, es una aplicación web basada en Java creada para ejecutar servlets y
páginas JSP, siendo la implementación oficial de referencia de las especificaciones
Servlet 2.3 y JSP 1.2.
69
Lenguajes y Herramientas
ü Simple y Completo
70
Lenguajes y Herramientas
Para albergar nuestra base de datos tenemos una gran cantidad de sistemas gestores
de bases de datos. Barajando las distintas características de cada uno finalmente
hemos optado por el uso de MySQL.
Una característica importante es que consume muy pocos recursos, tanto de CPU
como de memoria. Se sacrificaron algunas características esenciales en sistemas más
“serios” con este fin
Ventajas
JDBC (Java Data Base Connectivity) proporciona una interfaz estándar con el
servidor de base de datos. Provee una API que podemos usar sin importar qué base
de datos se esté usando.
71
Lenguajes y Herramientas
Interfaz JDBC
Mysql Connector es un “driver” creado por Mysql AB que nos permitirá trabajar con
Mysql desde programas escritos en Java. A diferencia de otros “drivers”, este es de
libre distribución, y tiene un buen rendimiento.
72
Lenguajes y Herramientas
73
Diseño e Implementación
4.3.1 Despliegue
Terminal
del
Administrador
Servidor
Computadora
de la
del Usuario
aplicación
Lector de
huellas
Servidor
Web
Base
de
Datos
74
Diseño e Implementación
4.3.2 Gestión
Clases
Auxiliares
Clases Clases
Fingerprint mySql-connector
75
Diseño e Implementación
Este paquete representa las clases nativas de Java. Entre las que se encuentran las
incluidas en los paquetes estandares: java.lang., java.util., java.io., java.awt., etc.
ID id_persona
Superclase
genérica de
Clase para listar Clase para
cualquier clase del
timagen el contenido de mostrar todos los
dominio
la base de datos referentes a
(from Logical View)
datos un usuario
id_imagen
recoger
76
Diseño e Implementación
Las clases del dominio son el resultado del planteamiento del problema, en la forma
de situaciones sacadas del mundo real. La figura 22 muestra el diagrama de clases
del dominio.
tElemento
ID
tPersona
timagen
(from Logical View)
(from Logical View)
id_persona
id_imagen
Huella
77
Diseño e Implementación
Este paquete contiene las clases propias de la interfaz de la aplicación, son clases que
se utilizan para mostrar y capturar información referente a las clases del dominio. En
el caso de nuestra aplicación se trata de páginas, tanto html como jsp. La figura 23
muestra el diagrama de clases de la interfaz.
Index
autenti_admin
Cada clase representa una página alojada en nuestro servidor, que nos mostrará la
información que necesitemos en cada momento en función de la tarea que se vaya a
realizar.
Index: Esta clase representa la página de inicio de nuestra aplicación y desde la que
se podrá acceder a cada página en función de lo que se desee hacer.
78
Diseño e Implementación
PAGINAS ADMINISTRADOR
ad_alta: Esta clase representa la página en la que se muestran los usuarios que estén
en la base de datos, en espera de ser dados de alta, para que el administrador decida a
quien desea dar de alta.
ad_borrar: Lista los usuarios dados de alta, para que el administrador decida a quien
quiere dar de baja.
ad_modif.: Clase encargada de mostrar los usuarios que están dados de alta en la
base de datos, para que el administrador elija el que desee modificar.
PAGINAS USUARIO
Usu_alta: Muestra el formulario que debe rellenar el usuario nuevo que quiera pasar
a formar parte de nuestra base de datos, tanto con campos para los datos personales
como para que nos envíe los ficheros con las imágenes.
79
Diseño e Implementación
Usu_huellas: En caso está pensado para aquel usuario que ya solicitó pasar a formar
parte de la base de datos, y que pasado un tiempo decide mandar nuevas huellas. Se
le solicita que se identifique como usuario existente y se le permite mandar nuevas
huellas.
80
Diseño e Implementación
SmartUpload
SmartUpload()
getFiles()
getRequest()
getBinaryData()
getSize()
Request
setAllowedFilesList()
setContentDisposition()
getParameter()
setDeniedFilesList()
getParameterName()
setDenyPhysicalpath()
getParameterValues()
setMaxFileSize()
setTotalMaxFileSize()
downloadField()
downloadFile()
save()
upload()
uploadlnFile() File
fileToField()
getBinaryData()
getContentDisp()
getContentString()
Files
getContentType()
getFieldName()
getCount() getFieldExt()
getFile() getFileName()
getSize() getfilePathName()
getSize()
getSubTypeMIME()
getTypeMIME()
isMissing()
saveAs()
81
Diseño e Implementación
Estas clases conectan con el gestor de base de datos desde las páginas jsp y beans. A
esta clase pertenece por ejemplo la clase Driver.class que permite crear una
instancia del driver que nos conectará con la mysql. Otras clases también importantes
son: Connection.class, ResultSet, etc.
Estas clases pertenece a la API Java que permite acceder tanto al lector de huellas,
como a las funciones propias de la clase Fpr, la cual posibilita la autenticación y la
generación de una plantilla a partir de una imagen de huella.
82
Diseño e Implementación
Entrar
Pedir datos
Identificacion
Aceptar
Pedir dedo
Poner dedo
autenticar( )
83
Diseño e Implementación
1: Entrar
4: Identificacion 2:
5: Aceptar 6:
: Interfaz : Aplicación
3: Introducir datos
: (Administrador) 9:
7: autenticar( )
8:
: Administrador
84
Diseño e Implementación
: Interfaz : Aplicación
: Administrador
Pulsar tarea
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
85
Diseño e Implementación
1: Tarea
4: Seleccionar usuario
: Interfaz
7: Mostrar datos
: (Administrador)
3: 2: Listar usuarios
6: 5: Mostrar usuario
: Aplicación
86
Diseño e Implementación
Pulsar alta
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Confirmar
OK
alta_admin( )
87
Diseño e Implementación
1: Alta
4: Seleccionar usuario
9: OK
: Interfaz
7: Mostrar datos
: (Administrador) 8: Confirmar
2: Listar usuarios
5: Mostrar usuario
3:
10:
6:
13:
12:
: Usuario : Aplicación
11: alta( )
88
Diseño e Implementación
Pulsar Baja
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Confirmar
OK
baja( )
borrar( )
Borrar huella
89
Diseño e Implementación
2: Listar usuarios
1: Baja 5: Mostrar usuario
4: Seleccionar usuario 10:
9: OK
: Interfaz : Aplicación
7: Mostrar datos 3:
: (Administrador) 8: Confirmar 6:
15:
11: baja( )
12:
14:
13: borrar( )
Borrar huella
: Huella
: Administrador
90
Diseño e Implementación
Pulsar modif.
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Modificar datos
Confirmar
OK
actualizar( )
91
Diseño e Implementación
1: Modif
4: Seleccionar usuario
8: Modifficar datos
10: OK
: Interfaz
7: Mostrar datos
: (Administrador) 9: Confirmar
2: Listar usuarios
3: 5: Mostrar usuario
6: 11:
14:
13:
: Usuario : Aplicación
12: actualizar( )
92
Diseño e Implementación
: Usuario
Pulsar alta
Mostrar formulario
Introd. datos
Aceptar
alta_usu( )
alta( )
Alta huella
93
Diseño e Implementación
1: Pulsar alta
4: Introd. datos 2: Mostrar formulario
5: Aceptar 6:
: Interfaz : Aplicación
: (Usuario) 3:
11:
Crear huella
9: alta( )
: Huella
: Usuario
94
Diseño e Implementación
: Usuario
Introducir datos
Aceptar
alta( )
alta huella
95
Diseño e Implementación
1: Pulsar alta
4: Introd. datos 2: Mostrar formulario
5: Aceptar 6:
: Interfaz : Aplicación
3:
: (Usuario) 9:
8:
Crear huella
7: alta( )
: Huella
96
Diseño e Implementación
Pulsar autenticar
Pedir datos
Introducir Datos
OK
Pedir dedo
Poner dedo
Autenticar
97
Diseño e Implementación
1: Pulsar autenticar
4: Introducir datos 2: Pedir datos
5: OK 6: Pedir dedo
8: Poner dedo 9:
: Interfaz : Aplicación
3:
: (Usuario) 7:
12:
: Usuario
98
Diseño e Implementación
4.3.3 Visualización
Página principal
Desde la página principal, se accede tanto a las tareas de administración como a las
utilidades de usuario.
99
Diseño e Implementación
En esta pantalla se muestra un formulario con los campos de los datos personales
requeridos a los usuarios que quieran darse de alta en el sistema. Además se incluye
un campo para cada uno de los dedos de ambas manos, gestionando el envío de las
imágenes digitalizadas de los mismos.
100
Diseño e Implementación
En esta pantalla se muestra un formulario con los campos de los datos personales
requeridos para identificarlo como un usuario existente. Además se incluye un
campo para cada uno de los dedos de ambas manos, gestionando el envío de las
imágenes digitalizadas de los mismos.
101
Diseño e Implementación
Autenticar Usuario
En esta pantalla comprobamos que un usuario que se haya dado de alta en la base de
datos con alguna imagen de huella, se autentica correctamente. Comparamos la
imagen “en vivo”, la que está sobre el lector, con la que está en la base de datos, y
mostramos el resultado.
102
Diseño e Implementación
Tras obtener los datos solicitados en la pantalla de la figura 39, se inicia el proceso
de autenticación. Si la autenticación tiene éxito se muestra la imagen del dedo del
usuario, así como diversos datos referentes a esta: calidad de la imagen, tamaño,
características adquiridas en el proceso de captura, nivel de coincidencia con la
huella en la base de datos, etc.
103
Diseño e Implementación
Autenticar Administrador
104
Diseño e Implementación
Alta Administrador
105
Diseño e Implementación
106
Diseño e Implementación
Baja Administrador
Esta página proporciona una relación de los usuarios dados de alta en la base de
datos para que el administrador gestione posible bajas. El proceso de baja borra tanto
los datos personales como las huellas y plantillas que se hayan podido generar.
107
Diseño e Implementación
108
Diseño e Implementación
Modificar Administrador
En esta página se podrán modificar los datos personales de un usuario dado de alta en
la base de datos, al pulsar sobre la opción modificar por parte del administrador. En
primer lugar, se visualiza una página con los usuarios dados de alta (figura 49).
109
Diseño e Implementación
110
Validación
Cada imagen en la base de datos se compara con su propia plantilla y con las otras
49 plantillas. Si la comparación de una huella con una plantilla del mismo dedo
resulta exitosa, se considera una autenticación correcta, en caso contrario, estamos
ante un falso rechazo. Si se obtiene una autenticación correcta al comparar una
huella con otra que no pertenece al mismo dedo, estamos ante lo que se denomina
una falsa aceptación.
num_correctas
porcentaje de autenticación = × 100
num _ correctas + numero _ falsas
num _ rechazadas
porcentaje de rechazo = × 100
50
111
Validación
% Autenticación % Rechazo
Usuario 1 99.9 % 13.32 %
Usuario 2 99.88 % 12.82 %
Usuario 3 99.65 % 12.13 %
Usuario 4 99.45 % 13.72 %
Usuario 5 98.94 % 10.41 %
112
Conclusiones
6. Conclusiones
Aunque parezca algo un tanto futurista, sobre todo pensando en otro tipo de
reconocimiento como los basados en sensores de calor o geometría facial, la
tecnología avanza a pasos agigantados, sobre todo en las últimas décadas, y no sería
raro que se empezara por implantar en computadoras de acceso restringido y con
información muy crítica, como en empresas, bancos, etc. Desde ese momento, el que
cualquier persona tenga un sistema biométrico en su computadora de sobremesa hay
un paso, o un abismo dependiendo por donde avance la tecnología.
113
Manual de Administrador
Manual de Administrador
V1.0
Instalación
Base de datos
Para instalar la base de datos en el sistema sobre el que va a trabajar se tiene que:
Instalación de MySQL
Primero se debe obtener una copia de una distribución de MySQL. Para el desarrollo
del presente proyecto se utilizó la última versión disponible MySQL-3.23.49.
114
Manual de Administrador
‘mysql –help’ muestra todas las opciones que se le pueden pasar a mysqld en el
arranque.
Para iniciar y parar el servicio MySQL, se utilizan con los siguientes comandos
respectivamente:
115
Manual de Administrador
Tras instalar correctamente MySQL, se deberá añadir nuestra base de datos para que
pueda ser utilizada por la aplicación. Concretamente se trata de un directorio llamado
base que situamos en el directorio data en la ubicación de instalación de MySQL:
D:\mysql\data\base
Esta base de datos contiene las tres tablas que requiere nuestra aplicación para su
funcionamiento: usuarios, huellas, administradores.
Servidor Apache
Instalación Apache
El software de Servidor Apache está disponible en el sitio web del Grupo Apache y
en decenas de sitios mirrow de todo el mundo. Se debe obtener una distribución
binaria gratuita de Apache, apache<versión>, disponible en su página web oficial
http://www.apache.org.
116
Manual de Administrador
Utilizaremos la opción reiniciar para que tenga efecto cualquier cambio realizado en
los archivos de configuración de Apache, sin necesidad de detener y volver a iniciar
el servidor.
Instalación SSL
Primero se deben tener los módulos mod_ssl y OpenSSL, que podemos obtener en el
sitio http://www.modssl.org/contrib/.
117
Manual de Administrador
Port 443
Listen 80
Listen 443
ServerName www-mi-servidor.com
Para comprobar que el puerto 443 funciona correctamente se debe escribir en nuestro
navegador http://mi-servidor.com:443/.
118
Manual de Administrador
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
SSLLog logs/SSL.log
SSLLogLevel info
<VirtualHost www.my-server.dom:443>
SSLEngine On
SSLCertificateFile conf/ssl/my-server.cert
SSLCertificateKeyFile conf/ssl/my-server.key
</VirtualHost>
119
Manual de Administrador
Iniciar el servidor desde la línea de comandos con el propósito de ver los mensajes de
error que impiden iniciar Apache. Si algo no funciona, Apache escribe mensajes
significativos en la pantalla y, o en los archivos error.log y SSL.log en el directorio
Apache\logs.
Servidor Tomcat
Instalación Tomcat
Tras instalar este software en nuestra computadora se debe obtener el archivo binario
de versión apropiada de jakarta-tomcat<versión>. En el proyecto se utiliza
jakarta-tomcat3.3.1.
JAVA_HOME - d:\jdk
TOMCAT_HOME - d:\jakarta-tomcat
120
Manual de Administrador
La aplicación hace uso del directorio donde tenemos instalado Tomcat, por ello
introduciendo una variable que le indique este directorio, obteniendo una aplicación
independiente del lugar donde se instale.
121
Manual de Administrador
<context-param>
<param-name>directorio</param-name>
<param-value>D:/<dir_tomcat>t/webapps/proyecto/upload/
</param-value>
</context-param>
122
Manual de Administrador
Del nuevo fichero hay que quitar todas las referencias a JServMount y cambiarlas por
JkMount (no se pueden mezclar JServ y mod_jk). Además al principio del fichero
hay que poner las siguientes líneas:
include c:\<dir_tomcat>\conf\mio-tomcat-apache.conf
con esto indicamos a Apache las nuevas directivas para los servlets.
Ya tenemos instalado el módulo. Arrancamos en primer lugar Tomcat y a
continuación Apache; en este último al arrancar debe de salir un mensaje que indique
que estamos utilizando mod_jk.dll (algo similar a mod_jk.dll running).
Hay que tener en cuenta que Tomcat siempre se debe arrancar antes que Apache, y si
se para, hay que parar Apache y volver a arrancat Tomcat primero.
A continuación se describe lo que contiene cada directorio de nuestra aplicación:
Directorio Raíz
Contiene las páginas .html de nuestra aplicación, entre las que se encuentra la página
de inicio.
123
Manual de Administrador
Directorio JSP
Como su propio nombre indica contiene las páginas .jsp, que junto con las páginas
.html forman la interfaz de nuestra aplicación.
Directorio Recursos
Aquí se mantienen los archivos (imágenes, botones, iconos, etc) que se van a usar en
las páginas de la aplicación.
Directorio Upload
Aquí es donde se transfieren las imágenes de las huellas de los usuarios. Además
mantiene las plantillas generadas por la aplicación a partir de las imágenes de huellas
digitalizadas.
Directorio Admin
Este es un subdirectorio de Upload y en el mantendremos las plantillas de los
administradores que tengan privilegios para gestionar la aplicación.
Directorio WEB-INF
Aquí está el archivo descriptor de despliegue web.xml, que se utiliza para configurar
los servlets y otros recursos que forman parte de la aplicación web.
Además incluye dos subdirectorio, el lib y classes:
Directorio lib
Contiene los archivos .jar. Las clases de cualquier archivo .jar que se encuentre en
este directorio se ponen automáticamente a disposición del cargador de clases sin
tener que estar explícitamente listadas en la ruta de clases.
Aquí es donde situaremos las librerías de clases para el acceso al lector de huellas
(FPJni.jar) y las clases que nos permitirán acceder a MySQL desde las páginas
(mysql-connector-java-3.0.1-beta-bin.jar).
124
Manual de Administrador
Directorio classes
Este directorio contiene servlets y otras clases. Aquí se pueden ubicar los paquetes
que utilizados en la aplicación, en nuestro caso el paquete jspSmartUpload (com) y
las clases desarrolladas para modelar la aplicación: usuario, huella y administrador.
JspSmartUpload
Para poder utilizar este paquete en las páginas JSP de nuestra aplicación, se tendrá
que ubicar en el directorio de la aplicación. Concretamente la estructura de directorio
de Tomcat nos indica que hay que situarlo en el directorio WEB-INF\classes.
Lector de huellas
125
Manual de Administrador
La API Java que se utiliza en nuestra aplicación esta en el archivo jar ‘FPJni.jar’,
que no son más que un conjunto de clases “empaquetadas”.
126
Comandos de creación de tablas
Para la creación de las tablas de la base de datos, se incluye a continuación una serie
de comandos SQL, utilizando los comandos SQL92 (ANSI SQL) soportados por
MySQL, se decidiera migrar la aplicación a otra base de datos estos comandos nos
facilitarían las cosas. Por otra parte MySQL soporta SQL92, aunque le añada algunas
extensiones.
Tabla Administradores
127
Comandos de creación de tablas
Tabla Usuarios
Tabla Huellas
128
Bibliografía
Bibliografía
[1] Damon Hougland, Aarón Tavistock. “Guía esencial JSP”. Pearson Educación
S.A, Madrid, 2002.
[4] Rich Bowen & Ken Coar, Servidor Apache al Descubierto. Pearson Educación,
S.A. Madrid, 2000.
[5] Lemay, Laura, “Aprendiendo HTML 4 para web en una semana”. Prentice Hall,
México, 1998.
[6] Juan Carlos Orós, “Diseño de páginas Web interactivas con JavaScript”. RA-MA
Editorial, Madrid, 1998.
[7] Graham Hamilton, Rick Cattell, Maydene Fisher, “JDBC Database Access with
Java - A tutorial and annotated reference”. Addison-Wesley, Massachussets,
1997.
[9] Agustín Froure Quintas, “Java Server Pages – Manual de usuario y tutorial”. RA-
MA, Madrid, 2002
129
Bibliografía
[10] Jayson Falke, Ben Galbraith, Romin Irani, ... “Fundamentos Desarrollo Web con
JSP”. Anaya Multimedia, Madrid, 2002
130
Direcciones web
Direcciones web
http://www.mysql.com - MySQL
http://jakarta.apache.org - Tomcat
http://www.ictnet.es/ICTnet/cv/comunidad.jsp?area=engInf&cv=biometrica
- Comunidad de Biometría
131
Índice de Figuras
Índice de figuras
132
Índice de Figuras
133
Índice de Tablas
Índice de Tablas
Tabla 1. Candidatos a Entidad y Relación ....................................................... 47
Tabla 2. Porcentaje de autenticación y porcentaje de rechazo ...................... 110
134