Cryptographic Security in IoT (II)

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.

Given Atmel’s long history of developing security elements with cryptographic abilities, such as TPM modules, microcontrollers for SmartCards, cryptographic accelerators, crypto-memories, comparators, etc. it is only natural that the IoT ecosystem begin to integrate its Crypto-Authenticators to add cryptographic abilities. These have three different available variants:

Their physical characteristics are practically identical and are therefore compatible and interchangeable. Choosing one or the other will be determined by the needs of the device storing them, and though they incorporate numerous characteristics of some complexity, it is possible to use their  basic functions easily.

They can be used as highly versatile cryptographic security elements: from simple device authentication, mutual or reciprocal authentication, session key negotiation for integral encryption of a communication, code or data authenticity verification during secure start-up (SecureBoot) or remote firmware updating (OTA), etc. All this for less than 1 euro. If we meet the program’s requirements for “samples”, Atmel sends free samples at no extra cost.

Different small sized formats are produced, all of which are surface-mounted. Though there is a version with only three pins that uses an SWI communication protocol, which for a time was sold by Sparkfun on a mini board, the 8-pin encapsulations are the most common, with SOIC-8 being the most manageable. For the evaluation and testing stages, using a DIP-8 adaptor is advised; there are different types, including the most popular GROVE modules, and you can even make your own.

Only four of its pins are in use. Two for its flexible power supply, of extremely low consumption, which can vary from 2.0 to 5.5 watts; two for the I2C bus, which enables connection to microcontrollers such as the popular Arduino, and even desktop systems and servers by means of adaptors, generally USB types.

The I2C bus is a standard for serial communication, widely used in the industry to interconnect integrated circuits. It uses two lines to transmit information: a data line (SDA) and a clock line (SCL), both with ground reference (GND).

In systems such as BeagleBone and Raspberry PI, the I2C is easily accessible both physically, as it is exposed, and logically, through numerous tools available in GNU/Linux.

If we want to use a conventional system, either Windows, Linux or Mac, that does not have an accessible I2C bus, the most simple option is to use an I2C USB adaptor. There are commercial ones, however it is possible to build your own thanks to the i2c-tiny-usb standard driver, which allows any system to use an Atmel ATtiny 45/85 microcontroller by way of interface USB to I2C. Only a few brave people dare to use the I2C bus present in the connector of video cards, even though it is technically possible. Although it doesn’t provide the same functionality, it is also possible to use firmware that uses the LUFA library in any compatible Atmel microcontroller, for example the ATmega32u4 from Arduino Leonardo, creating a “Serial to I2C” interface, which is accessible from Python, for example. With the USB adaptors included in the official Atmel development kits, the Microsoft Word tools that are included for free can be used.

Communication in the I2C bus is conducted in a “master-slave” manner. The master initiates the dialogue, obtaining a response from the slaves that are identified by their 7-bit I2C address. This address comes factory ready, though many devices have mechanisms to modify it, allowing several similar devices to connect to the same I2C bus.

The “host” systems can only be masters of the I2C bus, with the majority of I2C devices being slaves. Some microcontrollers, for example those used in Arduino, can be programmed to behave as masters or as slaves, though it is most common for them to act as masters.

Through the “i2cdetect” command in Linux, or with a simple sketch in Arduino, the I2C bus can be scanned to detect connected slave devices.

In this scanning example, performed in either Linux, with an “i2c-tiny-usb” adaptor, or in Arduino, the real I2C addresses (in 7-bit format) for the crypto-devices connected to the bus can be obtained. Many manufacturers, Atmel included, usually indicate the I2C addresses in 8-bit format in their specifications, which can result in some confusion.

From these libraries, adaptations to different environments began to appear, once again emphasising Josh Datko’s work which, from Cryptotronix, facilitates numerous examples for both Linux and Arduino.

The Atmel SHA204A Linux driver, called Hashlet, particularly stands out, and has served as a starting point for many other developments.

There are different adaptations for the Arduino platform, each of which has its pros and cons, so a choice must be made to find the one that adapts best to each particular need.

The Atmel SHA204A is one of the simplest and most easy to use cryptographic devices, though it has a wide variety of functions in relation to its relative complexity.

Its functioning is based on the computing of SHA-256 summaries, used to generate MAC/HMAC (Message Authentication Code) from internally stored keys. It has 16 slots to store keys that are 256 bits (32 bytes) in length, and can, in turn, have different access and usage configurations, defined when personalising the device. Together with an 88 byte configuration zone and an OTP (One Time Programmable) zone that is 64 bytes in length.

It has a random number generator, with which it implements challenge-response operations without exposing keys (MAC, CheckMac, GenDig). Supporting “Key Rolling” mechanisms (DeriveKey). It is unequivocally identified by an unmodifiable, factory-defined 72 bit serial number (SN).

It has an abundance of official documentation which is available on the internet, as well as a large number of examples developed by the Open Source community. Though it implements 14 commands, it is possible to make complete functional use of it with only two of them, as we will see next.

Before being able to use any cryptographic device, it is necessary to establish its unique keys and configuration options, and to lock the configuration and OTP zones. This process is known as “personalisation“, and is irreversible; once this has been performed, there is no possibility of turning back, the established parameters will remain unchangeable.

ATSHA204A personalisation is easily performed through Linux by using the Cryptotronix “hashlet”, as described in the documentation. Once the personalisation command has been executed, the unique keys will be defined and configured in the following manner:

Stay tuned! In the following post about Cryptographic security in IoT, we will take a look at how the HMAC calculation works in technical terms in ATSHA204A. And as a proof of concept (PoC), we will implement the practical use case of an IoT device that must be robustly authenticated by a web service and using cryptographic hardware.