Una vez que ya éramos capaces de capturar todos los datos del cubo a partir del prototipo que hemos visto en las partes anteriores, era el momento de avanzar. Ya tendíamos información tanto de giro de las caras como de posicionamiento del cubo en el espacio con seis grados de libertad. Ahora era el turno de hacernos las siguientes preguntas que vamos a analizar en esta parte del artículo.
Tenemos estos datos, y queremos construir un sistema de autenticación Anti Rubber Hose, pero había que aterrizar los conceptos con una serie de preguntas típicas de cualquier proyecto que utilice Machine Learning. Las preguntas en este caso son:
Capturando datos
El preprocesado de datos se ha convertido hoy en día en una pieza crítica debido a la gran complejidad y cuantía de datos que se manejan. Procesar y filtrar correctamente los datos puede llevarnos a ahorrar tiempo en el descubrimiento de insights tras la aplicación de los modelos sobre los datos, lo cual podría derivar en un impacto positivo en el caso en el que el Machine Learning se esté aplicando.
Al final de la investigación contábamos con algo más de 120 secuencias de resolución, equivalente a unos 18,000 movimientos repartidos en 10 usuarios. El volumen de datos no era todo lo grande que hubiéramos deseado, pero resolver repetidas veces un cubo de Rubik requiere tiempo y, si ya habéis leído esta entrada, esa cuarta dimensión del espacio-tiempo es algo valioso que hay que saber aprovechar.
De cada secuencia de resolución del cubo se puede extraer una gran cantidad de información. En nuestro caso, se obtienen las siguientes características:
Este componente es responsable de alojar los algoritmos de aprendizaje automático dedicados al modelado de secuencias de movimientos generadas por el usuario, así como de evaluar y predecir la autoría de un conjunto de movimientos de resolución consecutivos como parte del proceso de autenticación.
Independientemente de las características de las secuencias elegidas para caracterizar el patrón biométrico del usuario, en esta investigación nos enfrentamos ante un problema de clasificación de secuencias de datos. Es decir, dado un conjunto de características que caracterizan la secuencia de resolución del cubo 3x3x3, se busca caracterizar los modelos de clasificación binarios para que aprendan a discernir la autoría de las secuencias que se proporcionan para cada usuario dentro de un paradigma de aprendizaje supervisado.
Un clasificador o una regla de clasificación es una función ϕ: X→Y, donde Y es un conjunto finito de clases o etiquetas {c_1,c_2,…,c_J}. Para una clasificación binaria, Y ∈{0,1}.
El motor de Machine Learning soporta, en la rutina de entrenamiento, las siguientes actividades ordenadas por orden de ejecución:
La rutina de autenticación de Auth Backend ML soporta las siguientes funcionalidades:
Se han elegido e implementado tres modelos de aprendizaje automático para su incorporación al Auth Backend ML:
Los tres algoritmos hacen uso de secuencias de datos y patrones de posicionamiento del cubo para aprender la autoría de los mismos. Estos modelos admiten tanto secuencias con posicionamiento como secuencias sin información giroscópica. Un usuario puede ingresar secuencias con diferentes cubos, Cube11Paths o GiiKER®, y entrenarlos y probarlos independientemente de si el dispositivo es compatible con giroscopio o no.
Dada la variedad en las resoluciones entre usuarios, cada vez que se inicia el entrenamiento para un usuario, se realiza antes una búsqueda aleatoria de hiperparámetros para maximizar la precisión en el conjunto de datos disponible para cada usuario. Con los hiperparámetros óptimos, se guarda el modelo dedicado exclusivamente a la autenticación de ese usuario, que es el que se restaurará cuando desde el Frontend se pida una autenticación.
Para validar la bondad de las predicciones de nuestros tres clasificadores, dado que nos encontramos ante un problema de imbalanced learning, se recurrieron a las métricas sentitividad, precisión y F1-score. Todo el trabajo que hicimos en la construcción del algoritmo, lo puedes leer en este paper que hemos publicado en ElevenPaths.
El objetivo del algoritmo es conseguir identificar cada grupo de entrenamientos como un conjunto de resolución que en la imagen siguiente están representados por A, B, C, D y E. Dependiendo de cómo de consistentes - similares entre sí - hayan sido las resoluciones, el conjunto será más denso y con menos dispersión, o menos denso y con un mayor grado de dispersión en la resolución.
Así, dos personas que utilicen el mismo método de resolución, pueden tener conjuntos cercanos en el espacio n-dimensional de los datos que utilizamos en el algoritmo, pero pueden estar muy separados si usan métodos distintos de resolución, con más o menos velocidad, e incluso si son diestros o zurdos que mueven las caras de forma totalmente distinta.
Sin embargo, debido a que el volumen de datos que se capturan no es excesivamente grande, sería necesario un aprendizaje intenso para poder utilizar el sistema como un modelo de identificación unívoca de cada individuo. Es decir, saber que una resolución del cubo cae en el conjunto C es posible realizarlo con los datos y entrenamiento explicados en el paper de la Figura 42. Saber si esa resolución pertenece a C o A es necesita más fuentes de datos y una estrategia distinta. Debido a ello, implementamos una solución que explicaremos en la última parte de esta serie para autenticar usuarios.
Para saber cómo abordar esta casuística, lo tenéis todo perfectamente explicado en las páginas 113-115 del libro Machine Learning aplicado a Ciberseguridad. Técnicas y ejemplos en la detección de amenazas de 0xWord.
Saludos Malignos!
**************************************************************************************************
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 1 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 2 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 3 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 4 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 5 de 5)
**************************************************************************************************
 |
| Figura 36: RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 4 de 5) |
Tenemos estos datos, y queremos construir un sistema de autenticación Anti Rubber Hose, pero había que aterrizar los conceptos con una serie de preguntas típicas de cualquier proyecto que utilice Machine Learning. Las preguntas en este caso son:
- ¿Qué pregunta(s) estoy tratando de responder?
- ¿Los datos con los que quiero trabajar tienen potencial para resolver mi problema?
- ¿Cuál es la mejor manera de expresar mis preguntas como un problema de Machine Learning?
- ¿Cuento con un volumen suficiente de datos?
- ¿Qué características voy a extraer de mis datos?
- ¿Qué normalización de datos debemos aplicar (si procede)?
- ¿Qué modelo(s) de ML puedo implementar? ¿Cuáles son los mejores?
- ¿Cómo voy a caracterizar la validez de mi análisis?
Capturando datos
El preprocesado de datos se ha convertido hoy en día en una pieza crítica debido a la gran complejidad y cuantía de datos que se manejan. Procesar y filtrar correctamente los datos puede llevarnos a ahorrar tiempo en el descubrimiento de insights tras la aplicación de los modelos sobre los datos, lo cual podría derivar en un impacto positivo en el caso en el que el Machine Learning se esté aplicando.
 |
| Figura 37: Capturando datos de movimientos. En este caso los de Mi Padawan. |
Al final de la investigación contábamos con algo más de 120 secuencias de resolución, equivalente a unos 18,000 movimientos repartidos en 10 usuarios. El volumen de datos no era todo lo grande que hubiéramos deseado, pero resolver repetidas veces un cubo de Rubik requiere tiempo y, si ya habéis leído esta entrada, esa cuarta dimensión del espacio-tiempo es algo valioso que hay que saber aprovechar.
 |
| Figura 38: Extracto de características y secuencias de resolución del cubo para un determinado usuario almacenadas en un pandas dataframe |
De cada secuencia de resolución del cubo se puede extraer una gran cantidad de información. En nuestro caso, se obtienen las siguientes características:
- Separación temporal entre giros.
- Tiempo de resolución de la secuencia.
- Número de movimientos en cada secuencia.
- Porcentaje de giros de cada cara diferenciado también por sentido de giro (horario o anti horario) en la secuencia.
- Desviación típica de la media del ángulo de cada eje durante la secuencia;
- Media de la desviación típica de los ángulos durante la secuencia;
- Valores medios de la velocidad angular durante la secuencia.
 |
| Figura 39: Arquitectura creada para el servicio de entrenamiento y autenticación |
Este componente es responsable de alojar los algoritmos de aprendizaje automático dedicados al modelado de secuencias de movimientos generadas por el usuario, así como de evaluar y predecir la autoría de un conjunto de movimientos de resolución consecutivos como parte del proceso de autenticación.
Independientemente de las características de las secuencias elegidas para caracterizar el patrón biométrico del usuario, en esta investigación nos enfrentamos ante un problema de clasificación de secuencias de datos. Es decir, dado un conjunto de características que caracterizan la secuencia de resolución del cubo 3x3x3, se busca caracterizar los modelos de clasificación binarios para que aprendan a discernir la autoría de las secuencias que se proporcionan para cada usuario dentro de un paradigma de aprendizaje supervisado.
Un clasificador o una regla de clasificación es una función ϕ: X→Y, donde Y es un conjunto finito de clases o etiquetas {c_1,c_2,…,c_J}. Para una clasificación binaria, Y ∈{0,1}.
 |
| Figura 40: Entrenamiento y testeo en Aprendizaje Supervisado |
El motor de Machine Learning soporta, en la rutina de entrenamiento, las siguientes actividades ordenadas por orden de ejecución:
- Movimientos y posicionamiento de lectura, filtrado y preprocesamiento de datos desde la base de datos Frontend.
- Compilación y construcción de los modelos.
- Rutinas de búsqueda de hiperparámetros para cada modelo y usuario.
- Ajuste del modelo a las características derivadas del estado actual del conjunto de datos.
- Guardado de checkpoints de los modelos de cara al testeo.
 |
| Figura 41: Diagrama de entrenamiento y testeo para cada algoritmo evaluado en la presente investigación |
La rutina de autenticación de Auth Backend ML soporta las siguientes funcionalidades:
- Recepción de los movimientos de autenticación recibidos desde el Frontend: construcción, compilación del modelo y carga del punto de control más reciente.
- Evaluación de modelos una vez que se hayan recibido todos los movimientos esperados del usuario.
- Proporcionar al Frontend la etiqueta predicha por los modelos entrenados para clasificación binaria.
Se han elegido e implementado tres modelos de aprendizaje automático para su incorporación al Auth Backend ML:
- Una primera dedicada a la Regresión Logística Binaria.
- Una segunda basada en un clasificador de Máquinas de Vectores de Soporte (Support Vector Machines).
- El tercero utiliza un Clasificador de Bosque Aleatorio (Random Forest) para autenticar a los usuarios.
Los tres algoritmos hacen uso de secuencias de datos y patrones de posicionamiento del cubo para aprender la autoría de los mismos. Estos modelos admiten tanto secuencias con posicionamiento como secuencias sin información giroscópica. Un usuario puede ingresar secuencias con diferentes cubos, Cube11Paths o GiiKER®, y entrenarlos y probarlos independientemente de si el dispositivo es compatible con giroscopio o no.
Dada la variedad en las resoluciones entre usuarios, cada vez que se inicia el entrenamiento para un usuario, se realiza antes una búsqueda aleatoria de hiperparámetros para maximizar la precisión en el conjunto de datos disponible para cada usuario. Con los hiperparámetros óptimos, se guarda el modelo dedicado exclusivamente a la autenticación de ese usuario, que es el que se restaurará cuando desde el Frontend se pida una autenticación.
Para validar la bondad de las predicciones de nuestros tres clasificadores, dado que nos encontramos ante un problema de imbalanced learning, se recurrieron a las métricas sentitividad, precisión y F1-score. Todo el trabajo que hicimos en la construcción del algoritmo, lo puedes leer en este paper que hemos publicado en ElevenPaths.
El objetivo del algoritmo es conseguir identificar cada grupo de entrenamientos como un conjunto de resolución que en la imagen siguiente están representados por A, B, C, D y E. Dependiendo de cómo de consistentes - similares entre sí - hayan sido las resoluciones, el conjunto será más denso y con menos dispersión, o menos denso y con un mayor grado de dispersión en la resolución.
 |
| Figura 43: Clasificación de conjuntos de Rubika |
Sin embargo, debido a que el volumen de datos que se capturan no es excesivamente grande, sería necesario un aprendizaje intenso para poder utilizar el sistema como un modelo de identificación unívoca de cada individuo. Es decir, saber que una resolución del cubo cae en el conjunto C es posible realizarlo con los datos y entrenamiento explicados en el paper de la Figura 42. Saber si esa resolución pertenece a C o A es necesita más fuentes de datos y una estrategia distinta. Debido a ello, implementamos una solución que explicaremos en la última parte de esta serie para autenticar usuarios.
Para saber cómo abordar esta casuística, lo tenéis todo perfectamente explicado en las páginas 113-115 del libro Machine Learning aplicado a Ciberseguridad. Técnicas y ejemplos en la detección de amenazas de 0xWord.
Saludos Malignos!
**************************************************************************************************
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 1 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 2 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 3 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 4 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 5 de 5)
**************************************************************************************************
No hay comentarios:
Publicar un comentario