Proyecto Biometria

UNIVERSIDADE DA CORUÑA

FACULTADE DE INFORMÁTICA Departamento de Tecnoloxías da Información e as Comunicacións

PROXECTO FIN DE CARREIRA DE ENXEÑERÍA TÉCNICA EN INFORMÁTICA DE XESTIÓN

Sistema de gestión de huellas dactilares en formato digital

Autor: José Antonio Orgueira Pérez Tutor: Antonino Santos del Riego

A Coruña, enero de 2003

Titles you can't find anywhere else

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.































Agradecimientos A mis padres, familiares, amigos y compañeros de facultad porque sin ellos nada sería 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 Gestión de huellas dactilares en formato digital

Resumen Este proyecto constituye un acercamiento al ámbito de la biometría. En concreto, nos centraremos en el reconocimiento de huellas dactilares, desarrollando un sistema que, sobre el soporte de una base de datos, permita una gestión de las entidades involucradas sobre una arquitectura cliente-servidor. El sistema hará la autenticación de los usuarios a través de un dispositivo lector de huellas dactilares. En el proceso de autenticación se utiliza el algoritmo de comprobación de plantillas basadas en la obtención de minucias. Tanto la gestión de la base de datos como las comprobaciones de usuarios registrados estarán orientadas a la WEB, pudiéndose realizar cualquiera de las tareas a través de un navegador.

Palabras claves Biometría,

Autenticación,

Reconocimiento,

Apache, Java, JSP, Javabeans, MySQL

Huellas

dactilares,

Web,

Tomcat,































Sistema Sistema de Gestión de huellas

Índice

dactilares en formato digital

ÍNDICE 1. INTRODUCCIÓN INTRODUCCI ÓN

6

2. DOMINIO DE APLICACIÓN. APLICACIÓN. AUTENTICACIÓN Y HUELLAS HUELLAS DACTILARES DACTILARES 2.1. Autenticación Autenticación de usuarios 2.2. Autenticación biométrica 2.3. Huellas dactilares

9 11 15

3. ESTADO DEL ARTE 3.1. Huella digital por ultrasonidos 3.2. Los dedos de gelatina de Matsumoto 3.3. Algoritmo de huellas

20 21 23

4. METODOLOGÍA 4.1. Modelado 4.2. Lenguajes y herramientas 4.3. Diseño y desarrollo

36 53 74

5. VALIDACIÓN DEL SISTEMA

111

6. CONCLUSIONES

113































Sistema Sistema de Gestión de huellas

Índice

dactilares en formato digital

ANEXO I: Manual del Administrador ANEXO II: Comando de creación de tablas

114 127

BIBLIOGRAFÍA

129

DIRECCIONES WEB

131

ÍNDICE DE FIGURAS

132

ÍNDICE DE TABLAS

134































Introducción

1. INTRODUCCIÓN En el ámbito de las tecnologías 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 físico. De este modo, surge la biometría, también conocida como técnicas de identificación biométrica, con el objetivo de resolver este problema a partir de las características propias de cada individuo, como la voz, huella dactilar, rostro, etc. Éstas técnicas de identificación biométrica, frente a otras formas de autenticación personal como el uso de tarjetas o PINes (Personal ), o número Personal Identification Number ), de identificación personal, como el usado en cajeros automáticos, tienen la ventaja de que los patrones no pueden perderse o ser sustraídos, 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 autenticación actuales están basados únicamente en el uso de una tarjeta personal y, o, un PIN, con sus consecuentes problemas de seguridad. Sea cual sea la técnica seleccionada para una determinada aplicación, tendremos que ponderar en cada caso las restricciones o peculiaridades que pueden tener cada una de las técnicas, frente al grado de seguridad añadido que conseguimos y del que anteriormente no disponíamos. Estas características vienen dadas básicamente por los siguientes aspectos: ü

Necesidad de un dispositivo de adquisición específico (lector de huella dactilar, micrófono, cámara, etc.) allí donde esté el usuario.

































Introducción

ü

Posible variabilidad con el tiempo del patrón a identificar (afonías, catarros en voz, uso de gafas/bigote/barba en el rostro, etc.).

ü

Probabilidad de error individual de cada una de las técnicas (en función de la técnica elegida).

ü

Aceptación por parte del usuario de cada una de las técnicas, en función de si son o no técnicas intrusivas, cómodas, que mantengan (o al menos lo parezca) la privacidad, sencillas de usar, etc.

De este modo, en función de la situación en que necesitemos realizar una autenticación segura del usuario, se buscará cuál es la técnica (ó combinación de técnicas) biométrica más adecuada en función de los cuatro parámetros fundamentales anteriormente mencionados. En este contexto, el objetivo de este proyecto es el desarrollo de un sistema de gestión 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 imágenes digitalizadas de sus huellas, pudiendo enviarnos un número variable de estas, una por cada uno de los dedos. Tras la solicitud, será el administrador del sistema el que se encargue, de la gestión de la información generada (altas, bajas, modif.).































Introducción

Todo el proceso se realizara a través de Internet, sobre una arquitectura cliente-servidor. Los objetivos principales del proyecto son: ü

Diseño y desarrollo de una base de datos con información sobre los usuarios e imágenes de sus huellas dactilares.

ü

Diseño y desarrollo del sistema de gestión.

ü

Integración de un algoritmo de autenticación sobre las huellas facilitadas.

ü

Validación del sistema.































Dominio de la aplicación

2. Domino de aplicación. Huellas dactilares en formato digital 2.1 Autenticación de Usuarios En la actualidad uno de los requisitos primordiales de los sistemas informáticos 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 cómputo), mediante procesos tan simples como una contraseña 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 físico o la forma de hablar, son demasiado complejos para una computadora; el objetivo de los sistemas de identificación de usuarios no suele ser identificar a una persona, sino autenticar que esa persona es quien dice ser realmente. Aunque seguramente ambos términos nos parecerán equivalentes, para una computadora existe una gran diferencia entre ellos: imaginemos un sistema de identificación biométrico basado en el reconocimiento de la retina; una persona miraría a través del dispositivo lector, y el sistema sería capaz de decidir si es un usuario válido, y en ese caso determinar de quién se trata; esto es identificación.
































problema de una población potencialmente muy elevada a un grupo de usuarios más reducido, el grupo de usuarios del sistema que necesita autenticación. Los métodos de autenticación se suelen dividir en tres grandes categorías, en función de lo que utilizan para la verificación de identidad: (a) algo que el usuario sabe, (b) algo que éste posee, y (c) una característica física del usuario o un acto involuntario del mismo. Esta última categoría se conoce con el nombre de autenticación biométrica. Es fácil identificar ejemplos de cada uno de estos tipos de autenticación: 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 característica física del usuario. Por supuesto, un sistema de autenticación puede, y debe, para incrementar su fiabilidad, combinar mecanismos de diferente tipo, como en el caso de una tarjeta de crédito unida al PIN de los cajeros automáticos o en el de un dispositivo generador de claves para el uso de One Time Passwords . Cualquier sistema de identificación (aunque se les llame así, recordemos que realmente son sistemas de autenticación) ha de poseer unas determinadas características para ser viable; obviamente, ha de ser fiable con una probabilidad muy elevada, económicamente factible para la organización y ha de soportar con éxito
































comprobar que es quien dice ser; seguramente sería barato y altamente fiable, pero nadie aceptaría dar un poco de sangre cada vez que desee consultar su correo.

2.2. Autenticación biométrica A pesar de la importancia de la criptología en cualquiera de los sistemas de identificación de usuarios, existe otra clase de sistemas en los que no se aplica esta ciencia, o al menos su aplicación es secundaria. Es más, parece que en un futuro no muy lejano estos serán los sistemas que se van a imponer en la mayoría de las situaciones en las que se haga necesario autenticar a un usuario. En general son más amigables para el usuario, no va a necesitar recordar passwords o números de identificación complejos y, como se suele decir, el usuario se puede olvidar la tarjeta de identificación identificación en casa, pero nunca nunca se olvidará de su mano o su ojo, y son mucho más difíciles de falsificar que una simple contraseña o una tarjeta magnética. Las principales razones por la que no se han impuesto ya en nuestros días es su elevado precio, fuera del alcance de muchas organizaciones, y su dificultad de mantenimiento. Estos sistemas son los denominados biométricos, basados en características físicas del usuario a identificar. El reconocimiento de formas, la inteligencia artificial y el aprendizaje son las ramas de la informática que desempeñan el papel más importante en los sistemas de identificación biométricos; la criptología se limita aquí a un uso


































La autenticación basada en características físicas existe desde que existe el hombre y, sin darnos cuenta, es la que más 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 fácil porque es una persona, pero en el modelo aplicable a redes de comunicaciones el agente ha de ser un dispositivo que, basándose en características del sujeto a identificar, gestione el acceso a un determinado recurso. Los dispositivos biométricos tienen tres partes principales: ü

Un mecanismo automático que lee y captura una imagen digital o analógica de la característica a analizar.

ü

Una entidad para manejar aspectos como la compresión, almacenamiento o comparación de los datos capturados con los registrados en una base de datos (que son considerados válidos).
































En la figura 1 se muestra la estructura clásica del Diagrama de Bloques de un Sistema de Reconocimiento Biométrico.

Adquisición de datos Persona Autentificador Incógnita

Preproc. de la Señal

Extracción de Características

Obtención de los Modelos de la BD

Algoritmo de Reconocimiento

Figura 1. Diagrama Sistema Reconocimiento Biométrico

Decisión
































Para determinar las prestaciones de un sistema biométrico se suele utilizar la tasa de éxito (Success Rate, SR) que responde a una combinación de los dos factores anteriores: SR= 1 – (FAR +FRR)

El FAR y el FRR FRR responden a parámetros inversamente proporcionales, por tanto, variarán en función de las condiciones prefijadas por el programa de identificación biométrica. Así si por ejemplo se tiene que utilizar el programa en un entorno de máxima seguridad, se intentará que el FAR sea lo más pequeño posible, aunque esta FRR. acción signifique de forma explícita, el incremento drástico del factor FRR

Por lo tanto se debe fijar un parámetro o umbral que permita igualar los dos factores, asegurando de esta manera el óptimo funcionamiento del sistema. Este umbral se denomina tasa de error igual ( Equal Error Rate, ERR), y es el que determinará, finalmente, la capacidad de identificación del sistema. En la figura 2 se muestra la relación dicha relación.
































2.3. Huellas dactilares Típicamente la huella dactilar de un individuo ha sido un patrón bastante bueno para determinar su identidad de forma inequívoca, 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 convertirían antes o después en un modelo de autenticación biométrico: desde el siglo pasado hasta nuestros días se vienen realizando con éxito clasificaciones sistemáticas de huellas dactilares en entornos policiales, y el uso de estos patrones fue uno de los primeros en establecerse como modelo de autenticación biométrica. Cuando un usuario desea autenticarse ante el sistema sitúa 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
































Figura 3. Huella dactilar con minucias

Las huellas huellas de de los dedos presentan como característica principal, la presencia de un


































Está demostrado que dos dedos nunca pueden poseer más de ocho minucias comunes, y cada uno tiene al menos entre 30 y 40 de éstas. En la figura 3 se muestra una imagen de una huella digitalizada con sus minucias. Si la comparación de las posiciones relativas de las minucias minucias leídas con las almacenadas almace nadas en la base de datos es correcta, se permite el acceso al usuario, denegándose obviamente en caso contrario. Los sistemas basados en reconocimiento de huellas son relativamente baratos, en comparación con otros biométricos, 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 pequeño corte o una quemadura que afecte a varias minucias pueden hacer inútil al sistema. También elementos como la

































Estado del Arte

3. Estado del Arte

Algunos aeropuertos experimentan tecnologías de seguridad que basadas en el reconocimiento del iris y la mano. La identificación dactilar es uno de los más extendidos; el rostro, el menos invasivo. La asignatura pendiente, la estandarización. Poner el dedo en un escáner, hablar por un micrófono o mirar de cerca a una cámara puede ser suficiente para pasar el control de seguridad y acceder a una instalación o sistema informático. La tecnología biométrica ha traspasado los laboratorios de

































Estado del Arte

Gobierno de Estados Unidos, salió del grupo de 60 empresas y agencias para crear su propia tecnología. El Departamento de Defensa cuenta con una organización y un laboratorio de biométrica, donde prueba la utilidad de los más de 600 productos existentes en el mercado. El Departamento de Energía desarrolla un escáner holográfico que analizará, a través de ondas de radio y en tres dimensiones a los pasajeros para comprobar si esconden armas. La industria está concentrada en los sistemas de identificación dactilar. En general, son los más económicos; los más baratos sobre los 120 € . Los expertos consideran que para no atentar contra la intimidad una de las mejores

































Estado del Arte

3.1 Huella digital por ultrasonidos Este esquema funciona por ultrasonidos, lo que evita los fallos que hasta ahora se producían con la lectura óptica por suciedad en la piel o en el dispositivo de escaneo. La empresa valenciana especializada en tecnologías de seguridad Mundiscan Electronic Systems ha

presentado recientemente el primer sistema infalible de

identificación por huella dactilar basado en ultrasonidos. Se trata de una tecnología desarrollada en la última década, que ha demostrado una alta fiabilidad al extraer los rasgos más característicos e inequívocos de las personas

































Estado del Arte

3.2 Los dedos de gelatina de Matsumoto Recientemente ha salido publicada una noticia que está provocando un debate sobre la valoración de la biometría: un criptógrafo japonés llamado Matsumoto ha descubierto un método para engañar con un "dedo de gelatina" a 11 sensores biométricos en el 80% de los intentos. El estudio se basa en conseguir una huella artificial que engañe a los sistemas de autenticación. El profesor Matsumoto muestra como conseguir artificialmente una huella que puede servir como la original.



































Estado del Arte

Dependiendo del nivel de seguridad deseado se puede optar por una solución de seguridad más efectiva, por ejemplo, el uso de biosensores, cámaras de vigilancia, combinaciones de varias biometrías, combinaciones con smart cards y PinPad , etc. Al igual que con cualquier sistema de seguridad, existen vulnerabilidades y



































Estado del Arte

3.3 Algoritmos de huellas Autenticación significa comprobar si un individuo es quien dice ser. El algoritmo de autenticación que se utiliza en el presente proyecto, está formado por dos bloques: en



































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 comparación, dentro de unos límites de tolerancia, del patrón biométrico, o conjunto de minucias extraídas, adquirido “en vivo” y el almacenado.



































Estado del Arte

computacional del proceso de reconocimiento, es suficiente aplicar una máscara de 3x3 píxeles para el calculo de la inclinación en cada píxel.



































Estado del Arte

previamente). Después de esto el área de la imagen con ruido, que será excluido en las siguientes etapas, se define por bajas variaciones en todas las direcciones. En la figura 6 se muestran las variaciones de una huella y la región de interés obtenida a partir de esta.





































Estado del Arte





































Estado del Arte





































Estado del Arte





































Estado del Arte





































Estado del Arte





















































































































































































































































































































































































































































































































































































































































































































































































































Lenguajes y Herramientas

ü

Rendimiento La tecnología CGI normalmente inicia un nuevo proceso para gestionar cada petición 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 básico 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 petición previa del mismo cliente, la interfaz API Servlet proporciona una clase HttpSession que permite superar esta limitación.

ü

Acceso a la tecnología Java Al ser aplicaciones Java, los servlets tienen acceso directo a toda la gama de características Java, como el uso de subprocesos, acceso a redes y conectividad a base de datos.
































ü

Comunicación Como cada invocación de un programa CGI desencadena un proceso independiente, la comunicación entre ellos se debe hacer con frecuencia a través de ficheros, lo que puede ralentizar bastante la operación. Si estos programas pertenecen a un mismo servidor, su intercomunicación suele ser igualmente problemática.

ü

Seguridad Algunas variantes de CGI tienen graves problemas de seguridad. Aunque se utilicen los últimos estándares o lenguajes relativamente seguros, el sistema no ofrece garantías suficientes de protección.

Una Una Página Java en servidor, o “ Java Server Pages” (JSP) es una plantilla para una página Web que emplea código Java para generar un documento HTML dinámicamente. Las páginas JSP se ejecutan en un componente del servidor conocido como contenedor de JSP, que las traduce a servlets Java equivalentes. Por esta razón los servlets y las páginas JSP están íntimamente relacionados. Lo que se puede hacer con una tecnología es, en gran medida, también posible con la otra; aunque cada una tiene sus capacidades propias. Como son servlets, las páginas JSP tienen todas las ventajas de los servlets, pero además tienen ventajas propias: ü

Se vuelven a compilar automáticamente cuando es necesario.

ü

Como están en el espacio común de documentos del servidor Web, dirigirse a ellas es más fácil que dirigirse a los servlets.

ü

Como las páginas JSP son similares al HTML, tienen mayor compatibilidad
































JavaScript

es un lenguaje de programación creado por Netscape con el objetivo de

integrarse en HTML y facilitar la creación de páginas interactivas sin necesidad de utilizar scripts de CGI o Java. El código 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 código. 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.
































4.2.3 Herramientas Apache

ha sido desarrollado por diversos de usuarios que han tenido que reparar sus

fallos alguna vez y que han agregado funciones al software del servidor web, disponible en los primeros días de la World Wilde Web. Es uno de los mejores servidores de Web utilizado en la red Internet desde hace mucho tiempo, únicamente le hace competencia un servidor de Microsoft, el IIS. Por lo que éste servidor es uno de los mayores triunfos del software libre. La configuración y administración de Apache está basada en un sistema de ficheros, editable desde un editor de textos. Las características principales de Apache son las siguientes: ü

Permite instalar los servicios de aplicación CGI, Perl y Java. Opcionalmente, y como medida común 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 módulos de apoyo y con la API de programación de módulos.

ü

Incentiva la realimentación de los usuarios, obteniendo nuevas ideas, informes de fallos y parches para solucionar los mismos.
































Funciona sobre s obre un gran gran número de plataformas (Unix, Linux, Vms,

ü

Win32,OS2).

ü

Módulos cargados dinámicamente.

ü

Utilización de SSL para transacciones seguras.

ü

Soporte para host virtuales.

ü

Alto desempeño.

Para conseguir que nuestro servidor web sea un servidor seguro, es conveniente utilizar la tecnología SSL (Secure Socket Layer ) que detallamos a continuación: SSL

es una tecnología desarrollada por Netscape en 1994 junto con su primer

navegador, para asegurar la privacidad y fiabilidad de las comunicaciones entre dos aplicaciones. Utiliza un sistema de cifrado asimétrico basado en claves pública/privada pública/privada para negociar una clave de sesión que se utilizará para para establecer una comunicación basada en cifrado simétrico. SSL es el protocolo de cifrado más utilizado en Internet en estos momentos y es el más usado en servidores web donde se solicita información confidencial, además es abierto y de dominio público, y su implementación es sencilla. La seguridad de SSL actualmente proporciona servicios de cifrado de datos, servidor de autenticación, integridad de mensaje y autenticación de cliente para una conexión TCP/IP.


































ü

Cifrado de datos La información transferida se cifra utilizando un algoritmo de clave secreta, capaz de cifrar grandes volúmenes de información en muy poco tiempo, por lo que resultará ininteligible en manos de un atacante, garantizando así la confidencialidad.

ü

Autenticación de servidores El usuario puede asegurarse de la identidad del servidor al que se conecta y al que posiblemente envíe información personal confidencial. De esta forma se evita que un usuario se conecte a un servidor “impostor” que haya copiado las páginas del servidor al que suplanta. Estos ataques se conocen como Web spoofing ,

y se utilizan para hacerse con las contraseñas y números de tarjeta

de crédito de los usuarios. ü

Integridad de mensajes Se

impide

que

pasen

inadvertidas

modificaciones

accidentales en la información mientras “viaja” por Internet. ü

Autenticación de cliente

intencionadas

o
































SSL puede tener una clave de sesión de 40 bits o de 128 bits, dicha clave es generada en cada transacción. La longitud de la clave hará más difícil romper el cifrado. La mayoría de los navegadores soportan una clave de 40 bits para sesiones SSL, mientras que las últimas versiones soportan claves clave s de sesión sesió n de 128 bits. Las funciones son: ü

Verificación de la Identidad Emitir al servidor del cliente un Certificado Digital único, asegurándole asegurándole 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 comunicaciónes.

ü

Mantener la seguridad Un servidor SSL debe mantener la seguridad e integridad de la información a través del método de clave pública/privada.

ü

Facilidad de Utilización A pesar de la gran seguridad que debe tener, tener, el servicio debe ser de fácil uso para los clientes sin grandes traumatismos que ocasionen confusiones.
































Tomcat ,

uno de los proyectos de código abierto liderado por la Apache Software

Foundation,

es una aplicación web basada en Java creada para ejecutar servlets y

páginas JSP, siendo la implementación oficial de referencia de las especificaciones Servlet 2.3 y JSP 1.2.

Hemos decidido la utilización de Tomcat por los siguientes motivos: ü

Es “gratuito” y de “código libre”.

ü

Utilizaremos JSP para la generación dinámica de páginas.

ü

Nos permitirá la utilización de JavaBeans que nos facilitará implementar la lógica de la aplicación en base a componentes, con lo que conseguimos programar nuestra aplicación orientada a objetos.

ü

Proporciona una total integración con el sistema operativo Windows NT/2000/XP.

Además para realizar la tarea de transferir un fichero al servidor, desde nuestras páginas JSP, hemos utilizado un módulo desarrollado en Java, totalmente gratuito y disponible en la red, es el JspSmartUpload . JspSmartUpload es

un paquete de clases Java, que nos permitirán transferir ficheros
































Vamos a explicar alguna de las características de este paquete: ü

Simple y Completo Solo se necesitan unas pocas líneas de código en nuestra aplicación JSP para realizar la tarea de transferir ficheros. Provee todas las características que se necesitan para transferir uno o más 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 métodos del módulo jspSmartUpload , permiten el acceso a toda la información sobre los ficheros transferidos (tamaño, nombre, tipo, extensión, etc.), incluso sin salvar los ficheros a disco.

ü

Gestión 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
































Para albergar nuestra base de datos tenemos tenemos una una gran cantidad de de sistemas gestores de bases de datos. Barajando las distintas características de cada uno finalmente hemos optado por el uso de MySQL. Una característica importante es que consume muy pocos recursos, tanto de CPU como de memoria. Se sacrificaron algunas características característ icas esenciales en sistemas más “serios” con este fin Ventajas ü

Buenos rendimientos. Mayor velocidad tanto al conectar con el servidor como al servir consultas.

ü

Utilidades de administración (backup , recuperación 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 estándar con el servidor de base ba se de datos. Provee Pr ovee una API que podemos usar usar sin importar qué base de datos se esté usando. La conectividad de la base de datos de Java es un marco de programación para los


































Interfaz JDBC

Driver ODBC

Driver Sybase

Driver Oracle

Base Access

Base Sybase

Base Oracle

Figura 19. Interfaz JDBC

Sin importar la localización, 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 colección de extensiones ( class) que contienen las clases abstractas de la interacción de la base de datos. La ingeniería del software en los
































forma

construir

programas

que

interactuan

con

Mysql.

Analizando todas estas opciones hemos decidido utilizar las siguientes tecnologías 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 páginas web estáticas.

ü

ü

Generación dinámica de páginas con JSP sobre el servidor Tomcat. Javabeans

para implementar nuestra aplicación totalmente orientada a

objetos, utilizando clases Java. ü

El paquete Jspsmartupload para transferir los ficheros al servidor de nuestra































Diseño e Implementación

4.3 Diseño y desarrollo 4.3.1 Despliegue La figura 19 muestra el diagrama de despliegue de la aplicación.

Computadora del Usuario

Servidor de la aplicación

Terminal del Administrador

Lector de huellas

Servidor Web
































La aplicación reside en el servidor servidor de la aplicación, aplicación, con acceso directo a la base de de datos. Tanto las tareas de los usuarios como las del administrador se podrán realizar desde un simple navegador desde sus computadoras personales, conectándose vía web al servidor de la aplicación.

4.3.2 Gestión La figura 20 muestra muestra el esquema esquema de los distintos distintos paquetes software desarrollados, des arrollados, así como sus dependencias.

Clases Java

Clases jspSmartUplo ad

Clases
































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.lang., java.util., java.io., java.awt., etc.

4.3.2.2 Clases Auxiliares Este paquete contiene las clases desarrolladas para facilitar la aplicación. aplicación. La figura 21 muestra estas clases.

tElemento

tPersona

(from Logical View)

(from Logical View)

ID

Superclase

id_persona

Listar

Mostrar


































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


































4.3.2.4 Clases Interfaz Este paquete contiene las clases propias de la interfaz de la aplicación, son clases que se utilizan para mostrar y capturar información referente a las clases del dominio. En el caso de nuestra aplicación se trata de páginas, tanto html como jsp. La figura 23 muestra el diagrama de clases de la interfaz.

Index


































PAGINAS ADMINISTRADOR

Autenti_admin: En esta página se pide al administrador que se identifique ante el sistema, se utilizará autenticación biométrica para controlar el acceso a las páginas desde las que realizar las tareas de administración. Opción Alta Administrador

ad_alta: Esta clase representa la página en la que se muestran los usuarios que estén en la base de datos, en espera de ser dados de alta, para que el administrador decida a quien desea dar de alta.


































Opción enviar huellas Usuario existente solicitó pasar pasar a formar Usu_huellas: En caso está pensado para aquel usuario que ya solicitó 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. Opción Autenticar Usuario

Autenticación: En la página de autenticación se pedirá la identificación al usuario, la mano y el dedo sobre el que se va a realizar la validación. Una vez introducidos se


































4.3.2.5 Clases jspSmartUpload La figura 24 muestra el diagrama de clases del módulo JspSmartUpload:

SmartUpload SmartUpload() getFiles() getRequest() getBinaryData() getSize() setAllowedFilesList() setContentDisposition() setDeniedFilesList()

Request getParameter()




































4.3.2.5. Clases mysql-connector Estas clases conectan con el gestor de base de datos desde las páginas jsp y beans. A esta clase pertenece por ejemplo la clase Driver.class

que permite crear una

instancia del driver que nos conectará con la mysql. Otras clases también importantes




































Diagramas de Secuencia y Colaboración A

continuación

mostraremos

los

diagramas

de

secuencia

correspondientes a cada uno de los casos de uso de nuestro sistema:

y

colaboración




































Diagrama de Colaboración: Autenticar Administrador

1: Entrar 4: Identificacion

2:

5: Aceptar

6:




































Diagrama de Secuencia: Visualización




































Diagrama de Colaboración: Visualización

1: Tarea














































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































Manual de Administrador Administrador

Con el parámetro ‘directorio’, indicamos el camino completo desde el directorio de instalación de Tomcat, hasta el directorio donde se almacenarán las huellas y plantillas (upload ). ). Introduciremos el parámetro ‘directorio’ en web.xml, y lo inicializaremos al directorio de nuestra instalación, finalizando en el directorio upload, en donde se almacenarán las huellas y plantillas, de la siguiente forma: directorio directorio D:/t/webapps/proyecto/upload/

Enlazar Apache con Tomcat Para enlazar el servidor web Apache con el contenedor de servlets Tomcat necesitamos instalar el módulo mod_jk en el directorio correspondiente de Apache. Descargamos el fichero mod_jk.dll en la dirección 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 ,

automáticamente

el

fichero

c:\
lo copiamos con otro nombre p.e. c:\
tomcat>\conf\mio-tomcat-apache.conf .

Esto es necesario porque vamos a modificarlo, pero Tomcat lo sobrescribe cada vez que arranca con lo que perderíamos las modificaciones si no lo renombramos.
































Del nuevo fichero hay que quitar todas las referencias a JServMount y cambiarlas por JkMount (no

se pueden mezclar JServ y mod_jk ).). Además al principio del fichero

hay que poner las siguientes líneas: LoadModule jk_module libexec/mod_jk.dll AddModule mod_jk.c J kWorkersFile kWorkersFile c:\\conf\workers c:\\conf\workers.properties .properties JkLogFile c:\\logs\mod_jk.log JkLogLevel warn JkMount /*.jsp ajp13 JkMount /servlet/* ajp13 JkMount /otherworker/*.jsp remoteworker

Por último añadimos al final del fichero de Apache conf\httpd.conf la línea: include include c:\\conf\mio-tomcat-apache.conf c:\\conf\mio-tomcat-apache.conf

con esto indicamos a Apache las nuevas directivas para los servlets. Ya tenemos instalado el módulo. Arrancamos en primer lugar Tomcat y a continuación Apache; en este último al arrancar debe de salir un mensaje que indique que estamos utilizando mod_jk.dll (algo similar a mod_jk.dll running ). Hay que tener en cuenta que Tomcat siempre se debe arrancar antes que Apache, y si se para, hay que parar Apache y volver a arrancat Tomcat primero. A continuación se describe lo que contiene cada directorio de nuestra aplicación: Directorio Raíz Contiene las páginas .html de nuestra aplicación, entre las que se encuentra la página de inicio.
































Directorio JSP Como su propio nombre indica contiene las páginas .jsp, que junto con las páginas .html forman la interfaz de nuestra aplicación.

Directorio Recursos Aquí se mantienen los archivos (imágenes, botones, iconos, etc) que se van a usar en las páginas de la aplicación. Directorio Upload Aquí es donde se transfieren las imágenes de las huellas de los usuarios. Además mantiene las plantillas generadas genera das por la aplicación aplicación a partir de las imágenes de huellas digitalizadas. Directorio Admin Este es un subdirectorio de Upload y en el mantendremos las plantillas de los administradores que tengan privilegios para gestionar la aplicación. Directorio WEB-INF Aquí está el archivo descriptor de despliegue web.xml, que se utiliza para configurar los los servlets y otros recursos que forman parte de la aplicación web. Además incluye dos subdirectorio, el lib y classes: Directorio lib Contiene los archivos .jar . Las clases de cualquier archivo .jar que se encuentre en este directorio se ponen automáticamente a disposición del cargador de clases sin tener que estar explícitamente listadas en la ruta de clases. Aquí es donde situaremos las librerías de clases para el acceso al lector de huellas (FPJni.jar ) y las clases que nos permitirán acceder a MySQL desde las páginas
































Directorio classes Este directorio contiene servlets y otras clases. Aquí se pueden ubicar los paquetes que utilizados en la aplicación, en nuestro caso el paquete jspSmartUpload (com) y las clases desarrolladas para modelar la aplicación: usuario, huella y administrador. JspSmartUpload

Todos

los

ficheros jspsmartUpload vienen

jspSmartUpload.zip.

en

un

fichero

comprimido

Se descarga el archivo comprimido y se descomprime en un ,

directorio temporal asegurándonos de que la estructura de directorios está intacta. Si por ejemplo, se extrae el fichero en ‘/temp’, se debería tener lo siguiente:

Para poder utilizar este paquete en las páginas JSP de nuestra aplicación, se tendrá que ubicar en el directorio de la aplicación. Concretamente la estructura de directorio de Tomcat nos indica que hay que situarlo en el directorio WEB-INF\classes.

Lector de huellas

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 instalación,
































La instalación 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 código 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 aplicación esta en el archivo jar ‘FPJni.jar’, que

no

son

más

que

un

conjunto

de

clases

“empaquetadas”.

































Comandos de creación de tablas

Anexo II: Comando de creación de tablas Para la creación de las tablas de la base de datos, se incluye a continuación una serie de comandos SQL, utilizando los comandos SQL92 (ANSI SQL) soportados por MySQL, se decidiera migrar la aplicación a otra base de datos estos comandos nos facilitarían las cosas. Por otra parte MySQL soporta SQL92, aunque le añada algunas extensiones. En el caso de utilizar un Sistema gestor de base de datos relacional, relaciona l, a los comandos de creación se les tendrá que unir los comandos de autorizaciones y vistas pertinentes, que serán propios del entorno de trabajo. Para garantizar la integridad referencial, se tiene en consideración 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































Comandos de creación 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,































Bibliografía

Bibliografía [1] Damon Hougland, Aarón Tavistock. “Guía esencial JSP”. Pearson Educación S.A, Madrid, 2002. [2] Phil Hanna. “JSP. Manual de referencia”. McGraw-Hill, Madrid, 2002. [3] John Zukowski.”Programación en Java 2”. Ediciones Anaya Multimedia, Madrid, 1999. [4] Rich Bowen & Ken Coar, Servidor Apache al Descubierto. Pearson Educación, S.A. Madrid, 2000. [5] Lemay, Laura, “Aprendiendo HTML 4 para web en una semana”. Prentice Hall, México, 1998. [6] Juan Carlos Orós, “Diseño de páginas Web interactivas con JavaScript”. RA-MA Editorial, Madrid, 1998. [7] Graham Hamilton, Rick Cattell, Maydene Fisher, “JDBC Database Access with Java - A tutorial and annotated reference”. Addison-Wesley, Massachussets, 1997.































Bibliografía

[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.































Direcciones web

Direcciones web http://desaweb.forosdelweb.com - Foros del Web http://www.programacion.com - Java en castellano. Foros de debate http://www.javahispano.org - Java en Castellano http://www.programadores.com.sv - Comunidad salvadoreña de programadores http://www.mysql.com - MySQL http://java.sun.com - Pagina oficial sobre Java y tecnologías http://www.jspsmart.com - JspSmartUpload para subir ficheros

http://jakarta.apache.org - Tomcat

http://www.ii.uam.es/~abie/ -- Asociación de Biometría Informática Española http://www.ii.uam.es/~abie/ http://www.ictnet.es/ICTnet/cv/comunidad.jsp?area=engInf&cv=biometrica - Comunidad de Biometría

































Índice de Figuras

Índice de figuras Figura 1. Diagrama Sistema Reconocimiento Biométrico .............................. 13 Figura Figura 2. Relación entre FAR, FRR y ERR .................. ......... .................. .................. ................... .................. ........ 14 Figura 3. Huella dactilar con minucias

............................................................ 16

Figura 4. Huella original original y huella normalizada normalizada ................ ........................................ ................................ ........ 24 Figura 5. Huella orientada y campos realineados ............................................ 25 Figura 6. Variaciones de la huella y región importante .................................. . . 26 Figura Figura 7. Imagen Imagen filtrada filtrada e imagen imagen binaria ................................. ................. ................................ ................... ... 27 Figura 8 . Imagen después del primer filtro perfilador e imagen después del segundo filtro perfilador con máscara espacial ......... 28 Figura 9. Imagen después del adelgazamiento adelgazamiento y eliminación de imperfecciones y patrón de minucias después del proceso de eliminación de conjuntos .................................................... ........................ ........................................... ............... 29 Figura 10. Patrón de minucias ....................................... ............................................... ................. ................. ................. ........... .. 30 Figura 11. 11. Alineación Alineación de la cresta cresta de entrada y la cresta plantilla ................. 32 Figura 12. Actores del sistema

.. 40































Índice de Figuras

Figura Figura 25. Clase s JspSmartUpload ...................................... .......................................................... ............................. ......... 81 Figura 26. Secuencia de Autenticar Administrador ....................................... ....................................... 83 Figura 27. Diagrama de colaboración, caso Autenticar Administrador ...... .... .. 84 Figura 28. Secuencia de Visualización ............................. ............................. ... 85 Figura 29. Diagrama de colaboración, caso Visualización ............................. ............................. 86 Figura Figura 30. Secuencia Secuencia de Alta Administra Administrador dor ................. ......... ................. ................. ................. ................. ........ 87 Figura 31. Colaboración, Colaboración, caso Alta Administrador ................................. ....................................... ...... 88 Figura 32. Secuencia de Baja ............................. ............... ............................. ............................. ............................ .................. .... 89 Figura 33. Diagrama de colaboración, caso Baja ............................................ 90 Figura 34. Secuencia de Modificación .................................... ................. ...................................... .......................... ....... 91 Figura 35. Diagrama de colaboración, colaboración, caso Modificación ............................. ................. ............ 92 Figura 36. Secuencia de Alta usuario nuevo ................................... ................ 93 Figura 37. Diagrama de colaboración, colaboración, caso Alta usuario usuario nuevo .................... .................... 94 Figura 38. Secuencia Secuencia de Alta usuario existente ........................ ............ ......................... ...................... ......... 95 Figura 39. Diagrama de colaboración, colaboración, caso Alta usuario usuario existente existente .............. 96 Figura 40. Secuencia de Autenticar ................................... ............................. ..................... .......... .. 97 Figura 41. Diagrama de colaboración, caso Autenticar ................................. ................................. 98































Índice de Tablas

Índice de Tablas Tabla 1. Candidatos a Entidad y Relación ....................................................... 47 Tabla 2. Porcenta Porcentaje je de de autenticación autenticación y porcentaje de rechazo rechazo ...................... 110































Proyecto Biometria

Recommend Documents