Take part in Latch Plugins Contest with such hacks as Paper Key. Are you game?

Thursday, November 24, 2016

At Elevenpaths there is a tradition of developing innovation and training the ability to transform an idea into something tangible, as you might know that in development process, projects often have “asymptotic” completion times

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!

ElevenPaths and Etisalat Digital announce their collaboration for Mobile Security R&D

Monday, November 21, 2016

Madrid, November 21 2016.- ElevenPaths, Telefónica Cyber Security Unit, and Etisalat Digital, two of the world’s leading providers of communications services and solutions, announced today their collaboration in the field Mobile Security research & development (R&D) to conduct extensive research in monitoring and analysing mobile threats for applications and devices. The collaboration was announced at the recent RSA Conference 2016 held at Abu Dhabi. This is an expansion of their alliance beyond their existing shared portfolio of Managed Security and Cyber Security Services. The agreement in Security Services is part of the broader collaboration existing between both companies in multiple areas, under the framework of the Strategic Partnership Agreement originally signed in June 2011.

Francisco Salcedo, Senior Vice President Etisalat Digital said “today’s announcement is significant as mobility has moved beyond devices, apps and online transactions to a connected ecosystem. This transformation has made mobile platforms vulnerable and an easy target for cybercriminals. The collaboration and the deployment at Etisalat Digital’s Cyber Security Operating Centres will enable both partners to provide a solution for enterprises to control fraudulent activity which directly impacts its services, brand or reputation.”

The tools and knowledge used for prevention of PC malware is completely different to mobile malware. A mobile ecosystem is extremely dynamic and cybercriminals are constantly evolving the tools and techniques used for such activities. They look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets on a regular basis.

Both companies will work with Tacyt, a cyber intelligence mobile threat tool developed by ElevenPaths for mobile threats monitoring and analysis. Tacyt uses a big data approach for mobile app environment research and an enterprise-grade service to conduct full investigations, including mobile malware classification, attribution, categorization, monitoring and in-depth analysis of mobile malware need multiple approaches:

  • Mobile ecosystem is extremely dynamic and cybercriminals look for sustainable, scalable business models that generate revenue through fraud while defeating security enhancements introduced by Mobile App Markets. 
  • Attribution and malware family categorization reveals trends in the cybercriminal community. 
  • Malware risk categorization is vital for mobile threat defense in Bring Your Own Device (BYOD) deployments. If an employee installs aggressive adware on a device, would that be enough to block access to corporate email on its own? What if the adware roots and places a backdoor? Categorization will help in such deployments.

Pedro Pablo Pérez, ElevenPaths CEO and Telefónica Global Security Managing Director, said “we are pleased to collaborate with Etisalat Digital to conduct this in-depth research and analysis on mobile threats. Cyber analysts can use Tacyt for manual or automated search, matching, and investigation of different parameters (metadata) within iOS and Android apps. This allows the identification of potential ‘singularities’, a concept which refers to whatever data (dates, size, images, digital certificates) – technical or circumstantial –makes the app or its developer – as a person – singular or unique from others.”

Cryptographic Security in IoT (III)

Friday, November 4, 2016

The proliferation of IoT services platforms and devices is occurring much faster than the adoption of security measures in its field. In the face of the urgent need for mechanisms that guarantee the authentication, integrity and confidentiality, of both communications and the devices themselves, the trend is to transfer cryptographic solutions contrasted in traditional IT, such as public key digital certificates over SSL/TLS protocols. We are moving forward in the state-of-the-art of cryptography solutions for IoT.

HMAC Calculation
Execution of the HMAC command, as with other ATSHA204A commands, must precede execution of the Nonce command.

The aim of the Nonce command is to populate the 32-byte internal register, called TempKey, by generating or loading a challenge, which will then be used in later commands.

The Nonce command has three operating modes. 0x00 and 0x01 are the most common modes. In these modes, the Nonce command is invoked, providing it with a number of 20 bytes as an entry, to which it responds by returning a random number of 32 bytes that are generated internally as a challenge.

The 20 received bytes are linked to the random number of 32 bytes, along with three more bytes: 0x16, the mode and 0x00. And based on the set of 55 bytes, the SHA-256 summary, which is stored in the TempKey, is calculated. Additionally, two binary registers are modified:
  • TempKey.SourceFlag to 0, meaning random origin. 
  • TempKey.Valid, to 1, meaning that the TempKey is usable.
The difference between the 0x00 and 0x01 mode is that in the second case the seed of the random number generator does not update, something that Atmel does not recommend.

In 0x03 mode it is used to directly populate the TempKey, without generating a random number, or the SHA-256 calculation in bypass mode.

If the Nonce command has finished satisfactorily, setting the TempKey.Valid bit to value 1, it is then possible to invoke the HMAC command.

The call to the HMAC command is performed by providing as entry parameters only its mode of operation, and the slot number that contain the key to be used in the HMAC calculation. The response to this command will be the resulting number of 32 bytes from the HMAC-256 computation over a total of 88 bytes made up of:
  • Set of 0x00 value 32 bytes. 
  • Content of 32 bytes from the TempKey. 
  • Base of 24 bytes determined by the mode of operation. 
The HMAC command presents multiple modes of operation, which will determine the content of the OPT zone and the series number (SN) for the device incorporated into the base. It is possible that none of these elements are incorporated, establishing the last 20 bytes of the base at 0x00.

The base of the HMAC calculation will always begin by the 0x11 byte, followed by the mode byte, and two more bytes indicating the slot which is occupied by the key that will perform the HMAC-SHA-256 calculation.

The third least significant bit of the byte mode must coincide with the TempKey.SourceFlag value previously established by the Nonce command.

For all communication with the ATSHA204A device, both incoming and outgoing, two CRC cyclical redundancy check bytes will be added to guarantee the integrity of both the command invocation and its response.

Web PoC
Although the literal description of the authentication commands may appear confusing, their use becomes very simple once implemented within a code library, as can be seen below:

As a simple proof of concept (PoC), we have implemented the practical use case of an IoT device that must be robustly authenticated by a web service, using cryptographic hardware.

For the example to be extended towards the general public, Arduino is used as development environment on an ESP8266 platform that facilitates web access through its WIFI interface.

Any ESP8266 module could be used; a NodeMCU v0.9 has been used in this case, loading a sketch generated from the ESP8266 core for Arduino. An Atmel SHA204A Cryto-Authenticator externally connected to the NodeMCU module has been chosen as the cryptographic hardware.

From the different libraries available for managing the SHA204A, the best adapted for this in general, and the most worked on, was the work of Nusku in 2013. However, it apparently did not work uniformly on different devices and presented some important shortcomings. We have solved these problems by publishing our own fork in Github.

The authentication in the web service is done by inserting an authentication token in the HTTP request (GET request). This is a very common and widespread practice among the most important web authentication services. The "Authorization” header, together with the adequate parameters, has been added for this purpose.

These should include the "11PATHS-HMAC-256” type token, together with the corresponding encoded values in Base64 format. To simplify the process, in addition to the “id” of the device, the header also includes the "nonce" (challenge) and the "base", used to calculate the verification "signature", although the protocol supports the challenge provided by the server.

Captured requests could be re-utilized by sending all this data in the request. In order to avoid this weakness, the timestamp is added in unix-time format as part of the request to be signed.

GET /?timestamp=1458647701 HTTP/1.1\r\n

In order to sign the HTTP request with the Atmel SHA204A, it is summarized to 20 bytes with the SHA-1 algorithm. The Arduino core for ESP8266 includes this function in the "Hash.h” library, but it can be added from the Arduino Crytosuite if another platform is used.

The SHA204A Nonce command is invoked with the obtained 20 bytes, obtaining the 32 resulting bytes as the challenge, and they are stored.

The HMAC command is then invoked, indicating the slot number that contains the key with which the HMAC-SHA-256 will be calculated, together with the execution mode. Once these values (mode and slot) are known, the 24 byte base added to the calculation can be deduced. The result of this command will be the 32 bytes corresponding to the signature of the request.

These values, together with the "id" we assign to the device, will be the base64 parameters that will be included in the header. The base64 encoding is done using the Adam Rudd library.

Authorization: 11PATHS-HMAC-256
nonce="LmzzEpRnXvqmvnbOSobGp1VysR/wEpWoMNaY2Miew5g=", base="EQACAAAAAAAAAAAAAAAA7gAAAAABIwAA", signature="4qnOa5ZGecdzC+DscOSuOhJ64LeB1jTieJATUWPoIZE="

The web service will be able to verify the authenticity of the IoT device that makes the request, performing the same calculations and comparing the results. To that end, it only needs to know the 32 byte key assigned to the device by its “id”.

The example web service has been published in the following url as part of the demonstration: http://sha204a.cf

This web service will respond with a JSON that contains information related to the authentication if it is valid, and failing this, with the details of the error that has occurred. It can be freely used for testing, because it answers to any id that has signed with the example key:


A reciprocal authentication does not occur in this example; in other words, the web service’s answer does not contain any parameter aimed at verifying its own legitimacy, though incorporating it would have been easy. This condition is usually delegated by establishing a secure SSL (https) connection where the web service certificate is verified.

The code of the Arduino sketch is very simple. It manages the connection to the Internet with the "WiFiManager.h" library, which presents an AP with a captive portal from which to configure the Wifi network if the SSID has not been configured or is not available, or if its credential is not valid. Once the Internet connection is established, the current time is established through an NTP server.

An SHA204A authenticated request to the configured web service is made each time the FLASH button is pressed.

A simple Script in BASH can be used to test the connection to the web service; this simple script simulates the calculation of the signature the same way as the ATSHA204A would, and makes the web request.

The Shell Script, the Arduino code for the IoT module, and the PHP code of the web service are published in this Github space: https://github.com/latchdevel/crypto-iot

*Related Content:
Cryptographic Security in IoT (I)
Cryptographic Security in IoT (II)

New tool: PinPatrol for Chrome. Something more than a plugin, a forensics tool

Tuesday, November 1, 2016

Back in July, we created a new tool for improving the experience using HSTS and HPKP in Firefox. Now it's time for Chrome. It shows this information in a human readable way. PinPatrol for Chrome is very easy to use and it can provide useful information about the HSTS and HPKP data stored by your browser... or any other. Porting it to Chrome, it has become not just a Chrome extension, but a simple forensic tool for interpreting HPKP and HSTS data from any Chrome’s user.

Just as Firefox, Chrome stores HPKP and HSTS information in a clear text file. But their strategies are quite different. The main ones are that:
  • Chrome stores the information in a Json file.
  • Instead of storing it in cleartext, it hashes the domains in a standard format, so there is some "privacy" for the users.
  • It uses report_uri from HPKP protocol (Firefox does not yet).

The way the domains are hashed is documented. An example is here. This is the way a raw Json looks like:

Chrome offers an integrated way (chrome://net-internals/#hsts) to check some HSTS and HPKP values, but definitely it is not the best way to watch your domains.

There is another difference in the way Chrome works. Chrome does not allow extensions to get to your profile files, so you have to drag and drop yourself the file where the information is stored (%localappdata%\Google\Chrome\User Data\Default\TransportSecurity in the case of Windows). We can think of this as an advantage to use this extension as a forensic tool.

Another interesting thing the tool tries, is to "un-hash" the domains. If there is a domain in your HSTS and HPKP domains repository, it means you have visited it. So it should be in your History files. What the tool tries is get to your history of domains visited and hash them. If this hash matches with some of the hashes in HSTS/HPKP, the tool "translates" it so it is un-hashed.

PinPatrol takes history domains visited, hashes and compares them against HSTS and HPKP hashed domains

But, why are there so many domains that are not un-hashed? Some reasons:
  • Your history has been deleted and the domain is not there, but still in the HSTS/HPKP repository.
  • Some visits to some domains with HSTS and HPKP are done "in the background" of a webpage, as part of its APIs, advertising system, etc. And these are not stored in the History. 
Here is a very short video about how to use the tool.

The tool is available from the official Chrome Extensions Store:

We hope you find it useful.