Tuesday, 23 December 2014

Security is Paramount in the Internet of Things

This article was written by my friend Kim Rowe of RoweBots and it has been slightly adapted for this blog. The original can be read at http://www.embedded-know-how.com/article/1776/security-is-of-paramount-in-the-internet-of-things...

Security is of paramount concern for internet connected systems because it now controls all infrastructure, most entertainment, most factories, medical systems, all electronic communications – both corporate and personal, and all financial transactions. As a society, we are completely dependent on the Internet and without reliable Internet services society would not function.

This Internet dependence will only grow as we add more devices and capabilities creating the Internet of Things. Dependence will create significant vulnerabilities if the devices are not secure. Imagine a connected hospital without security for patient data collected in real time or a voting system vulnerable to hackers. How about traffic lights which can easily be changed by criminals? Without security on all devices, everything that surrounds us will be subject to attack and exploitation by terrorists, criminals, power hungry hackers and vandals. Our society, safety and freedom will be at risk.

If pervasive security is in place, our society will have the capabilities to become much safer, with greater freedom and improved safety and security. The tyranny of the masses could be minimized and a society responsive to individual needs could be created – from getting the right traffic lights while eliminating all accidents, through guaranteeing private information remains private and ensuring that medical results are both secure and immediately accessible. Internet of things devices will go into the field now but will remain viable for many years depending on the application. Traffic lights and utility meters are rarely changed. Communications infrastructure is designed to be compatible and operational for twenty years. Electrical transmission systems last thirty years or more. Homes, offices, industrial buildings and other structures are intended to last indefinitely with retrofits in terms of decades.

If new systems are not secure now, they could be a significant risk for the purchaser very quickly as threats grow. To preserve customers investments in their smart devices and protect society, security is an essential requirement for all new devices. The time to protect society is when systems are designed. How secure can small microcontrollers (MCUs) and microprocessors (MPUs) be? Of the 20-50B devices expected to go onto the Internet in the next few years, all can be secure to the point where abuse and misuse is minimal.  Small devices can be more secure than much larger devices for two reasons. First, they are not subject to the same type of threats – threats are much lower level. Second, they often lack the features to dynamically run new programs and the mechanisms that they have for reloading the program either require physical access or can be secured relatively easily. This does not mean that security is very easy, just that it is not as difficult if you properly exploit the features of MCUs and small MPUs for maximum security. The remainder of this article discusses how to protect small devices on the Internet of Things.

Hacking an Embedded Device

 In the case of systems with dynamic loading, modification of executable files and other sophisticated features, security is difficult. Imagine the following scenario:
  • An intruder moves a file onto the machine using email, ftp or some other means.
  • The file is dynamically loaded and when it runs, it corrupts other executable files. It then cleans up and deletes itself.
  • If the virus is new or unknown to the system, it won't be recognized as a virus and will pass into the system and infect it.
Consider another scenario where communication links are not secure or not properly secured. In this case, there is likely a means to read data at a minimum. There might also be a means to inject new data into the data stream which could be used in turn to corrupt the receiving system. A good example of this is loading a non-secured image for a device over the Internet. When the new image is loaded and run, it could take over the system assuming that it has the correct access. In yet another scenario, a device with critical data on it is stolen. Unless the data is encrypted or sits in an encrypted file system, it could be possible to recover the restricted data from the device. This is another scenario to consider.

To ensure system security, often it is best to consider how the device information will be accessed. Typically, great security would require: something you know (password), something you have (debit card or a wearable device), and something that you are (an iris scan). For small devices this is typically overkill, but in cases where very high security is required, it is possible to achieve this through indirect means as long as the various elements are all secure. By securely interacting with a server which in turn securely accesses the device the device interfaces for security can run on larger machines and still be used to secure small devices.

Another critical element for secure systems is layered security and an assumption that someone will gain partial access. A good design practice uses layered security where possible. In this case, the intruder may access some part of the system but not all the system without significant additional work. Examples of this might be using two different firewalls in cascade to secure a server so that vulnerabilities in one are secured by the second firewall. Following a discussion of the processes required and the components or software elements which provide various security features, the use of these components will be discussed further in the context of system security, addressing each of these scenarios.

Securing Small Devices

 The first and most important thing that is required to secure a small system is the desire to make sure the device is impenetrable by all reasonable means. Without the proper motivation and mindset to make the system secure, it most certainly won't be secure. The second thing that is required is an approach that designs in layered security at the design level. After having completed a design, to then think about how best to secure the device is at best impractical. By using the correct approaches and knowing what is needed at design time, and actually using these tools to achieve a secure system is the next step to a secure system.

The third important approach is a well defined process for testing the security of the system after the implementation is completed and the device is properly configured. Through proper configuration followed with good testing approaches, the security of the final system can be assured; provided that the installation is correct. The final step to a secure system is a secure installation. A secure installation requires a rigorous procedure for installation which is strictly followed. Automation of the process is not necessary but is highly desirable as it can eliminate human error. Final in place testing will ensure that the install was correct and the security is operational.

Security Features

To completely lock down an MCU or small MPU at design time, the following security features are required. Some may not be necessary for your system, but in general, all should be considered. Security using standard information technology security solutions are the core security mechanisms for deeply embedded MCU and MPU products. These security protocols are:
•    TLS
•    IPSec / VPN
•    SSH
•    SFTP
•    Secure bootloader and automatic fallback
•    IP Filtering
•    HTTPS
•    SNMP v3
•    Secure wireless links
•    Encryption and decryption
•    DTLS (for UDP only security)
•    Secure email

TLS, IPSec/VPN, HTTPS, Secure wireless links, and DTLS are all means to secure communications links. SFTP provides secure file transfer while SSH provides secure remote access and Secure email provides email services over encrypted links. A secure bootloader with automatic fallback ensures that the system cannot be corrupted. SNMPv3, encrypted data, and an encrypted file system protects data through encryption either locally or as it is about to be transferred to another machine. IP filtering is really a firewall feature, intended to keep out unwanted and uninvited guests. Each section and each item will be discussed after a discussion on system level security.

System Security

Security is only as strong as its weakest link or component. To make a system secure, all the various communication channels, all the file transfer, all the data storage and any means to update anything must be secure. By making all of these things secure, the system becomes secure.

rowebots140826-1Figure 1. Network Security Components highlighted. The diagram shows the Unison OS Internet protocols, highlighting the components that offer the necessary security for that feature in order to build secure MCU and small MPU based devices. The security components require seamless integration across the entire set of protocols to provide high quality security.

The approach whereby the system is secured in layers using components is an excellent approach and the one used in the RoweBots Unison Operating System and most higher level environments. At the core, all operating system components are secure to protect against unauthorized tampering. Operating system security includes an encrypted file system so even if the device is stolen, the data is protected. Small MCUs use memory protection units (MemPU) and MPUs use their memory management units (MMUs) to ensure unauthorized changes to the programs are prohibited. Often flash reading is eliminated by using memory protection features which stop users from accessing the programs and or executing new programs from RAM or non program flash.

Secure boot and re-flash should be part of the core operating system security. By using the mechanisms provided by a secure boot system in conjunction with secure operating system features, all unauthorized tampering with the program can be prevented.  After the basic OS has been secured, attention is turned to the next layer of security – namely secure data link communications protocols. This includes wireless link level security and various military data link security protocols.

The next layer is at the IP level. This includes the following protocols:
•    IPSec (or VPN)
•    IP filtering or firewall capabilities

These protocols securely transfer IP packets over the network. With reference to the OSI model, they all operate in the IP or network layer. IP filtering is used to authenticate and accept and reject connections. IPSec provides a virtual network built on top of the IP network using encrypted packets, and the remaining protocols provide encrypted and/or authenticated communications links for iP packets.

The next layer of security includes the transport, session and presentation layers. This end to end encryption layer includes TLS and DTLS. The remainder of the security protocols are application level protocols and provide the following features:
•    SSH – secure remote access
•    SMTP – secure email
•    SFTP – secure file transfer
•    SNMP v3 – secure device management
•    HTTPS – secure web server access
•    Encryption and decryption provide separately secured data in the environment to prevent unauthorized use.

Using all of these components and layers together, within a secure framework which has been thoroughly tested will ensure that your layered, secure design has optimal protection.

rowebots140826-2Figure 2. Unison Nanokernel Architecture – highlighted with security components. The Unison RTOS offers an additional secure boot feature at the lowest levels which completely locks down the system. Without an interpreter or other means to load a program which would run and then exploit a vulnerability of the system, it becomes extremely difficult for the system to be attacked.

System Security Revisited

Now consider the security of a MCU or MPU with limited resources needing to apply most if not all of these protocols to achieve security. To provide practical examples, this will be considered for the Unison OS, a tiny POSIX RTOS which has these features off the shelf in its tiny footprint. First, using secure communications protocols, all applications talking to the target device can be made secure. This includes phone applications, secure web based access to a tiny web server and more. Tricks like buffer overflow attacks are not possible because Unison is designed to run in minimal resources and must protect against any unreasonable resource use. Secure wireless links can be used. A VPN may be used.

To transfer files into the system SFTP can be used. This guarantees that the data is not corrupted during transmission – very important to secure the system updates. Adding filtering to the front end processing in the TCP server ensures that only authorized requests and updates are processed. This protects the device from intruders and significantly improves security. In addition, SSH can be used to remotely setup the device using a terminal based approach which may be more conducive to a scripted approach compared to a web server. This guarantees that the setup of the device is secure as well. At this point, the data flowing to and from the device is secure. Any changes or setup is secure and authorized applications and users can get access to the device's data and features. What if the device is stolen? To protect against this either encrypt the stored data on the device, keep no local data or use an encrypted file system. This will ensure that the critical data on the device is secured. If the user has the device, and has a password, this is generally regarded as reasonable security. Additional security in terms of fingerprint scans, iris scans, palm prints and other devices can be added for additional security either with the device or connected to a secure access station. If you review the security scenarios that were first discussed, you will see that all but one of the scenarios has been discussed. The issue of execution of a program which subverts the security system has not been considered in depth.

In the case of an MCU and some MPUs, the program is a single linked image that runs from flash memory. In this case, it is not possible to add anything to the system because the entire image runs from flash and if the boot mechanism or re-flashing mechanism is secure, then an intruder can't introduce new code. This is true in the Unison case which makes the system extremely secure. In the case where an interpreter is in the system, the same cannot be said. An interpreted program could go and change the system image with unfettered access on an MCU or MPU unless elaborate security mechanisms are put into place such as use of a memory protection unit or MMU.

Securing MCU and MPU Systems

In summary, MCU and small MPU systems can be completely locked down using standard IT security protocols, secure boot and by restricting interpreter use. Unison benefits from the complete integration of all these components and the attention paid to layers security as part of this integration. Security should not be an afterthought or something layered on top of the operating system – it should be designed into the system and integrated and tested as a unit for true security.

 Kim Rowe is the CEO of RoweBots Limited, the manufacturer of the Unison Operating System and builder of Internet of Things devices.

More information can be found at http://rowebots.com/products/unison_rtos .