As an increasing number of IoT systems are being deployed one of the key enabling technologies has been the Message Queued Telemetry Transport (MQTT) protocol from IBM. MQTT is an easy to use publish and subscribe architecture with open source servers and client such as the Mosquito server and Paho embedded client.
However, many early systems have been designed without any form of communications security, sending unencrypted data packets which are easily intercepted and decoded.
An important design rule for modern cryptographic systems is called “Kerckhofs principle” this states that “the security of the system must depend on the secrecy of the key not the secrecy of the algorithm”. This means that you should only use well researched and trusted algorithms rather than a secret proprietary system. As engineering professionals, we should resist any governmental attempts to restrict research or the weakening of algorithms under the auspices of law enforcement.
| Figure 1: Security services provided by mbed-TLS |
The strong advice is to use only well tried and trusted algorithms and a widely used source code library that is actively supported. This has generally meant using an open source library such as open-SSL. However such a library is not suitable for a small constrained device like a microcontroller. Here we have a much better option in the form of a cryptographic library called mbed-TLS. The mbed-TLS library has been specifically developed as a highly modular minimal footprint library for small embedded systems.
Figure 2: Comparison of Cipher Key sizes |
The mbed-TLS library was originally developed as a commercial library called Polar SSL. In 2015 Polar was acquired by ARM and the Polar SSL library was incorporated as the security component within ARM’s Mbed IoT platform. The Polar SSL library was then renamed as mbed-TLS and made free for commercial and non-commercial use available under either an Apache V2.0 license or GPL v2 license.
A cryptographic library needs to provide a range of security services to enable us to design a secure system. The most obvious of these services are ciphers to ensure confidentiality of user data. While a range of ciphers are supported the current best practice is to use the Advanced Encryption Standard (AES). We also need to ensure the integrity of the data and this is done with hashing algorithms and in particular the family of Secure Hashing Algorithms (SHA) published by the US National Institute of Science and Technology (NIST).
| Figure 3: XCA Certificate and Key management tool |
The original SHA-1 algorithm is no longer recommended for use and any new system should use SHA-2 as a minimum. We also need to provide non-repudiation, if a message is sent we need to be sure of who sent it. If two users can agree a password in advance, then we can use a Message Authentication Code (MAC) this will agree both the integrityand origin of the data. It is also possible to sign messages with public key cryptosystems. This is particularly elegant in the RSA system but there are also dedicated systems such as the Digital Signature Algorithm (DSA).
Random number generation
One of the corner stones of many security protocols is a cryptographically strong random number generator. A typical system will work by gathering true random data (entropy) into an entropy pool. This process is often too slow for real time communication so the random values in the entropy pool are then used as seed values for the pseudo random number generator.
While the mbed-TLS library provides a range of pseudo random number generators, support for gathering random values into an entropy pool is up to the designer.
So how do you know if you have a good enough random number generator? Fortunately, there is a Statistical test suite available from the US National Institute for Science and Technology which has fifteen tests which can be used to qualify your random number generator.
In addition to a wide range of cryptographic algorithms the mbed-TLS library includes a set of abstraction layers which provide a high-level API for each security service. This allows you to develop a system were for example a range of ciphers are installed while a common API is used to select a cipher algorithm from the suite installed and then use the abstracted API to encrypt and decrypt data regardless of the underlying cipher algorithm.
Most of the major silicon vendors now provide Cortex-M based microcontrollers which include a cryptographic processor. Typically this cryptographic processor will provide a hardware implementation of symmetrical ciphers, Hash and MAC algorithms.
The mbedTLS library provides a series of software hooks which can be enabled to use a hardware cryptographic processor in place of the software algorithm.
As its name implies the mbed-TLS library is designed to support the Transport Layer Security protocol. A key part of the TLS protocol is negotiation of a session key using public key encryption. The most widely used public key cipher is the RSA asymmetrical cipher. While this is supported by mbed-TLS it is not the most suitable system for a small microcontroller because of very large key sizes and computational effort required. Fortunately, there are alternatives to RSA such as Diffie Hillman key agreement which can be realised using elliptic curve cryptography.
The use of an elliptic curve in place of a linear number line reduces the required key size and overall computational effort. To achieve the same level of security as the AES cipher with a 128 bit key requires the RSA system to have a key size of over 3000 bits while an elliptic curve implementation of the Diffe Hellman system requires a key size of just 256 bits. The simple take away here is to use elliptic curve cryptography where possible.
During the initial TLS handshake the public keys of the participants are exchanged in the form of X.509 certificates. A certificate consists of user data stored in a format called “Abstract Syntax Notation 1”(ASN.1) and uses a set of “Distinguished Encoding rules”(DER) which ensure that there is exactly one way to encode the certificate data. Once created the DER binary data is then converted to base 64 and stored as ASCII characters in a Privacy Enhanced Mail (.pem) file. If you are running your own website it is necessary to generate your own certificate and have it signed by a trusted certificate authority. However, if you are designing your own closed system it is possible to create and manage your own certificates. The mbed-TLS library contains both source code and command line tools to create and read X.509 certificates.
Another useful tool is XCA. This is an easy to use windows or OS X application that allows you to create sign and manage your own X.509 certificates and is extremely useful during development or managing small scale systems.
All of the cryptographic algorithms used in the TLS protocol have been designed for general purpose computers such as PC’s and servers and as such they are not ideal for small microcontrollers. In 2013 the NSA release two new families of block ciphers called Simon and Speck.
These ciphers were specifically designed for very constrained devices which would typically be user as nodes in the internet of things.
The ‘Speck’ Cipher is designed to be a software implementation while the ‘Simon’ cipher has been optimised for hardware implementations. Currently there are reference implementations available and it is planned to add both ciphers to future releases of mbed-TLS.
The mbed-TLS library is primarily concerned with secure communications and is part of a wider security initiative from ARM. The ARM Platform Security Architecture is a framework designed to enable developers to analyse security threats then design and implement an appropriate architecture.
While this is fairly new it will be available to compliment the new generation of ARMv8-M (Cortex-M23 and Cortex-M33) microcontrollers featuring the Trust Zone security technology.
