sistema de autenticaciÓn Único basado en biomÉtricos
TRANSCRIPT
SISTEMA DE AUTENTICACIÓN ÚNICO BASADO EN BIOMÉTRICOS
DIEGO LUIS MALDONADO REY
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA
DEPARTAMENTO INGENIERIA DE SISTEMAS Y COMPUTACION
BOGOTA 2003
SISTEMA DE AUTENTICACIÓN ÚNICO BASADO EN BIOMÉTRICOS
DIEGO LUIS MALDONADO REY
Proyecto De Grado
Directora BEATRIZ ACOSTA
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA DEPARTAMENTO INGENIERIA DE SISTEMAS
Y COMPUTACION BOGOTA
2003
AGRADECIMIENTOS Agradezco a las personas que me han apoyado, ayudado y motivado en el desarrollo del presente trabajo. Ante todo a mis padres, su apoyo, cariño, ejemplo entre muchas cosas que como siempre, me ayudaron a realizar el presente trabajo. A mi asesora Beatriz Acosta por su paciencia, aportes, y ánimo constantes durante el desarrollo del proyecto. Agradezco adicionalmente a mis amigos, que con sus ideas y apoyo me ayudaron más de lo que se imaginan. Dentro de mis amigos, quiero agradecer de manera especial a uno que me demostró su apoyo, y me brindó herramientas útiles y necesarias en el desarrollo del proyecto: Juan Diego Losada.
A mis padres, todo lo que soy, todo lo que seré, todo lo que tengo y todo lo que tendré, se los debo a ellos. Si esta vida fuese eterna, no me alcanzaría el tiempo para reunir recursos para saldar mi deuda. Por siempre agradecido.
TABLA DE CONTENIDO
1. INTRODUCCIÓN .........................................................................................................5
1.1. Objetivo general ................................................................................................................................................. 7
1.2. Objetivos específicos.......................................................................................................................................... 8
1.3. Plan del documento ........................................................................................................................................... 8
2. BIOMÉTRICOS ..........................................................................................................10
2.1. Definición de biométricos...............................................................................................................................10 2.1.1. Modos de identificación a través de biométricos y errores ..............................................................10 2.1.2. Uso de biométricos .......................................................................................................................................11 2.1.3. Uso de biométricos en el proyecto ...........................................................................................................12
2.2. Descripción de la tecnología de huella digital...........................................................................................13 2.2.1. Categorías de huellas digitales .................................................................................................................14 2.2.2. Tecnología AFIS ..........................................................................................................................................15 2.2.3. Tecnología Finger Scan ..............................................................................................................................17
2.3. Iris ........................................................................................................................................................................20 2.3.1. Cómo funciona..............................................................................................................................................20
2.4. Comparación entre las dos tecnologías a utilizar en el proyecto ........................................................24
3. HERRAMIENTAS DE PROGRAMACIÓN ADICIONALES................................26
3.1. BIOAPI...............................................................................................................................................................26
3.2. JNI (Java Native Interface)...........................................................................................................................29
4. ALMACENAMIENTO DE LA INFORMACIÓN EN LDAP ..................................32
4.1. Introducción a LDAP (Lightweight Directory Access Protocol) .......................................................32
4.2. Diferencias entre directorio y base de datos relacional ........................................................................33
4.3. Estructura de directorio en LDAP .............................................................................................................33
4.4. Protocolo LDAP ..............................................................................................................................................34
4.5. Directorio LDAP ............................................................................................................................................35
4.6. Servidores Stand Alone .................................................................................................................................35
4.7. Modelos LDAP.................................................................................................................................................36
4.8. LDAP en el proyecto ......................................................................................................................................36
5. SISTEMAS ACTUALES DE AUTENTICACIÓN POR DIFERENTES MÉTODOS BIOMÉTRICOS.............................................................................................39
5.1. Sistemas de autenticación multimodal ......................................................................................................39
5.2. Sistemas integrados de seguridad................................................................................................................39
5.3. Sistemas de contr ol de acceso con acoplamiento a los sistemas de información actuales ............41
6. DISEÑO DE SISTEMA Y ANÁLISIS DE REQUERIMIENTOS..........................43
6.1. Metas ..................................................................................................................................................................43
6.2. Alcance...............................................................................................................................................................43
6.2. Usuarios del sistema.......................................................................................................................................44
6.3. Análisis de requerimientos ...........................................................................................................................44 6.3.1. Casos de uso de la aplicación ....................................................................................................................44
6.4. DISEÑO Y ARQUITECTURA...................................................................................................................56 6.4.1. Diagrama de componentes ........................................................................................................................56 6.4.2. Diagrama de clases ......................................................................................................................................59 6.4.3. Diagramas de secuencia .............................................................................................................................63 6.4.4. Estructura de información adicional utilizada ....................................................................................70
6.4.4.1. Estructura de información biométrica.......................................................................................70 6.4.4.2. Estructura de información de logs ..............................................................................................71 6.4.4.3. Definición de esquemas y atributos adicionales .......................................................................72
6.5. Interfaz y visualización de la aplicación...................................................................................................73
6.6. Atributos del sistema......................................................................................................................................74
7. IMPLEMENTACIÓN..................................................................................................82
7.1. Detalles de implementación..........................................................................................................................82
7.2. Herramientas utilizadas ................................................................................................................................83
7.3. Posibles mejoras futuras ...............................................................................................................................84
8. PROBLEMAS ENCONTRADOS ............................................................................85
8.1. Obstáculos iniciales en la implementación ...............................................................................................85
8.2. Problemas en la implementación ................................................................................................................86
8. CONCLUSIONES......................................................................................................87
10. REFERENCIAS......................................................................................................89
ISC-2003-1-24
5
1. INTRODUCCIÓN Desde que las organizaciones se comenzaron a establecer formalmente como entidades, ha existido el interés de proteger sus activos, que son finalmente la esencia de la organización, son lo que la compone. Los activos están conformados por el personal de la empresa, sus bienes físicos, reputación, maquinaria, productos, investigación, entre otros, y el más importante de ellos: la información. Este interés de proteger sus activos de personas indeseadas, de evitar el acceso indebido a los recursos por personas no autorizadas o de limitar las acciones que las personas autorizadas podían ejercer sobre determinados activos, llevó a la creación de diferentes mecanismos de control sobre el acceso de las personas sobre los recursos de la organización. Los mecanismos de control de acceso han sido implementados para controlar el acceso a diferentes recursos: acceso físico a instalaciones que se consideran de alta confidencialidad o alto riesgo, control de acceso a las instalaciones de la empresa y control a los recursos de información de la empresa. En los últimos tiempos se han incrementado los esfuerzos de controlar el acceso de las personas a los diferentes recursos de la organización, principalmente a los controles que manejan y controlan el acceso a la información de la empresa, considerada hoy en día el activo más importante de la compañía. Gracias a diferentes hechos como el ocurrido en el 11 de septiembre de 2001, y al aumento en el número de ataques y violaciones a la seguridad de los diferentes sistemas, se ha visto la necesidad de incrementar los sistemas utilizados en el control de acceso. En la actualidad que estamos viviendo, se está presentando una nueva era en la seguridad. El 11 de septiembre de 2001 como en algunos medios de comunicación lo titularon: “el día en que cambió el mundo” [1] ha marcado un cambio de era en la seguridad, ocasionando un creciente interés, ya no sólo de las compañías gubernamentales y oficiales, sino de todas las empresas en la seguridad. Esto se ha podido observar en la bolsa de valores de NASDAQ en Estados Unidos, donde se ha aumentado el valor de las acciones de las empresas de tecnologías biométricas y se ha visto un incremento considerable en las utilidades del sector pasando de 523.9 millones de dólares en 2001, a 729.1 millones en 2002 y se espera que se generen 1049.6 millones en 2003 [2]. La guerra contra el terrorismo ha comenzado, y en ella los sistemas de seguridad juegan un rol muy importante.
ISC-2003-1-24
6
Actualmente el método para controlar el acceso a los recursos más utilizado, tanto para acceso desde una terminal a la información bancaria como para ingresar los datos de correo electrónico es la utilización de una contraseña y un identificador único de la persona o PIN. Ésta alternativa ha demostrado ser de un costo relativamente bajo en su construcción y desarrollo, como también en su incorporación en los diferentes ambientes laborales. Sin embargo, se han visto diferentes debilidades en su implementación; se han visto patrones de comportamiento entre los individuos que utilizan éste medio para autenticar que permiten que los controles pierdan su efectividad y el sistema se vuelva vulnerable. Dentro de las soluciones emergentes al problema de control de acceso ha surgido un mecanismo que ha venido creciendo y gozando de una popularidad cada vez mayor, por su familiaridad con los datos necesarios para realizar la autenticación. Éstos son los sistemas de verificación y autenticación a través de los biométricos, o medidas basadas en el cuerpo. La creciente popularidad de éste sistema de autenticación, se debe en parte a que la información que se está utilizando para autenticar al usuario es su mismo cuerpo. Se han demostrado diferentes ventajas en la utilización de biométricos para identificar de manera única a las personas, algunas de ellas son: conveniencia; la persona no debe cargar ningún objeto ni aprenderse ninguna información adicional, exactitud; las medidas corporales utilizadas son únicas a cada persona y ofrecen un alto grado de exactitud en la verificación de la identidad de una persona, seguro; representa un mayor reto y dificultad para personas que deseen falsificar la identificación de otra persona, precio; disminuye el costo administrativo de seguridad que se requiere con otros sistemas de autenticación y aceptación; las personas que lo han utilizado han visto la facilidad y conveniencia de utilizar un sistema basado en la biometría. El principal objetivo del proyecto es construir una solución al problema de autenticación mediante el uso de diferentes tecnologías biométricas, logrando integración de diferentes tecnologías actuales en una misma aplicación o sistema de autenticación. Se busca tener un repositorio de datos central y una aplicación que lo maneje y administre, en el cual la autenticación se realice independiente del dispositivo utilizado para la captura de las medidas biométricas, y exista un único registro con toda la información relevante a una persona, reuniendo toda la información de las diferentes medidas tomadas. Se busca que la aplicación que se desarrolle sea capaz de dar un veredicto frente a la validez de la identificación de la persona, independientemente de la medida proporcionada, si previamente se ha alistado en el sistema y esa medida está soportada. Para lograr un adecuado control de acceso, que responda a los requerimientos y situaciones actuales de seguridad de la información, se hace necesario implementar un sistema que utilice varios mecanismos de autenticación, dependiendo del nivel de seguridad requerido en los diferentes escenarios o para los diferentes tipos de recursos de la organización. Para un manejo más consistente de la información de cada usuario para su autenticación, se desea un sistema que centralice y maneje toda la información referente al control de acceso de los usuarios. Este puede ser por medio de una contraseña, por medio de la huella digital,
ISC-2003-1-24
7
por medio del patrón del iris, por medio de la forma de la mano o cualquier otro mecanismo de identificación que se considere adecuado. Es interés de éste trabajo entonces, modelar, analizar y construir un piloto de un sistema de control de usuarios que permita una integración de tecnologías tales de autenticación. Un sistema único que almacene y verifique los datos de las personas que deseen autenticarse, ya sea esta autenticación realizada a través de un login y una contraseña, o se realice con la ayuda de un dispositivo que mida un biométrico en particular. Este sistema almacenará toda la información referente a un usuario en particular, y permitirá hacer una validación con cualquiera de los datos almacenados en el registro de este usuario para verificar su identidad. El sistema que se desea desarrollar será único en el proceso de autenticación para los diferentes modos de ingreso de datos, permitiendo un manejo centralizado, consistente y de mayor facilidad en los controles de auditoría y en el mantenimiento del sistema. Actualmente existen varias soluciones similares ofrecidas por diferentes empresas de seguridad y por algunos proveedores de servicios. El mayor problema de las soluciones actuales es el elevado costo de las soluciones ofrecidas por estas compañías, ya que los productos son ofrecidos por empresas especialistas en seguridad, y la competencia de productos ofrecidos en este sector es reducida. Es por esto que se desea construir un proyecto que ofrezca una solución más económica, supliendo las necesidades en seguridad de las empresas. Para el desarrollo de este sistema se requiere tener conocimientos básicos de la tecnología biométrica que se utilizará, en este caso huella digital y patrón del iris del ojo. Se requiere adicionalmente tener conocimientos del repositorio que datos que se utilizará para almacenar la información, para el desarrollo de este proyecto se utilizarán directorios LDAP. Y para el desarrollo mismo de la aplicación se necesitan conceptos en herramientas de programación y arquitecturas, que para este proyecto va a ser basado en Java, aprovechando la interoperabilidad que éste ofrece. Adicionalmente, por desarrollar una aplicación que utilizará diferentes tecnologías biométricas se utilizará una interfaz de programación que se ha desarrollado para tal fin, el BioAPI.
1.1. Objetivo general El principal objetivo del presente trabajo es diseñar una solución para la autenticación de usuarios, que permita la validación del usuario a través de diferentes tecnologías biométricas.
ISC-2003-1-24
8
1.2. Objetivos específicos
Adquirir conocimiento de las tecnologías biométricas, principalmente las relacionadas con la huella digital y el iris. Adquirir conocimiento acerca de las posibles herramientas (en lo posible libres), que permitan el desarrollo de la aplicación que se desea desarrollar. Diseñar una solución general al problema, que sea independiente de los fabricantes de tecnologías biométricas, de los proveedores del servidor de base de datos e independiente del sistema operativo sobre el cual se ejecuta. Desarrollar un piloto de la aplicación que implemente el diseño presentado y permita en un futuro extenderse a una solución de autenticación completa en un ambiente real.
1.3. Plan del documento El plan del presente documento busca establecer una estructura adecuada para la comprensión del mismo, que permita entender y estructurar las ideas utilizadas en la solución del problema. El segundo capítulo explica brevemente algunos de los conceptos necesarios para la comprensión de este trabajo. Se comienza con una explicación del concepto de biométricos, de la evolución e importancia de ésta tecnología y su principal uso. Luego se ilustra el funcionamiento de las tecnologías biométricas que se utilizarán (huella digital e iris). El tercer capítulo expone dos interfaces de programación que se debieron estudiar para implementar la solución planteada: el BioApi, el cual expone una manera estándar se utiliza para la comunicación con los dispositivos y JNI (Java Native Interface) necesaria para la integración de código en diferentes lenguajes, en este caso Java y C. El cuarto capítulo abarca los conceptos de la solución que se utilizó para la persistencia de la información: LDAP, mostrando sus ventajas y aplicabilidad dentro del trabajo. En el quinto capítulo se exponen los diferentes problemas actuales, y las soluciones existentes en este campo. Se pretende contextualizar al lector con algunas de las soluciones que se han construido hasta el momento. Para esta etapa del documento, se pretende que el lector visualice el problema que se desea solucionar, y tenga las bases para entender la solución planteada.
ISC-2003-1-24
9
En el capítulo 6, ya se propone la solución del problema. En este capítulo se presentan los diferentes formatos y diagramas en UML que permiten expresar los casos de uso de la aplicación que se va a desarrollar y se expresa de manera gráfica el diseño de la aplicación (diagrama de clases y por componentes), la interacción entre los diferentes componentes de la aplicación (diagramas de secuencia), la estructura de la información biométrica utilizada y la interfaz con el usuario. En el capítulo 7 se documentan algunos detalles de la implementación hecha, se nombran las herramientas utilizadas y aspectos relacionados. El capítulo 8 busca, presenta y explica los problemas encontrados previamente y durante el desarrollo del proyecto. Esto busca que el lector considere los problemas presentados en la implementación, ya sea para proponer soluciones o para que utilice los analice. En el último capítulo se presenta una conclusión del trabajo realizado estableciendo la importancia que se desea que tenga el trabajo; luego de lo cual se procede a realizar proyecciones, estableciendo un panorama futuro. Finalmente se presentarán las referencias y bibliografía utilizadas.
ISC-2003-1-24
10
2. BIOMÉTRICOS
2.1. Definición de biométricos La biometría se conoce como la ciencia y tecnología que analiza y mide estadísticamente datos biológicos o comportamentales. En tecnología de información, la biometría se conoce como el estudio de diferentes medidas en el cuerpo humano que sirvan como medida o dato de entrada en la autenticación de un usuario ante un sistema [3]. Dentro de las diferentes medidas utilizadas actualmente para la autenticación está la huella digital, el iris del ojo, la retina del ojo, la forma de la cara, la forma de la mano, patrones de voz y patrones de comportamiento en la firma de documentos, entre los más utilizados. Entre los menos utilizados están algunas medidas biológicas, como lo puede llegar a ser el olor del cuerpo de una persona. Utilizar la biométrica para la autenticación personal está llegando a ser conveniente y considerablemente más exacto que los métodos actuales (contraseñas, PIN, smartcards, etc.). Esto es porque la biométrica liga el acontecimiento a un individuo particular (una contraseña o un token puede ser utilizado por alguien diferente al usuario autorizado), es conveniente (nada que llevar o recordar), exacto (provee autentificación positiva con un alto grado de certidumbre), puede proporcionar un rastro de auditoría (se pueden rastrear las diferentes acciones de las personas) y está llegando a ser socialmente aceptado (está siendo aceptado por un número creciente de personas) y barato (se están comenzando a ofrecer productos cada vez más económicos y portables) [4].
2.1.1. Modos de identificación a través de biométricos y errores El reconocimiento biométrico se puede utilizar en el modo de la identificación, donde el sistema biométrico identifica a una persona entre la totalidad de la población alistada, buscando en la base de datos por su igual. Un sistema también se puede utilizar en el modo de verificación, donde el sistema biométrico autentica la validez de la identidad demandada de una persona por su patrón previamente alistado [5].
ISC-2003-1-24
11
Sin embargo, los sistemas que se basan en biométricos están sujetos a errores, los cuales se pueden clasificar a grandes rasgos en dos categorías: errores debidos a falsa aceptación y errores debidos a falsos rechazos. Los errores debidos a la falsa aceptación ocurren cuando en un sistema se acepta identificación de un usuario no registrado en el sistema, esto se puede dar por diferentes motivos, como la falsificación de datos de manera malintencionada, el bajo grado de exactitud en las medidas realizadas o inclusive por errores en la toma de la medida donde los datos ingresados se asemejen a otros. Los errores de falsos rechazos ocurren cuando el sistema rechaza a un usuario válido, lo cual se puede dar por errores en la toma de datos, como por ejemplo si tiene las manos sucias y el sistema utilizado se basa en huella digital, o si el sistema utiliza el reconocimiento de voz, y la persona que se desea autenticar tiene gripa. Los falsos rechazos se pueden generar también por el cambio en la medida biológica natural en la persona, caso en el cual se le deberá actualizar la información en la base de datos [6]. La rata de falsos rechazos y de aceptaciones falsas son en muchos casos contrarias, ya que si un sistema desea disminuir al máximo la tasa de falsas aceptaciones, va a estar sujeta a unas tasa de falsos rechazos mayor, ya que tendrá que manejar un grado de exactitud mayor en la toma de datos y pueden ocurrir errores como los anteriormente mencionados y ocasionar falsos rechazos de usuarios válidos.
Imagen de la Universidad de Stanford [6]
2.1.2. Uso de biométricos Los biométricos se utilizan para identificar de manera única a una persona, tratando de establecer medidas que no se encuentren duplicadas entre diferentes personas. Esto sirve principalmente entonces, para identificar de manera única a una persona, y en tecnología de información se utiliza para autenticar y validar la identificación de una persona ante un sistema.
ISC-2003-1-24
12
De esta manera, el principal desarrollo de estas tecnologías, y de interés para el trabajo que se desea realizar es desarrollar dispositivos y programas que permitan el manejo acertado de la información de las diversas medidas biológicas para lograr diferenciar las personas. Esta tecnología principalmente se utiliza en los sistemas de autenticación y validación de usuarios reemplazando o complementando el hoy tan difundido sistema de autenticación a través de contraseñas. Los biométricos brindan una alternativa de solución al problema de autenticación interesante, sin embargo posee algunas desventajas. Según el Electronic Frontier Foundation [7] el 1% de las personas posee biomas, o medidas biométricas no aptas para la utilización de estos dispositivos, no permiten una lectura y toma de medidas correcta, que permitan su identificación. Existen personas cuyas huellas digitales son difíciles de tomar por la contextura de sus dedos, así como hay personas que han perdido algunos miembros de su cuerpo por diferentes causas. Este problema resulta ser importante si consideramos el 1% de errores en la toma de medidas simplemente, más el error que pueda presentar el sistema en la verificación de la información es un problema que puede representar el fracaso de un sistema basado en biométricos. Para mitigar en parte los problemas ocasionados por esto, se recomienda utilizar sistemas que no se basen en una única medida biométrica para la autenticación de las personas, sino que utilice diferentes medidas, y pueda reducir el riesgo asociado con esto.
2.1.3. Uso de biométricos en el proyecto Para el desarrollo de este proyecto se pretende poder utilizar cualquier dispositivo soportado por la interfaz de programación que se usará en el desarrollo de la aplicación (BioApi)1. Sin embargo, para propósito de implementación de la aplicación se sugiere utilizar dispositivos de escaneo de huella digital y dispositivos basados en el patrón del iris del ojo por razones que se explicarán mas adelante en el documento. Se escogió la huella digital como medida biométrica por ser la tecnología más difundida, de mayor crecimiento y actualmente la más económica de utilizar dentro de las relacionadas con la biometría. La huella digital es el medio biométrico de mayor aceptación actualmente, ya que desde hace varias décadas se viene usando como método de verificación de la identidad de las personas en documentos, medicina forense y sistema penitenciario. Es por esto que la tecnología relacionada con la huella digital tiene un mayor avance y madurez. Además se están comenzando a producir dispositivos de menor precio, que buscan servir como dispositivo de autenticación dentro de las oficinas, como parte de las estaciones de
1 En el capítulo 2.5 del presente documento se detalla el bioApi.
ISC-2003-1-24
13
trabajo. Esto la hace una de las tecnologías más atractivas para utilizar en el desarrollo de este proyecto. Para el desarrollo de este proyecto se utilizará la tecnología de Finger Scan, ya que el objetivo es ofrecer autenticación a través de un sistema de validación2 y no de identificación3, lo cual hace poco viable la opción de utilizar un sistema AFIS (Automated Fingerprint Identification System, sistema principalmente basado en identificación el cual se describe más adelante en el documento). Además los costos relacionados a la implementación de un sistema que utiliza Finger Scan son mucho menores que los que se deben asumir si se desea implementar un sistema que utilice AFIS. Una razón adicional para la elección del sistema basado en Finger Scan es su facilidad para incorporarse en las estaciones y equipos de trabajo de las oficinas, permitiendo un menor impacto en la vida laboral de las personas al introducir el sistema de autenticación en las empresas. La otra tecnología biométrica escogida es el iris. Esta tecnología promete convertirse en una de las biometrías más exitosas en los próximos años. Su alto grado de exactitud en la toma de los patrones, su unicidad en cada ojo, y su facilidad y comodidad de captura son algunos de los motivos que hacen que esta tecnología tenga proyecciones prometedoras como mecanismo de autenticación. Además sus características le permiten ser más versátil y robusta que otros métodos biométricos al poder ser utilizada tanto para validación como para identificación de las personas.
2.2. Descripción de la tecnología de huella digital La huella digital es usada como mecanismo de autenticación e identificación por diferentes motivos inherentes a las características a las huellas digitales [8]:
1. Los patrones de arrugas y detalles en áreas pequeñas, presentes en la superficie de fricción de la piel son únicas, y nunca se repiten entre diferentes personas.
2. Las arrugas de fricción son desarrolladas en el feto, y toman su forma definitiva antes de nacer.
3. Las arrugas son permanentes a través de toda la vida, excepto por cicatrices permanentes.
4. Los patrones de arrugas en la piel varían dentro de algunos límites, lo que permite realizar una clasificación.
2 Los sistemas que realizan validación de usuarios hacen una comparación 1:1 del dato biométrico del usuario,
verificando la validez de la identificación que el usuario dice tener. En estos sistemas el usuario da su identificación con anticipación y el sistema verifica que la persona sea quien dice ser.
3 Los sistemas que realizan identificación de usuarios hacen una comparación de 1:N del dato biométrico del usuario buscando su identificación en la base de datos. Estos se basan en una tasa de error aceptada, para encontrar las medidas más cercanas a la tomada.
ISC-2003-1-24
14
Desde aproximadamente el año 1000 AC, los arqueólogos han encontrado evidencia de antiguas civilizaciones chinas y babilónicas que utilizaban la huella digital para firmar documentos legales [9]. La huella digital es el mecanismo de autenticación por biométricos más popular, más económico y el que mayor crecimiento proyecta para los próximos años. Su proyección de crecimiento se manifiesta por el creciente interés hacia los biométricos, siendo la huella digital la más popular entre las diferentes medidas. Con el incremento de la conciencia hacia la seguridad en los últimos tiempos, la investigación en tecnologías para la utilización eficiente de la huella digital ha aumentado considerablemente. Esto ha permitido el desarrollo de diferentes algoritmos para la comparación y manejo de la huella digital, así como desarrollo de nuevos materiales y dispositivos para la captura de las medidas. Esto permite la visión de un futuro desarrollo de productos de manera masiva, ayudando a disminuir los precios de la tecnología, abarcando cada vez a más sistemas y usuarios. El tamaño de los dispositivos actuales ha permitido que se integren con periféricos y se adapten más fácilmente al ambiente empresarial y de trabajo, evitando que se presente un impacto muy grande al introducir el nuevo sistema de autenticación. Además, hace que los computadores personales sirvan como herramienta dentro de la arquitectura de seguridad.
2.2.1. Categorías de huellas digitales Para el análisis de las huellas digitales, se ha logrado establecer categorías según el patrón y características de la huella. Las categorías han permitido facilitar y volver más eficientes las búsquedas en las bases de datos, limitando el rango de búsqueda una vez se logra clasificar. Categorías de las huellas La clasificación de las huellas se basa principalmente en la forma de la huella, y en la ubicación de los puntos de minucia4. Esta clasificación se hace con base en el sistema de Henry, que ya lleva varias décadas de vigencia. Las huellas se clasifican principalmente en 3 categorías de acuerdo a su forma, que luego son discriminadas según su sentido y ubicación dentro del dedo [10].
4 Los puntos minucia, son puntos en los cuales los arcos de la huella se bifurcan, parten, nacen o cambian su trayectoria.
ISC-2003-1-24
15
Arco
Ciclo
Remolino
Para la comparación de las huellas se utilizan principalmente dos algoritmos: uno basado en la ubicación de las minucias, y otro basado en el cambio relativo de los diferentes puntos cuando se traslada y rota la imagen con respecto a la almacenada en la base de datos. Actualmente, existen dos tecnologías principales para el manejo de la huella digital. Las dos tecnologías son importantes y difieren en su principal objetivo.
2.2.2. Tecnología AFIS
Imagen de tomada de www.deakin.edu.au
La primera herramienta o sistema, y el más antiguo, es el AFIS (Automated Fingerprint Identification System). Este sistema es utilizado principalmente como mecanismo de identificación, más que de autenticación. La identificación realiza consultas de uno a muchos dentro de una base de datos para establecer la identidad de un sujeto dentro del sistema. Estos sistemas se utilizan principalmente para la búsqueda de criminales por los principales departamentos policiales y forenses del mundo. Las huellas que se extraen de las escenas del crimen son utilizadas para realizar la búsqueda del criminal, previamente almacenada en la base de datos.
ISC-2003-1-24
16
En la base de datos se almacena la imagen completa de las huellas digitales (generalmente de las diez) de las personas para poder establecer la identidad de una persona con cualquiera de las huellas. Estas imágenes requieren de aproximadamente 250kb de espacio para cada imagen de la huella, y es almacenada como imagen completa de bits de aproximadamente 500dpi. El sistema debe ser complementado por un experto en huellas digitales, ya que el sistema tiene la capacidad de establecer candidatos que cumplen con las características dadas y es el experto el encargado de establecer si existe dicho sujeto, o si los candidatos arrojados no corresponden con la identificación de la persona que se busca. Además el experto en huellas digitales debe determinar la validez de las huellas ingresadas en el sistema, él debe establecer si las huellas ingresadas al sistema para ser almacenadas son lo suficientemente claras y concisas, así como si la huella ingresada para la búsqueda cumple con algunos parámetros que le permita al sistema realizar su labor de manera eficaz [11]. Características [8]
• Tiempo de respuesta: La búsqueda de los posibles candidatos puede tardar varias horas, ya que se realiza una búsqueda de uno a muchos en una base de datos, basándose en algoritmos de comparación.
• Costo: Debido al poder computacional y dispositivos requeridos, el costo del sistema completo puede llegar a ser de varios miles de dólares.
• Exactitud: El sistema detecta los principales candidatos, basado en una previa categorización y clasificación de las huellas por patrones previamente establecidos. Para la identificación completa, el sistema debe ser complementado por un experto en huellas digitales que determine la validez e identidad definitivas.
• Escalabilidad: Estos sistemas fueron construidos para ser escalables a varios miles, e incluso millones de usuarios en la base de datos, realizando consultas de 1:N.
• Captura: Estos sistemas utilizan la imagen completa de la huella digital, se toma la imagen de uña a uña.
• Almacenamiento: Se almacena la imagen completa, para que una vez se establezcan los candidatos, un experto tome la decisión y realice la comparación en mayor detalle. El tamaño de la imagen requerido es 250kb en mapa de bits de 500dpi.
• Infraestructura: Estos sistemas generalmente requieren de sistemas de almacenamiento, digitalización de imagen, procesamiento y seguridad de alto desempeño, que pueden llegar a ser bastante costosos.
Uso y aplicación:
• Identificación de sospechosos en escenas de crimen o para identificar crímenes recurrentes en comisarías y estaciones policiales.
• Identificación de verdadera identidad de los sujetos • Identificación de personas con características determinadas, como enfermedades
contagiosas o alguna otra característica que se desea detectar.
ISC-2003-1-24
17
• Identificación de la identidad de personas que no son capaces de identificarse por sí mismas (ej. pacientes con Alzheimer).
2.2.3. Tecnología Finger Scan
Esta tecnología ya es líder en el mercado de biométricos, y se proyecta como líder hasta el 2005. Gracias al la variedad de ambientes en los cuales la el mecanismo puede ser implementado y utilizado, y gracias a que compañías fuertes e importantes están destinando recursos significativos al desarrollo de ésta tecnología, se proyecta que los ingresos de ésta industria crezcan de US$57.2 millones en el 2000 a US$453 millones en el 2005 en Estados Unidos [8]. Este mecanismo se basa en la extracción de información relevante para la validación o verificación de usuarios de la huella digital, para la construcción de una plantilla que será utilizada posteriormente para comparar las huellas ingresadas. Una vez que una imagen de alta calidad se captura, hay varios pasos requeridos para convertir sus características distintivas en una plantilla compacta. Cada una de las principales empresas que producen dispositivos de este tipo, desarrollan mecanismos propietarios para la extracción de características utilizando diferentes algoritmos. Una vez que se captura una imagen de la calidad, debe ser convertida a un formato usable. Para esto se utiliza un mecanismo a través del cual se reduce el ancho de los arcos de manera significativa, dejando sólo aquella información relevante a las terminaciones y bifurcaciones de los arcos en la huella. A partir de ésta imagen se procede a la detección de las los puntos de minucia. A continuación se procede a la aplicación de diferentes algoritmos de mejoramiento y filtración de la imagen, para eliminar todos aquellos puntos incoherentes que pudieron haber surgido por errores en la toma de la huella, como mugre, defectos en la superficie,
ISC-2003-1-24
18
sudor, etc. En este proceso se elimina un gran porcentaje de puntos de minucia que no tienen sentido. Una vez se establecen los puntos relevantes para la plantilla, se ubican éstos en un sistema coordenado al que generalmente se le asigna el punto (0,0) en el centro de la huella. Además de la ubicación de los puntos dentro del eje coordenado, se utiliza el ángulo con respecto al origen, este ángulo se mide a partir de una línea paralela al eje x, siguiendo la curvatura de los arcos.
Imagen tomada www.stanford.edu [6]
Generalmente se toman entre 30 y 40 puntos de minucia relevantes en la huella, para construir la plantilla que se almacena en la base de datos.
El algoritmo utilizado por los diferentes fabricantes, es entonces utilizado para verificar las imágenes tomadas por el dispositivo y comparar la imagen con la plantilla almacenada en la base de datos. El sistema entonces, da un veredicto afirmativo o negativo acerca de la validez de la identificación ingresada [13]. Características [8]
• Tiempo de respuesta: El tiempo de respuesta es relativamente corto (1-3 segundos), esto se logra gracias que las búsquedas se hacen 1:1, para validación únicamente. El tiempo de respuesta se limita en algunos casos por la claridad de la huella ingresada.
• Costo: Gracias a la reciente masificación de la tecnología, y a los avances en la producción de dispositivos, ahora se consiguen dispositivos desde US$100 en adelante, hasta incluir dispositivos muy completos.
• Exactitud: El sistema, al ser un mecanismo de validación, está diseñado para dar respuestas afirmativas o negativas de la validez de la identificación proporcionada. Los errores para rechazo falso son menores al 1%, y los errores ocasionados por la falsa aceptación son menores al 0.01%.
• Escalabilidad: Estos sistemas son casi invariablemente 1:1, y gracias a la utilización de patrones para el reconocimiento hace que se dificulte una posible aplicación en un sistema de identificación que necesite consultas 1:N.
• Captura: Se utiliza únicamente la parte central de la huella, a la cual se le extrae la información relevante para la construcción de la plantilla.
ISC-2003-1-24
19
• Almacenamiento: Se almacena la plantilla con la información relevante a los puntos minucia y algunos otros datos relevantes, lo cual requiere de 250-1000 bytes únicamente.
• Infraestructura: E poder computacional para la aplicación que realiza la verificación es relativamente bajo, y depende más del tamaño de la base de datos almacenado, pero para una base de datos mediana se puede correr sobre un computador personal.
Uso y aplicación:
• Validación de ingreso a zonas de un cierto nivel de seguridad. • Validación de usuarios para el ingreso al sistema corporativo de una empresa. • Validación para el control de acceso a diferentes recursos dentro de una
organización. • Validación de la identificación de la persona en aeropuertos, aduanas, controles de
inmigración y otros lugares donde se requiera validar la identificación de las personas.
• Integración con periféricos del escritorio, que permiten reemplazar de manera natural las contraseñas, donde éstas son empleadas.
Tipos de dipositivos utilizados
- Ópticos: Es la tecnología más antigua y de mayor uso. La mayoría de las compañías actualmente trabajan con dispositivos ópticos. Estos dispositivos funcionan con una pantalla de CCD (Charged Coupled Device), la cual convierte las arrugas de la huella en una imagen digital. Esta es la más popular, y posee ciertas ventajas sobre resistencia al cambio de temperatura y calidad de la imagen.
- Tecnología de silicio: La mayoría de éstos dispositivos se basan en la capacitancia DC. El sensor de silicio actúa como un plato del condensador y el dedo, como el otro. La diferencia de capacitancia entre los dos es posteriormente convertida a una imagen. Esta tecnología produce imágenes de mejor calidad, con menor área de placa que los ópticos.
- Tecnología ultrasonido: A pesar de ser considerada la más exacta, es poco utilizada. Transmite ondas acústicas y mide la impedancia del dedo, la placa de contacto y el aire. Esta tecnología permite tomar imágenes aceptables a pesar de mugre, sudor y otros factores que pueden limitar la toma de imágenes en los sensores ópticos.
ISC-2003-1-24
20
2.3. Iris La idea de usar patrones de las características del iris para la identificación fue propuesta originalmente en 1936 por el oftalmólogo Frank Burch. Por los años 80, la idea había aparecido en las películas de James, pero todavía seguía siendo ciencia ficción. En 1987 dos otros oftalmólogos, Aran Safir y Leonard Flom, patentaron la idea, y en 1989 pidieron a John Daugman (que en ese entonces enseñaba en la universidad de Harvard) que intentara crear los algoritmos reales para el reconocimiento del iris. Estos algoritmos, que Daugman patentó en 1994 son propiedad de Iridian Technologies, son la base para todos los sistemas actuales del reconocimiento del iris [16]. La tecnología que utiliza el patrón de la forma del iris como medida para establecer identificación y verificación de usuarios es de las tecnologías más certeras en cuanto a la cantidad de errores a los que se induce cuando se utiliza. El iris representa una medida única entre las personas, el patrón del iris del ojo inclusive es diferente en cada ojo de la misma persona. La utilización de ésta tecnología permite establecer identificaciones de manera única de una forma asombrosa, se podría potencialmente almacenar a toda la población del planeta, y aún así la tasa de falsas aceptaciones y falsos rechazos es mínima, al compararse con las demás medidas biométricas. La medida representa tal exactitud y unicidad, que es posible utilizar esta tecnología para realizar la identificación de personas, además de la verificación. El reconocimiento del iris está basado en las cualidades visibles del iris. Una característica visible principal, es el estroma conjuntivo (formado a partir del octavo mes de gestación), éste tejido da la apariencia de dividir el iris radialmente desde el centro de la pupila. Otras características importantes en el reconocimiento del patrón de la forma del iris son anillos, surcos, pecas y la corona, entre las características más familiares del ojo.
2.3.1. Cómo funciona
ISC-2003-1-24
21
Imagen tomada de International Biometric Group
La tecnología de reconocimiento del iris convierte estas características visibles en un formato de 512 bytes llamado IrisCode™, el cual representa una plantilla que se almacena para futuras comparaciones. El iris se dice que tiene 266 puntos únicos, en contraste con los 13 a 60 puntos únicos de otras medidas biométricas tradicionales. Estos 266 puntos se obtienen a partir de aplicar las funciones correlativas del algoritmo de reconocimiento a la imagen tomada del iris de una persona, y tomando las características inherentes a la mayoría de ojos humanos. El proceso consiste primero en la localización del ojo por una cámara a no más de un metro de distancia. Después de localizado el ojo, el algoritmo disminuye el rango de búsqueda ubicando los extremos derecho e izquierdo externos de la pupila. Esta aproximación horizontal, busca tener en cuenta la obstrucción acusada por los párpados. Simultáneamente se ubican los bordes internos del iris ubicados en la pupila. La cámara utiliza luz visible así como infrarroja para la extracción de la imagen. A continuación se procede a emplear operaciones de demodulación matemática empleando las Ondas en 2D de Gabor para filtrar y trazar los segmentos del iris en pequeños vectores (fasores). El algoritmo procede a la asignación de valores a las longitudes de onda extraídas de la orientación y frecuencia espacial de fragmentos de área del iris seleccionados, así como la posición de éstas áreas. En el análisis del iris, se descartan partes superiores e inferiores, ya que pueden ser afectados por los párpados y reflejos de luz. Con ésta información se procede a construir la plantilla que será almacenada, y utilizada posteriormente en comparaciones de la representación hexadecimal de la plantilla construida [18].
ISC-2003-1-24
22
Imagen tomada de International Biometric Group [16]
Características [16]
• Tiempo de respuesta: El proceso completo es muy rápido, el iris es normalmente ubicado y la plantilla generada en menos de un cuarto de segundo. Las búsquedas en la base de datos a su vez son muy veloces, analizando cientos de miles de registros por segundo en sistemas de bases de datos completos.
• Costo: Los costos de los dispositivos y sistemas necesarios han venido disminuyendo con el avance en la tecnología de cámaras y dispositivos ópticos. En el momento se pueden conseguir dispositivos de hasta cerca de 500 dólares para arriba.
• Exactitud: Es uno de los biométricos más certeros y exactos. La rata de falsos rechazos es prácticamente igual a la tasa de falsas aceptaciones, siendo una tasa impresionante de 1 en 1.2 millones. La probabilidad de que dos irises diferentes produzcan la misma plantilla es de 1 en 1052.
• Escalabilidad: Estos sistemas fueron construidos para ser escalables a millones de usuarios en la base de datos, permitiendo una tasa de error mínima. El sistema permite que se realicen consultas de verificación 1:1 o de identificación 1:N, de una manera muy eficiente y eficaz.
• Captura: Se construye y almacena una plantilla a partir de la imagen del iris del ojo, la tecnología utilizada es tan potente, que permite que se obtengan identificaciones con un error menor a 1 en 100.000 con tan sólo un tercio de la imagen del ojo capturada de manera exitosa y clara.
• Almacenamiento: Se almacena la plantilla IrisCode™, de los diferentes datos únicos del iris a cada ojo. Cada plantilla, incluye las características de los 266 puntos únicos a cada ojo almacenados en tan sólo 512 bytes.
• Infraestructura: Estos sistemas generalmente requieren de sistemas de almacenamiento, captura de imagen y procesamiento. El acceso a la información (sistemas de almacenamiento secundario) y el desempeño del procesador, pueden generar un cuello de botella en sistemas con un alto número de personas registradas.
ISC-2003-1-24
23
Uso y aplicación:
• Sistema de autentificación, verificación en entidades financieras para establecer la identidad de los individuos en la realización de las diferentes transacciones.
• Identificación de individuos buscados o considerados peligrosos en los sitios de acceso fronterizo. Su implementación se puede hacer en aeropuertos, oficinas de inmigración, etc.
• Identificación de criminales recurrentes. Se puede utilizar como reemplazo o complemento a la existente huella digital, ya que permite una menor tasa de error.
• Identificación y verificación de acceso físico a áreas de seguridad restringida, en las cuales se desee proteger algún activo dentro de la compañía.
• Se puede utilizar en cualquier escenario en el cual los sistemas de autenticación de usuarios sean necesarios. Su efectividad y certeza hace que se convierta en uno de los mejores mecanismos de autenticación en el mercado actualmente.
Sensores
En sistemas para el reconocimiento del iris se utilizan cámaras de vídeo de tipo CCD en la mayoría de los sistemas.
El corazón de la cámara es un circuito integrado tipo CCD (Dispositivo de Carga Acoplada). Este dispositivo consiste de varios cientos de miles de elementos individuales (píxeles) localizados en la superficie de un diminuto CI.
Cada píxel se ve estimulado con la luz que incide sobre él (la misma que pasa a través de los lentes y filtros de la camera), almacenando una pequeña carga de electricidad. Los píxeles se encuentran dispuestos en forma de malla con registros de transferencia horizontales y verticales que transportan las señales a los circuitos de procesamiento de la cámara (convertidor analógico-digital y circuitos adicionales). Esta transferencia de señales ocurre 6 veces por segundo [19].
ISC-2003-1-24
24
2.4. Comparación entre las dos tecnologías a utilizar en el proyecto Cuadro comparativo de las dos tecnologías extraído de International Biometric Group
Technology Positive Privacy Aspects Negative Privacy
Aspects BioPrivacy Technology
Risk Ratings
Finger-scan
· Can provide different fingers for different systems · Large variety of vendors with different templates and algorithms
· Storage of images in public sector applications · Use in forensic applications · Strong identification capabilities
Verification/ identification: H
Overt/covert: M Behavioral/physiological:
H Give/grab: M
Risk Rating: H
Iris-scan
· Current technology requires high degree of user cooperation - difficult to acquire image without consent · Iris images not used in forensic applications
· Very strong identification capabilities · Development of technology may lead to covert acquisition capability · Most iris templates can be compared against each other - no vendor heterogeneity
Verification/ identification: H
Overt/covert: L Behavioral/physiological:
H Give/grab: M
Risk Rating: H
c) Copyright 2002 International Biometric Group Cuadro comparativo realizado por ADMS (Advanced Digital Microsystems) [23]
Characteristic Ease of use
Error incidence Accuracy User
acceptance Required security level
Long-term stability
Fingerprints High Dryness, dirt, age High Medium High High
Iris Medium Poor Lighting
Very High Medium Very High High
Cuadro de exactitud inherente a los sistemas de autenticación realizado por ADMS [23] Biometric Crossover Accuracy
Iris Scan 1:131,000
Fingerprints 1:500
ISC-2003-1-24
25
Zephyr Analysis de International Biometric Group [24]
ISC-2003-1-24
26
3. HERRAMIENTAS DE PROGRAMACIÓN ADICIONALES Para el desarrollo y programación del presente proyecto se hizo necesario utilizar algunas herramientas de programación adicionales a las de los lenguajes de programación que se utilizarán. Dos de las herramientas que presentan gran importancia en el proyecto, y de las cuales fue necesario estudiar para ser utilizadas en el desarrollo de la solución fueron el BioApi (Interfaz de programación para biométricos) y JNI (Interfaz para incorporar funciones desarrolladas en lenguajes diferentes a Java).
3.1. BIOAPI [25]
“La especificación de BioAPI representa un paso importante en la industria de la biométrica, pues define un API abierto estándar que permite a las aplicaciones comunicarse con una amplia gama de tecnologías biométricas de una manera común.”5 El consorcio de BioAPI fue formado para desarrollar un API extensamente disponible y aceptado, que servirá para las diferentes tecnologías biométricas. El BioAPI está desarrollado con la intención de proveer un modelo de autenticación genérico de alto nivel e independiente de la tecnología biométrica utilizada. En él se cubren las funciones básicas de inscripción, verificación e identificación, e incluye adicionalmente una interfaz con la base de datos que permite a un proveedor de servicios biométricos (BSP) manejar la población para la identificación de manera óptima. También provee funciones que le permiten a la aplicación manejar la captura de las muestras a un cliente, así como la inscripción, verificación e identificación en el servidor. El BioAPI está diseñado para uso de los desarrolladores de aplicación, así como para desarrolladores o constructores de la tecnología biométrica. Para permitir la integración de la tecnología lo más simple y directa posible (así mejorando su viabilidad comercial), la aproximación tomada por esta interfaz es esconder o encapsular al máximo las complejidades de la tecnología biométrica. Ésta aproximación también sirve para extender
5 Palabras de Richard E. Norton, Executive Director of the International Biometric Industry Association (IBIA) en un comunicado de prensa. http://www.bioapi.org/BioAPI_news_press_files/press_files/PR01-001.htm
ISC-2003-1-24
27
la generalidad de la interfaz, y poder abarcar un mayor número de potenciales tecnologías biométricas y aplicaciones. Existen tres principales funciones abstraídas en el API:
1. Inscripción: Se capturan muestras a través de un dispositivo, se construyen plantillas para la futura comparación y posteriormente son retornadas a la aplicación.
2. Verificación: Una o más muestras son capturadas, procesadas en datos utilizables que sirvan para realizar comparaciones y luego comparadas contra alguna plantilla previamente construida.
3. Identificación: Una o más muestras son capturadas, procesadas en datos que puedan ser utilizados en comparaciones y posteriormente comparados contra un conjunto de plantillas. Se retorna un listado con los candidatos, mostrando qué tan cerca estuvieron los candidatos de la muestra tomada.
Adicionalmente el BioApi ofrece funciones para manejar la captura de las muestras en el cliente, distribuciones de las funciones básicas de inscripción, verificación e identificación entre el cliente y el servidor. Se soporta también el manejo de payload, información almacenada junto con el dato biométrico para ser revelada en el momento en que se haga una validación certera o una identificación de un usuario. Junto con esto el BioApi brinda la interfaz para que la aplicación pueda comunicarse con el servidor de servicios biométricos (BSP) y pueda ofrecer una interfaz con el usuario diferente a la que éste presenta. Si el BSP soporta administración y manejo de una base de datos interna, la interfaz (BioApi) ofrece funciones para comunicarse con ésta y para realizar las operaciones de gestión de dicha base de datos desde la aplicación. Se ofrece el llamado a funciones tales como crear base de datos, borrar base de datos, ingresar nuevo registro, etc. Algunos BSP ofrecen su propia base de datos principalmente por dos razones: optimizar el manejo de la información biométrica en bases de datos extensas y hacer un almacenamiento local en dispositivos que lo soporten.
ISC-2003-1-24
28
Posibles estrategias de implementación tomadas del documento BioAPI 1.1
El intercambio de información biométrica se realiza a través de un formato de información biométrica llamado en BIR (Biometric Identification Record), éste sigue las especificaciones descritas en el CBEFF (Common Biometric Exchange File Format) desarrollado por el CBEFF Technical Development Team.6 Este formato de información biométrica es usado en la construcción de las plantillas para almacenamiento en la base de datos, y en el procesamiento de las muestras capturadas en vivo para comparación.
Estructura del BIR descrita en el documento de referencia de BioApi 1.1
Implementación del BioAPI permitirá:
• Rápido desarrollo de aplicaciones que utilicen biométricos • Depuración flexible de biométricos a través de diferentes plataformas.
6 Mayor información del CBEFF se puede encontrar en la publicación NISTIR 6529 de Enero 3 de 2001 del National Institute of Standards.
ISC-2003-1-24
29
• Habilidad mejorada para explotar las mejoras en precio y desempeño en los biométricos.
• Puesta en práctica mejorada de alternativas utilizando múltiples tecnologías biométricas.
• Desarrollo de interfaces simples en las aplicaciones. • Acceso modular estándar a las funciones biométricas, algoritmos y dispositivos. • Métodos estándar para diferenciar datos biométricos y tipos de dispositivos. • Soporte para identificación biométrica en sistemas distribuidos.
Esto agregará valor a:
• Los administradores de seguridad de información y recursos. • Integradores de sistema y revendedores de soluciones de seguridad. • Desarrolladores de aplicaciones • Usuarios finales de tecnología biométrica.
Actualmente el bioApi se encuentra en la versión 1.1 de su especificación, y junto a ella desarrolló la primera versión de su implementación, desarrollada en C para Win32. En la implementación se incluye un ejemplo de aplicación utilizando la especificación y librerías proporcionadas en el mismo paquete, también programas de muestra de un Bsp, y algunos otros programas de muestra. Parte de la importancia en la utilización ésta interfaz para el desarrollo de aplicaciones biométricas se debe a que en 2002, BioApi ver1.1 fue aprobada por el ANSI y publicado como estándar nacional americano con el número ANSI/INCITS 358-2002. Adicionalmente en la reunión de diciembre del mismo año del ISO/IEC JTC1 SC37, el subcomité de la ISO para biométricos, los miembros de EU. del comité lo propusieron como estándar ISO [26]. Sin embargo, la implementación del BioApi 1.1 es la primera implementación disponible públicamente para el desarrollo de aplicaciones biométricas, razón por la cual la información para el desarrollo de aplicaciones basándose en esta interfaz es todavía escasa. Los que mayores avances y productos han sacado son los fabricantes de dispositivos biométricos y los proveedores de soluciones de seguridad basados en biométricos, y el código y documentación que ellos están dispuestos a contribuir para el desarrollo libre es casi nulo.
3.2. JNI (Java Native Interface)
Java Native Interface es una interface de programación estándar para escribir métodos nativos Java y embeber la Java Virtual Machine en aplicaciones nativas. JNI es una interfaz de programación nativa, ella permite que código que se ejecute dentro de una máquina
ISC-2003-1-24
30
virtual java (JVM) interaccione con aplicaciones y librerías hechas en lenguajes de programación diferentes a Java, por ejemplo C, C++ y lenguaje Ensamblador.
Uno de los más importantes beneficios de ésta interfaz es que no impone restricciones a la implementación de la JVM sobre la cual se ejecutan las aplicaciones. Anteriormente se habían presentado interfaces desarrolladas por los mismos proveedores de las máquinas virtuales, como por ejemplo: JRI (Java Runtime Interfaces) interfaz de Netscape y RNI (Raw Native Interfaces), uno de los métodos de bajo nivel de Microsoft7. JNI ofrece una interfaz común para facilidad de mantenimiento y desarrollo por parte de los programadores, los cuales no tienen que cambiar la implementación y compilación de sus métodos nativos dependiendo de la máquina virtual sobre la cual se va a ejecutar, perdiendo la interoperabilidad de Java.
La utilización de métodos nativos (desarrollados en lenguajes diferentes a Java) es necesaria en varias situaciones. Algunas de ellas son [27]:
• Cuando queramos utilizar una característica dependiente de la plataforma en donde vayamos a ejecutar nuestra aplicación como puede ser una tarjeta de recogida de datos.
• Cuando tengamos que trabajar con librerías escritas en otro lenguajes y son imprescindibles para nuestra aplicación, y resulta más difícil pasar la librería a Java.
• Métodos críticos en ejecución, que queramos que se ejecuten de manera más eficiente en un lenguaje de programación nativo como c o ensamblador. Esto con los nuevos avances en tecnología Java cada vez será menos preciso utilizar métodos nativos para lograr velocidad, con la perdida de portabilidad que esto supone.
Al utilizar JNI se pueden programar métodos nativos que sean capaces de crear, consultar y actualizar objetos Java, hacer llamados a métodos de Java, coger y arrojar excepciones, cargar clases y obtener información de ellas, y realizar revisiones de tipos. Esto es, se puede hacer casi todo lo que se hace en código Java desde código nativo. Sin embargo, existen algunas desventajas al utilizar la interfaz de programación JNI frente al desarrollo de la aplicación enteramente en Java. Algunas de las ventajas más sobresalientes en la utilización de ésta interfaz son [28]:
- Perdida de interoperabilidad La facilidad que provee Java de generar un único código que sea transportable a múltiples plataformas se pierde cuando se utiliza este modelo, ya que las funciones implementadas en código nativo por las librerías que llama la aplicación Java son dependientes de la plataforma para la cual se desarrolle.
7 JNI ha sido un punto de discusión entre Sun y Microsoft, ya que Microsoft busca crear su propia interfaz para código nativo y Sun alega que esto violaría su acuerdo de licencias.
ISC-2003-1-24
31
- Dificultad en la depuración La depuración de errores se dificulta, ya que las herramientas de programación ofrecen herramientas para la depuración de aplicaciones escritas en solo un lenguaje. Si se presentan errores en la comunicación, en el llamado a librerías adicionales requeridas o en el proceso de link, las herramientas de programación no ofrecen mayor descripción del problema. La depuración y corrección de este tipo de errores requiere de mayor experiencia y conocimiento. - Riesgos potenciales en la seguridad de la aplicación Al realizar llamados a métodos nativos desde Java, se pierden las restricciones de acceso a memoria y seguridad que Java proporciona para desarrollar aplicaciones más seguras. Utilizando métodos nativos, la seguridad de la aplicación es responsabilidad del programador. - Dificultad en programación y desarrollo La programación de aplicaciones utilizando dos lenguajes de programación diferentes y comunicación mediante JNI, requiere que el programador tenga más pericia y conocimientos que en una aplicación desarrollada completamente en Java. La programación de aplicaciones utilizando este modelo, además de requerir mayor conocimiento, implica mayor dificultad y complejidad en el código.
Al diseñar una aplicación utilizando este modelo, hay que analizar posibles alternativas y considerar la viabilidad y conveniencia de utilizar JNI en el desarrollo de la solución. Para el presente proyecto, se consideró que JNI ofrecía la solución más apropiada para la utilización de la implementación de BioApi hecha en C.
ISC-2003-1-24
32
4. ALMACENAMIENTO DE LA INFORMACIÓN EN LDAP Para el almacenamiento de los datos correspondientes a las diferentes medidas biométricas, se consideró la utilización de un servicio de directorios. El servicio de directorios presenta facilidades de búsqueda y agrupación de información y está diseñado para agilizar las consultas sobre los datos. Adicionalmente posee una estructura que facilita el almacenamiento de la información de los individuos que pertenecen a una compañía. La utilización de un sistema de directorios para el almacenamiento de la información presenta una solución satisfactoria para la construcción del repositorio de la información en este proyecto. La naturaleza estática de la información que se almacenará en el repositorio, la necesidad de optimizar las consultas realizadas y la estructura de la información misma, en la cual se desea agrupar la información de las diferentes medidas biométricas de una misma persona en una misma entrada de la base de datos, hacen que el servicio de directorios sea un sistema apropiado para almacenar la información de los diferentes mecanismos biométricos. LDAP ofrece adicionalmente mayor simplicidad que los servidores de directorios basados exclusivamente en el estándar X.500 y ofrece un protocolo más eficiente para el manejo de los datos a través de la red.
4.1. Introducción a LDAP (Lightweight Directory Access Protocol) LDAP es una tecnología de crecimiento acelerado, que sirve para acceso a información de directorios común. Se está generando como un estándar abierto, independiente del proveedor, que proporciona una arquitectura extensible para un almacenamiento y administración de la información de manera central. LDAP define un método estándar para tener acceso y actualizar la información en un directorio. LDAP está ganando aceptación como el método de acceso a directorios en Internet. Está siendo apoyado por un número significativo de los vendedores de software e incorporado en un número creciente de aplicaciones.
ISC-2003-1-24
33
4.2. Diferencias entre directorio y base de datos relacional [33] Un directorio es una especie de base de datos especializada o repositorio, en la cual se almacena información ordenada de alguna manera acerca de objetos. Existen algunas características que separan a un directorio de una base de datos relacional. Una característica principal es que los directorios son accedidos con una frecuencia mucho mayor de que la frecuencia a la cual se actualiza la información. Gracias a que los directorios están diseñados para soportar grandes volúmenes de lecturas o accesos a la información, generalmente están optimizados para realizar consultas eficientes. Por lo que los directorios están diseñados para almacenar información relativamente estática, y están optimizados para ello, no se recomienda almacenar en ellos información que cambie continuamente. Otra característica importante que diferencia a los directorios de las bases de datos relacionales de propósito general es, que los directorios no soportan el concepto de transaccionalidad (operaciones que se definen para que se ejecuten de manera atómica, todo o nada). La información almacenada en un directorio puede llegar a ser temporalmente inconsistente, ya que la información allí almacenada no es transaccional, y los cambios a ella son infrecuentes. El acceso a la información se diferencia al utilizado en las bases de datos convencionales, la mayoría de las base de datos soportan un método de acceso muy complejo y poderoso llamado SQL, en cambio LDAP utiliza un protocolo simplificado y optimizado del acceso que puede ser utilizado en aplicaciones livianas y relativamente simples
4.3. Estructura de directorio en LDAP La unidad básica de información almacenada en un directorio es una entrada. Las entradas representan objetos de interés, están compuestas de una colección de atributos que contienen información de un objeto. Cada atributo tiene un tipo y uno o más valores asociados. El tipo de atributo a su vez es asociado con una sintaxis, que especifica qué tipo de valores pueden ser almacenados. Adicionalmente a definir qué tipo de datos pueden ser almacenados en un atributo, la sintaxis también define el comportamiento de éstos valores en las diferentes consultas y operaciones sobre los directorios.
ISC-2003-1-24
34
Se pueden establecer restricciones sobre los tipos de los atributos para limitar la cantidad de valores que pueden ser almacenados, o inclusive para limitar el tamaño de los datos que se almacenen en él. Los esquemas definen el tipo de objeto que pueden ser almacenados en un directorio. Los esquemas listan también los atributos de cada tipo de objeto, y si éstos son necesarios u opcionales. Chequeo en los esquemas asegura que todos los atributos requeridos para una entrada están presentes, antes de ser almacenada. Cada entrada de un directorio posee un atributo especial llamado objectClass. El valor de este atributo es analista de dos o más nombres de esquemas. Los esquemas definen el tipo de objetos que la entrada representa. El objectClass, determina cuáles atributos puede y cuáles debe tener una entrada. Las entradas son organizadas en una estructura jerárquica similar a un árbol, llamada Directory Information Tree (DIT). Las entradas dentro de éste árbol son ubicadas por su Distinguished Name (DN). Un DN es un nombre único que define de manera concreta una entrada particular. Los DNs están compuestos por una secuencia de DNs relativos (RDN). Cada RDN dentro de un DN corresponde a una rama en el árbol determinando el camino desde la raíz hasta la entrada. Cada RDN es derivado de los atributos dentro de la entrada del directorio [31].
4.4. Protocolo LDAP LDAP es un protocolo para el almacenamiento de información en directorios en una arquitectura cliente-servidor, basado en el estándar X.500. El X.500 organiza las entradas de directorio en un espacio de nombres jerárquico, capaz de apoyar grandes cantidades de información. También define métodos de gran alcance de búsqueda para hacer la consulta de la información más fácil. Debido a su funcionalidad y escalabilidad, el X.500 se utiliza a menudo junto con módulos adicionales para la operación entre los servicios incompatibles del directorio. El X.500 especifica que la comunicación entre el cliente del directorio y el servidor del directorio utiliza el Directory Access Protocol (DAP). Sin embargo, como protocolo de capa de aplicación, el DAP requiere el protocolo entero de la OSI para funcionar. El soporte del protocol stack de la OSI requiere más recursos y es más costoso de implementar que el popular TCP/IP [33]. LDAP fue desarrollado como una alternativa ligera a DAP. LDAP requiere del protocolo más ligero y popular de TCP/IP, en lugar del protocolo en niveles de la OSI. LDAP también simplifica algunas operaciones X.500 y omite algunas características esotéricas.
ISC-2003-1-24
35
LDAP define un protocolo de comunicación. Es decir, define el transporte y el formato de los mensajes usados por un cliente para tener acceso a datos en un directorio de X.500. LDAP no define el servicio de directorio en sí mismo.
4.5. Directorio LDAP Una aplicación cliente inicia un mensaje de LDAP llamando un método especificado en el LDAP API. Pero un servidor del directorio X.500 no entiende mensajes de LDAP. De hecho, el cliente de LDAP y el servidor el X.500 incluso utilizan diferentes protocolos de comunicación (TCP/IP contra la OSI). El cliente de LDAP se comunica realmente con un proceso de entrada (también llamado proxy) que retransmite las peticiones al servidor de directorio X.500. Esta entrada se conoce como servidor de LDAP. Éste servidor mantiene peticiones del cliente de LDAP, hace esto actuando como cliente del servidor X.500. El servidor de LDAP debe poder comunicarse con TCP/IP y OSI para servir como cliente al servidor X500 (OSI) y como servidor LDAP (TCP/IP).
Imagen del redbook Understanding LDAP de IBM
4.6. Servidores Stand Alone A medida que el uso de LDAP se volvió más popular, y los beneficios se comenzaron a vislumbrar en las diferentes aplicaciones, las personas que no poseían servidores X.500 o los ambientes necesarios para soportarlos, deseaban construir directorios que pudieran ser accedidos por clientes LDAP. Entonces pensaron en una solución que tuviera el almacenamiento en el servidor de LDAP y accediera al directorio sí mismo, en vez solamente de actuar como entrada a los servidores X.500. Esto eliminaba cualquier necesidad del protocolo pesado de la OSI. Por supuesto esto hace al servidor de LDAP mucho complicado, puesto que debe almacenar y recuperar entradas de directorio. Estos servidores de LDAP a menudo se llaman los servidores independientes de LDAP porque no dependen de un servidor del directorio X.500. Puesto que LDAP no apoya todas las
ISC-2003-1-24
36
capacidades X.500, un servidor independiente de LDAP necesita solamente apoyar las capacidades requeridas por LDAP.
Imagen del redbook Understanding LDAP de IBM
4.7. Modelos LDAP LDAP se basa principalmente en cuatro modelos:
• Información: Describe la estructura de la información que puede ser almacenada en un directorio.
• Nombres: Describe cómo es organizada e identificada la información de los directorios, para sus posteriores consultas.
• Funcional: Describe las operaciones que pueden ser ejecutadas sobre la información almacenada en los directorios.
• Seguridad: Describe cómo la información puede ser protegida contra acceso no autorizados a la información.
Esos cuatro modelos describen a grandes rasgos las características del modelo LDAP, sobre las cuales se basa y definen el modelo grosso modo.
4.8. LDAP en el proyecto La utilización de LDAP en el proyecto ha demostrado tener varios beneficios por características expuestas anteriormente en este documento. La eficiencia en las consultas que provee el sistema de directorios se acomoda a los requerimientos del sistema, ya que la eficiencia y tiempo de respuesta juegan un papel
ISC-2003-1-24
37
importante en un sistema de autenticación. El usuario no está dispuesto a esperar mucho tiempo para que el sistema le otorgue acceso. Las características de la información que se maneja en un sistema de autenticación se acomodan a los requisitos que se deben cumplir para utilizar exitosamente un sistema de directorios, lo que permite realizar una solución apropiada. La información no se modifica constantemente, ni se requiere que las operaciones sean transaccionales. Esto hace que las debilidades del sistema de directorios en el manejo de información no desmejoren el sistema. La naturaleza y tipo de información manejados en el sistema, hace que el esquema jerárquico manejado en los directorios sea apropiado para representar los datos. Por esto se consideró que LDAP era una herramienta importante que proporcionaba las características y beneficios adecuados para que el sistema cumpliera con sus requerimientos. El modelo del mundo planteado en el diseño, se adaptó para la implementación utilizando el modelo de directorios. Para esto, algunas clases no se representaron en Java como objetos, pero sí se representaron como objectClass en el directorio. Las clases que se representaron como entradas en el directorio, definidas en esquemas y que no tenían definidas clases en Java, debían presentar ciertas características importantes: no ofrecer funcionalidad adicional a la consulta y modificación de sus atributos, sus atributos podrían ser representados en tipos de datos básicos o mediante cadenas de caracteres y que la asociación entre clases se pudiera representar mediante la jerarquía de directorios. Las clases que cumplieron con dichas características, y para las cuales se definió un esquema para su definición en el sistema de directorios fueron:
• Perfil de usuario: Esta clase representa los perfiles de usuario definidos según el rol que se tiene ante el sistema, y que permite mejor gestión de usuarios. Para ella se definió un nuevo objectClass en un esquema de directorios.
• Dependecias: Las dependecias en el modelo del sistema se asemejan a las Organizational Units de LDAP, motivo por el cual se consideró que este objectClass representaba de manera satisfactoria a esta clase.
• Niveles de Seguridad: Esta clase tiene un único atributo con un identificador, su principal objetivo es de clasificación de usuarios por los permisos que éstos tienen sobre el sistema. Para esta clase se definió un nuevo objectClass, para tener niveles de seguridad definidos en el sistema.
En el diseño de la información en el directorio se observó la necesidad de tener una clase que reuniera la información básica del usuario, que tuviera asignada un perfil de usuario y a la cual se le asignara el objeto Java que representa al usuario en cuestión. Para esto se miraron las clases predefinidas para los usuarios de las organizaciones en LDAP, pero se observó que aunque la clase inetOrgPerson reunía casi todos los atributos necesarios, era
ISC-2003-1-24
38
necesario crear una nueva clase que heredara de ésta a la cual se le pudiera asignar un perfil de usuario. Esta clase se definió como:
• Biometric Person: Representa la información del usuario dentro de la organización.
Como apoyo a la creación de estas clases en los directorios, y para seguir con el modelo del mundo planteado, se consideró conveniente crear algunos atributos nuevos, adicionales a los establecidos en los RFC8 para los servicios de directorios. Los atributos que se definieron son:
• Nivel: Este atributo representa el identificador de la clase Nivel de Seguridad definida.
• Perfil: Este atributo representa el identificador de la clase Perfil de Usuario. 8 RFC (request for Comments) son un grupo de documentos técnicos sobre Internet y aspectos relacionados. Estos documentos si tienen interés de la comunidad y apoyo suficiente, se convierten en estándar.
ISC-2003-1-24
39
5. SISTEMAS ACTUALES DE AUTENTICACIÓN POR DIFERENTES MÉTODOS BIOMÉTRICOS
5.1. Sistemas de autenticación multimodal Los sistemas de autenticación basados en biométricos a pesar de presentar numerosas ventajas antes mencionadas, se ha visto que su eficacia se puede ver limitada por la calidad de la muestra tomada, por el dispositivo de captura y por la posible incapacidad de capturar la medida de algún individuo por alguna limitación física. Los sistemas multimodal mitigan este riesgo y aumentan la efectividad del sistema incorporando simultáneamente numerosos dispositivos biométricos diferentes. Ésta estructura mejorada de integración de tecnologías utiliza las virtudes de cada tecnología biométrica del sistema para brindar mejor eficiencia, menores tasas de error y adicionalmente sobrepasar los problemas que pueda tener una tecnología determinada (por ejemplo se estima que el 5% de la población tiene huellas digitales ilegibles). Adicionalmente ofrece un mayor grado de dificultad de falsificación, ya que se aumenta el número de datos que se deben falsificar para poder vulnerar el sistema [34]. A continuación se realiza una breve descripción de algunos de los sistemas más importantes en el mercado.
5.2. Sistemas integrados de seguridad BioNetrix Authentication Suite 4.1 [35]
El BioNetrix Authentication Suite es una plataforma de software que ofrece a las organizaciones administración unificada necesaria para depurar cualquier combinación de tecnologías avanzadas de autenticación, tales como smart cards, tokens y biométricos. En
ISC-2003-1-24
40
ella se pueden implementar accesos basados en políticas cliente-servidor, aplicaciones legado y aplicaciones web.
El Authentication Suite habilita a que las organizaciones puedan consolidar tecnologías de autenticación separadas, usando una plataforma de administración universal para administrar centralmente las politicas de autenticación para el sistema completo.
El núcleo del Authentication Suite es el manejador de autenticación, el cual provee herramientas para configurar y monitorear todas las actividades de autenticación. Integrado con el manejador de autenticación está la interfaz de dispositivos unificada, el cual permitirá interoperabilidad entre métodos de verificación y aplicaciones.
El Authentication Suite soporta el más extensivo método de autenticación y librerías de aplicación en la industria. Permite a las organizaciones depurar cualquier combinación de verificaciones biométricas y no biométricas con otras aplicaciones líderes en seguridad.
Características y ventajas
• Administración unificada de autenticación para empresas y aplicaciones web • Un motor dinámico de políticas patentado para la implementación de políticas de
autenticación a lo largo de la compañía. • Administración centralizada o distribuida con funcionalidad basada en tareas. • Inscripción única para autenticación a múltiples aplicaciones. Generación de
bitácoras en tiempo real de eventos de autenticación. • Integración con algunos sistemas de seguridad existentes. • Arquitectura altamente escalable y tolerante a fallos.
ISC-2003-1-24
41
Safe World PremierAccess – Secure Computing [36]
PremierAccess otorga control sobre quién puede acceder su red, VPN y aplicaciones de red a través de herramientas poderosas incluyendo el Web Agent Universal, auto inscripción de usuarios, multiples opciones de autenticación y autorización basada en roles. Se pueden administrar a todos los usuarios y puntos de acceso dea manera centralizada con una única herramienta.
Características y ventajas
• Se puede administrar todos los puntos de acceso en una única aplicación que los integra.
• Se puede lograr un control de acceso con autorización flexible basada en roles. • Se permite una autenticación de dispositivos, como de usuarios. • Brinda protección a cualquier servidor web. • Permite el manejo de cualquier número de usuarios, desde unos pocos hasta
millones de usuarios. • A través del Authentication Broker se pueden extender las capacidades de la
infraestructura actual, como lo puede ser ActiveDirectory o sistemas legados de autenticación.
5.3. Sistemas de control de acceso con acoplamiento a los sistemas de información actuales
Daon para Windows [37] Daon para Windows es un producto de autenticación biométrico que elimina la necesidad de que los usuarios tengan que recordar una contraseña cuando se identifican para iniciar sesión en Windows en un computador. Con esta solución se presentan beneficios como la disminución de administración de contraseñas en una red, esto a su vez disminuye costos y brinda un mayor nivel de seguridad dentro de la red. El producto fue desarrollado por Daon en alianza con IBM como una solución que permite que los biométricos se integren al ambiente laboral cotidiano, adaptándose al sistema de control de acceso más utilizado.
ISC-2003-1-24
42
SAF Solution Enterprise Edition for Windows [38] SAF Solution Enterprise para Windows es una solución de seguridad biométrica que permite a usuarios ingresar a sus estaciones de trabajo y dominios de Windows. Está diseñada y probada para depuraciones a nivel empresarial, SAF Solution se integra estrechamente con Microsoft Active Directory, permitiéndoles a los administradores asegurar el acceso a la red y a las estaciones de trabajo. Secure Suite XS – I/O Software SecureSuite XS proporciona una plataforma de autenticación sólida, modular y flexible a cualquier dominio de Windows 2000. SecureSuite XS Server está plenamente integrado con Windows Active Directory, y con su arquitectura multi-factor ofrece integración con una multitud de tecnologías avanzadas de autenticación, incluyendo biométricos, tokens, smart cards, y dispositivos combinados. SecureSuite XS ofrece un paquete conveniente de autenticación, con soporte a múltiples tecnologías, administración central de cuentas, herramientas poderosas de administración y amplias capacidades de auditoria. Proporciona identificación a PC, a archivos, carpetas y aplicaciones, ofreciendo funcionalidad de único acceso. Adicionalmente ofrece herramientas para control de acceso basado en web, como para aplicaciones Windows. Ofrece herramientas que permiten administración centralizada de usuarios y permisos. Adicionalmente se ofrecen herramientas que permiten la integración con sistemas de seguridad y control de acceso existentes, para permitir un manejo centralizado de seguridad.
ISC-2003-1-24
43
6. DISEÑO DE SISTEMA Y ANÁLISIS DE REQUERIMIENTOS
6.1. Metas
• Proporcionar un sistema de autenticación a través de biométricos que pueda validar la identificación de un usuario.
• Soportar múltiples tecnologías biométricas diferentes. • Generar una solución estándar, que sea independiente de los fabricantes de los
dispositivos, del fabricante del servidor de directorios y de la plataforma sobre la cual se ejecute.
• Utilizar estándares de la industria, que permitan compatibilidad con diferentes sistemas y mayor vigencia de la aplicabilidad del sistema.
• La aplicación deberá ser capaz de autenticar un usuario a través de un dato biométrico.
• Se deberá poder hacer seguimiento de las acciones realizadas en el sistema • Administrar información de usuarios registrados en el sistema.
Desarrollo de un piloto del sistema, que permita realizar las funciones relacionadas a los casos de uso en cuestión. Sin embargo la solución planteada da cabida a mejoras en requerimientos técnicos; como seguridad de transmisión de datos, encripción de información, manejo de carga de usuarios concurrentes, políticas de respaldo de información e integración con sistemas operativos existentes, para ingreso a ellos. El sistema planteado pretende establecer un modelo básico sobre el cual se podrán apoyar soluciones de seguridad más completas. La solución planteada no incluye la parte del servidor de servicios biométricos (BSP), dicha aplicación es proveída por el fabricante del dispositivo para controlar las funciones específicas a él. El BSP deberá seguir las especificaciones del bioAPI para que se pueda utilizar exitosamente (deberá ser BioAPI compliant).
ISC-2003-1-24
44
6.2. Usuarios del sistema
• Administrador de sistema, administrador de alguna instalación específica, responsable de seguridad o responsable del control de acceso.
• Administrador de las bases de datos. • Usuarios miembros de una organización para los cuales sea necesario establecer
políticas de seguridad y restricciones de acceso a recursos. • Usuarios interesados en el tema de seguridad y control de acceso.
6.3. Análisis de requerimientos 6.3.1. Casos de uso de la aplicación
A continuación se muestran los escenarios principales considerados para el uso de la aplicación, agrupados en tres categorías: manejo de usuarios, autenticación biométrica y auditoría. Manejo de usuarios Nombre Caso de Uso: C1. Agregar perfil de usuario Iteración: Filled Resumen: Se ingresa un nuevo perfil de usuario en el sistema con los datos ingresados por
el usuario. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. Este caso de uso comienza cuando el administrador manifiesta al sistema su deseo de crear un nuevo perfil de usuario 3. El usuario ingresa la información del perfil de usuario que desea adicionar.
2. El sistema le ofrece al actor un formato con la información que se necesita para crear dicho perfil 4. El sistema crea el nuevo perfil de usuario en el sistema con la información ingresada por el actor. 5. El sistema informa al actor de el resultado de la operación sea éxito o fracaso.
ISC-2003-1-24
45
Caminos de Excepción: Ya existe un perfil con el mismo nombre, hubo error al crear el perfil o los datos ingresados fueron inválidos. El sistema despliega un mensaje de error.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactua Suposiciones: Los datos ingresados para el perfil son coherentes, no se hace verificación del
tipo de datos ingresados, ya que éstos son texto y pueden ser cualquier combinación de caracteres establecido por el usuario. Se ha podido establecer una conexión exitosa con el servidor LDAP con anterioridad y ésta no se ha perdido.
Pre-condiciones: Post- Condiciones: Se ingresa un nuevo perfil de usuario con los datos dados. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C2. Agregar nivel de seguridad Iteración: Filled Resumen: Se ingresa un nuevo nivel de seguridad para los usuarios Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. Este caso de uso comienza cuando el administrador manifiesta al sistema su deseo de ingresar un nuevo nivel de seguridad. 3. El usuario ingresa la información solicitada por el sistema.
2. El sistema le pregunta al actor cuál nivel de seguridad desea crear para el sistema 4. El sistema verifica que no exista previamente un nivel de seguridad igual.
5. El sistema crea el nuevo nivel de seguridad deseado por el actor. 6. El sistema informa al actor de el resultado de la operación sea éxito o fracaso.
Caminos de Excepción: Ya existe un nivel de seguridad con el mismo nombre, hubo error al crear el nivel de seguridad o los datos ingresados fueron inválidos. El sistema despliega un mensaje de error.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactua Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se ingresa un nuevo nivel de seguridad al sistema Autor: Diego L. Maldonado Fecha: Mayo de 2003
ISC-2003-1-24
46
Nombre Caso de Uso: C3. Agregar dependencia Iteración: Filled Resumen: Se agrega una nueva dependencia que representa el departamento al que
pertenecen los usuarios Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. Este caso de uso comienza cuando el administrador manifiesta al sistema su deseo de ingresar una nueva dependencia. 3. El usuario ingresa la información solicitada por el sistema.
2. El sistema le pregunta al actor los datos necesarios para crear una dependencia 4. El sistema verifica que no exista una dependencia con el mismo nombre
5. El sistema crea la nueva dependencia. 6. El sistema informa al actor de el resultado de la operación sea éxito o fracaso.
Caminos de Excepción: Ya existe una dependencia con el mismo nombre, hubo error al crear la dependencia o los datos ingresados fueron inválidos. El sistema despliega un mensaje de error.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactua Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se ingresa una nueva dependencia al sistema Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C4. Ingresar un usuario en el sistema Iteración: Filled Resumen: Ingresar un nuevo usuario a la base de datos Curso Básico Eventos: Acción del Actor Respuesta del sistema
ISC-2003-1-24
47
1. Este caso de uso comienza cuando un administrador indica su deseo de ingresar un nuevo usuario a la base de datos. 3. El administrador ingresa los datos del usuario que desea registrar en la plantilla proporcionada.
2. El sistema le ofrece al actor la plantilla con la información requerida para el ingreso de un usuario al sistema. 4. El sistema verifica que el código de usuario no haya sido asignado a otro usuario. 5. El sistema procede a ingresar el nuevo usuario en la base de datos del sistema. 6. El sistema notifica el resultado de la operación al administrador.
Caminos de Excepción: El usuario ya existe, los datos del usuario que se desea ingresar son inválidos o existe error al ingresar el usuario en la base de datos. El sistema informa el error al administrador.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se ingresa un usuario nuevo. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C5. Agregar medida biométrica a un usuario Iteración: Filled Resumen: Agregar una medida biométrica que identifica a un usuario determinado. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea ingresar una nueva medida biométrica de un usuario determinado. 3. El administrador indica el momento en el que desea realizar la captura de dicho dato.
2. El sistema muestra la interfaz de captura del dato biométrico proporcionada por el fabricante del dispositivo. 4. El sistema realiza la captura y procede a almacenar la información de la medida tomada. 5. El sistema notifica al administrador del resultado de la operación.
ISC-2003-1-24
48
Caminos de Excepción: El usuario no existe, la medida biométrica solicitada no está soportada o disponible, error en la captura de la medida, error en la construcción de la plantilla extraída de la muestra.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. El dispositivo y aplicación que lo controlan están funcionando correctamente.
Pre-condiciones: True Post- Condiciones: Se ingresa una nueva medida biométrica. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C6. Modificar información de un usuario Iteración: Filled Resumen: Modificar la información básica que posee un usuario. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea realizar un cambio a la información de un usuario determinado. 3. El administrador realiza cambios a la información proporcionada e indica que desea realizar los cambios.
2. El sistema busca el usuario y le muestra al administrador la información actual del usuario indicado. 4. El sistema actualiza la información del usuario indicado.
Caminos de Excepción: El usuario no existe en el sistema, la información ingresada es inválida, ocurre
un error al actualizar la información del usuario. Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: El código del usuario permanece inalterado. Post- Condiciones: Se modifica exitosamente la información de un usuario con determinado código. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C7. Modificar o reasignar alguna medida biométrica de un usuario Iteración: Filled Resumen: Se toma una medida biométrica para reemplazar otra existente del mismo tipo
para un usuario determinado y se reemplaza en la base de datos. Curso Básico Eventos: Acción del Actor Respuesta del sistema
ISC-2003-1-24
49
1. El caso de uso comienza cuando el administrador del sistema indica que desea tomar una medida biométrica para un usuario dado. 3. El administrador indica cuál medida se desea cambiar, e indica el momento en que se debe realizar la nueva captura.
2. El sistema busca el usuario sobre el cual se desea realizar el cambio y despliega la interfaz de captura de muestra biométrica. 4. El sistema procede a realizar la captura de la información y reemplazar la existente. 5. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: El cliente no existe en la base de datos, la medida capturada no es satisfactoria, hubo un error al almacenar la información. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: True Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. El dispositivo y aplicación que lo controlan están funcionando correctamente.
Pre-condiciones: Post- Condiciones: Se reasigna exitosamente la medida biométrica al usuario. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C8. Modificar la descripción de una dependencia Iteración: Filled Resumen: Se modifica la descripción de una dependencia con un nombre específico. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea buscar una dependencia para modificarla. 3. El administrador modifica la información que quiere que cambie y le informa al sistema que realice los cambios.
2. El sistema busca la dependencia con ese nombre, y le muestra los datos actuales de ella al usuario. 4. El sistema realiza los cambios a la dependencia. 5. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: La dependencia no existe en la base de datos, hubo un error al almacenar la información. El sistema deberá notificar al administrador en caso de que se
ISC-2003-1-24
50
presente alguno de estos acontecimientos. Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: El nombre de la dependencia permanece inalterado. Post- Condiciones: Se modifica exitosamente la información descriptiva de la dependencia Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C9. Modificar un perfil de usuario Iteración: Filled Resumen: Se modifican los datos que describen al perfil de usuario Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea buscar un perfil de usuario con un determinado nombre para modificarlo. 3. El administrador modifica la información que desea cambiar y le informa al sistema que realice los cambios.
2. El sistema busca el perfil con ese nombre, y le muestra los datos actuales de este al usuario. 4. El sistema actualiza la información del perfil. 5. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: No existe un perfil con ese nombre en la base de datos, hubo un error al almacenar la información. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: El nombre del perfil permanece inalterado. Post- Condiciones: Se modifica exitosamente la información del perfil. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C10. Eliminar un perfil de usuario Iteración: Filled Resumen: Se elimina un perfil con un nombre dado de la base de datos Curso Básico Eventos: Acción del Actor Respuesta del sistema
ISC-2003-1-24
51
1. El caso de uso comienza cuando el administrador del sistema indica que desea eliminar un perfil de usuario con un determinado nombre.
2. El sistema busca el perfil con ese nombre y procede a eliminarlo. 3. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: No existe un perfil con ese nombre en la base de datos, hubo un error al eliminar
el perfil. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se elimina exitosamente el perfil. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C11. Eliminar nivel de seguridad Iteración: Filled Resumen: Se elimina un nivel de seguridad determinado de la base de datos Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea eliminar un nivel de seguridad específico.
2. El sistema busca el nivel con ese nombre y procede a eliminarlo. 3. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: No existe un nivel de seguridad con ese nombre en la base de datos, hubo un
error al eliminar el nivel. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se elimina exitosamente el nivel de seguridad. Autor: Diego L. Maldonado Fecha: Mayo de 2003
ISC-2003-1-24
52
Nombre Caso de Uso: C12. Eliminar una dependencia Iteración: Filled Resumen: Se elimina una dependencia con un nombre dado de la base de datos Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea eliminar una dependencia con un nombre determinado.
2. El sistema busca la dependencia con ese nombre y procede a eliminarla. 3. El sistema notifica al usuario del resultado de la operación.
Caminos de Excepción: No existe una dependencia con ese nombre en la base de datos, hubo un error al
eliminar la dependencia. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. Pre-condiciones: True Post- Condiciones: Se elimina exitosamente la dependencia de la base de datos. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C13. Eliminar un usuario del sistema Iteración: Filled Resumen: Se elimina un usuario del sistema que posee un código dado. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea eliminar un usuario del sistema con un código específico.
2. El sistema busca el usuario y en caso de existir procede a eliminarlo de la base de datos. 3. El sistema informa al administrador el resultado de la operación.
Caminos de Excepción: No existe un usuario en la base de datos con el código ingresado, hubo un error al eliminar el usuario. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Otros casos de uso que disparen este
Quien lo llama… con quienes interactúa Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido.
ISC-2003-1-24
53
Pre-condiciones: True Post- Condiciones: Se elimina exitosamente el usuario de la base de datos. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C14. Buscar la información básica de un usuario en el sistema. Iteración: Filled Resumen: Se busca y despliega la información de un usuario dado su nombre o su código. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador del sistema indica que desea buscar un usuario con un código o un nombre determinado.
2. Si el usuario ingresa el código, el sistema procede a buscar el usuario en la base de datos. Si no ingresa un código, procede a buscar el primer usuario que tenga el nombre dado por el usuario. 4. El sistema despliega la información del usuario encontrado que cumple con los parámetros de búsqueda. 3. El sistema informa al administrador el resultado de la operación.
Caminos de Excepción: No existe un usuario en la base de datos con el código o con el nombre ingresado, hubo un error al buscar el usuario. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: C1 Ingresar usuario en el sistema
C6 Modificar usuario C13 Eliminar usuario
Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con anterioridad y ésta no se ha perdido.
Pre-condiciones: True Post- Condiciones: Se encuentra un usuario en la base de datos y se despliega su información básica. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Autenticación biométrica. Nombre Caso de Uso: C15. Autenticación de un usuario Iteración: Filled Resumen: Autentica un usuario dada su identificación, la naturaleza de la medida y la
información de la medida biométrica. Curso Básico Eventos: Acción del Actor Respuesta del sistema
ISC-2003-1-24
54
1. El caso de uso comienza cuando el usuario le indica al sistema que desea autenticarse como usuario válido con una identificación 3. El usuario le informa al sistema el momento en el cual desea que se realice la captura de la muestra.
2. El sistema despliega la interfaz de captura de muestra biométrica proporcionada por el dispositivo para realizar la captura del dato. 4. El sistema toma la muestra y realiza la verificación de la muestra con la identificación ingresada contra los registros almacenados en la base de datos. 5. El sistema genera un veredicto de validez determinado por el resultado de la comparación anterior. 6. El sistema notifica al usuario el veredicto generado.
Caminos de Excepción: No existe un usuario en la base de datos con el código ingresado, hubo un error al validar el usuario, la muestra tomada no es satisfactoria. El sistema deberá notificar al usuario en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. El dispositivo y aplicación que lo controlan están funcionando correctamente.
Pre-condiciones: True Post- Condiciones: Se valida si el usuario está registrado en el sistema exitosamente. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C16. Crear plantilla de información biométrica. Iteración: Filled Resumen: Crear una plantilla a partir del dato capturado por el dispositivo. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador le indica al sistema que desea realizar crear una nueva plantilla biométrica. 3. El administrador le informa al
2. El sistema despliega la interfaz de captura de muestra biométrica proporcionada por el dispositivo para realizar la captura del dato.
ISC-2003-1-24
55
6. El sistema notifica al administrador el resultado de la operación.
Caminos de Excepción: Hubo un error al crear la plantilla, la muestra tomada no es satisfactoria. El
sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: C15 Agregar medida biométrica a un usuario Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con
anterioridad y ésta no se ha perdido. El dispositivo y aplicación que lo controlan están funcionando correctamente.
Pre-condiciones: True Post- Condiciones: Se crea una plantilla biométrica. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Auditoría Nombre Caso de Uso: C17. Generar entrada en logs de auditoría. Iteración: Filled Resumen: Generar una entrada en los logs de auditoría al realizar ciertas funciones del
sistema. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador le indica al sistema que desea realizar algunas de las funciones a las que se les desea hacer seguimiento.
2. El sistema genera una entrada nueva en el archivo de la fecha actual de logs, indicando la acción, responsable y origen de solicitud.
Caminos de Excepción: Error al escribir en el archivo. El sistema deberá notificar al administrador en
caso de que se presente alguno de estos acontecimientos. Puntos de Extensión: Triggers: C1 Agregar perfil usuario
C2 Agregar nivel de seguridad C3 Agregar dependencia C4 Ingresar usuario en el sistema C5 Agregar medida biométrica de un usuario C6 Modificar información de un usuario C7 Modificar o reasignar medida biométrica de un usuario C8 Modificar la descripción de una dependencia C9 Modificar perfil de usuario C10 Eliminar perfil de usuario C11 Eliminar nivel de seguridad C12 Eliminar dependencia
ISC-2003-1-24
56
C13 Eliminar usuario del sistema C15 Autenticar usuario ante el sistema
Suposiciones: Se ha podido establecer una conexión exitosa con el servidor LDAP con anterioridad y ésta no se ha perdido.
Pre-condiciones: True Post- Condiciones: Se escribe una entrada nueva en el archivo de logs. Autor: Diego L. Maldonado Fecha: Mayo de 2003 Nombre Caso de Uso: C18. Leer logs de una fecha determinada Iteración: Filled Resumen: Leer la información de los logs de auditoría para una fecha determinada. Curso Básico Eventos: Acción del Actor Respuesta del sistema
1. El caso de uso comienza cuando el administrador le indica al sistema que desea leer los logs de una fecha determinada 3. El administrador ingresa la fecha y le notifica al sistema.
2. El sistema le pide al administrador la fecha de la cual desea ver los logs de auditoría. 4. El sistema lee del archivo de la fecha indicada los logs, los interpreta y despliega gráficamente.
Caminos de Excepción: Error al leer el archivo, archivo no existe. El sistema deberá notificar al administrador en caso de que se presente alguno de estos acontecimientos.
Puntos de Extensión: Triggers: Suposiciones: Los archivos de logs no se han cambiado de lugar en el disco, ni se han
eliminado. Pre-condiciones: True Post- Condiciones: Se muestra la información de los logs de auditoría para una fecha dada. Autor: Diego L. Maldonado Fecha: Mayo de 2003
6.4. DISEÑO Y ARQUITECTURA
6.4.1. Diagrama de componentes La aplicación se dividió en componentes según las grandes categorías de funcionalidad que se encontraron en el diseño. Se consideró conveniente agrupar estos componentes por funcionalidad para permitir un desarrollo y arquitectura más claros.
ISC-2003-1-24
57
Lector biométrico
Aplicación Cliente
Aplicación Servidor
Proveedor Servicios Biométricos (BSP)Implementacion
BioAPI
Servidor LDAP
TCP/IP
BioAPI
BioAPI
manejador Autenticacion
manejador Biométricos
llamado a métodos
llamado a métodos
LDAP
puente bioAPI - Java
llamado a métodos
BioAPI
Descripción de componentes: Aplicación servidor: Representa a la aplicación del lado del servidor, la cual ofrece las funciones de administración de usuarios, manejo de medidas biométricas y auditoría. Aplicación cliente: Parte del sistema que hace solicitud de llamados remotos de autenticación al servidor. Manejador autenticación: Componente de la aplicación servidor que maneja las funciones que administran los datos de la aplicación, es el encargado de realizar los llamados necesarios al servidor de directorios LDAP para realizar consultas, inserciones y eliminaciones sobre la base de datos. Manejador biométricos: Componente de la aplicación encargado del manejo de los datos biométricos. Servidor LDAP: Representa al servidor de directorios LDAP en el cual se está realizando la persistencia de la información.
ISC-2003-1-24
58
Puente bioAPI - Java: Representa un componente que sirve como conector entre la implementación del bioAPI que es una librería hecha en C, ésta tiene una interfaz de llamados a métodos establecida, y el manejador de biométricos que está hecho en Java. Implementación bioApi: Librería dll elaborada en C para Win 32 que representa una implementación a la especificación del estándar bioAPI para biométricos. Proveedor servicios biométricos: Aplicación que controla el dispositivo biométrico conectado, ésta deberá seguir la especificación del bioAPI para que la comunicación se pueda realizar. Lector biométrico: Dispositivo lector de las muestras biométricas
ISC-2003-1-24
59
6.4.2. Diagrama de clases
Servidor(LDAP)
Servidor Sistema de Autenticacion por Biometricos
Cliente Sistema Autenticación por biométricos
direccionServidor1 0..*1 0..*
solicita autenticacion a
Interfaz Gráfica (GUI)
1
1
1
1
despliega a traves de
manejadorLogs
escribirEntradaLog()leerLogsFecha()getColumnasLogActual()getFilasLogActual()
Medida Autenticación
datoBiometricoidBsp
puenteBioApi
inicializarBioApi()listarBsps()enroll()verify()hayError()getError()
Manejador biométricos
iniciarlizarBioapi()listarBsps()alistar()verificar()existeError()getError()
1
1
1
1accede al bioapi a traves de
FachadaidAdminpasswdAdmin
Fachada()srvAgregarDependencia()srvAgregarNivel()srvAgregarPerfil()srvAgregarUsuario()srvAutenticar()srvBuscarPerfil()srvBuscarUsuario()srvBuscarUsuarioCod()srvCargarLogsFecha()srvEliminarDependencia()srvEliminarNivel()srvEliminarPerfil()srvEliminarUsuario()srvEnroll()srvEscribirEntradaLog()srvListarBspsInstalados()srvListarDependencias()srvListarNiveles()srvListarPerfiles()srvModificarDependencia()srvModificarPerfil()srvModificarUsuario()srvGetColumnasLogActual()srvGetFilasLogActual()
1
1
1
1llama a
11 realiza auditoria a traves de
1
1
1
1
gestiona info. biométrica a traves de
Manejador AutenticaciónldapUserldapUrlLdapPassldapContext
adminLog()agregarDependencia()agregarMedida()agregarNivelSeg()agregarPerfil()agregarUsuario()buscarDependencia()buscarNivel()buscarPerfil()buscarUsuarioCodigo()buscarUsuarioNombre()eliminarDependencia()eliminarNivel()eliminarPerfil()eliminarUsuario()listarDependencias()listarNiveles()listarPerfiles()modificarDependencia()modificarPerfil()modificarUsuario()setValores()buscarVariables()init()writeConfig()manejadorAutenticacion()
1
1
1
1gestiona usuarios a traves de
Dependencianombredescripcion
Usuarionombrecodigocontraseñadependenciaperfildescripción
agregarMedida()getMedida()
0..*
1
0..*
1
se identifica por
1
1
1
1
manejado por
11
pertenece a
NivelSeguridad
PerfilnombrenivelSeguridaddescripcion11tiene 11 11
esta relacionado a
ISC-2003-1-24
60
El diagrama de clases de implementación muestra las clases de la aplicación y las asociaciones que hay entre ellas. Este diagrama representa las clases que han de implementarse y la forma como se comunican entre ellas. Clase Servidor Sistema de Autenticación por biométricos Esta clase representa la aplicación del lado del servidor. Esta busca modelar la parte del servidor como un todo, es por esto que no se le asocia ningún método ni atributo. En el código del piloto esta clase representa a la clase aplicación_biométricos. Ella tiene el método main de la aplicación y se encarga de lanzar la interfaz gráfica para interacción con el usuario. Clase Interfaz gráfica (GUI) Esta clase modela toda la interfaz gráfica utilizada para mostrar la información al usuario. En la implementación ésta clase representa conceptualmente a todas las ventanas, menús y despliegues que se utilicen para que el usuario pueda interactuar con el sistema. En el código del piloto se utiliza una ventana principal, sub-ventanas y diálogos. Cada una de las cuales representa una clase diferente. La ventana principal se representa en la clase framePrincipal, en ella se muestra la mayoría de las funcionalidades de la aplicación. Las clases Dialog sirven de apoyo, para brindar mayor claridad al usuario en el ingreso de los datos. Existen Dialog para ingreso de la información de configuración del servidor, para consultar los logs y para que el administrador se autentique al iniciar la aplicación. Clase Fachada La clase fachada ofrece las funciones completas para los casos de uso de la aplicación, como su nombre lo dice representa una “fachada” a la aplicación, ella establece un punto de entrada al kernel de la aplicación para que se pueda cambiar la visualización de la aplicación de manera transparente. En el desarrollo del modelo cliente – servidor se consideró apropiado por eficiencia tener una versión de la fachada mas restringida llamada fachadaServidor del lado del servidor, para atender las solicitudes de autenticación realizadas por los clientes. Esta clase se crea por razones de ahorro en recursos en la máquina del servidor, ya que se crea una instancia por cada solicitud hecha por los clientes, para atenderlos más eficientemente. De manera similar, se tiene una clase fachadaCliente que realiza las solicitudes de autenticación al servidor.
ISC-2003-1-24
61
Clase Manejador autenticación Esta clase se encarga de manejar la funcionalidad de administración de la información, ella implementa los métodos que se encargan de la comunicación con el servidor de directorios LDAP. A través de ella se realizan las consultas, actualizaciones, inserciones y eliminaciones de datos en el repertorio de información. Clase Manejador biométricos El manejador de biométricos ofrece una forma de llamado a métodos para el manejo de la información biométrica en el lenguaje que se desarrolló la aplicación (Java). Esta clase sirve para que el resto de la aplicación pueda llamar a los servicios biométricos necesarios de una manera familiar, esto además con el objetivo de proporcionar escalabilidad y modularidad a la aplicación. Esta clase utiliza JNI para realizar llamados a métodos en C y ofrecer una traducción en tipos de información manejada entre los dos lenguajes, ya que la clase puenteBioApi se implementó en este lenguaje para permitir realizar llamados directamente al BioAPI necesarios en la comunicación con el dispositivo biométrico. Clase Manejador Logs En ella se maneja toda la funcionalidad de escritura y lectura de los archivos de logs generados por la aplicación con fines de auditoría. Clase Puente bioApi Esta clase representa la necesidad de realizar una conexión entre los dos lenguajes de programación que se van a utilizar en la aplicación. Esta clase realiza los llamados a la implementación del BioApi hecha en C e implementa los métodos que el resto de la aplicación necesita para satisfactoriamente interactuar con el dispositivo biométrico, retornando y recibiendo parámetros que se puedan interpretar de un lenguaje al otro. Esta clase se apoya en la interfaz JNI para realizar la comunicación con la clase Manejador biométricos y ofrecer la funcionalidad que ésta requiera. Clase Usuario Esta clase modela la información y acciones de un usuario del sistema para propósitos de autenticación y gestión de usuarios en un sistema.
ISC-2003-1-24
62
Cada usuario tiene una información básica con la cual se identifica. El usuario posee datos básicos que lo identifican ante el sistema, y que adicionalmente lo clasifican dentro de la organización. Clase Medida Autenticación Esta clase sirve para representar la información biométrica con la cual se identifica a un usuario. Dentro de la aplicación la información biométrica tiene dos atributos que la describen: la identificación del proveedor de servicios biométricos que generó la muestra y que sabe como interpretar la información almacenada en la base de datos, y el dato biométrico en si, o plantilla generada en el momento de la captura para almacenamiento posterior. Clase Dependencia Esta clase en el mundo representa a la dependencia a la cual está vinculado el usuario. Para la aplicación se consideró relevante sólo una descripción de ella, ya que el propósito principal es para catalogar y organizar a los usuarios. Para la implementación se consideró más eficiente y pertinente con el modelo de directorios, representarla como una entrada de directorio con su descripción como atributo sin un objeto en Java que la represente. Sin embargo la utilización de directorios permite que si se considera conveniente en alguna implementación tener un objeto asociado, se pueda hacer. Clase Nivel de seguridad Esta clase representa los niveles de seguridad que se desean tener dentro del sistema, clasificándolos en alto, medio, bajo, o como se considere conveniente en la organización. Esta clase no ofrece ninguna funcionalidad, y sirve únicamente para tener niveles de seguridad establecidos que se le puedan asignar al usuario, es por esto que se consideró conveniente representarla en una entrada de directorio. Clase perfil Esta clase sirve para modelar los perfiles de usuario dentro de la organización. Cada perfil tiene un nivel de seguridad asociado y una descripción.
ISC-2003-1-24
63
Esta clase también se consideró conveniente representarla en una entrada de directorios, siguiendo la estructura de directorios, y aprovechando las ventajas en eficiencia que representa.
6.4.3. Diagramas de secuencia A continuación se presentan los diagramas de secuencia por caso de uso de la aplicación, que muestran la interacción entre las clases que componen el sistema.
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
: Dependencia
srvAgregarDependencia(String, String)
agregarDependencia(String, String)
rebind(String, dependencia)
Agregar dependencia
Dependencia(String, String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Manejador biométricos
: puenteBioApi : Usuario : Servidor directorios (LDAP)
: Medida Autenticación
srvEnroll(String, String)
buscarUsuarioCodigo(String)
alistar(String, Integer)
enroll(Integer, Byte[])
tipoBiométrico(String, Byte[])
agregarMedida(String, Byte[])
rebind(String, usuario)
Agregar medida biométrica
ISC-2003-1-24
64
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: NivelSeguridad : Servidor directorios (LDAP)
srvAgregarNivel(String)
agregarNivelSeg(String)
NivelSeguridad(String)
rebind(String, nivelSeguridad)
Agregar nivel de seguridad
: Interfaz Gráfica (GUI)
: Manejador Autenticación
: Fachada : Perfil : Servidor directorios (LDAP)
srvAgregarPerfil(Sring, String, String)
agregarPerfil(String, String, String)
Perfil(String, String, String)
rebind(String, Perfil)
Agregar perfil
ISC-2003-1-24
65
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Manejador biométricos
: puenteBioApi : Usuario
srvAutenticar(String, String)
buscarUsuarioCodigo(String)
getMedida(String)
verificar(String, String, Byte[])
verify(Integer, Byte[])
Autenticar usuario
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
srvBuscarUsuario(String)
buscarUsuarioCodigo(String)
search(String)
BuscarUsuario por código
ISC-2003-1-24
66
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
BuscarUsuario por nombre
srvBuscarUsuario(String)
buscarUsuarioNombre(String)
search(String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
srvEliminarDependencia(String)
eliminarDependencia(String)
unbind(String, String)
Eliminar dependencia
ISC-2003-1-24
67
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
Eliminar nivel seguridad
srvEliminarNivel(String)
eliminarNivel(String)
unbind(String, String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
Eliminar perfil
srvEliminarPerfil(String)
eliminarPerfil(String)
unbind(String, String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
Eliminar usuario
srvEliminarUsuario(String)
eliminarUsuario(String)
unbind(String, String)
ISC-2003-1-24
68
: Interfaz Gráfica (GUI)
: Fachada : manejadorLogs
srvEscribirEntradaLog(String, String, String, String)
escribirEntradaLog(String, String, String, String)
Generar nueva entrada en log
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
: Usuario
Ingresar usuario nuevo
srvAgregarUsuario(String, String, String, String, String, String)
agregarUsuario(String, String, String, String, String, String)
rebind(String, Usuario)
Usuario(String, String, String, String, String, String)
: Interfaz Gráfica (GUI)
: Fachada : manejadorLogs
Leer logs fecha
srvCargarLogsFecha(String)
leerLogsFecha(String)
ISC-2003-1-24
69
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
: Dependencia
Modificar dependencia
srvModificarDependencia(String, String)
modificarDependencia(String, String)
rebind(String, dependencia)
setDescripcion(String)
buscarDependencia(String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
: Usuario
Modificar usuario
srvModificarUsuario(String, String, String, String, String, String)
modificarUsuario(String, String, String, String, String, String)
buscarUsuarioCodigo(String)
rebind(String, Usuario)
setNombre(String)
setContraseña(String)
setDependencia(String)
setPerfil(String)
setDescripcion(String)
ISC-2003-1-24
70
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Servidor directorios (LDAP)
: Perfil
Modificar perfil
srvModificarPerfil(String, String, String)
modificarPerfil(String, String, String)
buscarPerfil(String)
rebind(String, perfil)
setDescripcion(String)
setNivel(String)
: Interfaz Gráfica (GUI)
: Fachada : Manejador Autenticación
: Manejador biométricos
: puenteBioApi : Usuario : Servidor directorios (LDAP)
: Medida Autenticación
Modificar/reasignar medida biométrica
srvEnroll(String, String)
buscarUsuarioCodigo(String)
alistar(String, Integer)
enroll(Integer, Byte[])
agregarMedida(String, Byte[])
rebind(String, usuario)
tipoBiométrico(String, Byte[])
getMedida(String)
6.4.4. Estructura de información adicional utilizada
6.4.4.1. Estructura de información biométrica La especificación del bioApi establece un estándar que debe tener la información biométrica para que ésta se pueda intercambiar exitosamente entre las aplicaciones que siguen la especificación.
ISC-2003-1-24
71
En el proyecto el tipo de información de la cual se hace persistencia es la estructura que contiene el dato de las muestras biométricas tomadas y que han sido procesadas en información utilizable; que contenga sólo información relevante y pueda ser utilizada en las comparaciones. Este tipo de información es al que se refieren en el BioApi como BIR (Biometric Identification Record). En ella se guarda un encabezado de la información en el que se describe la longitud de la información biométrica, el tipo de información biométrica almacenada, el formato utilizado, la calidad de la muestra, el propósito del dato biométrico y el tipo de tecnología biométrica utilizada. El BIR contiene adicionalmente el dato y una firma opcional del proveedor de servicios biométricos que generó esta información. BioAPI_BIR typedef struct bioapi_bir {
BioAPI_BIR_HEADER Header; BioAPI_BIR_BIOMETRIC_DATA_PTR BiometricData; /* longitud indicada en el header */ BioAPI_DATA_PTR Signature; /* NULL si no existe firma; la longitude es inherente en este tipo */
} BioAPI_BIR, *BioAPI_BIR_PTR; BioAPI_BIR_HEADER typedef struct bioapi_bir_header {
uint32 Length; /* longitud del header + Opaque Data */ BioAPI_BIR_VERSION HeaderVersion; BioAPI_BIR_DATA_TYPE Type; BioAPI_BIR_BIOMETRIC_DATA_FORMAT Format; BioAPI_QUALITY Quality; BioAPI_BIR_PURPOSE Purpose; BioAPI_BIR_AUTH_FACTORS FactorsMask;
} BioAPI_BIR_HEADER, *BioAPI_BIR_HEADER_PTR;
6.4.4.2. Estructura de información de logs Para hacer auditoría sobre las acciones que se realizan en la aplicación, se escribe un archivo por cada fecha. El nombre del archivo está compuesto de un prefijo log acompañado de la fecha en la que suceden las acciones descritas en formato día-mes-año, por ejemplo: log_14-05-2003. Dentro de éste archivo existe una entrada diferente para cada acción realizada en el sistema. En ella se consideró relevante tener principalmente 4 datos relevantes:
ISC-2003-1-24
72
• La fecha de la acción, ésta se supone que es la misma que se encuentra en el nombre del archivo, pero se almacena adicionalmente como medida de seguridad a la posible alteración de información indeseada.
• La acción realizada, esto representa una cadena que describe la funcionalidad de la aplicación que el usuario invocó.
• La identificación del usuario al que se le quiso hacer la autenticación, o si es una acción del administrador, del administrador logueado en el momento.
• La dirección ip de la cual se hace la solicitud de autenticación, en caso de realizarse desde la misma aplicación servidor, se pone localhost.
Ejemplo: log_14-05-2003.lsab 14-05-2003|verificar|80435143|localhost 14-05-2003|verificar|52432163|localhost
6.4.4.3. Definición de esquemas y atributos adicionales
Todos los servidores de directorios deben tener ciertas clases y atributos de directorio predefinidos, algunos proveedores de servidores proporcionan definiciones adicionales que ellos han considerado relevantes para los usuarios de este servidor. Pero esto no implica que los usuarios y desarrolladores de aplicaciones se deban conformar con las clases y atributos establecidos inicialmente, los sistemas de directorios ofrecen la capacidad de crear nuevas clases y atributos que se desee, siempre y cuando cumpla con una especificación y reglas necesarias. Para crear nuevas clases y atributos que puedan ser almacenadas en un servicio de directorios, es necesario crear un esquema con las especificaciones deseadas, y luego indicarle al servidor de directorios que cargue este esquema al hacer inicio. A continuación se expone el esquema creado en el que se tienen las especificaciones de las clases y atributos creados para el sistema. Nivel Este atributo representa el identificador de la clase Nivel de Seguridad, hereda del atributo name para facilidad en las búsquedas y comparaciones. attributetype ( 1.1.2.1.1 NAME 'nivel' DESC 'nivel de seguridad de un usuario' SUP name ) Perfil
ISC-2003-1-24
73
Este atributo representa el identificador de la clase Perfil de Usuario, hereda del atributo name para facilidad en las consultas y por poder representarse como subclase de ésta. attributetype ( 1.1.2.1.2 NAME 'perfil' DESC 'perfiles de usuario definidos en el sistema' SUP name ) Niveles de Seguridad Esta clase tiene un único atributo con un identificador de tipo nivel. Su principal objetivo es de clasificación de usuarios. Esta clase representa un nuevo objectClass para ser almacenada como nueva entrada en el directorio. objectclass ( 1.1.2.2.1 NAME 'nivelSeguridad' DESC 'niveles de seguridad del sistema de autenticacion' MUST nivel ) Perfil de usuario Esta clase representa los perfiles de usuario. Tiene como atributos necesarios el identificador del perfil de tipo perfil, el nivel de seguridad de tipo nivel y tiene un atributo opcional que indica la descripción del Perfil de Usuario de tipo description. objectclass ( 1.1.2.2.2 NAME 'perfilUsuario' DESC 'perfiles de usuario existentes en el sistema' MUST ( perfil $ nivel ) MAY description ) Biometric Person Representa la información del usuario dentro de la organización. Esta clase es subclase de inetOrgPerson, clase definida dentro de las clases predeterminadas del servicio de directorios. Tiene un atributo adicional indicando el perfil que tiene el usuario del sistema de tipo perfil. objectclass ( 1.1.2.2.3 NAME 'biometricPerson' DESC 'usuario en el sistema de autenticacion por biometricos' SUP inetOrgPerson MUST perfil )
6.5. Interfaz y visualización de la aplicación La interfaz gráfica de la aplicación se realizó utilizando principalmente las librerías Awt y Swing de Java. El modelo utilizado es el de ventanas, para comodidad y familiaridad del usuario de la aplicación. La metáfora de interfaz utilizada es la de una carpeta múltiple con pestañas que separan y clasifican el contenido. Esta metáfora se sigue en la aplicación presentando las opciones principales de la aplicación servidor a través de pestañas (tabs), las opciones adicionales se acceden a través de un menú ubicado en la parte superior.
ISC-2003-1-24
74
La aplicación cliente una sencilla interfaz de una única ventana en la cual se ingresan los datos para solicitud de autenticación y se despliega el resultado de la misma.
6.6. Atributos del sistema Identificador: Sistema de autenticación único basado
en biométricos
Nombre del documento Requerimientos técnicos
Estado del documento: Final
Responsables Diego L. Maldonado
DOCUMENTO DE DEFINICIÓN DE REQUERIMIENTOS TÉCNICOS
HERRAMIENTAS Y DESARROLLO
IDENTIFICADOR:
RT1
Nombre: Interoperabilidad
DESCRIPCIÓN : CAPACIDAD DE LA APLICACIÓN DE SER EJECUTA DA EN PLATAFORMAS DIFERENTES.
CRITERIOS DE ACEPTACIÓN
LA APLICACIÓN DEBERÁ SER PORTABLE A OTRAS PLATAFORMAS CON UN NÚMERO PEQUEÑO DE ALTERACIONES Y ADAPTACIONES AL CÓDIGO. ESTO SE GARANTIZARÁ MEDIANTE LA UTILIZACIÓN DE JAVA COMO LENGUAJE DE PROGRAMACIÓN Y CON LA UTILIZACIÓN DE LAS INTERFACES DE PROGRAMACIÓN ESTÁNDARES E INDEPENDIENTES DE PLATAFORMA. IDENTIFICADOR:
RT2
Nombre: Persistencia en servicio de directorios
DESCRIPCIÓN : SISTEMA QUE SE UTILIZARÁ PARA REALIZAR LA PERSISTENCIA DE LA INFORMACIÓN MANEJADA EN LA APLICACIÓN.
ISC-2003-1-24
75
CRITERIOS DE ACEPTACIÓN
LA PERSISTENCIA DE LA INFORMACIÓN MANEJADA EN LA APLICACIÓN SE DEBERÁ REALIZAR EN UN SERVICIO DE DIRECTORIOS LDAP PARA PERMITIR MAYOR VELOCIDAD EN LAS CONSULTAS DE LA INFORMACIÓN. IDENTIFICADOR:
RT3
Nombre: Multimodalidad de tecnología biométrica
DESCRIPCIÓN : CAPACIDAD PARA SOPORTAR AUTENTICACIÓN DE USUARIOS A TRAVÉS DE DIFERENTES TECNOLOGÍAS BIOMÉTRICAS.
CRITERIOS DE ACEPTACIÓN
LA APLICACIÓN PODRÁ SER CAPAZ DE SOPORTAR LA AUTENTICACIÓN DE UN USUARIO POR DIFERENTES TECNOLOGÍAS BIOMÉTRICAS. LAS TECNOLOGÍAS QUE SE PUEDEN UTILIZAR SON AQUELLAS QUE SEAN COMPATIBLES CON EL ESTÁNDAR BIOAPI. IDENTIFICADOR:
RT4
Nombre: Soporte cliente - servidor
DESCRIPCIÓN : SOPORTE PARA OFRECER FUNCIONALIDAD DE CLIENTE-SERVIDOR .
CRITERIOS DE ACEPTACIÓN
SE AUTENTICA UN USUARIO EN UNA MÁQUINA DIFERENTE A LA QUE TIENE EL SERVIDOR DE AUTENTICACIÓN, LA COMUNICACIÓN ENTRE LOS DOS SE DEBERÁ PODER REALIZAR A TRAVÉS DE LA RED. IDENTIFICADOR:
RT5
Nombre: Utilización de herramientas libres
DESCRIPCIÓN : UTILIZACIÓN DE HERRAMIENTAS LIBRES PARA EL DESARROLLO Y DE APOYO A LA APLICACIÓN .
CRITERIOS DE ACEPTACIÓN
SI EXISTEN HERRAMIENTAS LIBRES PARA LA FUNCIONALIDAD REQUERIDA, SE UTILIZARÁN EN EL DESARROLLO DEL PROYECTO CON EL FIN DE MINIMIZAR LOS COSTOS EN LOS CUALES SE DEBE INCURRIR A LA HORA DE IMPLEMENTAR LA APLICACIÓN. LAS HERRAMIENTAS DE APOYO QUE EN EL MOMENTO DE LA IMPLEMENTACIÓN PUDEN NO SER LIBRES SON: EL SERVIDOR LDAP Y EL SERVIDOR DE TECNOLOGÍA BIOMÉTRICA RELACIONADO AL DISPOSITIVO. IDENTIFICADOR:
RT6
Nombre: Plataforma de desarrollo
DESCRIPCIÓN : PLATAFORMA EN LA CUAL DEBERÁ DESARROLLARSE Y EJECUTARSE LA APLICACIÓN .
ISC-2003-1-24
76
CRITERIOS DE ACEPTACIÓN
SE IMPLEMENTARÁ EN WINDOWS INICIALMENTE, YA QUE LA IMPLEMENTACIÓN DEL BIOAPI ESTÁ HECHA PARA WINDOWS, SIN EMBARGO DEBERÁ PODER SER PORTABLE A OTRAS PLATAFORMAS A MEDIDA QUE LA ORGANIZACIÓN DEL BIOAPI GENERE IMPLEMENTACIONES PARA OTRAS PLATAFORMAS QUE CUMPLAN CON LA ESPECICACIÓN. IDENTIFICADOR:
RT7
Nombre: Lenguaje de programación
DESCRIPCIÓN : LENGUAJE DE PROGRAMACIÓN EN EL CUAL SE CODIFICARÁ LA APLICACIÓN .
CRITERIOS DE ACEPTACIÓN
SE UTILIZARÁ EL LENGUAJE JAVA SIGUIENDO ESPECIFICACIONES DE J2SE PARA JDK1.4.0 EN ADELANTE. ALGUNOS MÓDULOS SERÁN HECHOS EN C, LOS CUALES UTILIZARÁN LIBRERÍAS ESTÁNDAR Y LAS NECESARIAS PARA LLAMAR FUNCIONES DEL BIOAPI. VISUALIZACIÓN
IDENTIFICADOR:
RV1
Nombre: Interfaz de servidor de autenticación
DESCRIPCIÓN : INTERFAZ QUE SE OFRECERÁ PARA LA INTERACCIÓN LA PARTE DEL SERVIDOR DE AUTENTICACIÓN.
CRITERIOS DE ACEPTACIÓN
LA APLICACIÓN OFRECERÁ UNA INTERFAZ CLARA, BASADA EN EL MODELO DE VENTANAS QUE PROPORCIONAN LAS LIBRERÍAS DE APOYO A JAVA, COMO SWING, AWT PARA LAS FUNCIONES QUE DEBE PROPORCIONAR EL SERVIDOR DE AUTENTICACIÓN, EN EL CUAL PUEDA HACER LA ADMINISTRACIÓN DE LOS USUARIOS CORRESPONDIENTE. IDENTIFICADOR:
RV2
Nombre: Interfaz del cliente
DESCRIPCIÓN : INTERFAZ OFRECIDA PARA LA INTERACCIÓN DEL CLIENTE CON LA APLI CACIÓN PARA REALIZAR REQUERIMIENTOS DE
AUTENTICACIÓN . CRITERIOS DE ACEPTACIÓN
LA APLICACIÓN OFRECERÁ UNA INTERFAZ CLARA, BASADA EN LA ESTRUCTURA DE VENTANAS QUE PROPORCIONAN LAS LIBRERÍAS DE APOYO A JAVA, COMO SWING, AWT PARA LA PETICIÓN DE AUTENTICACIÓN DESDE EL CLIENTE. IDENTIFICADOR:
RV3
Nombre: Interfaz para captura de muestra biométrica
DESCRIPCIÓN : INTERFAZ PROPORCIONADA PARA LA CAPTURA DE INFORMACIÓN BIOMÉTR ICA.
ISC-2003-1-24
77
CRITERIOS DE ACEPTACIÓN
LA INTERFAZ QUE SE BRINDARÁ PARA LA TOMA DE LA MUESTRA DEL DATO BIOMÉTRICO SERÁ PROPORCIONADA POR EL PROVEEDOR DE LA TECNOLOGÍA BIOMÉTRICA UTILIZADA. LA APLICACIÓN CEDERÁ EL CONTROL DE LA INTERFAZ AL PROVEEDOR DE SERVICIOS BIOMÉTRICOS PARA QUE ÉSTE MUESTRE LA INTERFAZ QUE CONSIDERA CONVENIENTE. INTERACCIÓN
IDENTIFICADOR:
RI1
Nombre: Interacción gráfica
DESCRIPCIÓN : FORMA DE INTERACCIÓN ENTRE EL USUARIO Y LA INTERFAZ GRÁFICA DE LA APLICACIÓN .
CRITERIOS DE ACEPTACIÓN
LA INTERACCIÓN CON LA APLICACIÓN SE HARÁ MEDIANTE EL TECLADO Y MOUSE, QUE LE SERVIRÁN AL USUARIO PARA REALIZAR ACCIONES SOBRE LA INTERFAZ DE VENTANAS, SOBRE LOS BOTONES Y CAMPOS. IDENTIFICADOR:
RI2
Nombre: Interacción dispositivo biométrico
DESCRIPCIÓN : INTERACCIÓN PRESENTADA ENTRE EL USUARIO Y EL DISPOSITIVO DE TOMA DE MUESTRA BIOMÉTRICA.
CRITERIOS DE ACEPTACIÓN
CUANDO LA APLICACIÓN INDIQUE, EL USUARIO DEBERÁ PODER INTERACTUAR CON EL DISPOSITIVO BIOMÉTRICO PARA LA CAPTURA DE LA MUESTRA. OPERACIÓN
IDENTIFICADOR:
RO1
Nombre: Apoyo de configuración por ventana y archivo
DESCRIPCIÓN : ALTERNATIVAS PROPORCIONADAS POR LA APLICACIÓN PARA CONFIGURAR LOS DATOS DEL SERVIDOR. CRITERIOS DE ACEPTACIÓN
EN CASO DE NO EXISTIR EL ARCHIVO DE CONFIGURACIÓN DEL SERVIDOR DE DIRECTORIOS QUE SE CARGA POR DEFECTO, LA APLICACIÓN PROPORCIONARÁ UNA VENTANA PARA INGRESAR DICHOS PARÁMETROS QUE AL SER MODIFICADOS POR ESTE MEDIO SON MODIFICADOS EN EL ARCHIVO.
ISC-2003-1-24
78
DESEMPEÑO
IDENTIFICADOR:
RD1
Nombre: Volumen de usuarios
DESCRIPCIÓN : EL VOLUMNEN DE USUARIOS QUE SE PUEDE MANEJAR EN LA APLICACIÓN. CRITERIOS DE ACEPTACIÓN
LA APLICACIÓN NO GENERARÁ RESTRICCIONES ADICIONALES SOBRE EL NÚMERO DE USUARIOS QUE SE PUEDEN ALMACENAR EN LA BASE DE DATOS, ESTA CAPACIDAD DEPENDERÁ DE LAS CARACTERÍSTICAS DEL SERVIDOR LDAP. IDENTIFICADOR:
RD2
Nombre: Tiempo de respuesta
DESCRIPCIÓN : EL TIEMPO DE RESPUESTA DE LA APLICACIÓN . CRITERIOS DE ACEPTACIÓN
EL TIEMPO DE RESPUESTA EN QUE LA APLICACIÓN VALIDARÁ LA IDENTIFICACIÓN DE UN USUARIO NO SOBREPASARÁ LOS 5 SEG, PARA UN NÚMERO DE CLIENTES LIMITADO. EL TIEMPO DE RESPUESTA SE PUEDE VER AFECTADO CON LA VELOCIDAD DE TRANSMISIÓN DE INFORMACIÓN EN LA RED Y CON LA SOBRE CARGA DE USUARIOS HACIENDO PETICIONES CONCURRENTES. IDENTIFICADOR:
RD3
Nombre: Peticiones concurrentes de clientes
DESCRIPCIÓN : NÚMERO DE PETICIONES DE CLIENTES CONCURRENTES A UN MISMO SERVIDOR SOPORTADOS SIN QUE LA APLICACIÓN TOME UN COMPORTAMIENTO INDETERMINADO. CRITERIOS DE ACEPTACIÓN
UN SERVIDOR PODRÁ SOPORTAR UN NÚMERO LÍMITE DE 20 USUARIOS CONCURRENTES HACIENDO PETICIONES SIMULTÁNEAS DE AUTENTICACIÓN SIGUIENDO EL COMPORTAMIENTO ESPERADO. SI EL NÚMERO DE CLIENTES SOBREPASA ESTE NÚMERO, NO SE GARANTIZA EL FUNCIONAMIENTO ADECUADO DE LA APLICACIÓN. COMPATIBILIDAD
IDENTIFICADOR:
RC1
Nombre: Compatibilidad con servidores de servicios
biométricos DESCRIPCIÓN : COMPATIBILIDAD CON DIFERENTES FABRICATES Y PROVEEDORES DE SERVICIOS BIOMÉTRICOS.
ISC-2003-1-24
79
CRITERIOS DE ACEPTACIÓN
LA COMPATIBILIDAD QUE TIENE LA APLICACIÓN CON DIFERENTES FABRICANTES, PROVEEDORES Y DISPOSITIVOS DE SERVICIOS BIOMÉTRICOS SE BASAN EN LA COMPATIBILIDAD QUE ÉSTOS PRESENTEN CON LA ESPECIFICACIÓN DEL BIOAPI. IDENTIFICADOR:
RC3
Nombre: Formato de la información de usuarios
DESCRIPCIÓN : ESTRUCTURA QUE PRESEN TA LA INFORMACIÓN DE USUARIOS DENTRO DEL DIRECTORIO. CRITERIOS DE ACEPTACIÓN
LA INFORMACIÓN DE USUARIOS ALMACENADA EN EL SERVICIO DE DIRECTORIOS SIGUE UN ESQUEMA DE DIRECTORIOS Y CON ATRIBUTOS, QUE HACE POSIBLE QUE CUALQUIER APLICACIÓN QUE TENGA PERMISOS SOBRE EL SERVICIO DE DIRECTORIOS, PUEDA INTERPRETAR LA MAYORÍA DE LA INFORMACIÓN ACERCA DE UN USUARIO. ROBUSTEZ Y RECUPERACIÓN DE ERROR
IDENTIFICADOR:
RR1
Nombre: Manejo de fallas en el servidor de directorios
DESCRIPCIÓN : COMPORTAMIENTO DEL SISTEMA ANTE LA PRESENCIA DE UNA FALLA EN EL SERVIDOR DE DIRECTORIOS CRITERIOS DE ACEPTACIÓN
SI SE PRESENTA UNA FALLA EN EL SERVIDOR LDAP, LA APLICACIÓN INFORM A DE DICHO ERROR Y NO OFRECE LA FUNCIONALIDAD REQUIERIDA HASTA ESTABLECER UNA NUEVA CONFIGURACIÓN DE SERVIDOR O REINICIAR LA APLICACIÓN. IDENTIFICADOR:
RR2
Nombre: Manejo de situaciones anormales en el transcurso
de la ejecución de la aplicación DESCRIPCIÓN : COMPORTAMIENTO DEL SISTEMA CUANDO ALGUNA SOLICITUD DE DE ALGUNA TAREA NO SE LOG RA REALIZAR CRITERIOS DE ACEPTACIÓN
EN CASODE PRESENTARSE UNA SITUACIÓN ANORM AL O QUE NO PERMITA LA REALIZACIÓN EXITOSA DE ALGUNA TAREA, LA APLICACIÓN INFORM A DEL ERROR OCURRIDO Y VUELVE AL ESTADO ANTERIOR EN EL CUAL SE ENONTRABA ANTES DE DICHA SOLICITUD.
ISC-2003-1-24
80
MANTENIBILIDAD
IDENTIFICADOR:
RM1
Nombre: Casos de uso
DESCRIPCIÓN : CASOS DE USO DEL SISTEMA CRITERIOS DE ACEPTACIÓN
DE DOCUMENTARÁN LOS CASOS DE USO DE LA APLICACIÓN. ES A ÉSTOS CASOS DE USO PRESENTADOS EN DICHO DOCUMENTO A LOS CUALES EL PROYECTO PRETENDE DAR SOLUCIÓN. IDENTIFICADOR:
RM2
Nombre: Diagramas de clase
DESCRIPCIÓN : DIAGRAMAS DE CLASE DEL DISEÑO DE LA APLICACIÓN CRITERIOS DE ACEPTACIÓN
EXISTE UN DIAGRAMA DE CLASES DE LA APLICACIÓN EN EL CUAL SE PODRÁN VISUALIZAR LAS CLASES QUE COMPONEN EL SISTEMA Y LA MANERA EN QUE ÉSTAS INTERACCIONAN ENTRE SÍ. IDENTIFICADOR:
RM3
Nombre: Diagramas de secuencia
DESCRIPCIÓN : DIAGRAMAS DE SECUENCIA DE LA APLICACIÓN CRITERIOS DE ACEPTACIÓN
SE PRESENTARÁ UN DIAGRAMA DE SECUENCIA DE LA APLICACIÓN PARA ILUSTRAR LA INTERACCIÓN ENTRE LAS DIFERENTES CLASES Y MOSTRAR LA MANERA EN QUE SE COMUNICAN PARA LLEVAR A CABO LOS DIFERENTES CASOS DE USO. IDENTIFICADOR:
RM4
Nombre: Identación
DESCRIPCIÓN : INDENTACIÓN UTILIZADA EN LA CODIFICACIÓN DE LA APLICACIÓN CRITERIOS DE ACEPTACIÓN
TODO EL CÓDIGO GENERADO SERÁ INDENTADO A 4 ESPACIOS. IDENTIFICADOR:
RM5
Nombre: Documentación del código
DESCRIPCIÓN : DOCUMENTACIÓN Y COMENTARIOS PRESENTADOS EN EL CÓDIGO DE LA APLICACIÓN CRITERIOS DE ACEPTACIÓN
EL CÓDIGO ESTÁ COMENTADO CASI EN SU TOTALIDAD PARA FACILITAR EL ENTENDIMIENTO POSTERIOR POR PARTE DE TERCEROS, EL CÓDIGO QUE NO SE COMENTA ES AQUEL QUE NO PRESENTA DIFICULTAD Y/O RELEVANCIA EN EL OBJETIVO PRINCIPAL DEL PROYECTO (P.EJ. INTERFAZ GRÁFICA).
ISC-2003-1-24
81
IDENTIFICADOR:
RM6
Nombre: Modelo de diseño
DESCRIPCIÓN : MODELO EN EL CUAL SE BASA EL DISEÑO DE LA SOLUCIÓN CRITERIOS DE ACEPTAC IÓN
EL PROYECTO BASA SU SOLUCIÓN EN UN MODELO ORIENTADO A OBJETOS EN CASI SU TOTALIDAD, LAS LIBRERÍAS ADICIONALES DESARROLLADAS EN LENGUAJE DIFERENTE A JAVA NO CUMPLEN CON ESTE MODELO DE OBJETOS. CONTROL DE ACCESO
. IDENTIFICADOR:
RA1
Nombre: Restricciones de acceso al servidor
DESCRIPCIÓN : USUARIOS AUTORIZADOS EN EL SERVIDOR DE AUTENTICACIÓN CRITERIOS DE ACEPTACIÓN
EL SERVIDOR DE AUTENTICACIÓN TENDRÁ RESTRINGIDO EL ACCESO A PERSONAS QUE TENGAN EL PERFIL DE ADMINISTRADOR DENTRO DEL SISTEMA. LA VALIDACIÓN DE ÉSTE SE HACE CON CONTRASEÑA A NIVEL LOCAL. IDENTIFICADOR:
RA2
Nombre: Restricciones de acceso al cliente
DESCRIPCIÓN : USUARIOS AUTORIZADOS A ACCEDER EL CLIENTE DE LA APLICACIÓN DE AUTENTICACIÓN CRITERIOS DE ACEPTACIÓN
INICIALMENTE AL CLIENTE DE AUTENTICACIÓN PODRÁ TENER ACCESO CUALQUIER PERSONA QUE FÍSICAMENTE TENGA ACCESO A LA MÁQUINA DONDE SE ESTÉ EJECUTANDO. SERÁ RESPONSABILIDAD DE LOS QUE QUIERAN IMPLEMENTAR EL SISTEMA SI DESEAN ESTABLECER POLÍTICAS DE SEGURIDAD DIFERENTES.
ISC-2003-1-24
82
7. IMPLEMENTACIÓN
7.1. Detalles de implementación Librería dll para implementar Puente bioApi La clase puente_bioApi es muy importante para el desarrollo de la aplicación, ya que a través de ella se invocan directamente los métodos proveídos por la interfaz de programación biométrica (BioApi). Debido a que la implementación de ésta referencia estaba dada en C, para que su llamado fuese realizada por aplicaciones que se desarrollaran en este lenguaje, fue necesario plantear una solución en la cual fuese posible desde la aplicación en Java acceder a estos métodos. La solución que se plantea es desarrollar una librería dll en C, en ella se proporcionan métodos que realizan cierto procesamiento y retornan valores que se puedan interpretar desde el resto de la aplicación desarrollada en Java. La librería dll ofrece una solución satisfactoria al problema, ya que nos brinda funciones ejecutables que pueden ser utilizadas desde cualquier otra aplicación en Windows. Para la interoperabilidad de la aplicación, se hace necesario recompilar el código de la librería para generar una que sea propia del sistema operativo sobre el cual se desea ejecutar la aplicación. Modelo multi hilos La eficiencia y tiempo de respuesta son elementos importantes a considerar en el desarrollo de aplicaciones de autenticación, el tiempo que el usuario está dispuesto a esperar que el sistema le otorgue acceso es limitado. Por esto, se consideró apropiado tener un modelo con varios hilos de ejecución; un hilo de ejecución por cada atención a solicitud de autenticación que el servidor va recibiendo. Esto proporciona una solución al problema de cuello de botella, que se puede generar cuando un servidor atiende múltiples clientes simultáneamente.
ISC-2003-1-24
83
Sin embargo, utilizar un hilo de ejecución de toda la aplicación por cada solicitud de autenticación que se recibe implica un desperdicio de recursos en la máquina donde se ejecuta el servidor. Para esto se creó la clase fachadaServidor mencionada anteriormente, la cual ofrece la funcionalidad necesaria para atender las solicitudes de autenticación únicamente. Esto permite que se instancie un objeto dicha clase en cada hilo de ejecución sin desperdiciar tantos recursos de la máquina. Conexión cliente - servidor La conexión entre el cliente y el servidor también juegan un papel importante en el tiempo de respuesta del sistema, siguiendo un modelo de programación de llamados a procedimientos remotos o algún otro mecanismo por el estilo, se puede tal vez presentar una arquitectura más clara. Sin embargo estas soluciones con ineficientes en cuanto al tiempo de respuesta, ya que se deben utilizar un número mayor de capas en la comunicación. Por estas razones, se consideró que la comunicación por sócalos o sockets era más apropiada para los objetivos y requerimientos del presente sistema. Los clientes se comunican con el servidor a través de los sockets de la librería Net de Java directamente a la dirección ip de la máquina en la cual se encuentra corriendo el servidor, al puerto en el cual éste se encuentre escuchando. El servidor por el otro lado, utiliza la clase ServerSocket de la misma librería para escuchar y esperar las conexiones entrantes de los clientes.
7.2. Herramientas utilizadas
- Servidor LDAP El servidor utilizado en el desarrollo del proyecto fue un servidor OpenLDAP montado sobre un computador con router, habilitando el puerto para conexión remota. Las pruebas se realizaron accediendo a este computador desde otras máquinas. La comunicación de la aplicación hacia el servidor de directorios se realiza a través de la librería javax.naming ofrecida en el JDK1.4.1. - Herramientas de programación Para la construcción de la mayor parte de la aplicación se utilizó JBuilder Personal 8 de Borland Software Corporation.
ISC-2003-1-24
84
Para el módulo desarrollado en C se utilizó Borland C++ Builder 5 de la misma empresa. También se construyó la librería en Visual Studio .Net por razones de depuración. Estas herramientas se utilizaron debido a sus extensas funcionalidades y a la familiaridad que el autor tenía con las herramientas, desarrollado en el transcurso de la carrera. - Depuración La depuración con objeto se realizó con las herramientas de construcción, sin embargo, para la versión final del piloto se espera generar ejecutables y archivos comprimidos (.jar) que faciliten la ejecución por parte del usuario.
7.3. Posibles mejoras futuras La aplicación presenta un piloto inicial a un sistema de autenticación completo. Para implementar un sistema que brinde todas las características que debe tener un sistema de seguridad, se pueden realizar mejoras significativas en atributos del sistema funcionales y no funcionales con el fin de mejorar desempeño, estabilidad y aplicabilidad en un ambiente real. Algunas de las mejoras que se pueden hacer a la aplicación para constituir un sistema de autenticación completo son las siguientes:
- Incremento en la seguridad de transmisión de datos. Para garantizar el transporte seguro de los datos a través de la red, se puede implementar la utilización de SSL en la transmisión de los datos.
- Manejo de carga de usuarios concurrentes. Se recomienda utilizar un modelo de
conection pool con multi threads en el lado del servidor. Esto permite que exista hilo de ejecución atendiendo a cada uno de los clientes que realicen peticiones al servidor, garantizando mayor eficiencia.
- Integración con aplicaciones existentes. Uno de los escenarios en que se utiliza con
mayor frecuencia autenticación es para el acceso a las estaciones de trabajo, ellas utilizan la autenticación por contraseña proporcionada por el sistema operativo para tener acceso a éste. Estas soluciones se pueden mejorar integrando la funcionalidad de la aplicación biométrica con el sistema de autenticación del sistema operativo.
ISC-2003-1-24
85
- Políticas de manejo de logs. Para lograr un manejo exitoso de los logs de auditoría se deben establecer políticas de seguridad que acompañen al sistema, y éste pueda ofrecer los beneficios a las organizaciones de manera satisfactoria.
8. PROBLEMAS ENCONTRADOS
8.1. Obstáculos iniciales en la implementación
- Documentación escasa El campo de aplicaciones que realicen autenticación a través de biométricos presenta la mayoría de los desarrollos de forma propietaria. El BioApi refleja el primer intento real de la industria para ofrecer un estándar, en él se incorpora las características positivas de otros intentos de ofrecer interfaces comunes; como el HAAPI, BAPI, entre otros. Sin embargo, en la industria las soluciones y documentación para desarrollo de aplicaciones se ofrecen a través de paquetes de desarrollo proporcionados por los proveedores de servicios biométricos. Hay paquetes de desarrollo propietarios ofrecidos que dicen ser compatibles con la especificación del BioApi, pero no se pudo tener acceso a ninguno de ellos por cuestiones económicas para estudiarlos. Esto hace que la documentación libre para el desarrollo de aplicaciones, así como ejemplos de aplicaciones sea prácticamente nula. No existe una comunidad de desarrollo de aplicaciones biométricas abierta, que tenga ejemplos y código libre de la que se tenga conocimiento. Por estos motivos, para el desarrollo de la aplicación se basó en el ejemplo que viene en la implementación del BioApi (Sample), disponible en la página de la organización (www.bioapi.org). Este ejemplo esta documentado pobremente, y tiene errores en el proyecto de Microsoft Visual Studio incluido, el cual no compila como viene. Teniendo esto en cuenta, se utilizó como referencia la especificación del BioApi junto con el único código incluido en la implementación de la referencia, para el desarrollo de la clase que hace llamado a los métodos de que utilizan tecnología biométrica.
ISC-2003-1-24
86
- Disponibilidad de dispositivos Para realizar pruebas y éxito de la aplicación no se pudo tener a disposición ningún dispositivo biométrico compatible con el BioApi. Para las pruebas se decidió probar un ejemplo de BSP que viene junto a la implementación del BioApi. - Lenguaje de programación de la implementación de BioApi El lenguaje de programación para el cual está disponible la implementación de BioApi presentó un problema inicial, ya que se deseaba construir la aplicación utilizando Java. Esto hizo que se considerara la utilización de JNI como la solución más adecuada al problema de comunicación entre lenguajes de programación.
8.2. Problemas en la implementación Durante la implementación de la aplicación se presentaron algunos problemas que hacen que el piloto pueda no estar desarrollado con las características plenamente probadas, garantizando su correcto funcionamiento. Debido a las dificultades en las aplicaciones ejemplo, y a las fallas que presenta la información contenida en la implementación del BioApi, las pruebas realizadas no garantizan el funcionamiento completo de la aplicación. Se espera que la comunidad genere más código y ayudas para el desarrollo de aplicaciones que utilicen el estándar, sin necesidad de adquirir ninguno de los paquetes de desarrollo propietarios. Adicionalmente se presentaron problemas en la comunicación y llamado de las funciones nativas desde Java. En el proceso de link de las librerías del bioApi que se requieren para la generación de la librería compartida puenteBioApi, se presentaron inconvenientes que hicieron dudosa la veracidad de la librería generada. Esto hizo que esta funcionalidad de la aplicación no pudiera ser completamente probada.
ISC-2003-1-24
87
9. CONCLUSIONES El problema de la seguridad en las organizaciones ha adquirido mayor importancia a través del tiempo. Las organizaciones se han venido concientizado de la importancia que tiene proteger sus activos para permanecer competitivos en su industria. La información como activo más importante que una empresa posee para mantener la ventaja competitiva, hace que la asignación de recursos destinados a la seguridad de sistemas de información sea ahora más importante en el presupuesto. Los sistemas de autenticación basados en tecnología biométrica han venido demostrando su importancia, ventajas y aceptación en el campo de seguridad informática y se proyecta que reemplacen los sistemas vigentes de utilización de contraseñas en un futuro cercano. El presente proyecto pretende iniciar investigación en el campo de tecnologías biométricas en la universidad, utilizando herramientas libres y estándares biométricos en el desarrollo de las aplicaciones, permitiendo a que la academia realice avances que puedan impulsar industria y desarrollo novedoso en esta área en el país. Durante el desarrollo del proyecto se pudo observar la inmadurez existente en la estandarización de la información utilizada en los diferentes sistemas biométricos, ya que en el segundo semestre de 2002 se oficializó el BioApi como estándar ANSI con propuesta de ser incorporado como estándar ISO a nivel internacional. Por esto, se considera que el momento es muy pertinente para investigar y desarrollar aplicaciones en ésta área, ya que se puede incorporar la tecnología en las organizaciones nacionales y se puede competir a nivel internacional en aplicaciones que utilizan esta tecnología. El desarrollo del piloto permitió ver algunas dificultades actuales en el desarrollo de aplicaciones que se conformen con la interfaz de programación para biométricos, como la inexistencia actual de librerías o interfaces para el desarrollo en Java, lenguaje que ha gozado de una popularidad significativa, y que se va asimilando en la mayoría de las aplicaciones y plataformas existentes. Por esto se diseñó una solución temporal al problema, con la utilización de la librería dll en la aplicación, pero se considera que esta
ISC-2003-1-24
88
solución es temporal hasta que la comunidad de tecnología biométrica incorpore una solución definitiva al problema. El piloto tuvo algunas dificultades para un mejor desarrollo debido a diferentes factores que no permitieron la construcción de un piloto más robusto, pero se considera que lo realizado forma un peldaño importante en la construcción de soluciones de seguridad biométricas. El siguiente paso natural en el desarrollo del presente trabajo es la solución de los problemas encontrados, con lo cual se espera que se logre observar el completo funcionamiento del sistema y se puedan realizar pruebas en ambientes reales, con cargas de usuarios considerables y observar el comportamiento del sistema. En el futuro se espera que se sigan desarrollando aplicaciones en el campo, y se espera que el presente trabajo sirva como punto de partida para que se logren incorporar las mejoras nombradas en el documento, entre otras, y se construya una solución viable y comercialmente competitiva. Se pretende que la presente experiencia les permita a otras personas utilizar la solución planteada para construir soluciones de autenticación y seguridad completas, y generen valor en empresas, en la academia o en las organizaciones en las cuales se implemente.
ISC-2003-1-24
89
10. REFERENCIAS [1] Proyecto 11 de septiembre, El Tiempo. http://eltiempo.terra.com.co/PROYECTOS/Septiembre11/especial/ [2] Biometric Expected Growth, Axis. http://www.axistech.com/expectedG.htm [3] An introduction to biometrics, The Biometric Consortium. http://www.biometrics.org/html/introduction.html [4] Everything You Need to Know About Biometrics, International Biometric Industry Association. http://www.ibia.org/EverythingAboutBiometrics.PDF [5] Biometrics Direct - Secure Biometric Products for Home and Office. http://www.biometricsdirect.com/Web/Biometrics/Biometrics_101.htm [6] Management in an Information Age, Final Project: An introduction to biometrics, Stanford University. http://www.stanford.edu/~bjohara/introduction.htm [7] Biometrics: Who's watching you?, Electronic Frontier Foundation. http://www.eff.org/Privacy/Surveillance/biometrics.php [8] Fingerprint Technology Reports, International Biometric Group. http://www.ibgweb.com/reports/public/reports_finger-scan.html [9] History of fingerprints, Deakin University http://www.deakin.edu.au/forensic/Chemical%20Detective/fingerprint_history.htm [10] Fingerprint Patterns, Ridges and furrows. http://www.ridgesandfurrows.homestead.com/fingerprint.html
ISC-2003-1-24
90
[11] Automated Fingerprint Identification System (A.F.I.S.), Ridges and furrows. http://www.ridgesandfurrows.homestead.com/afispage.html [12] Fingerprint Searching - Fingerprint Matching, East Shore. http://www.east-shore.com/tech.html [13] About Fingerprint Scanning, Find Biometrics. http://www.findbiometrics.com/Pages/fingerprint_articles/fingerprint_1.html [14] Finger-Scan (FingerPrints), Biometric ID. http://www.biometricid.org/finger.html [15] Scientific Methodology and the Friction Ridge Identification Process, Mary Beeton. http://www.ridgesandfurrows.homestead.com/files/Scientific_Methodology.pdf [16] Iris – scan Technology Reports, International Biometric Group. http://www.ibgweb.com/reports/public/reports_iris-scan.html [17] Finger-Scan (FingerPrints), Biometric ID. http://www.biometricid.org/iris.html [18] Iris Recognition: The Technology, Iris Scan http://www.iris-scan.com/iris_technology.htm [19] SENSORES BIOMPETRICOS, Patricio Olguín S. http://neutron.ing.ucv.ve/revista-e/No6/Olguin%20Patricio/SEN_BIOMETRICOS.html [20] Understanding Iris Recognition, Find Biometrics. http://www.findbiometrics.com/Pages/iris_articles/iris_1.html [21] IRIS SCANNING, Colby College. http://www.colby.edu/~jbrosenb/STS%20Project/iris/IRISSCAN.htm [22] IRIS SCAN, Nacional Senter for State Courts http://ctl.ncsc.dni.us/biomet%20web/BMIris.html [23] Comparison of biometrics, ADMS. http://www.admsyst.com/comparison_bio.htm [24] Zephyr Análisis, International Biometric Group. http://www.ibgweb.com/zephyr_2002.pdf [25] BioAPI Consortium http://www.bioapi.org/
ISC-2003-1-24
91
[26] News and events, J. Markowitz, Consultants. http://www.jmarkowitz.com/news.html [27] Java Native Interface, Sun Microsystems Inc. http://java.sun.com/products/jdk/1.2/docs/guide/jni/ [28] JNI Basics, The code Project. http://www.codetools.com/useritems/jnibasics1.asp [29] An introduction to the Java Native Interface, Java One. http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/2253.pdf [30] The OpenLDAP Foundation http://www.openldap.org [31] An Introduction to LDAP. Michael Donnelly, LDAPMan. 28 de abril de 2000. http://ldapman.org/articles/intro_to_ldap.html [32] Introduction to Directory Server, Sun Microsystems Inc. http://docs.sun.com/source/816-5599-10/intro.htm#11284 [33] Understanding LDAP. Heinz Johner, Larry Brown, Franz-Stefan Hinner, Wolfgang Reis, Johan Westman, IBM. Junio de 1998. http://www.redbooks.ibm.com [34] Understanding Multimodal Biometrics Systems, Find Biometrics. http://www.findbiometrics.com/Pages/smartcard%20articles/multi_1.html [35] BioNetrix Authentication Suite 4.1, BNX Systems. http://www.bionetrix.com/products.html#features [36] Safe World PremierAccess, Secure Computing. http://www.securecomputing.com/index.cfm?skey=643 [37] Daon para Windows, Daon. http://www.daon.com/products/daon%20for%20windows/index.htm [38] SAF Solution Enterprise Edition for Windows, Saflink Corporation. http://www.saflink.com/SAFsolutionEnt.html [39] Secure Suite XS, I/O Software. http://www.iosoftware.com/pages/Products/SecureSuite%20XS/index.asp