En las tripas de Bitcoin

Como ya he comentado en algún post anterior estoy trabajando en comprender al detalle que es blockchain y cómo funciona.

Por encima el concepto es sencillo pero cuando entras en detalle todo se hace más completo.

Prometo un artículo ( o puede que varios) sobre cómo funciona realmente esta tecnología que, según aventuran algunos, acabará siendo la moneda mundial pero por el momento quiero dejaros dos documentos de Princeton donde cuentan desde lo más general hasta un gran nivel de detalle todo sobre Bitcoin, el padre de todas las monedas criptográficas y de la mano de quien nació el concepto de Blockchain, para mi juicio el verdadero éxito.

Armaros de curiosidad y paciencia. Disfrutadlo.

http://www.the-blockchain.com/docs/Princeton%20Bitcoin%20and%20Cryptocurrency%20Technologies%20Course.pdf

http://assets.press.princeton.edu/chapters/s10908.pdf

Edge Computing, qué es y porqué me importa.

Las tecnologías son como un péndulo. Las modas que desaparecen años después resurgen con algún nuevo matiz pero el mismo fondo.

Cloud no es nada más que el producto de eso mismo, la eterna lucha entre la centralización o descentralización de recursos.

Antes cada empresa tenía sus propios CPD llenos de servidores y con todos sus recursos centralizados en ellos, con el tiempo llegó al normativa ante desastres naturales que obligaba a tener una réplica de ese CPD a varios kilómetros y replicándose en tiempo real. Justo estaba empezando a emerger tecnologías como VMWare ESX (que vieja soy…) las cuales daban respuesta a estas necesidades, el CPD remoto ya podía ser de la mitad del tamaño y soportaba lo mismo o más que el original.

Luego alguien se dió cuenta que no todas las empresas podían tener esa infraestructura con su propio CPD, sus facturas de luz, su mantenimiento, su gestión y todo lo que conllevaba tener eso operativo cada día y seguro. Entonces llegó la nueva moda, el cloud.

Las empresas podían disfrutar de tener su propia infraestructura con garantías, replicada y, con muchas cosas, autogestionadas. Los costes bajaban en picado y las oportunidades eran infinitas. La cumbre de la centralización había llegado. Millones de empresas con todos sus recursos en CPDs inmensos con tecnología punta a su servicio a un precio muy competitivo.

Pero a la par nacían nuevos rumbos de mercado que chocaban con ello frontalmente. IoT, es el concepto mismo de descentralización (y blockchain, pero de eso hablaremos otro día) millones de dispositivos conectados por todo el mundo. Unos incluso en movimiento. Gestionar todo esto desde infraestructuras como la nube podrían suponer muchos problemas para las empresas:

• Problemas de costos: Tener un número de “cosas” medianamente grande suponía ancho de banda (gasto) y procesado (gasto) en tu nube.
• Problemas de seguridad: No vamos a entrar en la seguridad del dispositivo y demás, solo en el canal. Cantidades ingentes de información de valor para tu empresa corriendo por la red hasta tu nube. Dependiendo qué información fuera eso al crimen organizado se lo estábamos poniendo en bandeja.
• Problemas de protección de datos: Muchos de esos datos que se estaban almacenando no cumplian todas las normativas de todos los países donde se pudiera vender el producto.

Por suerte IoT está en pleno crecimiento, es lo que se trabajará y estudiará los próximos años por lo que había margen para poder solucionar y mejorar los esquemas para su gestión.

Entonces ha surgido una nueva moda más, agregar una tercera capa entre esos dispositivos y la nube donde poder recolectar y tratar todos esos datos. A eso se le dió el nombre de Fog/Edge computing.

¿Que es el Fog/Edge computing?

Existe un documento muy trabajado de la SoftNet 2016 donde se habló de los términos Fog Computing, Edge Computing y Cloudlet. Durante días estuve leyendo papers y documentos sobre cuál es la mejor definición de Fog y Edge y cuál era la diferencia entre ambos conceptos.

En la diapositiva 19, por fin pude respirar tranquila:

Correcto, no existe una definición consensuada de cada uno de los términos por lo que es muy difícil poder esclarecer las diferencias entre ambos.

Podríamos decir que Fog nació en concreto para IoT y que Edge cubría más campos y es más dependiente de la conexión (si es Wifi o LTE) pero también es muy inexacto. En mi opinión lo voy a llamar Edge, que es como están llamando las principales casas a sus soluciones, y seguimos adelante.

El término Edge lo que defiende es una capa intermedia entre la nube y los dispositivos. IBM muestra en su blog un diagrama que es muy ilustrativo:

Los cuadros azules inferiores serían los Sensores/Actuadores, se puede ver como en la parte más local, sin que haya salido aún a la red, existen tantos servidores Edge como se puedan necesitar.

Puedes agruparlos como quieras:

• Por número de sensores máximos que quieras que soporten.
• Por funcionalidad de los diferentes sensores.
• Por la potencia necesaria en el Edge para tratar la información antes de salir. Por ejemplo, que necesitemos algo de inteligencia para seleccionar qué información queremos mandar luego a la nube.
• Por localización. Por ejemplo, un Edge para cada ciudad o pueblo.

Los casos puede ser infinitos, habría que ver las necesidades de cada empresa para pensarse como distribuir los Edge, pero como se puede ver en el esquema las posibilidades son infinitas.

Una vez tenemos la infraestructura definida la funcionalidad de los Edge también queda a criterio de las necesidades, se puede:

• Depurar la información: Posiblemente no necesites toda la que tus dispositivos generan, aquí eliminas la no necesaria.
• Ofuscar/Cifrar/Tokenizar información: Si hay una capa más segura es mejor subirlo a ese nivel pero dependendiendo de la criticidad en esta capa ya se podría agregar un primer nivel de seguridad en el dato.
• Guardar temporalmente: Si es muy importante que esa información llegue a tu nube, puedes preparar tus Edge para que guarden esa información en caso de que existan problemas con la red.
• Empaquetar información: Puede que prefieras tener la red libre durante todo el día y la información llegue en una única entrega por la noche, cuando nadie está usando la red. No tendrás información en tiempo real, pero hay negocios que no lo necesitan.
• Implementar seguridad en el canal: Puede que tu pequeño sensor no tenga capacidad de establecer una conexión cifrada hasta la nube, podemos poner esa seguridad a este nivel.

Los límites están en las necesidades de cada negocio, puede meter la inteligencia que necesites en tu Edge.

Ventajas

A estas alturas ya tenemos una idea de que es el Edge y para que sirve, por lo que es más sencillo poder ver las ventajas que aporta [http://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf]:

• Reducción de la latencia: Las “cosas” están más cerca de su Edge que de la nube por lo que la información fluirá de forma más rápida.
• Escalabilidad: Filtraremos y trataremos los datos que subimos a la nube por lo que el flujo de datos será menor reduciendo costes y volumen de carga.
• Mejora de la privacidad: Tendremos un mayor control de los datos, donde viajan y cómo. Ya no son nuestros pequeños dispositivos generando tráfico por la red sino que hasta que no son tratados no viajarán.
• Control de errores por desconexión: Si la red, tanto por el lado de la nube como por el nuestro, tiene caídas podemos guardar los datos temporalmente para no perderlos.
• Seguridad. Podemos mejorar la seguridad en nuestras conexiones, en la cantidad de datos (a menos volumen de datos menor volumen que defender), en la calidad del dato.

Como veis Edge tiene un largo recorrido, los principales distribuidores cloud están trabajando duro por poder ofrecer soluciones de calidad adaptados a sus plataformas.

Pese a que aún esta solución esta en definición el futuro es IoT y creo que el Edge es una muy buena medida para poder controlar los enormes volúmenes de información que nuestras pequeñas cosas generarán.

Iremos profundizando sobre Edge e IoT próximamente, espero que con este artículo s haya dado unas pinceladas para entender qué es y porque va a ser tan importante.

Anexos

https://www.iaria.org/conferences2016/filesICSNC16/Softnet2016_Tutorial_Fog-MEC-Cloudlets-E.Borcoci-v1.1.pdf

http://openedgecomputing.org/

http://elijah.cs.cmu.edu/

www.openfogconsortium.org  

Certifícate en AWS (o no) pero entérate bien de que va la fiesta

Cloud como concepto, hace tiempo que ha bajado de puesto en tecnologías emergentes, hoy en día es un término con el que todos hemos de estar familiarizados y entender bien “sus tripas”.

Las empresas tienen una clara tendencia a adoptar este modelo, ahora que ya está maduro y, existen varias soluciones muy estables.

Pero, aunque todos sabemos que significa el concepto de cloud, meterte en sus tripas y entender mejor sus piezas o soluciones, es otra historia.

Y en esa tesitura me ví hace poco, necesitaba entender bien cómo funcionan las piezas y que posibilidades nos dan cada una de ellas revisando los distintos partners opté por comenzar on AWS.

No creáis que esto es un post para promocionar a nadie, sencillamente, a mi me ha venido muy bien y, quiero recomendar este MOOC de cara a que todos los que estais con el mismo problema, lo tengais mas o menos localizado.

Amazon pone a disposición de todos una basta documentación:

Documentos técnicos: https://aws.amazon.com/es/whitepapers/

Preparación certificación: https://aws.amazon.com/es/certification/certification-prep/

Aparte de regalarte 1 año entero una cuenta de pruebas, con la que podéis probarlo de forma gratuita (ojo que tiene limitaciones, no vayáis a terminar pagando por hacer las pruebas).

Pero si lo que queréis es que os lo expliquen desde el comienzo y con un excelente nivel de detalle os recomiendo este MOOC, que es por donde yo pasé y realmente os enseña tanto de AWS como para que, quien quiera, pueda plantearse presentarse a la certificación.

https://www.udemy.com/aws-certified-solutions-architect-associate

IoT ya es pasado, el futuro es “Tactile Internet”

Revisando mi lista de papers diaria he ido a dar con uno que me ha llamado enormemente la atención, el titulo es este:

“What is the next innovation after the internet of things?”

Y durante unos segundos he estado mirando el título como hipnotizada pensando ¿ya estamos trabajando en el futuro del futuro? IoT está en pañales, con problemas de arquitectura, tecnología y seguridad aún por resolver mientras que la gente de Cisco ya están pensando en cuando Gardner ponga a IoT en el pasado en su gráfica.

No he podido resistirme a leer el paper y resumiendo enormemente lo que viene a decir es que tenemos en nuestras manos IoT con sus billones de dispositivos interconectados llegando a cada rincón del mundo y generando información sin medida, tenemos 5G con su evolución en mejora de velocidad que nos abrirá nuevas puertas y tenemos una evolución en tecnologías hápticas (sí, atentos al palabrejo porque aquí está el corazón de este nuevo término tecnológico) estas tres cosas son el caldo de cultivo perfecto para lo que han bautizado como “Tactile Internet”.

Es decir:

IoT + 5G + Tecnologías Hápticas = Tactile Internet

Pero vayamos más despacio, entendamos mejor qué están diciendo ¿que son las tecnologías hápticas? Yo también he tenido que buscarlo, no tenía ni idea de que era esto pero con una sencilla búsqueda en Google te topas con artículos como este del androide libre, de 2015, donde puedes ver que son tecnologías que te hacen sentir. Hasta ahora interactuamos con las tecnologías usando la vista y el sonido (mayoritariamente) ahora vamos a un nivel diferente, nuevos sentidos entran en juego ¿y si pudieras tocar ese dragón de tu videojuego? ¿Y si pudieras oler ese puchero que te enseña tu madre por la video llamada? Si, eso aún está muy lejos pero es donde la tecnología háptica nos va a llevar, a usar nuevo sentidos a través de la red a velocidades de tiempo casi real y con la información de billones de sensores de todo tipo repartidos por el mundo.

Os recomiendo que echéis un ojo al paper, a la tecnología háptica y memoricéis el término de “Tactile Internet” porque estoy segura que dentro de unos años nos acordaremos de esta entrada.

Tres protocolos de autenticación y tres tragedias de Shakespeare

Hoy toma voz en este blog un invitado especial para presentar una publicación autoeditada, a medio camino entre el manual técnico, la presentación descriptiva y la tragedia de Shakespeare. Así, como suena. Mejor ver que intentar describirlo.

La noche que se me ocurrió contar el funcionamiento y operación de los tres protocolos de autenticación y autorización más utilizados entre diferentes proveedores y APIs pensé que se me había ido ya la cabeza del todo, y que iba siendo hora de irme de vacaciones, por salud mental sobre todo. Sin embargo me envolvió esa dulce embriaguez de pensar que estoy haciendo algo completamente original, potencialmente útil y que unía de un modo ciertamente inverosímil dos de mis aficiones; Seguridad y Shakespeare. 

Suena tremendamente pedante. Lo sé, pero sal del prejuicio e intenta conocer la publicación primero, ya que espoco probable que a través de este medio llegues a conocer al autor. 

Lo que nació como una charla informal a unos compañeros de oficina que querían unas nociones del funcionamiento de SAML, OAuth y OpenIDConnect se convirtió en dos sesiones de formación de varias horas cada una, donde, por el simple hecho de mezclar pasajes de las tragedias de Shakespeare con comportamientos técnicos de los flujos de comunicaciones, quedaron grabados a fuego los casos de uso de los protocolos. Porque las brujas van al encuentro de MacBeth o MacBeth es quien va a buscarlas sabemos que el protocolo SAML puede iniciarse desde el service provider o desde el Identity provider. De Yago manipulando a Otelo para que haga su voluntad ante un tercero sin exponer sus credenciales entendemos el protocolo OAuth 3-legged. El ejemplo con OpenIDConnect tendrás que descubrirlo en el documento, espero que me disculpes, no descubro toda mi magia en el primer encuentro. 

Tiempo después de contar todas estas eclécticas tecnicidades de ciberseguridad con parafernalia Shakespeariana decidí ponerle texto a la presentación. Nunca quise abandonar ese formato por la fuerte capacidad de transmisión de las imágenes a la hora de representar un flujo de comunicaciones. Un poco después me vi forzado a cambiar de trabajo, pero eso es otra historia, mi historia, y hoy no soy yo el personaje principal de una obra por más tiempo. Damas y caballeros, con todos ustedes y con mi máximo amor y dedicación: Three Auth Protocols and Three Shakespeare Tragedies. No dudes en enviarme los comentarios u opiniones que pululen por tu materia gris. 

Y claro... todo ello en el maravilloso idioma del bardo.

Three Auth protocols and Three Shakespeare tragedies  Slideshare
Three Auth protocols and Three Shakespeare tragedies  Scrbdb

Seguridad en ChatBots

La industria de la Inteligencia Artificial está en pleno apogeo, se han depositado muchas esperanzas en ella y se está trabajando en muchos laboratorios creando nuevos “cerebros”.

El “Machine Learning” es un camp que está disfrutando de una época dorada gracias a la nube y el crecimiento de información disponible preparada para ser procesada. Estas evoluciones crearán pronto inteligencias que, según Stephen Hawking, acabarán con nosotros ya que podrán evolucionar más rápido y pronto serán más inteligentes.

Puede que eso suceda o puede que no, por el momento la representación más “a pie de calle” que existe sobre la IA son los ChatBots. ¿Quién no ha sido respondido nunca por uno en Telegram? ¿Quién no ha abierto una página web y una ventana de Chat con un amable señor/señora le pregunta si puede atenderle?

Es la versión más light de Inteligencia Artificial, pero ya se puede hacer mucha operativa interesante con ellos, por ejemplo encargar pizza, hablar de fútbol, ser tu entrenador personal, buscarte los mejores precios del producto que quieras por cientos de webs, ser tu shopping assistant,... Como se pueden ver las opciones ya son miles, por si queréis conocerlos y probarlos os referencio a BotList una web que colecciona ChatBots de todo tipo.

Pero los ChatBot no son ninguna excepción y tienen problemas que hay que revisar en cuanto a seguridad. Dejando de lado el ciclo de desarrollo seguro es un pequeño decálogo para que podáis evaluar en vuestros robots.

1.- ChatBot aislado

El sistema que contiene el ChatBot tendría que estar aislado. Lo ideal es una máquina que contenga solo al Bot y no esté conectada con el resto de la red corporativa.

2.- ChatBot que nunca llama a teleoperadoras.

Si tu sistema de ChatBot te da la posibilidad de poder contactar con una teleoperadora el sistema más seguro para hacerlo es que el usuario indique el número al que se le quiera llamar y que sea una operadora el que le llame a él. Si es el chatbot el que lanza la llamada para conectar de forma directa un atacante podría lanzar miles de peticiones haciendo un ataque de DoS contra la centralita bloqueandola con miles de llamadas entrantes y dejando a los verdaderos clientes en espera e incluso desconectados. Esto haría daño reputacional y puede que se perdieran potenciales clientes.

3.- Sistema contra suplantación.

Un atacante puede que trate de suplantar nuestro ChatBot en otras páginas. Dependiendo que tipo de operativa haga dicho bot puede resultar muy fructífero. Dependiendo en qué plataforma tengamos nuestro ChatBot podría ser más o menos fácil implementar técnicas contra la suplantación. En el entorno Web podrían ser las mismas que contra un phising, en Telegram saludar de forma personalizada a nuestro cliente, de forma que sepa que solo nosotros podemos conocer esa información u otro tipo de medidas creativas que en función de las características de nuestro ChatBot podemos poner.

4.- Canal cifrado.

Esto es un máxima, en todo momento que el canal de la conversación este cifrado. Esto en Telegram puede ser un problema ya que (hasta hace poco) no soportaba establecer canal seguro para bots. Pero en el resto de casos debería ser obligatorio para nuestra tranquilidad.

5.- No almacenar información.

Nunca almacenes las conversaciones, en primer lugar por la privacidad de tu usuario y en segundo lugar porque almacenar la información puede suponer que un atacante te llene la memoria provocando, en el mejor de los casos, la caída de tu servidor.

Si necesitas almacenar la información por logs o seguridad en la operativa ten unas reglas muy bien definidas.

6.- Sanitiza los datos

Nunca sabes lo que un usuario o un atacante puede intentar meter en el chat por lo que sanitizar los datos para que no puedan intentar ejecutar una inyección de código es una idea muy saludable.

7.- Deshabilita los comandos que no quieras usar.

Los chatbots tienen muchos comandos con funcionalidades muy diversas y no siempre necesitamos todas las disponibles por lo que os recomiendo que aquellas que no queréis/necesitáis se eliminen o comenten o hagáis lo que queráis pero que en ningún caso sean accesibles.

8.- No permitas que el ChatBot ejecute comandos de sistema

Tenemos aislado el sistema y controlado que datos guardamos pero sigue siendo muy importante que nuestro ChatBot en ningún momento pueda ejecutar comandos en el sistema que lo aloja.

9.- Prueba de vida.

Esto también depende mucho de la plataforma sobre la que tengamos nuestro bot pero es muy interesante poner un sistema que valide que el usuario está vivo. Puede que, un Captcha para los entornos web o preguntas en entornos Telegram, sean alguna buena idea para esto. Nos ahorraremos muchos dolores de cabeza contra ataques por fuerza bruta.

10.- Agrega un TTL

Agregar un TTL puede salvarte de problemas muy diversos. Si tu ChatBot genera sesión con el usuario, que esa sesión tenga un tiempo máximo de vida. Poner un TTL entre interacción e interacción también es interesante.

Solo revisando estas pequeñas pautas ya se puede intuir que hay ChatBots con características muy diversas. Dependiendo en que plataforma lo queramos implementar y dependiendo de lo sensibles que sean las funcionalidades queramos que haga hay que pensar diferentes medidas.

Todo esto pensando en los ChatBots cuya lógica aún es muy sencilla, el día que tengan un motor potente de IA por detrás puede que (aquí me sale mi ramalazo de ciencia ficción) existan vulnerabilidades a través del razonamiento.

Queda mucho campo por delante para recorrer.

Lectura de Verano 2

Este verano me estoy metiendo de lleno en el mundo del Blockchain, por aventuras de las que ya os hablaré más adelante (aún está la cosa muy verde) estoy leyendo todos los libros y paper que caen en mis manos sobre la materia.

Quería traeros otra recomendación para estas vacaciones, de entre todos los que me he leido por ahora quería destacar el de “Melanie Swan”, iba a comentaros un poco sobre su contenido pero da la casualidad que revisando mi feedreader he ido a topar con este post de Alaxei Manalov (Kaspersky) donde, referenciando a este mismo libro, nos hablan de los seis mitos de Blockchain.

Por lo que para quienes estén interesados en este campo os dejo tres referencias de interés:

• Melanie Swan, Blockchain: Blueprint for a new economy. https://g.co/kgs/hU6q9N
• Six myths about blockchain and Bitcoin: Debunking the effectiveness of the technology. https://www.kaspersky.com/blog/bitcoin-blockchain-issues/18019/
• Blockchain, simplified. https://www.kaspersky.com/blog/bitcoin-easy-explanation/12915/

Autenticación y biometría: Retos y posible solución

Hace tiempo que muchas grandes empresas buscan alternativas para la autenticación de sus clientes/usuarios. Algunos de los sistemas que usan para poder realizar autenticación son:

• Contraseñas, las cuales se consideran por defecto como vulneradas o fáciles de obtener vía phising, compradas en el mercado negro o cualquier otro imaginativo método.
• SMS: En muchos países es muy sencillo poder hacer un duplicado de SIM por lo que el SMS no es suficiente para ayudar en un proceso.
• Authenticator: Esos códigos numéricos que duran solo un breve lapso de tiempo, en mi opinión bastante útiles pero si es cierto que si te han vulnerado el correo o la cuenta con la que pidas esos códigos estamos igual.
• Tarjetas de coordenadas: Los grupos organizados hacen campañas de phising pidiendo tarjetas completas las cuales los usuarios, pacientemente, meten. No quiere decir que tengan todas vulneradas, pero sí que es una medida temporal y que si se proponen pronto tendrán todo el parque de tarjetas en su conocimiento.
• Correo electrónico: Las cuentas de correo se consideran como vulneradas, los usuarios suelen usar contraseñas sencillas, predecibles o siempre las mismas por lo que en alguna BBDD de contraseñas robadas puede estar la del usuario.

La situación es bastante crítica para las grandes empresas por lo que pensando una posible solución se llegó a que era el momento de invertir en biometría. El futuro estaba en pasar del “lo que tengo” o “lo que sé” al “lo que soy”.

Referencia de la imagen

No voy a explayarme contando como funciona, en YouTube hay muchos vídeos sobre biometría (facial, táctil, voz, iris,...) pero éstos planteaban nuevos problemas.

Las principales biometrías estudiadas son:

• Facial: Se dispone del Hardware necesario ya que todos (o la inmensa mayoría) los móviles tienen cámara las cuales no se necesita que sean muy potentes, por lo que la convierte en el candidato perfecto.
• Táctil: La famosa huella dactilar. Este sistema tiene dos problemas principales. El primero es que no se controla el hardware ni el proceso de obtención en ningún momento, hay que confiar en el dispositivo móvil y éstos por definición no son confiables. En segundo lugar huellas solo tenemos 10, si el crimen organizado decide invertir recursos en ésto y se dispone a robar huellas cuando tenga tus 10 estarás vulnerado (y no creo que quieras poner las de tus pies).
• Voz: Demostrado que es la biometría más sensible y difícil de emular, el problema es que necesita un micrófono muy potente para poder grabar todos los indicadores que te van a diferenciar.
• Iris: Descartado por defecto, necesita una cámara muy potente de la cuales el grueso de los usuarios no dispone.
• Reconocimiento de firma escrita: Ya se ha hablado hace tiempo sobre cómo poder vulnerar este sistema. Referencia 1 || Referencia 2

Bien pues visto el panorama las empresas decidieron invertir en biometría facial, el problema es que éste sistema va a nacer marcado de muerte. Ya se han realizado pruebas por las cuales el crimen organizado puede industrializar el hacerse pasar por otra persona, con movimientos incluidos (os adjunto el vídeo porque es sorprendente), por lo que nos plantamos ante un nuevo reto ¿como podemos autenticar de forma segura a nuestros usuarios?

Dado este planteamiento muchos apostaran por el “lo que soy” + “lo que sé” ó “lo que soy” + “lo que tengo” pero de una forma poco acertada combinando los sistemas que hemos visto anteriormente:

• Biometría + usuario/contraseña → Vulnerado
• Biometría + SMS → Vulnerado
• Biometría + Authenticator → Menor riesgo pero vulnerado

Referencia de la imagen

Creo que con esto entendemos el problema ante el que están las grandes empresas ¿solución?

Hace poco cayó en mis manos un paper curioso: “SMAUG: Secure Mobile Authentication Using Gestures” en este estudio proponen un sistema para autenticación segura de usuarios combinando el sensor de huellas con el giroscopio y el acelerómetro de forma que puedas hacer una combinación con tus huellas+movimiento del móvil y así crear un patrón que te identifique. El documento no tiene desperdicio, es un estudio muy completo pero nace con problemas de base:

• No tenemos control sobre el lector de huellas y el proceso de lectura de las mismas en los dispositivo móviles. Ésto es 100% realizado por el SO y solo nos devuelve un true/false, pensemos en dispositivos móviles rooteados ¿Seguís tranquilos con la idea?
• No tenemos control sobre cómo realiza el alta de ese patrón. Si no somos capaces de identificar al usuario durante el alta puede estar haciéndolo otra persona en su lugar generando un patrón desconocido para nuestro cliente.
• ¿Que podemos guardar nosotros? Al no tener control sobre el táctil no podremos controlar fácilmente el patrón

Pero la idea es buena, es muy buena. ¿Que tal si fuéramos un paso más allá?

Dado que las grandes empresas tienen (o están trabajando) sobre un sistema de biometría facial ¿porque no combinar patrones con dicho sistema?

Pero cuando digo patrones no me refiero solo a gestos con la cara (eso ya está muy visto) sino que puedas hacer un gesto con la cara, luego girar la cámara y hacer otro gesto con tu mano o un movimiento con el dispositivo que lo pueda captar el giroscopio…

Combina biometría facial, con giroscopio y acelerómetro puede dar lugar a una combinación muy atractiva de patrones muy diversos que logren hacer un nuevo concepto de “lo que soy” + “lo que sé” ya que la biometría capta lo que soy y el patrón capta lo que sabes.

De ese modo si nos roban nuestra cara y puede emular los gestos nos va a dar igual, tienen que conocer también nuestros movimiento y la velocidad con que lo hacemos. El más difícil todavía para que nos vulneren la autenticación.

Lectura de verano

Todos los veranos hago “la carta a los reyes magos”, esa lista con decenas de cosas que quiero hacer aprovechando la jornada reducida. Lo que normalmente sucede es que llegas a casa muerta de hambre y luego sucumbes a la siestecita por lo que esa lista siempre me ha quedado incumplida.

Este año con el doctorado ha sido muy distinto, he aprovechado mucho las tardes libres y, entre otras cosas de la que ya os hablaré he podido leer varios libros y hoy quiero traeros uno que me ha encantado.

Todo un clásico ¿Quién no conoce a Tanenbaum? El gran profesor que enseña sistemas con Minix (quien quiera sabe de dónde viene Linux que revise la historia de este SO).

Quería darme un repaso sobre redes y protocolos, sentía que era un aspecto que tenía olvidado y abandonado así que hace un par de semana compré el libro de Redes de computadoras.

Una maravilla, un libro que su primera edición es de 1980 y durante cada una de sus nuevas ediciones ha sido revisado y ampliado al completo, por lo que la profundidad con la que explica las capas de red, protocolos y la historia de internet es asombrosa.

Por ponerle una pega, la quinta edición es de 2012 y puede que se eche en falta una nueva actualización en algunos puntos.

A mi me ha valido para dar un repaso completo a lo que tenía ya olvidado, he aprendido muchas cosas nuevas y entre sus páginas se me han ocurrido varias ideas para trastear.

Que no os asusten sus casi 1000 páginas, os prometo que es toda una joya informática.

Todos los libros de Tanenbaum
Libro en Amazon