Atreva-se a participar em Latch Plugins Contest com hacks como Paper Key

A Elevenpaths tem uma boa tradição cujo objetivo é desenvolver a inovação e treinar a capacidade de concluir as coisas. Vocês já sabem que, na área de desenvolvimento, muitas vezes, os projetos têm tempos de conclusão “assintóticos”.

A cada seis meses permitem-nos desenvolver uma ideia por 24 horas seguidas, levá-la à prática e, depois, apresentá-la ao público. Pode ser o que for, mas o importante é que funcione. Chamamos isso de Equinox.

No Equinox de Outono de 2016, um grupo de colegas (Jorge Rivera, Pedro Martínez, Alberto Sánchez e Félix Gómez) decidiu unir o abstrato, a segurança lógica, e o concreto, algo que fosse tangível. E pensamos que também poderíamos utilizar a tecnologia do Latch e a nova API desenvolvida este ano (as “instâncias de operação”- SDK do Latch).

Foi assim que surgiu o projeto Paper Key, com o qual queríamos unir diversas peças tecnológicas, priorizando a segurança de todo o processo e abstraindo a tecnologia, para que o uso fosse simples e intuitivo.

A ideia é poder emitir um token que dê acesso a um serviço ou dispositivo. Nós imprimimos esse token em papel (algo que eu tenho) e ele só é válido quando o Emissor do token autoriza o uso no aplicativo Latch (segundo fator de autorização). 

No nosso exemplo real, uma pessoa pode imprimir um ticket com uma quantidade de dinheiro associada a ele e, depois de autorizar a operação no Latch por meio do celular, uma segunda pessoa troca o ticket em um porta-moedas automático, que entregará a quantidade indicada de moedas.

Somente duas pessoas (o Emissor e o Destinatário) e quatro blocos de tecnologia participam do processo: o aplicativo Web, a impressora de tickets, o servidor API Python e o leitor de tickets+porta-moedas.

O Emissor, por meio de um aplicativo Web, gera um ticket com um identificador de operação e uma quantidade de dinheiro. A operação fica associada à conta do Latch do Emissor e o ticket é enviado ao Destinatário por meios físicos, ou porque a impressora está em seu ambiente.

Quando o Destinatário quer consumir o ticket (neste caso, obter uma quantidade de euros de um porta-moedas automático), ele se aproxima de um leitor de tickets, que comprovará o estado da autorização no Latch. Se o Emissor do ticket não autorizar a operação, o serviço não poderá ser acessado nem consumido e, além disso, será enviada uma notificação ao app do Latch, dizendo que há uma tentativa de utilização do ticket (que é o comportamento padrão).

A arquitetura utilizada neste teste de conceito poderia ser otimizada, mas, como tínhamos que realizar todos os desenvolvimentos em 24 horas, era necessário que dividíssemos o trabalho entre os quatro. (Essa aproximação também permite que o servidor, a impressora e o leitor de tickets possam ficar em diferentes locais, já que se comunicam entre si por meio da Internet.

Levando em conta as premissas do Equinox (24 horas, que funcione e que possa ser explicado!), descrevemos os diversos componentes com mais detalhes.

O aplicativo web (WebApp)
É um aplicativo simples em PHP com uma interface em HTML líquido que permite adaptar os formulários a vários tamanhos ou orientações de tela dos celulares.

O aplicativo é executado em um servidor WAMP e comunica-se com uma API em Python para fazer a interface com a impressora e o leitor de tickets.

Trata-se de um aplicativo em PHP padrão, no qual os usuários são autenticados por meio de usuário e senha contra um MySQL, gerando-se um token de sessão. Vocês podem encontrar na Web uma grande quantidade de exemplos sobre como fazer isso.

O WebApp permite ao usuário Emissor navegar e, depois da validação, selecionar uma quantidade de dinheiro e escrever um texto livre para identificar a transação. Essas informações são enviadas por meio de um POST a um servidor em Python, que gerará uma solicitação para a impressora.

A resposta do servidor com a API em Python é um JSON que analisamos no servidor PHP para devolver a resposta ao WebApp:
{
status: [Ok/NOK]
money: [quantidade de dinheiro – para informar ao WebApp]
id: [Identificador devolvido pelo servidor – para o WebApp]
}

Na resposta do POST, recebemos o status da operação e o ID gerado para apresentá-lo na tela do telefone do Emissor.

A impressora de tickets
Este subsistema é composto por uma Raspberry Pi e uma impressora térmica de tickets. A impressora (Brother QL-570) foi emprestada com carinho pela equipe de Secretaria, e conseguimos a Raspberry do laboratório de Segurança IoT, que tem muitos hardwares para brincar.

A Raspberry conecta-se à Internet por WiFi e aguarda em uma porta uma solicitação REST com o conteúdo a ser impresso (operação “generateID”).

{
instanceId: [ID de instância Latch]
money: [quantidade de dinheiro em Euros]
}

É gerado um código QR bidimensional com a livraria libqrencode e, por meio das livrarias do Image Magic, sobrepõe-se a um fundo preestabelecido com o logotipo “Equinox”.

Em seguida, o texto é adicionado à solicitação; neste caso, o valor do ticket gerado.

O ticket final será impresso pela Raspberry PI graças ao pseudo-driver de impressão dessa impressora, disponível no Git-Hub.

O código QR é um identificador de operação codificado em Base32 e permitirá ao leitor de códigos QR comprovar o estado de autorização da operação antes de liberar o dinheiro (1 Internet Point, para quem nos perguntar por que tivemos que usar Base32 em vez de Base64).

O servidor API Python
Neste servidor, encontram-se a API em Python para o Latch (interface entre o WebApp, a impressora, o leitor de tickets e o servidor do Latch) e o servidor WAMP.

O servidor é invocado pelo WebApp por meio de um POST à porta 1338, com os campos:
{
money: [quantidade de dinheiro em euros]
text: [string de texto que aparecerá no aplicativo Latch]
}

Então, duas operações são executadas em sequência:
1. O servidor cria uma solicitação por meio da API para solicitar a “instância de operação” ao sistema Latch da Elevenpaths, sendo que, no app Latch associado ao usuário, aparecerá uma nova linha com o texto identificador da operação. Portanto, essa operação está agora sujeita à autorização do usuário, está “latcheada”.

E, na interface do app do telefone … aparecerá, dentro do serviço PaperKey, uma nova “instância de operação” com o texto inserido “Equinox Demo 2016”.

2. O servidor invoca a impressora de tickets (IP e porta da Raspberry associada à impressora) de modo que o ticket é impresso com o código QR associado à operação.

Nesse momento, o Emissor gerou uma operação no Latch, além de ter impresso um ticket em papel com um código QR que identifica essa operação.

Se o Destinatário da operação (a pessoa que pega o ticket fisicamente) quiser utilizá-lo, deverá aguardar até que o Emissor autorize essa operação.

O leitor laser apresenta-se por USB como um teclado padrão HID, de modo que, para transmitir informações ao sistema operacional, ele simula teclas pressionadas correspondentes ao código digitalizado (dígitos ou caracteres).

Isso apresentavam um problema interessante com o terminal. Para poder realizar a captura de teclas pressionadas sem contar com o STDIN do processo, já que este estaria em seu console, não estando disponível por meio de um processo lançado em um pseudo terminal, utilizamos um wrapper programado em C que intercepta os eventos do dispositivo que apresenta o kernel do Linux no espaço do usuário /dev/input/event5.

E isso gerou um segundo problema, já que o identificador de operação que utilizamos tem caracteres alfanuméricos com maiúsculas e minúsculas. E a emulação de teclado do scanner é sempre de caracteres que não precisam ser pressionados simultaneamente (por exemplo, [SHIFT] + Letra). Por isso, foi preciso realizar uma conversão de código para Base32 (que colateralmente aumenta o tamanho do string, sendo, portanto, necessário incrementar a densidade do código QR). Se você leu isso, não merece mais um Internet Point.
Depois de todas as curvas e buracos, temos um identificador de operação. Por meio da Raspberry, construímos e lançamos uma solicitação JSON contra o servidor API Python, como uma operação “checkID”.

{
Id: [Identificador de operação]
}


O servidor realizará uma consulta ao Latch, proporcionando o ID de operação associado ao usuário. Se a operação estiver “latcheada” (“Latch ON”), o sistema devolverá um erro.

Se a operação tiver sido de-latcheada (“Latch OFF”), o sistema considerará a operação como autorizada e liberará a quantidade de dinheiro indicada no porta-moedas automático.  O porta-moedas conecta-se à Raspberry Pi por USB e recebe a quantidade de moedas a ser dispensada com um código de 4 dígitos.

Latch Plugin Contest. Lembre-se!
O Paper Key, como teste de conceito, permitiu-nos demonstrar que é simples (fizemos isso em 23,5 horas!) integrar diferentes tecnologias para obter um sistema fácil de utilizar, seguro e com vários casos de uso, conforme a imaginação de cada um.

Por exemplo, seria possível utilizar bilheterias que contêm um produto proporcionado pelo Emissor e que só podem ser abertas pelo Destinatário quando o Emissor confirmar, por meio do seu Latch, que recebeu o pagamento.

Ou poderiam ser emitidos tickets para uma barra livre: só quando o responsável (por pagar) decidir isso por meio do seu Latch, os tickets começam a poder ser validados em troca de bebidas.

Também posso dar acesso de um só uso (OTA) a certas instalações, por exemplo, dar dias de teste grátis de acesso às instalações de um ginásio.

Como podem ver, muitas coisas podem ser feitas com integrações relativamente simples.

Vamos aproveitar para dizer-lhes que, há algumas semanas, a ElevenPaths convocou uma nova edição do concurso Latch Plugins Contest. Nesse concurso, você pode ganhar até 5.000 dólares. Lembre-se de que os critérios de premiação são a imaginação, o talento, a criatividade e a solução apresentada.

Se quiserem conhecer todos os passos que devem seguir para fazer sua inscrição no concurso, visite a nossa Comunidade, na qual explicamos como participar e onde você pode encontrar dicas e conselhos, e na qual você também pode participar da conversa sobre o Latch Plugins Contest. Além disso, se quiserem conhecer todo o mecanismo do concurso, lá vocês podem consultar o regulamento.

Lembre-se de que o prazo para inscrever-se no concurso vai até o dia 12 de dezembro de 2016. Mostre o seu lado mais hacker e participe agora!