Every six months we are challenged to develop an idea for 24 hours in a row, put it into practice and then present it in public. It can be anything, but the important thing is that it works. We call it Equinox.
In the Equinox of Fall of 2016, a group of colleagues (Jorge Rivera, Pedro Martínez, Alberto Sánchez and Félix Gómez) wanted to unite the abstract, the logical security, with the specific, something that you could touch. And we thought that, at the same time, we could use the technology of Latch and the new API developed this year (the “operation instances”- Latch SDK).
From there, the Paper Key project was created, with which we wanted to unite different technological pieces, prioritizing the security of the whole process, and abstracting the technology, so that the use is simple and intuitive.
The idea is to be able to issue a token that gives access to a service or device. This token is printed on paper (which I have) and is only valid when the token Issuer authorizes its use from the Latch application (second authorization factor).
In our real example, a person can print a ticket with an associated amount of money, and after authorizing the operation in Latch from their mobile, a second person exchanges the ticket in an automatic wallet, which will deliver the indicated amount of coins.
The whole process involves two people (the Issuer and the Recipient) and four technology blocks: the web application, the ticket printer, the API Python server, and the ticket reader + wallet.
The Issuer, from a web application, generates a ticket with an operation identifier and an amount of money. The operation is associated with the Issuer’s Latch account, and the ticket is sent to the Recipient by physical means, or with the printer that is in their environment.
When the Recipient wants to consume the ticket (in this case, get an amount of euros from an automated wallet), they approach a ticket reader, which will check the status of the authorization in Latch. As long as the ticket Issuer does not authorize the operation, the service cannot be accessed or consumed, and a notification will also be sent to their Latch app that someone is attempting to use the ticket (which is the standard behavior).
The architecture used in this proof of concept could be optimized, but since we had to finish all developments in 24 hours, we needed to share the work among the four of us. (This approach also allows the server, printer and ticket reader to be distributed in different locations, since they communicate with each other via the Internet).
Taking into account the premises of Equinox (24 hours, that it works and that it can be explained!), we describe the different components in more detail.
The WebApp
It is a simple application in PHP with an interface in liquid HTML that allows to adapt the forms to the different sizes or orientations of the screen of mobile telephones.
The application runs on a WAMP server and communicates with an API in Python to interface with the printer and the ticket reader. It is a standard PHP application, where users are authenticated by user and password against a MySQL generating a session token. You can find a lot of examples on how to do this on the website.
The WebApp allows the user to browse, and after being validated, to select an amount of money and write a free text to identify the operation. This information is sent via a POST to a Python server, which will generate a request for the printer.
The response of the server with the API in Python is a JSON that we parse in the PHP server to return the response to the WebApp:
{
status: [Ok/NOK]
money: [amount of money – to inform the WebApp]
id: [Identifier returned by the server – for the WebApp]
}
In the response of the POST we receive the status of the operation and the ID generated to enter it on the screen of the Issuer’s phone.
The ticket printer
This subsystem consists of a Raspberry Pi and a thermal ticket printer. The printer (Brother QL-570) was kindly lent to us by the Secretariat team, and we got the Raspberry from the IoT Security lab, which has enough hardware to play with.
The Raspberry is connected to the Internet via Wi-Fi, and it waits in a port for a REST request with the contents it has to print ( “generateID” operation.)
{
instanceId: [Latch instance ID]
money: [amount of money in Euros]
}
A two-dimensional QR code is generated with the libqrencode library, and with the Image Magic’s libraries, the code is superimposed over a pre-established background with the “Equinox” logo. Then, the text is added to the request, in this case the value of the generated ticket.
The final ticket will be printed with the Raspberry PI thanks to the printing pseudo-driver for this printer, available in Git-Hub.
The QR code is an operation identifier encoded in Base32, and will allow the QR code reader to check the authorization status of the operation before providing money (1 Internet Point goes to the one that tells us why we had to use Base32 instead of Base64).
The Python API server
On this server we can find the API in Python for Latch (interface between the WebApp, the printer, the ticket reader and the Latch server) and the WAMP server.
The server is invoked by the WebApp, using a POST to port 1338, with the fields:
{
money: [amount of money in euros]
text: [string of text that will appear in the Latch app]
}
Two operations are now executed sequentially:
1. The server creates a request via the API to request the “operation instance” to the Latch system of Elevenpaths, so that in the Latch app associated with the user, a new line will appear with the text identifier of the operation. This operation is now subject to the authorization of the user, is “latched”.
And in the interface of the phone app … we find, within the PaperKey service, a new “operation instance” with the entered text “Equinox Demo 2016”.
2. The server invokes the ticket printer (IP and port of the Raspberry associated with the printer) so that the ticket is printed with the QR code associated with the operation. At this moment, the Issuer has generated an operation in Latch, and also has printed a paper ticket with a QR code that identifies said operation.
If the Recipient of the operation (that person who physically takes the ticket) would like to use it, they must wait for the Issuer to authorize such operation.
Ticket reader + money bank This system is composed of another Raspberry Pi (in the cardboard box), a laser QR code reader, like those in supermarkets and a colorful coin dispenser (we told you they have a lot of toys).
The laser reader is presented by USB as a standard HID keyboard, so that to transmit information to the operating system it simulates keystrokes corresponding to the scanned code (digits or characters).
This posed an interesting problem with the terminal. In order to be able to capture keystrokes without the STDIN of the process – since this would be in its console, not being available from a process launched in a pseudo terminal – we used a wrapper programmed in C that intercepts the events of the device that presents the Linux kernel in user space /dev/input/event5.
And this caused us a second problem, since the operation identifier we use has alphanumeric characters with uppercase and lowercase, and the keyboard emulation of the scanner is always with characters that do not require simultaneous keystrokes (e.g. [SHIFT] + Letter.) So we had to do a code conversion to Base32 (which collaterally increases the size of the string, so the density of the QR code must be increased as well.) If you have read this, we will not give you that Internet Point. After all the twists and bumps, we have an operation identifier. From the Raspberry, we build a JSON request, and launch it against the API Python server as operation “checkID.”
{
Id: [Operation identifier]
}
The server sends a query to Latch, providing the operation ID associated with the user. If the operation is “latched” (“Latch ON”), the system will return an error.
If the operation has been unlatched (“Latch OFF”), the system will consider the operation as authorized and will proceed to provide the amount of money indicated in the automatic wallet. The wallet is connected to the Raspberry Pi by USB, and it receives the amount of coins to dispense with a code of 4 digits.
Taking part in Latch Plugin Contest
Paper Key, as proof of concept, allowed us to prove that it is simple (we did it in 23.5 hours!) to integrate different technologies to achieve a secure and user friendly system with many use cases, depending on the imagination of each person.
For example, lockers containing a product provided by the Issuer and that can only be opened by the Recipient, upon confirmation of payment received by the Issuer via their Latch. Or one could issue tickets for a free bar: only when the party responsible (to pay) decides so via their Latch, the tickets can be validated in exchange for drinks. One can also give one-time access (OTA) to a facility, for example, give free trial days of access to a gym.
As you can see, a lot of things can be done with relatively simple integrations.
We would like to take this opportunity to remind you that a few weeks ago ElevenPaths convened a new edition of the competition Latch Plugins Contest. In this contest you can win up to $ 5,000; remember that what is rewarded is the imagination, talent, creativity and solution provided. If you want to know all the steps to follow to register, visit our Community, where we explain how to participate and where you can find tricks, tips, and also join the conversation about the Latch Plugins Contest. In addition, if you want to know all the mechanics of the contest, you will also be able to check the legal terms and conditions.
Remember that the deadline of the contest is December 12, 2016, show your hack side and participate now!
*Related content:
Latch Plugins Contest: the plugins and hacks contest in which you can win up to 5,000 USD
Latch Plugins Contest: Remember the story!
