A WHITE PAPER FROM WITEKIO
Introduction
Part 1 — Protecting the Communications
Part 2 — Protecting the Resources
Part 3 — Protecting the System
Conclusion
Introduction
The Internet is evolving. With every device that comes online its reach increases, and as those devices — or ’things’ — become more interconnected the Internet expands in not only reach but capability. This is really what the Internet of Things is all about.
With over 25 years of experience, the Internet’s backbone, the IT industry, is well practiced in identifying security risks and implementing effective protection. The same isn’t true of the IoT. Potential and actual security problems related to the IoT are increasing; identifying them isn’t the problem. Effective protection against security threats is, and compounding that problem is the fact that many (if not the majority) of OEMs developing connected products won’t have decades of IT-based security experience to draw from.
Indeed, even the IT industry would find it difficult to implement existing protection in IoT nodes, most of which will be highly embedded and possibly resource-limited devices that may bear little or no resemblance to devices found within an IT infrastructure. Could a connected car be equipped with the same level of protection as a cloud-based server?
Some believe that the sheer volume of connected devices expected to be deployed over the next five years will provide a level of protection against attack — there will simply be too many to target. But, given that many of the ‘things’ in question will be manufactured in very high numbers, and that the wireless footprint of a Wi-Fi connected lightbulb looks exactly the same as, say, a Wi-Fi connected server, then it’s clear that OEMs can’t really afford to be complacent about security.
Of course, the risk is still related to the potential value to the criminal element. In the case of a connected car the potential gain is obvious, but given that even a connected lightbulb could provide access to a home network or cloud services that may hold sensitive personal or financial information, is there really an acceptable level of risk in the IoT?
Part 1 — Protecting the Communications
In this section:
• The challenge for embedded devices
• The Man in the Middle
• Common protocols and how to
secure them
The challenge for embedded devices
Although the IT industry has over two decades of experience in combating malicious and unintended attacks on the Internet’s infrastructure, peripherals and access points, the IoT represents a much greater challenge.
At the enterprise level, where a person is normally present, the use of black/white lists, two-factor authentication (2FA) or password protection are commonplace. In the IoT, where many of the devices will be small and probably headless, these security techniques are hard to implement.
The use of multiple levels of protection is common within the IT world; firewalls, authentication, encryption, intrusion detection and security protocols are all used at the enterprise level to provide protection. The important point here is that these techniques work together; no single technology is relied upon to provide all of the protection. In embedded devices, firewalls are conspicuous by their absence, removing a first line of defence.
In addition, the fact that IoT nodes may have multiple points of access, both wired (such as USB, Ethernet, CAN, or even simple serial ports such as I2C/SPI) and wireless (Bluetooth, ZigBee, WiFi, NFC) further increases the potential for malicious attack.
In effect, IoT nodes are, by design, open to access. They exist to gather, transmit and receive data.
The Man in the Middle
Many IoT devices will employ wireless connectivity using one or several of the (now many) Wireless Personal- and Local-Area Network (WPAN/WLAN) technologies, including WiFi, Bluetooth, ZigBee and Thread. Perhaps the most prevalent of these is WiFi, which supports restricted access in the form password protection. Nevertheless, there seems to be no lack of cases where inadequate password protection has led to compromised network access. This would be bad enough if the WiFi network was simply used for internet access in a home, but today more and more high-value items — including connected cars — are part of that network.
Hacking into devices on an unsecured WiFi network can be achieved using the so-called Man in the Middle attack. Once access to a network is achieved, a WiFi sniffer can be used to analyse the network traffic to identify patterns. This could be a regular exchange between an IoT node either passing data or asking for updates, for example. These types of exchanges are all too frequently carried out using neither encryption or authentication. As such, it is relatively simple to hi-jack the data stream and replace it with instructions that, for example, initiate an over-the-air firmware update to the device, thereby allowing hackers to embed their own code and hence compromise the security of the entire network.
Common protocols and how to secure them
While WiFi may be common at a WLAN level, the most widely deployed WPAN technology must be Bluetooth. Because of its frequency hopping nature, many OEMs may believe it is inherently secure, however it has been shown that it is possible to determine the hopping sequence using low cost hardware and open source software.
The Bluetooth protocol does support authentication and encryption, but it is still up to the developer(s) to implement it correctly. There are four security modes specified; devices operating in Mode 1 are considered to be non-secure, as this mode doesn’t implement any authentication or encryption. Security Mode 4 is an enforced security mode with encrypted key exchange. Under this scheme, a so-called ‘trusted device’ is a paired device with unrestricted access to all services, while ‘untrusted devices’ may require authorisation and/or authentication to access services.
Hackers have also successfully accessed ZigBee devices on home networks, by showing that it is possible to use a network sniffer to grab the network key, transmitted in plain text, when a new device joins a network. The organisations behind these WPAN standards are, of course, constantly developing new security measures, but given that many IoT devices are already in the field and are expected to be there for many years, the security issues that may already exist should not be ignored.
Whatever protocol is used, if access is password-protected, devices on the same network will still need access to that password; it needs to be shared in a secure way. Given that many connected devices will not have the facility for a comprehensive user interface, manually entering a password will be cumbersome at best and, more likely, cost-prohibitive to implement. The solution is to design-in encryption and decryption at the hardware level, using a private master key that can be hardwired in to the device. This may involve including a secure, fused memory that once programmed cannot be changed. It could also be implemented using secure read-only memory like that found in a Trusted Platform Module (as standardised under ISO/IEC 11889).
Using a private master key allows encrypted data, such as a network password, to be stored in unsecure and potentially removable Flash memory without the fear of it being decrypted, unless the master key is used. The process of creating a private master key should also be approached with security in mind; simple methods such as basing it on the Real-Time Clock (RTC) have already been exposed as easily hacked (there have been cases of connected cars being hacked over their WiFi access points, simply because the password was derived from the RTC, which could be reset through power cycling). Security experts will always advocate the use of a true random number generator (RNG) when generating a master key.
Part 2 — Protecting the Resources
In this section:
• Vulnerabilities in embedded systems
• Software Solutions
• Secure Boot
Vulnerabilities in embedded systems
Securing an embedded device from remote attack over a wireless protocol requires careful design and an understanding of the security features embedded within the protocol. Protecting devices from local attacks using standard ports or busses may prove more difficult. Eavesdropping on a CAN bus, which is used extensively in vehicles but also in industrial applications, is relatively simple using low cost hardware. Other interfaces, such as USB, are increasingly common in embedded devices, both for debugging and in-field upgrades. Securing a USB interface has, in theory, become simpler since the introduction of the USB Type-C authentication specification, which defined cryptographic-based authentication for devices with USB Type-C ports.
However, most embedded devices will feature either a standard-based or proprietary interface, often used for test and configuration during production. If access can be gained to such an interface the system becomes compromised. In the case of CAN, it would be possible to intercept bus traffic and replace it with instructions to, for example, initiate a firmware upgrade from a USB port. Clearly, this has significant security implications.
Software Solutions
It is apparent that for any software-defined application such as an embedded or IoT device, gaining access in any way (wired or wireless) could lead to the instigation of a firmware update. As such, this could represent one of the most common forms of attack in connected devices, but software could also be the solution.
Operating systems are increasingly common in embedded devices, there is a wide range of embedded (real-time) operating systems available to embedded developers, but thanks to the increased availability of high-performance 32-bit processors in small and low power formats, many are also now able to run Linux.
While not a real-time operating system in its native form, Linux is very popular. However, its popularity could also represent a threat to developers, as hackers are very familiar with its security shortcomings. To address this threat and provide a higher level of security for Linux-based systems, developers can now employ a security module known as Security-Enhanced Linux, or SELinux. This set of kernel modifications implements a ‘mandatory access control’ architecture, and can be used to limit the access of processes and background tasks in a system with the aim of containing any malicious code that enters the system through one of these processes.
For systems running an embedded (Linux or non Linux-based) operating system, another solution would be to employ a hypervisor. This is technology that effectively divides a hardware platform in to multiple ‘virtual’ platforms, while maintaining strict separation between the host and guest systems. Note that virtualisation and hypervisor technology can now be installed on many microcontrollers (MCUs); the main requirement being the presence of a Memory Management Unit (MMU).
Secure Boot
A common form of attack involves changing the firmware and rebooting the system. Examples of this type of attack can be difficult to detect initially, such as reprogramming the CAN bus to transmit data rather than just receive it. Systems with multiple points of access in the form of hardware or wireless interfaces may be vulnerable to this kind of non-authorised firmware update in the field, but they can still employ effective security features which are now available as hardwired blocks in many embedded processors.
Embedded systems strive to minimise the number of components used and many microcontrollers (MCUs) now offer sufficient on-chip Flash memory to hold all of the application software. In such cases, the MCU vendor will likely include a method for protecting the contents of the Flash memory from tampering and introducing malware after the product is placed in the field. This is normally achieved by blowing security fuses, thereby inhibiting the Flash memory to be read from or written to by an outside agent.
Systems that employ off-chip memory are, potentially, more vulnerable to attack, the solution in this scenario is to employ a method of Secure Boot. One such solution is NXP’s High Assurance Boot (HAB); a software library executed in internal ROM at boot time, which is able to authenticate the software stored in external memory using a digital signature that complies with a Command Sequence File.
Authentication is achieved using cryptography based on the Public Key Infrastructure (PKI) methodology, in which the file is signed offline with a private key, and verified by the processor using a public key. The HAB provided in the i.MX processors from NXP (formerly Freescale Semiconductor) uses a table of public Super Root Keys (SRKs) with corresponding hashes e-fused on the target device. If table verification is successful at boot time, a root of trust is established and the rest of the signature is processed to authenticate the firmware. The fact that hashes of the SRK are e-fused on the device avoids SRK replacement by a malicious SRK and thus always guarantees the root of trust: only the firmware signed with the appropriate private key can be booted on the device.
Part 3 — Protecting the System
In this section:
• Intrusion Detection Systems in the IoT
• Authentication & Encryption
• Hardware Helpers
Intrusion Detection Systems in the IoT
An Intrusion Detection System (IDS) in the IT world works by monitoring, validating and checking activity in a system or on a network. It effectively assumes that all other security measures can be bypassed or defeated, and that any activity could therefore be malicious or unauthorised.
The implementation of an IDS is essentially platform-specific and should be appropriate for the level of assessed risk. There is a lot more diversification in connected devices than in the IT domain, and an IoT device will most likely be much more resource-limited than, say, a server. As a result, employing IDS techniques in the IoT isn’t as simple as buying or licensing a solution from a provider, each device will have to be assessed and have IDS designed in at its core.
This may include countermeasures, such as erasing all or large parts of stored data if an intrusion is detected, or implementing some way of shutting down/closing off accessible ports, including wired buses such as CAN or USB, and wireless interfaces.
The Open Web Application Security Project (OWASP) IoT Project has identified a number of IoT Attack Surface Areas, including device memory, device physical interfaces, device firmware and authentication (for more information, visit owasp.org). The vulnerabilities identified include missing or poorly implemented encryption, and lack of two-factor authentication.
Authentication & Encryption
As the majority of IoT devices will be intended to be sold in large volumes, possibly from multiple retailers, this creates a scenario in which one design may be present in many hundreds or thousands of networks. Reverse-engineering that design would allow attackers to use a single hack to access many networks.
IoT devices will take many forms, consumer items being high on the list. Acquiring an IoT device for reverse-engineering will not be difficult, and once achieved the hack may even be distributed freely around the internet. Protecting against this kind of wide scale attack is potentially best achieved through the use of authentication and encryption. Authentication will require a root of trust to be established between two parts of a system (for example the host MCU and removable storage, or even a sensor) before data are exchanged, for example by using secure boot mechanisms as previously discussed. Encryption will ensure that data are not readable to any unauthorised devices on the network. Unlike many forms of IDS, both authentication and encryption are readily implementable in embedded systems, even resource-constrained devices.
Hardware Helpers
Many manufactures now integrate hardware-based functions to support security, in the form of authentication and encryption. Perhaps first among these is ARM’s TrustZone technology which isolates execution of critical code from possible malware and provides a hardware firewall between CPU (and DMA masters) and the other peripherals, including memory.
With the ARMv8-M architecture, ARM has extended its TrustZone technology to MCUs based on its Cortex-M cores. It effectively divides an application into ‘trusted’ and ‘non-trusted’ worlds. Each world contains software, hardware and data, and the Secure Attribution Unit (SAU) ensures the two remain isolated. Unlike the TrustZone used in ARM’s Application class processors, the transition between trusted and non-trusted worlds in a Cortex-M MCU is hardware based, allowing the device to retain its real-time attributes.
At a system level, TrustZone combined with secure boot and a trusted operating system make up what ARM refers to as a Trusted Execution Environment (TEE). When implemented by ARM’s licensees, the TEE is normally accessed using APIs.
In addition to this, many ARM licensees developing embedded silicon have implemented their own hardware security helper blocks. For example Texas Instruments has developed a hardware based solution, which it calls the Security Accelerator (SA); a hardware engine that provides encryption/decryption and authentication on packet-based protocols. SA also provides hardware for generating public keys and random numbers.
NXP (formerly Freescale Semiconductor) has a similar but not compatible technology called CAAM (Cryptographic Acceleration and Assurance Module), which provides the same kind of functionality.
The CAAM supports the encryption of any kind of secrets using a unique per-device secret key, which can be e-fused in to a device. Once fused, the device’s secret key cannot be read back by software. Any sensitive information can then be encrypted and authenticated using this key, into an opaque structure called ‘Blob’; the information can then be stored safely in any non-secure memory or media (DDR, filesystem, flash). Only the SoC that encrypted the data is able to decrypt the Blob and retrieve the corresponding secrets. This is particularly useful to protect encrypted communications initiated by a two-factor authentication, as described in Part 1 of this document.
These hardware features can be used to deliver high levels of security in resource-limited embedded designs. As such they can be effective when employing countermeasures to many of the security threats identified in this white paper, while consuming minimal core processing cycles.
Conclusion
With billions of new devices coming online within the next decade, the Internet of Things massively increases the attack surface of our networks.
Existing security solutions forged in the IT domain will not necessarily or easily provide the level of security needed for all connected devices. And as more devices become connected, the potential for introducing a device that doesn’t offer adequate security protection becomes an inevitability.
Reports about high-value items being hacked are becoming more frequent, while the reality is that for every report of a hacked car, a thousand smart sensors could have also been quietly compromised. There is a threat that the issue of security could negatively influence the growth of the IoT, with very real economical and even ecological implications.
The IoT isn’t just a trend, it is the direction in which society needs to move in order to secure the future of food and energy production. Mass transport, medical care and education will all rely on connected devices in the near future. Adding security to the devices that form the IoT is not an option. Fortunately, experts in embedded development like Witekio are well placed to ensure your next project includes the kind of security needed to succeed in the IoT.