La lógica dice que para que un capa pueda trabajar de modo asíncrono, todas sus capas por debajo puedan hacerlo y aquí es donde nos encontramos con este problema. Se miró la posibilidad de migrar a OpenUSB, desarrolado por SUN Microsystems, pero al final se descartó por diversos motivos.

¿Qué problemas supone esto? Pues por ejemplo, yo ejecuto una función donde quiero verificar una huella:

r = fp_verify_finger(dev, enroll_data);

El proceso sería activar el dispositivo, libfprint escanearía la huella, se procesan los resultados, se comparan los resultados y se devuelve el resultado de la comparación. Y el problema sería que la ejecución del programa se para hasta que el usuario escanee su huella, ¿y si estuviera alejado del ordenador en ese momento? Por ejemplo una interfaz GUI se quedaría sin responder hasta escanear el dedo. ¿Soluciones? Lo primero que pensamos para evitar este comportamiento sería programa la GUI usando un thread distinto cuando se vaya a escanear pero lo propio sería migrar a libusb-1.0 que permite I/O asíncrono.

Hasta ahora el desarrollo de libusb se encontraba parado así que Daniel Drake, el responsable principal de fprint, que últimamente se ha dedicado a desarrollar y estabilizar la versión 1.0.

Otra posible mejora sería incluir funciones para cancelar las operaciones en curso y otra sería tener un daemon global de sistema que funcionara por ejemplo con DBUS.

Aparte de la propia libfprint disponemos de unos cuantos extras para poder jugar. El primero de ellos sería pam_fprint, que es un módulo de PAM que nos proporciona la posibilidad de autenticación en el sistema. La idea es integrarlo con shadow, GDM y KDM aunque en los 2 últimos existen ciertos problemas por el propio diseño de GDM y KDM. Es un módulo muy básico y su función inicial casifue sólo demostrar el uso de libfprint.

Por último, actualmente disponemos de dos frontends, el primero fprint_demo y el segundo “QT Fingerprint Scanning GUI“.

Después de todos estos posts sobre fprint, ya no tenéis excusa para hacer un #include <fprint.h> y desarrollar vuestros pequeños monstruitos.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Lectores de huellas en linux
• [Fprint] La implemetación del driver
• [Fprint] Los dispositivos

El driver está desarrollado en C, como no, ¿por qué? pues porque:

• es adecuado para programar drivers porque nos proporciona funcionalidad a ‘bajo nivel’ siendo un lenguaje de ‘alto nivel’.
• facilmente podremos crear bindings en c++, java, python, ruby, …
• será fácil luego adaptarlo a sistema embebidos (empotrados, embedded o como se les quieran llamar)

Está implementado en forma de librería y recibe el nombre de libfprint y depende de otras librerías como:

• libusb: nos proporciona I/O al bus USB y además es portable a FreeBSD, Mac OSX, Windows y más.
• glib: un gran librería de rutinas en C de las cuales usaremos unas poquitas (listas enlazadas, operaciones sobre strings, para reservar memoria, etc)

A continuación os pongo un esquema de como está estructurado:

Como se puede ver, tendremos una API de alto nivel donde se nos proporcionan funciones para registrar huellas de dedos (enrollment), verificar (comprobar que la huella escaneada coincide con la almacenada contra la que se ha pedido confirmación) y identificar (encontrar entre las huellas almacenadas una que coincida con la escaneada). La diferencia entre verificar y identificar sería la misma que entre elegir tu nombre de usuario y escanear tu dedo y en lugar de eso escanear tu huella y que el sistema reconozca tu usuario y te confirme.

De estas funciones tendríamos 2 variantes, la que nos devuelve la imagen por si además si quisiéramos hacer alguna cosa con ella y que simplemente realiza su función:

- fp_enroll_finger( )
- fp_verify_finger( )
- fp_identify_finger( )
- fp_enroll_finger_img( )
- …

luego podríamos usar un trozo de código similar a esto:

if (is_imaging_device(dev))
fp_enroll_finger_img(&data, &img);
else
fp_enroll_finger(&data);

Para empezar a usar los dispositivos tendremos disponibles las siguiente funciones que son bastante autoexplicativas:

- fp_discover_devices()
- fp_dev_open() / fp_dev_close()

Para detectar qué dispositivo tenemos es fácil ya que el descriptor del dispositivo incluye un código con el Vendor (fabricante) y el Product ID (identificación de producto) que lo identifica inequívocamente. Por ejemplo, podremos obtener ese código con un simple  ‘lsusb’.

Por debajo de la capa “Imaging layer” para escanear necesitaremos las funciones para detectar la presencia del dedo, escanear y detectar la ausencia de dedo.

Como ya hemos contado en otros posts, el dispositivo upek al ser autónomo no requerirá de estas funciones.

Igualmente dispondremos de una serie de funciones para el almacenamiento.

Para el que quiera entretenerse un rato aquí hay más información sobre la API disponible: http://www.reactivated.net/fprint/api/

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Mejoras en el driver y algunos extras
• [Fprint] Los dispositivos
• [Fprint] Procesado de la imagen – Huellas dactilares

Para el primer grupo de lectores de huellas necesitaremos pues una serie de algoritmos que nos permitan analizar y comparar las imágenes de las huellas dactilares.

A la hora de desarrollar fprint se consideró programar todos estos algoritmos pero ya existían, además en forma de código libre, unas posibles soluciones que ahora veremos.

Pero primero, ¿qué buscamos en una huella dactilar? ¿cuáles son los puntos de interes? En una huella tenemos una serie de crestas y surcos que van dibujando un laberinto en el cual podemos de reconocer ciertos puntos de interés, comunmente llamados minutiae. Lo que tenemos que detectar son principalmente las terminaciones o bifurcaciones de las crestas. Existen otros puntos de interés como: el corazón (centro del patrón de la huella), islas, deltas y discontinuidades. En la siguiente imagen podemos ver un ejemplo de cada caso:

Decía antes que ya existe una colección de herramientas libres que tenían los algoritmos implementados. Se llama NBIS (NIST Biometric Image Software) y fue creada por el grupo de imagen del NIST (National Institute of Standards and Technology). Inicialmente fue desarrollada para el FBI (Federal Bureau of Investigation) y el DHS (Department of Homeland Security) y fue usada para el control del crímen y el control fronterizo respectivamente. Vamos, que cuando vamos a USA y nos escanean las huellas usan este software.

MINDTCT

Dentro del paquete NBIS esta es la herramienta que se usa para detectar las minutiae, como bien su nombre indica: minutiae detector. Antes de buscar los puntos de interés deberemos tratar la imagen para que facilitar esa detección. Se realiza un aumento de contraste en la imagen para binarizarla a 2 colores sólidos. De ese modo las crestas se convertirán en zonas negras sobre blanco. Luego se escanea durante varias pasadas buscando patrones de píxeles. La realidad es que se generan bastante falsos positivos así que seguidamente se eliminan las minutiae de las zonas de la imagen con menos calidad y las que no están claras.

Deberíamos quedarnos no solo con las coordenadas de la minutiae sino también con la dirección de la cresta, que tipo de punto de interés es (bifurcación, terminación, etc, y muy importante un factor de confianza sobre  la formalidad de ese punto detectado.

BOZORTH3

El siguiente paso sería tener la capacidad de concordar diferentes huellas para buscar casos coincidentes y para ello se puede usar este algoritmo. Fue creado por el FBI (un tal Allan S. Bozorth, original, eh?) y detecta coincidencias independientemente de la traslación y rotación de las imágenes. Posteriormente el NIST lo adoptó y lo mejoró. Tiene un umbral configurable para ser más o menos estrictos en las concordancias.

Existe otro sistema open source de procesamiento de huellas digitales, se llama Fingerprint Verification System junto con efinger,  pero no es tan eficaz como el creado por el NIST.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Los dispositivos
• [Fprint] Lectores de huellas en linux
• [Fprint] La implemetación del driver

• aes1610: Authentec AES1610
• aes2501: Authentec AES2501
• aes4000: AuthenTec AES4000
• fdu2000: SecuGen FDU 2000
• upeksonly: UPEK TouchStrip sensor-only
• upektc: UPEK TouchChip
• upekts: UPEK TouchStrip with biometric co-processor
• uru4000: Digital Persona U.are.U 4000/4000B
• vcom5s: Veridicom 5thSense

Poco a poco se van añadiendo modelos, de hecho, inicialmente sólo se dió soporte a 4 modelos distintos así que para ilustrar un poco las características que suelen tener estos cacharros vamos a ver los 4 primeros que se implementaron (empezando por el mio!) :

AuthenTec AES2501

Este es el que tengo yo en mi HP nc6400. Es “swipe-type fingerprint sensor” lo que viene a ser de barrido, es decir el usuario tiene que pasar el dedo y dependiendo de como lo haga la imagen resultante podrá ser distinta. Lo que hace es escanear durante distintos instantes de tiempo el trocito de huella que está encima del sensor en sí y luego presenta al sistema una serie de imagenes en ‘rebanadas’ de 192×16 píxeles en escala de grises. Con esas lonchas de imágenes el driver deberá eliminar el overlap entre los diferentes trozos y juntarlos para obtener la huella. Cuando este sensor viene montado en portátiles a veces se da el caso de que lo han puesto al revés así que, además de eliminar el overlap, se deberá también determinar la dirección de escaneo. Pero nos falta un detalle, digamos que unos dispositivos son más ‘tontos’ que otros, así que en este modelo también se deberá detectar cuando se ha puesto el dedo en el sensor y cuando se ha quitado. (lo cierto es que cuanto más tonto sea el dispositivo más guay porque al no hacer cosas automáticamente podremos hacer más cosas como queramos). Lo cierto es que a pesar que no tener implementadas en hardware funciones para detectar el dedo tiene un modo de captura en el cual devuelve el histograma de la imagen capturada pero SIN transferir los datos de esa imagen. Esto simplifica mucho las cosas porque calculando el area el histograma y teniendo un valor umbral podremos determinar la presencia de un dedo o no.

Respecto a la captura de las imágenes es un poco más complicado que en otros dispositivos, como hemos dicho devuelve una serie de imágenes de 192×16 pero el caso es que vienen codificadas y ordenadas de una forma un poco rara. Gracias a la especificación del fabricante se puede reordenar el churro de bytes y así obtener las imagenes en escala de grises.

Estos dispositivos suelen estar presentes en los portátiles de HP y Fujitsu.

AuthenTec AES4000

Este modelo, a diferencia del anterior es “press-type USB fingerprint sensor” es decir, se coloca el dedo en lugar de arrastrarlo por el sensor. Devuelve una imagen cuadrada en escala de grises al sistema y tiene implementado en hardware funciones básicas para detectar la presencia del dedo. Es bastante común en periféricos autenticadores. Al igual que AES2501 ordena los bits de las imágenes del mismo modo extraño made in AuthenTec.

Su mayor problema es que lleva un sensor muy pequeño, de 223ppi (pixels per inch), comparado otros modelos y con los 500ppi recomendados por los algoritmos de identificación y verificación de huellas (mindtct, del cual hablaremos más adelante) . Originalmente las imágenes que se obtenían eran malísimas pero escalando la imagen antes del procesado se solventa gran parte del desastre.

A continuación el resultado de la binarización de la imagenes con ambos tamaños:

Digital Persona U.are.U 4000B

Es un press-type USB fingerprint sensor también. Usa un sistema optico para capturar una imagen de alta resolución de la huella. Tiene implementado en hardware detección de la presencia del dedo y 2 modos de captura. Este dispositivo lo vende por separado la empresa Digital Persona y se encuentran en varios dispositivos de entrada embebidos de Microsoft. También se vende el módulo sensor por separado que, de hecho, otras empresas han integrado en más de uno de sus productos.

Devuelve imágenes de 8 bits en escala de grises estandar que no requiere de ningún tipo de reordenación como los casos anteriores.

UPEK TouchStrip

Es un “swipe-type USB fingerprint scanner” pero este dispositivo guarda una diferencia clave respecto al resto, lleva un coprocesador biométrico que realiza el procesado de la imagen en hardware y en lugar de presentar una imagen el sistema tan sólo presenta un resultado booleano de autenticación concedida o denegada. Por un lado eso nos ofrece desventajas a la hora de usar los algoritmos que queramos para el tratamiento de imágenes pero por otro nos podría simplificar el sistema a la hora de crear un sistema embebido y la ventaja de poder disminuir el tamaño del driver.

Este dispositivo se puede encontrar en portátiles de IBM/Lenovo, DELL y Toshiba. Existe un driver propietario de UPEK para linux y tambień tenemos disponible el driver Thinkfinger.

En las próximas entregas veremos que algoritmos se usan para tratar las imágenes. Y bueno, no hace falta decir que gran parte de lo que se conoce de todos estos dispositivo es gracias a la ingeniería inversa y a esnifar el bus USB. Si tienes un dispositivo que no esté soportado no dudes enviar tus chorrizos de bytes a la lista de correo de fprint.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] La implemetación del driver
• HP Mobile Data Protection System 3D
• [Fprint] Procesado de la imagen – Huellas dactilares

Ya es bastante común encontrarse con portátiles que llevan incorporado lectores de huellas que pueden ser usados para loguearse u otros menesteres menos útiles, incluso con algún gadget geek para jugar a ser Macgyver.

Históricamente, por algun razón absurda de pensar que es algo tecnólógicamente avanzado, se ha asociado estos dispositivos a las pelis de acción con un espías que entran en la sala super segura de la muerte usando el dedito (a veces se lo curran más y hacen escáneres de retinas y análisis in situ de ADN) pero lo cierto es que la experiencia ha demostrado que la seguridad de estos dispositivos no es tal. Por ello, para cualquiera que se lo plantee, ya lo avanzo: “Jamás uséis un escáner de huellas como método de autenticación a un sistema o servicio que sea crítico o susceptible”. Este sistema se debe usar como añadido (como confirmación extra) para aumentar la seguridad de una clave por ejemplo.

El soporte de estos dispositivos en linux ha sido prácticamente nulo y cojo hasta la llegada del proyecto fprint que ha conseguido dar soporte a la gran mayoría de los dispositivos más extendidos en el mercado. La parte más grande e importante viene en forma de librería (libfprint) que nos permite acceder interactuar estos lectores. En Gentoo el paquete está disponible en el overlay wschlich-testing y existen paquetes para otras distros porque el proyecto ya ha cogido fama, de todas formas no hay mayor problema en descargar las fuentes y compilar directamente.

En los próximos posts nos adentraremos un poquito en como funcionan estos dispositivos y como se ha desarrollado el driver.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Procesado de la imagen – Huellas dactilares
• [Fprint] Los dispositivos
• [Fprint] La implemetación del driver