The IoT is all about sharing, be that data, control or general access. Those who fully appreciate this — the ones listening closest to those shouting the loudest about security — also understand the measures that need to be implemented, to ensure any security issues are mitigated. While it’s not impossible to encrypt all data passed over public networks, the issue remains that sometimes that data may be passed to the wrong agent. For this reason, many believe that authentication will be fundamental in enabling the IoT. The ability to verify the identity of any agent making a request for access will hugely reduce the risk of nefarious activity.
This article looks at how authentication is achieved in general, with particular focus on how it is implemented in embedded systems, highlighting the hardware and software features now being integrated in MCUs for just this purpose, and how they may help improve the general security of any embedded system connected to the IoT.
Secret sauce
The perceived threat presented by Internet access to sensitive systems is that it may leave those systems open to attack; in commerce that could leave financial data vulnerable, but in the IoT that may well translate to changing operating parameters in a machine, or access to a building. The difference here is that the world of commerce is still predominantly ‘overlooked’ by humans, while the IoT aims to largely remove the need and expense of human interaction.
In addition, the speed with which any changes may need to be executed could render human interaction unfeasible. Motor control is often cited as a case in point; being able to modify the parameters of a motor in reaction to varying loads can increase efficiency significantly, an action that needs to be autonomous to be fully effective. Ensuring any new parameters passed to the control circuit are valid requires authentication of the sender, the data, or both.
Authenticating the sender may be possible, but the standard approach now adopted is to authenticate the data — or rather, check that the data has not been changed between being sent and being received. Today this is achieved using the Secure Hash Algorithm (SHA), a method that returns a ‘checksum’ for the data that can be freely shared but ‘practically’ never replicated. By running the data through the algorithm, the checksum is generated and for the data to be authenticated as genuine, the checksum generated locally must match that passed from the remote agent.
The fact that it’s safe to share the checksum, or ‘digest’ as it is more accurately known, is because the algorithm has been designed to only return one possible digest for any given data. In this respect it is unlike a regular checksum, which could easily be duplicated for different data. Furthermore, the algorithm has been developed so that it is ‘practically’ impossible to deduce the data from the value of the digest.
Implementing SHA using MPUs is becoming commonplace; so common that many manufacturers have now implemented its acceleration in hardware, alongside the MPU’s primary core. This allows the algorithm to execute quicker and more securely, while not taking up valuable core resources. It can also be an effective method for lowering the overall system power. SHA is now being made available in embedded processors such as Texas Instruments' Sitara AM35x family and Atmel’s SAMA5 family, both of which implement the ARM Cortex-A class application processor core.
Advanced encryption
As well as the Secure Hash Algorithm, the Advanced Encryption Standard (AES) is now also widely used to encrypt or decrypt data locally, often when over-the-air updates are implemented. Typically this requires at least one key, stored locally in secure non-volatile memory. Algorithms that use the same key for both encryption and decryption, as AES does, are referred to as symmetric key algorithms.
Many MCUs now support AES in order to allow code/data to be stored in external memory devices. Using encryption reduces the risk of attack through the code’s modification in the field. It is also used to authenticate devices when manufacturing is outsourced, as it can prevent cloning or over-manufacture.
Encryption is achieved using a number of specific steps, which can be implemented as functions in an MCU, often stored in firmware and invoked through an API. An example is the AES Bootloader from Atmel, which can run on its 8-bit AVR microcontrollers that have bootloader capabilities and at least 1 kbyte of SRAM. Figure 1 shows the encryption flowchart for the AES Bootloader.
Figure 1: A typical process flow for AES encryption, as performed by Atmel’s Bootloader.
Like SHA, AES acceleration is also now being implemented on a number of MCUs, from 8-bit to 32-bit, such as the AT97SC3204 from Atmel, which features the cryptographic accelerator engine (Figure 2). Another family of devices featuring hardware-accelerated AES decryption/encryption is the LPC18S family from NXP.
Figure 2: The cryptographic engine helps make Atmel’s AT97SC3204 fully compliant with the Trusted Computing Group’s Trusted Platform Module specification (V1.2).
Another important aspect of AES encryption/decryption is key generation; in general, the longer the key the more secure the encrypted information. For this reason, many MCUs that support AES will also integrate a True Random Number Generator, but the FRAM-based MSP430FR5xx and MSP430FR6xx mixed-signal MCU families from Texas Instruments go further than this, to implement a true random number seed that is unique to each device. Another benefit of these devices is their ability to generate a new key for every session and store it in FRAM; the low power operation of FRAM makes it feasible to store a number more frequently in power-constrained devices (such as those powered by battery, as many IoT nodes are expected to be), while minimizing external detection of the process caused by power supply fluctuations that may be apparent to ‘snoopers’ when writing to traditional Flash memory.
Conclusion
The use of both SHA and AES has become relatively common in embedded systems that may have elevated risk of attack, or when outsourcing occurs in their manufacturing process. However, as the IoT brings down traditional barriers, the need for greater authentication in all embedded systems is likely to increase. Security has been repeatedly cited as one of the biggest concerns over the IoT; from safeguarding access to property, to keeping sensitive medical and/or biometric data secure, the need for greater vigilance now pervades all sectors.
The solution is not to reduce connectivity; that would hardly appear to be an option given the nature of the IoT. The solution is to make the connections more robust, by adding measures such as encryption and authentication. For this reason, semiconductor manufacturers will continue to implement greater security features in an increasing number of MCUs.
