Desarrollo de Soluciones Cliente-Servidor para la Verificación ...

Desarrollo de Soluciones Cliente-Servidor para
la Verificación Biométrica de Identidad y
Monitorización en Plataformas Web:
Aplicación a Tele-enseñanza
Autor:
Elisardo González Agulla
Directores:
José Luis Alba Castro
Luis E. Anido Rifón
2010

Desarrollo de Soluciones
Cliente-Servidor
para Verificación Biométrica
de Identidad y Monitorización
en Plataformas Web:
Aplicación a Tele-enseñanza
Universidad de Vigo
Departamento de Teoría de la Señal y Comunicaciones
Elisardo González Agulla
Directores
José Luis Alba Castro
Luis E. Anido Rifón
2010

Dpto. de Teoría de la Señal y Comunicaciones
ETSE de Telecomunicación
Universidade de Vigo
Campus Universitario s/n
E-36310 Vigo
TESIS DOCTORAL
Desarrollo de Soluciones Cliente-Servidor
para Verificación Biométrica
de Identidad y Monitorización
en Plataformas Web:
Aplicación a Tele-enseñanza
Autor:
Directores:
Elisardo González Agulla
Ingeniero de Telecomunicación
José Luis Alba Castro
Doctor Ingeniero de Telecomunicación
Luis E. Anido Rifón
Doctor Ingeniero de Telecomunicación
Enero de 2010

TESIS DOCTORAL
Desarrollo de Soluciones Cliente-Servidor
para Verificación Biométrica
de Identidad y Monitorización
en Plataformas Web:
Aplicación a Tele-enseñanza
Autor: D. Elisardo González Agulla
Directores: Dr. D. José Luis Alba Castro
Dr. D. Luis E. Anido Rifón
TRIBUNAL CALIFICADOR
Presidente: Dra. Dña. Carmen García Mateo
Vocales:
Dr. D. Albert Sangrá Morer
Dr. D. Javier Ortega García
Dr. D. Roberto Paredes Palacios
Secretario: Dr. D. Martín Llamas Nistal
CALIFICACIÓN: Sobresaliente Cum Laude
Vigo, a 19 de Enero de 2010.

”Se nos conoce por nuestros actos.”
Bruce Wayne, 2005

A los que siempre estáis ahí.

Abstract
The use of online learning applications is nowadays widely spread and still growing
due to the advantages that it offers. At World Wide Web there exist thousands of virtual
courses currently available using e-learning environments. Nevertheless there are some
lacks in current Learning Management System (LMS) that do not allow to provide virtual
educational environments with full traditional learning capabilities.
Some of the most important drawbacks in current LMSs are the lack of adequate tools
to actually guarantee that the student is who he/she claims to be, and to properly track the
behaviour of the students along the whole learning session. Traditional solutions, such as
login and password based authentication, and simple session logs where the interactions
between user and system are recorded, can not actually guarantee that the user is who
he/she claims to be, and even worse, they can not guarantee whether the user is or not in
front of the computer looking at the screen.
Biometry, on the other hand, refers to the emerging field of technology devoted to
identification of individuals using biological traits (i.e. physiological or behavioral traits).
Biometry has become an essential method for verification and identification tasks, that
offers wide range of possibilities, although it was ever linked with human identification in
access control tasks, or with the field of criminalistics.
In this Thesis we propose the application of Biometrics to the E-learning environment
in order to increase the security level offered by the access control module in LMS, and to
improve the monitoring process of student’s behaviour during the learning session. With
this solution, we intend to contribute to the LMS spreading, allowing the use of LMS in
environments where only traditional learning could be used until now, such as courses that
require hour certification.
First, we present the open source project BioWebAuth (Biometrics for Web Authentication)
(BWA), that is our solution to provide improved access control using biometric
features. Second, we present BioWebMonitor (Biometrics for Web Monitoring) (BWM),
that is the evolution of BWA, able to monitor in real time the student’s behaviour during
the whole learning session, in terms of attendance and attention intervals.
A lot of advantages are derived from the availability of reliable identity, attendance
and attention information by the LMS. Among them, more reliable hour certification in
virtual courses can be provided. As well, reliable information about student’s behaviour
is an important information feedback. This information can be used by the LMS, for
instance, to report about the complexity of some learning topics, to estimate the whole

II
actual time that each student has spent viewing the course contents, etc.
Performance of the biometric monitoring module developed in this Thesis is experimentally
evaluated in a real environment. 25 students from the Image Processing
subject in the E.T.S.E.T Vigo were monitored while they were filling in two tests about
the subject’s topics using Moodle. The results of this experiment reflect the utility of the
application of Biometrics in the E-learning environment.
Keywords: E-learning, LMS, Biometrics, Access Control, Student Monitoring.

Resumen
En los últimos años y debido a las numerosas ventajas que ofrece, el aprendizaje electrónico
ha experimentado un gran crecimiento que le ha permitido asentarse como un
medio alternativo al aprendizaje presencial. A lo largo de todo el World Wide Web se ofertan
miles de cursos virtuales que, gracias a las plataformas de E-learning, están al alcance
de cualquier estudiante independientemente de su situación geográfica. Sin embargo, todavía
existen algunas carencias en los actuales Learning Management System (LMS) que
impiden proporcionar adecuados entornos educacionales virtuales, en los que se ofrezcan
todo el conjunto de funcionalidad que está disponible en los sistemas de aprendizaje convencional.
Las plataformas LMS actuales no pueden asegurar que el estudiante conectado
sea quién dice ser, ni proporcionan una medida fiable del comportamiento del estudiante
durante la sesión de aprendizaje. Actualmente, para suplantar a un estudiante basta con
conocer su nombre de usuario y su clave, y en determinados escenarios éste estaría dispuesto
a compartirlos. Estas mismas plataformas tampoco son capaces de ofrecer medidas
fiables sobre el tiempo real de presencia y de atención que el estudiante ha dedicado a cada
uno de los contenidos de un curso virtual, pues son incapaces de detectar si el estudiante
ha abandonado su equipo por un periodo de tiempo para luego regresar, o simplemente,
no pueden garantizar si el estudiante está mirando la pantalla del ordenador.
La Biometría, por otro lado, definida como el estudio de métodos automáticos para
el reconocimiento único de humanos basados en uno o más rasgos fisiológicos o de
conducta, se ha convertido en un método esencial de verificación e identificación, que
ofrece grandes posibilidades aunque desde sus orígenes siempre haya estado vinculada a
la identificación humana en tareas de control de acceso o en criminalística.
En esta Tesis se propone la aplicación de la Biometría en el ámbito del aprendizaje
electrónico para, por una parte, incrementar el nivel de seguridad ofrecido por el mecanismo
de control de acceso de las plataformas LMS, y por otra parte, mejorar el proceso
de monitorización del comportamiento del estudiante durante la sesión de aprendizaje.
De este modo pretendemos romper alguna de las barreras que impiden un mayor crecimiento
de los LMSs, permitiendo ofrecer servicios hasta ahora exclusivos del aprendizaje
presencial.
En esta Tesis se presenta en primer lugar el proyecto de código abierto BioWebAuth
(Biometrics for Web Authentication) (BWA), solución que permite resolver el problema
del control de acceso utilizando rasgos biométricos. En segundo lugar, se describe el Framework
BioWebMonitor (Biometrics for Web Monitoring) (BWM) que añade a BWA la

IV
capacidad de monitorizar en tiempo real la conducta del estudiante, en términos de tiempo
de presencia y de atención, durante la sesión de aprendizaje.
Son numerosas las ventajas que ofrece el hecho de que el LMS esté seguro de la identidad
del estudiante y tenga una medida fiable del tiempo de presencia y atención que éste
dedica a sus contenidos. Entre ellas, destacamos la posibilidad de ofrecer tanto un servicio
de Certificación de Horas en Cursos Virtuales más fiable que los que actualmente existen,
como un servicio de Estimación Automática de la Carga de Trabajo en Cursos Virtuales
de gran utilidad en el ámbito European Credit Transfer and Accumulation System (ECTS).
Además, la información de monitorización del comportamiento del estudiante supone una
fuente de realimentación que permite al LMS extraer información relevante sobre la complejidad
de algunos temas, dimensionar la carga de trabajo asociada a cada contenido de
un curso, etc.
Con el fin de evaluar las prestaciones del módulo de seguimiento biométrico desarrollado
en esta Tesis se realizó un experimento en un entorno real, contando con la
participación de 25 alumnos de la asignatura de Procesado de Imagen de la E.T.S.E.T de
la Universidad de Vigo. Estos alumnos fueron monitorizados biométricamente mientras
realizaban varios cuestionarios utilizando la plataforma de E-learning Moodle. Los
resultados obtenidos reflejan la utilidad de la aplicación de la Biometría en el campo del
aprendizaje electrónico.
Palabras clave: E-learning, LMS, Biometría, Control de Acceso, Monitorización de
Estudiante.

Agradecimientos
Por fin se acerca el momento de pasar página, de cerrar una importante etapa de mi
vida en la que he tenido la gran suerte de poder compartir momentos inolvidables con
vosotros, disfrutando de vuestra compañía, comprensión, amistad y apoyo. Gracias a todos
los que habéis estado ahí.
Como no podía ser de otra manera, en primer lugar, Carla, me gustaría agradecerte
toda la paciencia, la compresión, el apoyo y el amor que me has brindado durante este
largo camino, TE QUIERO.
A TODA mi Familia, especialmente a mis padres, gracias por vuestro cariño y sacrificio,
sin vuestro esfuerzo no habría llegado hasta aquí. Esta Tesis es en parte vuestra.
A Carmen García Mateo y a Óscar Márquez les estaré eternamente agradecido por
haberme brindado hace siete años la oportunidad de introducirme en el apasionante mundo
de la Biometría, y de permitirme formar parte de un estupendo equipo, en el que no sólo
tengo compañeros, sino amigos.
A mis directores de Tesis, José Luis Alba y Luis Anido, quisiera agradecerles la confianza
depositada en mi, gracias por guiarme y formarme a lo largo de esta etapa, sin
vuestra ayuda no habría sido posible la realización de este trabajo.
A Enrique Otero, Quique Argones y Daniel González, gracias por vuestra labor en
el nacimiento de BioWebAuth, sabéis que sin vosotros no habría sido posible ese parto.
También quiero dar las gracias a los alumnos que con sus PFCs han contribuido al desarrollo
de distintos módulos para BWA: Edu, Benxamín, Manu, Mario, Juan y Miguel. Y
agradecer el enorme trabajo de etiquetado realizado por Jacobo y que tan útil ha sido en
esta Tesis.
Me gustaría terminar agradeciendo todo su apoyo durante estos años a mis compañeros
del laboratorio TSC5 (Fran, Gonzalo, Abu, Fer, Juan, Pedro, Luis, Gabi, Javi Diéguez,
y demás.), de Inteligencia (Marcos, Marta, Norberto y Gonzalo), compañeros de Telemática
(Kike, Belén, David Conde, Su,...), mis amigos de Pontevedra (Edu, Sonia, Iván, Vero,
Armando, Víctor,...).
A todos vosotros, Gracias.

Tabla de Contenidos
1. Introducción 1
1.1. Introducción al E-learning . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. Learning Management Systems . . . . . . . . . . . . . . . . . . 4
1.1.3. Catálogo de plataformas LMS . . . . . . . . . . . . . . . . . . . 5
1.2. Introduccion a la Biometría . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2. Sistema Biométrico . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3. Modalidades Biométricas . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4. Sistemas Biométricos Multimodales y Fusión Biométrica . . . . . 12
1.3. Motivación y Objetivos de la Tesis . . . . . . . . . . . . . . . . . . . . . 13
1.4. Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2. Estado del Arte 17
2.1. Estado del Arte en E-learning . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1. Advanced Distributed Learning y SCORM . . . . . . . . . . . . 19
2.1.2. IMS Global Learning Consortium y Common Cartridge . . . . . 20
2.1.3. Seguridad en Plataformas de E-learning . . . . . . . . . . . . . . 22
2.2. Estado del Arte en Biometría . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1. Estándares asociados a Tecnologías Biométricas . . . . . . . . . 25
2.2.2. El Consorcio BioAPI y El Estándar BioAPI . . . . . . . . . . . . 25
2.3. Aplicación de Sistemas Biométricos en E-learning . . . . . . . . . . . . . 26
2.3.1. Control de Acceso . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2. Monitorización de Estudiante . . . . . . . . . . . . . . . . . . . 28
2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

VIII
Tabla de Contenidos
3. Base Tecnológica 31
3.1. Tecnologías Biométricas . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1. El Framework BioAPI . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2. BioAPI Framework desde Java . . . . . . . . . . . . . . . . . . . 36
3.2. Single Sign-On para el Web . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1. Central Authentication Service . . . . . . . . . . . . . . . . . . . 38
3.2.1.1. CASifying Learning Management Systems . . . . . . . 40
3.3. Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1. Seguridad en Servicios Web . . . . . . . . . . . . . . . . . . . . 43
3.4. Procesado de Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.2. Algoritmo de Viola & Jones . . . . . . . . . . . . . . . . . . . . 44
3.4.3. Algoritmo CAMSHIFT . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.4. Algoritmo de Lucas-Kanade . . . . . . . . . . . . . . . . . . . . 49
3.5. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.2. Relación de principales patrones GoF . . . . . . . . . . . . . . . 52
3.5.3. Catálogo de patrones J2EE . . . . . . . . . . . . . . . . . . . . . 54
3.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de Estudiante
para Plataformas LMS 57
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2. Proyecto de Código Libre BioWebAuth (BWA) . . . . . . . . . . . . . . 59
4.2.1. Diseño del BioWebAuth Framework . . . . . . . . . . . . . . . . 60
4.2.2. Interacción Hombre-Máquina en BWA: Modelado XML de Captura,
Enrollment y Verificación . . . . . . . . . . . . . . . . . . . 63
4.2.3. Una Visión Global del Framework BWA . . . . . . . . . . . . . 69
4.2.4. Integrando BioAPI en el Entorno Cliente-Servidor de BWA . . . 72
4.2.5. Contribuciones al Proyecto de Código Libre JBioAPI . . . . . . . 74
4.2.6. Conexión Cliente-Servidor de BWA: Web Services y XCBF . . . 74
4.3. Integración de BWA con las Plataformas LMS . . . . . . . . . . . . . . . 75
4.4. Análisis de Seguridad y Validación del BioWebAuth Framework . . . . . 75
4.4.1. Análisis de Seguridad de la Arquitectura de BWA siguiendo la
Taxonomía CERT . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5. Desarrollo de Módulos de Reconocimiento Biométrico según la Especificación
BioAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.1. Módulo de Reconocimiento Facial: BWAFaceBSP . . . . . . . . 77

Tabla de Contenidos
IX
4.5.2. Módulo de Reconocimiento de Locutor: BWAVoiceBSP . . . . . 78
4.5.3. Módulo de Reconocimiento Multimodal basado en Cara y Voz:
BWAMultimodalFaceAndVoiceBSP . . . . . . . . . . . . . . . . 80
4.5.4. Módulo de Reconocimiento de Firma Dinámica: SignatureBSP . 81
4.5.5. Módulo de Reconocimiento de Huella Dactilar: BWAFingerprintBSP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.6. Alcance, Difusión y Repercusión de la Plataforma BWA . . . . . . . . . 82
4.6.1. Estadísticas sobre el Repositorio de BWA en SourceForge . . . . 83
4.6.2. Estadísticas sobre el Demostrador Online de BWA . . . . . . . . 83
4.7. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de Estudiante
para Plataformas LMS 89
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2. Diseño y Desarrollo del Proyecto BioWebMonitor . . . . . . . . . . . . . 93
5.2.1. Monitorización de Presencia y Atención de Estudiante basada en
la Detección y Verificación Biométrica Facial . . . . . . . . . . . 93
5.2.2. Una Visión Global del Framework BWM . . . . . . . . . . . . . 95
5.2.3. Descripción del Módulo de Seguimiento . . . . . . . . . . . . . . 96
5.2.4. Sincronización de relojes entre la plataforma LMS y el Framework
BWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3. Integración con LMSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real . 103
5.4.1. Especificación del Protocolo . . . . . . . . . . . . . . . . . . . . 104
5.4.2. Análisis y Validación de Resultados . . . . . . . . . . . . . . . . 105
5.4.2.1. Resultados Generales . . . . . . . . . . . . . . . . . . 106
5.4.2.2. Precisión en la Detección de Presencia . . . . . . . . . 109
5.4.2.3. Precisión en la Detección de Presencia de Estudiante . . 110
5.4.2.4. Criterio para la Medida del Tiempo de Atención . . . . 111
5.4.2.5. Precisión en la Detección de Atención . . . . . . . . . 112
5.4.2.6. Precisión en la Detección de Atención de Estudiante . . 113
5.4.3. Comparativa Visual . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.5. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6. Contribuciones, Conclusiones y Trabajos Futuros 121
6.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

X
Tabla de Contenidos
6.1.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 122
6.1.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 123
6.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.2.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 124
6.2.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 124
6.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 125
6.3.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . . . . 125
A. Apéndice 129
A.1. Adquisición Base de Datos BioSecure . . . . . . . . . . . . . . . . . . . 129
A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA . . . . . . . 130
A.3. Resultados Alternativos del Módulo de Monitorización Biométrica . . . . 144
B. Acrónimos y Abreviaturas 155

Lista de Figuras
1.1. False Acceptance Rate (FAR) y False Rejection Rate (FRR) como funciones
del threshold t. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2. False Acceptance Rate y False Rejection Rate . . . . . . . . . . . . . . . 12
3.1. Posibles estrategias de implementación de un Biometric Service Provider. 33
3.2. Estructura de un Biometric Identification Record. . . . . . . . . . . . . . 34
3.3. El modelo BioAPI: Primitivas de bajo nivel y abstracciones de alto nivel. 34
3.4. Diagrama de bloques del modelo BioAPI en un entorno Cliente-Servidor. 36
3.5. Sistema de autenticación CAS. . . . . . . . . . . . . . . . . . . . . . . . 39
3.6. Los Servicios Web en funcionamiento. . . . . . . . . . . . . . . . . . . . 41
3.7. Estructura de los mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.8. Cascada de clasificadores. . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9. Haar-like Features - A la izquierda las características empleadas en el
algoritmo original de Viola & Jones y a la derecha las empleadas en la
mejora de Lienhart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10. MEANSHIFT - Desplazamiento de la ventana hacia el centro de masas,
hasta cumplir el criterio de convergencia. . . . . . . . . . . . . . . . . . 47
4.1. Diagrama de Bloques y Descripción Funcional de BioWebAuth. . . . . . 69
4.2. Central Authentication Service: original (izquierda) y con autenticación
biométrica (derecha). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3. Captura de la GUI del sistema de autenticación biométrica. . . . . . . . . 72
4.4. Diagrama de bloques del modelo BioAPI en un entorno cliente-servidor. . 73
4.5. Interfaz de captura del Face BSP. . . . . . . . . . . . . . . . . . . . . . . 78
4.6. Interfaz de captura del Voice BSP. . . . . . . . . . . . . . . . . . . . . . 80
4.7. Interfaz de captura del Multimodal BSP. . . . . . . . . . . . . . . . . . . 81
4.8. Interfaz de captura del Signature BSP. . . . . . . . . . . . . . . . . . . . 82

XII
Lista de Figuras
4.9. Interfaz de captura del Fingerprint BSP. . . . . . . . . . . . . . . . . . . 83
4.10. Accesos Web el Proyecto BioWebAuth de SourceForge. . . . . . . . . . . 84
4.11. Descargas del Proyecto BioWebAuth desde SourceForge. . . . . . . . . . 84
4.12. Visitas hechas desde diferentes países al demostrador de BioWebAuth. . . 85
4.13. Visitas hechas desde diferentes ciudades de España al demostrador de
BioWebAuth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1. Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2. Diagrama de Bloques de BioWebMonitor. . . . . . . . . . . . . . . . . . 95
5.3. Diagrama de Flujo del módulo de Seguimiento de Estudiante. . . . . . . . 97
5.4. Salida visual del módulo de monitorización de alumnos en tiempo real
en la que se aprecian las localizaciones devueltas por Viola&Jones, Cam-
Shift y Lucas-Kanade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.5. Salida visual del módulo de monitorización de alumnos en tiempo real. El
color de los cuadrados y elipses describe el estado de autenticación de la
cara detectada. Verde para estudiantes verificados, rojo para impostores,
y naranja para aquellos que todavía no han sido verificados. . . . . . . . . 101
5.6. Los estudiantes comprueban que sus caras están correctamente enmarcadas
por la webcam colocada sobre el monitor del ordenador. . . . . . . . 104
5.7. Herramienta gráfica de visualización de la monitorización biométrica de
un estudiante durante una sesión de aprendizaje. . . . . . . . . . . . . . . 107
5.8. Imágenes extraídas de los 7 vídeos que obtuvieron DAP T
RAP T
5.9. Imágenes extraídas de los 6 vídeos que obtuvieron DAP T
RAP T
>96 %. . . . . . 115

Lista de Tablas
1.1. Tabla comparativa de Tecnologías Biométricas. . . . . . . . . . . . . . . 13
5.1. Resumen de la precisión de la medida de detección de presencia en los
vídeos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2. Precisión en la detección de presencia. . . . . . . . . . . . . . . . . . . . 109
5.3. Resumen de la precisión de la medida de detección de presencia autenticada
de estudiante en los vídeos . . . . . . . . . . . . . . . . . . . . . . 110
5.4. Precisión en la detección de presencia de estudiante autenticado . . . . . 110
5.5. Similitud entre tiempo de pose frontal y tiempo de atención. . . . . . . . 111
5.6. Resumen de la precisión de la medida de detección de atención en los vídeos112
5.7. Precisión en la detección de atención. . . . . . . . . . . . . . . . . . . . 112
5.8. Resumen de la precisión de la medida de detección de atención de estudiante
en los vídeos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.9. Precisión en la detección de atención de estudiante. . . . . . . . . . . . . 113
5.10. Precisión en la detección de pose frontal. . . . . . . . . . . . . . . . . . . 114
A.1. Error de precisión cometido por el detector de presencia extraído de los
logs biométricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2. Error de precisión cometido por el detector de frontalidad del estudiante
extraído de los logs biométricos . . . . . . . . . . . . . . . . . . . . . . 146

Capítulo 1
Introducción
Contenido
1.1. Introducción al E-learning . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. Learning Management Systems . . . . . . . . . . . . . . . . . 4
1.1.3. Catálogo de plataformas LMS . . . . . . . . . . . . . . . . . . 5
1.2. Introduccion a la Biometría . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2. Sistema Biométrico . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3. Modalidades Biométricas . . . . . . . . . . . . . . . . . . . . . 10
1.2.4. Sistemas Biométricos Multimodales y Fusión Biométrica . . . . 12
1.3. Motivación y Objetivos de la Tesis . . . . . . . . . . . . . . . . . . . 13
1.4. Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Desde una perspectiva histórica, los nuevos sistemas de aprendizaje a través de Internet,
o Sistemas de E-learning, son una evolución de los sistemas de educación a distancia
tradicionales, a los que se les han añadido numerosas funcionalidades mediante el empleo
de las nuevas tecnologías de la información. Durante los últimos años han aparecido
cientos de estos sistemas, y con ellos se quiere proporcionar aplicaciones que permitan
mantener entornos de aprendizaje virtuales útiles y eficaces para todos los actores involucrados.
Pese a su gran crecimiento y proliferación, el aprendizaje electrónico todavía
presenta algunas carencias en comparación con el aprendizaje presencial que frenan su
expansión hacia determinadas direcciones. Algunas de estas carencias tienen que ver con
la verificación de identidad del estudiante, y con la monitorización llevada a cabo mientras
realiza un curso virtual. Las plataformas LMS actuales no pueden asegurar que el estudiante
conectado sea quién dice ser, pues para suplantarlo basta con conocer su nombre
de usuario y su clave, y en determinados escenarios el propio estudiante estaría dispuesto
a compartir estos datos. Por otra parte, estas mismas plataformas tampoco proporcionan

2 Capítulo 1. Introducción
una medida fiable del tiempo real de presencia y de atención que el estudiante ha dedicado
a cada uno de los contenidos de un curso virtual, pues éstas no son capaces de detectar
determinadas situaciones, como por ejemplo si el estudiante abandona su equipo por un
periodo de tiempo para luego regresar y continuar con la tarea desde el punto en el que lo
había dejado.
La identificación biométrica, por otro lado, se ha convertido en un método esencial de
verificación e identificación que ofrece grandes posibilidades, aunque desde sus orígenes
siempre haya estado vinculada a la identificación humana en tareas de control de acceso
o en criminalística.
En esta Tesis proponemos la aplicación de la Biometría en el ámbito del aprendizaje
electrónico para incrementar así el nivel de seguridad ofrecido por el mecanismo de
control de acceso de las plataformas LMS, y para mejorar el proceso la monitorización
del estudiante proporcionando una medida fiable de los tiempos de presencia y atención
que éste dedica a cada uno de los contenidos durante la sesión de aprendizaje. De este
modo pretendemos romper alguna de las barreras que impiden un mayor crecimiento
de los LMSs, permitiendo, por una parte, su aplicación en entornos que hasta ahora son
feudo exclusivo de la formación presencial, como por ejemplo en aquellos cursos donde
se requiere la certificación de las horas dedicadas, y proporcionando, por otra parte, un
mecanismo fiable para la estimación automática de la carga de trabajo en cursos on-line,
siendo de gran utilidad en el ámbito ECTS, ya que los créditos ECTS hacen referencia al
tiempo que tiene que dedicar el alumno a una materia para poder asimilar sus contenidos.
El resto del capítulo está organizado como se muestra a continuación: en la sección
1.1 se describe la evolución del la Tele-enseñanza desde su origen, se define el concepto
de plataforma Learning Management System (LMS), y se presenta un catálogo de las
principales plataformas de E-Learning disponibles en la actualidad. En la sección 1.2
se describe la evolución de la Biometría junto con las características principales de los
sistemas biométricos. La sección 1.3 refleja la motivación y los objetivos de esta Tesis.
Finalmente, en la sección 1.4 se resume la estructura de esta Tesis.
1.1. Introducción al E-learning
En esta sección describiremos la evolución historia de los sistemas de aprendizaje
electrónico, particularizando al caso español. Introduciremos el concepto de plataforma
de tele-enseñanza o Learning Management System (LMS) y presentaremos un catálogo
detallado de las principales plataformas, tanto comerciales como de código libre, de E-
Learning existentes.
1.1.1. Introducción
El E-learning puede ser definido como un sistema de aprendizaje sustentado en la utilización
de medios electrónicos por medio de los cuales se le proporciona a los alumnos del
material educativo necesario para su aprendizaje. Éste encuentra su origen en la educación
a distancia, que en los comienzos se realizaba vía correo ordinario. Debido al desarrollo
de las tecnologías y la aparición de Internet, este sistema se vio bastante favorecido, lo

1.1. Introducción al E-learning 3
que permitió su utilización para las actividades educativas, y dando origen al E-learning.
Las primeras manifestaciones de aprendizaje electrónico se remontan a los años 50
[Reiser, 2001], cuando se llevan a cabo las primeras experiencias basadas en la utilización
de ordenadores con propósitos pedagógicos, destacando las realizadas por parte de investigadores
de IBM [Rath y otros, 1959]. Sin embargo no fue hasta los años 60 cuando aparecen
los primeros sistemas autónomos de Entrenamiento Basado en Ordenador (Computer
Based Training (CBT)) o Instrucción Asistida por Ordenador (Computer Assisted Instruction
(CAI)), como PLATO [Woolley, 1994], desarrollado en la Universidad de Illinois, o
COURSEWRITER [Buck y Hunka, 1995], desarrollado por IBM. Estos primigenios sistemas,
que incluían una cierta capacidad pedagógica en forma de dirección del proceso
educativo, fueron evolucionando en los años 70-80 a raíz, tanto de las innovaciones tecnológicas
existentes, como de los avances en las aproximaciones pedagógicas implementadas
en estos sistemas. En estos años aparecen los Tutores Inteligentes (Intelligent Tutor
System (ITS)) [Carbonell, 1970][Wenger, 1987], que se caracterizan por la aplicación de
técnicas propias de la Inteligencia Artificial para enfocar la enseñanza como un proceso
cooperativo entre un tutor automático y el alumno. Pero fue la difusión del servicio
WWW en los años 90 lo que supuso un importante impulso hacia la popularización del
aprendizaje electrónico.
Actualmente, el aprendizaje electrónico permite a los estudiantes lidiar de manera
bastante efectiva con los problemas clásicos de la educación formal, como la asistencia
a clases, la sincronización de los horarios con el trabajo, etc. Ofrece además ventajas relacionadas
con el medio tecnológico que utilizan como soporte, entre las que podemos
contar con una amplia gama de posibilidades favorables a los procesos de aprendizaje,
como la capacitación basada en los ordenadores, el uso de salas de clases virtuales, la colaboración
digital a través de foros y chats, la compartición del material educativo a través
de medios electrónicos como Internet, el uso de archivos de audio y vídeo, la televisión
interactiva, etc. Entre las desventajas del sistema podemos citar la disminución o falta de
la relación estudiante-profesor, el posible aislamiento del estudiante, y el entorpecimiento
que sufren muchas veces los trabajos en grupo.
Las aplicaciones de E-learning, pueden ser utilizadas tanto en el mundo educativo como
en el corporativo. Por ejemplo, las empresas, a través de este sistema pueden capacitar
a su personal para aprender a usar un nuevo producto para luego venderlo. Por otra parte,
en el mundo académico, estudiantes de todo el mundo pueden acceder a una amplia gama
de carreras ofrecidas por las universidades sin tener que desplazarse físicamente.
Particularizando en España, según el informe El estado del arte de la formación
[Capital Humano, 2009], en contra de lo que pudiera creerse, la inversión en formación
en España ascendió a 2.095 millones de euros en 2008, un 2,24 % más respecto al 2007.
Según este estudio, el modelo de formación vigente en España aprovecha la crisis actual
para reajustar algunas de sus deficiencias, mostrando un cambio de paradigma, pasando
de la cultura de las horas y la asistencia física a un aula, a un modelo más alineado con
objetivos. Es decir, esta contención presupuestaria se ha reflejado, más que en la desinversión
en formación, en la apuesta por nuevas formas de aprendizaje, en las que el
componente tecnológico juega un papel destacado y cuyo coste es bastante inferior a los
métodos tradicionales. De acuerdo con las cifras hechas públicas por Adecco Training,
en 2008 el E-learning ha experimentado un aumento del 30 % con respecto al año pasado

4 Capítulo 1. Introducción
y la demanda del coaching ha crecido un 15 %. Es por ello que la temática de esta Tesis
tiene gran importancia.
Las cifras muestran como hoy en día la formación online en España se ha posicionado
como una clara alternativa en la formación de profesionales, destinándose a este tipo de
formación un importante porcentaje del presupuesto de los planes de formación de las
empresas o instituciones. Si bien es cierto que su presencia es mayor en grandes empresas
(donde alcanza entorno al 20 % de la formación impartida), en PYMES, Administraciones
Públicas y Agentes Sociales también está experimentando un importante crecimiento.
1.1.2. Learning Management Systems
La difusión del servicio WWW en los años 90 supuso un importante impulso hacia la
popularización del aprendizaje electrónico. A partir de esta época surge la aparición de los
primeros sistemas de Educación Basada en Web (Web Based Education (WBE)), que se
caracterizan por la utilización de un Sistema de Gestión de Aprendizaje, al cual los alumnos
y tutores acceden utilizando un navegador web convencional. En términos generales,
un LMS es una aplicación software, típicamente una aplicación web, que se caracteriza
por facilitar las tareas de administración de usuarios, planificación de actividades formativas
y seguimiento de alumnos en un entorno de aprendizaje electrónico. De forma paralela,
nos encontramos con los Sistemas de Gestión de Contenidos de Aprendizaje (Learning
Content Managament System (LCMS)), que pueden ser definidos como aquellos entornos
multiusuario donde los desarrolladores de contenidos educativos pueden crear, almacenar,
reutilizar, gestionar y entregar contenidos de aprendizaje digital desde un repositorio de
objetos centralizado [Smythe, 2003]. Habitualmente, los sistemas LCMS combinan las
funciones de un Sistema de Gestión de Contenidos Content Management System (CMS),
para el almacenamiento y administración de material educativo, con las funciones de un
LMS para la planificación y entrega de los mismos a los alumnos.
En la literatura podemos encontrar múltiples referencias referidas al potencial y a las
carencias del aprendizaje electrónico [Rosenberg, 2001]. En líneas generales, esta modalidad
educativa combina las ventajas de la educación a distancia frente al aprendizaje
presencial (eliminación de distancias geográficas y flexibilidad de horarios), con aquellas
originadas por la utilización de ordenadores en lugar de libros de texto (empleo de material
multimedia, simuladores, herramientas de evaluación, etc.) y aquellas derivadas de la
utilización de Internet frente a otros medios de comunicación (inmediatez en el intercambio
de información y audiencia amplia).
El uso de sistemas de aprendizaje electrónico resulta especialmente relevante en los
cursos de formación permanente. Ello se debe a que es en esta modalidad formativa en
la que las ventajas introducidas anteriormente resultan de mayor interés al facilitar que
aquellos trabajadores que quieran completar y actualizar su formación puedan compaginarlo
con sus obligaciones laborales. Consecuentemente, el aprendizaje electrónico no
es sólo uno de los sectores en los que se evidencian las bondades de la Sociedad de la
Información y se benefician de ellas sino que, además, contribuye a sostener este nuevo
modelo social y promueve su evolución. En esta Tesis se pretende contribuir con una
solución que elimine alguna de las carencias tecnológicas actuales que impiden ofrecer
un servicio fiable de certificación de horas dedicadas por el estudiante a los contenidos

1.1. Introducción al E-learning 5
de los cursos virtuales.
1.1.3. Catálogo de plataformas LMS
Como hemos mencionado anteriormente un Learning Management System (LMS) es
una aplicación software, típicamente una aplicación web, que se caracteriza por facilitar
las tareas de administración de usuarios, planificación de actividades formativas y seguimiento
de alumnos en un entorno de aprendizaje electrónico de una institución u organización.
Algunos de estos LMS han tardado en ser compatibles con las especificaciones
existentes, y en un principio exigían la necesidad de que los educadores tuvieran bastante
conocimiento técnico para su uso efectivo. No obstante, estos problemas están en vías
de solución, ya que cada vez aparecen nuevas versiones de los LMS, tanto comerciales
como de software libre, que soportan el uso de algunas especificaciones y, por lo menos,
la importación o la exportación de cursos completos empaquetados según SCORM o IMS
Common Cartridge (como veremos en las secciones 2.1.1 y 2.1.2). Además esto está unido
también al desarrollo de nuevas herramientas que permiten la creación de objetos de
aprendizaje y de cursos completos, así como su anotación con metadatos, sin necesidad
de ser un experto en los estándares educativos.
En esta sección mostraremos algunas de las principales plataformas LMS más relevantes
tanto a nivel comercial como de código libre. Si el lector necesita información
más detallada sobre cada una de ellas, le recomendamos que consulte el siguiente informe
realizado por JOIN [LMSs by JOIN Project, WWW], así como las web oficiales de cada
plataforma. Además, recomendamos al lector dos sitios de referencia para mantenerse
al día de las continuas evoluciones de los estándares, que son el Centre for Educational
Technology Interoperability Standards ∗ y el Learning Technolgy Standards Observatory †
del Centro Europeo para la Normalización.
A continuación, destacamos las siguientes plataformas LMS comerciales:
Blackboard: Blackboard Learning System ‡ es un entorno de manejo de cursos. Actualmente
esta plataforma esta siendo usada a nivel mundial por diversas instituciones
relacionadas con la educación, tal es el caso del Servicio Nacional de Aprendizaje
SENA en Colombia. También la utilizan la Universidad Nacional de Colombia y la
Pontificia Universidad Javeriana. En México tiene presencia desde hace más de 10
años en diversas universidades e instituciones como el Instituto Tecnológico y de
Estudios Superiores de Monterrey (ITESM).
Desire2Learn: Desire2Learn Inc. § es una corporación fundada en 1999 que suministra
programas empresariales que permiten a los usuarios construir entornos para el
aprendizaje en línea. Los productos de Desire2Learn incluyen una plataforma basada
en páginas web que combina Sistemas de Manejo de Aprendizaje, Sistemas
de Administración de Contenido, un Depósito de Objetos de Aprendizaje (LOR)
∗ http://www.cetis.ac.uk
† http://www.cen-ltso.net
‡ http://www.blackboard.com
§ http://www.desire2learn.com/

6 Capítulo 1. Introducción
y un número de otras herramientas para la educación en línea. La plataforma de
aprendizaje consiste de un paquete de herramientas de enseñanza y aprendizaje para
la creación, calificación, comunicación, manejo y entrega de cursos. El LOR es
un depósito basado en estándares para almacenaje, etiquetado, búsqueda y re-uso
de objetos de aprendizaje. Eso permite a las organizaciones manejar y compartir
contenidos a través de múltiples programas, cursos y secciones.
Joomla LMS: JoomlaLMS ∗ es un conjunto de poderosas herramientas de educación online.
Es un sistema totalmente funcional con innovadores métodos de formación,
opciones de evaluación (auto evaluaciones) y aplicaciones avanzadas de conferencia.
TimeCruiser: TimeCruiser † es otra plataforma LMS abalada por la experiencia de la
agrupación Timecruiser Computing Corporation iniciada en 1995.
WebCT: WebCT ‡ fue originalmente desarrollado en la Universidad de Columbia Británica,
en Canadá por un miembro de la escuela de ingeniería en informática, Murray
Goldberg. En 1995 Murray comenzó la búsqueda de sistemas basados en páginas
de web aplicados para la educación. Su investigación demostró que el nivel de satisfacción
del estudiante y el desempeño académico podían mejorar a través del uso de
recursos educativos basados en páginas de Internet. Para continuar su investigación
decidió construir un sistema que facilitara la creación de entornos educativos basados
en páginas web. De allí se originó la primera versión de WebCT. En 1997 Murray
creó la compañía WebCT Educational Technologies Corporation, una empresa
derivada de la Universidad de Columbia Británica. A mediados de 1999, WebCT
fue adquirido por Universal Learning Technology (ULT), una empresa con sede en
Boston, Estados Unidos, dirigida por Carol Vallone. Vallone continuó al mando de
la compañía hasta el punto de llegar a tener cerca de 10 millones de estudiantes en
80 países. Murray Goldberg se mantuvo como presidente de WebCT Canadá hasta
el 2002. WebCT tiene actualmente dos versiones: WebCT Vista y WebCT Campus
Edition. Vista es la versión profesional completa dirigida a empresas, y Campus
Edition (Versión Universitaria) es ofrecida a instituciones que ya tienen servicios
tales como de sistemas de almacenamiento de archivos y herramientas para registro
de cursos.
WebStudy Learning: WebStudy Learning § es otra plataforma LMS comercial desarrollada
por WebStudy, Inc. que ofrece una amplia variedad de servicios.
De entre ellas cabe mencionar a WebCT Vista y a Blackboard como dos de las más
utilizadas, y hay que destacar el hecho de que el 28 de febrero de 2006 se fusionaron con
el fin de crear una única plataforma.
Por otra parte, en lo que se refiere a las principales plataformas LMS de código libre
destacan las siguientes:
∗ http://www.joomlalms.com/
† http://www.timecruiser.com/
‡ http://www.webct.com
§ http://www.webstudy.com

1.1. Introducción al E-learning 7
.LRN: .LRN ∗ ofrece una completa herramienta para la creación y gestión de portales junto
con la capacidad de gestión de cursos, comunidades virtuales, gestión de contenidos
y gestión del aprendizaje. Originalmente fue desarrollado en el Massachusets
Institute of Technology (MIT). .LRN es hoy en día utilizado por cerca de medio millón
de usuarios en más de dieciocho países. El conjunto de aplicaciones .LRN está
respaldado por una próspera comunidad de usuarios y por el Consorcio .LRN. Los
miembros del Consorcio trabajan juntos para dar soporte a las respectivas implementaciones
y para acelerar y expandir la adopción y desarrollo de .LRN. Para este
fin, el Consorcio asegura la calidad del software certificando los componentes como
.LRN-conforme, coordina los planes de desarrollo del software y mantiene los
contactos con OpenACS, el conjunto de herramientas de software libre que forma
la base de .LRN.
ATutor: El proyecto ATutor † empezó en 2002 en colaboración con el Adaptive Technology
Resource Centre (ATRC) de la Toronto Universiy. Este centro es un líder
internacionalmente reconocido en el desarrollo de tecnologías y estándares que permitan
a la gente con discapacidades el acceso a las oportunidades E-learning y esta
misión ha influenciado profundamente el desarrollo de la plataforma. El desarrollo
ha prestado especial interés a la accesibilidad: ATutor es la única plataforma LMS
que cumple las especificaciones de accesibilidad W3C WCAG 1.0 de nivel AA+.
Bazaar: Bazaar ‡ es un desarrollo de la mayor universidad abierta de Canadá, la Universidad
de Athabasca. Empezó como un sistema de web board conferencing pero
ha evolucionado rápidamente en un sistema integrado de información. Bazaar es
un sistema muy flexible y configurable y puede ser usado para distribuir cursos,
portales o cualquier otro tipo de proyectos basados en la web.
Claroline: Claroline § es uno de los LMS más usados en el mundo. Muchas universidades
aprecian su ambiente de aprendizaje colaborativo que permite a los enseñantes y a
las instituciones educativas crear y administrar cursos en la web. Las herramientas
que ofrece el sistema son muchas (gestión de los grupos, forum, repositorios de
documentos, chat, administración del perfil de los usuarios, entre otras) y dan a los
usuarios la posibilidad de establecer cualquier escenario deseado.
Dokeos: El proyecto Dokeos empezó desde una versión previa de Claroline y se ha
convertido en un producto por sí mismo. El objetivo es ayudar al docente a crear
contenido pedagógico, a estructurar las actividades en caminos de aprendizaje, a
interaccionar con los estudiantes y a seguir su evolución mediante un sistema de
informes. Dokeos ha conseguido en poco tiempo el entusiasmo de sus usuarios.
Eledge: El proyecto Eledge ‖ desarrollado por la Universidad de Utah, es un entorno de
∗ http://dotlrn.org/
† http://www.atutor.ca/
‡ http://www.bazaar.org/
§ http://www.claroline.net/
http://www.dokeos.com/
‖ http://eledge.sourceforge.net/

8 Capítulo 1. Introducción
creación de un websites para la educación en línea que incluye el registro de estudiantes,
la autenticación, la creación de contenido, encuestas, exámenes, evaluación
de trabajos, uploads de informes, libro de notas del instructor, calendario de clase y
ayuda en línea.
FSL-OpenUSS LMS: OpenUSS ∗ es un sistema de administración basada en una base
de datos y centrado en: la comunicación y la publicación. Freestyle Learning (FSL)
es un Learning Content System (LCS) basado en Java 2 Platform Standard Edition
(J2SE) y GNU General Public License (GPL). FSL sirve para crear y ejecutar
contenidos multimedia.
Ganesha: Ganesha † permite al formador o a la organización formadora ofrecer a uno o
varios grupos de alumnos uno o varios módulos de aprendizaje, con contenidos, addons,
encuestas y tests de evaluación. También ofrece herramientas de colaboración
(webmail, foro, chat, compartición de documentos) y herramientas para la tutoría en
línea. Es un producto de software libre distribuido con licencia GPL y desarrollado
por la empresa de formación Anéma.
ILIAS: ILIAS ‡ es una plataforma que ofrece muchas funcionalidades a todos los niveles.
Con ILIAS es posible establecer diferentes escenarios e incluso entornos complejos
para todos los usuarios.
Moodle: Moodle § es uno de los LMS más populares y está actualmente viviendo una
fase explosiva de expansión. Su comunidad de usuarios y desarrolladores es muy
numerosa y se caracteriza por su entusiasmo respecto al sistema. Moodle es un
proyecto inspirado en la pedagogía del constructivismo social.
OLAT: OLAT (Online Learning And Training) es una plataforma de E-Learning basada
en Java completamente gratuita desarrollada desde 1999 en la Universidad de
Zurich (Suiza).
Sakai: Sakai ‖ es un ambicioso proyecto de dos años (2004-2005) fundado por la University
of Michigan, Indiana University, MIT, Stanford, el uPortal Consortium y
la Open Knowledge Initiative (OKI) con el apoyo de la Andrew W. Mellon Foundation.
Los socios de Sakai están uniendo fuerzas para integrar y sincronizar todo
su considerable software educativo en una colección pre-integrada de herramientas
de software libre. Los productos de este proyecto incluirán un Portal Institucional
basado en Servicios, un Sistema de Gestión de Cursos completo con sofisticadas
herramientas de evaluación, un Sistema Colaborativo de Apoyo a la Investigación,
un sistema de Flujo de Trabajo y un Technology Portability Profile (TPP) como
standard claro para escribir futuras herramientas que puedan extender el conjunto
central de aplicaciones educativas de Sakai.
∗ http://www.openuss.org/
† http://savannah.nongnu.org/projects/ganesha/
‡ http://www.ilias.de/
§ http://moodle.org/
http://www.olat.org/website/en/html/index.html
‖ http://sakaiproject.org/

1.2. Introduccion a la Biometría 9
Spaghetti Learning: SpaghettiLearning es una herramienta nacida y desarrollada en Italia.
Su interfaz es bastante diferente al de las herramientas más populares y resulta
interesante y fácil de usar. El soporte SCORM 1.2. es una de las funcionalidades
más importantes de la nueva versión. Es una buena plataforma para entornos pequeños
y medios.
DoceboLMS: Se puede decir que DoceboLMS ∗ ha nacido de una costilla de SpaghettiLearning,
pero es más que esto: es casi una reescritura del código de Spaghetti-
Learning, un producto que, aunque tiene una corta vida, ha sido bastante novedoso
respecto al resto de LMS de software libre. Muchas características del producto anterior
aún están disponibles en DoceboLMS (por ejemplo la conformidad a SCORM
1.2) pero también se han desarrollado nuevas funcionalidades y un nuevo interfaz.
Podemos afirmar que es un producto comparable con los más conocidos LMS.
1.2. Introduccion a la Biometría
En esta sección definiremos el concepto de autentificación biométrica, explicaremos
el funcionamiento de un sistema biométrico, presentaremos una comparativa entre las
principales modalidades biométricas, y terminaremos dando unas pinceladas sobre los
sistemas biométricos multimodales y sobre el concepto de fusión biométrica.
1.2.1. Introducción
El acceso automático de personas a servicios se está convirtiendo en una característica
muy importante en la era de la información. Esto ha resultado en la creación de una nueva
área tecnológica conocida como reconocimiento biométrico, o simplemente Biometría,
término que se deriva de las palabras griegas bios de vida y metron de medida. La meta
principal de la Biometría es la discriminación de un modo automático entre individuos
empleando uno o más rasgos físicos o comportamentales[Jain y otros, 2004]. Las huellas
dactilares, las retinas, el iris, los patrones faciales, de venas de la mano o la geometría de
la palma de la mano, representan ejemplos de características físicas, mientras que entre los
ejemplos de características del comportamiento se incluye la firma, el paso y el tecleo. La
voz se considera una mezcla de características físicas y del comportamiento, pero todos
los rasgos biométricos comparten aspectos físicos y del comportamiento.
En las Tecnologías de la Información (TI), la autentificación biométrica se refiere a las
tecnologías para medir y analizar las características físicas y del comportamiento humanas
con el propósito de autentificación. Como ejemplo de uso real, en Disney World, se toman
medidas biométricas de los visitantes con pase de varios días para asegurarse de que el
pase es usado por la misma persona todos los días.
∗ http://www.spaghettilearning.com/doceboCms/

10 Capítulo 1. Introducción
1.2.2. Sistema Biométrico
Un sistema biométrico es esencialmente un sistema de reconocimiento de patrones que
utiliza rasgos biométricos con el fin de reconocer individuos. El objetivo es determinar una
identidad basándonos en quién eres o qué tienes desde que naciste (who you are or what
you produce), en lugar de en qué posees (what you possess) o en qué sabes (what you
know). Este nuevo paradigma no sólo proporciona una mejora de la seguridad, sino que
también evita, en aplicaciones de autenticación, la necesidad de recordar diferentes claves.
La arquitectura general de un sistema biométrico puede ser dividida en dos categorías:
verificación e identificación [Jain y otros, 2004].
Aplicaciones de verificación: en las aplicaciones de verificación o autenticación, los
clientes o usuarios son conocidos por el sistema mediante una etapa previa de registro
en el sistema o enrollment. En tales aplicaciones, un usuario proporciona una
muestra biométrica B (por ejemplo, una huella dactilar) y la identidad que afirma
ser k, una comparación uno-contra-uno es llevada a cabo contra la plantilla biométrica
(template) almacenada y creada en la fase de registro por el usuario que afirma
ser. El resultado de la comparación es una puntuación de similitud (similarity score)
s que puede ser normalizada a x antes de compararla con el umbral de decisión
(decision threshold). Si el score es mayor que el umbral de decisión, el usuario es
aceptado, en otro caso el usuario es rechazado.
Aplicaciones de identificación: las aplicaciones de identificación reconocen un individuo
buscando sobre los clientes registrados. El proceso de identificación conlleva
comparaciones uno-contra-muchos para determinar la identidad del individuo.
Los trabajos realizados en esta Tesis se enfocan hacia la tarea de verificación o autenticación
biométrica. El objetivo de la autenticación biométrica es clasificar las señales
biométricas de entrada en dos clases, cliente o impostor. Dependiendo del sistema de verificación
biométrica, los impostores pueden conocer información sobre el cliente (por
ejemplo, forma de la firma en verificación por firma) que le resulte muy útil en el proceso
de engañar al sistema. Como resultado de esto, se consideran generalmente dos tipos de
impostores llamados casual impostors y skilled impostors.
En un sistema de autenticación biométrica, el rendimiento de una medida biométrica
se define generalmente en términos de Tasa de Falso Positivo (False Acceptance Rate
o FAR), de Tasa de Falso Negativo (False NonMatch Rate o FNMR, también False Rejection
Rate o FRR), y del Fallo de Tasa de Alistamiento (Failure-to-enroll Rate, FTR o
FER). En los sistemas biométricos reales la FAR y la FRR pueden transformarse en los
demás cambiando cierto parámetro. Una de las medidas más comunes de los sistemas
biométricos reales es la Tasa de Error Igual (Equal Error Rate o EER), también conocida
como la Tasa de Error de Cruce (Cross-over Error Rate o CER). Cuanto más bajo es el
EER o el CER, se considera que el sistema es más exacto.
1.2.3. Modalidades Biométricas
A lo largo de los últimos años un gran número de diferentes modalidades biométricas
han sido propuestas y son usadas en varias aplicaciones reales. Las modalidades biomé-

1.2. Introduccion a la Biometría 11
Figura 1.1: False Acceptance Rate (FAR) y False Rejection Rate (FRR) como funciones
del threshold t.
tricas fisiológicas incluyen imágenes de las orejas, de la cara, de la geometría de la mano,
del iris, de la retina, de la huella de la palma, o de la huella dactilar. Las modalidades biométricas
comportamentales incluyen la voz, la firma escrita, la forma de andar o la forma
de teclear. El ADN generalmente no se considera como una modalidad biométrica debido
a que los sistemas de identificación basados en él todavía requieren un modo de operación
manual y no pueden ser usados en tiempo real. Algunas de estas modalidades biométricas
tienen una larga historia y pueden ser consideradas a día de hoy como tecnologías
maduras, mientras que otras todavía son áreas jóvenes de investigación.
En teoría, cualquier característica humana puede ser usada como un rasgos biométrico
si satisface los siguientes requerimientos:
Universalidad: Significa que toda persona debe tener el rasgo biométrico.
Fiabilidad: Significa que dos personas deberían tener ese rasgo biométrico suficientemente
diferenciado.
Estabilidad: Significa que el rasgo biométrico debería tener una representación compacta
e invariante en un periodo de tiempo.
Recolectabilidad: Se refiere a la habilidad de medir el rasgo biométrico cuantitativamente.
Otros criterios requeridos para aplicaciones prácticas incluyen:
Prestaciones: Se refiere a la eficiencia, precisión, velocidad, robustez y requerimientos
de recursos específicos de implementaciones particulares basadas en rasgos biométricos.
Aceptabilidad: Hace referencia a las condiciones en que la gente está dispuesta a utilizar
el rasgo biométrico.
Sorteabilidad: Se refiere a la dificultad que ofrece al engaño por métodos fraudulentos,
el sistema basado en rasgos biométricos.
En el Cuadro 1.1 se recoge una comparativa entre diferentes modalidades biométricas.

12 Capítulo 1. Introducción
Figura 1.2: Distribución de scores para accesos de clientes (azul) e impostores (rojo).
Representación de las tasas FAR y FRR.
1.2.4. Sistemas Biométricos Multimodales y Fusión Biométrica
En un entorno real puede suceder que los sistemas de autenticación basados solamente
en una modalidad biométrica no completen los requisitos o requerimientos de seguridad
necesarios que demandan ciertas aplicaciones en los términos descritos anteriormente
(universalidad, peculariedad, recolectabilidad, prestaciones, aceptabilidad y sorteabilidad).
Eso es lo que ha motivado el actual interés en los rasgos biométricos multimodales
o multimodal biometrics, en los cuales, varios rasgos biométricos son usados simultáneamente
[Jain y otros, 2004]. Hay numerosos beneficios en realizar esto, pero por nombrar
algunos pocos: descienden los valores de las Tasas de Falsa Aceptación y de Falso Rechazo,
el sistema de autenticación se vuelve más robusto frente a fallos individuales de
sensores, el número de casos donde el sistema no es capaz de tomar una decisión se reduce
considerablemente (por ejemplo, por la mala calidad de las huellas digitales de un
trabajador manual), etc. Hay que destacar el hecho de que el entorno tecnológico actual es
también apropiado debido a la gran difusión de dispositivos multimodales (PDAs, móviles
3G, Tablet PCs, etc.).
Un sistema biométrico está generalmente dividido en cuatro módulos: el sensor que
adquiere la muestra biométrica, el módulo de extracción de características que procesa
la muestra biométrica para obtener la representación compacta de los datos biométricos
de entrada, el módulo de comparación que calcula la similitud entre el vector de

1.3. Motivación y Objetivos de la Tesis 13
Universalidad
Fiabilidad
Estabilidad
Recolectabilidad
Prestaciones
Aceptabilidad
Sorteabilidad
Biometría
Facial A B M A B A A
Geometría de la Mano M M M A M M M
Iris A A A M A B B
Voz M B B M B A A
Firma B B B A B A A
Huella M A A M A M M
Tabla 1.1: Tabla comparativa de Tecnologías Biométricas. Alta, Media, y Baja son etiquetadas
por A, M, y B, respectivamente.
características de entrada y las plantillas almacenadas dando como resultado los scores,
y finalmente, el módulo de decisión que devuelve una decisión de identificación o
verificación basándose en los scores. La fusión de información se puede llevar a cabo
en la salida de cualquiera de estos cuatro módulos, resultando los siguientes niveles de
fusión[Fiérrez Aguilar, 2006]:
Fusión a nivel de sensor: Este tipo de fusión hace referencia a la combinación de datos
puros desde los sensores biométricos. Un ejemplo es la combinación de varias caras
para obtener una entrada biométrica de cara en 3D.
Fusión a nivel de características: Este tipo de fusión se refiere a la combinación de diferentes
vectores de características, obtenidos con diferentes sensores o aplicando
diferentes algoritmos de extracción de características a los mismos datos puros.
Fusión a nivel de puntuación: Este tipo de fusión hace referencia a la combinación de
las puntuaciones de similitud obtenidas por sistemas diferentes.
Fusión a nivel de decisión: Este tipo de fusión se refiere a la combinación de las decisiones
ya tomadas por los sistemas biométricos individuales.
Para concluir esta sección debemos indicar que lo mas común en multibiometría es
realizar la fusión a nivel de puntuación.
1.3. Motivación y Objetivos de la Tesis
La problemática expuesta en las secciones anteriores, referentes a las carencias actuales
de las plataformas de E-Learning que pueden ser cubiertas con la aplicación del
reconocimiento biométrico, nos lleva a plantear los siguientes objetivos para esta Tesis:

14 Capítulo 1. Introducción
Diseño de una solución abierta que ofrezca un servicio de autenticación de usuario,
basado en el uso de rasgos biométricos, en el que puedan delegar las plataformas
Web de aprendizaje electrónico para la verificar la identidad de sus usuarios.
Tomando Central Authentication Service (CAS) como modelo de servicio de autenticación
single sign-on (sección 3.2.1), e integrando dentro de él, el Framework
BioAPI, como infraestructura de conexión con los distintos dispositivos y software
biométricos realizados por terceros (sección 3.1.1).
Diseño de una solución abierta que ofrezca un servicio de monitorización de usuario,
basado en el uso de rasgos biométricos, en el que las plataformas Web de aprendizaje
electrónico puedan recuperar información detallada sobre el comportamiento
del estudiante durante el acceso a sus contenidos, en términos de tiempo de presencia
y de atención. Utilizando como punto de partida el sistema diseñado en el primer
objetivo de esta Tesis, y añadiendo un módulo de seguimiento basado en la aplicación
de detección y verificación facial sobre el flujo de vídeo de la webcam del
equipo del alumno.
1.4. Estructura de la Tesis
El resto de esta Tesis esta organizado de la siguiente manera:
El capítulo 2 repasa el estado actual de las propuestas que aplican la Biometría
al entorno Web como mecanismo de autenticación o monitorización, intentando
particularizar en las plataformas de E-learning.
El capítulo 3 expone pormenorizadamente la base tecnológica en la que se asientan
las tecnologías utilizadas a lo largo de esta Tesis, explicando su funcionamiento.
Esta explicación sirve para entender los sistemas que se presentan en los siguientes
capítulos.
En el capítulo 4 se presenta la plataforma BioWebAuth (Biometrics for Web Authentication)
(BWA) que proporciona un servicio de autenticación centralizada para
portales Web utilizando rasgos biométricos, y que puede ser aplicado a distintas
plataformas de E-learning.
En el capítulo 5 se muestra la plataforma BioWebMonitor (Biometrics for Web
Monitoring) (BWM) que proporciona un servicio de monitorización del comportamiento
del estudiante utilizando seguimiento biométrico. Actualmente incorpora
componentes que proporcionan la medición del tiempo de presencia y del tiempo
de atención que se ha dedicado a cada contenido de aprendizaje. Su estructura
abierta permite añadir nuevos componentes que mejoren el proceso de monitorización,
como por ejemplo, detección de estado de ánimo del estudiante, o estimación
del tiempo de lectura dedicado a cada contenido. Todo ello, con el fin de obtener
unos registros que reflejen fielmente el comportamiento del estudiante durante la
sesión de aprendizaje. Con el fin de evaluar las prestaciones del sistema presentado
se realizó un experimento en un escenario real donde se monitorizó a 25 alumnos
mientras utilizaban la plataforma Moodle para la realización de unos cuestionarios.

1.4. Estructura de la Tesis 15
Finalmente, el capítulo 6 presenta las contribuciones, las conclusiones, y las líneas
futuras de trabajo de esta Tesis Doctoral.

Capítulo 2
Estado del Arte
Contenido
2.1. Estado del Arte en E-learning . . . . . . . . . . . . . . . . . . . . . 18
2.1.1. Advanced Distributed Learning y SCORM . . . . . . . . . . . 19
2.1.2. IMS Global Learning Consortium y Common Cartridge . . . . 20
2.1.3. Seguridad en Plataformas de E-learning . . . . . . . . . . . . . 22
2.2. Estado del Arte en Biometría . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1. Estándares asociados a Tecnologías Biométricas . . . . . . . . 25
2.2.2. El Consorcio BioAPI y El Estándar BioAPI . . . . . . . . . . . 25
2.3. Aplicación de Sistemas Biométricos en E-learning . . . . . . . . . . 26
2.3.1. Control de Acceso . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2. Monitorización de Estudiante . . . . . . . . . . . . . . . . . . 28
2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Este capítulo presenta el Estado del Arte en el marco en el que se encuadra esta Tesis,
y repasa los principales trabajos publicados que están relacionados con los objetivos de
la misma. Para empezar, haremos una revisión sobre el Estado del Arte en las tecnologías
de aprendizaje electrónico, presentando las principales organizaciones de estandarización,
los estándares actuales más relevantes, y las medidas de seguridad que ofrecen las plataformas
de aprendizaje electrónico. Continuaremos con un resumen sobre el Estado del
Arte actual en Biometría citando también sus organizaciones y estándares más relevantes.
Finalmente, concluiremos el capítulo haciendo un resumen de las publicaciones existentes
en la literatura en las que se proponen la aplicación de sistemas biométricos en el ámbito
del aprendizaje electrónico. Este resumen se realizará diferenciando las contribuciones en
dos categorías: control de acceso de los estudiantes y monitorización del comportamiento
de los mismos.

18 Capítulo 2. Estado del Arte
2.1. Estado del Arte en E-learning
Debido a la evolución y a la ubicua presencia del E-learning surge la necesidad de
que el material ofrecido en cada LMS sea intercambiable. Especificaciones y estándares
internacionales definen un marco común en el que el software educativo es adaptable,
intercambiable y reutilizable. Pero el E-learning es tan vasto y trata aspectos tan variados
que dichos estándares tienen que crearse de forma gradual [Gutiérrez Santos, 2007].
El mundo del E-learning ha evolucionado rápidamente en los últimos años. Las herramientas
actuales son capaces de integrar tareas no sólo académicas sino también administrativas
en las instituciones de enseñanza. Los sistemas de gestión de contenido educativo
o Learning Content Managament System (LCMS) son capaces de hacerse cargo de una
serie de tareas que abarcan desde el pago de matrículas hasta enfoques pedagógicos personalizados
y actividades colaborativas. Una presencia tan extendida de las actividades de
aprendizaje hace recomendable, si no necesario, que el material educativo sea intercambiable
entre diferentes plataformas. Un curso que sólo puede ser usado en una plataforma
está condenado a que sólo un pequeño porcentaje de sus usuarios potenciales se beneficien
de su uso. Adicionalmente, en este nuevo escenario el material de enseñanza incluye una
variedad mucho más extensa de recursos y, por tanto, el proceso de producción ha incrementado
su complejidad. En conclusión, las plataformas de E-learning deben garantizar
interoperabilidad entre ellas: ofrecer la posibilidad de reutilizar recursos de otros cursos
aumenta mucho la productividad del proceso de creación.
La respuesta a estas necesidades viene dada por los estándares internacionales que
definen un marco común para hacer el software educativo adaptable, reutilizable e interoperable.
A nivel mundial el principal organismo que coordina las actividades de estandarización
relacionadas con el campo de las tecnologías de aprendizaje es el Sub-Comité
36 (SC36 ∗ ) del Joint Technical Committee on Information Technology (ISO/IEC JTC1),
del International Standards Organisation (ISO) y el International Electrotechnical Commission
(IEC).
A nivel nacional, la institución española que participa en ISO es la Asociación Española
de Normalización AENOR que ha creado el subcomité técnico AEN/CTN71/SC36
Tecnologías de la información para el aprendizaje. Su misión es la Normalización de aplicaciones,
productos, servicios y especificaciones relacionados con las tecnologías educativas,
formativas o de aprendizaje a nivel individual, de organización o de grupo, con el
fin de habilitar la interoperabilidad y la reutilización de herramientas y recursos.
Existen además otros organismos impulsando iniciativas en materias de aprendizaje
electrónico, como veremos en los siguientes apartados, pero es importante notar que hay
pocos estándares como tal en el mundo del E-learning. Definir dichos estándares es algo
complejo, puesto que el E-learning toca múltiples aspectos de varios campos. Las herramientas
disponibles van adoptando estos estándares de forma gradual, proporcionando en
algunos casos sólo un nivel parcial de conformidad. El proceso es largo y laborioso hasta
que un organismo oficial de estandarización ratifica una propuesta que ya es aceptada por
toda la comunidad. Tras unos primeros años con numerosas propuestas de estándares incompatibles
entre sí, el panorama se ha aclarado en los últimos años y se está produciendo
∗ http://jtc1sc36.org/

2.1. Estado del Arte en E-learning 19
una convergencia alrededor del proyecto SCORM, que está aglutinando a su vez el trabajo
de AICC, IEEE LTSC y, sobre todo, IMS [MEC, WWW].
2.1.1. Advanced Distributed Learning y SCORM
La iniciativa Advanced Distributed Learning (ADL), es una organización creada originalmente
por el Departamento de Defensa de los U.S.A. para trabajar con agencias
federales, instituciones académicas y miembros de la industria, así como para desarrollar
especificaciones para tecnología de apoyo al aprendizaje. ADL trabaja junto a diversas
organizaciones de especificación y estandarización como International Standards Organisation
(ISO), Institute of Electrical and Electronics Engineers (IEEE) e IMS para desarrollar
guías orientadas a hacer el software educativo accesible, adaptable, interoperable,
y reutilizable. Más que jugar un papel de desarrollador de estándares, esta institución actúa
como guía en el proceso. La contribución más conocida de ADL es el modelo de
referencia para objetos de contenido reutilizable o Shareable Content Object Reference
Model (SCORM) [SCORM, 2004]. El modelo define la forma en que los sistemas de
aprendizaje deben manejar el contenido del curso basado en web y servirlo a los usuarios.
SCORM utiliza especificaciones y guías propuestas por otras instituciones pero lo agrupa
todo bajo el paraguas de su propio modelo. La mayor contribución del modelo no está en
ningún aspecto concreto del E-learning sino en cómo deben integrarse todos ellos para
conseguir un sistema de E-learning efectivo. En el caso ideal, si los desarrolladores de
contenido por un lado y los desarrolladores de sistemas por el otro siguieran este modelo,
el material de aprendizaje se integraría sin problemas en cualquier plataforma.
La idea subyacente al modelo SCORM es la de considerar un curso basado en web
como una colección de objetos de contenido que están interconectados. Para que esta idea
se pueda trasladar a plataformas que funcionen es necesario considerar múltiples aspectos:
organización del contenido, metadatos, secuenciamiento, etc. SCORM se divide en tres
submódulos, cada uno de los cuales se encarga de una faceta del E-learning: modelo de
agregación de contenidos, entorno de ejecución, y navegación y secuenciamiento.
Modelo de agregación de contenidos: Define cómo hay que ensamblar, etiquetar y empaquetar
el contenido. SCORM es un modelo basado en objetos, por lo que es necesaria
una descripción detallada sobre cómo se conectan dichos objetos. Una experiencia
de aprendizaje se compone, en este contexto, de activos (assets), objetos
de contenido compatible (Shareable Content Objects, SCOs) y organizaciones de
contenido. Un Shareable Content Objects (SCO) está compuesto de varios activos,
y varios SCOs componen una organización de contenido. Ejemplos de activos son:
documentos HTML, ficheros de audio o vídeo, etc. Los SCOs contienen un conjunto
de activos y deben ser ejecutables por el LMS. Una organización de contenido
describe cómo se organizan un conjunto de SCOs en una estructura de árbol de
ramificación arbitraria. Las hojas de dicho árbol deben ser SCOs o activos ejecutables.
Entorno de ejecución: Describe el proceso de ejecución que debe realizar un LMS con
un SCO, así como el proceso de comunicación entre ambos. Un estudiante sólo
tiene un SCO activo en cada momento. El modelo no especifica qué controles de

20 Capítulo 2. Estado del Arte
navegación deben presentarse al usuario para elegir diferente material. La comunicación
entre el SCO y el sistema se produce a través de un interfaz de programación
de aplicaciones que sí es parte del modelo. También se denomina Runtime Environment
(RTE).
Navegación y secuenciamiento: SCORM hace uso de múltiples especificaciones así como
del estándar IEEE LOM. El modelo propuesto describe como debe manejarse
el material de E-learning; las especificaciones se adoptan como parte del modelo
para la mayoría de los asuntos concretos de este manejo. Por ejemplo, en el caso
del secuenciamiento (uno de los múltiples aspectos considerados por SCORM), el
modelo describe cómo dicho secuenciamiento interactúa con el resto del RTE; sin
embargo, la descripción del proceso de secuenciamiento se hace usando la especificación
IMS Simple Sequencing.
Es muy probable que, a medida que nuevas especificaciones aparecen en relación con
nuevos aspectos relacionados con el E-learning, las especificaciones de SCORM futuras
los irán incluyendo como parte del modelo. SCORM es el modelo más ampliamente
aceptado por los actuales LMS. Las herramientas actuales soportan la importación y exportación
de cursos en SCORM, y esto se traduce en un cierto grado de reutilización. El
mayor problema a la hora de crear un curso con una herramienta e importarlo en otras de
forma efectiva está en el grado de conformidad. SCORM es un modelo muy vasto basado
en un conjunto extenso de especificaciones, de forma que un fabricante suele soportar sólo
un subconjunto de la funcionalidad. Debido a las variaciones en estos subconjuntos, no
es infrecuente disponer de material conforme a SCORM que se ejecuta en una plataforma
pero no en otra. Esto ha llevado a que SCORM publique un conjunto de requerimientos de
compatibilidad especificando cuáles son los aspectos críticos que las herramientas deben
incluir para conseguir la certificación de conforme a SCORM (SCORM compliant).
2.1.2. IMS Global Learning Consortium y Common Cartridge
El consorcio IMS Global es una organización sin ánimo de lucro orientada a facilitar
la adopción de tecnologías de E-learning en todo el mundo. Entre sus miembros hay
fabricantes, proveedores de contenidos, instituciones educativas, editores, organizaciones
gubernamentales y otros consorcios, que pertenecen a más de 50 países. Su labor se centra
en promover la adopción de especificaciones técnicas abiertas para alcanzar la interoperabilidad
real entre tecnologías. El impacto del consorcio está fuera de toda duda: SCORM
incluye varias de sus especificaciones y parte de la comunidad del E-learning desarrolla
una activa labor investigadora alrededor de las mismas. Varias se han convertido en estándares
de facto para productos y servicios de E-learning. Las especificaciones de IMS se
ocupan de múltiples aspectos del E-learning, lo que hace difícil abarcar el conjunto en su
totalidad.
IMS Global Learning Consortium ha publicado la versión 1.0 de la especificación del
Common Cartridge (IMS CC), un nuevo estándar de contenidos digitales de aprendizaje
que define un perfil de uso de tres especificaciones previamente existentes, más una
completamente nueva:

2.1. Estado del Arte en E-learning 21
IEEE Learning Object Metadata: El Instituto de Ingenieros Eléctricos y Electrónicos
(Institute of Electric and Electronic Engineers, IEEE) es una organización sin ánimo
de lucro que ofrece información técnica y profesional, recursos y servicios a una
gran parte de la comunidad ingenieril. Dentro del IEEE, el Comité de estándares de
tecnologías educativas (LTSC) se enfoca al desarrollo y publicación de estándares
técnicos así como a la recomendación de prácticas y guías en relación con las tecnologías
educativas. Sus tareas se organizan en grupos de trabajo especializados en
diferentes aspectos del abanico del E-learning. La contribución más relevante del
IEEE LTSC es la publicación del estándar de metadatos de objetos de aprendizaje
Learning Object Metadata (LOM), un esquema conceptual de datos que define
la estructura de una instancia de metadatos para objetos de aprendizaje. En este
contexto, un objeto de aprendizaje es simplemente cualquier entidad que pueda ser
utilizada para aprender. El objetivo de este estándar es definir el conjunto mínimo de
atributos (metadatos) que deben adjuntarse a estos objetos de aprendizaje para manejarlos.
Estos atributos intentan capturar no sólo aspectos administrativos simples
(ej. autor, título, fecha de creación, etc) sino también aspectos pedagógicos (ej. nivel
de dificultad, enfoque pedagógico, prerrequisitos, etc). Una característica importante
de LOM es que contempla la posibilidad de extender el conjunto de atributos para
propósitos específicos. IMS CC utiliza la versión 1.0 de esta especificación.
IMS Content Packaging: IMS CP es una especificación básica para facilitar la interoperabilidad
entre los sistemas de E-Learning, ya que dichos sistemas pueden intercambiar
materiales empaquetados de acuerdo a IMS CP, es decir, especifica el
empaquetado de contenidos. Un sistema que soporta IMS CP (por ejemplo, una herramienta
de autor, un sistema de gestión del aprendizaje, una biblioteca digital de
recursos educativos, etc.) será capaz de abrir los paquetes IMS, independientemente
de la forma y el lugar en los que dichos paquetes hayan sido producidos. IMS CC
utiliza la versión 1.2 de esta especificación.
IMS Question & Test Interoperability: La especificación IMS Question and Test Interoperability
(IMS QTI) permite crear preguntas individuales y evaluaciones completas.
El objetivo principal de esta especificación es permitir el intercambio de
preguntas, evaluaciones y resultados entre distintas herramientas. Con este propósito
IMS QTI plantea un modelo en el que se definen los componentes principales
que intervienen en el proceso de evaluación y, adicionalmente a este modelo,
se proporciona un formato de contenido para almacenar las preguntas de manera
independientemente del sistema o herramienta de autoría utilizada para crearlas.
Este formato, basado en XML, hace uso de estándares ampliamente utilizados en
el ámbito empresarial y técnico, permitiendo el uso de las mismas preguntas entre
diversos sistemas de gestión de aprendizaje o LMS, entre sistemas de evaluación
electrónica independientes y la integración en un único LMS de preguntas y exámenes
desarrollados con distintas herramientas. Por otro lado se propone un sistema
coherente para que los sistemas puedan informar de cual es el resultado de una evaluación.
IMS QTI permite la construcción de almacenes o repositorios de preguntas
que sean directamente utilizables en distintos sistemas LMS (e incluso para crear e
imprimir exámenes tipo test que los alumnos realicen por escrito). IMS CC utiliza

22 Capítulo 2. Estado del Arte
la versión 1.2.1 de esta especificación.
IMS Authorization Web Service: Se trata de una especificación que define un protocolo
de autorización que permite al editor de un paquete controlar el acceso a sus
contenidos. IMS CC utiliza la versión 1.0 de esta especificación.
La motivación que ha impulsado este trabajo ha sido comunicar, claramente y sin
ambigüedades, cómo utilizar la citada colección de especificaciones para distribuir contenidos
web ricos, en un formato que ofrezca un alto grado de interoperabilidad entre
plataformas.
Con el Common Cartridge, IMS ha optado por simplificar lo máximo posible y dejar
de lado la mayoría de características opcionales y extensiones. Así, para los metadatos
sólo se usan los quince elementos de Dublin Core, mapeados a los elementos correspondientes
de Learning Object Metadata (LOM), y en cuanto a Question & Test Interoperability
(QTI) sólo se contemplan los seis tipos de preguntas más comunes. Se han añadido,
en cambio, nuevas características cuando se ha estimado necesario:
Un nuevo tipo de recurso que sirve para iniciar un fórum de debate.
Un protocolo de autorización (IMS Authorization Web Service) que permite al editor
de un paquete controlar el acceso a sus contenidos.
En este sentido, es un estándar de estándares. Más allá de los detalles se trata de un
formato de empaquetado destinado a facilitar la importación y exportación de contenidos.
El estándar ha considerado también los estándares IMS Tools Interoperability Guidelines
v1.0 y SCORM 1.2 y 2004, si bien SCORM como tal no forma parte de la especificación.
Cuenta con el compromiso de ANGEL Learning, Blackboard, Sakai, McGraw-Hill y
otros desarrolladores de software y de materiales de E-learning. La herramienta eXe ya
lo incorpora y la versión 2.0 de Moodle (aún en desarrollo) tiene previsto incorporarlo.
Aunque es un estándar que aparece bien respaldado y pese al esfuerzo de simplificación
vuelve a ser otro estándar más en versión 1.0, lo que revela la falta de madurez de las
tecnologías y estándares de E-learning. Un grupo de tecnologías que deberán evolucionar
bastante en los próximos años, especialmente para integrar tanto la filosofía 2.0 como las
novedades de la web 3.0.
2.1.3. Seguridad en Plataformas de E-learning
Las actuales prácticas de seguridad en sistema de E-learning residen principalmente en
la utilización de claves como mecanismos de autenticación. Las publicaciones referentes a
los retos de seguridad en entornos de E-Learning se centran en la protección de la infraestructura
tecnológica contra usuarios no autorizados, como es el caso de [Yu y Tsao, 2003].
De un modo similar, en el artículo [Huang y otros, 2004] se tratan aspectos relacionados
con la seguridad en LMSs, sugiriendo centrarse en dos capas cuando se pretenda asegurar
un sistema de E-learning. La primera de estas capas engloba lo referente a la seguridad
que ofrece la infrastructura tecnológica usada para facilitar el aprendizaje (hardware, redes,
etc.). La segunda capa se refiere a las distintas aplicaciones empleadas en las tareas de
aprendizaje (LMSs, herramientas de comunicación, etc.). Algunos autores critican a los

2.2. Estado del Arte en Biometría 23
sistemas de E-learning existentes por no prestar suficiente atención a la tarea de autenticación
de estudiante, en particular durante la realización de cuestionarios y exámenes. En el
artículo [Hugl, 2005] se describen numerosas tecnologías existentes relacionadas con la
seguridad que en ese momento no se estaban aplicando en E-learning. Una de esas soluciones
contemplaba incluir tecnologías biométricas que potencialmente llegarían a formar
parte de los sistemas de E-learning.
2.2. Estado del Arte en Biometría
En los últimos años se ha notado una preocupación creciente por las organizaciones
regulatorias respecto a elaborar estándares relativos al uso de técnicas biométricas en el
ambiente informático. Esta preocupación es reflejo del creciente interés industrial por
este ámbito tecnológico, y a los múltiples beneficios que su uso aporta. No obstante, a
día de hoy la estandarización continúa siendo deficiente y como resultado de ello, los
proveedores de soluciones biométricas continúan suministrando interfaces de software
propietarios para sus productos, lo que dificulta a las empresas el cambio de producto o
vendedor.
A nivel mundial el principal organismo que coordina las actividades de estandarización
biométrica es el Sub-Comité 17 (SC17) del Joint Technical Committee on Information
Technology (ISO/IEC JTC1), del International Organization for Standardization
(ISO) y el International Electrotechnical Commission (IEC). En Estados Unidos
desempeñan un papel similar el Comité Técnico M1 del INCITS (InterNational
Committee for Information Technology Standards), el National Institute of Standards
and Technology (NIST) y el American National Standards Institute (ANSI). En
2002 se creó el ISO/IEC JTC1/SC37 Biometrics determinando que su campo de actividad
sea el de las tecnologías biométricas genéricas, correspondientes a seres humanos,
para aportar interoperabilidad e intercambio de datos entre aplicaciones y sistemas
[Sánchez Reíllo y Luis Puebla, WWW]. Las normas sobre identificación biométrica humana
genérica, incluyen: entornos de ficheros comunes, interfaces de programación de
aplicaciones biométricas, formato de intercambio de datos biométricos, perfiles relacionados
con la biometría, aplicación de criterios de evaluación para las tecnologías biométricas,
metodologías para la verificación y emisión de informes sobre el rendimiento de
los sistemas, y los aspectos sociales y jurisdiccionales. De todo este trabajo se excluye:
El trabajo realizado dentro del ISO/IEC JTC1/SC17, sobre la aplicación de las tecnologías
biométricas a las tarjetas y la identificación personal.
El trabajo realizado dentro del ISO/IEC JTC1/SC27, sobre las técnicas de protección
de los datos biométricos, la verificación de la seguridad biométrica, sus evaluaciones
y sus metodologías de evaluación.
Para llevar a cabo todo este trabajo, en el SC37 se estableció una estructura inicial
dividida en seis Grupos de Trabajo (WG - Working Groups), cada uno de ellos destinado
a trabajar en un aspecto determinado del campo de la Identificación Biométrica:

24 Capítulo 2. Estado del Arte
WG1 Harmonised Biometric Vocabulary: Encargado de crear un catálogo de términos
estandarizados que cubran todos aquellos conceptos relacionados con los sistemas
biométricos.
WG2 Biometric Technical Interfaces: Su ámbito de trabajo incluye los interfaces de
comunicación entre aplicaciones y sistemas.
WG3 Biometric Data Interchange Formats: Destinado a estipular los formatos de datos
para cada una de las distintas modalidades biométricas.
WG4 Biometric Functional Architecture & Related Profiles: Su misión es la de definir
las distintas arquitecturas biométricas y los distintos perfiles de aplicación.
WG5 Biometric Testing and Reporting: Encargado de definir los mecanismos de evaluación
de los sistemas biométricos, desde el punto de vista de la funcionalidad, así
como de indicar la forma en la que deben hacerse los informes de dichas evaluaciones.
WG6 Cross-jurisdictional and Societal Aspects: Se encarga de estudiar los efectos jurídicos
de la instalación de sistemas biométricos, así como la influencia social de su
aplicación.
Cada grupo de trabajo tiene un coordinador responsable, y la presidencia y secretaría
de todo el Subcomité la ostenta actualmente Estados Unidos, en las personas Fernando
Podio, como Presidente, y Lisa Rajchel, como Secretaria. Durante estos primeros años de
vida, el Subcomité ISO/IEC JTC1/SC37, se ha caracterizado por un intenso y fructífero
trabajo. Después de 4 años de vida, ya cuenta con cerca de una decena de estándares publicados,
así como muchos en fases finales de elaboración, y muchas otras vías de trabajo
abiertas. Para ello se sigue el un esquema de trabajo basado en dos reuniones anuales de
los WG, una en enero, y la otra a finales de junio, así como de una reunión plenaria, que
coincide con una de la reunión de verano de los WG. Si se considera necesario que existan
reuniones y trabajo común durante el tiempo existente entre reunión y reunión, cada
WG puede constituir Grupos de Trabajo Especializados (Special Groups), de forma que
se pueda avanzar más rápidamente.
A nivel nacional, el pasado 16 de junio de 2006, se procedió a la Constitución formal
del Subcomité AEN/CTN71/SC37 con el título de Identificación Biométrica. Se decidió
que el Campo de Actividad fuera el mismo que el del Subcomité internacional, y que en
el futuro se determinase una estructura totalmente a imagen de la de ISO.
Existen además otros organismos no gubernamentales impulsando iniciativas en materias
biométricas tales como: Biometrics Consortium, International Biometrics Groups y
BioAPI Consortium. Este último se estableció en Estados Unidos en 1998 compuesto por
las empresas Bioscrypt, Compaq, Iridiam, Infineon, NIST, Saflink y Unisis. El Consorcio
BioAPI desarrolló conjuntamente con otros consorcios y asociaciones, un estándar que
promoviera la conexión entre los dispositivos biométricos y los diferentes tipos de programas
de aplicación, además de promover el crecimiento de los mercados biométricos.

2.2. Estado del Arte en Biometría 25
2.2.1. Estándares asociados a Tecnologías Biométricas
En esta sección enumeraremos algunos de los estándares más importantes creados por
los organismos presentados en la sección anterior:
Estándar ANSI X.9.84: Fue creado en 2001 por la American National Standards Institute
(ANSI) y actualizado en 2003. En el se definen las condiciones de los sistemas
biométricos para la industria de servicios financieros haciendo referencia a la transmisión
y almacenamiento seguro de información biométrica, y a la seguridad del
hardware asociado.
Estándar ANSI / INCITS 358: Fue creado en 2002 por ANSI y BioApi Consortium,
presenta una interfaz de programación de aplicación que garantiza que los productos
y sistemas que cumplen este estándar son interoperables entre sí. Se trata de la
BioAPI Specification en la que profundizaremos en las próximas secciones.
Estándar NISTIR 6529: Fue creado en 1999 por el National Institute of Standards and
Technology (NIST) y Biometrics Consortium. También es conocido como CBEFF
(Common Biometric Exchange File Format) y se trata de un estándar que propone
un formato estandarizado (estructura lógica de archivos de datos) para el intercambio
de información biométrica.
Estándar ANSI 378: Fue creado en 2004 por la ANSI y establece criterios para representar
e intercambiar la información de las huellas dactilares a través del uso de
minucias. El propósito de esta norma es que un sistema biométrico dactilar pueda
realizar procesos de verificación de identidad e identificación, empleando información
biométrica proveniente de otros sistemas.
Estándar ISO 19794-2: Fue creado en 2005 por la ISO/IEC con propósitos similares a
la norma ANSI 378, respecto a la que guarda mucha similitud.
Estándar PIV-071006: Fue creado en 2006 por el NIST y el FBI en el contexto de la
norma FIPS 201 del gobierno de E.E.U.U., establece los criterios de calidad de
imagen que deben cumplir los lectores de huellas dactilares para poder ser usados
en procesos de verificación de identidad en agencias federales.
2.2.2. El Consorcio BioAPI y El Estándar BioAPI
El Consorcio BioAPI fue fundado para desarrollar una Application Programming Interface
(API) biométrica que ofreciera a los programadores de aplicaciones y de servicios
biométricos la independencia de los dispositivos y software biométricos. El consorcio es
un grupo que cuenta aproximadamente con 120 compañías y organizaciones que tienen el
interés común de promover el crecimiento del mercado biométrico. La especificación y la
implementación de referencia de la estandarizada BioAPI es compatible con una amplia
gama de aplicaciones biométricas y un enorme espectro de tecnologías biométricas.
La especificación BioAPI pretende proporcionar un modelo de autenticación biométrica
genérico de alto nivel adecuado para cualquier tipo de tecnología biométrica. Cubre

26 Capítulo 2. Estado del Arte
las funciones básicas de Enrollment, Verificación e Identificación, e incluye una base de
datos que permite a un Biometric Service Provider (BSP) gestionar la población sobre la
que se efectuará el proceso de Identificación para ofrecer un rendimiento óptimo. También
proporciona primitivas de bajo nivel que permiten a la aplicación gestionar la captura
de las muestras en un equipo cliente, y efectuar, del lado del servidor, los procesos
de creación del template, extracción de características, verificación e identificación. Esta
especificación define dos interfaces para estandarizar el acceso a la tecnología biométrica
que son la Application Programming Interface y la Service Provider Interface. Fuera de
su alcance queda la definición de los requerimientos de seguridad de las propias aplicaciones
biométricas y de los proveedores de servicios biométricos, aunque si se incluye en
la documentación de la BioAPI alguna información sobre buenas prácticas en temas de
seguridad.
2.3. Aplicación de Sistemas Biométricos en E-learning
Los Sistemas de E-learning, como ya hemos mencionado anteriormente, representan
una nueva forma de aprendizaje que está en continua expansión debido a las ventajas
que proporcionan, pero en la que todavía existen carencias que frenan su aplicación en
determinados ámbitos. Paralelamente, la Biometría se ha convertido en un método de verificación
e identificación que ofrece grandes posibilidades y que se debe tener en cuenta.
Ya hemos presentado las carencias de los LMSs en las tareas de autenticación remota
del alumno y de monitorización continua del mismo durante la realización de un curso
virtual. Muchos autores muestran su descontento hacia el hecho de que actualmente se
dedican pocos recursos a estos aspectos en los sistemas LMSs. Por ejemplo, en el artículo
[Rabuzin y otros, 2006] los autores argumentan que las tecnologías biométricas todavía
no están siendo suficientemente utilizadas en la educación a distancia, y que ciertos
problemas relativos a la verificación de usuarios en sistemas de E-learning pueden ser
resueltos por medio de su uso.
A continuación presentaremos las principales publicaciones presentes en la literatura
y relacionadas con el trabajo presentado en esta Tesis. Agruparemos las contribuciones
en dos categorías diferenciadas según su aportación: control de acceso del estudiante, y
monitorización del comportamiento del mismo.
2.3.1. Control de Acceso
En esta subsección citaremos las principales publicaciones en las que se proponga la
aplicación de rasgos biométricos en el mecanismo de control de acceso de las plataformas
de E-learning.
En el artículo [Jonas Richiardi, 2005] se presenta el diseño y la implementación de un
sistema distribuido que ofrece un servicio de verificación biométrica multimodal, que está
inspirado en la especificación BioAPI. Esta solución divide el procesado necesario entre
las máquinas cliente y servidor utilizando la tecnología Java Remote Method Invocation
(JavaRMI), he implementa los requisitos de seguridad principales del estándar X9.84. Los
principales inconvenientes de esta solución son los siguientes. Por una parte, el hecho de

2.3. Aplicación de Sistemas Biométricos en E-learning 27
que realmente no sea compatible con módulos BioAPI afecta a la interoperabilidad de la
solución. Por otra parte, el uso de la tecnología JavaRMI para la comunicación clienteservidor
puede verse afectada por la existencia de cortafuegos en un entorno real.
En el artículo [Auernheimer y Tsai, 2005] se presenta un prototipo que aplica autenticación
biométrica en cursos basados en plataformas Web en el contexto de una universidad.
Este prototipo realiza la autenticación de usuario utilizando la huella dactilar, pero
utiliza una webcam con el fin de capturar periódicamente la imagen del alumno, con el
fin de realizar una auditoría en caso de sospecha de fraude. Uno de los inconvenientes de
la solución propuesta es que el proceso de auditoría no se realiza de manera automática,
sino que depende de la supervisión humana.
Almeida et al. [Almeida y otros, 2006] presentan un sistema de autenticación para
entornos LMS que utiliza la verificación biométrica basada en keystroke. Es decir, verificación
basada en los intervalos de tiempo que transcurren mientras el usuario pulsa las
teclas al escribir una clave. Esta solución cuenta con la ventaja de no necesitar de ningún
hardware especial para realizar la captura, ya que la captura puede ser efectuada por el
teclado convencional. Se trata de un método de rápido procesamiento pero este tipo de
verificación está sujeta a grandes variaciones en función de la condición del individuo.
En el artículo [Levy y Ramim, 2007] se propone una solución teórica para la autenticación
en evaluaciones electrónicas. Según la arquitectura propuesta, el estudiante utiliza
su huella dactilar para ser identificado en el servidor de la aplicación de E-learning, manteniendo
su autenticación durante la sesión. Durante el proceso de evaluación, al usuario
se le solicita cada cierto tiempo una muestra de un dedo aleatorio. De este modo, es más
sencillo detectar el caso de que otra persona ocupe su lugar después de entrar en el sistema.
En el trabajo [Costa, 2007] se presenta un modelo de arquitectura para realizar autenticación
biométrica en sistemas de Web Banking. La solución presentada se basa en
la utilización de la tecnología de Servicios Web, que se caracteriza por su interoperabilidad
y facilidad de integración en sistemas heredados. El autor muestra la aplicabilidad
del modelo a través de un prototipo que realiza verificación basada en huella dactilar para
sistemas de Web Banking.
En el trabajo [Asha y Chellappan, 2008] se combinan rasgos biométricos anatómicos
y comportamentales en un esquema multimodal. Se usan las tecnologías de reconocimiento
por huella dactilar y por dinámica de ratón. Para ésta última se usan como características
la dirección, la velocidad, y el tiempo de los movimientos hechos con el ratón. Todavía
no han realizado ninguna evaluación de esta solución.
En el trabajo [Elias Penteado y Marana, 2009] los autores exponen un solución teórica
similar, a la presentada en esta tesis, al problema de autenticación remota en el contexto
de entornos de E-learning. Exponen que la autenticación biométrica puede ayudar asegurando
que el individuo correcto es quien está haciendo el curso. Proponen una arquitectura
que pretende reducir la carga computacional y el tráfico entre el equipo del estudiante y
el servidor, que es independiente del LMS utilizado. Analizando los resultados expuestos
en el artículo referentes a los tiempos de procesado del módulo de detección de cara implementado,
y a las prestaciones del algoritmo de verificación implementado basado en el
uso de eigenvectors, concluimos que se encuentra todavía en una fase inicial de desarrollo,
y que todavía tienen un largo camino por recorrer.

28 Capítulo 2. Estado del Arte
2.3.2. Monitorización de Estudiante
En este apartado citaremos las principales publicaciones en las que se proponen el uso
de rasgos biométricos en el mecanismo de monitorización de los estudiantes dentro del
ámbito del E-learning.
En el artículo [Chen, 2003b] el autor nos presenta un sistema de videoconferencia que
automáticamente detecta si los estudiantes están hablando, haciendo gestos específicos, o
moviéndose en sus asientos. Uno de los resultados de este artículo es que estos indicadores
de actividad que define son un registro muy útil de lo sucedido durante la clase, y que
su uso es menos intrusivo para los estudiantes que la grabación del audio o del vídeo.
Este sistema de videoconferencia llamado Video Auditorium es presentado en la Tesis
[Chen, 2003a], que está enfocada hacia la interacción en tiempo real entre el profesor
y los alumnos en entornos de aprendizaje virtual, más que hacia la monitorización del
alumno mientras accede a los contenidos de aprendizaje.
En el artículo [García-Barrios y otros, 2004] se presenta el Framework AdELE, una
solución que utiliza las posibilidades del análisis del seguimiento del ojo y del contenido
en tiempo real, con el fin de proporcionar enseñanza y aprendizaje adaptativo, en los
entornos de E-learning.
Otro tipo de monitorización más compleja es la que se presenta en el artículo
[Loh y otros, 2005] donde se discute sobre la aplicación del análisis automático de las
expresiones faciales del estudiante al entorno del E-learning con el fin de ofrecer un mayor
apoyo durante el proceso de aprendizaje.
En el estudio [Hernández y otros, 2008] se presenta el efecto que supone en los alumnos
el hecho de ser conscientes de que están siendo monitorizados con una webcam durante
el proceso de evaluación. La autenticación se realizaba utilizando la huella dactilar
del alumno. Al terminar el experimento, los alumnos cubrían un cuestionario sobre sus
impresiones en relación al uso del sistema. Uno de los resultados importantes de estudio
fue que la media de las notas de los alumnos que fueron evaluados a distancia fue menor
comparada con la media de una evaluación similar hecha en condiciones presenciales. Los
alumnos manifestaron sentirse incómodos tanto por la presencia de la cámara, como con
la limitación en el tiempo disponible para resolver la prueba.
En el artículo [ROLIM y BEZERRA, 2008] los autores presentan al Sistema de Identificación
Automática de Faces (SIAF) que han acoplado a la plataforma de LMS Moodle.
Este sistema hace uso de la webcam para la captura periódica de imágenes de la cara del
alumno, utilizando la transformada del discreta del coseno (DCT) para extraer las características
de la cara presente. El SIAF no utiliza técnicas de localización y detección de
caras obtenidas, lo que influye negativamente en las prestaciones del sistema, obteniendo
unas prestaciones insuficientes para su uso en un entorno real.
En el artículo [Calvi y otros, 2008] los autores presentan un sistema en el que aplican
seguimiento ocular para estimar el tiempo que se le dedica a cada párrafo de los contenidos
de aprendizaje. Utilizan esta información para comprobar que se haya leído todo
el texto de un contenido antes de poder acceder al siguiente. Esta solución se basa en el
uso de una cámara web que trabaja en la parte del espectro correspondiente a la luz infrarroja.
Requiere una calibración inicial en la que se analiza el seguimiento de los ojos del
usuario mientras recorre los límites de la pantalla. Esta solución depende de la pose del

2.4. Conclusiones 29
estudiante, y las prestaciones que ofrece decaen si hay variaciones en la pose del estudiante
durante la sesión. Su aplicación realista parece estar limitada a entornos con personas
con incapacidades motoras.
2.4. Conclusiones
A lo largo de este capítulo hemos presentado los distintos estándares existentes en los
campos de la Biometría y del E-Learning, junto con las publicaciones más relevantes en
la literatura que están relacionadas con la problemática expuesta en esta Tesis. Hemos
visto como la mayoría de las contribuciones que proponen el uso de la Biometría en
el ámbito del aprendizaje electrónico, se centran principalmente en la tarea de control
de acceso, predominando entre ellas la verificación por huella dactilar, y siendo en su
mayoría propuestas teóricas validadas con prototipos experimentales, pero escaseando
las implementaciones de sistemas reales. La mayoría de las aportaciones presentadas no
prestan excesiva atención a su aplicación para la mejora de la tarea de monitorización
del comportamiento del alumno a lo largo de la sesión de aprendizaje. Por todo esto,
podemos concluir que las contribuciones presentadas en esta Tesis son novedosas y de
gran relevancia.

Capítulo 3
Base Tecnológica
Contenido
3.1. Tecnologías Biométricas . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1. El Framework BioAPI . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2. BioAPI Framework desde Java . . . . . . . . . . . . . . . . . . 36
3.2. Single Sign-On para el Web . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1. Central Authentication Service . . . . . . . . . . . . . . . . . . 38
3.3. Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1. Seguridad en Servicios Web . . . . . . . . . . . . . . . . . . . 43
3.4. Procesado de Imagen . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.2. Algoritmo de Viola & Jones . . . . . . . . . . . . . . . . . . . 44
3.4.3. Algoritmo CAMSHIFT . . . . . . . . . . . . . . . . . . . . . . 46
3.4.4. Algoritmo de Lucas-Kanade . . . . . . . . . . . . . . . . . . . 49
3.5. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.2. Relación de principales patrones GoF . . . . . . . . . . . . . . 52
3.5.3. Catálogo de patrones J2EE . . . . . . . . . . . . . . . . . . . . 54
3.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
En este capítulo se expone la base tecnológica en la que se apoyan los sistemas diseñados
y desarrollados en esta Tesis. Esta explicación agrupa los conceptos técnicos
necesarios para comprender cada uno de los componentes de las arquitecturas software
presentadas en los capítulos siguientes. En la sección 3.1 nos centramos en las tecnologías
actuales que se emplean en el desarrollo de sistemas biométricos. A continuación, la
sección 3.2 se centra en soluciones Single Sign-On como mecanismos de autenticación

32 Capítulo 3. Base Tecnológica
Web, enumerando un conjunto de plataformas LMS actuales que soportan este tipo de
autenticación. En la sección 3.3 se describe a los Servicios Web como una tecnología de
comunicación entre un equipo cliente y un servidor que proporciona múltiples ventajas.
En la sección 3.4 se presentan los fundamentos de los principales algoritmos de procesado
de imagen utilizados en esta Tesis para las tareas de detección y seguimiento de estudiantes.
Finalmente, en la sección 3.5 se citarán algunas de las buenas prácticas seguidas en
las tareas de programación de los distintos módulos software que conforman esta Tesis.
3.1. Tecnologías Biométricas
Con el término tecnología biométrica nos referimos a las soluciones software y/o hardware
que permiten el reconocimiento de la identidad de un individuo a partir de alguno,
o de la combinación de varios, de sus rasgos biométricos. Para maximizar la interoperabilidad
de estas tecnologías biométricas con las aplicaciones genéricas que pretendiesen
incorporar sus servicios se creó el estándar BioAPI, tal y como ya hemos comentado en
la sección 2.2.2. En esta sección presentaremos algunos detalles técnicos sobre el Framework
BioAPI necesarios para comprender las soluciones presentadas en capítulos posteriores.
3.1.1. El Framework BioAPI
El propósito de la especificación BioAPI es proporcionar un modelo de autenticación
biométrica de alto nivel para cualquier tecnología de biometría. En la actualidad existen
dos especificaciones de este estándar: la BioAPI 1.2 y la BioAPI 2.0. Para cada una de
estas especificaciones está disponible una implementación de referencia realizada en el
lenguaje de programación C, siendo de pago la implementación de referencia de la BioAPI
2.0. Este estándar cubre las funciones básicas de Enrollment, Verification, e Identification
descritas anteriormente.
El modelo básico es el mismo para todos los tipos de tecnologías. Primero se ha de
construir el modelo del usuario o template inicial para registrarse. Esto se hace tomando
capturas con los sensores de los que se disponga. De estas capturas se extraen las características
que conforman el template del usuario. Esta primera fase de construcción se llama
Enrollment y los algoritmos que construyen el template suelen ser propietarios. Este template
suele ser almacenado por la aplicación siendo, conceptualmente, equivalente a un
password tradicional. Posteriormente, el usuario tendrá que ser autenticado, para lo que se
toman capturas de los dispositivos que serán procesadas adecuadamente. A estas capturas
procesadas se les aplicará el algoritmo de matching contra el template que previamente
se haya creado. Esta etapa de Verificación trata, como su nombre indica, de verificar que
un usuario es quien dice ser. Del mismo modo, se puede realizar una nueva forma de
autenticación, denominada Identificación, en la que el Biometric Service Provider (BSP)
compara la muestra obtenida contra un grupo muestral y decide a cual de ellos se parece
más. Dependiendo de las probabilidades de matching estipuladas, la identidad del usuario
puede ser asociada a uno de los registros del grupo muestral o a ninguno de ellos.
La Figura 3.1 muestra algunas de las posibles estrategias de implementación dentro

3.1. Tecnologías Biométricas 33
Figura 3.1: Posibles estrategias de implementación de un Biometric Service Provider.
de este framework. Los pasos necesarios durante las operaciones de verificación e identificación
son mostrados en la caja etiquetada como Biometric Service Provider (BSP). Las
fases identificadas sobre la caja hacen referencia a las primitivas de bajo nivel: Capture,
Process y Match. En la Figura 3.1 se aprecia que en la tarea de implementación de un
BSP, el desarrollador tiene bastante libertad en el emplazamiento de la funcionalidad que
cubre cada una de esas primitivas.
El estándar BioAPI [BioAPI Framework, WWW] utiliza el término plantilla biométrica
o template para referirse a los datos biométricos obtenidos en la fase de enrollment
anteriormente descrita. Este template ha de ser comparado, a partir de una tolerancia, con
la muestra tomada del usuario, para que el usuario sea autenticado. El término Biometric
Identification Record (BIR) se utiliza para referirse a cualquier tipo de datos biométricos
que son devueltos a la aplicación, como por ejemplo las muestras recién capturadas
(RAW), las muestras procesadas, la plantilla biométrica, etc. La estructura de un BIR es la
que se muestra en la siguiente Figura 3.2, en ella se puede apreciar que un BIR está compuesto
por una cabecera (Header) que contiene información sobre los datos biométricos
(longitud, versión, tipo, formato, calidad, propósito, etc.), los propios datos biométricos
(Opaque Biometric Data), y opcionalmente un campo de firma (Signature).
La descripción completa del estándar BioAPI se escapa de los objetivos del presente
capítulo, por lo que se recomienda acudir a [BioAPI Framework, WWW] para obtener
mayor información.

34 Capítulo 3. Base Tecnológica
Figura 3.2: Estructura de un Biometric Identification Record.
La API definida por la especificación incluye tres funciones de alto nivel (high-level
abstractions) y cinco primitivas de bajo nivel (low-level primitives) tal y como podemos
ver representado en la Figura 3.3.
Figura 3.3: El modelo BioAPI: Primitivas de bajo nivel y abstracciones de alto nivel.
Las abstracciones de alto nivel constituyen un medio muy simple de desarrollar aplicaciones
autónomas con capacidades biométricas, y son las siguientes:
BioAPI_Enroll: En esta función se capturan muestras desde un dispositivo, se procesan
y almacenan de forma estándar para construir y devolver un template o modelo de
usuario a la aplicación.
BioAPI_Verify: En esta función se capturan una o más muestras para procesarlas y compararlas
contra un template. Se devuelve el resultado booleano de la comparación y
la FAR obtenida. La devolución del valor de FRR es opcional.
BioAPI_Identify: Es conceptualmente igual al caso anterior, sólo que la muestra se compara
contra un grupo de templates y se decide cuáles son los candidatos que obtie-

3.1. Tecnologías Biométricas 35
nen una mayor puntuación de matching con la muestra dada. Su implementación
también es opcional.
Sin embargo, el procesado de los datos biométricos, realizado desde el momento de
la captura hasta la tarea de matching contra el template, puede ser cumplido en varias
fases. La API ha sido definida para permitir a los desarrolladores de módulos biométricos
la máxima libertad en el emplazamiento del procesado, y permitiendo que este procesado
sea compartido entre una máquina cliente (que es la que tiene conectada el dispositivo
biométrico), y una máquina servidor. Con ese propósito existen en la API las primitivas
de bajo nivel, que usadas secuencialmente son equivalentes a utilizar las abstracciones
de alto nivel, pero permitiendo más libertad en el desarrollo de implementaciones clienteservidor
tal y como se puede apreciar en la Figura 3.4. Estas primitivas de bajo nivel son:
BioAPI_Capture: Esta función siempre se ejecuta en la máquina del cliente y en ella se
captura la información biométrica del usuario que se devuelve como un BIR. Si es
necesario realizar un procesado de esa muestra, la cabecera del BIR indicará que se
trata de un BIR intermedio, si no, indicará que se trata de un BIR procesado.
BioAPI_Process: Los algoritmos de procesado debieran estar disponibles en el servidor,
pero pueden estar en el cliente. El propósito de esta función es proporcionar el
procesado necesario a las muestras obtenidas para luego ser verificadas o identificadas.
Siempre toman un BIR intermedio como entrada y pueden devolver un BIR
intermedio para que sea procesado de nuevo en el servidor, o un BIR procesado.
BioAPI_CreateTemplate: Esta función está pensada para construir a partir de las muestras
de datos biométricos, el template de un usuario. De forma opcional, esta función
puede tomar como parámetro de entrada un template antiguo para utilizarlo en el
proceso de creación del nuevo template.
BioAPI_VerifyMatch: Realiza la comparación entre el BIR procesado y un template.
BioAPI_IdentifyMatch: Realiza la comparación entre el BIR procesado y un conjunto
de templates.
Las muestras biométricas son datos complejos producidos por sensores. Para un mismo
usuario es muy probable que dos muestras biométricas no sean idénticas. Las plantillas
de usuarios son resultado digital del procesado y compresión de estas muestras, son representaciones
no precisas del usuario. Por ello, los resultados de cualquier comparación
de una muestra contra una plantilla almacenada sólo se puede expresar en términos de
probabilidad.
Como ya se ha comentado en 1.2, existen dos posibles medidas para los resultados
de una comparación: la Tasa de Falsa Aceptación (FAR), y la Tasa de Falso Rechazo
(FRR). La FAR es la probabilidad de que una muestra sea falsamente aceptada por el
sistema cuando se compara con la plantilla biométrica (es decir, se acepta al impostor).
Mientras que la FRR es la probabilidad de que una muestra sea falsamente rechazada (es
decir, se rechaza al cliente). Dependiendo de las circunstancias, la aplicación puede estar
más interesada en reducir una u otra.

36 Capítulo 3. Base Tecnológica
Figura 3.4: Diagrama de bloques del modelo BioAPI en un entorno Cliente-Servidor.
Las funciones de la BioAPI permiten a la aplicación especificar un valor máximo de
FAR (es decir, un límite a la probabilidad de una falsa aceptación) y opcionalmente un
valor máximo de FRR. Si se proporcionan ambos, la aplicación debe indicar cual tiene
precedencia.
El principal resultado devuelto es la FAR real conseguida en esa comparación (es
decir, el score normalizado en términos de probabilidad). Según la especificación BioAPI
la devolución por parte de un BSP del valor real de la FRR conseguida es opcional.
La devolución de los scores a la aplicación puede ser una debilidad de la seguridad
del sistema si no se toman las medidas correspondientes para evitar ataques por el método
conocido como hillclimbing. Estas medidas consisten en devolver los valores de FAR
cuantificados de determinada manera en función del algoritmo utilizado.
Para concluir, tenemos que decir que los módulos de reconocimiento biométrico realizados
y utilizados en esta Tesis se ajustan a la especificación BioAPI 1.2.
3.1.2. BioAPI Framework desde Java
Entre las numerosas razones existentes para intentar portar el Framework BioAPI de
C/C++ a Java podemos citar: Java es un lenguaje orientado a objetos de alto nivel que es
simple sobre las bases de los principios de ingeniería del software, Java proporciona un
medio más simple de desarrollar aplicaciones software mantenibles que otros lenguajes
más complejos como C/C++, y Java ofrece numerosas tecnologías para el desarrollo de
aplicaciones Web.
Las implementaciones de referencia del BioAPI framework son dependientes del sis-

3.2. Single Sign-On para el Web 37
tema operativo, lo que significa que desarrollar aplicaciones multiplataforma conformes
al estándar BioAPI no es una tarea sencilla. Portar el Framework BioAPI al entorno Java
facilitaría el desarrollo de aplicaciones biométricas orientadas al Web debido a que ya
existen numerosas tecnologías orientadas al Web realizadas en Java. Es por ello, que la
existencia de una versión puramente Java de la BioAPI proporcionaría numerosas ventajas,
y además contaría con la particularidad de facilitar la extensión de las aplicaciones
biométricas a dispositivos móviles. Existe una propuesta del INCITS [INCITS, WWW]
sobre la estandarización de una especificación de la BioAPI en Java que todavía se encuentra
en proceso. Además, existe un problema de interoperabilidad entre el nuevo marco
puramente Java y las existentes implementaciones de los BSPs realizados en C/C++ no
solucionado a priori. Es por ello, por lo que se necesita una solución con disponibilidad
inmediata.
Para acceder al Framework BioAPI hecho en C/C++ desde el entorno Java, se puede
usar un Java Wrapper basado en la tecnología Java Native Interface (JNI). JNI es una
interfaz de programación estándar para escribir métodos nativos que se pueden invocar
desde Java, e incluso, poder utilizar la máquina virtual Java dentro de aplicaciones nativas.
En el momento en el que nos planteamos en esta Tesis la búsqueda de un Java Wrapper
que nos permitiera utilizar el Framework BioAPI, existían dos proyectos: el JNI BioAPI
Wrapper para Windows desarrollado por Gens Software, y el proyecto de código libre
JBioAPI para Linux/Unix. Ambos proyectos basados en la especificación BioAPI 1.1.
El principal problema que se nos presentó fue que los dos proyectos no eran compatibles
entre sí, y eso complicaba el desarrollo de aplicaciones multiplataforma conformes
al estándar BioAPI. Por otra parte, sendos proyectos solamente ofrecían acceso a las abstracciones
de alto nivel, y no a las primitivas de bajo nivel, por lo que no permitían dividir
el proceso de autenticación entre una máquina cliente y un servidor. Fue necesario realizar
varias contribuciones al proyecto JBioAPI para poder ofrecer una solución viable a este
problema, tal y como veremos en las sección 4.2.5.
3.2. Single Sign-On para el Web
Los sistemas Single Sign-On (SSO) permiten transportar la información de autenticación
de un sistema a otro. En otras palabras, supongamos que disponemos de una serie
de servicios distribuidos en diferentes proveedores Web, en un entorno normal, al acceder
a cualquier servicio de un proveedor necesitamos autenticarnos. Este hecho provoca
la pérdida de tiempo en varios procesos de autenticación y disminuye la usabilidad. En
lugar de esto, los sistemas Single Sign-On nos permiten centralizar este proceso. La idea
es que el usuario se autentica una sola vez contra el sistema centralizado, y éste le expende
un tícket. Cuando el usuario quiere usar un determinado servicio presenta este tícket,
el servicio se conecta con el servidor Single Sign-On para pedir la validación del tícket
presentado por el usuario, en caso de validar correctamente el usuario, éste puede acceder
al servicio como si se hubiera autenticado en él de forma normal. Como hemos dicho,
un SSO es un procedimiento de autenticación que habilita al usuario para acceder a varios
sistemas con una sola instancia de identificación, también se les llama sistemas de
autenticación reducida (Reduced Sign On Systems) y hay cinco tipos principales:

38 Capítulo 3. Base Tecnológica
Enterprise Single Sign-On (E-SSO): También llamado Legacy Single Sign-On, funciona
para una autenticación primaria, interceptando los requerimientos de login presentados
por las aplicaciones secundarias para completar los mismos con el usuario
y contraseña. Los sistemas E-SSO permiten interactuar con sistemas que pueden
deshabilitar la presentación de la pantalla de login.
Web Single Sign-On (Web-SSO): También llamado Web Access Management (Web-
AM) trabaja sólo con aplicaciones y recursos accedidos vía Web. Los accesos son
interceptados con la ayuda de un servidor proxy o de un componente instalado en el
servidor web destino. Los usuarios no autenticados que tratan de acceder son redirigidos
a un servidor de autenticación y regresan solo después de haber logrado un
acceso exitoso. Se utilizan cookies, para reconocer aquellos usuarios que acceden y
su estado de autenticación.
Kerberos: Es un método popular de externalizar la autenticación de los usuarios.
Los usuarios se registran en el servidor Kerberos y reciben un tícket, luego las
aplicaciones-cliente lo presentan para obtener acceso.
Identidad Federada: Se trata de una nueva manera de concebir este tema, también para
aplicaciones Web. Utiliza protocolos basados en estándares para habilitar que las
aplicaciones puedan identificar los clientes sin necesidad de autenticación redundante.
OpenID: Se refiere a un proceso de SSO distribuido y descentralizado donde la identidad
se compila en una Uniform Resource Locator (URL) que cualquier aplicación o
servidor puede verificar.
De entre todos ellos, en la presente Tesis nos centraremos en Web-SSO, incorporándole
capacidades biométricas al proceso de autenticación.
3.2.1. Central Authentication Service
Uno de los sistema SSO más extendidos y con mejores críticas es Central Authentication
Service (CAS) que fue desarrollado originalmente por la Universidad de Yale y que
actualmente se mantiene y se evoluciona desde la organización JA-SIG. En el típico escenario
de CAS, un navegador realiza una petición de servicio a una determinada aplicación
(Figura 3.5 paso 1), esta aplicación buscará el tícket del servidor CAS en la petición para
determinar si este usuario ya se ha autenticado. Si el tícket no se encuentra es porqué el
usuario no se ha autenticado o su sesión ha caducado, en estos casos se redirige la petición
hacia el sistema de autenticación de CAS (Figura 3.5 paso 2). Este sistema de autenticación
puede ser cualquiera desde el típico login/password hasta cualquier otro que se quiera
implementar mediante la interfaz Authentication-Handler. Por ejemplo, en nuestro caso
lo que se hace es realizar una implementación de esta interfaz que soporta autenticación
biométrica. En este punto el sistema de autenticación verificará las credenciales aportadas
por el usuario contra una base de datos, un LDAP, Kerberos, etc. Una vez realizado el
proceso de autenticación correctamente contra el sistema CAS, éste redirige al usuario de

3.2. Single Sign-On para el Web 39
nuevo hacia la aplicación original pero incorporando el tícket correspondiente en la petición
(Figura 3.5 paso 3). Como la aplicación a la que se quiere acceder ahora sí encuentra
el tícket en la petición, pregunta a CAS (Figura 3.5 paso 4) si efectivamente el tícket es
válido. Si la respuesta del sistema CAS es afirmativa se permitirá al usuario acceder a
esta aplicación. Si en el futuro, este usuario (y dentro de la validez de este tícket) intenta
acceder a otra aplicación del sistema, ésta pedirá a CAS que verifique el tícket del que el
usuario ya dispone y le permitirá el acceso si la verificación es correcta.
Figura 3.5: Sistema de autenticación CAS.
Un punto fuerte de esta arquitectura es el hecho de que la única aplicación que conoce
las credenciales de los usuarios es CAS ya que el resto de aplicaciones sólo utilizan un
tícket que tiene una caducidad temporal.
El JA-SIG Central Authentication Service (CAS) es un proyecto de código libre que
ofrece Web-SSO proporcionando a las aplicaciones web la habilidad de deferir todo el
proceso de autenticación a un servidor externo en el que confía. Su implementación esta
hecha con Servlets Java y se puede desplegar sobre cualquier servidor de aplicaciones
compatible con la especificación JSP 1.2. Sus principales virtudes son la seguridad, características
proxy, flexibilidad, fiabilidad, y las numerosas librerías freeware cliente disponibles,
incluyendo clientes para Java, .Net, PHP, Perl, Apache, uPortal, Liferay entre
otros. Es por estas ventajas que CAS es usado por muchas universidades Americanas,
con autenticación basada en LDAP o Kerberos. Además, CAS ofrece la posibilidad de
ser conectado directamente dentro de uPortal, escogido por el consorcio ESUP-Portrail,
en camino de convertirse en un estándar para portales de código abierto. Esto nos hace
confiar en su permanencia.

40 Capítulo 3. Base Tecnológica
3.2.1.1. CASifying Learning Management Systems
Como se ha dicho en la sección anterior CAS está siendo adoptado como mecanismo
de autenticación en un amplio número de aplicaciones web de diversa funcionalidad
(gestores de correo, portales de noticias, wikis, etc.). En esta sección no vamos a enumerar
las más conocidas de ellas, sino aquellas que tienen un interés especial debido a
la naturaleza de la problemática planteada en esta Tesis. Es por ello que a continuación
presentaremos una lista con 17 plataformas Learning Management System (LMS), tanto
comerciales como de código libre, que permiten utilizar CAS como mecanismo de autenticación
de sus usuarios. Si el lector desea obtener más información sobre cada una de
ellas puede consultar las sección 1.1.3.
LMS.
Blackboard Learning System CE 6.1 Enterprise License fabricado por WebCT.
Blackboard Learning System Vista 4.1 Enterprise License fabricado por WebCT.
Desire2Learn 8.3
JoomlaLMS
ILIAS ∗
Claroline ∗
Moodle 1.8 ∗
Moodle 1.9
Moodle Rooms
OLAT
Sakai 2.3
Sakai Community Release 2.5
The Blackboard Academic Suite (Release 8.0) fabricado por Blackboard.
The Blackboard Learning System (Release 7) - Enterprise License fabricado por
Blackboard.
The rSmart Sakai CLE
Timecruiser Solution Suite
WebStudy Learning CMS v9.0
∗ El control de acceso biométrico que proporciona BioWebAuth fue probado con éxito con la plataforma

3.3. Servicios Web 41
Los datos han sido extraídos utilizando el portal [EDUTOOLS, WWW], propiedad
del WCET (Western Cooperative for Educational Telecommunications), que proporciona
un sistema que permite realizar la comparación de distintos productos CMS. Este portal
ofrece a su vez la posibilidad de consultar un informe detallado sobre cada una de estas
plataformas LMS. Recomendamos su visita si el lector está interesado en profundizar en
las características particulares de alguna de ellas.
3.3. Servicios Web
Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su
complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican.
Una posible sería hablar de ellos como un conjunto de aplicaciones o de tecnologías
con capacidad para interoperar en la Web [ServiciosWeb, WWW]. Estas aplicaciones o
tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores
ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un
servicio llamando a estos procedimientos a través de la Web.
Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes
aplicaciones, que interactúan entre sí para presentar información dinámica al usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo
tiempo sea posible su combinación para realizar operaciones complejas, es necesaria
una arquitectura de referencia estándar.
El gráfico de la Figura 3.6 muestra cómo interactúa un conjunto de Servicios Web.
Figura 3.6: Los Servicios Web en funcionamiento.
Según el ejemplo del gráfico, un usuario (que juega el papel de cliente dentro de los
Servicios Web), a través de una aplicación, solicita información sobre un viaje que desea
realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a través
de Internet. La agencia de viajes ofrecerá a su cliente (usuario) la información requerida.
Para proporcionar al cliente la información que necesita, esta agencia de viajes solicita a

42 Capítulo 3. Base Tecnológica
su vez información a otros recursos (otros Servicios Web) en relación con el hotel y la
compañía aérea. La agencia de viajes obtendrá información de estos recursos, lo que la
convierte a su vez en cliente de esos otros Servicios Web que le van a proporcionar la
información solicitada sobre el hotel y la línea aérea. Por último, el usuario realizará el
pago del viaje a través de la agencia de viajes que servirá de intermediario entre el usuario
y el servicio Web que gestionará el pago.
En todo este proceso intervienen una serie de tecnologías que hacen posible esta circulación
de información. Por un lado, estaría SOAP (Protocolo Simple de Acceso a Objetos).
Se trata de un protocolo basado en XML, que permite la interacción entre varios dispositivos
y que tiene la capacidad de transmitir información compleja. Los datos pueden ser
transmitidos a través de HTTP, SMTP, etc. SOAP especifica el formato de los mensajes.
Como podemos apreciar en la Figura 3.7, el mensaje SOAP está compuesto por un sobre
(envelope), cuya estructura está formada por los siguientes elementos: cabecera (header)
y cuerpo (body).
Figura 3.7: Estructura de los mensajes.
Para optimizar el rendimiento de las aplicaciones basadas en Servicios Web, se han
desarrollado tecnologías complementarias a SOAP, que agilizan el envío de los mensajes
(MTOM) y los recursos que se transmiten en esos mensajes (SOAP-RRSHB).
Por otro lado, WSDL (Lenguaje de Descripción de Servicios Web), permite que un
servicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles de transporte
de mensajes y su contenido, a través de un documento procesable por dispositivos. WSDL
representa una especie de contrato entre el proveedor y el que solicita. WSDL especifica
la sintaxis y los mecanismos de intercambio de mensajes.
Durante la evolución de las necesidades de las aplicaciones basadas en Servicios Web
de las grandes organizaciones, se han desarrollado mecanismos que permiten enriquecer
las descripciones de las operaciones que realizan sus servicios mediante anotaciones se-

3.3. Servicios Web 43
mánticas y con directivas que definen el comportamiento. Esto permitiría encontrar los
Servicios Web que mejor se adapten a los objetivos deseados. Además, ante la complejidad
de los procesos de las grandes aplicaciones empresariales, existe una tecnología que
permite una definición de estos procesos mediante la composición de varios Servicios
Web individuales, lo que se conoce como coreografía.
3.3.1. Seguridad en Servicios Web
Dada la diversidad existente en la naturaleza de los datos (personales, bancarios, biométricos,
etc.) transmitidos en las llamadas a Servicios Web, deben ofrecerse mecanismos
que garanticen la autenticidad, confidencialidad e integridad de los mismos. WS-Security
es un protocolo de comunicaciones que suministra un medio para aplicar seguridad a los
Servicios Web.En abril de 2004 el estándar WS-Security 1.0 fue publicado por Oasis-
Open. En 2006 fue publicada la versión 1.1. Originalmente desarrollado por IBM, Microsoft,
y VeriSign, el protocolo es ahora llamado oficialmente WSS y está desarrollado
por un comité en Oasis-Open. El protocolo contiene especificaciones sobre cómo debe
garantizarse la integridad y seguridad en mensajería de Servicios Web, e incluye detalles
en el uso de SAML y Kerberos, y formatos de certificado tales como X.509.
La Integridad de datos y confidencialidad pueden garantizarse sobre Servicios Web a
través del uso de la Transport Layer Security (TLS), por ejemplo enviando mensajes sobre
HTTPS. Esto puede reducir significativamente la sobrecarga, por ejemplo eliminando la
necesidad de codificar claves y firmas de mensaje en ASCII antes de enviar. La parte
negativa de usar TLS sería si los mensajes necesitaran pasar a través de un servidor proxy.
En tal caso, el servidor vería la petición que llega del proxy, no del cliente; esto podría
ser solventado si el proxy tiene una copia de la clave y certificado del cliente, o teniendo
un certificado de firmado de confianza para el servidor, con el cual podría generar un par
clave/certificado que coincida con aquellos del cliente. Sin embargo, el hecho de que el
proxy está operando el mensaje significa que no asegura la seguridad extremo a extremo,
sino que solo asegura la seguridad punto a punto. WS-Security incorpora características
de seguridad en el encabezado de un mensaje SOAP, trabajando en la capa aplicación. Así
garantiza seguridad extremo a extremo.
Las siguientes especificaciones borrador están asociadas con WS-Security: WS-
SecureConversation, WS-Federation, WS-Authorisation, WS-Policy, WS-Trust y WS-
Privacy.
En esta Tesis se utiliza el proyecto Apache WSS4J [Apache WSS4J, WWW] para garantizar
la autenticidad, confidencialidad e integridad de los datos que se envían en las
llamadas al Servicio Web biométrico que veremos en el siguiente capítulo. Apache WSS4
es la implementación en JAVA de WS-Security realizada por OASIS Web Services Security
TC. Principalmente una librería que permite firmar y verificar mensajes SOAP con
información WS-Security, y utiliza los proyectos Apache Axis y Apache XML-Security
que hacen que sea una solución compatible con servidores y clientes basados en .NET y
en JAX-RPC. WSS4J implementa:
Web Services Security: SOAP Message Security 1.1
Username Token Profile 1.1

44 Capítulo 3. Base Tecnológica
X.509 Certificate Token Profile 1.1
3.4. Procesado de Imagen
Como parte del trabajo realizado en esta Tesis se presenta una herramienta de monitorización
de estudiante que proporciona una medida del tiempo de presencia y de atención
que éste dedica a los contenidos de una plataforma de E-Learning. Para ello se aplica
un procesado de imagen al flujo de vídeo procedente de la cámara web del equipo del
estudiante, donde se espera que éste se encuentre. OpenCV es una biblioteca libre de visión
artificial originalmente desarrollada por Intel que será utilizada en esta Tesis para la
realización de las tareas de detección de caras frontales, detección y seguimiento de rasgos
faciales (ojos, nariz y boca), y seguimiento de la piel del estudiante. Concretamente,
se partirá de las implementaciones existentes de los métodos de detección Adaboost de
Viola-Jones, del algoritmo de seguimiento basado en flujo óptico de Lucas-Kanade, y de
la técnica no paramétrica Camshift, combinándolos para crear un módulo de seguimiento
de estudiante efectivo.
3.4.1. Introducción
Desde que apareció su primera versión alfa en el mes de enero de 1999, OpenCV se
ha utilizado en infinidad de aplicaciones. Desde sistemas de seguridad con detección de
movimiento, hasta en el control de procesos donde se requiere reconocimiento de objetos.
Esto se debe a que su publicación se da bajo licencia BSD, que permite que sea usada
libremente para propósitos comerciales y de investigación con las condiciones en ella
expresadas.
OpenCV es multiplataforma, existiendo versiones para Linux, Mac OS X y Windows.
Contiene mas de 500 funciones que abarcan una gran gama de áreas en el proceso de
Visión, como reconocimiento de objetos (reconocimiento facial), calibración de cámaras,
visión estéreo, etc.
El proyecto pretende proveer un Tool-Kit o Marco de desarrollo fácil de utilizar y altamente
eficiente. Esto se ha logrado, realizando su programación en código C y C++
optimizados, aprovechando además las capacidades que proveen los procesadores multinúcleo.
Además, OpenCV es compatible con las Primitivas de Rendimiento Integradas
de Intel, que son un conjunto de rutinas de bajo nivel específicas para procesadores Intel
(IPP) que aumentan su rendimiento.
3.4.2. Algoritmo de Viola & Jones
El primer método que vamos a ver para realizar tareas de detección es el desarrollado
por Paul Viola y Michael Jones [Viola y Jones, 2001]. Este método realiza una detección
de la posición del objeto buscado. Se ha comprobado que ofrece muy buenos resultados
en la detección de caras de frente. En concreto una mejora del algoritmo realizada por
Lienhart [Lienhart y Maydt, 2002] es uno de los métodos más utilizados para la detección

3.4. Procesado de Imagen 45
de caras. En esta Tesis se utiliza para detectar la posición de la cabeza del estudiante y de
sus principales rasgos faciales (ojos, nariz y boca).
Viola & Jones está basado en la combinación de clasificadores débiles construida con
la técnica Adaboost [Freund y Schapire, 1997], esto quiere decir que un único clasificador
no aporta unos resultados muy fiables, pero su combinación adecuada mejora enormemente
las prestaciones. Estos clasificadores se diseñan para tener una Tasa de Falso Rechazo
(FRR) muy baja, próxima a cero, lo que provoca que tengan una Tasa de Falsa Aceptación
(FAR) alta. Para realizar la clasificación completa se emplea una cascada de clasificadores
como la mostrada en la Figura 3.8, con el objetivo de dar una detección positiva si
todos los clasificadores lo detectan, pero rechazar la detección del objeto si tan sólo uno
lo rechaza. Este sistema permite aumentar la velocidad de procesamiento con respecto a
técnicas que necesitan procesar todos los clasificadores, como puede ser la Regla del Más
Votado [Kuncheva, 2004].
Figura 3.8: Cascada de clasificadores - Cada elemento representa un clasificador que, si
rechaza, continúa con el siguiente y, si acepta, se detiene.
Si consideramos que los clasificadores son independientes y con las mismas características
(suposición poco probable pero aceptable para entender el ejemplo siguiente),
podemos considerar una cascada de 20 clasificadores con una FRR = 0,001 y una FAR =
0,5, el clasificador en cascada obtendrá los siguientes resultados.
F RR tot = F RR + (1 − F RR)F RR + ... + (1 − F RR) 19 F RR ≈ 0, 02 (3.1)
F AR tot = F AR 20 ≈ 0, 00001 (3.2)
Mediante este ejemplo vemos que a pesar de que un solo clasificador da muchos falsos
positivos, el conjunto tiene una tasa FAR incluso mucho más baja que la FRR.
Para que este sistema funcione es necesario disponer de los clasificadores débiles
adecuados. Sabiendo que se dispone de miles posibles es fácil comprender que hay
que realizar una selección. Esta selección se realiza mediante la técnica de AdaBoost
[Freund y Schapire, 1997].
Los clasificadores empleados utilizan las características Haar-like features
[Papageorgiou y otros, 1998]. Estas características consisten en la diferencia entre la suma
de los píxeles de unos rectángulos con otros. En la Figura 3.9 vemos sombreados
unos rectángulos y blancos los otros. Estos rectángulos se desplazan y se escalan en el
área donde se considera que está el objeto. Por ello, partiendo de estos pocos ejemplos se
consiguen miles de clasificadores diferentes.

46 Capítulo 3. Base Tecnológica
Figura 3.9: Haar-like Features - A la izquierda las características empleadas en el algoritmo
original de Viola & Jones y a la derecha las empleadas en la mejora de Lienhart.
Para conseguir estos clasificadores (la selección realizada mediante AdaBoost) y la
cascada final, es necesario realizar un entrenamiento muy costoso. Este entrenamiento
necesita muchos ejemplos del objeto buscado (recordemos que en nuestro caso se trata
de caras y rasgos faciales), además de mucho tiempo de procesamiento. Debido a estos
problemas se pueden emplear clasificadores ya entrenados previamente por otros grupos.
La propia librería OpenCV facilita algunos.
Este método tiene la ventaja de que la detección es muy fiable, es decir, cuando detecta
una cara con pose frontal, es altamente probable que se encuentre allí. Sin embargo
tiene el inconveniente de que en algunas ocasiones la cara no es detectada, y por tanto
en esos momentos se pierde por completo su posición. Si esto ocurriese en fotogramas
aislados y sabiendo que la cabeza no se mueve mucho entre fotogramas se podría suponer
que la posición en los fotogramas perdidos es la posición anterior. El problema en nuestro
sistema es que la cara del usuario no estará siempre de frente, sino que al teclear algunos
estudiantes inclinarán la cabeza perdiendo la frontalidad, o la cara será ocluida parcialmente
por la mano en determinados momentos, o el estudiante se pondrá de perfil. En
esos momentos la localización de la cara se pierde por completo y el mantener la posición
anterior no es viable ya que no diferenciamos ninguno de los casos anteriores del hecho
de que el estudiante se haya ido. Por ello, el empleo de este sistema en solitario para llevar
a cabo todo el proceso de monitorización de presencia del estudiante no es razonable, ya
que necesitamos conocer de forma fiable la posición en todo momento del alumno, siendo
por ello necesario emplear algún otro método complementario. Por otra parte, dada la
fiabilidad que ofrece el método en la tarea de detección, consideramos muy útil su empleo
en el proceso de inicialización de otros métodos.
3.4.3. Algoritmo CAMSHIFT
Otro método que vamos a utilizar para la detección de la posición y seguimiento
de la cara en 2D es el CAMSHIFT [Allen y otros, 2004]. Este método está basado en
uno desarrollado previamente, denominado MEANSHIFT [Fukunaga, 1990] en el que

3.4. Procesado de Imagen 47
se desplaza una ventana en la dirección del gradiente de un mapa de probabilidad del
objecto de interés en el espacio de características adecuado, hasta alcanzar un máximo,
detectando así de forma robusta, una moda local de la función de probabilidad. El
algoritmo CAMSHIFT, además de encontrar la moda, estima el tamaño del objeto correspondiente
en la imagen original. A continuación se explica el sistema en más profundidad.
Primeramente explicaremos el funcionamiento del algoritmo MEANSHIFT. En la Figura
3.10 vemos el desarrollo del algoritmo MEANSHIFT que sigue los pasos siguientes:
1. Se escoge el tamaño s de la ventana de búsqueda W .
2. Se escoge la posición inicial p k en la que se centra la ventana de búsqueda dentro
de la imagen de probabilidad.
3. Se calcula el centro de masas de la ventana de búsqueda.
ˆ¯p k (W ) = 1 ∑
p j (3.3)
|W |
4. Se centra la ventana de búsqueda en el centro de masas ˆ¯p k (W ) obtenido en el Paso
3.
5. Se repiten los Pasos 3 y 4 hasta que cumpla el criterio de convergencia, es decir,
que el centro de masas se mueva menos que un umbral predefinido.
j∈W
Figura 3.10: MEANSHIFT - Desplazamiento de la ventana hacia el centro de masas, hasta
cumplir el criterio de convergencia.
A continuación vamos a definir algunos de los términos citados en los pasos que describen
el algoritmo de MEANSHIFT:

48 Capítulo 3. Base Tecnológica
Imagen de probabilidad: Para calcular la imagen de probabilidad se puede emplear
cualquier método que asocie a un valor de píxel una probabilidad. El método comúnmente
empleado es una retroproyección de histograma. Para su cálculo se suele
emplear un histograma obtenido del canal de color H del modelo HSV de la ventana
seleccionada, pero en nuestro caso trabajamos en el espacio RG normalizado. En
este trabajo vamos a crear el histograma de forma automática a partir de la ventana
de salida que nos devuelva el algoritmo de Viola & Jones, procesándola con el fin
de modelar la piel del usuario.
Localización del Centro de masas: En el cálculo del centro de masas dentro de la ventana
de búsqueda (Pasos 3 y 4) se emplean los momentos de orden cero y orden
uno. Para el cálculo de los momentos se emplea la intensidad de la imagen de probabilidad
en el punto (x, y) denominada I(x, y).
1. Cálculo del momento de orden cero:
M 00 = ∑ ∑
I(x, y) (3.4)
x y
2. Cálculo de los momentos de orden uno para x y para y:
3. Cálculo del centro de masas:
M 10 = ∑ x
M 01 = ∑ x
∑
xI(x, y) (3.5)
y
∑
yI(x, y) (3.6)
y
x c = M 10
M 00
; y c = M 01
M 00
(3.7)
Convergencia de MEANSHIFT: Finalmente se necesita tener un criterio de convergencia
para detener el algoritmo MEANSHIFT. La convergencia del algoritmo MEANS-
HIFT se puede entender de la siguiente manera: el MEANSHIFT asciende el gradiente
de f(p).
ˆ¯p k (W ) − p k ≈ f ′ (p k )
(3.8)
f (p k )
Cerca de la moda, f ′ (p k ) ∼ = 0, por lo que el algoritmo MEANSHIFT converge en
ese punto.
El criterio de convergencia puede estar basado en un número máximo de iteraciones,
en una distancia máxima entre centros de masas consecutivos, etc. Además, en el
caso de que el momento M 00 tenga un valor 0 el algoritmo también debe detenerse
puesto que ningún píxel tiene valor, lo que indica que el objeto se ha perdido.
Una vez explicado el funcionamiento del algoritmo MEANSHIFT, vamos a proceder
a describir el algoritmo CAMSHIFT, que se resume en los siguientes pasos:

3.4. Procesado de Imagen 49
1. Se escoge la localización inicial de la ventana de búsqueda dentro de la imagen
donde se espera encontrar el objeto.
2. Se aplica MEANSHIFT, tal y como se ha explicado anteriormente, una o varias
iteraciones, almacenando el valor de la posición del centroide y del momento de
orden cero.
3. Se centra la ventana de búsqueda en la posición del centroide y se actualiza su
tamaño en función del momento de orden cero calculado en el paso 2. En la implementación
de OpenCV [Bradski, 1998], para distribuciones de probabilidad de
imágenes 2D donde el valor máximo de píxel es 255, el tamaño de la ventana se
ajusta según la siguiente fórmula:
s = 2 ∗
√
M00
256
(3.9)
4. Se repiten los Pasos 2 y 3 hasta convergencia (el centro de masas se mueve menos
que un umbral predefinido).
Este método de seguimiento de un objeto, en nuestro escenario, es muy inestable, pero
con una serie de pequeños cambios adaptados a la situación puede ser bastante útil.
Además, a diferencia del algoritmo de Viola & Jones, no se producen pérdidas en la localización
de la cabeza en ningún fotograma. El principal problema que provoca la inestabilidad
consiste en la confusión del objeto con otros elementos debido a una mala imagen
de probabilidad, la cual asigna excesivo valor a zonas donde no se encuentra la cara. En
nuestro caso en particular, usaremos CAMSHIFT como un detector de piel que inicializaremos
con la salida de nuestro detector múltiple basado en Viola & Jones que devuelve
información sobre la localización de la cara y de varios rasgos faciales.
3.4.4. Algoritmo de Lucas-Kanade
El método de seguimiento implementado por Lucas y Kanade e incluido en OpenCV
[Bouguet, 2000] se basa en la representación piramidal de las imágenes involucradas, de
forma que el seguimiento se realiza a lo largo de los diferentes niveles de profundidad de
las pirámides. De esta forma el algoritmo es más robusto y su convergencia más rápida
siempre que se escojan adecuadamente los parámetros del algoritmo (niveles de la pirámide,
condiciones para las iteraciones, etc.). Se trata de un algoritmo iterativo de cálculo
del flujo óptico entre imágenes, que pueden formar parte de una secuencia de vídeo o bien
pueden ser imágenes independientes con alguna región en común, pero que en esta Tesis
se corresponderán con el flujo de vídeo procedente de la webcam.
El seguimiento piramidal se basa en calcular el Vector de Flujo Óptico entre dos imágenes
para la región de interés, partiendo de una región con poca información, pasando
posteriormente a refinar el cálculo realizado ampliando la información en el nivel superior
de la pirámide. De esta forma, una vez se tiene calculado el vector de movimiento en un
nivel, se calcula dicho vector para el nivel superior, tomando en cuenta información sobre
regiones que no aparecían en el nivel inferior. Así, partiendo de la región alrededor del

50 Capítulo 3. Base Tecnológica
punto origen, el nivel final de la pirámide constituye la imagen completa. Por lo tanto,
el objetivo del algoritmo estudiado se basa en obtener, para un punto x en la imagen I,
su correspondiente posición y = x + d en la imagen J. Con todos estos datos aplicados
a diferentes puntos de la imagen es posible realizar un seguimiento a lo largo del tiempo
de los puntos que más nos interesen, como por ejemplo la posición de los ojos, nariz y
boca para realizar estimaciones de pose a lo largo de la sesión. Es decir, se puede utilizar
la posición relativa entre ojos, nariz y boca para modelar la pose del estudiante y poder
medir el tiempo que éste presenta una pose frontal, con el fin de proporcionar una medida
del tiempo de atención.
3.5. Patrones de diseño
Durante el transcurso de esta Tesis se ha realizado el diseño y desarrollo de software
muy diverso, desde arquitecturas cliente-servidor que ofrecen control de acceso biométrico
y monitorización de usuario en el entorno Web, hasta módulos independientes que
proporcionan verificación e identificación biométrica de acuerdo al estándar BioAPI. Con
el fin de ofrecer la mejor solución posible, antes de abordar cada una de esas tareas fue
necesario realizar un primer esfuerzo en labores de documentación en temas de Arquitecturas
Orientadas a Servicios, Servicios Web, Seguridad, Patrones de diseño (Fachada, DataAccessObject,
Factoría, ValueObject, Singleton, Model-View-Controller...), lenguajes
de programación (Java, C/C++, PHP,...), estándares, etc. El resultado de este proceso de
documentación se resume en la adquisición de los conocimientos necesarios para el desarrollo
de software basado en componentes con bajo acoplamiento y alta cohesión. Esto
se traduce en la creación de componentes reutilizables. En esta sección presentaremos la
solución software conocida como patrones de diseño[Patrones de diseño GoF, WWW].
3.5.1. Origen
En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el
libro The Timeless Way of Building, en él proponía el aprendizaje y uso de una serie de
patrones para la construcción de edificios de una mayor calidad. En palabras de este autor,
Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así
como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de
veces más adelante sin tener que volver a pensarla otra vez.
Los patrones que Christopher Alexander y sus colegas definieron, publicados en un
volumen denominado A Pattern Language, son un intento de formalizar y plasmar de
una forma práctica generaciones de conocimiento arquitectónico. Los patrones no son
principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria,
ni son específicos a una situación particular o cultural, son algo intermedio.
Un patrón define una posible solución correcta para un problema de diseño dentro de un
contexto dado, describiendo las cualidades invariantes de todas las soluciones.
Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander
para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un
artículo en OOPSLA-87 titulado Using Pattern Languages for OO Programs.

3.5. Patrones de diseño 51
No obstante, no fue hasta principios de los 90’s cuando los patrones de diseño tuvieron
un gran éxito en el mundo de la informática a partir de la publicación del libro
Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma,
Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño
comunes.
Un patrón de diseño es una abstracción de una solución en un nivel alto. Los patrones
solucionan problemas que existen en muchos niveles de abstracción. Hay patrones que
abarcan las distintas etapas del desarrollo, desde el análisis hasta el diseño, y desde la
arquitectura hasta la implementación. Los patrones de diseño pretenden:
Proporcionar catálogos de elementos reusables en el diseño de sistemas software,
Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados
anteriormente,
Formalizar un vocabulario común entre diseñadores,
Estandarizar el modo en que se realiza el diseño, y
Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento
ya existente.
Asimismo, los patrones de diseño no pretenden:
Imponer ciertas alternativas de diseño frente a otras.
Eliminar la creatividad inherente al proceso de diseño.
Hay que hacer hincapié en el hecho de que no es obligatorio utilizar los patrones, sólo
es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón,
siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Por otra
parte, abusar o forzar el uso de los patrones puede ser un error.
El grupo de GoF clasificaron los patrones en 3 grandes categorías basadas en su propósito:
patrones creacionales, estructurales y de comportamiento.
Creacionales: Los patrones creacionales tratan con las formas de crear instancias de
objetos. El objetivo de estos patrones es el de abstraer el proceso de instanciación y
ocultar los detalles de cómo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales describen como las clases y objetos pueden
ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades.
Estos objetos adicionados pueden ser incluso objetos simples u objetos
compuestos.
Comportamiento: Los patrones de comportamiento nos ayudan a definir la comunicación
e iteración entre los objetos de un sistema. El propósito de este patrón es
reducir el acoplamiento entre los objetos.
También clasificaron a los patrones en 2 ámbitos: Clases y objetos. Es así que, realmente
tenemos 6 tipos de patrones:

52 Capítulo 3. Base Tecnológica
Patrones Creacionales
Creacional de la Clase: Los patrones creacionales de clases usan la herencia como
un mecanismo para lograr la instanciación de la clase. Por ejemplo el método
Factoría.
Creacional del Objeto: Los patrones creacionales de objetos son más escalables
y dinámicos comparados con los patrones creacionales de clases. Por ejemplo
la Factoría abstracta y el patrón Singleton.
Patrones Estructurales
Estructural de la Clase: Los patrones estructurales de clases usan la herencia para
proporcionar interfaces más útiles combinando la funcionalidad de múltiples
clases. Por ejemplo el patrón Adaptador (clase).
Estructural de Objetos: Los patrones estructurales de objetos crean objetos complejos
agregando objetos individuales para construir grandes estructuras. La
composición del patrón estructural del objeto puede ser cambiado en tiempo
de ejecución, el cual nos da flexibilidad adicional sobre los patrones estructurales
de Clases. Por ejemplo el Adaptador (objeto), Façade, Bridge, Composite.
Patrones de Comportamiento
Comportamiento de Clase: Los patrones de comportamiento de clases usan la herencia
para distribuir el comportamiento entre clases. Por ejemplo Interpreter.
Comportamiento de Objeto: Los patrones de comportamiento de objetos nos permite
analizar los patrones de comunicación entre objetos interconectados, como
objetos incluidos en un objeto complejo. Ejemplo Iterator, Observer, Visitor.
3.5.2. Relación de principales patrones GoF
En esta sección describiremos los principales patrones definidos por el Gang of Four
siguiendo la misma clasificación que la presentada en la sección anterior:
Patrones Creacionales:
Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas
familias de manera que las familias no se mezclen entre sí y haciendo transparente
el tipo de familia concreta que se esté usando.
Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo,
centralizando dicho proceso en un único punto.
Factory Method (Método de fabricación): Centraliza en una clase constructora
la creación de objetos de un subtipo de un tipo determinado, ocultando al
usuario la casuística para elegir el subtipo que crear.

3.5. Patrones de diseño 53
Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
Singleton (Instancia única): Garantiza la existencia de una única instancia para
una clase y la creación de un mecanismo de acceso global a dicha instancia.
Patrones Estructurales:
Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una
clase que de otro modo no podría utilizarla.
Bridge (Puente): Desacopla una abstracción de su implementación.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de
uno simple se tratase.
Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
Facade (Fachada): Provee de una interfaz unificada simple para acceder a una
interfaz o grupo de interfaces de un subsistema.
Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos
poseen idéntica información.
Proxy: Mantiene un representante de un objeto.
Patrones de Comportamiento:
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea
que deben llevar los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar
dicha operación sin necesidad de conocer el contenido de la misma.
Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje,
así como las herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente
de la implementación de estos.
Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos
de distintas clases, pero que funcionan como un conjunto.
Memento (Recuerdo): Permite volver a estados anteriores del sistema.
Observer (Observador): Define una dependencia de uno-a-muchos entre objetos,
de forma que cuando un objeto cambie de estado se notifique y actualicen
automáticamente todos los objetos que dependen de él.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que
cambie su estado interno.
Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema
y elegir cuál utilizar en tiempo de ejecución.

54 Capítulo 3. Base Tecnológica
Template Method (Método plantilla): Define en una operación el esqueleto de un
algoritmo, delegando en las subclases algunos de sus pasos, esto permite que
las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases
sin modificar las clases sobre las que opera.
Patrones de Sistema
MVC (Modelo-Vista-Controlador): Divide un componente o un subsistema en
tres partes lógicas: modelo, vista y controlador, facilitando la modificación o
personalización de cada parte.
Session (Sesión): Ofrece una forma de que los servidores de sistemas distribuidos
sean capaces de distinguir los clientes, permitiendo que las aplicaciones asocien
el estado con la comunicación entre el cliente y el servidor.
Worker Thread (Thread trabajador): Mejora la productividad y minimiza la latencia
media.
Callback (Retrollamada): Permite que un cliente se registre en un servidor para
ciertas operaciones. De esta forma, el servidor puede notificar al cliente cuando
la operación ha finalizado.
Succesive Update (Actualización Sucesiva): Ofrece a los clientes una forma de
recibir actualizaciones continuas.
Router (Encaminador): Desacopla múltiples fuentes de información de los objetos
de esa información.
Transaction (Transacción): Agrupa una colección de métodos de forma que todos
ellos finalicen correctamente o fallen de forma colectiva.
3.5.3. Catálogo de patrones J2EE
En varios de los desarrollos software de esta Tesis se escogió J2EE como entorno
para su implementación debido a la naturaleza de los objetivos marcados en ella. Es
por ello que fue necesario el estudio tanto de este entorno como del catálogo de patrones
que tiene asociado. Desde que J2EE es una arquitectura por si misma que involucra
otras arquitecturas, incluyendo Servlets, JavaServer Pages, Enterprise JavaBeans, y más,
se dice que merece su propio conjunto de patrones específicos para diferentes aplicaciones
empresariales. Según el libro J2EE PATTERNS Best Practices and Design Strategies[Patrones
de diseño J2EE, WWW], existen 5 capas en la arquitectura J2EE:
Cliente
Presentación
Negocios
Integración

3.5. Patrones de diseño 55
Recurso
El libro citado explica 15 patrones J2EE dividiéndolos en 3 de las capas: presentación,
negocios e integración. A continuación daremos unos detalles sobre cada uno de ellos.
Capa de Presentación:
Decorating Filter / Intercepting Filter: Un objeto que está entre el cliente y los
componentes Web. Este procesa las peticiones y las respuestas.
Front Controller/ Front Component: Un objeto que acepta todos los requerimientos
de un cliente y los direcciona a manejadores apropiados. El patrón
Front Controller podría dividir la funcionalidad en 2 diferentes objetos: el
Front Controller y el Dispatcher. En ese caso, El Front Controller acepta todos
los requerimientos de un cliente y realiza la autenticación, y el Dispatcher
direcciona los requerimientos a manejadores apropiada.
View Helper: Un objeto helper que encapsula la lógica de acceso a datos en beneficio
de los componentes de la presentación. Por ejemplo, los JavaBeans
pueden ser usados como patrón View Helper para las páginas JSP.
Composite view: Un objeto vista que está compuesto de otros objetos vista. Por
ejemplo, una página JSP que incluye otras páginas JSP y HTML usando la
directiva include o el action include es un patrón Composite View.
Service To Worker: Es como el patrón de diseño MVC con el Controlador actuando
como Front Controller pero con una cosa importante: aquí el Dispatcher (el
cual es parte del Front Controller) usa View Helpers a gran escala y ayuda en
el manejo de la vista.
Dispatcher View: Es como el patrón de diseño MVC con el controlador actuando
como Front Controller pero con un asunto importante: aquí el Dispatcher (el
cual es parte del Front Controller) no usa View Helpers y realiza muy poco
trabajo en el manejo de la vista. El manejo de la vista es manejado por los
mismos componentes de la Vista.
Capa de Negocios:
Business Delegate: Un objeto que reside en la capa de presentación y en beneficio
de los otros componentes de la capa de presentación llama a métodos remotos
en los objetos de la capa de negocios.
Value Object/ Data Transfer Object/ Replicate Object: Un objeto serializable
para la transferencia de datos sobre lar red.
Session Façade/ Session Entity Façade/ Distributed Façade: El uso de un bean
de sesion como una fachada (facade) para encapsular la complejidad de las interacciones
entre los objetos de negocio y participantes en un flujo de trabajo.
El Session Façade maneja los objetos de negocio y proporciona un servicio de
acceso uniforme a los clientes.

56 Capítulo 3. Base Tecnológica
Aggregate Entity: Un bean entidad que es construido o es agregado a otros beans
de entidad.
Value Object Assembler: Un objeto que reside en la capa de negocios y crea Value
Objets cuando es requerido.
Value List Handler/ Page-by-Page Iterator/ Paged List: Es un objeto que maneja
la ejecución de consultas SQL, caché y procesamiento del resultado.
Usualmente implementado como beans de sesión.
Service Locator: Consiste en utilizar un objeto Service Locutor para abstraer toda
la utilización JNDI y para ocultar las complejidades de la creación del contexto
inicial, de búsqueda de objetos home EJB y recreación de objetos EJB.
Varios clientes pueden reutilizar el objeto Service Locutor para reducir la complejidad
del código, proporcionando un punto de control.
Capa de Integración:
Data Access Object: Consiste en utilizar un objeto de acceso a datos para abstraer
y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexión
con la fuente de datos para obtener y almacenar datos.
Service Activator: Se utiliza para recibir peticiones y mensajes asíncronos de los
clientes. Cuando se recibe un mensaje, el Service Activator localiza e invoca
a los métodos de los componentes de negocio necesarios para cumplir la
petición de forma asíncrona.
Concluimos constatando la aplicación en esta Tesis de algunos de los patrones presentados
en esta sección. Entre los más utilizados en el diseño de las distintas soluciones
software realizadas están: Fachada, Data Access Object, Factoría, Value Object, Singleton,
Model-View-Controller, Business Delegate, etc.
3.6. Conclusiones
En este capítulo hemos expuesto la base tecnológica necesaria para comprender cada
uno de los componentes de las arquitecturas software presentadas en los capítulos posteriores.
Se han presentado distintas tecnologías biométricas existentes, el concepto de
servicio de autenticación centralizada, la tecnología de los servicios web, algunas bases
de procesado de imagen, y una guía de buenas prácticas de programación. Todo ello con
el fin de proporcionar al lector el background necesario para una adecuada comprensión
de las soluciones presentadas en los próximos capítulos.

Capítulo 4
Diseño y Desarrollo de un Sistema de
Autenticación Biométrica de Estudiante
para Plataformas LMS
Contenido
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2. Proyecto de Código Libre BioWebAuth (BWA) . . . . . . . . . . . . 59
4.2.1. Diseño del BioWebAuth Framework . . . . . . . . . . . . . . . 60
4.2.2. Interacción Hombre-Máquina en BWA: Modelado XML de
Captura, Enrollment y Verificación . . . . . . . . . . . . . . . . 63
4.2.3. Una Visión Global del Framework BWA . . . . . . . . . . . . 69
4.2.4. Integrando BioAPI en el Entorno Cliente-Servidor de BWA . . 72
4.2.5. Contribuciones al Proyecto de Código Libre JBioAPI . . . . . . 74
4.2.6. Conexión Cliente-Servidor de BWA: Web Services y XCBF . . 74
4.3. Integración de BWA con las Plataformas LMS . . . . . . . . . . . . 75
4.4. Análisis de Seguridad y Validación del BioWebAuth Framework . . 75
4.4.1. Análisis de Seguridad de la Arquitectura de BWA siguiendo la
Taxonomía CERT . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5. Desarrollo de Módulos de Reconocimiento Biométrico según la Especificación
BioAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.1. Módulo de Reconocimiento Facial: BWAFaceBSP . . . . . . . 77
4.5.2. Módulo de Reconocimiento de Locutor: BWAVoiceBSP . . . . 78
4.5.3. Módulo de Reconocimiento Multimodal basado en Cara y Voz:
BWAMultimodalFaceAndVoiceBSP . . . . . . . . . . . . . . . 80
4.5.4. Módulo de Reconocimiento de Firma Dinámica: SignatureBSP 81
4.5.5. Módulo de Reconocimiento de Huella Dactilar: BWAFingerprintBSP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

58
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
4.6. Alcance, Difusión y Repercusión de la Plataforma BWA . . . . . . . 82
4.6.1. Estadísticas sobre el Repositorio de BWA en SourceForge . . . 83
4.6.2. Estadísticas sobre el Demostrador Online de BWA . . . . . . . 83
4.7. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
En este capítulo presentamos la solución que hemos diseñado para poder realizar autenticación
biométrica de estudiante en las plataformas de E-Learning. Se trata del proyecto
de código abierto BioWebAuth (Biometrics for Web Authentication) (BWA) que ofrece
un servicio de autenticación biométrica centralizada para plataformas Web, basándose
en el proyecto Central Authentication Service (CAS) y en el estándar BioAPI, y que se
encuentra disponible en SourceForge ∗ .
La estructura de este capítulo es la siguiente, comenzaremos en la sección 4.1 con una
breve introducción de la problemática que queremos resolver. En la sección 4.2 presentaremos
una visión global de la solución propuesta en esta Tesis, describiéndola tanto desde
un punto de vista funcional como estructural. Luego, en la sección 4.3 mostraremos como
se realiza la integración de BWA con varias plataformas de E-learning. Continuaremos
con un análisis de seguridad realizado sobre toda la plataforma en la sección 4.4. En la
sección 4.5 se presentarán los distintos módulos de reconocimiento biométrico que disponemos
en la plataforma. En la sección 4.6 se muestran varios informes que reflejan el
alcance, la difusión y la repercusión de la solución propuesta. La sección 4.7 muestra algunas
tareas en las que todavía debemos trabajar y que pueden ser vistas como limitaciones
actuales o líneas futuras. Finalmente, la sección 4.8 concluye el capítulo.
4.1. Introducción
En los últimos años las aplicaciones Web han experimentado una gran difusión sobre
nuestras redes. En ellas, a menudo el usuario debe realizar un proceso previo de autenticación
para poder acceder a los servicios que ofrecen. En una sesión típica de navegación
Web, el usuario necesita acceder a diferentes aplicaciones (gestor de correo Web, plataformas
de aprendizaje, etc.). Para cada una de ellas el usuario debe proporcionar unas
credenciales para poder utilizar los servicios ofrecidos. Esto es una tarea tediosa, una
solución mucho más amigable para el usuario sería que el proceso de autenticación se
realizase una única vez al principio de la sesión de navegación Web, y poder acceder después
a múltiples aplicaciones sin tener que repetir el proceso de autenticación en cada una
de ellas. Este es el principio básico para todas las soluciones de autenticación centralizada
(SSO). Por otra parte, los mecanismos clásicos de autenticación empleados en entornos
Web presentan numerosos inconvenientes en lo que se refiere a la fiabilidad del proceso
de autenticación. Al tratarse de un entorno con operaciones remotas, a los problemas de
seguridad típicos asociados a operaciones locales (como la pérdida o el robo de tarjetas
∗ http://sourceforge.net/projects/biowebauth/

4.2. Proyecto de Código Libre BioWebAuth (BWA) 59
de identificación, el olvido o el intercambio de claves de los usuarios) hay que añadir los
posibles ataques de un pirata informático a través de la red.
Lo que en los últimos años está atrayendo una gran atención en el reconocimiento
automático de usuario basado en sus características anatómicas (cara, voz, huella, iris,
etc.) o de comportamiento (firma estática/dinámica, forma de teclear, etc.).
Teniendo en cuenta todas estas consideraciones, en este capítulo se presenta un framework
que integra un módulo de verificación biométrica dentro de una solución clásica
de autenticación centralizada. Para este propósito, hemos escogido una solución extensamente
aceptada llamada Central Authentication Service (CAS) [CAS Project, WWW] ya
presentada en capítulos anteriores (ver sección 3.2.1). Como ya hemos dicho, se trata de
una plataforma de código libre basada en JAVA que en sus orígenes fue desarrollada por
la Universidad de Yale y que actualmente se encuentra bajo los auspicios del grupo Java
Architectures Special Interest Group (JA-SIG). Hoy en día, tiene una extensa comunidad
de adeptos. De hecho, ese sistema de código libre ha llegado a ser rápidamente el sistema
de autenticación centralizada más popular para universidades, especialmente en E.E.U.U..
La idea principal que reside tras la incorporación de verificación biométrica dentro de
CAS es aprovechar toda su infraestructura para proporcionar un sistema de autenticación
centralizada que proporcione un mayor nivel de seguridad al que se ofrece empleando los
clásicos mecanismos de login y password, añadiendo el uso de características biométricas.
De este modo, hacemos posible que cualquier aplicación compatible con CAS pueda
utilizar de manera transparente nuestra solución biométrica para autenticar a sus usuarios.
El proceso de autenticación biométrica subyacente se delega en módulos que cumplen
el estándar BioAPI lo que convierte a este sistema en una solución abierta al soportar cualquier
software o dispositivo desarrollado por terceros que sea compatible con el estándar
BioAPI 1.2.
Actualmente, numerosas plataformas de E-learning son capaces de delegar el proceso
de autenticación en CAS tal y como se muestra en la sección 3.2.1.1. Es por ello que
cualquiera de ellas podría sacar partido de las ventajas que ofrece el sistema presentado en
este capítulo. Por citar alguna, las plataformas de código libre Moodle, ILIAS o Claroline
son ejemplos bien conocidos, y en los que hemos integrado con éxito el módulo CAS
biométrico.
4.2. Proyecto de Código Libre BioWebAuth (BWA)
Biometric for Web Authentication (BioWebAuth) engloba un proyecto de código
libre que ofrece autenticación Web centralizada usando características biométricas del
usuario, adoptando para ello los estándares más adecuados. El proyecto BWA ha sido
desarrollado en la Universidad de Vigo durante la elaboración de esta Tesis, está disponible
como proyecto de código libre en SourceForge [BioWebAuth Project, WWW]
y se puede encontrar una descripción más detallada sobre su arquitectura en el artículo
[Otero Muras y otros, 2007a].

60
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
4.2.1. Diseño del BioWebAuth Framework
Dado que BWA ofrece un servicio a través del World Wide Web, se han tenido en
cuenta durante su etapa de diseño varios criterios relevantes con este entorno. A continuación
enumeraremos y haremos una breve descripción de estos criterios.
Funcionalidad: Con el fin de poder abarcar una población de usuarios lo mayor
posible, BWA soporta por defecto dos de los rasgos biométricos más extendidos:
cara y voz. Estos rasgos biométricos han sido elegidos porque sus muestras pueden
ser adquiridas con dispositivos de bajo coste, como cámaras web y micrófonos, y
que actualmente ya vienen incorporados de serie en cualquier ordenador portátil. De
este modo, no es necesario disponer en cada hogar de los usuarios de dispositivos
biométricos de precio elevado como por ejemplo un escáner de iris. Así, la elección
de estos rasgos biométricos maximiza el tamaño de la población que puede verse
beneficiada del servicio que ofrece BWA. Además de estos rasgos, se han incluido
también las biometrías de huella dactilar y firma dinámica, ya que los dispositivos
de captura son cada día más baratos.
Portabilidad: De nuevo, el objetivo es cubrir el mayor número de usuarios posible.
Para conseguir esta meta, una posible solución es ofrecer una solución independiente
del sistema operativo. Por ello, la aplicación servidora se ha implementado
usando Java, y la aplicación cliente usando Java Web Start.
Interoperabilidad: Esta pauta se refiere a la habilidad de cooperación entre la aplicación
cliente y los diferentes dispositivos de captura de muestras biométricas. Se
persigue que BWA sea una solución abierta que pueda ser usada con el mayor número
de dispositivos posibles, y por ello, hemos adoptado el estándar biométrico Bio-
API que asegura la compatibilidad con un amplio abanico de módulos biométricos
desarrollados por terceros. Con este objetivo en mente, se ha usado el proyecto de
código libre JBioAPI que permite acceder y gestionar desde Java al BioAPI Framework
sobre entornos Unix y Windows [González Agulla, Elisardo y otros, 2009c].
Paralelamente, BWA ofrece un modo de funcionamiento ad-hoc en el que emplea
Java Media Framework para manejar una amplia gama de cámaras web y micrófonos,
y poder realizar la captura de muestras de voz y de caras, sin la necesidad
de tener el BioAPI Framework instalado en la máquina cliente. Otra importante
decisión relacionada con la interoperabilidad fue la selección de Servicios Web en
lugar de CORBA o JavaRMI como mecanismo de comunicación entre la aplicación
cliente y la servidora.
Aceptabilidad: La acogida de esta aplicación está asegurada por el uso de aplicaciones
estándar de código libre. Durante el desarrollo de BWA, han sido usados
componentes como el gestor de base de datos MySQL o el servidor de aplicaciones
web JBOSS. Esto asegura su aceptación entre los vendedores finales ya que estos
productos son gratuitos y pueden ser fácilmente adaptados a distintos entornos.
Confiabilidad: La fiabilidad de un sistema distribuido de autenticación biométrica
es esencial por el tipo de información que se maneja y el objetivo que persigue. Para

4.2. Proyecto de Código Libre BioWebAuth (BWA) 61
alcanzar esta meta, BWA hace uso de varios recursos. Algunos ejemplos son el uso
de conexiones SSL durante el envío de muestras biométricas, la implementación de
políticas de seguridad como la adopción del estándar ANSI X9.84. Otros ejemplos
radican en intentar complicar la decompilación del código Java con técnicas de
ofuscación, evitar el almacenamiento de muestras en disco en el equipo cliente,
utilizar WS-Security en el intercambio de mensajes SOAP, etc.
Usabilidad: Se ha diseñado una interfaz de usuario amigable con la cual el usuario
interactúa. Esta interacción entre el sistema y el usuario es especificada con un
documento XML que describe el proceso de adquisición de una muestra biométrica,
la creación de la plantilla o modelo de usuario correspondiente, y el proceso de
verificación.
Multilenguaje: BWA pretende ser una aplicación que opere en el World Wide Web.
Es por ello que debe proporcionar soporte en más de un idioma. Actualmente, BWA
soporta Gallego, Español e Inglés.
Como ya hemos dicho anteriormente, cualquier procedimiento de reconocimiento biométrico
puede ser dividido en las siguientes fases:
1. Adquisición de una muestra biométrica (procesado dependiente del dispositivo).
2. Extracción de una plantilla biométrica (procesado de señal: preprocesado, extracción
de características y creación de la plantilla del usuario).
3. Comparación de plantillas biométricas (procesado de reconocimiento de patrones).
La tercera de estas fases generalmente requiere un entrenamiento previo de los modelos
de usuario y un ajuste de umbrales en el proceso de registro cuando un nuevo usuario
es añadido al sistema. El proceso de comparación puede realizarse para tareas de identificación
o de verificación. Como ya sabemos, en el primero la plantilla biométrica es
comparada contra todos las plantillas de usuarios con autorización para acceder al sistema.
En el segundo caso, la plantilla biométrica es comparada contra un usuario en concreto.
La verificación es el modo más común de comparación para el acceso restringido a
aplicaciones.
Por otra parte, en aplicaciones biométricas distribuidas en arquitecturas clienteservidor,
los tres procesos descritos anteriormente proporcionan diferentes posibles configuraciones
dependiendo de donde se ejecuten cada uno de ellos. A pesar de que es obvio
que el proceso de captura de la muestra debe ser ejecutado del lado del cliente, quedan
tres configuraciones posibles para realizar los procesos de extracción de las plantillas biométricas
y comparación de las mismas. Estas configuraciones son: ambos procesos se
ejecutan en la máquina cliente (Pull model); la plantilla biométrica se extrae del lado del
cliente, se envía al servidor y es comparada contra las plantillas de los usuarios referenciados
(Push model); o ambos procesos son ejecutados del lado del servidor (una variante
del Push model). Los pros y contras de estas tres posibles configuraciones se detallan a
continuación:

62
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
1. Push Model: Según este modelo ambos procesos se ejecutan en la máquina cliente.
La autenticación en el lado del cliente tiene muchos inconvenientes. Las operaciones
necesarias pueden no ser viables computacionalmente hablando en la máquina
cliente, ni tampoco es factible el proceso de identificación con un número elevado
de posibles usuarios. Además, hay varios inconvenientes relacionados con la seguridad,
ya que al ejecutar todo el proceso de autenticación en el lado del cliente, éste
se hace más vulnerable, debido a que las máquinas clientes son potencialmente más
inseguras. Nótese que en el proceso de verificación es necesaria la transacción de
la plantilla del usuario en cuestión desde la base de datos del servidor a la máquina
cliente sobre una conexión segura para evitar una posible intercepción por parte de
un pirata. Si la privacidad realmente es importante, se puede utilizar una smart-card
para almacenar la plantilla biométrica del usuario, evitando de este modo el almacenamiento
centralizado de datos biométricos en un servidor, y evitando su envío a
través de la red. Esta solución es, a día de hoy, dentro del ámbito tecnológico, un
campo muy prometedor ya que combina las tres premisas del proceso de autenticación:
algo que el usuario sabe, algo que el usuario posee, y algo que el usuario
es.
2. Pull Model con extracción de características en el lado del cliente: El proceso de
extracción de los datos biométricos a partir de la muestra se hace del lado del cliente
y la comparación de plantillas biométricas del lado del servidor. Esta alternativa
tiene los inconvenientes de colocar la mayor parte de la carga computacional del
lado del cliente. Esto es debido a que el preprocesado de la muestra y la extracción
de características generalmente tiene asociado una gran carga computacional (CPU
y memoria) que suele ser mayor que la necesaria para realizar la comparación de
plantillas biométricas. Además, estos procesos se ejecutan en una máquina no segura
antes de que la plantilla se envíe por un canal seguro al servidor lo que posibilita
algunos ataques como el remplazo de la misma.
3. Pull Model con extracción de características del lado del servidor: Tanto la generación
de la plantilla como el proceso de autenticación del lado del servidor tienen
la ventaja de que la carga computacional recae del lado del servidor, donde puede
haber un equipo muy potente. Como consecuencia de esto, ninguna plantilla biométrica
es enviada por la red, pero si lo es la muestra biométrica capturada. Aunque
es necesario utilizar encriptación para esa transacción, es importante matizar que
las muestras biométricas no son información secreta. La cara y la voz de un cliente
pueden ser fácilmente grabadas, las huellas dactilares se dejan sobre muchos objetos
y pueden ser recuperadas, las firmas pueden ser fácilmente fotografiadas, etc.
Por ello, estos datos serían menos peligrosos en manos de un pirata que una plantilla
biométrica de usuario, pues la seguridad de un sistema de autenticación no recae
en la discreción (confidencialidad) sino en la integridad de los datos biométricos
[X9.84, 2003]. Finalmente, según nuestro criterio este modelo es la mejor configuración
desde el punto de vista de la seguridad y versatilidad, pues la parte pesada
del sistema recae del lado del servidor. Así, en el lado del cliente, que es el punto
más débil de la cadena, recae la única responsabilidad de la adquisición de las
muestras biométricas. Las desventajas de esta configuración están relacionadas con

4.2. Proyecto de Código Libre BioWebAuth (BWA) 63
el ancho de banda de la conexión cliente-servidor y con el hecho de que el servidor
deberá soportar la carga computacional de las múltiples y simultáneas peticiones de
acceso.
El sistema que hemos desarrollado se basa en la tercera de las configuraciones citadas
anteriormente. Del lado del cliente, la aplicación biométrica cliente de BWA se encarga
de la adquisición de distintos tipos de muestras, su encriptación y su envío. Del lado del
servidor, hay un servicio de autenticación centralizada con un módulo de autenticación
biométrica que está encargado de generar la plantilla biométrica del usuario para las peticiones
de registro, y de realizar la comparación y comprobar los permisos de acceso para
las peticiones de verificación.
4.2.2. Interacción Hombre-Máquina en BWA: Modelado XML de
Captura, Enrollment y Verificación
La interacción del usuario con el sistema durante las fases de registro y de verificación
se especifica utilizando documentos XML que describen de un modo flexible las tareas a
realizar en cada una de estas fases. En estos documentos XML se especifican las tareas
de adquisición de muestras biométricas, la creación de plantillas biométricas (en las fases
de enrollent), y la comparación de planillas biométricas (en las fases de verificación). En
cierta medida, este diálogo XML permite especificar de una manera flexible y cómoda
las llamadas a las funciones nativas que ofrece la BioAPI sobre los distintos BSPs que se
encuentren instalados en los equipos cliente y servidor.
Al principio de los trabajos de Tesis necesitábamos un modo sencillo de definir
diálogos hombre-máquina que modelasen el proceso de autenticación biométrica. Esos
diálogos deberían tener la capacidad de gestionar la captura de muestras biométricas.
En los tiempos en que se inició esta Tesis no existía ningún estándar basado en XML
que se ajustase completamente a nuestras necesidades. Tomamos la decisión de extender
VoiceXML ya que se ajustaba parcialmente a nuestras necesidades pues permitía
especificar la captura de muestras de voz de un modo sencillo. A esta extensión de
VoiceXML la bautizamos como BioVXML [González Agulla, Elisardo y otros, 2004b]
[Argones Rúa y otros, 2004], y permitía manejar diferentes tipos de datos biométricos,
como voz y caras. Para ello, a partir del DTD del estándar VoiceXML creamos
un nuevo DTD para nuestro BioVXML, al que le añadimos dos nuevas etiquetas
que especificaban las tareas de registro y de verificación (enroll y verify),
y modificamos la definición del la etiqueta record para que soportase otras fuentes
de captura. Se implementó un demostrador [González Agulla, Elisardo y otros, 2004a,
González Agulla, Elisardo y otros, 2005] para validar la solución propuesta. Este demostrador
no era compatible con el estándar BioAPI lo que nos sirvió para encontrar
algunas debilidades en su arquitectura.
Con la evolución del sistema, BioVXML ha ido convergiendo hacia el estándar Bio-
API, pudiendo modelar actualmente el proceso de identificación de usuario, y proporcionar
gestión de calidad en el proceso de captura de las muestras. Esta evolución nos ha
permitido ir un paso más allá, ya que la especificación 1.2 de la BioAPI no permite realizar
fusión multibiométrica. Con BioVXML podemos realizar de fusión multimodal, tanto

64
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
a nivel de decisión, como de puntuación, de los resultados de verificaciones monomodales
realizadas por distintos BSP. Los nombres de las etiquetas de BioVXML han pasado a ser
una correspondencia uno-a-uno con el estándar BioAPI. De este modo BioVXML se ha
ido separando poco a poco de VoiceXML, y seguramente sería más apropiado a día de
hoy rebautizarlo con el nombre de BioAPIXML.
En este apartado vamos a describir funcionalmente las principales etiquetas de Bio-
APIXML, detallando brevemente sus atributos.
La etiqueta nos permite modelar en el diálogo el proceso de envío de
información o instrucciones desde el sistema al usuario.
La etiqueta nos permite modelar en el diálogo el proceso de captura de
una muestra haciendo uso del BioAPI Framework. Los atributos de esta etiqueta
son:
name: Representa al BIR devuelto por la BioAPI.
bsp: Identificador del BSP seleccionado (ej.
263a41e0-71eb-11d4-9c34-1240370001810).
purpose: Propósito de la captura según la BioAPI (ej. PURPOSE_VERIFY).
timeout (opcional): Tiempo máximo permitido para efectuar la captura.
minquality (opcional): Calidad mínima de la muestra devuelta (ej. 0-100).
maxattempts (opcional): N o máximo de intentos en el proceso de captura (por
defecto, 1).
La etiqueta nos permite modelar en el diálogo el proceso
de creación de la plantilla biométrica del usuario o template a
partir de una muestra. Recibe como parámetro la muestra adquirida
usando la etiqueta con alguno de los siguientes propósitos:
PURPOSE_ENROLL, PURPOSE_ENROLL_FOR_VERIFICATION_ONLY,
ENROLL_FOR_IDENTIFICATION_ONLY. Los atributos de esta etiqueta son:
name: Representa el valor devuelto por la BioAPI.
bsp: Identificador del BSP seleccionado (ej.
263a41e0-71eb-11d4-9c34-1240370001810).
La etiqueta nos permite modelar en el diálogo el proceso de verificación.
Recibe como parámetro la muestra adquirida usando la etiqueta
con el siguiente propósito: PURPOSE_VERIFY. Los atributos de esta etiqueta son:
name: Representa el resultado de la verificación devuelto por la BioAPI, incluye
información tanto de la decisión booleana como del valor de FAR conseguido.
La devolución del valor de FRR es opcional.
bsp: Identificador del BSP monomodal y multimodal seleccionado (ej.
263a41e0-71eb-11d4-9c34-1240370001810).

4.2. Proyecto de Código Libre BioWebAuth (BWA) 65
requestedfar: Este atributo especifica en tanto por ciento el valor máximo de False
Accept Rate (FAR) que se corresponde con una verificación verdadera (ej.
10 %).
requestedfrr (opcional): Este atributo especifica en tanto por ciento el valor máximo
de False Reject Rate (FRR) que se corresponde con una verificación
verdadera (ej. 10 %).
farprecedence (opcional): Este atributo indica si el cálculo de la FAR tiene precedencia
respecto del cálculo de la FRR.
La etiqueta nos permite modelar extrínsecamente en el diálogo
el proceso de fusión multimodal de los resultados de varias verificaciones. Cada
resultado a fusionar se puede corresponder tanto con un BSP monomodal como con
un BSP multimodal que realice intrínsecamente algún tipo de fusión. Recibe como
parámetros las muestras adquiridas usando la etiqueta con el siguiente
propósito: PURPOSE_VERIFY. Los atributos de esta etiqueta son:
name: Representa el resultado de la fusión multimodal devuelto por la BioAPI,
incluye información tanto de la decisión booleana como del valor de FAR
conseguido. La devolución del valor de FRR es opcional.
method: Representa el tipo de fusión a realizar. Hemos definido métodos
de fusión a nivel de decisión (ej. MultimodalFusionAlgorithmImplOR y
MultimodalFusionAlgorithmImplAND), y métodos de fusión a nivel de scores
(ej. MultimodalFusionAlgorithmImplDefault) donde se toma como score
los valores de FAR y FRR devueltos.
requestedfar: Este atributo especifica en tanto por ciento el valor máximo de FAR
que se corresponde con una verificación verdadera (ej. 10 %).
requestedfrr (opcional): Este atributo especifica en tanto por ciento el valor mínimo
de FRR que se corresponde con una verificación verdadera (ej. 10 %).
farprecedence (opcional): Este atributo indica si el cálculo de la FAR tiene precedencia
respecto del cálculo de la FRR.
La etiqueta nos permite modelar en el diálogo el proceso de identificación.
Recibe como parámetro la muestra adquirida usando la etiqueta con
el siguiente propósito: PURPOSE_IDENTIFY. Los atributos de esta etiqueta son:
name: Representa el resultado de la identificación devuelto por la BioAPI indicando, en
caso de una identifiación positiva, el identificador del primer candidato dentro de la
población y los valores de FAR y FRR devueltos.
bsp: Identificador del BSP monomodal y multimodal seleccionado (ej. 263a41e0-71eb-
11d4-9c34-1240370001810).
requestedfar: Este atributo especifica en tanto por ciento el valor máximo de FAR que
se corresponde con una identificación verdadera (ej. 10 %).

66
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
requestedfrr (opcional): Este atributo especifica en tanto por ciento el valor máximo de
FRR que se corresponde con una identificación verdadera (ej. 10 %).
farprecedence (opcional): Este atributo indica si el cálculo de la FAR tiene precedencia
respecto del cálculo de la FRR.
A continuación vamos a mostrar cuatro ejemplos de diálogos escritos en BioAPIXML
en los que se aprecia claramente las ventajas (flexibilidad y comodidad) de definir
las tareas de registro, verificación, verificación multimodal e identificación biométrica
utilizando documentos XML.
< !DOCTYPE vxml PUBLIC " BioVoiceXML "
" h t t p : / / l o c a l h o s t : 8 0 8 0 / biowebauth / d t d / bvxml30 . d t d ">
< b l o c k >
S t a r t i n g an e n r o l l m e n t s e s s i o n f o r f a c e v e r i f i c a t i o n .
< / prompt >
< / b l o c k >
< c a p t u r e name=" f a c e " bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 "
p u r p o s e ="PURPOSE_ENROLL" t i m e o u t =" 50 s " m i n q u a l i t y =" 70 "
maxattempts =" 3 ">
P l e a s e , f o l l o w t h e BSP i n s t r u c t i o n s . < / prompt>
< / c a p t u r e >
< b l o c k > E n r o l l i n g . P l e a s e , w a i t . . . < / prompt>< / b l o c k >
< c r e a t e t e m p l a t e name=" monoface "
bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 ">
< / c r e a t e t e m p l a t e >
< b l o c k > The e n r o l l m e n t has f i n i s h e d . < / prompt>< / b l o c k >
< / form>
< / vxml>
Listing 4.1: Ejemplo de diálogo BioVXML que realiza un enrollment monomodal
utilizando el BWAFaceBSP.
Como podemos ver, el Listing 4.1 describe un registro de usuario en donde se utiliza
nuestro BSP de caras. Se pueden apreciar claramente las tareas de adquisición de la
muestra biométrica y de creación de la plantilla biométrica del usuario para ese BSP.
< !DOCTYPE vxml PUBLIC " BioVoiceXML "
" h t t p : / / l o c a l h o s t : 8 0 8 0 / biowebauth / d t d / bvxml30 . d t d ">
< b l o c k >
S t a r t i n g a v e r i f i c a t i o n s e s s i o n f o r f a c e v e r i f i c a t i o n .
< / prompt >

4.2. Proyecto de Código Libre BioWebAuth (BWA) 67
< / b l o c k >
< c a p t u r e name=" f a c e " bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 "
p u r p o s e ="PURPOSE_VERIFY" t i m e o u t =" 50 s " m i n q u a l i t y =" 31 "
maxattempts =" 2 ">
P l e a s e , f o l l o w t h e BSP i n s t r u c t i o n s . < / prompt>
< / c a p t u r e >
< b l o c k > Mono V e r i f y i n g . P l e a s e , w a i t . . . < / prompt>< / b l o c k >
< v e r i f y m a t c h name=" monoface "
bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 " r e q u e s t e d f a r ="10 %"
f a r p r e c e d e n c e =" t r u e " r e q u e s t e d f r r ="10 %">
< / v e r i f y m a t c h >
< b l o c k > The v e r i f i c a t i o n has f i n i s h e d . < / prompt>< / b l o c k >
< / form>
< / vxml>
Listing 4.2: Ejemplo de diálogo BioVXML que realiza una verificación monomodal
utilizando el BWAFaceBSP.
Como podemos ver, el Listing 4.2 describe una verificación monomodal en la que se
utiliza nuestro BSP de caras. Se pueden apreciar claramente las tareas de adquisición de
la muestra biométrica y de comparación.
< !DOCTYPE vxml PUBLIC " BioVoiceXML "
" h t t p : / / l o c a l h o s t : 8 0 8 0 / biowebauth / d t d / bvxml30 . d t d ">
< b l o c k >
S t a r t i n g a v e r i f i c a t i o n s e s s i o n f o r f u s i o n of v o i c e and f a c e
v e r i f i c a t i o n .
< / prompt >
< / b l o c k >
< c a p t u r e name=" v o i c e " bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000182}0 "
p u r p o s e ="PURPOSE_VERIFY" t i m e o u t =" 50 s " m i n q u a l i t y =" 31 "
maxattempts =" 2 ">
P l e a s e , f o l l o w t h e BSP i n s t r u c t i o n s . < / prompt>
< / c a p t u r e >
< c a p t u r e name=" f a c e " bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 "
p u r p o s e ="PURPOSE_VERIFY" t i m e o u t =" 50 s " m i n q u a l i t y =" 31 "
maxattempts =" 2 ">
P l e a s e , f o l l o w t h e BSP i n s t r u c t i o n s . < / prompt>
< / c a p t u r e >
< b l o c k > M u l t i V e r i f y i n g . P l e a s e , w a i t . . . < / prompt>< / b l o c k >
< m u l t i v e r i f y m a t c h name=" m u l t i v e r i f y "

68
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
method=" MultimodalFusionAlgorithmImplOR " f a r p r e c e d e n c e =" t r u e "
r e q u e s t e d f a r ="5 %" r e q u e s t e d f r r ="5 %">
< / m u l t i v e r i f y m a t c h >
< b l o c k > The v e r i f i c a t i o n has f i n i s h e d . < / prompt>< / b l o c k >
< / form>
< / vxml>
Listing 4.3: Ejemplo de diálogo BioVXML que realiza una verificación multimodal
extrínseca.
Como podemos ver, el Listing 4.3 describe una verificación multimodal que realiza
fusión biométrica de dos biometrías monomodales. El algoritmo de fusión seleccionado
actúa a nivel de decisión y consiste en la aplicación de la función lógica OR. Se realiza la
fusión de dos verificaciones monomodales correspondientes a una verificación de voz y
otra de caras.
< !DOCTYPE vxml PUBLIC " BioVoiceXML "
" h t t p : / / l o c a l h o s t : 8 0 8 0 / biowebauth / d t d / bvxml30 . d t d ">
< b l o c k >
S t a r t i n g an i d e n t i f i c a t i o n u s i n g f a c e f e a t u r e s .
< / prompt >
< / b l o c k >
< c a p t u r e name=" f a c e " bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 "
p u r p o s e ="PURPOSE_IDENTIFY" t i m e o u t =" 50 s " m i n q u a l i t y =" 31 "
maxattempts =" 2 ">
P l e a s e , f o l l o w t h e BSP i n s t r u c t i o n s . < / prompt>
< / c a p t u r e >
< b l o c k > I d e n t i f y i n g . P l e a s e , w a i t . . . < / prompt>< / b l o c k >
< i d e n t i f y m a t c h name=" i d e n t i f y "
bsp=" {263 a41e0 −71eb −11d4−9c34 −124037000181}0 " r e q u e s t e d f a r ="10 %"
f a r p r e c e d e n c e =" t r u e " r e q u e s t e d f r r ="10 %">
< / i d e n t i f y m a t c h >
< b l o c k > The i d e n t i f i c a t i o n has f i n i s h e d . < / prompt>< / b l o c k >
< / form>
< / vxml>
Listing 4.4: Ejemplo de diálogo BioVXML que realiza una identificación.
Para finalizar, el Listing 4.4 describe una identificación biométrica de usuario que
utiliza nuestro BSP de caras. En él se pueden apreciar claramente las tareas de adquisición
y de identificación. Actualmente, aunque BioAPIXML permite modelar el servicio

4.2. Proyecto de Código Libre BioWebAuth (BWA) 69
de identificación, BWA no ofrece este el servicio de identificación, sino que solamente
proporciona un servicio de verificación biométrica.
4.2.3. Una Visión Global del Framework BWA
Como hemos mencionado anteriormente, en BWA un documento XML especifica el
proceso de adquisición de una muestra biométrica durante las sesiones de registro y de
verificación. Este documento representa la interacción entre el usuario y el sistema, es
decir, el diálogo entre el hombre y la máquina. En la Figura 4.1 podemos ver un diagrama
de bloques que refleja la descripción funcional del Framework que a continuación
detallaremos y que guarda relación con lo que se especifique en los diálogos XML (ver
numeración en la Figura 4.1).
Figura 4.1: Diagrama de Bloques y Descripción Funcional de BioWebAuth.
1. La aplicación cliente Java Web Start obtiene del servidor el diálogo XML que describe
el proceso de registro/verificación.
2. El gestor del diálogo interpreta las instrucciones de alto nivel, mostrando mensajes
al usuario, adquiriendo muestras biométricas, y ejecutando las tareas de enrollment
o verificación.

70
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
3. Cada vez que se necesita adquirir una muestra biométrica, la aplicación cliente interroga
al BSP instalado localmente usando la primitiva BioAPI_Capture que ofrece
el JBioAPI Wrapper, o a partir de una aplicación ad-hoc totalmente Java que utiliza
Java Media Framework para controlar los dispositivos de audio y de vídeo del
equipo. La segunda opción se proporciona para poder utilizar de un modo sencillo
webcams y micrófonos sin tener que forzar a los clientes a instalar una BioAPI local
en sus equipos.
4. El resultado del proceso de adquisición se envuelve en un testigo biométrico XCBF
y es enviado al servidor en forma de una petición de enrollment o verificación.
5. En el servidor se ejecuta el proceso de enrollment o verificación como una secuencia
de llamadas a la BioAPI del servidor.
6. La plantilla del usuario o el resultado de la verificación es almacenado en la base
de datos.
7. El resultado de la verificación de usuario esta disponible para, finalmente, autenticar
al usuario usando el Central Authentication Service.
El principal objetivo de BioWebAuth (Biometrics for Web Authentication) (BWA) es
ofrecer a otras aplicaciones Web la capacidad de realizar autenticación biométrica. Nosotros
no hemos diseñado ningún nuevo servicio de autenticación desde cero dada la gran
variedad de proyectos de código libre existentes que ofrecían el clásico servicio de autenticación
centralizada (single sign-on) para entornos web. Algunos de ellos emplean el
intercambio de atributos de usuario (identity federation) o incluyen control de acceso y
políticas de autorización. Nosotros estamos más interesados, sin embargo, en el proceso
de autenticación en sí mismo, especialmente, en ofrecer un servicio de autenticación
centralizada para plataformas, recursos o aplicaciones web. Hemos integrado nuestro framework
biométrico como un módulo de autenticación en el proyecto CAS, un sistema
ampliamente aceptado que ha sido desarrollado en Java por la Yale University. La idea
principal detrás de esta integración consistente en tomar las ventajas de la infraestructura
que proporciona CAS y mejorar el nivel de seguridad que proporciona remplazando la autenticación
clásica que emplea basada en login y password por el uso del reconocimiento
biométrico. Con la integración de nuestro framework dentro de CAS, hacemos posible
que cualquier aplicación compatible con CAS pueda autenticar a sus usuarios de manera
biométrica.
La Figura 4.2 (izquierda) muestra el Central Authentication Service. Los pasos seguidos
en el protocolo de autenticación original son los siguientes:
1. El usuario solicita un recurso protegido por el Central Authentication Service. Si el
usuario no ha sido autenticado, la petición es dirigida hacia el Central Authentication
Service.
2. El usuario es autenticado por el CAS y como resultado obtiene unas credenciales.
El usuario es redirigido automáticamente de nuevo hacia el recurso web.

4.2. Proyecto de Código Libre BioWebAuth (BWA) 71
Figura 4.2: Central Authentication Service: original (izquierda) y con autenticación biométrica
(derecha).
3. En este segundo intento de acceso al recurso web, el navegador envía automáticamente
la credenciales del usuario.
4. El recurso web valida las credenciales del usuario contra el CAS.
5. El usuario solicita un nuevo recurso web protegido por el CAS. Para el caso en
el que la sesión single sign-on del usuario esté correctamente autenticada, no se
necesitarán ninguna futura autenticación para acceder a otros contenidos protegidos
por el mismo CAS.
6. Idéntico a 4.
La Figura 4.2 (derecha) muestra el Central Authentication Service que incluye nuestro
módulo de autenticación biométrica. A continuación se muestra la adaptación del protocolo
de autenticación para utilizar datos biométricos.
1. Petición inicial.
2. Con el módulo biométrico el proceso de autenticación se divide en las siguientes
etapas:
a) Se lanza la aplicación cliente que captura y envía las muestras biométricas.
b) La autenticación biométrica tiene lugar en el servidor.
c) El CAS comprueba el resultado de la verificación biométrica para entregar las
credenciales al usuario.
3. Petición.
4. Validación.

72
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.3: Captura de la GUI del sistema de autenticación biométrica.
La Figura 4.3 detalla la interfaz gráfica de usuario de la aplicación cliente que usa la
tecnología Java Web Start. En el fondo se puede apreciar la interfaz Web del Biometric
Central Authentication Service que hemos implementado.
4.2.4. Integrando BioAPI en el Entorno Cliente-Servidor de BWA
Como comentamos en [González Agulla, Elisardo y otros, 2007] el servidor de
BWA contiene una instancia del BioAPI Framework sobre una plataforma Linux y permite
utilizar BSPs desarrollados en C/C++ por terceros siempre que sean compatibles con la
especificación 1.2 de la BioAPI. Si el usuario tiene instalada localmente una instancia de
la BioAPI en su máquina cliente (Windows o Linux), el correspondiente BSP local será
controlado por la aplicación cliente de BWA. Sin embargo, dado el carácter multiplataforma
y distribuido de nuestra solución, para la completa integración de cualquier BSP que
sea BioAPI 1.2 compatible en nuestro sistema de autenticación, se requiere la existencia
de las implementaciones de ese BSP tanto para las plataformas Linux como Windows,
para soportar así todas las posibles combinaciones de diferentes sistemas operativos entre
el cliente y el servidor.
Tal y como hemos visto anteriormente, cada BSP implicado en un proceso de enrollment
o de verificación aparece adecuadamente indicado en un documento XML. Este
documento puede verse como una descripción a alto nivel de la interacción entre el usuario
y el sistema, y es transferido desde el servidor por un canal seguro cuando el cliente

4.2. Proyecto de Código Libre BioWebAuth (BWA) 73
comienza una sesión.
En cuanto al procesado de bajo nivel, éste está compuesto por las primitivas Bio-
API_Capture, BioAPI_CreateTemplate, BioAPI_Process y BioAPI_VerifyMatch. En la
configuración más segura, estas primitivas, con la excepción de BioAPI_Capture, son ejecutadas
como llamadas a la implementación del BSP del lado del servidor a través de la
BioAPI.
La primitiva BioAPI_Capture es ejecutada como una llamada a la BioAPI y al BSP
instalado en la máquina cliente, y su resultado es un Biometric Identification Record (BIR)
que es enviado al servidor para su proceso (ver Figura 4.4).
En nuestro caso, la comunicación cliente-servidor se implementa usando un Servicio
Web, como explicaremos en 4.2.6. Todo el proceso es transparente al usuario. El acceso
desde Java a los distintos BSPs instalados en el BioAPI Framework es realizado usando
el proyecto JBioAPI que gestiona las llamadas a código nativo usando la tecnología Java
Native Interface.
Con la llegada del estándar BioAPI 2.0, la definición de una capa adicional por debajo
de los BSPs, llamada Biometric Function Providers (BFPs), permitirá a nuestro Framework
relajar algunas de las condiciones de interoperabilidad anteriormente citadas. Sólo
la correspondiente implementación, sea en Windows o en Linux, del proceso de captura
será necesario en el lado del cliente (Sensor BFPs); y sólo la implementación en Linux de
los BFPs encargados del resto de las tareas serán necesarios en el lado del servidor (archive,
processing-algorithm and matching-algorithm BFPs). Así, el servidor podrá realizar
verificaciones sin obligar al cliente a tener un duplicado del BSP completo, y además, la
algoritmia de cada BSP queda confinada del lado del servidor.
Figura 4.4: Diagrama de bloques del modelo BioAPI en un entorno cliente-servidor.

74
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
4.2.5. Contribuciones al Proyecto de Código Libre JBioAPI
Para poder utilizar adecuadamente el Framework BioAPI en nuestro sistema
hemos necesitado mejorar el proyecto de código libre JBioAPI con varias
contribuciones[González Agulla, Elisardo y otros, 2009c]. Hemos aportado el soporte
necesario para su ejecución en el entorno Windows, hemos permitido el acceso desde
Java a las primitivas de bajo nivel de la BioAPI para favorecer así su uso en arquitecturas
cliente-servidor, y hemos habilitado la invocación de las funciones de identificación.
Para desarrollar el soporte para el S.O. Windows del proyecto JBioAPI hemos usado
el código nativo de la implementación de referencia de la BioAPI 1.1 que está disponible
como un proyecto de Visual Studio 6.0, y la herramienta SWIG (Simplified Wrapper and
Interface Generator)[SWIG Project, WWW] que permite la generación del código Java
Native Interface necesario para realizar las llamadas a los métodos nativos desde Java. El
proyecto JBioAPI, incluyendo estas mejoras, se distribuye bajo la licencia GNU y está
disponible en Internet como proyecto de código libre del que actualmente soy miembro
[JBioAPI Project, WWW].
4.2.6. Conexión Cliente-Servidor de BWA: Web Services y XCBF
El middleware es un software de conectividad que ofrece un conjunto de servicios
que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas.
Soluciones orientadas a objetos como CORBA o Java RMI son ampliamente
aceptadas para invocar métodos residentes en máquinas remotas desde objetos residentes
en la máquina local. Sin embargo, la interoperabilidad se puede ver aumentada si utilizamos
Servicios Web en su lugar. Servicios Web con SOAP (Simple Object Access Protocol)
permiten la interoperabilidad entre clientes heterogéneos (como CORBA pero de un
modo más sencillo) y relaja la restricción de utilizar el mismo lenguaje de programación
tanto en el lado del cliente como en el servidor (Java RMI necesita Java de los dos lados).
El mismo principio de interoperabilidad nos hace emplear el estándar XML Common
Biometric Format (XCBF) para el intercambio de muestras biométricas. El uso de XCBF
y Servicios Web permiten el desarrollo de nuevos clientes totalmente compatibles con
nuestro sistema y que no necesitan estar realizados en Java, simplemente deben cumplir
con la interfaz del servicio web. Esta funcionalidad es adecuada para aquellos terminales
para los que no exista una máquina virtual Java.
Todavía hay otra ventaja en usar Servicios Web en lugar de CORBA o Java RMI. A
menudo los usuarios acceden a Internet a través de LANs protegidas con cortafuegos.
Los cortafuegos filtran y bloquean algún tipo de tráfico por motivos de seguridad. En
este entorno, muchos (casi todos) puertos están típicamente cerrados al tráfico entrante y
saliente, y puede ocurrir que el usuario final no tenga los permisos necesarios para poder
abrir esos puertos. Los Servicios Web, sin embargo, son capaces de utilizar los puertos
usados habitualmente para el tráfico HTTP/HTTPS generado por los navegadores web
(puerto TCP para HTTP es el 80 y para HTTPS el 443). Estos puertos suelen estar siempre
abiertos por lo que no se necesita ningún cambio en la configuración del cortafuegos, y
ésta es una de las ventajas fundamentales detrás del éxito progresivo de los Servicios Web
en el despliegue de aplicaciones remotas.

4.3. Integración de BWA con las Plataformas LMS 75
Como ya hemos comentado anteriormente, desde el mes de Marzo del 2004, existe
un nuevo estándar de seguridad para Servicios Web publicado por OASIS, llamado WS-
Security. Se ocupa de asegurar la integridad y confidencialidad de los mensajes SOAP. De
las múltiples implementaciones existentes hemos escogido WSS4J por ser una implementación
de código abierto desarrollada en Java por la Apache Software Foundation. De este
modo podemos garantizar la integridad de los datos en la comunicación entre el cliente y
el servidor, y podemos autenticar la fuente de los datos biométricos y del resultado de la
verificación, incluso si una capa de transporte segura, por ejemplo una conexión SSL, no
está presente.
4.3. Integración de BWA con las Plataformas LMS
El hecho de que durante la etapa de diseño de BWA hayamos tomado la decisión
de cobijarnos bajo el paraguas del proyecto CAS, hace posible que cualquier aplicación
web preparada para utilizar CAS como mecanismo de autenticación de sus usuarios,
sea también compatible con nuestro sistema sin tener que realizar ninguna modificación
software [Otero Muras y otros, 2007b]. Las plataformas de E-learning ILIAS,
Moodle o Claroline son claros ejemplos de aplicaciones Web que ya son capaces de
delegar el proceso de autenticación en CAS, aunque podemos consultar una lista más
completa en la sección 3.2.1.1. Nosotros las hemos usado en esta Tesis para demostrar
la usabilidad de nuestro sistema biométrico dentro de una aplicación Web corriente.
En [ILIAS with Biometric Authentication, WWW] está disponible un demostrador online
que permite acceder biométricamente a la plataforma LMS ILIAS.
4.4. Análisis de Seguridad y Validación del BioWebAuth
Framework
Dada la naturaleza del servicio que pretende ofrecer BWA es necesario realizar rigurosos
estudios con distintos niveles de abstracción que permitan evaluar las prestaciones
del sistema diseñado y detectar posibles vulnerabilidades con el fin de poder subsanarlas.
Se han realizado diversos trabajos sobre la seguridad existente en la plataforma BWA,
algunos de ellos son referentes al diseño de la arquitectura propuesta, otros pretenden
descubrir vulnerabilidades en el protocolo de autenticación que define BWA, otros intentan
evaluar la robustez de los módulos biométricos implementados, etc. A continuación
mostraremos los más significativos.
4.4.1. Análisis de Seguridad de la Arquitectura de BWA siguiendo la
Taxonomía CERT
En colaboración con la Universidad de Magdeburg se ha definido una metodología
de análisis de la seguridad ofrecida en sistemas de autenticación basados en rasgos biométricos
que están orientados al Web. En el artículo [Zeitz y otros, 2008] se resumen las

76
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
cuestiones de seguridad a tener en cuenta para la integración de la autenticación biométrica
en el entorno Web. Con ese propósito se ha definido una lista de control basada en
el modelo OSI. Siguiendo la taxonomía CERT se han hecho mejoras y modificaciones
de este modelo, añadiendo nuevas capas y expansiones, permitiendo así especificar una
lista de control útil para un análisis más detallado de la seguridad en este tipo de aplicaciones.
Se ha analizado el sistema BWA tanto evaluando sus vulnerabilidades utilizando
la presentada lista de control, como utilizando herramientas de ataque en dos posibles
escenarios (Man-in-the-Middle y Bio-Phishing). El resultado fue el descubrimiento de
algunos puntos débiles en BWA que de ese modo se pudieron corregir. Algunas de las
recomendaciones que componen la lista de control son las siguientes:
La integridad y autenticidad en la aplicación cliente puede conseguirse usando un
certificado digital auténtico emitido por una entidad reconocida.
Se debe evitar por completo el almacenamiento de datos en el entorno cliente.
En lo referente a proteger las muestras biométricas como imágenes o sonidos frente
a posibles manipulaciones, éstas deberían estar etiquetadas por una marca de agua
frágil y oculta que nos permita asegurar la autenticidad y no repudiación de los
datos enviados al servidor.
La confidencialidad en la comunicación debería estar garantizada mediante mecanismos
de encriptación, como por ejemplo usando los protocolos SSL o TLS.
El servidor mismo debe ser protegido por sistemas de prevención y de detección de
intrusiones, y debería estar siempre al día en lo referente a los parches de seguridad.
La configuración de la base de datos debería depender de un usuario que no tenga
privilegios en el sistema.
Por otra parte, para cumplir con los Core Security Requirements del estándar ANSI
X9.84 para Biometric Information Management and Security, deberíamos garantizar también
la seguridad física de las máquinas. Sin embargo, como las máquinas cliente están
en entornos no controlados, esto no es factible. De cualquier modo, algunas acciones se
pueden considerar para proteger al sistema frente a ataques de ingeniería inversa o de manipulación
del software del lado del cliente en entornos no confiables. Uno de los métodos
bien conocidos para asegurar aplicaciones Java es la ofuscación de código. Con técnicas
de ofuscación la tarea de decompilación del código, aunque no imposible, se vuelve más
dificultosa. Nosotros utilizamos una herramienta de código abierto llamada Proguard para
realizar la ofuscación del código.
En el trabajo citado anteriormente no se profundizó demasiado en la capa biométrica,
dejando esa labor para un Proyecto Fin de Carrera (PFC) [Porto Domínguez, 2008] en el
que he colaborado. En este PFC se estudiaron distintos ataques que pueden ser llevados
a cabo contra sistemas de autenticación biométrica en redes distribuidas, desde el punto
más débil del sistema, el usuario no supervisado, hasta el entorno remoto más seguro.

4.5. Desarrollo de Módulos de Reconocimiento Biométrico según la Especificación
BioAPI 77
4.5. Desarrollo de Módulos de Reconocimiento Biométrico
según la Especificación BioAPI
En el transcurso de esta Tesis, además de la definición de la arquitectura de BWA,
se ha colaborado con otros doctorandos de la Universidad de Vigo en el desarrollo de
varios módulos compatibles con el estándar BioAPI 1.2 que ofrecen reconocimiento
biométrico (BWAFaceBSP, BWAVoiceBSP, y BWAMultimodalVoiceAndFaceBSP). Así
mismo, se ha supervisado la realización de otros módulos de reconocimiento biométrico
(firma dinámica y huellas dactilares) como proyectos fin de carrera. Todos ellos se
encuentran disponibles para su descarga desde el proyecto BioWebAuth en SourceForge
[BioWebAuth Project, WWW]. A continuación proporcionaremos una descripción detallada
de cada uno de ellos.
4.5.1. Módulo de Reconocimiento Facial: BWAFaceBSP
A lo largo de esta Tesis se ha colaborado en la implementación de varios BSPs basados
en reconocimiento facial de usuario y que han ido evolucionando proporcionando,
en un principio, solamente verificación biométrica y actualmente, también identificación
biométrica. El resultado de todo este trabajo se recoge en el BWAFaceBSP. El motor de
detección de caras utilizado en este BSP está basado en la aplicación del algoritmo de
Viola-Jones presentado anteriormente y que es utilizado para localizar en el flujo de vídeo
tanto la cara frontal del usuario como sus rasgos faciales más destacados (ojos, nariz y
boca) que son utilizados en el proceso de normalización de la cara detectada. El motor
de reconocimiento de caras está basado en características locales de Gabor multi-escala
y multi-orientación, las cuales han demostrado muy buenos resultados en biometría facial
[Poh y otros, 2009, Pinto y otros, ted ]. Estos filtros están motivados biológicamente,
puesto que se ha observado que su forma es similar a la del campo receptivo de ciertas
células corticales. Además, los filtros de Gabor presentan una óptima resolución tanto en
los dominios frecuencial como espacial [Daugman, 1988]. Un reciente estudio pone de
manifiesto la cantidad de trabajos que han adoptado dichas características para procesado
facial [Shen y Bai, 2006].
El sistema de reconocimiento facial se basa en la extracción de respuestas de Gabor
multiorientación y multiescala (jets) en cada uno de los nodos de una retícula rectangular
10 × 10, habiendo sido la cara previamente normalizada tanto geométrica como fotométricamente.
El valor de similitud s entre dos jets viene dado por el producto normalizado
entre los mismos, siendo el score final entre dos caras la mediana de las 100 similitudes
locales. Dado que trabajamos con secuencias de vídeo, podemos usar varios frames tanto
en enrollment como en test para llevar a cabo el reconocimiento. A continuación se describe
el método empleado en un marco genérico: supongamos que tenemos dos vídeos V 1
y V 2 , donde V 1 es el vídeo de enrollment y V 2 contiene el conjunto de frames de test disponibles
para hacer reconocimiento. La estrategia para comparar V 1 y V 2 es realizar todas las
comparaciones entre frames de V 1 y V 2 dando lugar a la siguiente matriz de similitudes:

78
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.5: Interfaz de captura del Face BSP.
⎛
S = ⎜
⎝
⎞
s 1,1 s 1,2 . . . s 1,Nf2
s 2,1 s 2,2 . . . s 2,Nf2
.
. . ..
⎟ . ⎠
s Nf1 ,1 s Nf1 ,2 . . . s Nf1 ,N f2
(4.1)
donde N f1 y N f2 representan el número de frames procesados en V 1 y V 2 respectivamente.
En la Ecuación (4.1), s i,j representa la similitud entre la i-ésima cara de V 1 y la
j-ésima cara de V 2 . El score final entre V 1 y V 2 se calcula tal y como sigue:
{ }
s = median
i
max {s i,j }
j
(4.2)
Se usa el operador max para intentar disminuir la influencia de los cambios de pose y
expresión que naturalmente pueden ocurrir durante una sesión de test.
Si el lector está interesado en conocer información más detallada sobre la algoritmia
se recomienda la consulta de la siguiente Tesis [González-Jiménez, 2008] y del artículo
[Alba-Castro y otros, 2008].
4.5.2. Módulo de Reconocimiento de Locutor: BWAVoiceBSP
A lo largo de esta Tesis se ha colaborado en la implementación de un BSP que
ofrece verificación e identificación de usuario usando reconocimiento de locutor de-

4.5. Desarrollo de Módulos de Reconocimiento Biométrico según la Especificación
BioAPI 79
nominado BWAVoiceBSP. El reconocedor de locutor en una primera etapa transforma
la voz a un dominio adecuado donde la identidad de los locutores pueda ser diferenciada.
Este proceso se denomina parametrización de voz. Los vectores de parámetros
utilizados por el reconocedor de locutor son 12 Mel Frequency Cepstral Coefficients
(MFCC) [Davis y Mermelstein, 1980], añadiendo además la energía logarítmica. A este
vector se le añaden además sus primeras y segundas diferencias temporales, denominadas
popularmente ∆ y ∆∆, obteniendo finalmente vectores de dimensión 39. En cuanto al
proceso para su obtención, se puede resumir en los siguientes pasos:
1. Preénfasis La señal acústica se filtra linealmente para realzar las altas frecuencias,
que tienen menores energías en señales de voz.
2. Enventanado La señal acústica es dividida en fragmentos de igual longitud según
una ventana Hamming [Nuttall, 1981]. Cada una de estas ventanas se trata a partir
de aquí independientemente.
3. Cálculo de la potencia espectral Se obtiene la Fast Fourier Transform (FFT) de la
señal enventanada, y se calcula la potencia espectral como el cuadrado del módulo
de esta señal transformada.
4. Escalado Mel Se transforma el eje de frecuencia a la escala psicoacústica Mel.
5. Cálculo del Cepstrum Se calcula el logaritmo de la potencia espectral en escala Mel,
y a esta señal se le aplica la transformada de coseno, obteniendo los coeficientes
MFCC.
6. Adición de diferencias y energía
De los vectores así obtenidos, se eliminan los que no correspondan con segmentos de
voz. Para ello se utiliza un detector de actividad de voz.
Una vez la voz está transformada de esta forma, se aplica el paradigma de reconocimiento
GMM-UBM (del inglés Gaussian Mixture Models-Universal Background Model)
[Reynolds y otros, 2000] para realizar el reconocimiento de locutor. En este tipo de
reconocedores de locutor la voz se modela estadísticamente mediante mezclas de gausianas
Λ, cuya expresión matemática se muestra a continuación:
p (x | Λ) =
M∑
i=1
ω Λ,i
exp ( − 1 2 (x − µ Λ,i) t Σ Λ,i −1 (x − µ Λ,i ) )
(2π) N/2 |Σ Λ,i | 1/2 (4.3)
Según este esquema, la verificación de locutor se realiza mediante el siguiente contraste
de hipótesis:
{
H0 : la voz pertenece al locutor u
H 1 : la voz pertenece a algún otro locutor,
donde la hipótesis H 0 está representada por el GMM del usuario u: Λ u ; y la hipótesis
alternativa H 1 está representada por el UBM: Λ UBM . Este contraste de hipótesis permite

80
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.6: Interfaz de captura del Voice BSP.
realizar la verificación de locutor a partir de una secuencia de parámetros de voz X =
[x 1 , . . . , x T ] según la siguiente expresión:
H 0 es aceptada ⇐⇒ s =
T∑
i=1
[ ]
p (xi | Λ u )
log
≥ Θ (4.4)
p (x i | Λ UBM )
El UBM Λ UBM se obtiene a partir de vectores de parámetros de voz provenientes
de múltiples locutores, mediante una inicialización basada en el algoritmo
LBG [Linde y otros, 1980] y el algoritmo esperanza-maximización
(EM) [Dempster y otros, 1977]. El modelo de usuario Λ u se obtiene mediante adaptación
máximo a posteriori (MAP) [Gauvain y Lee, 1994] de los parámetros del UBM a los
vectores de voz provenientes del locutor u en su fase de registro.
Si el lector está interesado en conocer información más detallada sobre la algoritmia
se recomienda la consulta de la siguiente Tesis [Argones Rúa, 2008].
4.5.3. Módulo de Reconocimiento Multimodal basado en Cara y Voz:
BWAMultimodalFaceAndVoiceBSP
Este módulo recoge todo el trabajo realizado en el desarrollo de los BSPs presentados
anteriormente (BWAFaceBSP y BWAVoiceBSP) y aplica técnicas de fusión biométrica

4.5. Desarrollo de Módulos de Reconocimiento Biométrico según la Especificación
BioAPI 81
para conseguir un módulo que realiza verificación e identificación biométrica multimodal.
Las técnicas de fusión implementadas han sido tanto a nivel de decisión: donde se realiza
la fusión lógica usando las funciones booleanas AND y OR; como a nivel de puntuación:
donde se ha implementado el método Q-Rule que tiene en cuenta los valores de FAR, de
FRR, y de calidad de las muestras, en el proceso de fusión biométrica.
Figura 4.7: Interfaz de captura del Multimodal BSP.
4.5.4. Módulo de Reconocimiento de Firma Dinámica: SignatureBSP
Se ha realizado una colaboración con la universidad de Magdeburg que consistió en
el desarrollo de tres BSPs para el sistema operativo Linux. Estos BSPs son capaces de
realizar verificación de usuario usando como rasgo biométrico la firma dinámica. Esta
colaboración se ha realizado por medio de un PFC bajo el programa de becas Erasmus
[Salgueiro Couto, 2008]. En este PFC se toma como punto de partida la aplicación denominada
Biosecure Signature Referente System, basada en la verificación de identidad
usando firma biométrica, y que ha sido desarrollada en el seno de una red de investigación
europea denominada BioSecure. BioSecure fue una red de excelencia europea formada
por diferentes centros de investigación europeos entre los que se encontraba la Universidad
de Vigo. Una vez realizado el desarrollo de los distintos BSPs de reconocimiento de
firmas basados en distintos algoritmos (distancia de Levenshtein, estadístico,...), se procedió
a la evaluación de las prestaciones de los mismos utilizando para ello tanto la base de
datos del primer concurso de verificación de firma dinámica (SVC2004), como la base de
datos recogida en la Universidad de Vigo dentro de la red de excelencia BioSecure (para
más detalles sobre está base de datos se recomienda la lectura del apéndice A.1).

82
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.8: Interfaz de captura del Signature BSP.
4.5.5. Módulo de Reconocimiento de Huella Dactilar: BWAFingerprintBSP
Se han tutorizado dos proyectos fin de carrera
[Aller Freire, 2009][Pereira Suárez, 2009] en los que se han desarrollado de manera
conjunta un proveedor de servicios biométricos según el estándar BioAPI v1.2 capaz
de realizar verificación e identificación de usuario usando huellas dactilares. Se han
realizado implementaciones de este BSP tanto para el sistema operativo Linux como
Windows. Esta solución es compatible con sensores del fabricante DigitalPersona en su
versión Windows, y con un mayor rango de dispositivos de distintos fabricantes en su
versión Linux al apoyarse en la librería FPRINT. Se ha adoptado el estándar ANSI/NIST
ITL 1-2007 tanto para la representación de las huellas capturadas, como para el formato
de las plantillas de los usuarios (minucias). Para la extracción de estas minucias se ha
elegido el algoritmo MINDTCT, y para comparación de plantillas se utiliza el algoritmo
BOZORTH3 (basado en minucias y que es invariante con respecto a la rotación y a
la traslación de las imágenes). Para finalizar diremos que ambos algoritmos han sido
extraídos del proyecto NBIS del NIST.
4.6. Alcance, Difusión y Repercusión de la Plataforma
BWA
En esta sección vamos a reflejar el alcance, la difusión, y la repercusión que ha experimentado
la solución presentada en este capítulo en los últimos años. Por un lado, mostraremos
información sobre las visitas realizadas a la página web de BWA en SourceForge
y sobre el número de descargas del proyecto desde su creación. Por otro lado, mostraremos
información sobre la utilización del demostrador online de BWA que se encuentra
disponible para todo el World Wide Web en la web de nuestro departamento.
Además, debemos comentar la utilización de la arquitectura propuesta en BWA como

4.6. Alcance, Difusión y Repercusión de la Plataforma BWA 83
Figura 4.9: Interfaz de captura del Fingerprint BSP.
base tecnológica en el desarrollo de aplicaciones biométricas en diversos proyectos. Por
una parte, dentro de la Red de Excelencia Europea BioSecure, que se utilizó para la implementación
de una aplicación de captura de muestras biométricas en el ámbito de Internet
(ver sección A.1). Por otra parte, dentro del proyecto IDENTICA, cofinanciado por el
Ministerio de Industria, Turismo y Comercio, dentro del Plan Nacional de Investigación
Científica, Desarrollo e Innovación Tecnológica 2004-2007, que tiene como objetivo dar
respuesta a problemas europeos de identificación de personas.
4.6.1. Estadísticas sobre el Repositorio de BWA en SourceForge
En este apartado presentamos informes estadísticos que reflejan el impacto que
ha experimentado el proyecto de código libre BioWebAuth (Biometrics for Web Authentication)
(BWA) [BioWebAuth Project, WWW] desde su creación. Proyecto que
se encuentra disponible en SourceForge y que cuenta con 32,723 líneas de código
[OhOh Website, WWW]. En la elaboración de estos informes se utilizaron todos los datos
recogidos desde el 01/12/2006 hasta el 05/10/2009 por las herramientas que proporciona
SourceForge sobre los proyectos que aloja. Estos informes muestran datos estadísticos
tanto sobre las visitas al sitio web del proyecto BWA en SourceForge (Figura 4.10), como
de las descargas de la plataforma realizadas por los usuarios (Figura 4.11), y en ellos se
puede apreciar la evolución y acogida de la solución presentada.
4.6.2. Estadísticas sobre el Demostrador Online de BWA
En esta sección se muestran informes estadísticos sobre el uso del demostrador online
de la plataforma BioWebAuth (Biometrics for Web Authentication) (BWA) que se

84
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.10: Accesos Web el Proyecto BioWebAuth de SourceForge.
Figura 4.11: Descargas del Proyecto BioWebAuth desde SourceForge.
encuentra disponible en [BioWebAuth Demonstrator, WWW]. En la elaboración de estos
informes se utilizaron todos los datos recogidos desde el 14/03/2008 hasta el 05/10/2009
por la herramienta Google Analytics. En este apartado haremos un resumen del número
de visitas recibidas y una representación gráfica de su procedencia, pero se recomienda al
lector que consulte la sección A.2 del apéndice donde encontrará una versión extendida y
detallada de estos informes, en la cual se muestran datos estadísticos sobre el uso del sitio
web, la visión general de los usuarios, los navegadores utilizados, la compatibilidad con
Java, la fidelización de los usuarios, la visión general de las fuentes de tráfico, y también
proporcionan gráficos de visitas por ubicación, tanto a nivel de España, como mundial.
A fecha de 05/10/2009 se han registrado en el sistema 386 usuarios, desde su desplie-

4.7. Limitaciones 85
gue el 01/03/2007, que han probado la plataforma. La Figura 4.12 es una representación
gráfica que agrupa en 83 países las 2.424 visitas recibidas desde su despliegue. Concretando
en España, la Figura 4.13 representa gráficamente las 1.250 visitas recibidas por
el Demostrador de BioWebAuth desde 53 ciudades españolas. De estos gráficos podemos
extraer una idea del alcance, la difusión y la repercusión de la Plataforma BWA en el
World Wide Web.
Figura 4.12: Visitas hechas desde diferentes países al demostrador de BioWebAuth.
4.7. Limitaciones
A la hora de valorar la seguridad que ofrece la solución de control de acceso propuesta
en este capítulo, hay que tener en mente el dicho "La seguridad de una cadena es tan
fuerte como el más débil de sus eslabones". De nada sirve diseñar una arquitectura que
garantice la autenticidad, confidencialidad, e integridad de los datos biométricos que se
intercambian en el protocolo de autenticación que tiene definido, si desde un principio
los algoritmos biométricos son fácilmente engañables utilizando grabaciones en reconocimiento
de voz, fotografías en reconocimiento facial, etc. Es por ello que los módulos
biométricos deben implementar técnicas de detección de prueba de vida para fortalecer el
eslabón que constituyen dentro de la solución de autenticación propuesta en este capítulo.
4.8. Conclusiones
Las contribuciones presentadas en este capítulo tienen una naturaleza bien diferenciada.
Por una parte, hemos presentado el desarrollo de múltiples módulos de reconocimiento
biométrico BioAPI-compliant que ofrecen verificación e identificación monomodal (cara,

86
Capítulo 4. Diseño y Desarrollo de un Sistema de Autenticación Biométrica de
Estudiante para Plataformas LMS
Figura 4.13: Visitas hechas desde diferentes ciudades de España al demostrador de Bio-
WebAuth.
voz, huella, firma) y multimodal (cara y voz). Por otra parte, hemos contribuido a la mejora
del proyecto de código libre JBioAPI ofreciendo una solución multiplataforma y
adecuada para el desarrollo de aplicaciones de autenticación distribuida basada en el uso
de rasgos biométricos.
Pero la gran aportación de este capítulo radica en la definición de una arquitectura que
permite el uso de rasgos biométricos en el proceso de autenticación de usuario en el acceso
a plataformas web. Se trata del proyecto de código libre BioWebAuth (Biometrics for Web
Authentication) (BWA) que como hemos visto proporciona un servicio de autenticación
centralizada que va más allá de los básicos mecanismos tradicionales de autenticación
basados en login y password, pues añade el empleo de características biométricas, y que
"bebe"de todas las contribuciones anteriormente citadas.
BWA es una solución abierta gracias principalmente a dos características. Por un lado,
la compatibilidad con cualquier dispositivo biométrico que cumpla el estándar BioAPI
1.2 permite utilizar software biométrico desarrollado por terceros en el proceso de verificación.
Por otro lado, el hecho de que BWA sea compatible con el proyecto Central
Authentication Service (CAS) permite que cualquier aplicación capacitada para delegar
en CAS el proceso de autenticación pueda utilizar la autenticación biométrica de un modo
transparente.
A lo largo de las secciones de este capítulo hemos argumentado que la solución propuesta
es adecuada para el fin que persigue. Esta argumentación se ha realizado presentando
estudios sobre el nivel de seguridad que ofrece la plataforma desarrollada; mostrando
informes que acreditan el alcance, la difusión y la repercusión de la solución presentada;
y demostrando la usabilidad y viabilidad de BWA en el ámbito del aprendizaje electrónico
mostrando una lista de 17 plataformas LMS compatibles, entre las que destacamos a

4.8. Conclusiones 87
ILIAS, Moodle y Claroline.
Para concluir, invitamos al lector a visitar tanto la web del proyecto de código libre
BWA en SourceForge ∗ como el demostrador online † para su evaluación.
∗ http://sourceforge.net/projects/biowebauth/
† https://www.webapps.gts.tsc.uvigo.es/biowebauth_cas/

Capítulo 5
Diseño y Desarrollo de un Sistema de
Monitorización Biométrica de Estudiante
para Plataformas LMS
Contenido
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2. Diseño y Desarrollo del Proyecto BioWebMonitor . . . . . . . . . . 93
5.2.1. Monitorización de Presencia y Atención de Estudiante basada
en la Detección y Verificación Biométrica Facial . . . . . . . . 93
5.2.2. Una Visión Global del Framework BWM . . . . . . . . . . . . 95
5.2.3. Descripción del Módulo de Seguimiento . . . . . . . . . . . . . 96
5.2.4. Sincronización de relojes entre la plataforma LMS y el Framework
BWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3. Integración con LMSs . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno
Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.1. Especificación del Protocolo . . . . . . . . . . . . . . . . . . . 104
5.4.2. Análisis y Validación de Resultados . . . . . . . . . . . . . . . 105
5.4.3. Comparativa Visual . . . . . . . . . . . . . . . . . . . . . . . . 114
5.5. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

90
Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
Estudiante para Plataformas LMS
En este capítulo presentamos la solución que hemos diseñado para poder realizar monitorización
biométrica de estudiante en las plataformas de aprendizaje electrónico. Se
trata del proyecto BioWebMonitor (Biometrics for Web Monitoring) (BWM) que ofrece
un servicio de monitorización del comportamiento del estudiante durante la sesión de
aprendizaje, y que actualmente consiste en la estimación del tiempo real de presencia y
del tiempo real de atención que el estudiante dedica a cada uno de los contenidos de la
plataforma de E-Learning. El sistema encargado de realizar esta monitorización procesa
el flujo de vídeo procedente de la webcam del equipo del alumno, y su estructura modular
permite la adicción de nuevos componentes que enriquezcan este proceso de monitorización.
La aplicación de esta solución en el campo del aprendizaje electrónico permite
extender el uso de las plataformas LMS a ámbitos hasta ahora exclusivos de la formación
presencial, y ofrecer servicios como el de la certificación de horas en cursos virtuales
realizados en base a medidas fiables. Su estructura modular permitirá añadir en el futuro
componentes de reconocimiento de expresión y/o pupilas para estudios más específicos.
La estructura de este capítulo es la siguiente, comenzaremos en la sección 5.1 con
una breve introducción de la problemática que queremos resolver. En la sección 5.2 presentaremos
una visión global de la solución propuesta para la monitorización del comportamiento
del estudiante, describiéndola tanto desde un punto de vista funcional como
estructural. En la sección 5.3 presentaremos las medidas en las que se basa la integración
de BWM con las plataformas de E-learning. Continuaremos con un análisis real de
las prestaciones de la solución propuesta en la sección 5.4. En la sección 5.5 se presentan
algunas limitaciones actuales y líneas futuras de trabajo. Finalmente, la sección 5.6
concluye el capítulo.
5.1. Introducción
En los últimos años el aprendizaje electrónico ha experimentado un gran crecimiento
y una gran difusión que le han permitido asentarse como un medio alternativo al aprendizaje
presencial debido a las numerosas ventajas que ofrece. A lo largo de todo el World
Wide Web se ofertan miles de cursos virtuales, que gracias a las plataformas de E-learning
están al alcance de cualquier estudiante independientemente de su situación geográfica.
Sin embargo, todavía existen algunas carencias en los actuales LMS que impiden proporcionar
adecuados entornos educacionales virtuales que ofrezcan todo el conjunto de
funcionalidad que está disponible en los sistemas de aprendizaje convencional. Una de
esas carencias es la falta de mecanismos que realicen una monitorización fiable del comportamiento
del estudiante a lo largo de la sesión de aprendizaje. Por mecanismos de
monitorización del comportamiento del estudiante nos referimos a herramientas capaces
de ofrecer informes sobre el tiempo real de presencia del estudiante durante la sesión
de aprendizaje, informes sobre el tiempo real de atención que el estudiante dedica a cada
contenido, informes sobre el estado de ánimo del estudiante mientras visualiza un contenido
[Loh y otros, 2005], información sobre el tiempo de lectura dedicado a cada contenido
[Calvi y otros, 2008], etc. La realimientación que supone la información contenida en estos
informes aporta al LMS un gran valor añadido, ya que a partir de ella se puede extraer
un amplio abanico de conclusiones, como por ejemplo: averiguar el tiempo medio que

5.1. Introducción 91
los alumnos necesitan para la realización de un determinado curso (a partir la medida del
tiempo de presencia), inferir el tiempo medio efectivo para la asimilación de un determinado
contenido (a partir de la medida del tiempo de atención), detectar los contenidos
más aburridos para los alumnos (a partir del estado de ánimo durante la visualización del
contenido), detectar los contenidos de mayor complejidad para los alumnos (a partir del
número de lecturas que el estudiante realiza), etc.
En esta Tesis proporcionamos una herramienta capaz de realizar monitorización del
comportamiento del estudiante durante la sesión de aprendizaje, basada en las medidas
del tiempo de presencia (el estudiante está frente al equipo) y del tiempo de atención
(el estudiante está mirando a la pantalla del equipo). Se trata de una solución modular
cuya estructura permite la adición de nuevos componentes que enriquezcan el proceso de
monitorización.
Generalmente, las plataformas de E-learning actuales asumen que el tiempo total que
un estudiante dedica a un determinado contenido de aprendizaje, es el intervalo de tiempo
que transcurre desde que éste lo solicita hasta que solicita el siguiente, o abandona la
sesión. Sin embargo, esta medición no siempre se corresponde con la cifra real, sino que
puede ser un valor muy sobrestimado.
Figura 5.1: Caso de Uso.
Veamos el caso de uso que se muestra en la Figura 5.1 : un estudiante accede usando
una plataforma LMS a una lección que describe un complejo algoritmo matemático.
Mientras lee la explicación detenidamente durante unos minutos, recuerda que debía enviar
un correo electrónico a su tutor, por lo que decide abrir su gestor de correo electrónico
y redactarlo, llevándole esta tarea unos cuantos minutos. Una vez enviado el correo,
el estudiante retoma la explicación del algoritmo, pero dada su complejidad, éste se distrae
mirando por la ventana de su cuarto un par de minutos. Luego, decide tomar un café
con su compañero de piso que acaba de llegar para despejarse un poco. Más tarde y con
las fuerzas renovadas, el estudiante regresa al equipo y continúa estudiando el algoritmo
matemático que por fin comprende. Orgulloso de su logro, procede a estudiar la siguiente
lección. Podemos apreciar en este caso de uso, que el tiempo estimado por la plataforma
LMS usando las herramientas convencionales es mayor que el tiempo real dedicado por
el estudiante a la lección, ya que el criterio convencional no permite detectar algunas de
las situaciones ocurridas, como son el intervalo de tiempo que transcurre en la redacción
y envío del correo, el periodo de distracción mientras el estudiante está mirando por la
ventana, y el tiempo de ausencia mientras se tomaba el café. Supongamos ahora que te-

92
Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
Estudiante para Plataformas LMS
nemos una herramienta software capaz de monitorizar el tiempo de presencia y el tiempo
de atención tal y como los hemos definido anteriormente. Podemos ver en el ejemplo que
el tiempo de presencia del alumno frente al equipo es una cota superior del tiempo de
atención, ya que ambos detectan el tiempo de ausencia del estudiante mientras se toma el
café, pero sólo el segundo es capaz de detectar el periodo de distracción mientras el usuario
está mirando por la ventana. Aun así, la medida del tiempo de atención del estudiante
proporcionada es una cota superior del tiempo de atención que el estudiante dedica a los
contenidos del LMS (tiempo de atención al LMS), ya que el tiempo de atención incluye el
intervalo de tiempo que el estudiante dedicó a la redacción y envío del correo electrónico.
Es importante por tanto poder detectar dentro de los intervalos de tiempo de atención del
alumno cuales se corresponden con la atención prestada a los contenidos de la plataforma
LMS, y cuales con la atención prestada a otras tareas. Para poder realizar esta separación,
cada contenido de la plataforma LMS debe ser capaz de informar al LMS de cuando se
encuentra en primer plano y de cuando es delegado a un segundo plano. De este modo
si combinamos la información del tiempo de atención del estudiante durante la sesión de
aprendizaje, con los intervalos de tiempo en que cada contenido del LMS ha estado en
primer plano podemos proporcionar la medida de tiempo de atención al LMS para cada
contenido de aprendizaje, y utilizar esta medida para ofrecer un servicio de certificación
del tiempo empleado en la realización de un curso virtual.
La situación anteriormente descrita manifiesta las carencias existentes en los actuales
sistemas LMS que limitan su aplicación en aquellos servicios donde el tiempo real empleado
por el estudiante tiene relevancia. Servicios como la certificación profesional de
cursos virtuales, o la realimentación efectiva del tiempo medio que el estudiante dedica a
los contenidos creados, etc.
Resulta obvio el hecho de que no se puede generalizar, para todos los escenarios de
aprendizaje electrónico, la idea de que el tiempo de aprendizaje total de un contenido sea
equivalente al tiempo de atención que se le ha dedicado utilizando el LMS. La solución
propuesta en esta Tesis permite medir el tiempo de atención dedicado a un contenido usando
la plataforma LMS, siendo éste una cota inferior del tiempo de aprendizaje total. Esto
es debido a que en éste último se incluye el tiempo de estudio dedicado a ese contenido
sin utilizar la plataforma LMS. Es decir, el tiempo de aprendizaje total tiene en cuenta
casos como la posible impresión de documentos y su posterior consulta offline, etc. Esta
casuística no invalida la solución presentada en esta Tesis, pero indica que debe tenerse
en cuenta en el proceso de diseño de los contenidos del curso. Es decir, si se pretende
ofrecer un servicio de certificación de horas dedicadas a un curso virtual, la plataforma
LMS debería informar a los alumnos de que el tiempo de estudio offline no es computado,
y tener presente en todo momento que la medida proporcionada por nuestro sistema se
corresponde con una cota inferior del valor real del tiempo de aprendizaje total.
Para finalizar esta introducción, queremos dejar claro que aunque en esta Tesis se presente
de manera conjunta, el proceso de monitorización de estudiante propuesto puede
desacoplarse del proceso de control de acceso si es necesario. Es decir, pueden existir
entornos en los que se realice una monitorización del comportamiento del estudiante en
los términos de tiempos de presencia y de atención presentados anteriormente, pero garantizando
el anonimato del estudiante. Un escenario posible sería un catálogo de cursos
ofrecidos abiertamente donde el sistema LMS sólo esté interesado en conocer los datos

5.2. Diseño y Desarrollo del Proyecto BioWebMonitor 93
estadísticos de utilización de cada curso por parte de los estudiantes, y no la identidad de
los mismos.
5.2. Diseño y Desarrollo del Proyecto BioWebMonitor
BioWebMonitor (Biometrics for Web Monitoring) (BWM) es la evolución de BioWebAuth
(Biometrics for Web Authentication) (BWA) que ofrece, además del servicio de
control de acceso de usuarios utilizando sus rasgos biométricos, un servicio de monitorización
del comportamiento del usuario durante una sesión de navegación Web, almacenando
información relativa a la presencia y a la pose de éste. En la fase de diseño de
BWM se han tenido en cuenta los mismos criterios que durante el diseño de BWA en
términos de funcionalidad, portabilidad, interoperabilidad, aceptabilidad, confiabilidad,
y usabilidad; mostrados en la sección 4.2.1. El sistema que hemos desarrollado basa el
proceso de autenticación del estudiante en la configuración Pull Model [con extracción
de características del lado del servidor] citada en la sección 4.2.1. El diagrama de flujo
funcional de BWM es muy similar al que tiene lugar en BWA y que se muestra en la
sección 4.2.3, con la diferencia de que tras la autenticación exitosa de usuario, en lugar
de cerrarse la aplicación cliente, ésta comienza a realizar el proceso de monitorización
continua del usuario. Durante esta monitorización se van almacenando en el servidor las
trazas de presencia y atención detectadas en cada instante. El sistema sigue basándose en
el proyecto Central Authentication Service (CAS), presentado en la sección 3.2.1, para
ofrecer el servicio de control de acceso a las plataformas web clientes, y oferta, mediante
un servicio web, los métodos que permiten a esas plataformas web cliente recuperar
la información relacionada con los intervalos de presencia y de atención de los usuarios.
De este modo, se pretende que cada plataforma web cliente pueda presentar unos informes
más precisos sobre el comportamiento de sus usuarios, combinando la información
residente en sus registros con la información resultante de la monitorización de comportamiento.
Como ya hemos mencionado, esta información de monitorización resulta útil a
las plataformas de E-learning para la generación de datos estadísticos sobre el uso que los
estudiantes dan a sus contenidos, como por ejemplo: evaluar el número de horas medio
necesarias para la realización de un determinado curso, catalogar la complejidad de los
contenidos en función del tiempo que le han dedicado los alumnos, etc.
5.2.1. Monitorización de Presencia y Atención de Estudiante basada
en la Detección y Verificación Biométrica Facial
Hemos comentado anteriormente que el aprendizaje electrónico se ve limitado en ciertos
ámbitos por la falta de herramientas adecuadas que, por un lado, eviten posibles fraudes
de identidad, y que, por otro, realicen una monitorización efectiva del comportamiento
del estudiante en términos de presencia y de atención. Se ha visto en el capítulo anterior
de esta Tesis que utilizar rasgos biométricos en el proceso de autenticación web de estudiante
es una alternativa válida a los mecanismos tradicionales de login y password en
aquellos sistemas web donde se requiere un alto nivel de seguridad. En esta sección nos
centraremos en las ventajas que proporciona a las plataformas LMS una monitorización

94
Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
Estudiante para Plataformas LMS
efectiva del comportamiento del estudiante.
En el artículo [González Agulla, Elisardo y otros, 2008] concluimos que el nivel de
confianza que se deposita en una plataforma de E-learning se ve incrementado si ésta
aplica reconocimiento facial en los procesos de autenticación y de monitorización del
estudiante. La solución propuesta en este artículo no se presenta como mecanismo para
evitar el fraude durante el proceso de evaluación online, sino que es una medida que
garantiza quien ha sido la persona que ha consultado los contenidos de aprendizaje: el
estudiante o un impostor. Por otra parte, es importante enfatizar el hecho de que aunque
esta solución nos garantice que el estudiante fue la persona que accedió al contenido, no
nos ofrece ninguna garantía de que éste estuviese solo en ese momento.
En el artículo [González Agulla, Elisardo y otros, 2009a] se muestra que la combinación
de la información procedente del módulo de monitorización de comportamiento del
estudiante (intervalos de presencia y de atención), con las trazas almacenadas por el LMS
(interacción entre el alumno y la plataforma de aprendizaje), permite generar unas trazas
detalladas para cada uno de los contenidos de la plataforma LMS, en las que se refleja la
conducta del estudiante de un modo mucho más fiable que los mecanismos tradicionales.
Como ya hemos comentado, a partir de estas trazas detalladas se pueden obtener importantes
datos estadísticos sobre las actividades de los alumnos, como por ejemplo conocer
el tiempo real empleado en la realización de un curso, el tiempo medio de asimilación de
un contenido, tiempo medio empleado en leer un determinado tema, etc.
En el artículo [González Agulla, Elisardo y otros, 2009b] presentamos un sistema
biométrico multimodal aplicado a las tareas de control de acceso y de monitorización
de conducta del estudiante en plataformas LMS. El módulo de control de acceso presentado
está basado en el uso de múltiples rasgos biométricos (cara, voz y huella) con el
fin de seguir ofreciendo buenas prestaciones en entornos no favorables para la verificación
facial. El módulo de medida de presencia de estudiante está principalmente basado
en un detector y un verificador de caras de características similares al presentado en
[González Agulla, Elisardo y otros, 2009a], pero con la incorporación de autenticaciones
cooperativas para evitar largos periodos de tiempo sin información fiable sobre la
identidad de las caras monitorizadas. Una de las mejoras que ofrece este nuevo planteamiento
es que la fiabilidad de los resultados de la monitorización biométrica es reforzada.
Esto se ha conseguido incorporando autenticación cooperativa cuando el sistema es incapaz
de autenticar al usuario monitorizado de manera automática. Una conclusión a remarcar
que se puede extraer de este trabajo es que los factores humanos pueden degradar
significativamente las prestaciones del esquema de autenticación no cooperativa propuesto
en [González Agulla, Elisardo y otros, 2009a]. Esta degradación puede ser debida al
comportamiento especial de algunos usuarios, a las condiciones de iluminación del entorno
desde donde el estudiante accede, etc. Como hemos dicho, el efecto que conseguimos
al incorporar esta autenticación cooperativa, utilizando además otras biometrías, es
la reducción de la influencia de los factores humanos y de las condiciones del entorno que
degradaban las prestaciones del sistema, a costa de una mayor interacción del sistema con
el usuario.
La solución propuesta en esta Tesis está basada en las contribuciones previamente
citadas. Esta solución no pretende evitar todos los tipos de fraude existentes en las plataformas
LMS, ya que no podemos garantizar que el alumno se encuentre realmente solo

5.2. Diseño y Desarrollo del Proyecto BioWebMonitor 95
frente al equipo. Lo que si que podemos garantizar es la presencia de ese alumno. Existen
determinados escenarios en E-Learning donde es relevante, por una parte, conocer si
realmente el estudiante que se encuentra al otro lado es quien dice ser, y por otra parte,
poder medir cuanto tiempo dedica realmente a los contenidos del curso. Escenarios como
el de la certificación de cursos online se ven beneficiados del trabajo presentado en esta
Tesis. Por tanto, la solución propuesta ofrece a la plataforma LMS la posibilidad de conocer
si fue el estudiante quien realizó el curso, y si éste dedicó el número de horas mínimas
necesarias para la consecución del título.
5.2.2. Una Visión Global del Framework BWM
En BWM la parte de control de acceso es análoga a la de BWA, es decir, un documento
XML modela el proceso de autenticación especificando en él la fase de adquisición de
una muestra biométrica, la fase de registro en el sistema, y la fase de verificación (recomendamos
al lector que revise el apartado 4.2.2 del capítulo anterior si tiene alguna duda
al respecto). En esta sección nos vamos a centrar en la descripción de los distintos módulos
que componen la arquitectura de la solución propuesta. Módulos que nos permiten
ofrecer el servicio de monitorización del comportamiento del estudiante durante la sesión
de aprendizaje.
Figura 5.2: Diagrama de Bloques de BioWebMonitor.
En la Figura 5.2 observamos el diagrama de bloques funcionales de BWM que refleja
la arquitectura cliente-servidor de la solución propuesta.
En la parte cliente hay que destacar el módulo de Seguimiento del Estudiante (Student
Tracker), que describiremos en profundidad en la sección 5.2.3. Este módulo encapsula

96
Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
Estudiante para Plataformas LMS
los componentes que realizan la monitorización del comportamiento del estudiante a lo
largo de la sesión de aprendizaje. Para ello, crea un modelo facial del estudiante diferente
para cada sesión a partir de la muestra facial capturada en la fase de control de acceso que
utilizará para verificar la presencia del estudiante. La monitorización realizada se basa en
la aplicación de técnicas de procesado de imagen sobre el flujo de vídeo procedente de
la webcam del equipo. Actualmente, se realiza un seguimiento automático de todos los
usuarios que aparecen en el flujo de vídeo, generando para cada uno de ellos un registro
con los intervalos de tiempo de presencia y de atención detectados. Además, se etiqueta
cada uno de estos intervalos como pertenecientes al estudiante o no en función de los
resultados que devuelva el componente de verificación facial.
Del lado del servidor destacamos el módulo de gestión de Trazas de Sesión del Estudiante
(Student Session Traces) que almacena los intervalos de presencia y atención
utilizados para modelar el comportamiento del estudiante durante la sesión de aprendizaje.
Estas trazas son enviadas desde el cliente por medio de un Servicio Web en formato
de colecciones de intervalos de tiempo. Estos intervalos de tiempo pueden ser divididos
en dos categorías: Intervalos de Tiempo de Presencia (Attendance Time Intervals) e
Intervalos de Tiempo de Atención(Attention Time Intervals).
Como se puede apreciar en la Figura 5.2, esta información se ofrece a la plataforma
LMS mediante un Servicio Web. Es labor de la plataforma de E-learning combinar la
información que reflejan sus propias trazas con estos intervalos de presencia y atención.
5.2.3. Descripción del Módulo de Seguimiento
En esta subsección entraremos en los detalles técnicos del módulo de Seguimiento del
Estudiante que aparece en la Figura 5.2. Su diseño se ha realizado siguiendo las buenas
prácticas de programación presentadas en la sección 3.5, y se ha implementado como una
librería en el lenguaje de programación C++. Su estructura permite fácilmente la adición
de nuevos componentes al estar basada en Dynamic Loading, un mecanismo a través del
cual un programa puede, en tiempo de ejecución, cargar una librería (u otro binario) en
memoria, recuperar la dirección de las variables y funciones que contiene, ejecutar esas
funciones o acceder esas variables, y liberar la librería de la memoria del equipo. Debemos
aclarar aquí que no todos los sistemas operativos soportan Dynamic Loading. Los sistemas
operativos basados en UNIX como Mac OS X, Linux, y Solaris proporcionan Dynamic
Loading con el lenguaje de programación C usando la librería dl. El sistema operativo
Windows proporciona Dynamic Loading mediante el API de Windows.
Actualmente, el módulo de seguimiento proporciona monitorización y verificación
de usuario combinando: algoritmos de detección de caras frontales y de rasgos faciales
(Viola & Jones), algoritmos de flujo óptico para el seguimiento de los rasgos faciales
(Lucas-Kanade), y algoritmos de detección y seguimiento de piel (Cam-Shift), de los que
el lector puede obtener información más detallada en la sección 3.4. Esta librería delega el
proceso de verificación biométrica en un componente propio compatible con el estándar
BioAPI.
A continuación vamos a describir los componentes principales del módulo de Seguimiento
del Estudiante:

5.2. Diseño y Desarrollo del Proyecto BioWebMonitor 97
Figura 5.3: Diagrama de Flujo del módulo de Seguimiento de Estudiante.
Detector de Viola & Jones Este componente procesa una imagen en busca de caras frontales
y rasgos faciales (ojos, nariz y boca). Es posible seleccionar que rasgos faciales

98
Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
Estudiante para Plataformas LMS
se deben detectar, es decir, su API nos permite especificar tanto un modo de funcionamiento
en el que sólo se buscan ojos, como un modo de funcionamiento en el que
también se busca por la nariz y por la boca. Este componente devuelve un array de
elementos, donde cada uno contiene información sobre la localización de los rasgos
activos que han sido detectados en esa imagen.
Detector de Cam-Shift Este componente procesa una imagen con el fin de averiguar la
nueva posición de la cara aplicando detección de piel. Devuelve la nueva posición
de la cara parametrizada como una elipse.
Seguidor de Lucas-Kanade Este componente procesa una imagen con el fin de averiguar
la nueva posición de los rasgos faciales: ojos, nariz y boca aplicando flujo óptico.
Dado que este componente se inicializa a partir de la localización de los rasgos que
devuelve el detector de Viola & Jones, la información de seguimiento que devuelve
el detector de Lucas-Kanade depende de la configuración de rasgos faciales que están
activos en el detector de Viola & Jones. Este componente devuelve información
útil para el proceso de estimación de pose.
Analizador de Calidad Este componente procesa cada cara frontal detectada evaluando
su calidad según criterios de contraste y simetría, con el fin de descartar las caras de
baja calidad y no utilizarlas en el proceso de verificación.
Modulo de Verificación Este componente recibe un vector de caras normalizadas y procede
a realizar una verificación biométrica utilizando el módulo BioAPI compatible
BWAFaceBSP presentado en el capítulo anterior.
La Figura 5.3 representa el diagrama de flujo que realiza el módulo de monitorización
de estudiante que a continuación detallamos.
1. Cada imagen procedente del flujo de vídeo de la webcam es analizada con el fin de
detectar todas las caras frontales que se encuentran en ella. Por cada cara encontrada
se comprueba si ésta se corresponde con un nuevo individuo, o con uno que ya se
estaba siguiendo.
En el caso de un nuevo individuo, se crean dos seguidores: un seguidor de piel
adaptativo, inicializado a partir de la región de la cara frontal detectada, que
se utiliza para la estimación del tiempo de presencia, y otro seguidor de rasgos
faciales, inicializado a partir de las características faciales activas que han sido
detectadas, que se utilizará en la estimación de la pose. A este nuevo individuo
se le asigna una etiqueta de identidad indeterminada.
En el caso de que sea un individuo que ya se estuviera siguiendo, se actualiza
el estado interno de sendos seguidores (piel y rasgos).
2. Lo siguiente que se realiza en el procesado del cuadro de vídeo, es evaluar para
todo individuo todavía no identificado y del que se haya detectado una cara frontal
en la imagen actual, la calidad de la cara frontal aplicando criterios de contraste y
simetría, con el fin de ver si son candidatas válidas para realizar una verificación de
identidad contra el modelo del estudiante.

5.2. Diseño y Desarrollo del Proyecto BioWebMonitor 99
3. Para todos los individuos con caras frontales que alcancen el nivel mínimo de calidad
requerido, se procede a la comparación con el modelo del estudiante. Si el
resultado de la comparación es verdadero, se etiqueta al individuo como estudiante,
en caso contrario, se etiqueta como impostor. Es importante decir que para todo individuo
catalogado como impostor, en los sucesivos cuadros, se continúa realizando
el proceso de verificación contra el modelo del estudiante. Esto es debido a que un
resultado bajo en la comparación con el modelo del estudiante, puede ser causado
por errores de pose o de expresión en la muestra de la cara frontal. Por otra parte,
puede parecer que esta verificación continua de la identidad del estudiante podría
incrementar la FAR, pero hay que recordar que el modelo de usuario que se utiliza
se extrae de la propia sesión, con lo que se puede utilizar un umbral de decisión
bastante restrictivo y así evitar valores de FAR elevados.
Figura 5.4: Salida visual del módulo de monitorización de alumnos en tiempo real en la
que se aprecian las localizaciones devueltas por Viola&Jones, Cam-Shift y Lucas-Kanade.
Las premisas que asumimos en el procesado que realiza este módulo de seguimiento
son:
La ubicación de la webcam en una posición centrada sobre la pantalla nos permite
utilizar la información de pose del usuario referente a la frontalidad como medida de
atención, tal y como se aprecia en la Figura 5.4. Esta premisa se ve respaldada por
el hecho de que a día de hoy tanto los portátiles como los monitores de ordenador
suelen traer incorporado de fábrica una webcam colocada en esa posición.
El bajo tiempo de procesado (

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
100
Estudiante para Plataformas LMS
Por otra parte, la salida del módulo de monitorización son unas trazas que nos indican
los intervalos de tiempo de presencia y de atención de cada individuo detectado. Cada
intervalo de seguimiento se inicia en el instante en que se detecta una cara frontal, y se
finaliza cuando el detector de piel pierde al individuo.
En lo referente a los intervalos de presencia, éstos son catalogados del mismo modo
que las imágenes procesadas por el módulo de seguimiento con las siguientes etiquetas:
identidad indeterminada, impostor y estudiante. Para catalogar un intervalo se aplica una
regla coherente sobre las etiquetas asignadas a los instantes temporales que lo componen.
Si en un mismo intervalo asociado a un individuo hay instantes en los que éste estuvo catalogado
como identidad indeterminada (mientras no se disponga de una cara frontal para
hacer una verificación), luego impostor (la cara frontal seleccionada produjo un resultado
bajo en su comparación con el modelo del estudiante), y finalmente estudiante (verificación
positiva); todo el intervalo pasa a ser catalogado como estudiante. Si el individuo
desaparece antes de conseguir una verificación positiva, el intervalo es catalogado como
impostor si se ha realizado alguna verificación que ha dado ese resultado, o identidad
indeterminada si no se encontró ninguna cara candidata para hacer una verificación frontal.
Los intervalos de tiempo etiquetados como estudiante nos permiten estimar el tiempo
total que el módulo de seguimiento está suficientemente seguro de que la identidad del
individuo monitorizado se corresponde con el estudiante. Es importante aclarar aquí que
los intervalos de tiempo etiquetados como impostor incluyen tanto los intervalos de presencia
de otro estudiante, como los intervalos de presencia del propio estudiante en los
que no se ha podido realizar una verificación positiva de su identidad (debido a problemas
de calidad de las muestras, errores de detección de pose, etc). Esto significa que el valor
de tiempo de detección de presencia de estudiante que ofrece el módulo de sistema debe
verse como una cota inferior del tiempo real.
En lo referente a los intervalos de atención, los hemos definido como los intervalos
de tiempo en los que el estudiante ha estado interactuando con los contenidos del LMS,
ya sea mirando hacia la pantalla, o mirando hacia el teclado. Dada la restricción impuesta
en esta Tesis sobre la ubicación de la webcam, asociamos detección de atención con detección
de pose frontal en la imagen procesada. Actualmente, para la detección de la pose
frontal sólo estamos utilizando la información que devuelve el detector de caras frontales
de Viola & Jones, pero se debería emplear también la información devuelta por el seguidor
de rasgos faciales (Lucas-Kanade) y el detector de piel (Cam-Shift), que también está
siendo almacenada durante la sesión. El criterio que hemos escogido para reducir la influencia
de los fallos de detección del algoritmo de Viola & Jones en la medida del tiempo
de atención, consistió en aplicar una ventana temporal de 1 segundo a todos los intervalos
de pose frontal detectados, de manera que se fusionan todos aquellos cuya distancia
temporal fuese inferior al tamaño de esa ventana. La justificación que nos permite aplicar
este criterio se basa en que la conducta típica de un estudiante, durante una sesión de
aprendizaje, no incluye habitualmente movimientos excesivamente bruscos. Es por ello
que parece coherente asignar la ausencia de cara frontal entre dos intervalos de pose frontal
que distan entre si menos de 1 segundo, a un error del detector, que al comportamiento
brusco del estudiante.
La Figura 5.5 muestra un ejemplo de monitorización de estudiante donde el cuadrado
identifica la detección de la cara frontal y de los ojos, y la elipse identifica la detección de

5.2. Diseño y Desarrollo del Proyecto BioWebMonitor 101
Figura 5.5: Salida visual del módulo de monitorización de alumnos en tiempo real. El
color de los cuadrados y elipses describe el estado de autenticación de la cara detectada.
Verde para estudiantes verificados, rojo para impostores, y naranja para aquellos que
todavía no han sido verificados.
la piel de la cara. El color de los cuadrados y de las elipses determina si el estudiante ya ha
sido verificado satisfactoriamente (verde), sin éxito (rojo), o si el todavía no se ha podido
detectar una cara frontal con calidad suficiente, en términos de simetría y contraste, para
realizar la identificación del estudiante (naranja).
5.2.4. Sincronización de relojes entre la plataforma LMS y el Framework
BWM
En este capítulo presentamos un framework externo al LMS que gestiona el proceso
de monitorización del comportamiento del estudiante mientras visualiza los contenidos de
aprendizaje. Como hemos dicho anteriormente, esta monitorización se basa en la detección
de los intervalos de presencia y de atención que el estudiante dedica a los contenidos.
En este proceso de monitorización se ven envueltos tres actores: la plataforma LMS, el
servidor BWM, y la aplicación cliente de BWM que realiza la monitorización en el equipo
del estudiante. Como la localización de cada uno de estos tres actores se puede corresponder
con un ordenador diferente, es necesario realizar un proceso de sincronización virtual
entre sus relojes. Esta sincronización automática es necesaria para poder asociar de un
modo fiable a un contenido de aprendizaje, el resultado correspondiente de la monitorización
biométrica que se le ha realizado.
Esta tarea de sincronización automática de relojes se incluye en el protocolo de autenticación
de BWM y se realiza de la siguiente manera. Al comienzo de cada sesión de
aprendizaje el LMS delega en el servidor de BWM el proceso de autenticación biométrica
del estudiante. Es en ese momento, cuando el LMS proporciona al servidor BWM
la información necesaria para llevar a cabo la tarea de sincronización. Desde el servidor
de BWM se inicia automáticamente la ejecución de la aplicación cliente de BWM en el
equipo del estudiante utilizando la tecnología Java Web Start. Esta aplicación cliente, que
va a realizar la tarea de autenticación e iniciar el proceso de monitorización de estudiante,
recibe la información de sincronización y ajusta el valor de su reloj interno. Como hemos
mencionado, esta sincronización tiene como fin asegurar que los intervalos de tiempo detectados
por la aplicación cliente de BWM durante la monitorización de estudiante, sean

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
102
Estudiante para Plataformas LMS
coherentes con los instantes temporales de las trazas almacenadas por el LMS durante la
sesión de aprendizaje.
5.3. Integración con LMSs
La integración de la monitorización biométrica del comportamiento del estudiante
en las plataformas LMS es un proceso complejo en el que hay que considerar múltiples
aspectos.
Nivel de Contenidos: Debe crearse una especificación o application profile, probablemente
como una extensión de SCORM, que permita definir como se debe etiquetar
la configuración de monitorización biométrica para cada contenido de un curso virtual.
Esta configuración debe contemplar la habilitación o inhibición de las tareas de
control de acceso biométrico, monitorización de presencia, monitorización de atención,
monitorización de atención efectivo, monitorización del tiempo de lectura,
etc. Así, cada contenido de un curso tendrá asociado una política de monitorización
que será interpretada por el LMS antes de ser entregado al estudiante. Es por
ello que las plataformas LMS deben proporcionar herramientas que permitan editar
la configuración de la monitorización biométrica para cada contenido de un curso,
permitiendo por ejemplo, habilitar la monitorización de atención durante la consulta
de algunas lecciones, y exigir control de acceso biométrico para la realización
de los cuestionarios. La existencia de una especificación que regulase este proceso
permitiría que los cursos para los que ya se haya definido una política de monitorización
biométrica en una plataforma LMS, se puedan ejecutar en otra de manera
transparente.
Nivel de Navegación y Secuenciamiento: Cada plataforma LMS debe ser capaz de interpretar
la configuración de monitorización biométrica asignada a cada contenido
previamente a su visualización, y tomar las medidas oportunas, como por ejemplo:
realizar autenticación biométrica cuando sea requerido, activar la monitorización de
presencia, etc.
Nivel de Seguimiento: Se enriquece el proceso de auditoría de las sesiones de aprendizaje
empleadas en la realización de un curso, mostrando información fiable sobre
el tiempo de atención que el estudiante presta a cada uno de los contenidos del
LMS. Cada LMS debe incorporar a su herramienta de visualización de seguimiento
de estudiante la información de presencia y atención de sus estudiantes que puede
recuperar desde el Servicio Web que ofrece BWM.
En esta sección nos centraremos en el nivel de seguimiento, dejando los otros dos
como posibles líneas futuras de esta Tesis.
Para enriquecer el proceso de auditoría de las sesiones de aprendizaje empleadas en
la realización de un curso, BioWebMonitor ofrece una API mediante Servicios Web que
permite recuperar los intervalos de tiempo de presencia y de atención de un estudiante
almacenados entre dos instantes de tiempo determinados. De este modo, cada LMS
debe mejorar su herramienta de visualización de trazas de estudiante para que combine

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 103
la información que almacena referente a cada contenido de aprendizaje, con la información
disponible en BioWebMonitor en términos de intervalos de tiempo de presencia y de
tiempo de atención, generando lo que hemos definido como tiempo de atención al LMS
dedicado por el alumno a ese contenido.
Los registros de sesión de los actuales LMS se basan principalmente en reflejar la interacción
del usuario con la plataformas de E-Learning, es decir, almacenan información
referente a instantes en los que el estudiante solicita un contenido a la plataforma LMS.
Sin embargo, como ya hemos dicho anteriormente, asumir que el tiempo total que un estudiante
dedica a un determinado contenido de aprendizaje, es el intervalo de tiempo que
transcurre desde que éste lo solicita hasta que solicita el siguiente, o abandona la sesión,
no siempre se corresponde con la cifra real, sino que puede ser un valor muy sobrestimado.
Esto es debido a que con los actuales LMS es difícil detectar, mientras el estudiante
visualiza un contenido de aprendizaje, situaciones como que éste cambie de pestaña del
navegador para consultar la programación televisiva, o abra su gestor de correo electrónico
para consultar su bandeja de entrada, etc. Para resolver la posible sobrestimación del
tiempo dedicado por el estudiante a los contenidos del curso, proponemos la mejora de los
LMS de manera que otorguen a cada recurso de aprendizaje la capacidad de comunicar al
LMS tanto los momentos en que se encuentra en primer plano, como cuando es delegado
a un segundo plano. De este modo, si el estudiante realiza alguna de las acciones anteriormente
citadas, el LMS sería consciente de ellas y podría saber exactamente cuanto tiempo
ha estado cada recurso en primer plano, siendo ese valor una cota superior del tiempo
de atención al LMS para ese recurso. Si combinamos, para un recurso determinado, esta
información de primer plano, con los intervalos de tiempos de presencia y de atención del
estudiante estimados por el módulo de monitorización biométrica mientras visualizaba
ese recurso, obtenemos de un modo fiable el tiempo de atención al LMS dedicado por el
alumno a ese contenido. Si generalizamos para todos los contenidos de un curso virtual, el
LMS podría certificar de un modo fiable el tiempo total de atención al LMS dedicado por
el estudiante a la realización de ese curso. En [González Agulla, Elisardo y otros, 2008]
presentamos una solución que otorga a cada recurso de aprendizaje la capacidad de ser
consciente tanto de los momentos en los que se encuentra en primer plano, como de cuando
es delegado a un segundo plano. La solución presentada consistía en añadir a los contenidos
de la plataforma LMS un código Javascript que, utilizando la tecnología AJAX,
informa al LMS de las situaciones anteriores detectándolas mediante el procesado de los
eventos de foco del navegador.
5.4. Evaluación y Validación del Módulo de Seguimiento
en un Entorno Real
Con el fin de evaluar las prestaciones del módulo de presencia explicado en este capítulo,
hemos llevado a cabo una prueba de campo en un entorno real. La meta de este
estudio era comprobar la precisión de las medidas obtenidas por nuestro módulo de presencia.
En este estudio, veinticinco estudiantes de la asignatura de Procesado de Imagen
de la E.T.S. de Telecomunicaciones de la Universidad de Vigo fueron monitorizados, en
los términos de tiempo de presencia y de atención definidos anteriormente, mientras utili-

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
104
Estudiante para Plataformas LMS
zaban Moodle para realizar varios cuestionarios sobre los contenidos de la asignatura. El
escenario donde se realizó la prueba fue el aula en la que se impartía la asignatura, donde
cada equipo constaba de una cámara web. El resultado de esta prueba de campo fue la
adquisición de veinticinco vídeos en los que se refleja el comportamiento de los alumnos
durante la sesión de aprendizaje.
5.4.1. Especificación del Protocolo
Figura 5.6: Los estudiantes comprueban que sus caras están correctamente enmarcadas
por la webcam colocada sobre el monitor del ordenador.
La prueba realizada por los estudiantes estaba dividida en tres partes: los estudiantes
rellenaban un cuestionario en el equipo en el que se habían registrado biométricamente,
después rellenaban otro cuestionario en otro equipo haciéndose pasar por un impostor, y
finalmente, cada estudiante consultaba la puntuación obtenida en sendos cuestionarios en
el equipo original. A continuación, explicaremos con más detalle el protocolo seguido en
la prueba:
1. El estudiante comprueba que la webcam está correctamente colocada sobre la pantalla
del ordenador (ver Figura 5.6) y que se puede ver a si mismo en el flujo de

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 105
vídeo.
2. Se crea un modelo biométrico del estudiante a partir del flujo de vídeo de la webcam
que será usado por el módulo de verificación facial. El proceso dura unos veinte
segundos y sólo requiere que el alumno mire hacia la cámara.
3. El estudiante realiza el cuestionario compuesto por siete preguntas utilizando para
ello la plataforma de Tele-enseñanza Moodle. La tarea dura unos ocho minutos y
durante este tiempo el estudiante se encuentra en el rol de cliente.
4. El estudiante se cambia al puesto de su izquierda con el fin de hacerse pasar por un
impostor del estudiante que se encontraba en ese puesto previamente.
5. El estudiante realiza en el nuevo puesto el segundo cuestionario. La tarea dura unos
ocho minutos y durante ese tiempo el estudiante se encuentra en el rol de impostor.
6. El estudiante regresa a su equipo y comprueba utilizando Moodle las puntuaciones
obtenidas. Durante este tiempo el estudiante recupera el rol de cliente.
5.4.2. Análisis y Validación de Resultados
Se realizó un etiquetado manual, externo, e independiente de los vídeos de los alumnos
con el fin de evaluar las prestaciones que ofrece la solución de monitorización de
comportamiento propuesta en este capítulo. Por una parte, se etiquetaron los 25 vídeos de
las sesiones de los alumnos en términos de tiempo de presencia y atención, para averiguar
la precisión obtenida en las medidas estimadas por el módulo de monitorización de comportamiento.
Por otra parte, se etiquetaron 12 vídeos de los alumnos en términos de pose
frontal con el fin de analizar la viabilidad de la elección como criterio de estimación del
tiempo de atención del estudiante, la detección del tiempo de pose frontal del alumno.
A continuación mostramos la clasificación de resultados que hemos definido:
Resultados Generales: Tiene como objetivo comprobar si los resultados son coherentes
con el protocolo especificado.
Precisión en la Detección de Presencia: Tiene como objetivo comprobar la precisión en
la medida del tiempo de detección de presencia estimado por el módulo de seguimiento.
Precisión en la Detección de Presencia de Estudiante: Tiene como objetivo comprobar
la precisión en la medida del tiempo de detección de presencia de estudiante
autenticado estimado por el módulo de seguimiento y verificación biométrica.
Criterio para la Medida del Tiempo de Atención: Tiene como objetivo comprobar la
viabilidad de la aplicación del tiempo de pose frontal del alumno como criterio de
estimación del tiempo de atención que dedica a los contenidos.
Precisión en la Detección de Atención: Tiene como objetivo comprobar la precisión en
la medida del tiempo de atención definido como el tiempo de pose frontal estimado
por el módulo de seguimiento.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
106
Estudiante para Plataformas LMS
Precisión en la Detección de Atención de Estudiante: Tiene como objetivo comprobar
la precisión en la medida del tiempo de atención de estudiante autenticado definido
como el tiempo de pose frontal de estudiante autenticado estimado por el módulo
de seguimiento y verificación biométrica.
5.4.2.1. Resultados Generales
Se ha realizado un análisis general de los resultados consistente en el cálculo de los
valores medios y desviaciones típicas de las diferentes medidas que proporciona el módulo
de monitorización para cada uno de los vídeos de estudiante, y de los procedentes
del etiquetado manual de los vídeos. Todo ello con el fin de averiguar si los resultados
reflejan fielmente el protocolo definido en la prueba.
A continuación, se presentan los valores medios y la desviación típica de las medidas
obtenidas por el módulo de monitorización, y que analizaremos más adelante:
Video Total Time (VTT): 0:26:06 es el valor medio de tiempo necesario para realizar
la prueba con una desviación típica de 0:02:15.
Total Session Time (TST): 0:25:48 es el valor medio de tiempo que dura la sesión del
estudiante, es decir, desde que se detecta la primera hasta que se detecta la última
cara en la prueba, con una desviación típica de 0:02:17.
Real Any Presence Time (RAPT): 0:25:23 es el valor medio del tiempo real de
presencia de alguna persona medido tras el etiquetado manual de los vídeos, con
una desviación típica de 0:02:24.
Real Student Presence Time (RSPT): 0:15:15 (60,08 % del RAPT) es el valor medio
del tiempo real de presencia del estudiante medido tras el etiquetado manual de los
vídeos, con una desviación típica de 0:02:03.
Real Any Attention Time (RAAT): 0:21:07 es el valor medio del tiempo real de
atención medido tras el etiquetado manual de los vídeos, con una desviación típica
de 0:01:33.
Real Student Attention Time (RSAT): 0:11:50 (77,60 % del RSPT) es el valor medio
del tiempo real de atención de estudiante medido tras el etiquetado manual de los
vídeos, con una desviación típica de 0:01:15.
Real Any Frontal Pose Time (RAFPT): 0:21:20 es el valor medio del tiempo real
de pose frontal medido tras el etiquetado manual de los vídeos (12/25), con una
desviación típica de 0:01:23.
Real Student Frontal Pose Time (RSFPT): 0:11:55 (78,14 % del RSPT) es el valor
medio del tiempo real de pose frontal de estudiante medido tras el etiquetado
manual de los vídeos (12/25), con una desviación típica de 0:01:25.
Detected Any Presence Time (DAPT): 0:21:02 es el valor medio del tiempo que el
módulo de monitorización ha detectado la presencia de alguna persona, con una
desviación típica de 0:04:31. Esta medida se asocia al tiempo de presencia.

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 107
Detected Student Presence Time (DSPT): 0:10:51 (51,67 % del DAPT) es el valor
medio del tiempo que el módulo de monitorización está seguro que el estudiante
previamente registrado estaba frente a la pantalla, con una desviación típica de
0:04:10. Esta medida se asocia al tiempo de presencia de estudiante
Detected Any Frontal Pose Time (DAFPT): 0:08:44 es el valor medio del tiempo que
el módulo de monitorización ha detectado en una pose frontal, con una desviación
típica 0:05:13. Esta medida se asocia al tiempo de atención.
Detected Student Frontal Pose Time (DSFPT): 0:05:04 (46,70 % del DSPT) es el
valor medio del tiempo que el módulo de monitorización ha detectado al estudiante
en una pose frontal, con una desviación típica de 0:03:44. Esta medida se asocia al
tiempo de atención de estudiante.
Figura 5.7: Herramienta gráfica de visualización de la monitorización biométrica de un estudiante
durante una sesión de aprendizaje. La primera fila muestra los intervalos relacionados
con la detección de presencia. La segunda fila muestras los intervalos relacionados
con la detección de atención.
En lo referente a las medidas de detección de tiempo de presencia y desde el punto
de vista del protocolo especificado para la prueba, a partir del etiquetado manual de los
vídeos observamos que el valor medio del Real Student Presence Time (RSPT) representa
el 60,08 % del valor medio del Real Any Presence Time (RAPT), y difiere en 9 puntos de
la correspondiente medida estimada, pues el valor medio del Detected Student Presence

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
108
Estudiante para Plataformas LMS
Time (DSPT) representa el 51,67 % del Detected Any Presence Time (DAPT). Pese a esta
diferencia, la cifra parece coherente con el protocolo definido en la prueba, ya que en
cada vídeo un estudiante dedica el mismo tiempo que un impostor a la resolución del
cuestionario (8 minutos), lo que implica a priori un valor del DSPT en torno al 50 %. El
valor que aparece a mayores en la medida, se corresponde con la influencia del tiempo que
el estudiante emplea para consultar sus puntuaciones al final de la prueba. En la Figura
5.7 se puede ver gráficamente como los intervalos de presencia son coherentes con el
protocolo de la prueba.
En lo referente a las medidas de detección de tiempo de atención y también desde
el punto de vista del protocolo especificado para la prueba, a partir del etiquetado manual
de los vídeos observamos que el valor medio del Real Student Attention Time (RSAT)
representa el 77,60 % del valor medio del Real Student Presence Time (RSPT), y difiere
en 30 puntos de la correspondiente medida estimada, pues el valor medio del Detected
Student Frontal Pose Time (DSFPT) representa el 46,73 % del Detected Student Presence
Time (DSPT). Es importante destacar que los 30 puntos de diferencia entre la media
del valor real y del estimado, pueden ser debidos a dos motivos: que el tiempo de pose
frontal no modele adecuadamente el tiempo de atención mientras se visualizan los contenidos,
y/o una baja precisión en las medidas que proporciona el detector de pose frontal
implementado. En los siguientes apartados mostraremos que la causa principal es la segunda.
En la Figura 5.7 se puede apreciar como los intervalos de atención, modelados
como detección de pose frontal, muestran indicios de una baja precisión ya que según el
protocolo definido cada estudiante/impostor debería estar, la mayor parte del tiempo del
vídeo, prestando atención a los contenidos de la plataforma LMS, es decir, resolviendo
los cuestionarios. En la Figura 5.7 podemos apreciar visualmente en el caso del impostor
que la medida estimada no refleja correctamente esa conducta ya que la detección de
frontalidad es muy baja.
En los siguientes apartados vamos a evaluar la precisión de las medidas que ofrece el
módulo de seguimiento.

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 109
5.4.2.2. Precisión en la Detección de Presencia
Se ha procedido a realizar un análisis de la precisión que proporciona el módulo de
monitorización en la estima del tiempo de detección de presencia (DAPT). Para ello, se
ha realizado un etiquetado manual sobre el tiempo real de presencia, o RAPT, en los
25 vídeos de las sesiones de los alumnos, y se han comparado estos resultados con los
estimados. Ordenando los valores de la precisión de detección de presencia ( DAP T ) de
RAP T
mayor a menor vemos que para el 48 % de los vídeos el valor de la DAP T es superior
RAP T
al 90 %, como se puede comprobar en la Tabla 5.1. En la Tabla 5.2 observamos que la
mediana de la precisión de detección de presencia ( DAP T ) es 89,29 %, y que para los 12
RAP T
mejores vídeos ( DAP T
DAP T
>90 %), se consigue un valor medio de del 95,81 %, con una
RAP T RAP T
desviación del 1,74 % y un máximo de 97,87 %.
DAP T
RAP T > 90 % > 80 % > 70 % > 60 % < 60 %
Número de vídeos: 12/25 17/25 19/25 23/25 2/25
Procentaje de vídeos: 48 % 68 % 76 % 92 % 8 %
Tabla 5.1: Resumen de la precisión de la medida de detección de presencia en los vídeos
User DAPT RAPT
DAP T
RAP T
2009-05-27_11-07-59_JAG_framerate_14.9_traces.txt 0:23:43 0:24:14 97,87 %
2009-05-25_10-17-46_IG_framerate_26.5_traces.txt 0:21:41 0:22:11 97,75 %
2009-05-27_11-07-07_NGC_framerate_15_traces.txt 0:23:08 0:23:51 97,00 %
2009-05-25_09-53-53_ld_framerate_14.9_traces.txt 0:26:25 0:27:19 96,71 %
2009-05-27_11-06-09_JRP_framerate_14.9_traces.txt 0:22:55 0:23:45 96,49 %
2009-05-25_09-55-15_DVC_framerate_14.9_traces.txt 0:27:23 0:28:26 96,31 %
2009-05-27_11-03-18_LML_framerate_14.9_traces.txt 0:23:30 0:24:25 96,25 %
2009-05-25_10-29-15_n_framerate_15_traces.txt 0:20:29 0:21:21 95,94 %
2009-05-25_09-57-18_A_framerate_14.9_traces.txt 0:26:23 0:27:32 95,82 %
2009-05-25_09-52-34_b_framerate_14.9_traces.txt 0:26:44 0:28:26 94,02 %
2009-05-25_09-49-22_D_framerate_14.9_traces.txt 0:25:25 0:27:14 93,33 %
2009-05-25_10-31-41_y_framerate_15_traces.txt 0:19:21 0:20:59 92,22 %
2009-05-25_10-01-36_d_framerate_15_traces.txt 0:21:57 0:24:35 89,29 %
2009-05-25_09-51-47_G_framerate_15_traces.txt 0:24:13 0:28:16 85,67 %
2009-05-25_10-26-39_h_framerate_26.2_traces.txt 0:18:09 0:22:23 81,09 %
2009-05-25_09-43-32_y_framerate_26.7_traces.txt 0:22:09 0:27:25 80,79 %
2009-05-27_12-53-11_MDFO_framerate_14.9_traces.txt 0:20:02 0:24:48 80,78 %
2009-05-25_09-51-43_UG_framerate_15_traces.txt 0:22:40 0:28:22 79,91 %
2009-05-27_10-54-53_PBO_framerate_25.2_traces.txt 0:18:27 0:24:02 76,77 %
2009-05-27_11-02-30_SRJ_framerate_14.9_traces.txt 0:16:52 0:24:49 67,97 %
2009-05-25_10-51-59_C_framerate_25.6_traces.txt 0:18:59 0:28:08 67,48 %
2009-05-25_11-42-12_mjb_framerate_15_traces.txt 0:19:00 0:28:37 66,39 %
2009-05-27_11-00-41_JLCP_framerate_14.9_traces.txt 0:15:13 0:24:49 61,32 %
2009-05-27_12-02-43_XACF_framerate_25.2_traces.txt 0:11:34 0:24:07 47,96 %
2009-05-27_11-02-55_MPD_framerate_26.3_traces.txt 0:09:24 0:24:32 38,32 %
MEAN: ( DAP T >90 % ; 12/25 videos) 0:23:56 0:24:59 95,81 %
RAP T
STANDARD DEVIATION: 0:02:36 0:02:43 1,74 %
MEAN: ( DAP T >70 % ; 19/25 videos) 0:22:53 0:25:14 90,74 %
RAP T
STANDARD DEVIATION: 0:02:48 0:02:33 7,35 %
MEAN: ( DAP T >0 % ; 25/25 videos) 0:21:02 0:25:23 82,94 %
RAP T
STANDARD DEVIATION: 0:04:31 0:02:24 16,52 %
Tabla 5.2: Precisión en la detección de presencia.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
110
Estudiante para Plataformas LMS
5.4.2.3. Precisión en la Detección de Presencia de Estudiante
Se ha procedido a realizar un análisis de la precisión que proporciona el módulo de
monitorización en la estima del tiempo de detección de presencia de estudiante (DSPT).
Para ello, se ha realizado un etiquetado manual sobre el tiempo real de presencia de estudiante,
o RSPT, en los 25 vídeos de las sesiones de los alumnos, y se han comparado estos
resultados con los estimados. Ordenando los vídeos de mayor a menor según los valores
de DAP T (como en la Tabla 5.2), observamos que para el 52 % de los vídeos se obtiene
RAP T
una precisión de detección de presencia de estudiante ( DSP T ) superior al 80 %, como se
RSP T
puede comprobar en la tabla 5.3. En la Tabla 5.4 observamos que la mediana de DSP T
RSP T es
80,96 %, y que para los 12 mejores vídeos ( DAP T >90 %) se consigue un valor medio de
RAP T
del 87,19 %, con una desviación del 14,63 % y un máximo de 98,71 %.
DSP T
RSP T
DSP T
RSP T >90 % >80 % >70 % >60 % 90 % ; 12/25 videos) 95,81 % 0:12:56 0:14:54 87,19 %
RAP T
STANDARD DEVIATION: 1,74 % 0:02:55 0:02:21 14,63 %
MEAN: ( DAP T >70 % ; 19/25 videos) 90,74 % 0:11:16 0:15:04 75,98 %
RAP T
STANDARD DEVIATION: 7,35 % 0:03:53 0:02:12 25,32 %
MEAN: ( DAP T >0 % ; 25/25 videos) 82,94 % 0:10:51 0:15:15 71,91 %
RAP T
STANDARD DEVIATION: 16,52 % 0:04:10 0:02:03 26,49 %
Tabla 5.4: Precisión en la detección de presencia de estudiante autenticado.

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 111
5.4.2.4. Criterio para la Medida del Tiempo de Atención
En esta Tesis se propone utilizar como criterio de medida del tiempo de atención del
estudiante, el tiempo que éste mantiene una pose frontal frente a la webcam. A priori, parece
coherente asumir que el estudiante está mirando hacia la pantalla cuando se detecta
una pose frontal si se respeta la premisa impuesta en esta Tesis sobre la colocación de la
webcam sobre la pantalla. Para analizar la viabilidad del criterio propuesto, se procedió
al etiquetado manual, en términos de tiempo real de atención y de tiempo real de pose
frontal, de los 12 vídeos con valores de precisión en detección de presencia más elevados.
Recalcamos que en el proceso de etiquetado manual de los vídeos, por una parte, se
contabilizó como tiempo de atención o Real Any Attention Time (RAAT), los intervalos
de tiempo en los que miraban hacia la pantalla del ordenador tanto el estudiante (RSAT)
como el impostor, independientemente de su pose respecto a la webcam, y por otra parte,
se contabilizó como tiempo de pose frontal o Real Any Frontal Pose Time (RAFPT), los
intervalos de tiempo en los que la pose, tanto del estudiante (RSFPT) como del impostor,
era frontal respecto a la webcam, sin tener en cuenta si se miraba hacia la pantalla del
ordenador.
En la Tabla 5.5 observamos que para los 12 mejores vídeos ( DAP T >90 %) los valores
RAP T
de similitud entre la medida real de atención y la medida real de pose frontal son muy elevados
para cada vídeo, tanto en general ( RAF P T ) como particularizando para el estudiante
RAAT
autenticado ( RSF P T ). RSAT
User RAFPT RSFPT RAAT RSAT
RAF P T
RAAT
RSF P T
RSAT
2009-05-27_11-07-59_JAG_framerate_14.9_traces.txt 0:22:22 0:13:31 0:22:40 0:13:21 98,68 % 101,25 %
2009-05-25_10-17-46_IG_framerate_26.5_traces.txt 0:21:11 0:11:13 0:19:07 0:10:54 110,81 % 102,91 %
2009-05-27_11-07-07_NGC_framerate_15_traces.txt 0:20:54 0:12:04 0:20:57 0:11:53 99,76 % 101,54 %
2009-05-25_09-53-53_ld_framerate_14.9_traces.txt 0:21:48 0:11:33 0:22:20 0:12:02 97,61 % 95,98 %
2009-05-27_11-06-09_JRP_framerate_14.9_traces.txt 0:19:21 0:09:41 0:21:19 0:11:46 90,77 % 82,29 %
2009-05-25_09-55-15_DVC_framerate_14.9_traces.txt 0:22:39 0:13:07 0:23:10 0:13:01 97,77 % 100,77 %
2009-05-27_11-03-18_LML_framerate_14.9_traces.txt 0:20:40 0:11:21 0:21:39 0:12:19 95,46 % 92,15 %
2009-05-25_10-29-15_n_framerate_15_traces.txt 0:19:55 0:11:10 0:19:56 0:11:11 99,92 % 99,85 %
2009-05-25_09-57-18_A_framerate_14.9_traces.txt 0:23:52 0:14:36 0:21:32 0:12:24 110,84 % 117,74 %
2009-05-25_09-52-34_b_framerate_14.9_traces.txt 0:22:00 0:12:01 0:22:28 0:12:40 97,92 % 94,87 %
2009-05-25_09-49-22_D_framerate_14.9_traces.txt 0:22:00 0:12:44 0:17:52 0:08:56 123,13 % 142,54 %
2009-05-25_10-31-41_y_framerate_15_traces.txt 0:19:19 0:10:02 0:18:36 0:09:28 103,85 % 105,99 %
MEAN: ( DAP T >90 % ; 12/25 videos) 0:21:20 0:11:55 0:20:58 0:11:40 102,21 % 103,16 %
RAP T
STANDARD DEVIATION: 0:01:23 0:01:25 0:01:43 0:01:21 8,78 % 14,99 %
Tabla 5.5: Similitud entre tiempo de pose frontal y tiempo de atención.
Los valores numéricos de RAF P T y RSF P T , presentados en este apartado y apreciables
RAAT RSAT
en la Tabla 5.5, respaldan la validez del criterio definido en esta Tesis según el cual se
propone la utilización de la estimación del tiempo de pose frontal del estudiante como
medida del tiempo de atención dedicado a cada contenido.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
112
Estudiante para Plataformas LMS
5.4.2.5. Precisión en la Detección de Atención
Se ha procedido a realizar un análisis de la precisión que proporciona el módulo de
monitorización en la estima del tiempo de atención a partir del tiempo de detección de
pose frontal (DAFPT). Para ello, se ha realizado un etiquetado manual sobre el tiempo real
de atención, o RAAT, en los vídeos de las sesiones de los alumnos, y se han comparado
estos resultados con los estimados. Ordenando los valores de la precisión de detección
de atención ( DAF P T ) de mayor a menor vemos que para el 44 % de los vídeos el valor
RAAT
de DAF P T es superior al 40 %, como se puede comprobar en la Tabla 5.6. En la Tabla
RAAT
5.7 observamos que la mediana de DAF P T es 36,13 %, y que para los 12 mejores vídeos
RAAT
( DAP T
DAF P T
>90 %) se consigue un valor medio de del 58,36 %, con una desviación del
RAP T RAAT
21,52 % y un máximo de 83,21 %.
DAF P T
RAAT > 80 % > 60 % > 40 % > 20 % < 20 %
Número de vídeos: 1/25 6/25 11/25 17/25 8/25
Procentaje de vídeos: 4 % 24 % 44 % 68 % 32 %
Tabla 5.6: Resumen de la precisión de la medida de detección de atención en los vídeos
User
DAP T
RAP T DAFPT RAAT
DAF P T
RAAT
2009-05-27_11-07-59_JAG_framerate_14.9_traces.txt 97,87 % 0:12:30 0:22:40 55,15 %
2009-05-25_10-17-46_IG_framerate_26.5_traces.txt 97,75 % 0:11:58 0:19:07 62,60 %
2009-05-27_11-07-07_NGC_framerate_15_traces.txt 97,00 % 0:17:26 0:20:57 83,21 %
2009-05-25_09-53-53_ld_framerate_14.9_traces.txt 96,71 % 0:10:00 0:22:20 44,78 %
2009-05-27_11-06-09_JRP_framerate_14.9_traces.txt 96,49 % 0:12:42 0:21:19 59,58 %
2009-05-25_09-55-15_DVC_framerate_14.9_traces.txt 96,31 % 0:15:29 0:23:10 66,83 %
2009-05-27_11-03-18_LML_framerate_14.9_traces.txt 96,25 % 0:14:48 0:21:39 68,36 %
2009-05-25_10-29-15_n_framerate_15_traces.txt 95,94 % 0:03:40 0:19:56 18,39 %
2009-05-25_09-57-18_A_framerate_14.9_traces.txt 95,82 % 0:15:47 0:21:32 73,30 %
2009-05-25_09-52-34_b_framerate_14.9_traces.txt 94,02 % 0:17:31 0:22:28 77,97 %
2009-05-25_09-49-22_D_framerate_14.9_traces.txt 93,33 % 0:13:00 0:17:52 72,76 %
2009-05-25_10-31-41_y_framerate_15_traces.txt 92,22 % 0:03:14 0:18:36 17,38 %
2009-05-25_10-01-36_d_framerate_15_traces.txt 89,29 % 0:04:40 0:22:33 20,69 %
2009-05-25_09-51-47_G_framerate_15_traces.txt 85,67 % 0:08:54 0:22:04 40,33 %
2009-05-25_10-26-39_h_framerate_26.2_traces.txt 81,09 % 0:06:42 0:21:10 31,65 %
2009-05-25_09-43-32_y_framerate_26.7_traces.txt 80,79 % 0:11:53 0:21:29 55,31 %
2009-05-27_12-53-11_MDFO_framerate_14.9_traces.txt 80,78 % 0:02:15 0:19:40 11,44 %
2009-05-25_09-51-43_UG_framerate_15_traces.txt 79,91 % 0:07:15 0:21:12 34,20 %
2009-05-27_10-54-53_PBO_framerate_25.2_traces.txt 76,77 % 0:06:50 0:20:47 32,88 %
2009-05-27_11-02-30_SRJ_framerate_14.9_traces.txt 67,97 % 0:01:47 0:21:12 8,41 %
2009-05-25_10-51-59_C_framerate_25.6_traces.txt 67,48 % 0:03:48 0:24:46 15,34 %
2009-05-25_11-42-12_mjb_framerate_15_traces.txt 66,39 % 0:06:53 0:19:03 36,13 %
2009-05-27_11-00-41_JLCP_framerate_14.9_traces.txt 61,32 % 0:04:34 0:21:38 21,11 %
2009-05-27_12-02-43_XACF_framerate_25.2_traces.txt 47,96 % 0:01:51 0:20:34 9,00 %
2009-05-27_11-02-55_MPD_framerate_26.3_traces.txt 38,32 % 0:02:50 0:20:11 14,04 %
MEAN: ( DAP T >90 % ; 12/25 videos) 95,81 % 0:12:20 0:20:58 58,36 %
RAP T
STANDARD DEVIATION: 1,74 % 0:04:43 0:01:43 21,52 %
MEAN: ( DAP T >70 % ; 19/25 videos) 90,74 % 0:10:21 0:21:05 48,78 %
RAP T
STANDARD DEVIATION: 7,35 % 0:04:53 0:01:27 22,67 %
MEAN: ( DAP T >0 % ; 25/25 videos) 82,94 % 0:08:44 0:21:07 41,23 %
RAP T
STANDARD DEVIATION: 16,52 % 0:05:13 0:01:33 24,40 %
Tabla 5.7: Precisión en la detección de atención.

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 113
5.4.2.6. Precisión en la Detección de Atención de Estudiante
Se ha procedido a realizar un análisis de la precisión que proporciona el módulo de
monitorización en la estima del tiempo de atención de estudiante (DSFPT). Para ello, se
ha realizado un etiquetado manual sobre el tiempo real de atención de estudiante, o RSAT,
en los vídeos de las sesiones de los alumnos, y se han comparado estos resultados con los
estimados. Ordenando los valores de la precisión de detección de atención de estudiante
( DSF P T
DSF P T
) de mayor a menor vemos que para el 52 % de los vídeos el valor de es
RSAT
RSAT
superior al 40 %, como se puede comprobar en la Tabla 5.8. En la Tabla 5.9 observamos
que la mediana de DSF P T
DAP T
es 44,78 %, y que para los 12 mejores vídeos ( >90 %) se
RSAT
RAP T
consigue un valor medio en la de DSF P T del 62,96 %, con una desviación del 28,14 %, y
RSAT
un máximo de 116,26 %.
DSF P T
RSAT > 80 % > 60 % > 40 % > 20 % < 20 %
Número de vídeos: 3/25 6/25 13/25 17/25 8/25
Procentaje de vídeos: 12 % 24 % 52 % 68 % 32 %
Tabla 5.8: Resumen de la precisión de la medida de detección de atención de estudiante
en los vídeos
Student
DAP T
RAP T DSFPT RSAT
DSF P T
RSAT
2009-05-27_11-07-59_JAG_framerate_14.9_traces.txt 97,87 % 0:10:13 0:13:21 76,53 %
2009-05-25_10-17-46_IG_framerate_26.5_traces.txt 97,75 % 0:10:03 0:10:54 92,20 %
2009-05-27_11-07-07_NGC_framerate_15_traces.txt 97,00 % 0:07:54 0:11:53 66,48 %
2009-05-25_09-53-53_ld_framerate_14.9_traces.txt 96,71 % 0:06:31 0:12:02 54,16 %
2009-05-27_11-06-09_JRP_framerate_14.9_traces.txt 96,49 % 0:05:23 0:11:46 45,75 %
2009-05-25_09-55-15_DVC_framerate_14.9_traces.txt 96,31 % 0:09:30 0:13:01 72,98 %
2009-05-27_11-03-18_LML_framerate_14.9_traces.txt 96,25 % 0:05:41 0:12:19 46,14 %
2009-05-25_10-29-15_n_framerate_15_traces.txt 95,94 % 0:03:06 0:11:11 27,72 %
2009-05-25_09-57-18_A_framerate_14.9_traces.txt 95,82 % 0:14:25 0:12:24 116,26 %
2009-05-25_09-52-34_b_framerate_14.9_traces.txt 94,02 % 0:11:31 0:12:40 90,92 %
2009-05-25_09-49-22_D_framerate_14.9_traces.txt 93,33 % 0:04:00 0:08:56 44,78 %
2009-05-25_10-31-41_y_framerate_15_traces.txt 92,22 % 0:02:03 0:09:28 21,65 %
2009-05-25_10-01-36_d_framerate_15_traces.txt 89,29 % 0:04:13 0:12:32 33,64 %
2009-05-25_09-51-47_G_framerate_15_traces.txt 85,67 % 0:01:17 0:11:45 10,92 %
2009-05-25_10-26-39_h_framerate_26.2_traces.txt 81,09 % 0:05:26 0:11:34 46,97 %
2009-05-25_09-43-32_y_framerate_26.7_traces.txt 80,79 % 0:02:00 0:12:23 16,15 %
2009-05-27_12-53-11_MDFO_framerate_14.9_traces.txt 80,78 % 0:00:56 0:10:47 8,66 %
2009-05-25_09-51-43_UG_framerate_15_traces.txt 79,91 % 0:00:59 0:12:29 7,88 %
2009-05-27_10-54-53_PBO_framerate_25.2_traces.txt 76,77 % 0:05:40 0:10:40 53,13 %
2009-05-27_11-02-30_SRJ_framerate_14.9_traces.txt 67,97 % 0:00:55 0:12:06 7,58 %
2009-05-25_10-51-59_C_framerate_25.6_traces.txt 67,48 % 0:02:53 0:15:17 18,87 %
2009-05-25_11-42-12_mjb_framerate_15_traces.txt 66,39 % 0:05:48 0:11:10 51,94 %
2009-05-27_11-00-41_JLCP_framerate_14.9_traces.txt 61,32 % 0:03:13 0:12:36 25,53 %
2009-05-27_12-02-43_XACF_framerate_25.2_traces.txt 47,96 % 0:01:17 0:11:37 11,05 %
2009-05-27_11-02-55_MPD_framerate_26.3_traces.txt 38,32 % 0:01:51 0:10:54 16,97 %
MEAN: ( DAP T >90 % ; 12/25 videos) 95,81 % 0:07:32 0:11:40 62,96 %
RAP T
STANDARD DEVIATION: 1,74 % 0:03:43 0:01:21 28,14 %
MEAN: ( DAP T >70 % ; 19/25 videos) 90,74 % 0:05:50 0:11:41 49,10 %
RAP T
STANDARD DEVIATION: 7,35 % 0:03:53 0:01:09 30,87 %
MEAN: ( DAP T >0 % ; 25/25 videos) 82,94 % 0:05:04 0:11:50 42,59 %
RAP T
STANDARD DEVIATION: 16,52 % 0:03:44 0:01:15 30,12 %
Tabla 5.9: Precisión en la detección de atención de estudiante.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
114
Estudiante para Plataformas LMS
Analizando detenidamente los valores obtenidos en las prestaciones de la detección
de atención de estudiante, por una parte, llama la atención el valor 116,26 % obtenido
en DSF P T por uno de los estudiantes. Tras realizar un análisis del vídeo correspondiente
RSAT
observamos que la causa es la existencia de intervalos de tiempo en los que el alumno tenía
una pose frontal pero en los que realmente no estaba atendiendo, sino que estaba hablando
con el estudiante que se encontraba a su lado. De hecho, el valor de la precisión de la
estimación de frontalidad ( DSF P T ) para ese estudiante es 98,74 %, tal y como se puede
RSF P T
apreciar en la Tabla 5.10, que refleja que el módulo de detección de pose ha funcionado
correctamente para ese caso.
User DAFPT DSFPT RAFPT RSFPT
DAF P T
RAF P T
DSF P T
RSF P T
2009-05-27_11-07-59_JAG_framerate_14.9_traces.txt 0:12:30 0:10:13 0:22:22 0:13:31 55,89 % 75,59 %
2009-05-25_10-17-46_IG_framerate_26.5_traces.txt 0:11:58 0:10:03 0:21:11 0:11:13 56,49 % 89,60 %
2009-05-27_11-07-07_NGC_framerate_15_traces.txt 0:17:26 0:07:54 0:20:54 0:12:04 83,41 % 65,47 %
2009-05-25_09-53-53_ld_framerate_14.9_traces.txt 0:10:00 0:06:31 0:21:48 0:11:33 45,87 % 56,42 %
2009-05-27_11-06-09_JRP_framerate_14.9_traces.txt 0:12:42 0:05:23 0:19:21 0:09:41 65,63 % 55,59 %
2009-05-25_09-55-15_DVC_framerate_14.9_traces.txt 0:15:29 0:09:30 0:22:39 0:13:07 68,36 % 72,43 %
2009-05-27_11-03-18_LML_framerate_14.9_traces.txt 0:14:48 0:05:41 0:20:40 0:11:21 71,61 % 50,07 %
2009-05-25_10-29-15_n_framerate_15_traces.txt 0:03:40 0:03:06 0:19:55 0:11:10 18,41 % 27,76 %
2009-05-25_09-57-18_A_framerate_14.9_traces.txt 0:15:47 0:14:25 0:23:52 0:14:36 66,13 % 98,74 %
2009-05-25_09-52-34_b_framerate_14.9_traces.txt 0:17:31 0:11:31 0:22:00 0:12:01 79,62 % 95,84 %
2009-05-25_09-49-22_D_framerate_14.9_traces.txt 0:13:00 0:04:00 0:22:00 0:12:44 59,09 % 31,41 %
2009-05-25_10-31-41_y_framerate_15_traces.txt 0:03:14 0:02:03 0:19:19 0:10:02 16,74 % 20,43 %
MEAN: ( DAP T >90 % ; 12/25 videos) 0:12:20 0:07:32 0:21:20 0:11:55 57,27 % 61,61 %
RAP T
STANDARD DEVIATION: 0:04:43 0:03:43 0:01:23 0:01:25 21,21 % 26,30 %
Tabla 5.10: Precisión en la detección de pose frontal.
Por otra parte, observamos que la precisión obtenida en la medida de atención ronda el
60 %, lo que nos indica que es insuficiente utilizar solamente la información que proviene
del detector de caras frontales para la estimación de pose frontal del alumno. Es por ello
que parece razonable combinar esta información con la disponible del seguidor de rasgos
faciales (ojos, nariz y boca), y el seguidor de piel. De esta manera podemos estimar la pose
del estudiante a partir de la distancia relativa entre los distintos rasgos faciales seguidos y
su localización dentro de la cara estimada por el detector de piel. Esta solución mejoraría
la precisión del sistema puesto que permitiría detectar los intervalos de tiempo en los que
el usuario está mirando al teclado que también forman parte del tiempo de atención.
Los resultados obtenidos no invalidan el criterio de asociación entre atención y frontalidad,
sino que muestran que es necesario fortalecer el proceso de modelado de pose
del estudiante implementado actualmente, y tener una calibración automática o semiautomática
para prefijar la relación entre pose real de atención a pantalla y frontalidad.
5.4.3. Comparativa Visual
En este apartado se ha realizado una comparación visual entre varias imágenes procedentes
de los 7 vídeos que han obtenido los mejores resultados de monitorización en
términos de presencia (Figura 5.8), y varias imágenes procedentes de los 6 vídeos que han
obtenido los peores resultados (Figura 5.9). La Figura 5.8 muestra capturas de los vídeos
con los mejores resultados de monitorización ( DAP T >96 %) ordenados por filas según
RAP T

5.4. Evaluación y Validación del Módulo de Seguimiento en un Entorno Real 115
el criterio de mejor (arriba) a peor (abajo). En cambio, la Figura 5.9 muestra capturas de
los vídeos con los peores resultados de monitorización ( DAP T 96 %.
Realizando una comparativa visual observamos la existencia de factores que causan
una degradación importante en las prestaciones del sistema de monitorización. Estos factores
son:
Ubicación incorrecta de la webcam durante la sesión: Esto provoca que las caras de
los estudiantes no se encuentren encuadradas dentro del flujo de vídeo de la webcam,
influyendo negativamente en las estimaciones de los tiempos de presencia y de
atención. La influencia de este factor se aprecia claramente en la diferencia de encuadre
de la cara en las imágenes de la primera fila de la Figura 5.8 y de la primera
fila de la Figura 5.9.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
116
Estudiante para Plataformas LMS
Figura 5.9: Imágenes extraídas de los 6 vídeos que obtuvieron DAP T
RAP T

5.5. Limitaciones 117
esta mejora, se evitarían los casos que provocan que decaigan las prestaciones del sistema,
mostradas en el apartado 5.4.2.1. Es decir, estos 6 peores vídeos tienen una gran influencia
negativa en el hecho de que la distancia entre el valor medio del Detected Student Presence
Time (DSPT) difiera en 9 puntos del valor medio del Real Student Presence Time (RSPT),
y que el valor medio del Detected Student Frontal Pose Time (DSFPT) difiera en 30 puntos
del valor medio del Detected Student Presence Time (DSPT).
Por otra parte, los factores más influyentes en degradación de la precisión obtenida en
la medida de detección de atención, tal y como se ha modelado en esta Tesis, son los
siguientes. Por un lado, las oclusiones de la cara hacen que se degraden las prestaciones
en la estimación del tiempo de pose frontal, debido al comportamiento poco robusto del
detector de Viola & Jones en el proceso de detección de caras frontales cuando existen
oclusiones. Por otro lado, la posición de la webcam es crítica para la detección de los
intervalos de tiempo en que el estudiante está mirando el teclado, si la posición de la
webcam es adecuada el detector de caras frontales de Viola & Jones nos permite detectar
como caras frontales esos instantes gracias al margen en pose que ofrece el detector. Estos
factores nos indican que parece necesario incorporar en el proceso de modelado de pose
de estudiante, la información de seguimiento que procede de los seguidores de piel y de
rasgos biométricos, para reducir su influencia.
5.5. Limitaciones
En esta sección presentamos algunas de las limitaciones existentes en el sistema presentado.
Actualmente, para el proceso de estimación de pose del estudiante sólo se está utilizando
la información del detector de caras frontales. La incorporación en este
proceso de las medidas que proporciona el seguidor de rasgos faciales (ojos, nariz
y boca) mejoraría la precisión en esta estimación. El proceso de fusión de estas dos
informaciones se podría realizar de la siguiente manera: a lo largo de una sesión de
aprendizaje, el detector de caras frontales nos marca instantes temporales donde la
cara del usuario tiene una pose frontal. Podemos analizar para esos instantes la relación
existente entre las posiciones relativa de los rasgos faciales que nos devuelve
el seguidor de rasgos faciales, y generar criterios de frontalidad en base a esa información.
Después, aplicaríamos al resto de los instantes de la sesión esos mismos
criterios etiquetando como instantes frontales aquellos en los que se cumplan.
La precisión en la detección de tiempo de presencia y de atención de la solución
implementada depende en gran medida de la correcta ubicación de la cámara web
con respecto al centro-superior de la pantalla. Para ofrecer una solución que no
imponga ninguna restricción sobre la ubicación de la webcam, debe remplazarse el
algoritmo actual de estimación de pose por otro que proporcione un mayor grado
de libertad, como por ejemplo Active Appearance Models (AAM).
Es necesaria la adición de nuevos módulos que enriquezcan el proceso de monitorización,
incorporando funcionalidad como la detección de estado de ánimo del
alumno, la detección del tiempo de lectura dedicado a cada contenidos, etc.

Capítulo 5. Diseño y Desarrollo de un Sistema de Monitorización Biométrica de
118
Estudiante para Plataformas LMS
Es necesario incorporar una solución software que medie con el estudiante si se
detecta la ausencia de éste para que tome las medidas oportunas.
5.6. Conclusiones
En este capítulo se ha presentado una solución software que ofrece a los sistemas
LMS un servicio de monitorización del comportamiento del estudiante durante la sesión
de aprendizaje. Esta monitorización se realiza actualmente en términos de tiempo real
de presencia y de tiempo real de atención que el estudiante dedica a cada uno de los
contenidos de la plataforma de E-Learning, aunque ya hemos comentado que el módulo
de seguimiento permite la adición de nuevos componentes que enriquezcan el proceso
de monitorización. Se ha presentado una descripción detallada de la estructura y de los
componentes del módulo de seguimiento biométrico. La solución propuesta ha sido validada
presentando los resultados obtenidos tras su aplicación en una prueba de campo. La
prueba consistió en la monitorización biométrica del comportamiento de 25 estudiantes
mientras realizaban varios cuestionarios sobre los contenidos de una asignatura usando
Moodle para ello.
En un análisis general de los resultados presentados observamos que los valores obtenidos
en las medidas de tiempo de presencia y de tiempo de presencia de estudiante,
eran coherentes con el el protocolo especificado en la prueba, no ocurriendo lo mismo
con la estimación del tiempo de atención y de tiempo de atención de estudiante donde los
valores estimados eran pesimistas respecto a los datos reales.
En un análisis más minucioso sobre la precisión de las medidas que proporciona el
módulo de monitorización de comportamiento, los valores de la estimación del de tiempo
de presencia, tanto del estudiante como en general, reflejan la viabilidad de la aplicación
de este tipo de monitorización en el entorno propuesto. Además, el análisis objetivo del
comportamiento del alumno durante la prueba de campo, en términos de atención y de
pose respecto a la cámara, nos ha permitido validar que el tiempo de pose frontal se
puede utilizar como criterio de estimación del tiempo de atención. La precisión obtenida
utilizando ese criterio indica que es necesario incorporar algunas mejoras al componente
de estimación de pose frontal que permitan aumentar las prestaciones obtenidas en este
tipo de monitorización.
En un análisis sobre las principales causas de degradación de las prestaciones del
sistema (oclusiones, iluminación, etc), concluimos que es la incorrecta ubicación de la
webcam la que ocasiona una mayor influencia negativa en las prestaciones del sistema.
Esta influencia ha sido corroborada con un análisis visual entre imágenes procedentes de
los vídeos que obtuvieron mejor y peor precisión.
Terminamos la exposición de este capítulo indicando las limitaciones actuales de la
solución propuesta junto con algunas líneas futuras que permitirían mejorar las prestaciones
ofrecidas por el módulo de seguimiento, especialmente en la estimación de tiempo
atención.
Finalmente, basándonos en lo anteriormente expuesto, podemos concluir que la aplicación
de técnicas biométricas en el escenario del aprendizaje electrónico es viable y aporta
un gran valor añadido a las plataformas LMS. Son numerosas las ventajas que ofrece el

5.6. Conclusiones 119
hecho de que el LMS esté seguro de la identidad del estudiante y tenga una medida fiable
del tiempo de presencia y atención que éste dedica a sus contenidos. Entre ellas, destacamos
la posibilidad de ofrecer tanto un servicio de Certificación de Horas en Cursos
Virtuales más fiable que los que actualmente existen, como un servicio de Estimación Automática
de la Carga de Trabajo en Cursos Virtuales de gran utilidad en el ámbito ECTS.
Además, la información de monitorización del comportamiento del estudiante supone una
fuente de realimentación que permite al LMS extraer información relevante sobre la complejidad
de algunos temas, dimensionar la carga de trabajo asociada a cada contenido de
un curso, etc.

Capítulo 6
Contribuciones, Conclusiones y Trabajos
Futuros
Contenido
6.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.1.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . 122
6.1.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . 123
6.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.2.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . 124
6.2.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . 124
6.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . . 125
6.3.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS . . . . . . . . . . . . 125
En este capítulo se resumen las contribuciones más importantes aportadas en esta
Tesis, se describen las principales conclusiones que se han extraído tras la realización de
los diferentes trabajos en ella presentados, y se enumeran posibles líneas futuras para la
mejora de las soluciones propuestas.

122 Capítulo 6. Contribuciones, Conclusiones y Trabajos Futuros
6.1. Contribuciones
En esta sección se agrupan las principales contribuciones que respaldan la validez de
las soluciones propuestas para cada una de las distintas problemáticas planteadas en esta
Tesis: control de acceso y monitorización de comportamiento.
6.1.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS
Hemos presentado de manera detallada tanto el diseño como la implementación del
proyecto de código libre BioWebAuth (Biometrics for Web Authentication) (BWA) alojado
en SourceForge ∗ . BWA ofrece autenticación de usuario empleando rasgos biométricos
dentro del entorno web, y el lector interesado puede probar su demostrador online † . En su
diseño, hemos abordado cuestiones relacionadas con la interoperabilidad en software biométrico,
y con la seguridad para aplicaciones distribuidas sobre redes abiertas, haciendo
especial incapié en el uso de estándares como BioAPI, Web Services y X9.84. Varios proyectos
de código abierto, como CAS y JBioAPI, han sido cuidadosamente integrados en
nuestro marco de trabajo añadiendo flexibilidad, portabilidad, e interoperabilidad a la solución
presentada. Se ha validado la efectividad de BWA como mecanismo de control de
acceso con múltiples aplicaciones Web, tales como las plataformas de E-Learning ILIAS,
Moodle y Claroline.
Asimismo, hemos presentado el desarrollo de varios módulos de verificación biométrica
monomodales (cara, voz, huella y firma) y uno multimodal (cara y voz) que pueden
ser utilizados desde BWA, o por cualquier aplicación que permita la gestión de Biometric
Service Provider (BSP) realizados bajo el estándar BioAPI.
La validez de la solución propuesta en esta parte de la Tesis está avalada tanto por los
siguientes artículos publicados en revista: [González Agulla, Elisardo y otros, 2009c]
publicado en la revista Computer Standards & Interfaces, [Otero Muras y otros, 2007a]
publicado en la revista Annals of Telecommunications, y [Alba-Castro y otros, 2008]
publicado en la revista Journal of Electronic Imaging; como por las siguientes publicaciones
presentadas en congreso: [González Agulla, Elisardo y otros, 2004b]
presentado en el congreso COST275, [Argones Rúa y otros, 2004] presentado
en el congreso ODYSSEY, [González Agulla, Elisardo y otros, 2004a] presentado
en el congreso KES, [González Agulla, Elisardo y otros, 2005] presentado
en el congreso UCAmI, [Otero Muras y otros, 2007b] presentado en el congreso
SWB, [González Agulla, Elisardo y otros, 2007] presentado en el congreso KES,
y [Zeitz y otros, 2008] presentado en el congreso Security, Forensics, Steganography, and
Watermarking of Multimedia Contents X.
∗ http://sourceforge.net/projects/biowebauth/
† https://www.webapps.gts.tsc.uvigo.es/biowebauth_cas/

6.2. Conclusiones 123
6.1.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS
Se ha presentado el Framework BioWebMonitor (Biometrics for Web Monitoring)
(BWM) que ofrece a las plataformas LMS un sistema de monitorización del comportamiento
del estudiante durante la sesión de aprendizaje, basado en el seguimiento de rasgos
biométricos. Actualmente, se monitoriza el comportamiento del estudiante en términos de
tiempo de presencia y de atención, pero la estructura del módulo de seguimiento permite
incorporar fácilmente nuevos componentes que ofrezcan otro tipo de medidas, como por
ejemplo, la estimación del tiempo de lectura dedicado a cada contenido, o información
relevante al estado de ánimo del estudiante. Todo ello, con el fin de obtener unos registros
que reflejen fielmente el comportamiento del estudiante durante la sesión de aprendizaje.
Se ha realizado una evaluación de la solución propuesta mediante una prueba de campo
en la que 25 estudiantes de la asignatura de Procesado de Imagen de la E.T.S.E.T de
Vigo eran monitorizados mientras rellenaban dos cuestionarios utilizando para ello un conocido
LMS (Moodle). Se llevó a cabo un etiquetado manual de los vídeos de los alumnos,
en términos de tiempo de presencia, de atención y de pose frontal, tanto para el estudiante
como para el impostor, con dos fines: validar el uso del tiempo de pose frontal como
criterio para estimar el tiempo de atención, y calcular la precisión en las estimaciones del
tiempo de presencia y del tiempo de atención del alumno que proporciona el módulo de
seguimiento implementado.
La validez de la solución propuesta en esta parte de la Tesis está apoyada
por los artículos [González Agulla, Elisardo y otros, 2008] presentado en el ICALT,
[González Agulla, Elisardo y otros, 2009a] presentado en el EEET obteniendo el Best-
Session Paper Award, y [González Agulla, Elisardo y otros, 2009b] aceptado en el ISM.
6.2. Conclusiones
La principal conclusión que se extrae del trabajo presentado en esta Tesis se resume
en que la aplicación de técnicas biométricas dentro el ámbito del Aprendizaje Electrónico,
para la mejora de los mecanismos de control de acceso y de monitorización del
comportamiento del estudiante, es viable y aporta un gran valor añadido a las plataformas
de E-learning. El hecho de que una plataforma LMS pueda, por una parte, asegurar que
el estudiante que ha accedido a un contenido sea quien dice ser, y no un impostor que
usurpa su identidad (control de acceso), y por otra parte, ofrezca la posibilidad de conocer
de manera fiable cuanto tiempo ha dedicado éste a cada contenido (monitorización de
comportamiento en términos de tiempo de presencia y de atención), permite mirar hacia
nuevos horizontes en la aplicación de las plataformas de E-learning. Entre estos nuevos
horizontes destacamos, por un lado, la aplicación de los sistemas LMS en escenarios hasta
ahora exclusivos del Aprendizaje Presencial, ya que con la solución presentada es viable
ofrecer un servicio fiable de certificación de horas dedicadas a un curso virtual; y por otro
lado, la aplicación de los sistemas LMS dentro del ámbito ECTS, ya que se proporciona
una estimación fiable de la carga horaria, en términos de presencia y atención, que los
estudiantes dedican a los contenidos de cada curso.

124 Capítulo 6. Contribuciones, Conclusiones y Trabajos Futuros
A continuación presentamos las conclusiones específicas que se extraen de cada una
de las dos partes presentadas en esta Tesis: control de acceso, y monitorización de comportamiento.
6.2.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS
En esta parte de la Tesis concluimos que el proyecto BioWebAuth (Biometrics for Web
Authentication) (BWA) incrementa el nivel de seguridad ofrecido durante el acceso a plataformas
Web, particularizando en el caso de LMS, al aplicar con éxito el reconocimiento
biométrico en el proceso de autenticación de estudiante. Asimismo, concluimos que en
el diseño de cualquier solución software se debe realizar un estudio riguroso sobre los
distintos estándares existentes en el ámbito de trabajo, ya que su adopción generalmente
aumenta la interoperabilidad de la solución propuesta. En este caso, por una parte, el hecho
de que BWA sea compatible con Central Authentication Service (CAS) permite que
numerosas plataformas Web se vean beneficiadas, de manera transparente, del servicio
ofrecido por BWA, tal y como se mostró en la sección 3.2.1.1. Por otra parte, la adopción
del estándar BioAPI permite incorporar a BWA, también de manera transparente, módulos
biométricos desarrollados por terceros.
6.2.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS
En esta parte de la Tesis se presentó el Framework BioWebMonitor (Biometrics for
Web Monitoring) (BWM) y se realizó una prueba de campo con el fin de evaluar las
prestaciones que ofrece en un entorno real el módulo de seguimiento desarrollado.
De los distintos análisis realizados sobre los resultados obtenidos extraemos varias
conclusiones:
Por una parte, realizando una comparativa visual entre los vídeos de los alumnos,
escogiendo como criterio la precisión en las estimaciones, observamos que entre los distintos
factores que podrían reducir la precisión en las medidas estimadas por el sistema
(oclusiones en la cara, condiciones de iluminación, posición errónea de la webcam, etc.),
la influencia negativa más importante se corresponde principalmente con una incorrecta
ubicación de la webcam. Recordemos que en la solución implementada, la localización
correcta de la webcam en una posición centrada sobre la pantalla, nos permite utilizar
la información de pose del usuario referente a la frontalidad, como medida de atención.
Concluimos, por tanto, que es necesario incorporar tanto una mejora software que realice
una calibración inicial de la posición de la webcam para asegurar una correcta posición
de la misma desde el principio de la sesión de aprendizaje, como añadir otra mejora que
interactúe con el estudiante durante la sesión si detecta situaciones que, de producirse de
manera prolongada, implicarían un decaimiento de las prestaciones del sistema (casos como
que el estudiante cambie de posición y deje de estar encuadrado dentro del flujo de
vídeo).

6.3. Trabajos Futuros 125
Por otra parte, teniendo en cuenta las medidas citadas que reducen la influencia negativa
en las prestaciones del sistema de una posición incorrecta de la webcam, la precisión
obtenida por el módulo de seguimiento en la estimación de las medidas de tiempo de
presencia, tiempo de atención, tiempo de presencia de estudiante, y tiempo de atención
de estudiante (consultar los valores obtenidos para los vídeos con DAP T > 90 % en la
RAP T
sección 5.4), nos permite concluir que la aplicación de técnicas biométricas en el escenario
del aprendizaje electrónico es viable y aporta un gran valor añadido a las plataformas
LMS, permitiendo ofrecer servicios hasta ahora exclusivos del aprendizaje presencial, como
por ejemplo cursos en los que se requiera la certificación de las horas dedicadas, o
proporcionando un mecanismo fiable para la estimación automática de la carga de trabajo
en cursos on-line, siendo de gran utilidad en el ámbito ECTS, ya que los créditos ECTS
hacen referencia al tiempo que tiene que dedicar el alumno a una materia para poder
asimilar sus contenidos.
6.3. Trabajos Futuros
A lo largo de esta Tesis hemos analizado la problemática existente en la aplicación de
la Biometría dentro del ámbito del E-learning, con el fin de mejorar el nivel de seguridad
ofrecido en la tarea de control de acceso, y de proporcionar un mecanismo fiable para monitorizar
el comportamiento del alumno durante la sesión de aprendizaje. Las soluciones
presentadas en esta Tesis pueden verse como los primeros pasos recorridos sobre un largo
camino que todavía queda por andar. En esta sección recogemos las principales líneas
futuras de investigación que quedan abiertas.
6.3.1. Diseño y Desarrollo de un Sistema de Autenticación Biométrica
de Estudiante para Plataformas LMS
Debido al eslabón débil que constituye cada Biometric Service Provider (BSP) dentro
de la cadena de seguridad de la solución propuesta en BioWebAuth (Biometrics for
Web Authentication) (BWA), es necesario incorporar técnicas que eviten el fraude por reply
attack, implementar medidas de aliveness detection, y añadir mecanismos de cifrado
que garanticen la integridad y confidencialidad de los datos biométricos que manejan los
distintos módulos de verificación biométrica presentados en la sección 4.5.
Otro posible trabajo a corto plazo siguiendo esta línea consistiría en minimizar la interacción
del estudiante con el sistema biométrico propuesto, para ofrecer así una solución
más amigable. Esto se haría automatizando algunos de los pasos que actualmente existen
en el protocolo de autenticación que implementa BWA.
6.3.2. Diseño y Desarrollo de un Sistema de Monitorización Biométrica
de Estudiante para Plataformas LMS
En cuanto a la parte de monitorización de comportamiento son varias las posibles
líneas a seguir para la mejora de las prestaciones de la solución propuesta.

126 Capítulo 6. Contribuciones, Conclusiones y Trabajos Futuros
A corto plazo, tenemos previsto la mejora del proceso de estimación de pose del estudiante,
que actualmente sólo tiene en cuenta la información que proporciona el detector
de caras frontales, incorporándole la información que proporcionan tanto el seguidor de
rasgos faciales como el detector de piel. La Figura 6.1 ilustra gráficamente la mejora que
se consigue al utilizar la información que proviene del seguidor de rasgos faciales. En
la Figura 6.1 se muestran algunos instantes en los que el detector de caras frontales ha
detectado una cara frontal, para ese mismo instante, los seguidores de rasgos faciales nos
devuelven las coordenadas de los ojos, nariz y boca. Se puede establecer un criterio a
partir de los ángulos que forman estos puntos en los instantes de pose frontal, y etiquetar
también como frontales aquellos instantes en los que los rasgos faciales guarden la misma
relación, pese a que el detector de caras frontales no haya detectado en ese instante una
cara frontal.
Figura 6.1: Estimación de pose frontal a partir del seguimiento de rasgos faciales.
Por otra parte, se propone realizar un estudio sobre la viabilidad de utilizar algoritmos
de estimación de pose más complejos que el empleado en esta Tesis, como Active
Appearance Models (AAM), con el fin de ofrecer una medida más precisa del tiempo de
atención, y eliminar la restricción impuesta sobre la colocación de la webcam sobre la
pantalla.
Además, se debe estudiar más a fondo la posibilidad de usar otras modalidades biométricas
para garantizar que el estudiante es quien dice ser, si las condiciones ambientales
no son favorables para realizar la verificación facial, tal y como planteamos en el artículo

6.3. Trabajos Futuros 127
[González Agulla, Elisardo y otros, 2009b].
También a corto plazo, se plantea la inclusión en un LMS de una herramienta que permita
definir diferentes niveles de seguimiento (monitorización de presencia y atención) y
asignar a cada parte del curso (temarios, cuestionarios, etc.) un tipo diferente de monitorización.
Por otra parte, la solución propuesta podría utilizarse como base para poder ofrecer
adaptación de contenidos en LMS según el perfil del alumno. Este perfil sería generado a
partir de la información de monitorización de las sesiones de aprendizaje y de la propia
naturaleza de los contenidos. El LMS podría saber cual es la representación más adecuada
de sus contenidos para su asimilación por parte de un estudiante en concreto. A partir de
la información de monitorización de varias sesiones se podría estimar si un determinado
estudiante presta más atención a aquellos contenidos con información gráfica que a los que
se basan simplemente en texto, y el LMS podría seleccionar el contenido más adecuado
para favorecer su aprendizaje, ya que podría disponer de varias representaciones para un
mismo tema.
Asimismo, la estructura modular de la solución de monitorización del comportamiento
del estudiante presentada, permite la adición de nuevos componentes que ofrezcan nuevas
funcionalidades. Se propone un análisis sobre la viabilidad de añadir nuevos componentes
que aporten información sobre el estado de ánimo del estudiante mientras visualiza
un recurso [Loh y otros, 2005], información sobre el tiempo de lectura dedicado a cada
contenido [Calvi y otros, 2008], etc.
De todos modos, el framework presentado en esta Tesis no se limita únicamente al entorno
de los LMS, sino que ofrece una solución abierta que permite incluir el seguimiento
en otro tipo de plataformas muy usadas hoy en día gracias al auge de la web 2.0, como
wikis, edublogs, etc.
Finalmente, y no por ello menos importante, en esta Tesis queda abierto un trabajo
de especificación que contemple el modo en que deben definirse y aplicarse, las posibles
configuraciones de seguridad y de monitorización biométrica que se le pueden asociar a
cada contenido de un curso virtual. En la sección 5.3 hemos comentado que la integración
de la monitorización biométrica del comportamiento del estudiante en las plataformas
LMS es un proceso complejo que se debe dividir en varios niveles: nivel de Contenido,
nivel de Navegación y Secuenciamiento, y nivel de Seguimiento. Con esta división reflejamos
que es necesario realizar una especificación que universalice la solución propuesta
haciéndola compatible con múltiples plataformas LMS. Esta especificación debe permitir
definir para cada contenido de un curso virtual el tipo de autenticación y monitorización
biométrica que se requiere para su acceso y consulta. Por ejemplo, especificar que para
el acceso a una lección sólo se realice monitorización del tiempo de presencia del estudiante;
pero si se trata de un cuestionario, que se requiera autenticación biométrica, y
monitorización del tiempo de atención del estudiante. Esta configuración, que refleja la
política de monitorización biométrica aplicada a ese contenido, debería quedar almacenada
en un formato estándar. De este modo se ofrece una solución portable a la hora de
intercambiar el curso entre diferentes plataformas LMS. Asimismo, cada plataforma LMS
debería, durante el proceso de secuenciamiento, ser capaz de interpretar la configuración
que refleja la política de monitorización asociada a un contenido, y aplicarla. Como hemos
dicho anteriormente, es necesaria la creación de herramientas que permitan la edición de

128 Capítulo 6. Contribuciones, Conclusiones y Trabajos Futuros
esta configuración para cada contenido de aprendizaje de un curso virtual. Concluyendo,
esta última línea propuesta se encaminaría hacia el proceso de especificación de la seguridad
y monitorización biométrica de un curso virtual, y se debe analizar si SCORM es el
paraguas más apropiado bajo el que cobijarse.

Apéndice A
Apéndice
Contenido
A.1. Adquisición Base de Datos BioSecure . . . . . . . . . . . . . . . . . 129
A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA . . . . 130
A.3. Resultados Alternativos del Módulo de Monitorización Biométrica . 144
A.1.
Adquisición Base de Datos BioSecure
Durante la realización de esta Tesis se ha colaborado en el proceso de diseño, desarrollo,
y adquisición de una base de datos multimodal dentro del marco de la Red de
Excelencia Europea BioSecure ∗ . En ella se han recogido las muestras biométricas de más
de 600 individuos de manera simultánea en tres escenarios diferenciados: sobre Internet,
en un entorno de oficina con un ordenador de sobremesa, y en un entorno interior/exterior
con un dispositivo portátil.
La colaboración realizada consistió en el diseño y la implementación del software
utilizado en el primer escenario y que estaba basada en la arquitectura de BWA. Software
que se encargaba de realizar la captura de las muestras biométricas y su envío a un servidor
central para su almacenamiento. Esta aplicación nos sirvió como escenario real de estudio
de las fases de captura y envío de muestras biométricas a un servidor central, que también
son necesarias para ofrecer autenticación biométrica en Internet.
Los tres escenarios incluían una parte común con datos de audio y vídeo. También se
han adquirido firma y huella digital en el segundo escenario utilizando el ordenador de
sobremesa. El proceso de adquisición fue llevado a cabo por 11 instituciones europeas.
A continuación citaremos algunas de las características adicionales de la BioSecure
Multimodal Database (BMDB): dos sesiones de adquisición, varios sensores biométricos
en algunas modalidades, distribuciones de la población balanceadas en género y en edad,
∗ http://www.biosecure.info/

130 Capítulo A. Apéndice
escenarios multimodales realistas con una única y rápida tarea por modalidad, diversidad
europea, disponibilidad demográfica, compatibilidad con otras bases de datos multimodales.
Las condiciones de adquisición de BMDB permiten afrontar nuevos desafíos de
investigación y evaluación tanto de sistemas biométricos monomodales como multimodales,
como se ha hecho en la reciente campaña de evaluación BioSecure Multimodal
Evaluation. Un descripción de esta campaña es presentado con más detalle en el artículo
[Ortega-Garcia y otros, 2009]. Para finalizar, informar que se espera que la base de datos
esté disponible con objetivos de investigación a través de la BioSecure Association
durante el 2009.
A.2.
Estadísticas Detalladas sobre el Demostrador Online
de BWA
En este apartado se recogen los informes estadísticos detallados sobre el demostrador
online de la plataforma BioWebAuth (Biometrics for Web Authentication) (BWA) que se
encuentra disponible en la siguiente dirección [BioWebAuth Demonstrator, WWW] para
su evaluación. En la elaboración de estos informes se utilizaron todos los datos recogidos
desde el 14/03/2008 hasta el 05/10/2009 utilizando Google Analytics. Estos informes
reflejan datos estadísticos sobre el uso del sitio web, la visión general de los usuarios,
los navegadores utilizados, la compatibilidad con Java, la fidelización de los usuarios, la
visión general de las fuentes de tráfico, y también proporcionan gráficos de visitas por
ubicación, tanto a nivel mundial como español.
A fecha de 05/10/2009 se han registrado en el sistema un total de 386 usuarios desde
su despliegue el 01/03/2007.

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 131
www.webapps.gts.tsc.uvigo.es
Panel
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
80
80
40
40
14/03/2008 - 15/03/2008 15/06/2008 - 21/06/2008 21/09/2008 - 27/09/2008 28/12/2008 - 03/01/2009 05/04/2009 - 11/04/2009 12/07/2009 - 18/07/2009
Uso del sitio
2.424 Visitas
58,21% Porcentaje de rebote
6.571 Páginas vistas
00:02:08 Promedio de tiempo en el sitio
2,71 Páginas/visita
49,09% Porcentaje de visitas nuevas
Visión general de usuarios
40
20
Usuarios del sitio web
40
20
Navegadores
Navegador Visitas Porcentaje de
visitas
Firefox 1.640 67,66%
Internet Explorer 410 16,91%
14/03/2008 - 15 15/06/2008 - 21 21/09/2008 - 27 28/12/2008 - 03 05/04/2009 - 11 12/07/2009 - 18
Usuarios del sitio web
1.208
Fidelización del usuario
Número de visitas que
ha realizado el usuario,
incluida esta.
Visitas que se correspondían con la
enésima visita del usuario
1 veces 49,30%
2 veces 7,22%
3 veces 3,38%
4 veces 2,02%
Opera 189 7,80%
Mozilla 67 2,76%
Chrome 57 2,35%
Compatibilidad con Java
Compatibilidad con Java Visitas Porcentaje de
visitas
Yes 2.206 91,01%
No 218 8,99%
Gráfico de visitas por ubicación world
5 veces 1,44%
6 veces 1,11%
7 veces 0,99%
8 veces 0,87%
9-14 veces 4,00%
15-25 veces 4,79%
Visitas
1 1.250
26-50 veces 5,94%
51-100 veces 8,62%
101-200 veces 9,57%
201+ veces 0,74%
1 Google Analytics

132 Capítulo A. Apéndice
Visión general de las fuentes de tráfico
Gráfico de visitas por ubicación ES
Tráfico directo
1.119,00 (46,16%)
Sitios web de referencia
1.028,00 (42,41%)
Motores de búsqueda
277,00 (11,43%)
Visitas
1 394
2 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 133
www.webapps.gts.tsc.uvigo.es
Visión general de usuarios
14/03/2008 - 05/10/2009
En comparación con: Sitio
Usuarios del sitio web
40
40
20
20
14/03/2008 - 15/03/2008 15/06/2008 - 21/06/2008 21/09/2008 - 27/09/2008 28/12/2008 - 03/01/2009 05/04/2009 - 11/04/2009 12/07/2009 - 18/07/2009
1.208 usuarios han visitado este sitio.
2.424 Visitas
1.208 Usuario único absoluto
6.571 Páginas vistas
2,71 Promedio de páginas vistas
00:02:08 Tiempo en el sitio
58,21% Porcentaje de rebote
49,09% Nuevas visitas
Perfil técnico
Navegador Visitas Porcentaje de
visitas
Firefox 1.640 67,66%
Internet Explorer 410 16,91%
Opera 189 7,80%
Mozilla 67 2,76%
Chrome 57 2,35%
Velocidad de conexión Visitas Porcentaje de
visitas
Unknown 896 36,96%
T1 680 28,05%
DSL 622 25,66%
Cable 182 7,51%
Dialup 40 1,65%
3 Google Analytics

134 Capítulo A. Apéndice
www.webapps.gts.tsc.uvigo.es
Fidelización del usuario
La mayoría de las visitas se han repetido: 1 veces
14/03/2008 - 05/10/2009
En comparación con: Sitio
Número de visitas que ha realizado el usuario,
incluida esta.
Visitas que
se
correspondí
an con la
enésima
visita del
usuario
Porcentaje de todas las visitas
1 veces 1.195,00 49,30%
2 veces 175,00 7,22%
3 veces 82,00 3,38%
4 veces 49,00 2,02%
5 veces 35,00 1,44%
6 veces 27,00 1,11%
7 veces 24,00 0,99%
8 veces 21,00 0,87%
9-14 veces 97,00 4,00%
15-25 veces 116,00 4,79%
26-50 veces 144,00 5,94%
51-100 veces 209,00 8,62%
101-200 veces 232,00 9,57%
201+ veces 18,00 0,74%
4 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 135
www.webapps.gts.tsc.uvigo.es
Visión general de las fuentes de
tráfico
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
80
80
40
40
14/03/2008 - 15/03/2008 15/06/2008 - 21/06/2008 21/09/2008 - 27/09/2008 28/12/2008 - 03/01/2009 05/04/2009 - 11/04/2009 12/07/2009 - 18/07/2009
Todas las fuentes de tráfico han enviado un total de 2.424 visitas.
46,16% Tráfico directo
42,41% Sitios web de referencia
11,43% Motores de búsqueda
Tráfico directo
1.119,00 (46,16%)
Sitios web de referencia
1.028,00 (42,41%)
Motores de búsqueda
277,00 (11,43%)
Fuentes de tráfico principales
Fuentes Visitas Porcentaje de
visitas
(direct) ((none)) 1.119 46,16%
sourceforge.net (referral) 363 14,98%
gts.tsc.uvigo.es (referral) 343 14,15%
google (organic) 276 11,39%
groups.google.com (referral) 252 10,40%
Palabras clave Visitas Porcentaje de
visitas
biowebauth 122 44,04%
facial recognition ubuntu 42 15,16%
biowebauth vigo 18 6,50%
"biowebauth" 4 1,44%
"perfectmatch fingerprint bsp" 3 1,08%
5 Google Analytics

136 Capítulo A. Apéndice
www.webapps.gts.tsc.uvigo.es
Navegadores
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
80
80
40
40
14/03/2008 - 15/03/2008 15/06/2008 - 21/06/2008 21/09/2008 - 27/09/2008 28/12/2008 - 03/01/2009 05/04/2009 - 11/04/2009 12/07/2009 - 18/07/2009
2.424 visitas han utilizado 9 navegadores.
Uso del sitio
Visitas
2.424
Porcentaje del total del
sitio:
100,00%
Páginas/visita
2,71
Promedio del sitio:
2,71 (0,00%)
Promedio de tiempo
en el sitio
00:02:08
Promedio del sitio:
00:02:08 (0,00%)
Porcentaje de visitas
nuevas
49,30%
Promedio del sitio:
49,09% (0,42%)
Porcentaje de rebote
58,21%
Promedio del sitio:
58,21% (0,00%)
Navegador Visitas Páginas/visita Promedio de
tiempo en el
sitio
Porcentaje de
visitas nuevas
Porcentaje de
rebote
Firefox 1.640 2,75 00:02:07 44,51% 58,84%
Internet Explorer 410 2,93 00:02:50 69,76% 47,80%
Opera 189 1,69 00:01:03 21,16% 78,84%
Mozilla 67 3,15 00:03:14 74,63% 53,73%
Chrome 57 3,16 00:01:36 77,19% 50,88%
Safari 38 3,00 00:00:57 76,32% 55,26%
Konqueror 10 1,60 00:00:10 100,00% 80,00%
(not set) 8 1,62 00:00:00 25,00% 37,50%
SeaMonkey 5 2,20 00:00:34 80,00% 80,00%
1 - 9 de 9
6 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 137
www.webapps.gts.tsc.uvigo.es
Compatibilidad con Java
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
80
80
40
40
14/03/2008 - 15/03/2008 15/06/2008 - 21/06/2008 21/09/2008 - 27/09/2008 28/12/2008 - 03/01/2009 05/04/2009 - 11/04/2009 12/07/2009 - 18/07/2009
2.424 visitas han utilizado 2 compatibilidad con Java.
Uso del sitio
Visitas
2.424
Porcentaje del total del
sitio:
100,00%
Páginas/visita
2,71
Promedio del sitio:
2,71 (0,00%)
Promedio de tiempo
en el sitio
00:02:08
Promedio del sitio:
00:02:08 (0,00%)
Porcentaje de visitas
nuevas
49,30%
Promedio del sitio:
49,09% (0,42%)
Porcentaje de rebote
58,21%
Promedio del sitio:
58,21% (0,00%)
Compatibilidad con Java Visitas Páginas/visita Promedio de
tiempo en el
sitio
Porcentaje de
visitas nuevas
Porcentaje de
rebote
Yes 2.206 2,71 00:02:11 47,64% 58,43%
No 218 2,67 00:01:42 66,06% 55,96%
1 - 2 de 2
7 Google Analytics

138 Capítulo A. Apéndice
www.webapps.gts.tsc.uvigo.es
Gráfico de visitas por ubicación
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
1 1.250
2.424 visitas provinieron de 83 países/territorios.
Uso del sitio
Visitas
2.424
Porcentaje del total del
sitio:
100,00%
Páginas/visita
2,71
Promedio del sitio:
2,71 (0,00%)
Promedio de tiempo
en el sitio
00:02:08
Promedio del sitio:
00:02:08 (0,00%)
Porcentaje de visitas
nuevas
49,30%
Promedio del sitio:
49,09% (0,42%)
Porcentaje de rebote
58,21%
Promedio del sitio:
58,21% (0,00%)
País/territorio Visitas Páginas/visita Promedio de
tiempo en el
sitio
Porcentaje de
visitas nuevas
Porcentaje de
rebote
Spain 1.250 2,40 00:02:19 25,84% 67,84%
United States 164 2,95 00:01:58 84,76% 51,22%
Russia 144 1,80 00:00:51 11,11% 80,56%
Brazil 109 3,18 00:02:18 64,22% 40,37%
India 92 4,53 00:03:42 81,52% 22,83%
Germany 55 3,11 00:01:50 85,45% 36,36%
Mexico 46 3,67 00:03:42 76,09% 47,83%
France 39 3,95 00:02:44 89,74% 38,46%
Colombia 38 3,29 00:02:03 76,32% 31,58%
United Kingdom 36 3,03 00:01:37 86,11% 52,78%
Italy 36 2,78 00:00:49 94,44% 52,78%
China 24 3,88 00:03:48 66,67% 20,83%
8 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 139
Canada 24 2,42 00:01:49 83,33% 54,17%
Argentina 23 2,74 00:01:16 82,61% 56,52%
Venezuela 23 4,00 00:04:15 82,61% 47,83%
Philippines 17 3,94 00:03:31 82,35% 23,53%
Poland 15 3,53 00:00:39 100,00% 46,67%
Australia 14 2,93 00:00:28 92,86% 50,00%
Chile 13 2,92 00:00:47 92,31% 69,23%
Thailand 13 3,85 00:00:52 84,62% 38,46%
Portugal 11 4,27 00:01:23 100,00% 27,27%
Malaysia 11 2,82 00:01:16 100,00% 36,36%
Austria 11 1,82 00:01:18 100,00% 72,73%
Netherlands 10 4,30 00:01:39 100,00% 40,00%
Norway 9 2,33 00:00:34 100,00% 55,56%
Romania 9 2,11 00:04:18 100,00% 44,44%
South Korea 9 2,44 00:01:13 77,78% 55,56%
South Africa 8 2,62 00:01:17 87,50% 75,00%
Kenya 7 5,00 00:04:00 42,86% 14,29%
Sweden 7 1,29 00:00:02 100,00% 71,43%
Slovakia 7 4,00 00:01:19 100,00% 42,86%
Switzerland 7 3,00 00:00:22 85,71% 42,86%
Israel 7 3,57 00:02:36 85,71% 57,14%
Vietnam 6 1,67 00:00:12 66,67% 50,00%
Ukraine 6 4,17 00:01:58 83,33% 33,33%
Belgium 6 2,00 00:00:20 100,00% 50,00%
Ghana 6 2,67 00:00:35 50,00% 33,33%
Indonesia 5 1,40 00:00:20 100,00% 60,00%
Czech Republic 5 1,60 00:00:04 100,00% 40,00%
Taiwan 5 2,80 00:02:05 100,00% 80,00%
Bolivia 5 2,60 00:00:36 80,00% 60,00%
Algeria 5 2,20 00:01:17 60,00% 60,00%
Singapore 5 3,80 00:04:10 80,00% 40,00%
Bulgaria 4 4,00 00:02:13 100,00% 25,00%
Turkey 4 1,75 00:00:06 100,00% 50,00%
Belarus 4 4,50 00:00:33 75,00% 25,00%
Croatia 3 3,00 00:00:27 66,67% 33,33%
Hungary 3 4,00 00:01:09 100,00% 0,00%
Japan 3 1,67 00:00:16 100,00% 66,67%
Greece 3 3,00 00:00:43 100,00% 33,33%
9 Google Analytics

140 Capítulo A. Apéndice
Hong Kong 3 1,00 00:00:00 100,00% 100,00%
Dominican Republic 3 1,33 00:00:02 100,00% 66,67%
Egypt 3 2,67 00:00:21 100,00% 0,00%
Iran 3 1,67 00:00:32 66,67% 33,33%
Ireland 3 1,00 00:00:00 100,00% 100,00%
Finland 3 2,33 00:00:15 100,00% 33,33%
New Zealand 3 2,33 00:00:24 66,67% 33,33%
Costa Rica 3 6,67 00:02:43 66,67% 0,00%
Nigeria 3 2,00 00:07:26 100,00% 33,33%
Serbia 3 4,00 00:01:24 33,33% 33,33%
Ecuador 2 1,50 00:00:37 50,00% 50,00%
Peru 2 1,50 00:00:36 100,00% 50,00%
Kuwait 2 7,50 00:09:32 100,00% 0,00%
Lithuania 2 4,50 00:01:41 100,00% 0,00%
Sri Lanka 2 1,50 00:00:06 100,00% 50,00%
Uganda 1 2,00 00:02:21 100,00% 0,00%
Trinidad and Tobago 1 1,00 00:00:00 100,00% 100,00%
Iraq 1 2,00 00:00:40 100,00% 0,00%
Panama 1 1,00 00:00:00 100,00% 100,00%
Saudi Arabia 1 2,00 00:00:13 100,00% 0,00%
Mauritius 1 1,00 00:00:00 100,00% 100,00%
Uzbekistan 1 2,00 00:00:06 100,00% 0,00%
Puerto Rico 1 1,00 00:00:00 100,00% 100,00%
Uruguay 1 3,00 00:00:26 100,00% 0,00%
Cuba 1 2,00 00:03:17 100,00% 0,00%
Moldova 1 1,00 00:00:00 100,00% 100,00%
Pakistan 1 1,00 00:00:00 100,00% 100,00%
Estonia 1 1,00 00:00:00 100,00% 100,00%
Cyprus 1 2,00 00:13:26 100,00% 0,00%
Latvia 1 1,00 00:00:00 100,00% 100,00%
Nicaragua 1 1,00 00:00:00 100,00% 100,00%
Libya 1 1,00 00:00:00 100,00% 100,00%
Réunion 1 1,00 00:00:00 100,00% 100,00%
1 - 83 de 83
10 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 141
www.webapps.gts.tsc.uvigo.es
Información sobre el país/territorio:
Spain
14/03/2008 - 05/10/2009
En comparación con: Sitio
Visitas
1 394
Este país/territorio ha enviado 1.250 visitas a través de 53 ciudades
Uso del sitio
Visitas
1.250
Porcentaje del total del
sitio:
51,57%
Páginas/visita
2,40
Promedio del sitio:
2,71 (-11,64%)
Promedio de tiempo
en el sitio
00:02:19
Promedio del sitio:
00:02:08 (8,32%)
Porcentaje de visitas
nuevas
25,84%
Promedio del sitio:
49,09% (-47,36%)
Porcentaje de rebote
67,84%
Promedio del sitio:
58,21% (16,54%)
Ciudad Visitas Páginas/visita Promedio de
tiempo en el
sitio
Porcentaje de
visitas nuevas
Porcentaje de
rebote
Vigo 394 1,98 00:01:40 19,04% 76,14%
Pontevedra 247 1,30 00:01:17 5,26% 87,04%
Vigo 188 3,43 00:04:12 21,81% 61,70%
Pontevedra 109 1,96 00:01:38 4,59% 78,90%
Madrid 74 4,16 00:04:11 55,41% 39,19%
Madrid 54 3,70 00:04:15 24,07% 22,22%
Barcelona 47 3,83 00:03:40 51,06% 29,79%
Santiago de Compostela 14 2,64 00:03:22 100,00% 50,00%
Cordoba 12 4,33 00:02:44 50,00% 33,33%
Valencia 11 2,27 00:03:39 81,82% 63,64%
La Coruna 10 2,40 00:00:56 100,00% 80,00%
11 Google Analytics

142 Capítulo A. Apéndice
Ourense 8 2,38 00:01:03 87,50% 75,00%
Sevilla 7 2,43 00:02:54 57,14% 57,14%
Santiago de Compostela 6 2,00 00:00:29 100,00% 50,00%
(not set) 5 1,00 00:00:00 80,00% 100,00%
Igualada 5 6,00 00:04:48 40,00% 0,00%
Eibar 4 1,25 00:03:17 50,00% 75,00%
Leon 3 3,00 00:00:28 66,67% 33,33%
Lugo 3 1,00 00:00:00 100,00% 100,00%
Alcala de Henares 3 1,33 00:00:35 100,00% 66,67%
Caceres 3 1,67 00:00:37 66,67% 33,33%
Zaragoza 3 5,67 00:00:54 100,00% 33,33%
Palma de Mallorca 2 1,50 00:00:04 100,00% 50,00%
Granada 2 2,00 00:00:14 100,00% 0,00%
Sevilla 2 1,00 00:00:00 50,00% 100,00%
Bilbao 2 1,50 00:01:13 50,00% 50,00%
Malaga 2 1,50 00:00:05 100,00% 50,00%
Pamplona 2 1,50 00:00:18 100,00% 50,00%
Santander 2 3,00 00:02:46 100,00% 50,00%
San Sebastian 2 1,00 00:00:00 50,00% 100,00%
Palma de Mallorca 2 1,00 00:00:00 0,00% 100,00%
Oviedo 1 1,00 00:00:00 100,00% 100,00%
Santander 1 2,00 00:00:05 100,00% 0,00%
Leon 1 3,00 00:00:20 100,00% 0,00%
Logrono 1 7,00 00:03:53 100,00% 0,00%
Hospitalet de Llobregat 1 6,00 00:09:24 100,00% 0,00%
Gijon 1 1,00 00:00:00 100,00% 100,00%
Valencia 1 1,00 00:00:00 100,00% 100,00%
Ciudad Real 1 1,00 00:00:00 100,00% 100,00%
Malaga 1 2,00 00:00:30 100,00% 0,00%
Alicante 1 4,00 00:00:43 100,00% 0,00%
Bilbao 1 3,00 00:00:24 100,00% 0,00%
Cullera 1 1,00 00:00:00 100,00% 100,00%
Elche 1 3,00 00:03:14 100,00% 0,00%
Ourense 1 1,00 00:00:00 100,00% 100,00%
Pamplona 1 1,00 00:00:00 100,00% 100,00%
Ripollet 1 2,00 00:01:46 100,00% 0,00%
Cartagena 1 1,00 00:00:00 100,00% 100,00%
Albacete 1 5,00 00:01:52 100,00% 0,00%
12 Google Analytics

A.2. Estadísticas Detalladas sobre el Demostrador Online de BWA 143
La Coruna 1 3,00 00:02:55 100,00% 0,00%
Hospitalet de Llobregat 1 1,00 00:00:00 0,00% 100,00%
Tarragona 1 1,00 00:00:00 100,00% 100,00%
Alcobendas 1 3,00 00:00:30 100,00% 0,00%
1 - 53 de 53
13 Google Analytics

144 Capítulo A. Apéndice
A.3.
Resultados Alternativos del Módulo de Monitorización
Biométrica
En este apartado mostramos los resultados del capítulo 5 en unas tablas en las
que las medidas reales referentes a los intervalos de presencia y de atención utilizadas,
proceden del etiquetado manual de los vídeos por parte de una persona diferente
a la que realizó el etiquetado de las medidas mostradas en la sección 5.4. Este
hecho nos permite ver la influencia, sobre la precisión de las medidas detectadas,
de la subjetividad asociada al proceso de etiquetado humano de los vídeos. Definimos
DetectedAnyP resenceT imeRatio(DAP T R) = DAP T y usamos esta medida como
T ST
criterio de ordenación a priori de los vídeos en todas las tablas de resultados. En este
experimento, el valor de DAPTR debería ser directamente proporcional a la efectividad
del módulo de seguimiento, dado que los vídeos contenían a individuos sentados frente
al ordenador prácticamente durante toda la sesión, exceptuando los dos intervalos de intercambio
de puesto comentados en el protocolo presentado en la sección 5.4.1. Parece
adecuado pensar que valores bajos de esta ratio, significan a priori un mal comportamiento
del módulo de seguimiento.

A.3. Resultados Alternativos del Módulo de Monitorización Biométrica 145
DAP T
DSP T
Student DAPT RAPT DSPT RSPT
RAP T RSP T
2009-05-27_11-07-59_JAG_14.9FPS_traces.txt 0:23:43 0:24:15 97,8 % 0:13:18 0:14:10 93,9 %
2009-05-27_11-03-18_LML_14.9FPS_traces.txt 0:23:30 0:24:23 96,4 % 0:11:42 0:14:39 79,9 %
2009-05-25_09-55-15_DVC_14.9FPS_traces.txt 0:27:23 0:28:25 96,4 % 0:16:37 0:17:43 93,8 %
2009-05-27_11-07-07_NGC_15FPS_traces.txt 0:23:08 0:23:53 96,9 % 0:12:52 0:14:34 88,3 %
2009-05-25_09-53-53_ld_14.9FPS_traces.txt 0:26:25 0:27:21 96,6 % 0:15:38 0:16:43 93,5 %
2009-05-25_10-29-15_n_15FPS_traces.txt 0:20:29 0:21:22 95,9 % 0:11:27 0:11:37 98,6 %
2009-05-27_11-06-09_JRP_14.9FPS_traces.txt 0:22:55 0:24:12 94,7 % 0:11:16 0:14:22 78,4 %
2009-05-25_09-57-18_A_14.9FPS_traces.txt 0:26:23 0:27:26 96,2 % 0:16:30 0:17:21 95,1 %
2009-05-25_09-52-34_b_14.9FPS_traces.txt 0:26:44 0:28:25 94,1 % 0:16:34 0:17:52 92,7 %
2009-05-25_09-49-22_D_14.9FPS_traces.txt 0:25:25 0:27:15 93,3 % 0:07:20 0:16:26 44,6 %
2009-05-25_10-31-41_y_15FPS_traces.txt 0:19:21 0:21:00 92,1 % 0:10:05 0:11:29 87,8 %
2009-05-25_10-17-46_IG_26.5FPS_traces.txt 0:21:41 0:23:11 93,5 % 0:11:52 0:12:17 96,6 %
2009-05-25_10-01-36_d_15FPS_traces.txt 0:21:57 0:24:37 89,2 % 0:13:28 0:13:54 96,9 %
2009-05-25_09-51-47_G_15FPS_traces.txt 0:24:13 0:27:55 86,7 % 0:11:14 0:17:24 64,6 %
2009-05-27_12-53-11_MDFO_14.9FPS_traces.txt 0:20:02 0:24:56 80,3 % 0:03:20 0:14:50 22,5 %
2009-05-25_09-51-43_UG_15FPS_traces.txt 0:22:40 0:28:21 80,0 % 0:04:52 0:17:36 27,7 %
2009-05-27_10-54-53_PBO_25.2FPS_traces.txt 0:18:27 0:24:02 76,8 % 0:09:39 0:13:30 71,5 %
2009-05-25_09-43-32_y_26.7FPS_traces.txt 0:22:09 0:27:55 79,3 % 0:05:38 0:17:17 32,6 %
2009-05-25_10-26-39_hr_26.2FPS_traces.txt 0:18:09 0:22:28 80,8 % 0:10:38 0:12:43 83,6 %
2009-05-27_11-02-30_SRJ_14.9FPS_traces.txt 0:16:52 0:24:48 68,0 % 0:02:58 0:15:17 19,4 %
2009-05-25_11-42-12_mjb_15FPS_traces.txt 0:19:00 0:28:33 66,5 % 0:17:00 0:17:51 95,2 %
2009-05-25_10-51-59_C_25.6FPS_traces.txt 0:18:59 0:28:00 67,8 % 0:11:39 0:17:16 67,5 %
2009-05-27_11-00-41_JLCP_14.9FPS_traces.txt 0:15:13 0:24:55 61,1 % 0:12:17 0:15:27 79,5 %
2009-05-27_12-02-43_XACF_25.2FPS_traces.txt 0:11:34 0:24:12 47,8 % 0:08:22 0:14:17 58,6 %
2009-05-27_11-02-55_MPD_26.3FPS_traces.txt 0:09:24 0:24:34 38,3 % 0:05:04 0:14:54 34,0 %
MEAN: (DAPTR >90 % 11/25 videos) 0:24:08 0:25:16 95,5 % 0:13:02 0:15:11 86,1 %
STANDARD DEVIATION: 0:02:37 0:02:40 1,7 % 0:03:03 0:02:16 15,1 %
MEAN: (DAPTR >70 % 19/25 videos) 0:22:53 0:25:20 90,4 % 0:11:16 0:15:05 75,9 %
STANDARD DEVIATION: 0:02:48 0:02:28 7,3 % 0:03:53 0:02:10 25,3 %
MEAN: (DAPTR >0 % 25/25 videos) 0:21:02 0:25:27 82,7 % 0:10:51 0:15:16 71,9 %
STANDARD DEVIATION: 0:04:31 0:02:19 16,4 % 0:04:10 0:02:01 26,5 %
Tabla A.1: Error de precisión cometido por el detector de presencia extraído de los logs biométricos.

146 Capítulo A. Apéndice
Student RSFPT DSFPT SSFPT(1seg) SSFPT(5seg)
DSF P T
RSF P T
SSF P T (1seg)
RSF P T
SSF P T (5seg)
RSF P T
2009-05-27_11-07-59_JAG_14.9FPS_traces.txt 0:12:49 0:07:20 0:10:13 0:12:16 57,2 % 79,7 % 95,7 %
2009-05-27_11-03-18_LML_14.9FPS_traces.txt 0:12:11 0:04:13 0:05:41 0:07:56 34,6 % 46,6 % 65,1 %
2009-05-25_09-55-15_DV_14.9FPS_traces.txt 0:13:17 0:06:15 0:09:30 0:12:12 47,1 % 71,5 % 91,8 %
2009-05-27_11-07-07_NGC_15FPS_traces.txt 0:11:08 0:06:13 0:07:54 0:09:29 55,8 % 71,0 % 85,2 %
2009-05-25_09-53-53_ld_14.9FPS_traces.txt 0:12:16 0:04:41 0:06:31 0:09:15 38,2 % 53,1 % 75,4 %
2009-05-25_10-29-15_n_15FPS_traces.txt 0:10:54 0:01:58 0:03:06 0:05:22 18,0 % 28,4 % 49,2 %
2009-05-27_11-06-09_JRP_14.9FPS_traces.txt 0:11:52 0:03:50 0:05:23 0:07:21 32,3 % 45,4 % 61,9 %
2009-05-25_09-57-18_A_14.9FPS_traces.txt 0:12:35 0:12:03 0:14:25 0:15:38 95,8 % 114,6 % 124,2 %
2009-05-25_09-52-34_b_14.9FPS_traces.txt 0:12:40 0:09:38 0:11:31 0:13:37 76,1 % 90,9 % 107,5 %
2009-05-25_09-49-22_D_14.9FPS_traces.txt 0:10:20 0:02:27 0:04:00 0:05:34 23,7 % 38,7 % 53,9 %
2009-05-25_10-31-41_y_15FPS_traces.txt 0:09:34 0:01:02 0:02:03 0:03:07 10,8 % 21,4 % 32,6 %
MEAN VALUES: 0:11:47 0:05:25 0:07:18 0:09:15 44,5 % 60,1 % 76,6 %
STANDARD DEVIATION VALUES: 0:01:09 0:03:20 0:03:49 0:03:52 25,4 % 28,2 % 27,3 %
Tabla A.2: Error de precisión cometido por el detector de frontalidad del estudiante extraído de los logs biométricos.

Bibliografía
[Alba-Castro y otros, 2008] Alba-Castro, J., González-Jiménez, D., Argones-Rúa, E.,
González-Agulla, E., Otero-Muras, E. y García-Mateo, C. (2008). Pose-corrected face
processing on video sequences for webcam-based remote biometric authentication.
Journal of Electronic Imaging, 17(1):011004–1–011004–12.
[Allen y otros, 2004] Allen, J. G., Xu, R. Y. D. y Jin, J. S. (2004). Object tracking using
camshift algorithm and multiple quantized feature spaces. En VIP ’05: Proceedings
of the Pan-Sydney area workshop on Visual information processing, páginas 3–7, Darlinghurst,
Australia, Australia. Australian Computer Society, Inc.
[Aller Freire, 2009] Aller Freire, M. (2009). Desarrollo de un módulo de captura de huellas
dactilares para un BSP basado en BioAPI en entornos Windows y Linux. Master’s
thesis, ETSET, University of Vigo.
[Almeida y otros, 2006] Almeida, R. d. M., Oliveira, H. J. Q., Colugnati, F. A. B. y Barretto,
S. F. A. (2006). User authentication in e-learning environments using keystroke
dynamic analysis. En Proceedings of the 22 a International Council for Distance Education,
Rio de Janeiro, Brasil.
[Apache WSS4J, WWW] Apache WSS4J (WWW). http://ws.apache.org/wss4j/. Apache
WSS4J.
[Argones Rúa, 2008] Argones Rúa, E. (2008). Robust Audiovisual Techniques for Identity
Verification. PhD thesis, Signal Theory and Communications Department, University
of Vigo, ETSET, 36310, Vigo, Spain.
[Argones Rúa y otros, 2004] Argones Rúa, E., González Agulla, Elisardo, García Mateo,
C. y Márquez Flórez, O. W. (2004). User Verification in a BioVXML Framework.
En ODYSSEY 2004 - The Speaker and Language Recognition Workshop, páginas 141
– 144, Toledo, Spain. ISCA.
[Asha y Chellappan, 2008] Asha, S. y Chellappan, C. (2008). Authentication of e-
learners using multimodal biometric technology. International Symposium on Biometrics
and Security Technologies ISBAST, páginas 1–6.

148 BIBLIOGRAFÍA
[Auernheimer y Tsai, 2005] Auernheimer, B. y Tsai, M. J. (2005). Biometric authentication
for web-based couse examinations. Hawaii International Conference on System
Sciences, 9:294b.
[BioAPI Framework, WWW] BioAPI Framework (WWW).
BioAPI.
http://www.bioapi.org/.
[BioWebAuth Demonstrator, WWW] BioWebAuth Demonstrator (WWW). https://www.webapps.gts.tsc.uvigo.es/biowebauth_cas/.
BioWebAuth Demonstrator.
[BioWebAuth Project, WWW] BioWebAuth Project (WWW).
http://sourceforge.net/projects/biowebauth/. BioWebAuth(Biomtrics for Web
Authentication).
[Bouguet, 2000] Bouguet, J.-Y. (2000). Pyramidal implementation of the lucas kanade
feature tracker description of the algorithm.
[Bradski, 1998] Bradski, G. R. (1998). Computer vision face tracking for use in a perceptual
user interface. Intel Technology Journal, (Q2).
[Buck y Hunka, 1995] Buck, G. y Hunka, S. (1995). Development of the ibm 1500
computer-assisted instructional system. IEEE Annals of the History of Computing,
17(1):19–31.
[Calvi y otros, 2008] Calvi, C., Porta, M. y Sacchi, D. (2008). e5learning, an e-learning
environment based on eye tracking. En ICALT ’08: Proceedings of the 2008 Eighth
IEEE International Conference on Advanced Learning Technologies, páginas 376–380,
Washington, DC, USA. IEEE Computer Society.
[Capital Humano, 2009] Capital Humano (2009). El estado del arte de la formación.
[Carbonell, 1970] Carbonell, J. (1970). Ai in cai: An artificial-intelligence approach to
computer-assisted instruction. IEEE Transactions on Man Machine Systems.
[CAS Project, WWW] CAS Project (WWW). http://sourceforge.net/projects/biowebauth/.
Central Authentication Service (CAS) project.
[Chen, 2003a] Chen, M. (2003a). Conveying Conversational Cues Through Video. PhD
thesis, Stanford University.
[Chen, 2003b] Chen, M. (2003b). Visualizing the pulse of a classroom. En MULTIME-
DIA ’03: Proceedings of the eleventh ACM international conference on Multimedia,
páginas 555–561, New York, NY, USA. ACM.
[Costa, 2007] Costa, L. (2007). Um modelo de autenticaÇao biometrica para web banking.
Master’s thesis, Universidade Federal de Santa Catarina.
[Daugman, 1988] Daugman, J. G. (1988). Complete Discrete 2D Gabor Transforms by
Neural Networks for Image Analysis and Compression. IEEE Trans. on Acoustics,
Speech and Signal Processing, 36(7):1169 – 1179.

BIBLIOGRAFÍA 149
[Davis y Mermelstein, 1980] Davis, S. B. y Mermelstein, P. (1980). Comparison of Parametric
Representations for Monosyllabic Word Recognition in Continuously Spoken
Sentences. IEEE Transactions on Acoustics, Speech and Signal Processing, ASSP-
28(4):357 – 366.
[Dempster y otros, 1977] Dempster, A. P., Laird, N. M. y Rubin, D. B. (1977). Maximum
Likelihood from Incomplete Data via the EM Algorithm. Journal of the Royal
Statistical Society. Series B, 39(1):1 – 38.
[EDUTOOLS, WWW] EDUTOOLS (WWW). http://www.edutools.info/.
[Elias Penteado y Marana, 2009] Elias Penteado, B. y Marana, A. N. (2009). A videobased
biometric authentication for e-learning web applications. En International Conference
on Enterprise Information Systems.
[Fiérrez Aguilar, 2006] Fiérrez Aguilar, J. (2006). Adapted Fusion Schemes for Multimodal
Biometric Authentication. PhD thesis, Universidad Politécnica de Madrid, Campus
de Cantoblanco, C./ Francisco Tomás y Valiente 11, 28049, Madrid, España.
[Freund y Schapire, 1997] Freund, Y. y Schapire, R. E. (1997). A decision-theoretic generalization
of on-line learning and an application to boosting. Journal of Computer
and System Sciences, 55(1):119–139.
[Fukunaga, 1990] Fukunaga, K. (1990). Introduction to Statistical Pattern Recognition,
Second Edition (Computer Science and Scientific Computing Series). Academic Press.
[García-Barrios y otros, 2004] García-Barrios, V. M., Gütl, C., Preis, A., Andrews, K.,
Pivec, M., Mödritscher, F. y Trummer, C. (2004). Adele: A framework for adaptive
e-learning through eye tracking. En Proceedings of IKNOW 2004, páginas 609–616.
[Gauvain y Lee, 1994] Gauvain, J.-L. y Lee, C. H. (1994). Maximum a Posteriori Estimation
for Multivariate Gaussian Mixture Observations of Markov Chains. IEEE
Transactions on Speech and Audio Processing, 2(2):291 – 298.
[González-Jiménez, 2008] González-Jiménez, D. (2008). Improvements in Pose Invariance
and Local Description for Gabor-based 2D Face Recognition. PhD dissertation,
Universidad de Vigo, Departamento de Teoría de la Señal. Doctor Europeus.
[Gutiérrez Santos, 2007] Gutiérrez Santos, S. (2007). Secuenciamiento de actividades
educativas orientado a la reutilización y la auto-organización en tutoría inteligente.
PhD thesis, Universidad Carlos III De Madrid.
[Hernández y otros, 2008] Hernández, J., Ortiz, A. O., Andaverde, J. y Burlak, G. (2008).
Biometrics in online assessments: A study case in high school students. Electronics,
Communications, and Computers, International Conference on, 0:111–116.
[Huang y otros, 2004] Huang, W., Wang, H., Lin, Z. y Huang, J. (2004). How to compete
in global education market effectively? - a conceptual framework for designing a next
generation eeducation system. Journal of Global Information Management.

150 BIBLIOGRAFÍA
[Hugl, 2005] Hugl, U. (2005). Tech-developments and possible influences on learning
processes and functioning in the future. Journal of American Academy of Business.
[ILIAS with Biometric Authentication, WWW] ILIAS with Biometric Authentication
(WWW). https://www.webapps.gts.tsc.uvigo.es/ilias3/. ILIAS with biometric authentication.
[INCITS, WWW] INCITS (WWW). 1829-d bioapi java progress report. purdue university.
[Jain y otros, 2004] Jain, A. K., Ross, A. y Prabhakar, S. (2004). An introduction to
biometric recognition. IEEE Trans. on Circuits and Systems for Video Technology,
14:4–20.
[JBioAPI Project, WWW] JBioAPI Project (WWW). http://code.google.com/p/jbioapi/.
Open-source Google Code JBioAPI project.
[Jonas Richiardi, 2005] Jonas Richiardi, Andrzej Drygajlo, A. P.-V. R. L. O. G. L. H.
(2005). A distributed multimodal biometric authentication framework. En Proc. 3d
COST 275 Workshop on Biometrics on the Internet, Hatfield, UK.
[Kuncheva, 2004] Kuncheva, L. I. (2004). Combining Pattern Classifiers: Methods and
Algorithms. Wiley-Interscience.
[Levy y Ramim, 2007] Levy, Y. y Ramim, M. M. (2007). A theoretical approach for
biometrics authentication of e-exams. En Proceedings of the 2007 Chais Conference on
Instructional Technologies Research, The Open University of Israel, Raanana, Israel.
[Lienhart y Maydt, 2002] Lienhart, R. y Maydt, J. (2002). An Extended Set of Haarlike
Features for Rapid Object Detection. En Proceedings of the 2002 International
Conference on Image Procesing, volumen I, páginas 900 – 903.
[Linde y otros, 1980] Linde, Y., Buzo, A. y Gray, R. M. (1980). An Algorithm for Vector
Quantizer Design. IEEE Transaction on Communications, 28(1):84 – 94.
[LMSs by JOIN Project, WWW] LMSs by JOIN Project (WWW).
http://www.ossite.org/join/sp/lms/catalog.htm.
[Loh y otros, 2005] Loh, M.-P., Wong, Y.-P. y Wong, C.-O. (2005). Facial expression
analysis in e-learning systems: The problems and feasibility. Advanced Learning Technologies,
IEEE International Conference on, 0:442–446.
[MEC, WWW] MEC (WWW). http://ares.cnice.mec.es/informes/16/contenido/indice.htm.
[Nuttall, 1981] Nuttall, A. H. (1981). Some Windows with Very Good Sidelobe Behaviour.
IEEE Transactions on Acoustics, Speech and Signal Processing, ASSP-29(1):84
– 91. Corrected Harris windows.
[OhOh Website, WWW] OhOh Website (WWW). http://www.ohloh.net/p/biowebauth.

BIBLIOGRAFÍA 151
[Ortega-Garcia y otros, 2009] Ortega-Garcia, J., Fierrez, J., Alonso-Fernandez, F., Galbally,
J., Freire, M. R., Gonzalez-Rodriguez, J., Garcia-Mateo, C., Alba-Castro, J.-L.,
Elisardo Gonzalez-Agulla, Otero-Muras, E., Garcia-Salicetti, S., Allano, L., Ly-Van,
B., Dorizzi, B., Kittler, J., Bourlai, T., Poh, N., Deravi, F., Ng, M. N. R., Fairhurst,
M., Hennebert, J., Humm, A., Tistarelli, M., Brodo, L., Richiardi, J., Drygajlo, A.,
Ganster, H., Sukno, F. M., Pavani, S.-K., Frangi, A., Akarun, L. y Savran, A. (2009).
The multi-scenario multi-environment biosecure multimodal database (bmdb). IEEE
Transactions on Pattern Analysis and Machine Intelligence, 99(1).
[Otero Muras y otros, 2007a] Otero Muras, E., González Agulla, Elisardo, Alba Castro,
J. y Márquez Flórez, O. (2007a). An open framework for distributed biometric authentication.
Annals of Telecommunications. Special Issue on Multimodal Biometrics, 62
(1/2):177–192.
[Otero Muras y otros, 2007b] Otero Muras, E., González Agulla, Elisardo, García Mateo,
C. y Alba Castro, J. L. (2007b). Biometrics for web authentication: an open source
java-based approach. En First Spanish Workshop on Biometrics, SWB, Girona, Spain.
[Papageorgiou y otros, 1998] Papageorgiou, C. P., Oren, M. y Poggio, T. (1998). 1998,
a general framework for object detection. Computer Vision, 1998. Sixth International
Conference on, páginas 555–562.
[Patrones de diseño GoF, WWW] Patrones de diseño GoF (WWW).
http://es.wikipedia.org/wiki/Patrones_de_diseño.
[Patrones de diseño J2EE, WWW] Patrones de diseño J2EE (WWW).
http://java.ciberaula.com/articulo/diseno_patrones_j2ee/.
[Pereira Suárez, 2009] Pereira Suárez, M. (2009). Desarrollo de un módulo BioAPI compatible
de verificación de huellas dactilares. Master’s thesis, ETSET, University of
Vigo.
[Pinto y otros, ted ] Pinto, N., Dicarlo, J. y Cox, D. (( accepted )). How far can you get
with a modern face recognition test set using only simple features? . En CVPR 2009.
[Poh y otros, 2009] Poh, N., Chan, C. H., Kittler, J., Marcel, S., McCool, C., Argones
Rúa, E., Alba Castro, J. L., Villegas, M., Paredes, R., Štruc, V., Pavešic, N., Salh,
A. A., Fang, H. y Costen, N. (2009). Face video competition. En Proceedings of the
International Conference on Biometrics (ICB09), páginas 715–724.
[Porto Domínguez, 2008] Porto Domínguez, B. (2008). Reverse engineering and malware
threat in distributed biometric systems. Master’s thesis, ETSET, University of Vigo.
[Rabuzin y otros, 2006] Rabuzin, K., Baca, M. y Sajko, M. (2006). E-learning: Biometrics
as a security factor. iccgi, 0:64.
[Rath y otros, 1959] Rath, G., Anderson, N. y Brainerd, R. (1959). E. galanter, automatic
teaching: The state of the art. The IBM Research Centre Teaching Machine Project.

152 BIBLIOGRAFÍA
[Reiser, 2001] Reiser, R. A. (2001). A history of instructional design and technology:
Part i: A history of instructional media. Educational Technology Research and Development,
49(1):53–64.
[Reynolds y otros, 2000] Reynolds, D. A., Quatieri, T. F. y Dunn, R. B. (2000). Speaker
Verification using Adapted Gaussian Mixture Models. Digital Signal Processing,
10:19 – 41.
[ROLIM y BEZERRA, 2008] ROLIM, A. L. y BEZERRA, E. P. (2008). Um sistema de
identificação automática de faces para um ambiente virtual de ensino e aprendizagem.
XIV Simpósio Brasileiro de Sistemas Multimídia e Web, II:129–132.
[Rosenberg, 2001] Rosenberg, M. (2001). E-Learning: Strategies for Delivering Knowledge
in the Digital Age. McGraw-Hill.
[Salgueiro Couto, 2008] Salgueiro Couto, E. (2008). Integration of biometric signature
verification in the biowebauth platform. Master’s thesis, ETSET, University of Vigo.
[Sánchez Reíllo y Luis Puebla, WWW] Sánchez Reíllo, R. y Luis Puebla,
A. (WWW). La estandarización en el campo de la identificación
biométrica. http://www.shsconsultores.es/jornadas/0202_-
_la_estandarizacion_en_el_campo_de_la_identificacion_biometrica.pdf.
[SCORM, 2004] SCORM (2004). Advanced Distributed Learning. SCORM: Sharable
Content Object Reference Model.
[ServiciosWeb, WWW] ServiciosWeb (WWW). http://www.w3c.es/ Divulgacion/Guias-
Breves/ServiciosWeb. ServiciosWeb.
[Shen y Bai, 2006] Shen, L. y Bai, L. (2006). A Review on Gabor Wavelets for Face
Recognition. Pattern Analysis and Applications, 9(2):273 – 292.
[Smythe, 2003] Smythe, C. (2003). The IMS Abstract Framework: White Paper - Version
1.0. IMS Specification. IMS Global Learning Consortium, Inc.
[SWIG Project, WWW] SWIG Project (WWW). http://www.swig.org. Open-source project
SWIG (Simplified Wrapper and Interface Generator).
[González Agulla, Elisardo y otros, 2009a] González Agulla, Elisardo, Alba Castro,
J. L., Argones Rúa, E. y Anido Rifón, L. (2009a). Realistic measurement of student
attendance in lms using biometrics. En Proceedings of the International Symposium on
Engineering Education and Educational Technologies (EEET2009), Orlando, Florida,
USA.
[González Agulla, Elisardo y otros, 2008] González Agulla, Elisardo, Anido Rifón,
L., Alba Castro, J. L. y García Mateo, C. (2008). Is my student at the other side?
applying biometric web authentication to e-learning environments. En ICALT ’08:
Proceedings of the 2008 Eighth IEEE International Conference on Advanced Learning
Technologies, páginas 551–553, Washington, DC, USA. IEEE Computer Society.

BIBLIOGRAFÍA 153
[González Agulla, Elisardo y otros, 2009b] González Agulla, Elisardo, Argones Rúa,
E., Alba Castro, J. L., González Jiménez, D. y Anido Rifón, L. (2009b). Multimodal
biometrics-based student attendance measurement in learning management systems.
En To appear in Proceedings of the IEEE International Symposium on Multimedia
(ISM2009), San Diego, California, USA.
[González Agulla, Elisardo y otros, 2004a] González Agulla, Elisardo, Argones Rúa,
E., García Mateo, C. y Márquez Flórez, O. W. (2004a). Development and Implementation
of a Biometric Verification System for e-Learning Platforms. En Kloss, C. D.
y Pardo, A., editores, Proceedings of EduTech Workshop, 18 th IFIP World Computer
Congress, Toulouse, France. The International Federation for Information Processing
(IFIP).
[González Agulla, Elisardo y otros, 2004b] González Agulla, Elisardo, Argones Rúa,
E., García Mateo, C. y Márquez Flórez, O. W. (2004b). Development and Implementation
of a Biometric Verification System for Internet Applications. En Proceedings
of Biometrics on the Internet Fundamentals, Advances and Applications, páginas 33 –
39, Vigo, Spain. COST 275.
[González Agulla, Elisardo y otros, 2005] González Agulla, Elisardo, M árquez Fl
órez, O. W., García Mateo, C. y Alba Castro, J. L. (2005). A java-based framework for
biometric identity verification in secure internet applications. En Simposio de Computación
Ubicua e Inteligencia Ambiental, UCAmI.
[González Agulla, Elisardo y otros, 2007] González Agulla, Elisardo, Otero Muras,
E., Alba Castro, J. L. y García Mateo, C. (2007). An open source java framework
for biometric web authentication based on bioapi. En KES ’07: Knowledge-Based Intelligent
Information and Engineering Systems and the XVII Italian Workshop on Neural
Networks on Proceedings of the 11th International Conference, páginas 809–815,
Berlin, Heidelberg. Springer-Verlag.
[González Agulla, Elisardo y otros, 2009c] González Agulla, Elisardo, Otero Muras,
E., García Mateo, C. y Alba Castro, J. (2009c). A multiplatform java wrapper for the
BioAPI framework. Computer Standards & Interfaces, 31(1):186 – 191.
[Viola y Jones, 2001] Viola, P. y Jones, M. (2001). Rapid object detection using a boosted
cascade of simple features. Proc. CVPR, 1:511–518.
[Wenger, 1987] Wenger, E. (1987). Artificial intelligence and tutoring systems : computational
and cognitive approaches to the communication of knowledge. Morgan Kaufmann.
[Woolley, 1994] Woolley, D. R. (1994). PLATO: The emergence of on-line community.
19(2):20–27.
[X9.84, 2003] X9.84, A. (2003). Biometric information management and security for the
financial services industry. American National Standards Institute. ANSI X9.84.

154 BIBLIOGRAFÍA
[Yu y Tsao, 2003] Yu, C. y Tsao, C. C. (2003). Web teaching: Design, security, and legal
issues. Delta Pi Epsilon Journal, páginas 191–203.
[Zeitz y otros, 2008] Zeitz, C., Scheidat, T., Dittmann, J., Vielhauer, C., González Agulla,
Elisardo, Otero Muras, E., García Mateo, C. y L., A. C. J. (2008). Security issues of
internet-based biometric authentication systems: risks of man-in-the-middle and biophishing
on the example of biowebauth. volumen 6819, página 68190R. SPIE.

Apéndice B
Acrónimos y Abreviaturas
AAM Active Appearance Models
API Application Programming Interface
ADL Advanced Distributed Learning
ANSI American National Standards Institute
BIR Biometric Identification Record
BSP Biometric Service Provider
BWA BioWebAuth (Biometrics for Web Authentication)
BWM BioWebMonitor (Biometrics for Web Monitoring)
CAS Central Authentication Service
CAI Computer Assisted Instruction
CBT Computer Based Training
CBEFF Common Biometric Exchange File Format
CMS Content Management System
DAPT Detected Any Presence Time
DAFPT Detected Any Frontal Pose Time
DSFPT Detected Student Frontal Pose Time
DSPT Detected Student Presence Time
ECTS European Credit Transfer and Accumulation System
FAR False Accept Rate

156 Capítulo B. Acrónimos y Abreviaturas
FRR False Reject Rate
ITS Intelligent Tutor System
IMS IMS
ISO International Standards Organisation
IEEE Institute of Electrical and Electronics Engineers
IEC International Electrotechnical Commission
INCITS InterNational Committee for Information Technology Standards
JNI Java Native Interface
LCMS Learning Content Managament System
LMS Learning Management System
LOM Learning Object Metadata
NIST National Institute of Standards and Technology
PFC Proyecto Fin de Carrera
RAPT Real Any Presence Time
RAAT Real Any Attention Time
RAFPT Real Any Frontal Pose Time
RSAT Real Student Attention Time
RSPT Real Student Presence Time
RSFPT Real Student Frontal Pose Time
RTE Runtime Environment
SCO Shareable Content Objects
SCORM Shareable Content Object Reference Model
SSO Single Sign-On
TI Tecnologías de la Información
TST Total Session Time
URL Uniform Resource Locator
VTT Video Total Time
XCBF XML Common Biometric Format
WBE Web Based Education