Atrévete a participar en Latch Plugins Contest con hacks como Paper Key

En Elevenpaths tenemos una sana tradición que persigue desarrollar la innovación y entrenar la capacidad de acabar las cosas. Ya sabéis que en desarrollo muchas veces los proyectos tienen tiempos de finalización “asintóticos”.

Cada seis meses tenemos el reto de desarrollar durante 24 horas seguidas una idea, llevarla a la práctica y después presentarla en público. Puede ser cualquier cosa, pero lo importante es que funcione. Lo llamamos Equinox.

En el Equinox de Otoño de 2016, un grupo de compañeros (Jorge Rivera, Pedro Martínez, Alberto Sánchez y Félix Gómez) quisimos unir lo abstracto, la seguridad lógica, con lo concreto, algo que pudieras tocar. Y pensamos que de paso podríamos utilizar la tecnología de Latch y la nueva API desarrollada este año (las “instancias de operación”- SDK de Latch).

De ahí surgió el proyecto Paper Key, con el que quisimos unir diversas piezas tecnológicas, primando la seguridad de todo el proceso, y abstrayendo la tecnología, para que el uso fuera sencillo e intuitivo.

La idea es poder emitir un token que da acceso a un servicio o dispositivo. Este token lo imprimimos en papel (algo que tengo) y sólo es válido cuando el Emisor del token autoriza su uso desde la aplicación Latch (segundo factor de autorización).

En nuestro ejemplo real, una persona puede imprimir un ticket con una cantidad de dinero asociada, y tras autorizar la operación en Latch desde su móvil, una segunda persona, canjea el ticket en un monedero automático, que entregará la cantidad indicada de monedas.

En todo el proceso participan dos personas (el Emisor y el Destinatario) y cuatro bloques de tecnología: la aplicación web, la impresora de tickets, el servidor API Python, y el lector de tickets+monedero.

El Emisor, desde una aplicación web, genera un ticket con un identificador de operación y una cantidad de dinero. La operación queda asociada a la cuenta de Latch del Emisor, y el ticket se hace llegar al Destinatario por medios físicos, o bien porque la impresora está en su entorno.

Cuando el Destinatario quiere consumir el ticket (en este caso, obtener una cantidad de euros de un monedero automatizado) se acerca a un lector de tickets, que comprobará el estado de la autorización en Latch. Mientras el Emisor del ticket no autorice la operación, el servicio no podrá ser accedido o consumido, y además se enviará una notificación a su app de Latch de que se está intentando utilizar el ticket (que es el comportamiento estándar).

La arquitectura utilizada en esta prueba de concepto podría optimizarse, pero dado que teníamos que realizar todos los desarrollos en 24 horas necesitábamos poder repartirnos el trabajo entre los cuatro. (Esta aproximación también permite que el servidor, la impresora y el lector de tickets pueden encontrarse distribuidos en distintas ubicaciones, puesto que se comunican entre ellos a través de Internet.
Teniendo en cuenta las premisas de Equinox (24 horas, que funcione y ¡que se pueda explicar!), os describimos los distintos componentes con más detalle.

La WebApp 

Es una sencilla aplicación en PHP con un interfaz en HTML líquido que permite adaptar los formularios a distintos tamaños u orientaciones de la pantalla de los teléfonos móviles.

La aplicación corre en un servidor WAMP y se comunica con una API en Python para hacer el interfaz con la impresora y el lector de tickets.
Es una aplicación en PHP estándar, donde se autentica a los usuarios mediante usuario y password contra un MySQL generando un token de sesión. Podéis encontrar en la web un montón de ejemplos sobre cómo hacer esto.

La WebApp permite al usuario Emisor navegar, y después de validarse, seleccionar una cantidad de dinero y escribir un texto libre para identificar la transacción. Esta información es remitida mediante un POST a un servidor en Python, que generará una petición para la impresora.

La respuesta del servidor con la API en Python es un JSON que parseamos en el servidor PHP para devolver la respuesta a la WebApp:

En el response del POST recibimos el estatus de la operación y el ID generado para presentarlo en la pantalla del teléfono del Emisor.

La impresora de tickets
Este subsistema se compone de una Raspberry Pi y una impresora térmica de tickets. La impresora (Brother QL-570) nos la prestó amablemente el equipo de Secretaría, y la Raspberry la conseguimos del laboratorio de Seguridad IoT, que tiene bastante hardware para jugar.

La Raspberry está conectada a Internet a través de wifi, y espera en un puerto una petición REST con los contenidos que tiene que imprimir (operación “generateID”).

Se genera un código QR bidimensional con la librería libqrencode, y mediante las librerías de Image Magic, se superpone sobre un fondo preestablecido con el logo “Equinox”.

Luego, se añade el texto en la petición, en este caso el valor del ticket generado.

El ticket final será imprimido desde la Raspberry PI gracias al pseudo-driver de impresión para esta impresora, disponible en Git-Hub.

El código QR es un identificador de operación codificado en Base32, y permitirá al lector de códigos QR comprobar el estado de autorización de la operación antes de proporcionar dinero (1 Internet Point al que nos diga por qué tuvimos que usar Base32 en lugar de Base64).

El servidor API Python

En este servidor se encuentran la API en Python para Latch (interfaz entre la WebApp, la impresora, el lector de tickets y el servidor de Latch) y el servidor WAMP. El servidor es invocado por la WebApp , mediante un POST al puerto 1338, con los campos:

Ahora se ejecutan dos operaciones secuencialmente:

1. El servidor construye una solicitud mediante la API para solicitar la “instancia de operación” al sistema Latch de Elevenpaths, de manera que en la app Latch asociada al usuario, aparecerá una nueva línea, con el texto identificador de la operación. Esta operación está ahora por tanto sujeta a la autorización del usuario, está “latcheada”.

Y en el interfaz de la app del teléfono… vemos aparecer, dentro del servicio PaperKey, una nueva “instancia de operación” con el texto introducido “Equinox Demo 2016”.

2. El servidor invoca a la impresora de tickets (IP y puerto de la Raspberry asociada a la impresora) de manera que se imprime el ticket con el código QR asociado a la operación.

En este momento, el Emisor ha generado una operación en Latch, y además ha imprimido un ticket en papel, con un código QR que identifica dicha operación.

Si el Destinatario de la operación (aquella persona que coge físicamente el ticket) quisiera utilizarlo, deberá esperar a que el Emisor autorice dicha operación.

Lector de tickets+hucha

Este sistema está compuesto por otra Raspberry Pi (en la caja de cartón), un lector láser de códigos QR, como los de los supermercados y un colorido dispensador de monedas (ya dijimos que tienen muchos juguetes).

El lector láser se presenta por USB como un teclado estándar HID, de manera que para transmitir información al sistema operativo simula pulsaciones de teclado correspondientes al código escaneado (dígitos o caracteres).

Esto planteaba un problema interesante con el terminal. Para poder realizar la captura de pulsaciones del teclado sin disponer del STDIN del proceso – ya que este estaría en su consola, no estando disponible desde un proceso lanzado en un pseudo terminal – utilizamos un wrapper programado en C que intercepta los eventos del dispositivo que presenta el kernel de Linux en espacio de usuario /dev/input/event5.

Y esto nos provocó un segundo problema, ya que el identificador de operación que utilizamos tiene caracteres alfanuméricos con mayúsculas y minúsculas. Y la emulación de teclado del escáner es siempre de caracteres que no requieren pulsaciones simultáneas (p.ej [SHIFT] + Letra). Por ello hubo que realizar una conversión de código a Base32 (que colateralmente aumenta el tamaño del string, por lo que hay que incrementar la densidad del código QR). Si has leído esto ya no te damos un Internet Point.

Después de todas las curvas y baches, tenemos un identificador de operación. Desde la Raspberry construimos una petición JSON, y la lanzamos contra el servidor API Python, como operación “checkID”.

{
Id: [Identificador de operación]
}

El servidor realizará una consulta a Latch, proporcionando el Id de operación asociado al usuario. Si la operación está “latcheada” (“Latch ON”), el sistema devolverá un error.

Si la operación ha sido des-latcheada (“Latch OFF”), el sistema considerará la operación como autorizada y pasará a proporcionar la cantidad de dinero indicada en el monedero automático. El monedero está conectado a la Raspberry Pi por USB, y recibe la cantidad de monedas a dispensar con un código de 4 dígitos.

Atrévete a participar en Latch Plugin Contest

Paper Key, como prueba de concepto, nos permitió demostrar que es sencillo (¡Lo conseguimos en 23 horas y media!) integrar distintas tecnologías para conseguir un sistema fácil de utilizar, seguro, y con multitud de casos de uso, según la imaginación de cada uno.

Por ejemplo, se podrían utilizar taquillas que contienen un producto proporcionado por el Emisor, y que sólo pueden ser abiertas por el Destinatario al confirmar el Emisor, mediante su Latch, que ha recibido el pago. O se podrían emitir tickets para una barra libre: sólo cuando el responsable (de pagar) lo decide mediante su Latch empiezan a poder validarse los tickets a cambio de bebidas. También puedo dar acceso de un solo uso (OTA) a unas instalaciones, por ejemplo, dar días de prueba gratis de acceso a las instalaciones de un gimnasio. Como veis, un montón de cosas se pueden hacer con integraciones relativamente simples.

Aprovechamos para recordaros que hace unas semanas desde ElevenPaths convocamos una nueva edición del concurso Latch Plugins Contest. En este concurso podéis ganar hasta 5.000 dólares; recordad que lo que se premia es la imaginación, talento, creatividad y solución aportada.

Si queréis conocer todos los pasos a seguir para inscribirse, visitad nuestra Comunidad donde explicamos cómo participar y donde podéis encontrar trucos, consejos, así como uniros a la conversación sobre Latch Plugins Contest. Además, si deseáis conocer toda la mecánica del concurso allí podéis consultar las bases legales.

Recuerda que el plazo del concurso acaba el día 12 de diciembre de 2016, ¡saca tu lado más hack y participa ya!

*También te puede interesar:
Latch Plugins Contest: el concurso de plugins y hacks con que el puedes ganar hasta 5.000 dólares
Latch Plugins Contest: ¡recuerda la historia!