IoT Security Part 1: Design solutions to IoT security
Although there are many aspects to the IoT, its two fundamental concepts have been successfully introduced to a wide audience; data, and control. The IoT gives both of these concepts greater value and where value exists there will always be people who want to exploit that value, mostly legitimately but, unfortunately, also nefariously. The security risk attached to data and control in the IoT depends on the application; there are low-risk applications such as temperature sensors, and much higher risk applications such as control systems for industrial machinery.
It may seem like data has ‘less’ value than control in this context, but if that control relies on data that can be corrupted or otherwise influenced with criminal intent, it becomes clear that protecting data is of the highest priority. The IoT is now intrinsically linked to the Cloud; Platforms- and Software-as-a-Service (PaaS and SaaS, respectively) live in the Cloud and exist to support the IoT. Getting data into and out of the Cloud is often seen as the weak link in security, but it is a link that can be significantly strengthened using data encryption technologies that are available in even the smallest devices today.
Of the tens of billions of devices expected to form the IoT, many will be so-called ’smart sensors’; low-cost devices designed to feed data into the IoT on a regular but relatively low frequency basis (such as once per minute, for example), capable of operating for many years from a single battery cell. This may seem ambitious, but with the advent of ultra-low power wireless technologies (such as Bluetooth 5), it is increasingly possible to achieve this goal. The challenge comes with adding the right level of security for the application. Standardised wireless protocols targeting the IoT now include levels of security which must be actively imposed in most cases. Each level will undoubtedly require an incremental amount of energy and, therefore, draw a higher level of power from the battery. Selecting the right level of security for the application while remaining within the total system power envelope is a challenge that engineers now face regularly. The ultra-low power microcontrollers (MCUs) that will enable these smart sensors now offer hardware features that help implement security without breaking the power budget, which may offer the right balance of power, performance and security for a range of IoT applications.
The interconnectivity of ‘everything’ is the driving force behind increased and proactive action against threats, to both devices and the data they produce. Protecting a device from a physical threat can be achieved through careful design, such as disabling unused (debug) ports. Protection from cyber (online, or connected) attack is perhaps more difficult; once a network has been compromised (typically through the device with the least amount of security) every device on the network could be at risk.
It isn’t uncommon for networks to assume a level of trust between devices on a network. Once compromised, a network’s devices my openly share data (and even control) with any device on that network. This puts all of the responsibility for maintaining security onto the device tasked with managing connectivity, typically that would be a Gateway; a device that manages communications between local devices (perhaps over a Personal Area Network) and the Wide Area Network connection to the Cloud. While this relieves the need for every device in a network to support WAN connectivity, it assumes a level of trust between PAN devices that may not be supportable.
One method of increasing the level of protection for low-risk devices, such as smart sensors, is to encrypt all data generated by all devices before it is transmitted across the network. In this way, even if the data is intercepted, it would be of little or no use. In addition, encrypting data that is stored locally can also provide protection from attack. Encryption is essentially the process of taking text in its original form (known as plaintext) and encoding it to a form that makes no obvious sense (ciphertext). The encryption of data is now more easily implemented thanks to the hardware and software features being integrated into even low cost, ultra-low power MCUs. Encrypting data ‘at source’ is an effective way of protecting the integrity of data that is passed between devices on a network, or stored in an MCU’s on-chip or attached memory (such as RAM, EEPROM or Flash), a network’s locally attached storage (SSD, HDD) or the Cloud.
Cryptography in the IoT
Encryption and device authentication are components of cryptography, commonly applied using industry standards such as the Advanced Encryption Standard (AES), as used by the U.S Government and, now, worldwide. Other standards include 3DES (referred to as Triple DES, or Data Encryption Algorithm) and RSA. Both AES and 3DES are denoted as symmetric-key algorithm (the same key is used for encryption and decryption), while RSA is asymmetric; it uses a (public) key for encryption and a different (secret) key for decryption. RSA is considered relatively slower than symmetric-key algorithms and as such is less widely used in embedded systems. What all encryption algorithms have in common is their need for at least one key; the solution to encrypting/decrypting data. Without the key, the data is assumed invulnerable to attack and so even if a message is intercepted in a system, it cannot be exploited without also having the key. For this reason, key generation and storage is a very important aspect of the overall security strategy.
Most wireless protocols targeting the IoT now offer some form of authentication that can be used to extend trust to new devices joining a network. For example, Thread uses an elliptic curve variant of J-PAKE (Juggling Password-Authenticated Key Exchange) to authenticate two peers and establish a shared secret based on a passphrase.
The IEEE 802.15.4 standard and related protocols, such as Bluetooth and Thread, support security features based on 128-bit AES encryption. It can be efficiently implemented in both hardware and software, which is perhaps why AES is now widely regarded as the preferred method for adding encryption in embedded systems.
AES supports five main cipher modes using keys of 128, 192 or 256 bits; the mode and length of the key determines the amount of processing required to encrypt/decrypt data. Because of its level of encryption, AES is seen as invulnerable to ‘brute force attacks’; repeated attempts to ‘guess’ the key, and it has been approved for protecting classified information up to Top Secret by the U.S. Government when used with a 256-bit key.
Security is rapidly becoming a ‘must have’ feature in embedded devices, many of which will be part of the IoT. Often battery operated, their viable use may be predicated on requiring no or low maintenance over many years of operation. This puts extra pressure on developers, as implementing encryption in software incurs additional instruction cycles, leading to greater power consumption.
MCU manufacturers understand this and are now implementing dedicated hardware features to support security, such as cryptography coprocessors, AES accelerators and true random number generators. These are features that can be optimised at the transistor level to provide the best possible performance for the lowest possible power. Such features are now available in ultra-low power MCUs, many of which also integrate wireless connectivity, making them very well positioned for the IoT. As these devices are ultimately MCUs, the hardware security features are also supported at the software level and often through a DMA connection, making it even simpler to add cryptography to embedded applications.
AES based cryptography is suitable for wireless communications, data storage and network traffic; any device on the network with access to the ciphertext and shared key can decrypt the data. Manufacturers that have added support for AES in hardware to ultra-low power MCUs include STMicroelectronics, Silicon Labs and Texas Instruments.
For example, the STM32L162xD devices from STMicroelectronics combine an ARM Cortex-M3 core with a range of digital and analog peripherals, along with a 128-bit AES encryption hardware accelerator. The hardware block works almost autonomously thanks to two DMA channels (input and output) that allow it to fetch data for encryption. The encrypted (or decrypted) data is written back to the on-chip memory and the whole process typically takes less than 200 clock cycles (depending on the encryption mode).
The EFM32 family of MCUs from Silicon Labs also features an AES accelerator that operates virtually autonomously, needing little or no CPU bandwidth. The process is initiated by loading the KEY and DATA registers and can be interrupt-driven or through its DMA interface.
For Smart Sensor applications, an even more comprehensive single-chip solution is offered by Texas Instruments in the form of its CC430 family of devices, which integrates TI’s CC1101 sub-1GHz transceiver and its MSP430 MCU technology. It also features a 128-bit AES accelerator module that can encrypt/decrypt 128-bit data using 128-bit keys.
Security is no longer an option in the IoT, the very nature of a virtual network of devices that has no boundaries in the conventional sense makes every device a potential weak point. Ensuring every single device is fully protected against attacks is unfeasible.
What is possible is to ensure that sensitive data is protected from eavesdroppers, so-called Man in the Middle attacks or malicious attacks. By observing the threats and designing accordingly, the IoT will realise its potential.
Farnell is committed to demystifying the IoT, through resources including technical articles, case studies, application examples and a growing number of stock items that will help you develop your IoT application. To find out more about security in the IoT, visit the Farnell IoT Hub , where we will be posting the other articles in this series over the next few months.
IoT Security Part 1: Design solutions to IoT security Date published: 14th June 2017 by Farnell element14