Proyecto Biometria PDF

UNIVERSIDADE DA CORUA
FACULTADE DE INFORMTICA
Departamento de Tecnoloxas da Informacin e as Comunicacins
PROXECTO FIN DE CARREIRA DE ENXEERA TCNICA EN

INFORMTICA DE XESTIN
Sistema de gestin de huellas dactilares en

formato digital
Autor: Jos Antonio Orgueira Prez

Tutor: Antonino Santos del Riego
A Corua, enero de 2003
Agradecimientos
A mis padres, familiares, amigos y compaeros de facultad porque sin ellos nada
sera posible.
A todos los que me ofrecieron su ayuda desinteresada en los foros de Internet

consultados.
A Nino, por todo.
A todos ellos, Gracias.
Sistema de Gestin de huellas

dactilares en formato digital
Resumen
Este proyecto constituye un acercamiento al mbito de la biometra. En concreto, nos
centraremos en el reconocimiento de huellas dactilares, desarrollando un sistema
que, sobre el soporte de una base de datos, permita una gestin de las entidades
involucradas sobre una arquitectura cliente-servidor.
El sistema har la autenticacin de los usuarios a travs de un dispositivo lector de

huellas dactilares. En el proceso de autenticacin se utiliza el algoritmo de
comprobacin de plantillas basadas en la obtencin de minucias.
Tanto la gestin de la base de datos como las comprobaciones de usuarios registrados

estarn orientadas a la WEB, pudindose realizar cualquiera de las tareas a travs de
un navegador.
Palabras claves
Biometra,
Autenticacin,
Reconocimiento,
Huellas
dactilares,
Web,
Tomcat,
Apache, Java, JSP, Javabeans, MySQL
ndice
NDICE
1. INTRODUCCIN
2. DOMINIO DE APLICACIN. AUTENTICACIN Y HUELLAS DACTILARES
2.1. Autenticacin de usuarios
2.2. Autenticacin biomtrica
11
2.3. Huellas dactilares
15
3. ESTADO DEL ARTE

3.1. Huella digital por ultrasonidos
20
3.2. Los dedos de gelatina de Matsumoto
21
3.3. Algoritmo de huellas
23
4. METODOLOGA
4.1. Modelado
36
4.2. Lenguajes y herramientas
53
4.3. Diseo y desarrollo
74
5. VALIDACIN DEL SISTEMA
6. CONCLUSIONES
111
113
ndice
ANEXO I: Manual del Administrador

ANEXO II: Comando de creacin de tablas
114
127
BIBLIOGRAFA
129
DIRECCIONES WEB
131
NDICE DE FIGURAS
132
NDICE DE TABLAS
134
Introduccin
1. INTRODUCCIN
En el mbito de las tecnologas de la seguridad, uno de los problemas
fundamentales a solventar es la necesidad de autenticar de forma segura la identidad
de las personas que pretenden acceder a un determinado servicio o recinto fsico. De
este modo, surge la biometra, tambin conocida como tcnicas de identificacin
biomtrica, con el objetivo de resolver este problema a partir de las caractersticas
propias de cada individuo, como la voz, huella dactilar, rostro, etc.
stas tcnicas de identificacin biomtrica, frente a otras formas de autenticacin

personal como el uso de tarjetas o PINes (Personal Identification Number), o nmero
de identificacin personal, como el usado en cajeros automticos, tienen la ventaja de
que los patrones no pueden perderse o ser sustrados, ni pueden ser usados por otros
individuos en el caso de que lleguen a tener accesible nuestra tarjeta personal y, o,
PIN.
Se debe tener en cuenta que gran parte de los sistemas de autenticacin actuales estn
basados nicamente en el uso de una tarjeta personal y, o, un PIN, con sus
consecuentes problemas de seguridad.
Sea cual sea la tcnica seleccionada para una determinada aplicacin, tendremos que
ponderar en cada caso las restricciones o peculiaridades que pueden tener cada una
de las tcnicas, frente al grado de seguridad aadido que conseguimos y del que
anteriormente no disponamos. Estas caractersticas vienen dadas bsicamente por
los siguientes aspectos:
Necesidad de un dispositivo de adquisicin especfico (lector de huella
dactilar, micrfono, cmara, etc.) all donde est el usuario.
Introduccin
Posible variabilidad con el tiempo del patrn a identificar (afonas,

catarros en voz, uso de gafas/bigote/barba en el rostro, etc.).
Probabilidad de error individual de cada una de las tcnicas (en funcin de
la tcnica elegida).
Aceptacin por parte del usuario de cada una de las tcnicas, en funcin de
si son o no tcnicas intrusivas, cmodas, que mantengan (o al menos lo
parezca) la privacidad, sencillas de usar, etc.
De este modo, en funcin de la situacin en que necesitemos realizar una

autenticacin segura del usuario, se buscar cul es la tcnica ( combinacin de
tcnicas)
biomtrica
ms
adecuada
en
funcin
de
los
cuatro
parmetros
fundamentales anteriormente mencionados.
En este contexto, el objetivo de este proyecto es el desarrollo de un sistema de

gestin de huellas dactilares en formato digital. Estamos interesados en que los
usuarios que lo soliciten puedan pasar a formar parte de nuestra base de datos, para
lo cual les permitiremos mandarnos sus datos y las imgenes digitalizadas de sus
huellas, pudiendo enviarnos un nmero variable de estas, una por cada uno de los
dedos.
Tras la solicitud, ser el administrador del sistema el que se encargue, de la gestin
de la informacin generada (altas, bajas, modif.).
Por ultimo el sistema dispondr de la posibilidad de la autenticacin de un usuario

dado de alta previamente, donde se capturar la huella de esta persona y se
comparar contra la de la base de datos enviada con anterioridad.
Debemos para ello, desarrollar una base de datos, con los datos de inters sobre la
persona, as como con las imgenes digitalizadas de sus huellas.
Introduccin
Todo el proceso se realizara a travs de Internet, sobre una arquitectura

cliente-servidor.
Los objetivos principales del proyecto son:
Diseo y desarrollo de una base de datos con informacin sobre los

usuarios e imgenes de sus huellas dactilares.
Diseo y desarrollo del sistema de gestin.
Integracin de un algoritmo de autenticacin sobre las huellas facilitadas.
Validacin del sistema.
Dominio de la aplicacin
2. Domino de aplicacin. Huellas dactilares en

formato digital
2.1 Autenticacin de Usuarios

En la actualidad uno de los requisitos primordiales de los sistemas informticos son
los mecanismos de seguridad que han de incluir al menos un sistema que permita
identificar a las entidades (elementos activos del sistema, generalmente usuarios) que
intentan acceder a los objetos (elementos pasivos, como ficheros o capacidad de
cmputo), mediante procesos tan simples como una contrasea o tan complejos
como un dispositivo analizador de patrones de la retina.
Los sistemas que habitualmente utilizamos para identificar a una persona, como el
aspecto fsico o la forma de hablar, son demasiado complejos para una computadora;
el objetivo de los sistemas de identificacin de usuarios no suele ser identificar a una
persona, sino autenticar que esa persona es quien dice ser realmente. Aunque
seguramente ambos trminos nos parecern equivalentes, para una computadora
existe una gran diferencia entre ellos: imaginemos un sistema de identificacin
biomtrico basado en el reconocimiento de la retina; una persona mirara a travs del
dispositivo lector, y el sistema sera capaz de decidir si es un usuario vlido, y en ese
caso determinar de quin se trata; esto es identificacin.
Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un

nmero, un nombre de usuario, etc.) adems de mostrar sus retinas ante el lector. En
este caso, el sistema no tiene que identificar a esa persona, sino autenticarlo:
comprobar los parmetros de la retina que est leyendo con los registrados en una
base de datos como identificativos del usuario. En este caso, se est reduciendo el
problema de una poblacin potencialmente muy elevada a un grupo de usuarios ms

reducido, el grupo de usuarios del sistema que necesita autenticacin.
Los mtodos de autenticacin se suelen dividir en tres grandes categoras, en funcin

de lo que utilizan para la verificacin de identidad: (a) algo que el usuario sabe, (b)
algo que ste posee, y (c) una caracterstica fsica del usuario o un acto involuntario
del mismo. Esta ltima categora se conoce con el nombre de autenticacin
biomtrica.
Es fcil identificar ejemplos de cada uno de estos tipos de autenticacin: un

password es algo que el usuario conoce y el resto de personas no, una tarjeta de
identidad es algo que el usuario lleva consigo, la huella dactilar es una caracterstica
fsica del usuario.
Por supuesto, un sistema de autenticacin puede, y debe, para incrementar su

fiabilidad, combinar mecanismos de diferente tipo, como en el caso de una tarjeta de
crdito unida al PIN de los cajeros automticos o en el de un dispositivo generador
de claves para el uso de One Time Passwords.
Cualquier sistema de identificacin (aunque se les llame as, recordemos que

realmente son sistemas de autenticacin) ha de poseer unas determinadas
caractersticas para ser viable; obviamente, ha de ser fiable con una probabilidad muy
elevada, econmicamente factible para la organizacin y ha de soportar con xito
cierto tipo de ataques, por ejemplo, ataques por fuerza bruta.
Adems de estas caractersticas se tiene otra, no tcnica sino humana, pero quizs la
ms importante: un sistema de autenticacin debe ser aceptada por los usuarios, que
sern al fin y al cabo quienes lo utilicen. Por ejemplo, imaginemos un potencial
sistema de identificacin para acceder a los recursos de la Universidad, consistente
en un dispositivo que fuera capaz de realizar un anlisis de sangre a un usuario y as
10
comprobar que es quien dice ser; seguramente sera barato y altamente fiable, pero
nadie aceptara dar un poco de sangre cada vez que desee consultar su correo.
2.2. Autenticacin biomtrica

A pesar de la importancia de la criptologa en cualquiera de los sistemas de
identificacin de usuarios, existe otra clase de sistemas en los que no se aplica esta
ciencia, o al menos su aplicacin es secundaria. Es ms, parece que en un futuro no
muy lejano estos sern los sistemas que se van a imponer en la mayora de las
situaciones en las que se haga necesario autenticar a un usuario. En general son ms
amigables para el usuario, no va a necesitar recordar passwords o nmeros de
identificacin complejos y, como se suele decir, el usuario se puede olvidar la tarjeta
de identificacin en casa, pero nunca se olvidar de su mano o su ojo, y son mucho
ms difciles de falsificar que una simple contrasea o una tarjeta magntica. Las
principales razones por la que no se han impuesto ya en nuestros das es su elevado
precio,
fuera
del
alcance
de
muchas
organizaciones,
su
dificultad
de
mantenimiento.
Estos sistemas son los denominados biomtricos, basados en caractersticas fsicas

del usuario a identificar. El reconocimiento de formas, la inteligencia artificial y el
aprendizaje son las ramas de la informtica que desempean el papel ms importante
en los sistemas de identificacin biomtricos; la criptologa se limita aqu a un uso
secundario, como el cifrado de una base de datos de patrones de retinas, o la
transmisin de una huella dactilar entre un dispositivo analizador y una base de
datos.
11
La autenticacin basada en caractersticas fsicas existe desde que existe el hombre y,

sin darnos cuenta, es la que ms utiliza cualquiera de nosotros en su vida cotidiana: a
diario identificamos a personas por los rasgos de su cara o por su voz.
Obviamente aqu el agente reconocedor lo tiene fcil porque es una persona, pero en
el modelo aplicable a redes de comunicaciones el agente ha de ser un dispositivo que,
basndose en caractersticas del sujeto a identificar, gestione el acceso a un
determinado recurso.
Los dispositivos biomtricos tienen tres partes principales:
Un mecanismo automtico que lee y captura una imagen digital o analgica

de la caracterstica a analizar.
Una entidad para manejar aspectos como la compresin, almacenamiento o

comparacin de los datos capturados con los registrados en una base de
datos (que son considerados vlidos).
Una interfaz de aplicaciones.
El proceso general de autenticacin sigue unos pasos comunes a todos los modelos
de autenticacin biomtrica: captura o lectura de los datos que el usuario a validar
presenta, extraccin de ciertas caractersticas de la muestra (por ejemplo, las
minucias de una huella dactilar), comparacin de tales caractersticas con las
registradas en una base de datos, y decisin de si el usuario es vlido o no.
12
En la figura 1 se muestra la estructura clsica del Diagrama de Bloques de un

Sistema de Reconocimiento Biomtrico.
Obtencin de
los Modelos
de la BD
Persona
Incgnita
Adquisicin de
datos
Autentificador
Preproc.
de la
Seal
Extraccin
de
Caractersticas
Decisin
Algoritmo de
Reconocimiento
Figura 1. Diagrama Sistema Reconocimiento Biomtrico
Es en la Decisin donde principalmente entran en juego las dos caractersticas

bsicas de la fiabilidad de todo sistema biomtrico: las tasas de falso rechazo y de
falsa aceptacin. Por tasa de falso rechazo (False Rejection Rate, FRR) se entiende la
probabilidad de que el sistema de autenticacin rechace a un usuario legtimo porque
no es capaz de identificarlo correctamente, y por tasa de falsa aceptacin (False
Acceptance Rate, FAR) la probabilidad de que el sistema autentique correctamente a
un usuario ilegtimo; evidentemente, una FRR alta provoca descontento entre los
usuarios del sistema, pero una FAR elevada genera un grave problema de seguridad,
proporcionando acceso a un recurso a personal no autorizado.
13
Para determinar las prestaciones de un sistema biomtrico se suele utilizar la tasa de

xito (Success Rate, SR) que responde a una combinacin de los dos factores
anteriores:
SR= 1 (FAR +FRR)
El FAR y el FRR responden a parmetros inversamente proporcionales, por tanto,

variarn en funcin de las condiciones prefijadas por el programa de identificacin
biomtrica. As si por ejemplo se tiene que utilizar el programa en un entorno de
mxima seguridad, se intentar que el FAR sea lo ms pequeo posible, aunque esta
accin signifique de forma explcita, el incremento drstico del factor FRR.
Por lo tanto se debe fijar un parmetro 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 identificacin del sistema. En la figura 2 se muestra la
relacin dicha relacin.
Figura 2. Relacin entre FAR, FRR y ERR
14
2.3. Huellas dactilares

Tpicamente la huella dactilar de un individuo ha sido un patrn bastante bueno para
determinar su identidad de forma inequvoca, ya que est aceptado que dos dedos
nunca poseen huellas similares, ni siquiera entre gemelos o entre dedos de la misma
persona. Por tanto, parece obvio que las huellas se convertiran antes o despus en un
modelo de autenticacin biomtrico: desde el siglo pasado hasta nuestros das se
vienen realizando con xito clasificaciones sistemticas de huellas dactilares en
entornos policiales, y el uso de estos patrones fue uno de los primeros en establecerse
como modelo de autenticacin biomtrica.
Cuando un usuario desea autenticarse ante el sistema sita su dedo en un rea

determinada, el rea de lectura. Aqu se toma una imagen que posteriormente se
normaliza mediante un sistema de finos espejos para corregir ngulos, y es de esta
imagen normalizada de la que el sistema extrae las minucias (ciertos arcos, bucles y
remolinos de la huella) que va a comparar contra las que se tiene en la base de datos.
Es importante resaltar que el sistema no analiza la huella en s sino las minucias,
concretamente la posicin relativa de cada una de ellas.
15
Figura 3. Huella dactilar con minucias
Las huellas de los dedos presentan como caracterstica principal, la presencia de un

conjunto de crestas o partes donde la piel se eleva sobre las partes ms bajas o valles
existentes entre las crestas. Con respecto a estas crestas se definen dos caractersticas
particulares que obedecen al termino de minucias:
Final de cresta (ridge ending). Caracterstica definida como el punto donde
la cresta acaba de forma abrupta.
Bifurcacin de la cresta (ridge bifurcation). Caracterstica definida como el
punto en el que la cresta se bifurca en dos o ms crestas.
Estas dos caractersticas quedan unvocamente definidas a partir de su localizacin

(coordenadas x, y respecto al sistema de coordenadas central de la imagen) y de su
orientacin (ngulo ).
16
Est demostrado que dos dedos nunca pueden poseer ms 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 comparacin de las
posiciones relativas de las minucias ledas con las almacenadas en la base de datos es
correcta, se permite el acceso al usuario, denegndose obviamente en caso contrario.
Los sistemas basados en reconocimiento de huellas son relativamente baratos, en

comparacin con otros biomtricos, como los basados en patrones de retinas. Sin
embargo, tienen en su contra la incapacidad temporal de autenticar usuarios que se
hayan podido herir en el dedo a reconocer. Un pequeo corte o una quemadura que
afecte a varias minucias pueden hacer intil al sistema. Tambin elementos como la
suciedad del dedo, la presin ejercida sobre el lector o el estado de la piel pueden
ocasionar lecturas errneas.
17
Estado del Arte
3. Estado del Arte
Algunos aeropuertos experimentan tecnologas de seguridad que basadas en el

reconocimiento del iris y la mano. La identificacin dactilar es uno de los ms
extendidos; el rostro, el menos invasivo. La asignatura pendiente, la estandarizacin.
Poner el dedo en un escner, hablar por un micrfono o mirar de cerca a una cmara
puede ser suficiente para pasar el control de seguridad y acceder a una instalacin o
sistema informtico. La tecnologa biomtrica ha traspasado los laboratorios de
espionaje, recintos militares y gubernamentales para extender sus aplicaciones al
mercado empresarial y de consumo.
Algunos expertos consideran que el reconocimiento del rostro puede ser la

herramienta ms til para la identificacin en aeropuertos. Las cmaras de seguridad
graban a distancia y permiten comparar las capturas con bases de datos de imgenes.
De hecho, uno de estos sistemas se utiliz en la ltima edicin de la final de ftbol
americano, la Super Bowl, celebrada en Tampa, Florida.
Los aeropuertos de San Francisco y Nueva York emplean sistemas que reconocen la
geometra de la mano de los empleados. El mismo sistema se utiliza en el aeropuerto
israel de Tel Aviv para los pasajeros frecuentes de las lneas areas El Al. En
Heathrow (Londres) se est realizando una experiencia con 2.000 pasajeros
norteamericanos de las aerolneas British Airways y Virgin Atlantic (deben estar
registrados y grabar el iris en una base de datos).
En la actualidad la extensin masiva de estos sistemas se ve frenada por la falta de
estndares. Demasiados sistemas propietarios. Microsoft, uno de los fundadores del
BioAPI, estndar propuesto en 1995 por el Biometric Consortium patrocinado por el
18
Estado del Arte
Gobierno de Estados Unidos, sali del grupo de 60 empresas y agencias para crear su
propia tecnologa. El Departamento de Defensa cuenta con una organizacin y un
laboratorio de biomtrica, donde prueba la utilidad de los ms de 600 productos
existentes en el mercado. El Departamento de Energa desarrolla un escner
hologrfico que analizar, a travs de ondas de radio y en tres dimensiones a los
pasajeros para comprobar si esconden armas.
La industria est concentrada en los sistemas de identificacin dactilar. En general,

son los ms econmicos; los ms baratos sobre los 120 .
Los expertos consideran que para no atentar contra la intimidad una de las mejores
opciones es usar sistemas hbridos que almacenen los datos biomtricos en tarjetas
inteligentes e infraestructuras de clave pblica. De esta forma se evita que la
informacin se encuentre en bases de datos. En la actualidad estn en estudio
sistemas que analizan el olor humano, las venas de la mano o la forma de andar.
19
Estado del Arte
3.1 Huella digital por ultrasonidos

Este esquema funciona por ultrasonidos, lo que evita los fallos que hasta ahora se
producan con la lectura ptica por suciedad en la piel o en el dispositivo de escaneo.
La empresa valenciana especializada en tecnologas de seguridad Mundiscan
Electronic Systems ha presentado recientemente el primer sistema infalible de
identificacin por huella dactilar basado en ultrasonidos.
Se trata de una tecnologa desarrollada en la ltima dcada, que ha demostrado una

alta fiabilidad al extraer los rasgos ms caractersticos e inequvocos de las personas
para posteriores procesos de identificacin. Este nuevo sistema, sustituye al de
identificacin por huella dactilar basado en la tecnologa ptica.
Esta ltima tecnologa ocasionaba problemas debido a las dificultades de lectura, si
la piel o el dispositivo de escaneo se encontraban sucias, algo que provocaba
consecuentemente un rechazo en el mercado. Mundiscan Electronic Systems es la
nica empresa que a travs del uso de los ultrasonidos ha conseguido superar este
problema imponiendo un mtodo de identificacin infalible. La tecnologa es
aplicable a los controles de edificios que requieren un alto nivel de seguridad como
aeropuertos,
bancos,
sedes
gubernamentales,
empresas
privadas,
instalaciones
militares o prisiones.
El sistema biomtrico por ultrasonidos consiste en el envo de ondas de diferentes

frecuencias que rebotan contra la base de la huella y el dispositivo de escaneo,
penetrando cualquier tipo de suciedad encontrada en los dedos como grasa, polvo o
manchas de tinta. De esta forma, se obtiene una imagen sin errores de las crestas y
los valles del dedo escaneado, consiguiendo una gran precisin en la captura de la
imagen que facilitar los procesos identificativos posteriores.
20
Estado del Arte
3.2 Los dedos de gelatina de Matsumoto

Recientemente ha salido publicada una noticia que est provocando un debate
sobre la valoracin de la biometra: un criptgrafo japons llamado
Matsumoto ha descubierto un mtodo para engaar con un "dedo de gelatina" a 11
sensores biomtricos en el 80% de los intentos.
El estudio se basa en conseguir una huella artificial que engae a los sistemas de
autenticacin. El profesor Matsumoto muestra como conseguir artificialmente una
huella que puede servir como la original.
Hacer una huella artificial directamente de una huella real:

Materiales: Plstico moldeable, lmina de gelatina slida
Como hacer un molde: Poner el plstico en agua caliente para ablandarlo,
presionar el dedo contra el, obteniendo el molde.
Preparacin del material: Mezclar la gelatina con un liquido en una
proporcin del 50 %, aadir agua hirviendo (30cc) a la gelatina slida (30g)
en una botella y mezclarlos.
Como hacer una huella falsa: Verter el lquido en el molde, meterlo en un
refrigerador para que enfre y se obtiene la huella.
Matsumoto ha realizado el test sobre 11 dispositivos biomtricos en el mercado. No

olvidemos que existen dispositivos con biosensor que garantizan que con un dedo de
gelatina no va a poder realizarse la intrusin.
21
Estado del Arte
Dependiendo del nivel de seguridad deseado se puede optar por una solucin de
seguridad ms efectiva, por ejemplo, el uso de biosensores, cmaras de vigilancia,
combinaciones de varias biometras, combinaciones con smart cards y PinPad, etc.
Al igual que con cualquier sistema de seguridad, existen vulnerabilidades y

soluciones para las mismas. Por primera vez se est dotando de una inteligencia a
nuestras mquinas por medio del reconocimiento preciso del usuario que interacta
con el sistema, y esto solo lo podemos conseguir con reconocimiento biomtrico.
El dedo de gelatina ha provocado un avance en algunos fabricantes y para otros,

ms previsores, les ha confirmado algo que poda pasar.
De todas formas, todos ellos da a da siguen realizando test de otro tipo de posibles
vulnerabilidades para crear una evolucin y un acercamiento asinttico al punto
limite de seguridad del 100%.
22
Estado del Arte
3.3 Algoritmos de huellas

Autenticacin significa comprobar si un individuo es quien dice ser. El algoritmo de
autenticacin que se utiliza en el presente proyecto, est formado por dos bloques: en
primer lugar se extraen las minucias caractersticas de la huella actual del usuario
que se va a autenticar (algoritmo de extraccin de minucias) y, en segundo lugar, se
comparan esas minucias caractersticas de su huellas con las minucias almacenadas
en la base de datos en forma de plantilla (algoritmo de comparacin de minucias).
Cuando hablamos de huella actual, se hace referencia a la huella situada sobre el

lector de huellas dactilares (tambin huella en vivo), mientras que la plantilla se
corresponde
con
las
caractersticas
extradas
de
una
huella
anteriormente,
normalmente para ser almacenada en una base de datos.
Se dice que un usuario ha sido autenticado si las caractersticas extradas de la huella

actual coinciden con las de la plantilla dentro de un lmite de tolerancia para el
algoritmo de comparacin de minucias.
3.3.1 Algoritmo de extraccin de minucias

Una de las tareas ms importantes en un sistema de reconocimiento de huellas es la
extraccin de las minucias de una imagen capturada de una huella. Debido a las
imperfecciones de la imagen adquirida, en algunos casos el algoritmo de extraccin
puede obviar algunas minucias, y en otros se pueden aadir minucias falsas . Las
imperfecciones de la imagen pueden tambin generar errores al determinar las
coordenadas de cada minucia y su orientacin relativa en la imagen.
23
Estado del Arte
Todos estos factores contribuyen a disminuir
la fiabilidad del sistema de
reconocimiento, puesto que el reconocimiento de huellas dactilares est basado en la

comparacin, dentro de unos lmites de tolerancia, del patrn biomtrico, o conjunto
de minucias extradas, adquirido en vivo y el almacenado.
A continuacin describiremos en profundidad cada una de las fases de este algoritmo

y lo que se consigue en estas.
3.3.1.1 Normalizacin de la imagen

El objetivo de esta fase es disminuir el rango de variacin de grises entre los valles y
las crestas de la imagen para facilitar el proceso en las siguientes etapas.
Figura 4. (a)Huella original (b) Huella normalizada
3.3.1.2 Clculo del campo orientacin

El campo orientacin representa la orientacin local de las crestas que contiene la
huella. Para estimarlo, la imagen se divide en bloques de 16x16 pxeles y se calcula
la inclinacin para cada pxel, en coordenadas x e y. Debido a la carga
24
Estado del Arte
computacional del proceso de reconocimiento, es suficiente aplicar una mscara de

3x3 pxeles para el calculo de la inclinacin en cada pxel.
Figura 5. (a) Huella orientada (b) Campos realineados
El ngulo de orientacin se calcula a partir de la informacin de la inclinacin.

Frecuentemente, en algunos bloques, el ngulo de orientacin no se calcula
correctamente debido a ruidos y daos en los valles y las crestas de la imagen
capturada. Como no pueden existir variaciones significativas del ngulo entre
bloques adyacentes, se aplica un nuevo filtro espacial de 5x5 pxeles al campo
orientacin estimado para reordenar correctamente todos los segmentos. La figura
5(a) muestra el campo orientacin obtenido a partir del clculo de la inclinacin. La
figura 5(b) muestra los campos realineados despus de aplicar el filtro espacial.
3.3.1.3 Seleccin de la zona de inters

Debido a que la imagen contiene ruido de fondo, el algoritmo puede generar
minucias fuera del rea ocupada por la huella. Para evitar este problema, se
selecciona el rea de imagen, definida por todos los bloques de 16x16, en la que
existe una alta variacin del nivel de grises en la direccin normal de las crestas
existentes (el campo orientacin normal de las crestas se haba calculado
25
Estado del Arte
previamente). Despus 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 regin de inters obtenida a
partir de esta.
Figura 6. (a) Variaciones de la huella (b) Regin importante
3.3.1.4 Extraccin de crestas

Para decidir si un pxel pertenece o no a una cresta dada, es necesario filtrar la
imagen de la huella con dos mscaras adaptables, ambas capaces de incrementar el
nivel de gris el la direccin normal de la cresta. La orientacin de la mscara se
adapta a cada bloque de 16x16 pxeles, dependiendo los ngulos obtenidos del
campo orientacin realineados de la figura 5(b).
Si el nivel de gris de un pxel excede un umbral en las dos imgenes filtradas, se

considera que el pixel pertenece a la cresta; de otra forma se asigna a un valle,
produciendo una imagen binaria de la huella. Las dimensiones de la mscara son
LxL y estn definidas por las ecuaciones dadas en (1) y (2).
26
Estado del Arte
u u
1
h1 (u, v ) = 2 e
0
, si : u0 = E[(vc v )ctg( ) + uc ]
, en otro caso
v v
1
e
h2 (u , v) =
2
0
, si : v0 = E [(u c u )tg ( ) + vc ]
, en otro caso
u, v [1, L]
donde u y v son las coordenadas de un pxel en la mscara; (uc, vc) es el centro de la
mscara; , es el ngulo de orientacin de la cresta en cada bloque de la imagen, y ,
es un parmetro para ajustar la funcin mscara al ancho de la cresta. La figura 7(a)
muestra la imagen filtrada con una de las mscaras espaciales. La figura 7(b)
representa la imagen binaria obtenida despus de aplicar un umbral, produciendo
bordes de crestas lisos.
Figura 7. (a) Imagen filtrada (b) Imagen binaria obtenida
27
Estado del Arte
3.3.1.5 Perfilar las crestas

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 continuacin se eliminan
a la imagen original, proporcionando los componentes de alta frecuencia necesarios
para perfilar las crestas, como se deduce de:
p[u , v] = f [u, v ] + fH [u,v ] = f [u, v ] + ( f [u, v] f L[u, v ])
donde p[u,v], es el resultado de perfilar la imagen; f[u,v], es la imagen binaria;

fH[u,v] y fL[u,v] son, respectivamente, las imgenes de alta y baja frecuencia; y es
un factor (>0), que determina el grado de perfilacin. En la figura 8(a) se muestra el
resultado de la huella despus de aplicarle el primer filtro. Se puede aplicar un
nuevo filtro para eliminar las crestas falsas debidas a manchas en la imagen. En este
caso se utiliza una mscara espacial capaz de adaptar su orientacin localmente a
la orientacin de la cresta.
Figura 8 . (a) Imagen despus del primer filtro perfilador (b) Imagen
despus del segundo filtro perfilador con mscara espacial
28
Estado del Arte
3.3.1.6 Simplificacin
En este paso se aplican dos algoritmos consecutivos paralelos de simplificacin, para
reducir a un nico pxel el ancho de las crestas en la imagen binaria. Estas
operaciones son necesarias para simplificar es siguiente anlisis estructurale de la
imagen para la extraccin de las minucias de la huella.
La simplificacin se debe realizar sin modificar la estructura original de las crestas

de la imagen. Durante este proceso, el algoritmo no puede calcular mal los
comienzos, finales y, o bifurcaciones de las crestas, ni las crestas se pueden romper.
3.3.1.7 Eliminar imperfecciones

Despus de la simplificacin, dependiendo de la calidad de la imagen, las
imperfecciones estructurales de la huella original permanecen en un cierto grado.
Esto conlleva crestas rotas, crestas falsas y huecos; as que, es necesario aplicar un
algoritmo para eliminar todo las lneas que no se corresponden a crestas y un
algoritmo para enlazar crestas rotas. La figura 9(a) muestra la imagen adelgazada
obtenida una vez aplicado el algoritmo de adelgazamiento y eliminacin de
imperfecciones.
Figura 9. (a) Imagen despus de la simplificacin y eliminacin de imperfecciones

(b) Patrn de minucias despus del proceso de eliminacin de conjuntos
29
Estado del Arte
3.3.1.8 Extraccin de minucias

En la ltima etapa, se extraen las minucias de la imagen simplificada, obteniendo el
patrn biomtrico de la huella (plantilla). Este proceso conlleva la determinacin de:
(i) si un pxel pertenece o no a una cresta y, (ii) si es as, si es una bifurcacin,
comienzo o final de cresta obteniendo as un grupo de candidatos a minucias. A
continuacin, todos los puntos en el borde de la zona de inters se borran. Entonces,
puesto que la densidad de minucias por unidad de rea no puede exceder un cierto
valor, todos los conjuntos de puntos candidatos cuya densidad excede este valor son
sustituidos por una simple minucia localizada en el centro del conjunto. En la figura
9(b) se muestra el patrn de minucias resultante.
Una vez finalizado el proceso de extraccin de minucias la plantilla contiene entre

70 y 80 minucias. En la figura 10 se muestra el patrn de minucias obtenido
superpuesto sobre la imagen de la huella normalizada:
Figura 10. Patrn de minucias
30
Estado del Arte
3.3.2. Algoritmo de comparacin de minucias

Con el emparejamiento se determina si dos huellas son del mismo dedo o no. Las dos
caractersticas usadas en el emparejamiento de huellas son los finales y las
bifurcaciones de las crestas (minucias).
A continuacin se explica en detalle cada una de las etapas del algoritmo de

comparacin de minucia:
Para cada minucia detectada, se almacenan los siguientes parmetros:

Coordenadas x e y de la minucia.
Orientacin definida como la orientacin local de la cresta asociada.
El tipo de minucia, que puede ser final de cresta o bifurcacin.
La cresta asociada.
Para la comparacin de las minucias se utilizarn las coordenadas polares de estas.
3.3.2.1 Alineacin del conjunto de minucias
Si denotamos por P al conjunto M de minucias en la imagen plantilla tenemos que:
P = (x1P , y1P , 1P ) ,...,(x MP , yMP , MP )

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
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
rotacin 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.
Figura 11. Alineacin de la cresta de entrada y la cresta plantilla
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
ecuacin siguiente:
Diff _ dist =
1 L
R( d i ) r ( d i )
L i =0
32
Estado del Arte
Diff _ ang =
1 L
R (i ) r (i )
L i= 0
Donde L es el nmero de puntos grabados. R(di) es la distancia desde el punto i en la

cresta R a la minucia Pi. R( i ) es el ngulo entre la lnea que conecta el punto i
sobre la cresta R a la minucia Pi y la orientacin de la minucia Pi ; r(di ) y r( i )
tienen significados similares.
Si Diff_dist es ms grande que Td o diff_ang es mayor que To , se pone rotate[i][j] a

400. De otra forma calculamos rotate[i][j] como:
Rotate[i][j] = dir_Temp dir_in

Donde dir_temp es la orientacin de Pi y dir_in es la orientacin de Qj.
Para alinear el conjunto de minucias de entrada con el conjunto de minucias de la
plantilla en la coordenada polar, lo que se necesita hacer es trasladar las minucias de
la imagen de entrada y las de la plantilla a coordenadas polares con respecto a las
minucias de referencia Pi y Qj, y a continuacin aadir el ngulo rotate[i][j] al
ngulo radial de la coordenada polar de cada minucia de entrada. Es decir, para
una minucia (xi, yi, i)T aplicamos la siguiente ecuacin:
) (
2
2
xi x r + xi y r
ri
r
1
i
e
i
=
tan
+
rotate
[
i
][
j
]

x xr
i

r
Donde (xr, yr, r)T es la coordenada de la minucia de referencia, y (ri, ei, i)T es la
representacin de la minucia en el sistema de coordenadas polares (ri representa la
33
Estado del Arte
distancia radial, ei representa el ngulo radial, y i ; representa la orientacin de la

minucia con respecto a la minucia de referencia).
3.3.2.2 Comparacin de las minucias alineadas
Los pasos del algoritmo de comparacin de minucias son los siguientes:

1) Para i (1 i M ) y j (1 j N ) , si rotate[i][j]=400, se repite este paso y se
elige otro Pi y Qj , sino se va al paso 2. Si se ha hecho para todos los pares de
minucias, se va al paso 5.
2) Poner Pi y Qj como minucia de referencia. Convertir cada minucia en el

conjunto de minucias de la plantilla y conjunto de minucias de entrada al
sistema de coordenadas polares con respecto a la correspondiente minucia de
referencia a travs del mtodo descrito al final de la seccin 2.1.
3) Representar las minucias de la plantilla y de la entrada en el sistema de

coordenadas polares como cadenas simblicas, concatenando cada minucia
en orden creciente de ngulos radiales:
((
= ((r
Pi s = r1 p , e1p , 1p
Qis
Q
1
) ,..., (r
T
p
M
, e Mp , Mp
, e1Q , 1Q ,..., rNQ , e QN , NQ

T
)
))
4) Comparar las cadenas resultantes Pis y Qjs para encontrar el nivel de

coincidencia de Pis y Qjs. Asignar a m_score[i][j] el valor del resultado.
Continuar en el paso 1.
34
Estado del Arte
5) Encontrar el mximo valor de m_score[i][j] y usarlo como el nivel de

coincidencia del conjunto de minucias de la entrada y la plantilla. Si el nivel
de coincidencia es mayor que un umbral, se considera que la imagen de
entrada se origin a partir de la misma huella que la plantilla, sino se
considera que las dos imgenes provienen de dedos diferentes.
35
4. Metodologa
Para el desarrollo del proyecto, seguiremos una metodologa clsica, que incluir los
siguientes pasos:
1. Modelado. Anlisis del dominio de la aplicacin.
a. Estudio de los actores del sistema

b. Estudio de los casos de uso
c. Estudio de las clases del dominio
d. Estudio y desarrollo de la base de datos
2. Seleccin de las herramientas de desarrollo

3. Diseo y desarrollo de la(s) aplicacin(es)
4. Validacin de la arquitectura resultante
4.1 Modelado
En primer lugar se hace un anlisis del problema, usuarios, requisitos funcionales,
etc. Para ello utilizaremos el Lenguaje Universal de Modelado (Unified Modeling
Language, UML en lo sucesivo) pues constituye un estndar utilizado ampliamente
en el desarrollo de software.
Puesto que va a ser este el lenguaje que vamos a utilizar para modelar nuestra
aplicacin,
haremos
una
breve
introduccin
resaltaremos
sus
principales
caractersticas:
36
Lenguaje Unificado de Modelado
4.1.1. El Lenguaje Unificado de Modelado

El UML es un estndar para escribir planos de software. El UML se puede utilizar
para visualizar, especificar y documentar los artefactos de un sistema que involucran
una gran cantidad de software.
El UML es apropiado para modelar desde sistemas de informacin en empresas hasta

aplicaciones distribuidas basadas en Web, como es este caso, e incluso para sistemas
de tiempo real.
Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar
y luego desplegar tales sistemas.
El UML es un lenguaje y por lo tanto se constituye como un mtodo de desarrollo de

software. UML es independiente del proceso, aunque para utilizarlo
ptimamente se debera usar en un proceso que fuese dirigido por los casos de uso,
centrado en la arquitectura, iterativo e incremental.
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese

vocabulario con el objetivo de posibilitar la comunicacin. El lenguaje de modelado
es un lenguaje cuyo vocabulario y reglas se centran en la presentacin conceptual y
fsica de un sistema.
El modelado proporciona una compresin del sistema. Nunca es suficiente un nico

modelo. Ms bien, para comprender cualquier cosa, a menudo se necesitan mltiples
modelos conectados entre s, excepto en los sistemas ms triviales. Para sistemas con
una gran cantidad de software, se requiere un lenguaje que cubra las diferentes vistas
de la arquitectura de un sistema mientras evoluciona a travs del ciclo de vida del
desarrollo del software.
37
El vocabulario y las reglas de un lenguaje como el UML indican cmo crear y leer
modelos bien formados, pero no dicen que modelos se deben crear ni cuando se
deberan crear. Esta es la tarea del proceso de desarrollo de software.
UML es un lenguaje para visualizar

UML es algo ms que un simple montn de smbolos grficos. Mas bien detrs de
cada smbolo en la notacin UML hay una semntica bien definida. De esta manera,
un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso
otra herramienta, puede interpretar ese modelo sin ambigedad.
UML es un lenguaje para especificar

En este contexto, especificar significa construir modelos precisos, no ambiguos y
completos. UML cubre la especificacin de todas las decisiones de anlisis, diseo e
implementacin que se deben de realizar al desarrollar y desplegar un sistema con
gran cantidad de software.
UML es un lenguaje para construir

UML no es un lenguaje de programacin visual, pero sus modelos se pueden
conectar de forma directa con una gran variedad de lenguajes de programacin, entre
los que est Java. Esta correspondencia permite ingeniera directa, la generacin de
cdigo a partir de un modelo UML en un lenguaje de programacin.
UML es un lenguaje para documentar

Una organizacin de software que trabaje bien produce toda clase de artefactos
adems de cdigo ejecutable: requisitos, arquitectura, diseo, cdigo fuente, etc.
Tales artefactos no son solo los entregables de un proyecto, tambin son crticos en el
control, la medicin y comunicacin que requiere un sistema durante su desarrollo y
despus de su despliegue.
38
El UML cubre toda la documentacin de la arquitectura de un sistema y todos sus

detalles. UML tambin proporciona un lenguaje para expresar requisitos y pruebas.
Finalmente, UML proporciona un lenguaje para modelar las actividades de
planificacin de proyectos y gestin de versiones.
39
Actores del sistema
4.1.2. Actores del sistema
Nuestro sistema cuenta con dos tipos de usuarios, llamados actores en UML.
Usuario
Administrador
Figura 12. Actores del sistema
Actor Administrador: Es el encargado de mantener los datos de la base de datos.

Su trabajo consiste en dar altas, bajas y modificaciones de los usuarios en la base de
datos. Todo su trabajo podr ser realizado a travs de la web, previa autenticacin
biomtrica, de la que se encarga el servidor.
Actor usuario: Representa la persona que hace el envo de la imagen de su huella as

como los datos referentes a ella, a travs de la web, para pasar a formar parte de la
base de datos. Tiene tambin la posibilidad de autenticarse para verificar que su
huella y datos se han incorporado a la base de datos.
40
Casos de uso
4.1.3 Casos de uso

Casos de uso del Actor Administrador
En la figura 12 se muestra el diagrama de casos de uso para el actor

Administrador.
Alta_admin
<<include>>
<<uses>>
<<uses>>
<<include>>
Administrador
Modificacin
Gestin
(from Actores)
<<uses>>
Visualizacin
<<uses>>
<<include>>
Baja
Autent_admin
Figura 13. Casos de uso de Administrador
41
Casos de uso
El caso Gestin es el ms general, representa la interaccin del administrador con

el sistema, cuando realiza las tareas de administracin. Hace uso, adems del caso de
uso Autenti_admin., que autenticar al administrador.
El caso Autenti_admin representa la autenticacin del actor ante el sistema, que

nos permitir tener control sobre los privilegios correspondientes a cada actor.
Para este caso de uso se va a usar la autenticacin biomtrica, que nos va a asegurar
el acceso exclusivo, por parte del administrador, a las pginas desde las que se
realizan las tareas de administracin (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
aplicacin. 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
eliminarn fsicamente las imgenes de las huellas, as como las plantillas generadas
a partir de estas.
42
Casos de uso
La Modificacin se encarga como su propio nombre indica de la modificacin de

los datos referentes a un usuario (excepto la clave primaria), que ya halla sido dado
de alta en la base de datos. Se mostrarn, en primer lugar, los datos actuales de un
usuario, y se le permitir al administrador introducir los cambios que desee, para
luego actualizar estos datos en la base de datos.
La Visualizacin consiste, en un primer momento, en dar una lista de los usuarios

de la base de datos, para a continuacin mostrar todos los datos que constan
referentes al usuario seleccionado.
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
visualizarn todos los usuarios y una vez seleccionado uno, se le mostrar la
informacin completa referente a este, para que confirme la operacin que est a
punto de realizar.
43
Casos de uso
Casos de uso del Actor Usuario
La figura 13 representa los casos de uso del actor Usuario.
Alta_nuevo_usu
Alta_usuario
Alta_existente_usu
Usuario
<<use>>
(from Actores)
generar_plantilla
Autenticar
Figura 14. Casos de uso Usuario
El caso de uso Alta realizado por los usuarios va web, se especializa en dos: en
primer lugar estn 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
algn momento y posteriormente deciden enviar alguna otra huella.
Para el primer caso (Alta_nuevo_usu), se le presentar al usuario un formulario para

que introduzca tanto los datos personales como, la posibilidad de enviar una imagen
de cada una de sus huellas.
44
Casos de uso
En el segundo caso (Alta_existente_usu), el usuario ya realiz en algn momento el

caso anterior, y decide enviar ms huellas. Para este caso, el usuario se tendr que
identificar para confirmar que ya consta en la base de datos, y se le dar la
posibilidad del envi de imgenes nuevas.
El caso de uso Autenticar representa la validacin final del sistema, ya que

consiste en la comprobacin de la identidad de un usuario que con anterioridad haya
pasado a formar parte de la base de datos.
Se autentica la huella en vivo de un usuario con la plantilla generada en el

momento del alta. Si el dedo que en ese momento est sobre el lector pertenece a un
usuario que ,con anterioridad, haba enviado la huella de ese mismo dedo, la
autenticacin ser exitosa. En caso contrario se le indicar el motivo del fracaso: bien
porque no es un usuario registrado o bien porque estando en la base de datos no
coincide el dedo que tiene sobre el lector con alguna de las imgenes de huellas que
haya enviado.
El caso Generar plantilla genera una plantilla a partir de una imagen. Esta plantilla
almacena las caractersticas (minucias) extradas de la huella, que la van a hacer
nica. De esta manera guardamos informacin referente a la persona, pero que no la
compromete en ningn momento, utilizndose para autenticar la huella en vivo.
La utilizacin de estas plantillas tiene como principal ventaja el tamao de estas, ya

que mientras una imagen de una huella ocupa unos 100 Kb, la plantilla nos ocupa
aproximadamente 1 Kb , y rene
toda informacin utilizada en el algoritmo de
autenticacin, que nos va a servir para diferenciar unas huellas de otras.
45
Lenguajes y Herramientas
4.1.4. Base de Datos

La aplicacin de gestin de huelas dactilares se basa en el mantenimiento de una
base de datos que recoge toda la informacin referente a los usuarios y sus huellas
dactilares. Por lo tanto, necesitaremos crear esa base de datos.
La base de datos va a estar formada por tres tablas con las que mantenemos la
informacin sobre los usuarios en una de ellas (tabla usuarios), informacin sobre las
huellas en la otra (tabla huellas), y una ltima en la que mantendremos la
informacin que concierne al administrador (tabla admin).
En el desarrollo de esta base de datos utilizaremos un enfoque entidad-relacin, para

posteriormente, convertir el modelo resultante en un modelo relacional, que ser
implementado directamente en el sistema gestor de base de datos elegido.
En primer lugar, realizaremos un anlisis de los requisitos de nuestro sistema.
Referente a la persona, nos interesan sus datos personales, direccin,

telfono, etc, siendo el identificador nico de cada persona su DNI.
Cada persona podr hacer un envo entre una y diez imgenes de huellas,
una por cada uno de sus dedos.
Las huellas se asociarn a los usuarios por medio del DNI de estos.
Las huellas se asociarn a una mano y a un dedo de la persona que los

envi.
46
A partir de cada huella se generar una plantilla caracterstica de la misma,

que agilizar el proceso de autenticacin.
Para la autenticacin del administrador se mantendr una plantilla, extrada

a partir de su huella, en la base de datos.
En nuestro caso mantendremos en la base de datos tanto las imgenes 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 informacin
relevante del usuario, como lo son sus huellas. Adems, 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 biomtricos que almacenan las plantillas caractersticas
de las personas, es que estas plantillas son del orden de 100 veces menores que las
imgenes a partir de las que se generan. Por lo tanto, la base de datos ser
considerablemente menor.
De lo expuesto anteriormente, obtenemos la lista de candidatos a entidades del

dominio y otra con las posibles relaciones.
Ca Candidatos a Entidades
Ca Candidatos a Relaciones
US USUARIO
TI TIENE: huella
H HUELLA
PE PERTENECE: usuario
SS ADMINISTRADOR
Tabla 1. Candidatos a Entidad y Relacin
47
4.1.4.1. Modelo Entidad-Relacin

Para un estudio de la estructura de los elementos del dominio, as como de sus
relaciones, utilizaremos el modelo Entidad-Relacin (ER). La figura 14 muestra el
modelo entidad-relacin resultante:
Persona
id_persona
Direccin
CP
Nombre
Nombre
Plantilla
Provincia
Localidad
Pais
email
http
Administrador
Usuario
id_huella
N
mano
Huella
dedo
plantilla
Figura 15. Modelo Entidad-Relacin
48
4.1.4.2. Diccionario de datos
Entidad Administrador
Persona que, como su nombre indica, se va a encargar de administrar la base de datos

de usuarios y huellas.
Atributos:
ID_ADMINISTRADOR
Numrico. Clave principal.
NOMBRE
Nombre del Administrador.
PLANTILLA
Plantilla generada a partir de la huella.
Clave Principal: ID_ADMINISTRADOR

Clave alternativa: NOMBRE
Entidad Huella
Imagen digitalizada de la huella enviada por un usuario.
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
Clave principal: ID_HUELLA
49
Entidad Usuario
Persona que nos enva su/s huella/s en formato digital y que pasarn a formar parte
de nuestra base de datos.
Atributos:
ID_USUARIO
Numrico. Clave principal.
NOMBRE
Nombre del Usuario.
DIRECCIN
Direccin donde reside el usuario, ser una cadena de

texto.
C.P.
Cdigo Postal del lugar de residencia del usuario.
LOCALIDAD
Localidad de residencia del usuario.
PROVINCIA
Provincia de residencia del usuario.
PAIS
Pas de residencia del usuario.
EMAIL
Direccin correo del usuario.
WEB
Pgina web del usuario.
ALTA
Estado en el que se encuentra (T/F).
Clave Principal: ID_USUARIO

Relacin Huella Usuario
Relacin tener. Una huella concreta pertenece a un usuario, mientras que un

usuario tiene desde una a diez posibles huellas en la base de datos. Por lo tanto,
estamos ante una relacin 1:N.
50
4.1.4.3. Modelo Relacional
El estudio del modelo entidad-relacin nos lleva al siguiente esquema de tablas, que
compone un modelo relacional completo del dominio de la aplicacin.
Tabla Administradores
ID_ADMINISTRADOR
Entero
No nulo
NOMBRE
Texto
No nulo
PLANTILLA
Texto
No nulo
Clave principal: ID_ADMINISTRADOR

Dependencias Funcionales
ID_ADMINISTRADOR -> NOMBRE, PLANTILLA
3 Forma Normal
Tabla Usuarios
ID_USUARIO
Entero
No nulo
NOMBRE
Texto
No nulo
DIRECCIN
Texto
No nulo
C.P.
Entero
LOCALIDAD
Texto
PROVINCIA
Texto
PAIS
Texto
EMAIL
Texto
WEB
Texto
ALTA
Texto
No nulo
51
Clave principal: ID_USUARIO

ID_USUARIO -> NOMBRE, DIRECCIN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB
NOMBRE -> ID_USUARIO, DIRECCIN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB
3 Forma Normal
Tabla Huellas
ID_HUELLA
Texto
No nulo
USUARIO
Entero
No nulo, Clave fornea
MANO
Texto
No nulo
DEDO
Texto
No nulo
PLANTILLA
Texto
No nulo
Clave principal: ID_HUELLA

Clave fornea: USUARIO referencia ID_USUARIO en tabla Usuarios.
ID_HUELLA -> USUARIO, MANO, DEDO, PLANTILLA.
3 Forma Normal
52
4.2 Lenguajes y herramientas
4.2.1 Programacin Web

La idea de usar la Web como un entorno de aplicaciones se fue desarrollando con el
tiempo, de modo que cada etapa de innovaciones tecnolgicas serva de trampoln
para la aparicin de nuevas ideas. El primer modelo operativo consista simplemente
en un servidor Web que enviaba los documentos que se le pedan. En este entorno, el
contenido no cambiaba a no ser que alguien proporcionara una nueva versin del
documento. La figura 15 muestra este entorno.
Navegador Web
Servidor Web
GET/doc.html
<HTML>...<HTML>
Documentos
HTML
Figura 16. Modelo de servidor de documentos estticos
53
HTTP (Hypertext Transfer Protocol) es un protocolo de peticin/respuesta simple en

el que el navegador Web solicita un documento, normalmente utilizando el comando
GET, y el servidor Web devuelve el documento en forma de un flujo de datos HTML
(Hypertext Markup Language), precedido por unas cuantas cabeceras descriptivas.
Rpidamente se hizo evidente que si una persona poda revisar los documentos
gestionados por el servidor Web, tambin poda hacerlo un programa de texto
procesado como una secuencia de comandos Perl. El navegador Web no aprecia la
diferencia porque el resultado de una peticin HTTP sigue siendo un flujo de datos
en HTML. Ms an, el navegador puede enviar algo ms que una simple peticin:
puede enviar parmetros, incluyndolos en la URL (Universe Reason Locate) o
enviando un flujo de datos con la peticin. Esto sugiere que una peticin HTTP
puede interpretarse como una consulta a una base de datos y los resultados de la
consulta se pueden usar para construir dinmicamente un documento HTML. Con el
desarrollo del servidor Web NCSA HTTPd lleg una nueva especificacin, los CGI
(Common Gateway Interface).
El servidor Web invoca a un programa CGI como respuesta a cierto tipo de

peticiones, generalmente peticiones de documentos de un directorio concreto o
nombres de fichero con una extensin especfica, como por ejemplo .cgi. Los
parmetros de la peticin se pasan como pares clave/valor y las cabeceras de
respuesta como variables de entorno. El programa lee estos parmetros y las
cabeceras, realizan la tarea de la aplicacin con la que se est trabajando, y entonces
genera una respuesta HTTP. La respuesta se enva al navegador Web solicitante
como si fuera un documento esttico corriente.
54
La figura 16 ilustra el flujo del proceso.
Navegador Web
Servidor Web
GET/cgi-bin/pgm
<HTML></HTML>
Programa CGI
Base
de datos
Figura 17. Contenido dinmico generado por una secuencia de comandos CGI
Los CGI normalmente generan un nuevo proceso para cada peticin HTTP. Esto
supone un problema cuando el trfico es escaso, pero provoca sobrecarga cuando el
nivel de trfico aumenta. En esta situacin, los CGI no se ajusta, a nuestras
necesidades.
Se produjo una mejora significativa con la paricin, en 1997, de la API Servlet de

Java, que fue seguida rpidamente por la API JSP (acrnimo de Java Server Pages,
las Paginas Java en servidor). Esta tecnologa lleva todo el potencial de Java al
servidor Web, con conectividad a base de datos, acceso a trabajo en red, operaciones
de subprocesos y, sobre todo, un modelo de proceso diferente.
55
Los servlets y las pginas JSP operan desde un solo ejemplar o instancia que
permanece en la memoria y utiliza mltiples subprocesos para responder a distintas
peticiones de forma simultnea. La figura 17 muestra ilustra el uso de esta
tecnologa.
Navegador Web
Servidor Web
GET / requestURI
<HTML></HTML>
Motor de servlets
Servlets
Pgina JSP
Servicios J2EE
Base
de datos
Otros
servicios
Figura 18. Aplicaciones dinmicas usando servlets, JSP y J2EE.
56
El modelo de aplicacin Web ha ido evolucionando a medida que la Web ha ido

madurando y la experiencia lograda en cada fase ha determinado los requisitos para
la siguiente. La oleada inicial de Java en cliente en forma de applets fue muy
popular, pero acab causando decepcin al aplicarse en la prctica. La utilidad de los
applets estaba limitada por el considerable nmero de incompatibilidades entre
navegadores, por los excesivos perodos de descarga con modems lentos y por las
restricciones de seguridad. Debido a esto el desarrollo de los applets se hizo ms
lento y la tecnologa Java en servidor se convirti en el mayor rea de crecimiento.
Java en el servidor no sufre las restricciones del entorno applet. No aparecen

inconsistencias del navegador porque no es necesario que este posea una mquina
virtual Java. El navegador slo tiene que generar HTML, y esto lo puede hacer
razonablemente bien hasta los navegadores ms antiguos. No es precisa la
configuracin del cliente ni la descarga desde otros recursos de extensos archivos de
clase. Del mismo modo, las consideraciones de seguridad se limitan a aquellas ya
gestionadas por el servidor Web, que est normalmente en un entorno cerrado con
controles separados.
57
4.2.2 El lenguaje Java

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 documentacin del dispositivo de huellas dactilares
disponible, y que nos llevara a la utilizacin de la tecnologa 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 llevara a utilizar la tecnologa de Microsoft ASP (Active Server
Pages) para la generacin dinmica de pginas, y todo ello trabajando bajo el
Servidor de Microsoft (IIS). Por el otro lado el uso de Java como leguaje de servidor
nos llevara a utilizar JSP (Java Server Pages) para la generacin dinmica de
pginas; 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 tecnologas Servlets, JSP y Javabeans como
lenguaje para el desarrollo de los distintos mdulos de la aplicacin por
una serie de motivos que discutimos a continuacin:
Java presenta una serie de ventajas frente a otros lenguajes, entre los cuales
destacamos los siguientes:
Seguridad
El modelo de seguridad de Java tiene tres componentes

principales:
el
cargador
de
clases,
el
verificador
bytecode
SecurityManager.
58
El verificador bytecode se asegura de que el programa se haya compilado

correctamente, que obedezca a las restricciones de acceso de la VM (Virtual
Machine, en castellano Maquina Virtual) y que el programa no acceda a
datos privados sino tiene que hacerlo.
El cargador de clases segn recupera las clases de la red de trabajo, se

almacenan en servidores Web independientes, de esta forma se evita que
cargue por error una clase que pretenda ser un complemento a la clase
principal o que interfiera en el proceso de carga de las clases procedentes de
otro servidor.
SecurityManager es el encargado de establecer la poltica de accin de la

VM. La poltica de seguridad determina las actividades que puede efectuar
la VM y bajo qu casos.
Core API
La interfaz Core API proporciona un conjunto de funciones comunes a

todas las plataformas que puedan trabajar con Java.
La interfaz se divide en paquetes, que son grupos de clases que pueden

desarrollar una serie de funciones. En uno de estos paquetes se encuentra
las bases del lenguaje de programacin, tales como el control de texto y
proceso de errores.
Estndares abiertos
En la actualidad la VM se puede utilizar con ms de una decena de

combinaciones de hardware y sistemas operativos. Los archivos escritos en
este lenguaje no se han de compilar en todas las plataformas.
59
Lo importante es que dichas plataformas trabajen con la VM. Una

aplicacin en Java que se escriba hoy, se ejecutar en todas las plataformas
que trabajen con la VM, aunque an no se haya creado.
Distribuido y dinmico
El cargador de la VM busca los archivos class que se encuentran en una red

o en un disco duro, proceso completamente transparente al usuario,
haciendo que la distribucin de las aplicaciones en Java sea completamente
transparente. Estas propiedades permiten que el explorador compatible con
Java se adapte automticamente a los protocolos que
obtiene desde un
nuevo sitio Web.
Orientada a objetos
La Programacin Orientada a Objetos, u Object Oriented Programming

(OOP), es una forma de escribir un software que se puede volver a utilizar y
cuyo mantenimiento es realmente sencillo. Java es un lenguaje de
programacin orientado a objetos. De hecho, Core API es un conjunto de
componentes OOP que se conoce como librera class. Las libreras class
permiten que los programadores se ahorren muchos dolores de cabeza
cuando han de desarrollar nuevos proyectos.
Multitarea
Una aplicacin 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
Las aplicaciones multitarea pueden utilizar varios thread a la vez durante la

ejecucin. Estos thread se comunican entre s, por lo que podrn cooperar
entre ellos pareciendo, de cara al usuario, que el programa lo est
ejecutando un nico thread, pero ms rpido que con las aplicaciones
monotarea.
Administracin de memoria y recoleccin de basura
El sistema recupera la memoria temporal en el momento tras cierta cantidad

de tiempo sin que el programa activo la solicite. De esta forma se libera al
desarrollador de una parte tediosa del trabajo.
La ingeniera de componentes ha hecho posible que se lleven
a cabo grandes
avances en hardware y en tecnologa electrnica. La programacin basada en

componentes lleva esta idea al mundo del software. En el mbito Java , esto es lo que
significa JavaBeans.
Un bean de Java es un componente elemental reutilizable de software. Se trata de

bloques de construccin que sirven para crear aplicaciones.
Para que los beans funcionen slo se necesita la VM Java. Esto permite que los
beans bien construidos se utilicen en cualquier entorno Java: applets, servlets,
pginas JSP o aplicaciones Java autnomas.
Por su parte , los servlets son clases Java que amplan la funcionalidad de un servidor
Web mediante la generacin dinmica de pginas Web. Un entorno de ejecucin
denominado motor de servlets administra la carga y descarga del servlet, y trabaja
con el servidor Web para dirigir peticiones a los servlets y enviar la respuesta a los
clientes.
Puesto que hemos optado por la utilizacin de servlets en detrimento de la interfaz

CGI, vamos a explicar alguna de sus ventajas principales:
61
Rendimiento
La tecnologa CGI normalmente inicia un nuevo proceso para gestionar

cada peticin que les llega. Los servlets, al contrario, se cargan cuando se
solicitan por primera vez y permanecen indefinidamente en la memoria. El
motor de servlets carga un solo ejemplar o instancia de la clase Servlet y le
lanza peticiones empleando un conjunto de subprocesos disponibles
(threads o hilos). La mejora del rendimiento con este sistema es
considerable.
Simplicidad
Los servlets se ejecutan en una VM en un entorno de servidor controlado y

solo necesitan el HTTP bsico para comunicarse con sus clientes. No es
preciso que el cliente tenga un software especial, ni siquiera en los
navegadores antiguos.
Sesiones http
Aunque los servidores HTTP no tienen capacidad para recordar detalles de

una peticin previa del mismo cliente, la interfaz API Servlet proporciona
una clase HttpSession que permite superar esta limitacin.
Acceso a la tecnologa Java
Al ser aplicaciones Java, los servlets tienen acceso directo a toda la gama de
caractersticas Java, como el uso de subprocesos, acceso a redes y
conectividad a base de datos.
62
Comunicacin
Como cada invocacin de un programa CGI desencadena un proceso

independiente, la comunicacin entre ellos se debe hacer con frecuencia a
travs de ficheros, lo que puede ralentizar bastante la operacin. Si estos
programas pertenecen a un mismo servidor, su intercomunicacin suele ser
igualmente problemtica.
Seguridad
Algunas variantes de CGI tienen graves problemas de seguridad. Aunque se

utilicen los ltimos estndares o lenguajes relativamente seguros, el sistema
no ofrece garantas suficientes de proteccin.
Una Pgina Java en servidor,o Java Server Pages (JSP) es una plantilla para una
pgina Web que emplea cdigo Java para generar un documento HTML
dinmicamente. Las pginas JSP se ejecutan en un componente del servidor
conocido como contenedor de JSP, que las traduce a servlets Java equivalentes.
Por esta razn los servlets y las pginas JSP estn ntimamente relacionados. Lo que
se puede hacer con una tecnologa es, en gran medida, tambin posible con la otra;
aunque cada una tiene sus capacidades propias. Como son servlets, las pginas JSP
tienen todas las ventajas de los servlets, pero adems tienen ventajas propias:
Se vuelven a compilar automticamente cuando es necesario.
Como estn en el espacio comn de documentos del servidor Web, dirigirse

a ellas es ms fcil que dirigirse a los servlets.
Como las pginas JSP son similares al HTML, tienen mayor compatibilidad
con las herramientas de desarrollo Web.
63
JavaScript es un lenguaje de programacin creado por Netscape con el objetivo de

integrarse en HTML y facilitar la creacin de pginas interactivas sin necesidad de
utilizar scripts de CGI o Java.
El cdigo de programa de JavaSript, llamado script, se introduce directamente en el

documento HTML y no necesita ser compilado, es el propio navegador el que se
encarga de traducir dicho cdigo.
Gracias a JavaScript podemos desarrollar programas que se ejecuten directamente en

el navegador (cliente) de manera que ste pueda efectuar determinadas operaciones o
tomar decisiones sin necesidad de acceder al servidor.
64
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 das 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.
La configuracin y administracin de Apache est basada en un sistema de ficheros,

editable desde un editor de textos. Las caractersticas principales de Apache son las
siguientes:
Permite
instalar
los
servicios
de
aplicacin
CGI,
Perl
Java.
Opcionalmente, y como medida comn de acceso a Internet por los equipos

de la empresa, dispone de un servicio proxy, permitiendo especificar la
seguridad de acceso a Internet, as como impedir el acceso no deseado
desde el exterior.
Implementa los ltimos protocolos, aunque se base en HTTP/1.1
Puede ser adaptado a diferentes entornos y necesidades, con los diferentes

mdulos de apoyo y con la API de programacin de mdulos.
Incentiva la realimentacin de los usuarios, obteniendo nuevas ideas,

informes de fallos y parches para solucionar los mismos.
65
Funciona sobre un gran nmero de plataformas (Unix, Linux, Vms,

Win32,OS2).
Mdulos cargados dinmicamente.
Utilizacin de SSL para transacciones seguras.
Soporte para host virtuales.
Alto desempeo.
Para conseguir que nuestro servidor web sea un servidor seguro, es conveniente
utilizar la tecnologa SSL (Secure Socket Layer) que detallamos a continuacin:
SSL
es una tecnologa 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
asimtrico
pblica/privada para negociar una clave de sesin que se
basado
en
claves
utilizar para establecer
una comunicacin basada en cifrado simtrico. SSL es el protocolo de cifrado ms

utilizado en Internet en estos momentos y es el ms usado en servidores web donde
se solicita informacin confidencial, adems es abierto y de dominio pblico, y su
implementacin es sencilla.
La seguridad de SSL actualmente proporciona servicios de cifrado de datos, servidor

de autenticacin, integridad de mensaje y autenticacin de cliente para una conexin
TCP/IP.
66
Cifrado de datos
La informacin transferida se cifra utilizando un algoritmo de clave secreta,

capaz de cifrar grandes volmenes de informacin en muy poco tiempo, por
lo que resultar ininteligible en manos de un atacante, garantizando as la
confidencialidad.
Autenticacin de servidores
El usuario puede asegurarse de la identidad del servidor al que se conecta y al

que posiblemente enve informacin personal confidencial. De esta forma se
evita que un usuario se conecte a un servidor impostor que haya copiado las
pginas del servidor al que suplanta. Estos ataques se conocen como Web
spoofing, y se utilizan para hacerse con las contraseas y nmeros de tarjeta
de crdito de los usuarios.
Integridad de mensajes
Se
impide
que
pasen
inadvertidas
modificaciones
intencionadas
accidentales en la informacin mientras viaja por Internet.

Autenticacin de cliente
Permite al servidor conocer la identidad del usuario, con el fin de decidir si

puede acceder a ciertas reas protegidas. En este caso, el cliente debe tener
instalado un certificado en su computadora o en una tarjeta inteligente, que le
permitir autenticarse ante el servidor web. Se evitan as ataques comunes de
captacin de contraseas mediante el uso de analizadores de protocolos
(sniffers) o el ataque por fuerza bruta con contraseas.
67
SSL puede tener una clave de sesin de 40 bits o de 128 bits, dicha clave es
generada en cada transaccin. La longitud de la clave har ms difcil romper
el
cifrado. La mayora de los navegadores soportan una clave de 40 bits para sesiones
SSL, mientras que las ltimas versiones soportan claves de sesin de 128 bits.
Las funciones son:
Verificacin de la Identidad
Emitir al servidor del cliente un Certificado Digital nico, asegurndole la

autenticidad a las personas que visitan su servidor web y permitiendo que
las comunicaciones se cifren para obtener una mayor privacidad, y
confiabilidad en las transacciones de comercio o de comunicacines.
Mantener la seguridad
Un servidor SSL debe mantener la seguridad e integridad de la informacin

a travs del mtodo de clave pblica/privada.
Facilidad de Utilizacin
A pesar de la gran seguridad que debe tener, el servicio debe ser de fcil
uso para los clientes sin grandes traumatismos que ocasionen confusiones.
Utilizaremos Apache como servidor de pginas web estticas, y lo enlazaremos con

Tomcat, trabajando este como contenedor de servlets. De esta forma liberamos de
trabajo a Tomcat, que lo utilizamos solo cuando realmente necesitamos la potencia
de Java, y utilizaremos Apache para el resto, aprovechando su robustez.
68
Tomcat, uno de los proyectos de cdigo abierto liderado por la Apache Software
Foundation, es una aplicacin web basada en Java creada para ejecutar servlets y
pginas JSP, siendo la implementacin oficial de referencia de las especificaciones
Servlet 2.3 y JSP 1.2.
Hemos decidido la utilizacin de Tomcat por los siguientes motivos:
Es gratuito y de cdigo libre.
Utilizaremos JSP para la generacin dinmica de pginas.
Nos permitir la utilizacin de JavaBeans que nos facilitar implementar la

lgica de la aplicacin en base a componentes, con lo que conseguimos
programar nuestra aplicacin orientada a objetos.
Proporciona una total integracin con el sistema operativo Windows

NT/2000/XP.
Adems para realizar la tarea de transferir un fichero al servidor, desde nuestras

pginas JSP, hemos utilizado un mdulo desarrollado en Java, totalmente gratuito y
disponible en la red, es el JspSmartUpload.
JspSmartUpload es un paquete de clases Java, que nos permitirn transferir ficheros

a nuestro servidor. En nuestro caso utilizaremos este mdulo para que los usuarios
que lo deseen nos transfieran las imgenes digitalizadas de sus huellas dactilares.
69
Vamos a explicar alguna de las caractersticas de este paquete:
Simple y Completo
Solo se necesitan unas pocas lneas de cdigo en nuestra aplicacin JSP

para realizar la tarea de transferir ficheros. Provee todas las caractersticas
que se necesitan para transferir uno o ms ficheros al servidor web usando
un navegador. De la misma forma, todos los ficheros pueden ser registrados
en una base de datos.
Control total sobre el proceso de subida de ficheros
Los objetos y mtodos del mdulo jspSmartUpload, permiten el acceso a

toda la informacin sobre los ficheros transferidos (tamao, nombre, tipo,
extensin, etc.), incluso sin salvar los ficheros a disco.
Gestin de formularios mixtos
JspsmartUpload proporciona un control total sobre formularios mixtos,

cargando tanto campos de ficheros como campos de formularios.
Control total sobre los ficheros enviados
Las caractersticas restrictivas de jspSmartUpload permiten mantener un

control total sobre los ficheros transferidos al servidor. Por ejemplo, se
puede limitar la transferencia de ficheros de acuerdo al tamao y tipo de los
mismos.
70
Para albergar nuestra base de datos tenemos una gran cantidad de sistemas gestores
de bases de datos. Barajando las distintas caractersticas de cada uno finalmente
hemos optado por el uso de MySQL.
Una caracterstica importante es que consume muy pocos recursos, tanto de CPU
como de memoria. Se sacrificaron algunas caractersticas esenciales en sistemas ms
serios con este fin
Ventajas
Buenos rendimientos. Mayor velocidad tanto al conectar con el servidor

como al servir consultas.
Utilidades de administracin (backup, recuperacin de errores, etc).
Control de acceso, en el sentido de qu usuarios tienen acceso a qu

tablas y con qu permisos.
JDBC (Java Data Base Connectivity) proporciona una interfaz estndar con el
servidor de base de datos. Provee una API que podemos usar sin importar qu base
de datos se est usando.
La conectividad de la base de datos de Java es un marco de programacin para los
desarrolladores de Java que escriben los programas que tienen acceso a la
informacin en bases de datos, hojas de calculo, y archivos "planos". JDBC se utiliza
comnmente para conectar un programa con una base de datos,
sin importar qu
software de administracin o gestor de base de datos se utilice para controlarlo. De

esta manera, JDBC es una plataforma cruzada . La figura 18 muestra un esquema de
uso de la interfaz JDBC:
71
Interfaz JDBC
Driver
ODBC
Driver
Sybase
Driver
Oracle
Base
Access
Base
Sybase
Base
Oracle
Figura 19. Interfaz JDBC

Sin importar la localizacin, la plataforma, o el programa piloto de la fuente de datos
(Oracle, Microsoft, etc.), el JDBC se conecta con una fuente de datos
proporcionando una coleccin de extensiones (class) que contienen las clases
abstractas de la interaccin de la base de datos. La ingeniera del software en los
programas con JDBC tambin conduce a la reutilizacin modular.
Para poder acceder a MySQL desde nuestras aplicaciones necesitaremos un driver.
Utilizaremos la ultima versin disponible en su la pgina oficial de MySQL, el
MySQL Connector/J 3.0.1
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
distribucin,
tiene
un
buen
rendimiento.
MySQL Connector/J es un driver nativo de Java que convierte las llamadas

generadas por JDBC en el protocolo de red que utiliza la base de datos de Mysql.
Permite al desarrollador trabajar con el lenguaje de programacin Java y de esta
72
forma
construir
programas
que
interactuan
con
Mysql.
Analizando todas estas opciones hemos decidido utilizar las siguientes

tecnologas en el desarrollo del presente proyecto:
Sistema gestor de base bases de datos MySQL.
JDBC para el acceso a la base de datos utilizando SQL.
Apache como servidor de pginas web estticas.
Generacin dinmica de pginas con JSP sobre el servidor Tomcat.
Javabeans para implementar nuestra aplicacin totalmente orientada a

objetos, utilizando clases Java.
El paquete Jspsmartupload para transferir los ficheros al servidor de nuestra

aplicacin.
73
Diseo e Implementacin
4.3 Diseo y desarrollo

4.3.1 Despliegue
La figura 19 muestra el diagrama de despliegue de la aplicacin.
Computadora
del Usuario
Servidor
de la
aplicacin
Terminal
del
Administrador
Lector de
huellas
Servidor
Web
Base
de
Datos
Figura 20. Despliegue de la aplicacin
74
La aplicacin reside en el servidor de la aplicacin, con acceso directo a la base de

datos. Tanto las tareas de los usuarios como las del administrador se podrn realizar
desde un simple navegador desde sus computadoras personales, conectndose va
web al servidor de la aplicacin.
4.3.2 Gestin
La figura 20 muestra el esquema de los distintos paquetes software desarrollados, as

como sus dependencias.
Clases Java
Clases
jspSmartUpload
Clases
Auxiliares
ClasesDominio
Clases Interfaz
Clases
Clases
Fingerprint
mySql-connector
Figura 21. Paquetes de la aplicacin
75
4.3.2.1 Clases Java
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.
4.3.2.2 Clases Auxiliares

Este paquete contiene las clases desarrolladas para facilitar la aplicacin. La
figura 21 muestra estas clases.
tElemento
tPersona
(from Logical View)
(from Logical View)
ID
Listar
Mostrar
id_persona
Superclase
genrica de
cualquier clase del
dominio
timagen
(from Logical View)
id_imagen
Clase para listar
Clase para
el contenido de
mostrar todos los
la base de
datos referentes a
datos
un usuario
recoger
Clase que nos

facilita el manejo del
valor de los campos
de los formularios
Figura 22. Clases Auxiliares.
76
4.3.2.3 Clases Dominio

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
(from Logical View)
ID
tPersona
timagen
(from Logical View)

id_persona
(from Logical View)

id_imagen
Huella
(from Logical View)
Administrador
Usuario
(from Logical View)
(from Logical View)
id_usu
mano
login
nombre
dedo
password
direccin
plantilla
c.p.
alta_admin()
localidad
alta()
baja()
provincia
generar_plantilla()
login()
pais
borrar()
estado
inicializar()
recuperar()
alta_usu()
autenticar()
actualizar()
recuperar()
inicializar()
Figura 23. Clases del dominio
77
4.3.2.4 Clases Interfaz

Este paquete contiene las clases propias de la interfaz de la aplicacin, son clases que
se utilizan para mostrar y capturar informacin referente a las clases del dominio. En
el caso de nuestra aplicacin se trata de pginas, tanto html como jsp. La figura 23
muestra el diagrama de clases de la interfaz.
Index
autenti_admin
usu_alta
ad_alta
ad_borrar
usu_huellas
autenticacin
ad_modif
Figura 24. Clases Interfaz
Cada clase representa una pgina alojada en nuestro servidor, que nos mostrar la
informacin que necesitemos en cada momento en funcin de la tarea que se vaya a
realizar.
Index: Esta clase representa la pgina de inicio de nuestra aplicacin y desde la que
se podr acceder a cada pgina en funcin de lo que se desee hacer.
78
PAGINAS ADMINISTRADOR
Autenti_admin: En esta pgina se pide al administrador que se identifique ante el

sistema, se utilizar autenticacin biomtrica para controlar el acceso a las pginas
desde las que realizar las tareas de administracin.
Opcin Alta Administrador
ad_alta: Esta clase representa la pgina en la que se muestran los usuarios que estn
en la base de datos, en espera de ser dados de alta, para que el administrador decida a
quien desea dar de alta.
Opcin Baja Administrador
ad_borrar: Lista los usuarios dados de alta, para que el administrador decida a quien
quiere dar de baja.
Opcin Modificar Administrador
ad_modif.: Clase encargada de mostrar los usuarios que estn dados de alta en la
base de datos, para que el administrador elija el que desee modificar.
PAGINAS USUARIO
Opcin Alta nuevo 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 enve los ficheros con las imgenes.
79
Opcin enviar huellas Usuario existente
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.
Opcin Autenticar Usuario
Autenticacin: En la pgina de autenticacin se pedir la identificacin al usuario,

la mano y el dedo sobre el que se va a realizar la validacin. Una vez introducidos se
capturar la huella del usuario y se autenticar con la de la base de datos.
80
4.3.2.5 Clases jspSmartUpload

La figura 24 muestra el diagrama de clases del mdulo JspSmartUpload:
SmartUpload
SmartUpload()
getFiles()
getRequest()
getBinaryData()
getSize()
Request
setAllowedFilesList()
setContentDisposition()
setDeniedFilesList()
setDenyPhysicalpath()
setMaxFileSize()
getParameter()
getParameterName()
getParameterValues()
setTotalMaxFileSize()
downloadField()
downloadFile()
save()
upload()
uploadlnFile()
File
fileToField()
getBinaryData()
getContentDisp()
Files
getContentString()
getContentType()
getFieldName()
getCount()
getFieldExt()
getFile()
getFileName()
getSize()
getfilePathName()
getSize()
getSubTypeMIME()
getTypeMIME()
isMissing()
saveAs()
Figura 25. Clases JspSmartUpload
81
4.3.2.5. Clases mysql-connector

Estas clases conectan con el gestor de base de datos desde las pginas 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 tambin importantes
son: Connection.class, ResultSet, etc.
4.3.2.6. Clases Fingerprint

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 autenticacin y la
generacin de una plantilla a partir de una imagen de huella.
82
Diagramas de Secuencia y Colaboracin
continuacin
mostraremos
los
diagramas
de
secuencia
colaboracin
correspondientes a cada uno de los casos de uso de nuestro sistema:
Diagrama de Secuencia: Autenticar Administrador
: Interfaz
: Aplicacin
: Administrador
: Administrador
Entrar
Pedir datos
Identificacion
Aceptar
Pedir dedo
Poner dedo
autenticar( )
Figura 26. Secuencia de Autenticar Administrador
83
Diagrama de Colaboracin: Autenticar Administrador
1: Entrar
4: Identificacion
5: Aceptar
2:
6:
: Aplicacin
: Interfaz
3: Introducir datos
: (Administrador)
9:
8:
7: autenticar( )
: Administrador
Figura 27. Diagrama de colaboracin, caso Autenticar Administrador
84
Diagrama de Secuencia: Visualizacin
: Administrador
: Interfaz
: Aplicacin
Pulsar tarea
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Figura 28. Secuencia de Visualizacin
85
Diagrama de Colaboracin: Visualizacin
1: Tarea
4: Seleccionar usuario
: Interfaz
7: Mostrar datos
: (Administrador)
3:
2: Listar usuarios
6:
5: Mostrar usuario
: Aplicacin
Figura 29. Diagrama de colaboracin, caso Visualizacin
86
Diagrama de Secuencia: Alta Administrador
: Interfaz
: Administrador
: Aplicacin
: Administrador
Pulsar alta
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Confirmar
OK
alta_admin( )
Figura 30. Secuencia de Alta Administrador
87
Diagrama de Colaboracin: Alta Administracin
1: Alta
9: OK
: Interfaz
7: Mostrar datos
8: Confirmar
: (Administrador)
2: Listar usuarios
5: Mostrar usuario
10:
3:
6:
13:
12:
: Aplicacin
: Usuario
11: alta( )
Figura 31. Colaboracin, caso Alta Administrador
88
Diagrama de Secuencia: Baja
: Interfaz
: Administrador
: Aplicacin
: Administrador
: Huella
Pulsar Baja
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Confirmar
OK
baja( )
borrar( )
Borrar huella
Figura 32. Secuencia de Baja
89
Diagrama de Colaboracin: Baja
2: Listar usuarios
1: Baja
5: Mostrar usuario
10:
9: OK
: Interfaz
: (Administrador)
: Aplicacin
7: Mostrar datos
8: Confirmar
3:
6:
15:
12:
14:
11: baja( )
13: borrar( )
Borrar huella
: Huella
: Administrador
Figura 33. Diagrama de colaboracin, caso Baja
90
Diagrama de Secuencia: Modificacin
: Interfaz
: Administrador
: Aplicacin
: Usuario
Pulsar modif.
Listar usuarios
Seleccionar usuario
Mostrar usuario
Mostrar datos
Modificar datos
Confirmar
OK
actualizar( )
Figura 34. Secuencia de Modificacin
91
Diagrama de Colaboracin: Modificacin
1: Modif
8: Modifficar datos
10: OK
: Interfaz
7: Mostrar datos
9: Confirmar
: (Administrador)
3:
6:
2: Listar usuarios
5: Mostrar usuario
11:
14:
13:
: Aplicacin
: Usuario
12: actualizar( )
Figura 35. Diagrama de colaboracin, caso Modificacin
92
Diagrama de secuencia: Alta Usuario nuevo
: Interfaz
: Aplicacin
: Usuario
: Huella
: Usuario
Pulsar alta
Mostrar formulario
Introd. datos
Aceptar
alta_usu( )
alta( )
Alta huella
Figura 36. Secuencia de Alta usuario nuevo
93
Diagrama de Colaboracin: Alta Usuario nuevo
1: Pulsar alta
4: Introd. datos
5: Aceptar
2: Mostrar formulario
6:
: Interfaz
: Aplicacin
3:
: (Usuario)
11:
10:
8:
Crear huella
7: Alta usuario
9: alta( )
: Huella
: Usuario
Figura 37. Diagrama de colaboracin, caso Alta usuario nuevo.
94
Diagrama secuencia: Alta usuario existente
: Aplicacin
: Usuario
: Huella
: Usuario
Pulsar Alta exist.

Mostrar formulario
Introducir datos
Aceptar
alta( )
alta huella
Figura 38. Secuencia de Alta usuario existente
95
Diagrama de Colaboracin: Alta Usuario existente
1: Pulsar alta
4: Introd. datos
2: Mostrar formulario
5: Aceptar
6:
: Interfaz
: Aplicacin
3:
9:
: (Usuario)
8:
Crear huella
7: alta( )
: Huella
Figura 39. Diagrama de colaboracin, caso Alta usuario existente
96
Diagrama secuencia: Autenticar Usuario
: Interfaz
: Aplicacin
: Usuario
: Usuario
Pulsar autenticar
Pedir datos
Introducir Datos
OK
Pedir dedo
Poner dedo
Autenticar
Figura 40. Secuencia de Autenticar
97
Diagrama de colaboracin: Autenticar
1: Pulsar autenticar
4: Introducir datos
2: Pedir datos
5: OK
6: Pedir dedo
8: Poner dedo
9:
: Interfaz
: Aplicacin
3:
: (Usuario)
7:
12:
11:
10: Autenticar
: Usuario
Figura 41. Diagrama de colaboracin, caso Autenticar
98
4.3.3 Visualizacin
En este apartado se mostrarn las funciones e interfaz de la aplicacin considerando
cada una de las pantallas de la misma.
Pgina principal
Desde la pgina principal, se accede tanto a las tareas de administracin como a las
utilidades de usuario.
Figura 42. Pantalla pgina principal
99
Alta Usuario nuevo

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. Adems se incluye
un campo para cada uno de los dedos de ambas manos, gestionando el envo de las
imgenes digitalizadas de los mismos.
Figura 43. Pantalla Alta usuario nuevo
100
Alta Usuario existente

En esta pantalla se muestra un formulario con los campos de los datos personales
requeridos
para identificarlo como un usuario existente. Adems se incluye un
campo para cada uno de los dedos de ambas manos, gestionando el envo de las
imgenes digitalizadas de los mismos.
Figura 44. Pantalla Alta usuario existente
101
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.
Figura 45. Pantalla Autenticacin I
102
Tras obtener los datos solicitados en la pantalla de la figura 39, se inicia el proceso
de autenticacin. Si la autenticacin tiene xito se muestra la imagen del dedo del
usuario, as como diversos datos referentes a esta: calidad de la imagen, tamao,
caractersticas adquiridas en el proceso de captura, nivel de coincidencia con la
huella en la base de datos, etc.
Figura 46. Pantalla Autenticacin II.
103
Autenticar Administrador
En esta pantalla se le solicita al administrador que se autentifique para controlar el

acceso a las pginas exclusivas del administrador. Este esquema de autenticacin
utiliza el propio del proyecto sobre el dispositivo lector de huellas dactilares.
Figura 47. Pantalla Autenticar Administrador
104
Alta Administrador
En esta pgina el administrador accede a la lista de usuarios en estado de espera para
ser dados de alta definitivamente. Seleccionando un usuario se dar de alta
definitivamente en la base de datos de la aplicacin.
Figura 48. Pantalla Alta AdministradorII
105
A continuacin se muestran todos los datos referentes al usuario, que constan en la

base de datos, para que el administrador si lo desea confirme el alta:
Figura 49. Pantalla Alta administrador II
106
Baja Administrador
Esta pgina proporciona una relacin 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.
Figura 50. Pantalla Baja AdministradorI
107
A continuacin se muestran todos los datos referentes al usuario, que constan en la

base de datos, para que el administrador si lo desea confirme la baja:
Figura 51. Pantalla Baja Administrador II
108
Modificar Administrador
En esta pgina se podrn modificar los datos personales de un usuario dado de alta en
la base de datos, al pulsar sobre la opcin modificar por parte del administrador. En
primer lugar, se visualiza una pgina con los usuarios dados de alta (figura 49).
Figura 52. Pantalla Modificar I
109
Una vez seleccionado un usuario, se accede a una pagina (formulario) en la que se

tienen todos sus datos. En esta pgina se introducen los cambios que se deseen, datos
que posteriormente se actualizarn.
Figura 53. Pantalla Modificar II
110
Validacin
5. Validacin del sistema

En la validacin de nuestro sistema usamos utilizamos base de datos que contiene 50
imgenes de huellas dactilares, pertenecientes a 5 personas distintas de las que
tendremos una imagen por cada dedo.
Cada imagen en la base de datos se compara con su propia plantilla y con las otras
49 plantillas. Si la comparacin de una huella con una plantilla del mismo dedo
resulta exitosa, se considera una autenticacin correcta, en caso contrario, estamos
ante un falso rechazo. Si se obtiene una autenticacin correcta al comparar una
huella con otra que no pertenece al mismo dedo, estamos ante lo que se denomina
una falsa aceptacin.
Utilizaremos los valores del porcentaje de autenticacin y del porcentaje de rechazo

como parmetros para la estimacin de la fiabilidad del sistema. Denotando al
nmero de falsos rechazos como num_rechazadas, num_correctas al nmero de
autenticaciones correctas y numero_falsas al nmero de falsas aceptaciones
obtenemos porcentaje de autenticacin y del porcentaje de rechazo de la siguiente
forma:
porcentaje de autenticacin =
num_correctas
100
num _ correctas + numero _ falsas
porcentaje de rechazo =
111
num _ rechazadas
100
50
Validacin
La tabla 2 muestra los valores obtenidos en el sistema desarrollado en el proyecto:
Usuario 1
Usuario 2
Usuario 3
Usuario 4
Usuario 5
% Autenticacin
99.9 %
99.88 %
99.65 %
99.45 %
98.94 %
% Rechazo
13.32 %
12.82 %
12.13 %
13.72 %
10.41 %
Tabla 2. Porcentaje de autenticacin y porcentaje de rechazo
Como se puede observar los valores son ptimos ( 99.5 % de media).
112
Conclusiones
6. Conclusiones
En este proyecto se incluye una pequea introduccin a la biometra y dentro de esta
al reconocimiento por huella digital. Quizs sera aventurarse demasiado asegurar
que dentro de unos aos la biometra estar implantada en tantos lugares que nos ser
familiar y hasta cotidiano.
Aunque parezca algo un tanto futurista, sobre todo pensando en otro tipo de
reconocimiento como los basados en sensores de calor o geometra facial, la
tecnologa avanza a pasos agigantados, sobre todo en las ltimas dcadas, y no sera
raro que se empezara por implantar en computadoras de acceso restringido y con
informacin muy crtica, como en empresas, bancos, etc. Desde ese momento, el que
cualquier persona tenga un sistema biomtrico en su computadora de sobremesa hay
un paso, o un abismo dependiendo por donde avance la tecnologa.
En concreto, para el desarrollo de este proyecto, se adquiri un lector de huellas

digitales por menos de 200 $.
En este proyecto se ha desarrollado una aplicacin cliente-servidor que permite una

gestin eficiente de huellas dactilares. Esta aplicacin permitir llevar a cabo
diversos estudios sobre esta tecnologa en un futuro cercano, especialmente en el
desarrollo nuevos algoritmos de autenticacin biomtrica.
113
Manual de Administrador
ANEXO I: Manual de Administrador
Gestin de huellas dactilares

en formato digital
V1.0
Instalacin
Base de datos
Para instalar la base de datos en el sistema sobre el que va a trabajar se tiene que:
Instalacin de MySQL
Primero se debe obtener una copia de una distribucin de MySQL. Para el desarrollo
del presente proyecto se utiliz la ltima versin disponible MySQL-3.23.49.
Para instalar la distribucin, se descomprime en un directorio vaco y se ejecuta el

setup.exe. Por defecto, MySQL para Windows est configurado para instalarse en
C:\mysql, si se quiere instalar en algn otro directorio, se puede instalar en
C:\mysql primero, y luego moverla al destino deseado. Si se mueve a otro destino,
se deber indicar la localizacin de cada cosa aadiendo una opcin --basedir en el
arranque del servidor.
114
Por ejemplo, si se ha movido la distribucin MySQL a D:\programas\mysql se

deber arrancar mysqld de la siguiente forma:
C:\> D:\programas\mysql\bin\mysqld basedir D:\programas\mysql
mysql help muestra todas las opciones que se le pueden pasar a mysqld en el
arranque.
En las ltimas versiones de MySQL, se puede crear un fichero C:\my.cnf que

configura todas las opciones por defecto para el servidor MySQL. Copiar el fichero
\mysql\my-xxxx.cnf a C:\my.cnf y editarlo para adecuarlo a la configuracin.
Especificar todos los caminos con / en lugar de \. Si se utiliza \ se deber
especificar dos veces, ya que \ es el carcter escape en MySQL.
Para instalar MySQL como un servicio en Windows2000, sistema operativo sobre el

que se desarrolla la aplicacin, se har lo siguiente:
C:\> C:\mysql\bin\mysql-nt install
Para iniciar y parar el servicio MySQL, se utilizan con los siguientes comandos
respectivamente:
C:\> NET START mysql
(iniciar MYSQL)
C:\> NET STOP mysql
(parar MYSQL)
Una vez instalado, se podr arrancar utilizando el SMC (Services Manager

Control) que se encuentra en el panel de control; o usando el comando NET START
mysql. Si se requiere alguna opcin, se deber especificar como Startup
parameters en la SMC antes de iniciar el servicio MySQL. Una vez que se est
115
ejecutando, mysqld-nt se puede parar usando Mysqladmin, desde la utilidad SMC o

por medio del comando NET STOP mysql.
Si no se quiere arrancar mysql-nt como un servicio, se arrancar de la siguiente

forma:
C:\> C:\mysql\bin\mysqld-nt --standalone

o
C:\> C:\mysql\bin\mysqld-nt standalone --debug
Tras instalar correctamente MySQL, se deber aadir nuestra base de datos para que
pueda ser utilizada por la aplicacin. Concretamente se trata de un directorio llamado
base que situamos en el directorio data en la ubicacin de instalacin de MySQL:
D:\mysql\data\base
Esta base de datos contiene las tres tablas que requiere nuestra aplicacin para su
funcionamiento: usuarios, huellas, administradores.
Servidor Apache
Instalacin 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 distribucin
binaria gratuita de Apache, apache<versin>, disponible en su pgina web oficial
http://www.apache.org.
116
Ejecutamos el archivo binario y seguimos las pantallas tpicas de instalacin de una

aplicacin windows, eligiendo durante este proceso el directorio de instalacin que
ms nos interese.
Para iniciar, detener y reiniciar el servidor teclearemos lo siguiente:
C:\<dir_apache>\Apache.exe
(iniciar apache)
C:\<dir_apache>\Apache.exe - k shutdwon
(detener apache)
C:\<dir_apache>\Apache.exe - k restart
(reiniciar apache)
Utilizaremos la opcin reiniciar para que tenga efecto cualquier cambio realizado en
los archivos de configuracin de Apache, sin necesidad de detener y volver a iniciar
el servidor.
Para probar que funciona nuestro servidor escribiremos en nuestro navegador

http://localhost:[puerto]/ y comprobaremos que nos muestra la pagina de bienvenida
de Apache. El parmetro puerto ser por defecto 8080, pudindolo modificar en el
archivo de configuracin httpd.conf.
Instalacin SSL
Primero se deben tener los mdulos mod_ssl y OpenSSL, que podemos obtener en el
sitio http://www.modssl.org/contrib/.
Para la instalacin de SSL en Apache deberemos introducir una serie de cambios en
su fichero de configuracin httpd.conf que describimos a continuacin:
En primer lugar se deben aadir los siguientes parmetros:
117
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/.
Se debe descomprimir el archivo Apache<versin>modssl<versin>.zip en un

nuevo directorio. Copiar los archivos ssleay32.dll y libeay32.dll del directorio
Apache\openssl\bin al directorio Windows\System en caso de Win9x o
WINNT/System32 en caso de WinNT/2000.
Para la creacin del certificado de prueba se deben seguir los pasos:
openssl req -config openssl.cnf -new -out mi-servidor.csr

Esto crea un certificado de requisicin de firma y una llave privada. Cuando pregunte
por "Common name (p.e. tu nombre de dominio)" se debe dar exactamente el
nombre de dominio (p.e. www.mi-servidor.com). El certificado pertenece al nombre
del servidor y los navegadores emiten un aviso de inconformidad si el nombre no
coincide.
openssl rsa -in privkey.pem -out mi-servidor.key

Esto remueve la contrasea de la llave privada. Se debe entender lo que significa
esto; mi-servidor.key debe ser solamente legible por el servidor Apache y el
administrador. Se debe borrar el archivo .rnd porque contiene informacin entrpica
para la creacin de la llave y podra usarse para ataques criptogrficos contra tu clave
privada.
118
openssl x509 -in mi-servidor.csr -out mi-servidor.cert -req -signkey mi-servidor.key

Esto crea un certificado con firma propia(llammoslo un certificado casero) que
puedes usar en tanto obtienes uno de validez oficial proveniente de una autoridad
certificada..
A continuacin crear el directorio <dir-apache>\conf\ssl y mover los archivos miservidor.key y mi-servidor.cert en el. Copiar todos los archivos de la distribucin de
Apache_mod_ssl en el directorio de instalacin original de Apache.
Localizar las directivas LoadModule en el archivo httpd.conf y aadir lo siguiente al

final de los existentes:
LoadModule ssl_module modules/mod_ssl.so

AddModule mod_ssl.c
Adems se debe aadir lo siguiente al final del archivo httpd.conf:
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
Iniciar el servidor desde la lnea de comandos con el propsito 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
Instalacin Tomcat
La instalacin de Tomcat requiere tener instalado previamente JRE (Java Runtime
Environment) conforme al JRE 1.1 o superior, incluyendo algn sistema con
plataforma Java2. Se necesita un compilador Java, como el incluido en el JDK (Java
Development Kit) 1.1 o superior.
Tras instalar este software en nuestra computadora se debe obtener el archivo binario
de versin apropiada de jakarta-tomcat<versin>. En el proyecto se utiliza
jakarta-tomcat3.3.1.
Se ejecuta el binario y se instala el servidor en el directorio deseado. A continuacin

se aaden
las variables de entorno java, para que Tomcat pueda utilizarlos. En
nuestro caso se har lo siguiente:
Mi Pc-> Propiedades-> Avanzado-> Variables de entorno
en variables del sistema se aaden las variables:
JAVA_HOME - d:\jdk
TOMCAT_HOME - d:\jakarta-tomcat
120
Para iniciar y parar el servidor se abrir una ventana DOS y se proceder de la

siguiente forma:
D:\jakarta-tomcat\bin\startup.exe
(iniciar Tomcat)
D:\jakarta-tomcat\bin\shutdown.exe
(parar Tomcat)
Para
verificar
que
funciona
se
puede
acceder
http://localhost:[puerto]/
comprobando que muestra la pagina de bienvenida de Tomcat. El parmetro puerto

ser por defecto 80, pudiendose cambiar en el archivo de configuracin de Tomcat
web.xml, para no tener conflictos con el servidor web Apache.
Teniendo el servidor instalado correctamente, se est en situacin de alojar nuestra

aplicacin. Para su despliegue, la aplicacin debe situarse en un nico archivo
denominado Web archive (war). En nuestro caso la aplicacin est empaquetada
en el archivo proyecto.war.
Tomcat, permite que el archivo .war simplemente quede en el directorio

<directorio_de_inicio_tomcat>/webapps. Cuando se reinicia Tomcat, el archivo .war
se desempaqueta y se valida, y nuestra aplicacin queda disponible. Esto es lo que
se debe hacer con proyecto.war.
El prximo paso es indicarle a nuestra aplicacin el lugar donde hemos instalado

Tomcat, para ello aadiremos el contexto a nuestro archivo web.xml, que se
encuentra en el directorio WEB-INF de nuestra aplicacin.
La aplicacin hace uso del directorio donde tenemos instalado Tomcat, por ello
introduciendo una variable que le indique este directorio, obteniendo una aplicacin
independiente del lugar donde se instale.
121
Con el parmetro directorio, indicamos el camino completo desde el directorio de

instalacin de Tomcat, hasta el directorio donde se almacenarn las huellas y
plantillas (upload).
Introduciremos el parmetro directorio en web.xml, y lo inicializaremos al

directorio de nuestra instalacin, finalizando en el directorio upload, en donde se
almacenarn las huellas y plantillas, de la siguiente forma:
<context-param>
<param-name>directorio</param-name>
<param-value>D:/<dir_tomcat>t/webapps/proyecto/upload/
</param-value>
</context-param>
Enlazar Apache con Tomcat

Para enlazar el servidor web Apache con el contenedor de servlets Tomcat
necesitamos instalar el mdulo mod_jk en el directorio correspondiente de Apache.
Descargamos el fichero mod_jk.dll en la direccin http://www.apache.org/dist/ y lo

copiamos al subdirectorio modules dentro del directorio de Apache .
Al
ejecutar
Tomcat,
se
crea
tomcat>\conf\tomcat-apache.conf,
automticamente
el
fichero
c:\<dir-
lo copiamos con otro nombre p.e. c:\ <dir-
tomcat>\conf\mio-tomcat-apache.conf.
Esto es necesario porque vamos a modificarlo, pero Tomcat lo sobrescribe cada vez
que arranca con lo que perderamos las modificaciones si no lo renombramos.
122
Del nuevo fichero hay que quitar todas las referencias a JServMount y cambiarlas por
JkMount (no se pueden mezclar JServ y mod_jk). Adems al principio del fichero
hay que poner las siguientes lneas:
LoadModule jk_module libexec/mod_jk.dll

AddModule mod_jk.c
JkWorkersFile c:\<dir-tomcat>\conf\workers.properties
JkLogFile c:\<dir_apache>\logs\mod_jk.log
JkLogLevel warn
JkMount /*.jsp ajp13
JkMount /servlet/* ajp13
JkMount /otherworker/*.jsp remoteworker
Por ltimo aadimos al final del fichero de Apache conf\httpd.conf la lnea:
include c:\<dir_tomcat>\conf\mio-tomcat-apache.conf
con esto indicamos a Apache las nuevas directivas para los servlets.
Ya tenemos instalado el mdulo. Arrancamos en primer lugar Tomcat y a
continuacin 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 continuacin se describe lo que contiene cada directorio de nuestra aplicacin:
Directorio Raz
Contiene las pginas .html de nuestra aplicacin, entre las que se encuentra la pgina
de inicio.
123
Directorio JSP
Como su propio nombre indica contiene las pginas .jsp, que junto con las pginas
.html forman la interfaz de nuestra aplicacin.
Directorio Recursos
Aqu se mantienen los archivos (imgenes, botones, iconos, etc) que se van a usar en
las pginas de la aplicacin.
Directorio Upload
Aqu es donde se transfieren las imgenes de las huellas de los usuarios. Adems
mantiene las plantillas generadas por la aplicacin a partir de las imgenes 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 aplicacin.
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 aplicacin web.
Adems 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 automticamente a disposicin del cargador de clases sin
tener que estar explcitamente listadas en la ruta de clases.
Aqu es donde situaremos las libreras de clases para el acceso al lector de huellas
(FPJni.jar) y las clases que nos permitirn acceder a MySQL desde las pginas
(mysql-connector-java-3.0.1-beta-bin.jar).
124
Directorio classes
Este directorio contiene servlets y otras clases. Aqu se pueden ubicar los paquetes
que utilizados en la aplicacin, en nuestro caso el paquete jspSmartUpload (com) y
las clases desarrolladas para modelar la aplicacin: usuario, huella y administrador.
JspSmartUpload
Todos
los
ficheros
jspsmartUpload
vienen
en
un
fichero
comprimido
jspSmartUpload.zip. Se descarga el archivo comprimido, y se descomprime en un

directorio temporal asegurndonos de que la estructura de directorios est intacta. Si
por ejemplo, se extrae el fichero en /temp, se debera tener lo siguiente:
Para poder utilizar este paquete en las pginas JSP de nuestra aplicacin, se tendr
que ubicar en el directorio de la aplicacin. Concretamente la estructura de directorio
de Tomcat nos indica que hay que situarlo en el directorio WEB-INF\classes.
Lector de huellas
Para instalar el hardware de captura de huellas que se utiliza en el proyecto se
introduce el CDROM que viene con el lector y seguimos el men se instalacin,
seleccionando la opcin Development Toolkit.
125
La instalacin copiar el archivo FPJni.dll en el directorio d:\winnt\system32 de

nuestro disco duro, que se corresponde con el directorio de Windows2000. Este
archivo es el que contiene el cdigo que implementa todo lo que se puede hacer con
el lector: capturar huella, salvar huella, comparar huella, generar plantilla, ...
La API Java que se utiliza en nuestra aplicacin esta en el archivo jar FPJni.jar,
que
126
no
son
ms
que
un
conjunto
de
clases
empaquetadas.
Comandos de creacin de tablas
Anexo II: Comando de creacin de tablas

Para la creacin de las tablas de la base de datos, se incluye a continuacin una serie
de comandos SQL, utilizando los comandos SQL92 (ANSI SQL) soportados por
MySQL, se decidiera migrar la aplicacin a otra base de datos estos comandos nos
facilitaran las cosas. Por otra parte MySQL soporta SQL92, aunque le aada algunas
extensiones.
En el caso de utilizar un Sistema gestor de base de datos relacional, a los comandos

de creacin se les tendr que unir los comandos de autorizaciones y vistas
pertinentes, que sern propios del entorno de trabajo.
Para garantizar la integridad referencial, se tiene en consideracin que no se pueden

cambiar las claves principales.
Tabla Administradores
CREATE TABLE ADMINISTRADORES
(
ID_ADMINISTRADOR INTEGER PRIMARY KEY,
NOMBRE VARCHAR(15) NOT NULL,
PLANTILLA VARCHAR(15) NOT NULL
);
127
Comandos de creacin de tablas
Tabla Usuarios
CREATE TABLE USUARIOS
(
ID_USUARIO INTEGER PRIMARY KEY,
NOMBRE VARCHAR(50) NOT NULL,
DIRECCION VARCHAR(50),
CP INTEGER,
LOCALIDAD VARCHAR(20),
PAIS VARCHAR(15),
ALTA CHAR(1)
);
Tabla Huellas
CREATE TABLE HUELLAS
(
ID_HUELLA INTEGER PRIMARY KEY,
MANO CHAR(1) NOT NULL,
DEDO CHAR(1) NOT NULL,
PLANTILLA VARCHAR(15) NOT NULL,
Id_usuario INTEGER,
CONSTRAINT FOREING KEY (Id_usuario) REFERENCES
USUARIOS(ID_USUARIO) ON DELETE CASCADE,
);
128
Bibliografa
Bibliografa
[1] Damon Hougland, Aarn Tavistock. Gua esencial JSP. Pearson Educacin
S.A, Madrid, 2002.
[2] Phil Hanna. JSP. Manual de referencia. McGraw-Hill, Madrid, 2002.
[3] John Zukowski.Programacin en Java 2. Ediciones Anaya Multimedia,

Madrid, 1999.
[4] Rich Bowen & Ken Coar, Servidor Apache al Descubierto. Pearson Educacin,
S.A. Madrid, 2000.
[5] Lemay, Laura, Aprendiendo HTML 4 para web en una semana. Prentice Hall,
Mxico, 1998.
[6] Juan Carlos Ors, Diseo de pginas 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.
[8] Herbert Schidt, Java 2 - Manual de Referencia. McGraw-Hill, Madrid, 2001
[9] Agustn Froure Quintas, Java Server Pages Manual de usuario y tutorial. RAMA, Madrid, 2002
129
Bibliografa
[10] Jayson Falke, Ben Galbraith, Romin Irani, ... Fundamentos Desarrollo Web con
JSP. Anaya Multimedia, Madrid, 2002
[11] G.Booch, J. Rumbaugh, I. Jacobson, El Lenguaje Unificado de Modelado.

Addison Wesley, Madrid, 1999.
130
Direcciones web
Direcciones web
http://desaweb.forosdelweb.com
http://www.programacion.com
http://www.javahispano.org -
- Foros del Web
- Java en castellano. Foros de debate
Java en Castellano
http://www.programadores.com.sv -
Comunidad salvadorea de programadores
http://www.mysql.com - MySQL
http://java.sun.com -
Pagina oficial sobre Java y tecnologas
http://www.jspsmart.com -
JspSmartUpload para subir ficheros
http://jakarta.apache.org - Tomcat
http://www.ii.uam.es/~abie/ - Asociacin de Biometra Informtica Espaola
http://www.ictnet.es/ICTnet/cv/comunidad.jsp?area=engInf&cv=biometrica
- Comunidad de Biometra
131
ndice de Figuras
ndice de figuras
Figura 1. Diagrama Sistema Reconocimiento Biomtrico .............................. 13
Figura 2. Relacin entre FAR, FRR y ERR ...................................................... 14
Figura 3. Huella dactilar con minucias ............................................................ 16
Figura 4. Huella original y huella normalizada ................................................ 24
Figura 5. Huella orientada y campos realineados ............................................ 25
Figura 6. Variaciones de la huella y regin importante ................................... 26
Figura 7. Imagen filtrada e imagen binaria .................................................... 27
Figura 8 . Imagen despus del primer filtro perfilador e imagen
despus del segundo filtro perfilador con mscara espacial ......... 28
Figura 9. Imagen despus del adelgazamiento y eliminacin de
imperfecciones y patrn de minucias despus del proceso de
eliminacin de conjuntos ................................................................... 29
Figura 10. Patrn de minucias ........................................................................... 30
Figura 11. Alineacin de la cresta de entrada y la cresta plantilla ................. 32
Figura 12. Actores del sistema ........................................................................... 40
Figura 13. Casos de uso de Administrador ...................................................... 41
Figura 14. Casos de uso Usuario ....................................................................... 44
Figura 15. Modelo EntidadRelacin ............................................................... 48
Figura 16. Modelo de servidor de documentos estticos ................................ 53
Figura 17. Contenido dinmico por secuencia de comandos CGI ................. 55
Figura 18. Aplicaciones dinmicas usando servlets, JSP y J2EE .................. 56
Figura 19. Interfaz JDBC .................................................................................. 72
Figura 20. Despliegue de la aplicacin ............................................................. 74
Figura 21. Paquetes de la aplicacin ................................................................. 75
Figura 22. Clases Auxiliares .............................................................................. 76
Figura 23. Clases del dominio ............................................................................ 77
Figura 24. Clases Interfaz .................................................................................. 78
132
ndice de Figuras
Figura 25. Clases JspSmartUpload ................................................................... 81

Figura 26. Secuencia de Autenticar Administrador ....................................... 83
Figura 27. Diagrama de colaboracin, caso Autenticar Administrador ...... 84
Figura 28. Secuencia de Visualizacin ............................................................. 85
Figura 29. Diagrama de colaboracin, caso Visualizacin ............................. 86
Figura 30. Secuencia de Alta Administrador ................................................... 87
Figura 31. Colaboracin, caso Alta Administrador ....................................... 88
Figura 32. Secuencia de Baja ............................................................................ 89
Figura 33. Diagrama de colaboracin, caso Baja ............................................ 90
Figura 34. Secuencia de Modificacin .............................................................. 91
Figura 35. Diagrama de colaboracin, caso Modificacin ............................. 92
Figura 36. Secuencia de Alta usuario nuevo ................................................... 93
Figura 37. Diagrama de colaboracin, caso Alta usuario nuevo .................... 94
Figura 38. Secuencia de Alta usuario existente .............................................. 95
Figura 39. Diagrama de colaboracin, caso Alta usuario existente .............. 96
Figura 40. Secuencia de Autenticar .................................................................. 97
Figura 41. Diagrama de colaboracin, caso Autenticar ................................. 98
Figura 42. Pantalla pgina principal ................................................................ 99
Figura 43. Pantalla Alta usuario nuevo ............................................................ 100
Figura 44. Pantalla Alta usuario existente ........................................................ 101
Figura 45. Pantalla Autenticacin I ................................................................. 102
Figura 46. Pantalla Autenticacin II ................................................................ 103
Figura 47. Pantalla Autenticar Administrador ............................................... 104
Figura 48. Pantalla Alta administrador I ......................................................... 105
Figura 49. Pantalla Alta administrador II ....................................................... 106
Figura 50. Pantalla Baja administrador I ........................................................ 107
Figura 51. Pantalla Baja Administrador II .................................................... 108
Figura 52. Pantalla Modificar I ........................................................................ 109
Figura 53. Pantalla Modificar II ....................................................................... 110
133
ndice de Tablas
ndice de Tablas
Tabla 1. Candidatos a Entidad y Relacin ....................................................... 47
Tabla 2. Porcentaje de autenticacin y porcentaje de rechazo ...................... 110
134

Proyecto Biometria PDF

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

Proyecto Biometria PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDADE DA CORUA

PROXECTO FIN DE CARREIRA DE ENXEERA TCNICA EN

Sistema de gestin de huellas dactilares en

Autor: Jos Antonio Orgueira Prez

A todos los que me ofrecieron su ayuda desinteresada en los foros de Internet

A Nino, por todo.

A todos ellos, Gracias.

Sistema de Gestin de huellas

El sistema har la autenticacin de los usuarios a travs de un dispositivo lector de

Tanto la gestin de la base de datos como las comprobaciones de usuarios registrados

Apache, Java, JSP, Javabeans, MySQL

Sistema de Gestin de huellas

dactilares en formato digital

2. DOMINIO DE APLICACIN. AUTENTICACIN Y HUELLAS DACTILARES

2.1. Autenticacin de usuarios

2.2. Autenticacin biomtrica

2.3. Huellas dactilares

3. ESTADO DEL ARTE

3.2. Los dedos de gelatina de Matsumoto

3.3. Algoritmo de huellas

4.2. Lenguajes y herramientas

4.3. Diseo y desarrollo

5. VALIDACIN DEL SISTEMA

Sistema de Gestin de huellas

dactilares en formato digital

ANEXO I: Manual del Administrador

stas tcnicas de identificacin biomtrica, frente a otras formas de autenticacin

Posible variabilidad con el tiempo del patrn a identificar (afonas,

De este modo, en funcin de la situacin en que necesitemos realizar una

fundamentales anteriormente mencionados.

En este contexto, el objetivo de este proyecto es el desarrollo de un sistema de

Por ultimo el sistema dispondr de la posibilidad de la autenticacin de un usuario

Todo el proceso se realizara a travs de Internet, sobre una arquitectura

Los objetivos principales del proyecto son:

Diseo y desarrollo de una base de datos con informacin sobre los

Diseo y desarrollo del sistema de gestin.

Integracin de un algoritmo de autenticacin sobre las huellas facilitadas.

Validacin del sistema.

2. Domino de aplicacin. Huellas dactilares en

2.1 Autenticacin de Usuarios

Sin embargo, lo que habitualmente hace el usuario es introducir su identidad (un

problema de una poblacin potencialmente muy elevada a un grupo de usuarios ms

Los mtodos de autenticacin se suelen dividir en tres grandes categoras, en funcin

Es fcil identificar ejemplos de cada uno de estos tipos de autenticacin: un

Por supuesto, un sistema de autenticacin puede, y debe, para incrementar su

Cualquier sistema de identificacin (aunque se les llame as, recordemos que

2.2. Autenticacin biomtrica

Estos sistemas son los denominados biomtricos, basados en caractersticas fsicas

La autenticacin basada en caractersticas fsicas existe desde que existe el hombre y,

Los dispositivos biomtricos tienen tres partes principales:

Un mecanismo automtico que lee y captura una imagen digital o analgica

Una entidad para manejar aspectos como la compresin, almacenamiento o

Una interfaz de aplicaciones.

En la figura 1 se muestra la estructura clsica del Diagrama de Bloques de un

Figura 1. Diagrama Sistema Reconocimiento Biomtrico

Es en la Decisin donde principalmente entran en juego las dos caractersticas

Para determinar las prestaciones de un sistema biomtrico se suele utilizar la tasa de

SR= 1 (FAR +FRR)

El FAR y el FRR responden a parmetros inversamente proporcionales, por tanto,

Figura 2. Relacin entre FAR, FRR y ERR

2.3. Huellas dactilares

Cuando un usuario desea autenticarse ante el sistema sita su dedo en un rea

Figura 3. Huella dactilar con minucias