Addressing IoT issues

While the ability to safeguard our possessions and even our children using tracking apps are all very welcome, other aspects of security, or more particularly the security of the IoT, have come into sharp focus in the many recent news reports. Examples include taking control of vehicles by hacking their controls and spying on children via their connected toys. Whether malicious or with criminal intent, clearly the design of IoT devices needs to address these security concerns.

Security needs to be designed into devices and systems, which may sometimes be seen as inconvenient because it adds to development timescales and component cost and complexity. On the other hand, vendors will not want to suffer the brand damage that can result from a high profile hack and so should be incentivised to protect their products from security vulnerabilities.

Understanding what needs protecting is key, but broadly security concerns can be grouped into one of three categories - secure communications, device security and software application security.

Addressing these security categories will take care of the common pitfalls that developers encounter. What needs to be appreciated here is that most security loopholes are exploited by people who have a detailed knowledge of how to use the various technologies involved. So hardware and software design engineers cannot afford to be complacent - they must assume that potential hackers are at least as clever as they are.

Encrypted communications
The IoT is all about communications, so securing the information that is transmitted over either a wired or wireless network is essential. Data transmitted over the air is especially susceptible to eavesdropping, as it doesn’t require physical access to cables. Encrypting this data using a strong algorithm, such as the Advanced Encryption Standard (AES) cipher used by most wireless IoT protocols, will certainly provide a baseline level of protection.

As AES encryption is built into the protocol stacks for wireless communication standards such as ZigBee, Bluetooth Smart and Thread, it may not be necessary for the designer to understand the finer details of how it works. However, knowing that the basic AES cipher block size is 16-bytes helps explain why a cipher block mode, such as counter mode, will improve security for messages longer than 16 bytes by changing the cipher for each block. Going beyond this, to ensure a message isn’t tampered with, many protocols use an authenticated cipher block mode that provides a ‘fingerprint’ that is unique to the originator’s key. Bluetooth Smart and IEEE-802.15.4 protocols like ZigBee and Thread all use some form of the counter cipher block mode for encryption and CBC-MAC (Cipher Block Chaining Message Authentication Code) for authentication.

For communications between IoT devices and the Cloud, establishing a secure connection using a cryptographic protocol for key exchange is also strongly advised.

Physical flash security
Aside from communications between network nodes, it is also necessary to protect against someone physically connecting to the pins of an IC and either reading out the data or code it contains or intercepting data being transmitted between the ICs within an IoT device. For a microcontroller (MCU) with embedded flash memory, there is a three-step process that should be followed:

1. Lock the entire flash memory – This is implemented within the MCU and typically requires a key sequence to be written to a register to unlock the memory.
2. Disable normal debug operation – During development it is inevitably necessary to make programming changes using the MCU’s debug interface. Once development is complete, it is vital to secure this interface before the design enters production. While this may present problems in the later diagnosis of any faulty products returned by customers there are other means that can be used to overcome this issue.
3. Use a secure bootloader to upload authenticated firmware - This is particularly vital to ensure only legitimate in-field firmware updates can be applied to an IoT device.

These measures should ensure that the firmware on a device is secure - indeed, when implemented correctly, even the MCU manufacturer will not be able to read the flash memory contents. Nevertheless, physical security is not as secure as encrypted code since it is theoretically possible that someone with expert knowledge and access to expensive equipment could still read the flash memory contents.

Software application security
Application layer security is particularly relevant where more than one party is involved in developing or providing software for a project, and this entails the secure partitioning of software running on the same platform. For example, a designer working on the code for a particular application might use a software development environment that includes the communication stack for a specific protocol. If the stack provider delivers source code or a linker library, then this assembly code is exposed to the application developer.

To avoid such problems, the code provided by the development environment should be secured so that it is not possible for an untrusted application developer to access or reverse engineer the secured assembly code. ARM’s uVisor supervisory kernel, which is part of its mbed operating system (OS), creates isolated security domains on M-series ARM cores that have a Memory Protection Unit (MPU). This can help defend applications against security exploits and other malware.

Software application security
Application layer security is particularly relevant where more than one party is involved in developing or providing software for a project, and this entails the secure partitioning of software running on the same platform. For example, a designer working on the code for a particular application might use a software development environment that includes the communication stack for a specific protocol. If the stack provider delivers source code or a linker library, then this assembly code is exposed to the application developer.

To avoid such problems, the code provided by the development environment should be secured so that it is not possible for an untrusted application developer to access or reverse engineer the secured assembly code. ARM’s uVisor supervisory kernel, which is part of its mbed operating system (OS), creates isolated security domains on M-series ARM cores that have a Memory Protection Unit (MPU). This can help defend applications against security exploits and other malware.

An obvious but overlooked pitfall
We have all heard this before - ‘avoid default passwords’. IoT devices, like many other internet connected devices such as routers, should employ password protection. When a hacker encounters a password interface, he or she will start by trying classic default passwords, such as ‘password’, ‘12345’, ‘admin’, etc. Should one of these, or any other password that might be discovered, prove successful, this could expose many other devices where the same password was reused.

It is important therefore, that an IoT device developer finds a way to ensure that the user is forced to change from the factory default password to one that is more secure and, ideally, one that requires changing at periodic intervals. From a security point of view, a default, static password should be considered on a par with no password at all.

Summary
To inspire consumer and commercial user confidence in the Internet of Things and to ensure successful, broad deployment of the IoT, it is vital that the industry as a whole pays adequate attention to the security concerns that are already widely evident. This requires action on multiple fronts, from industry standards groups such as those championing wireless protocols, through to the designers and manufacturers of embedded microcontrollers, and on to the IoT device developers themselves.

Everyone in the industry must invest the time, effort and resources necessary to ensure that end-devices are not vulnerable to hacking or data theft. This requires protocols that provide secure connections with encrypted data and authentication, MCUs and memory chips that can be locked against unauthorised access, and software that is not exposed to other software running on the same platform.

Ultimately, IoT device developers are responsible for the security of their products, and their reputation will suffer most if they get it wrong. However, the few simple precautions outlined here should help ensure that most connected device and system designs can be readily secured.