Securing microcontroller RTOSes for the Internet of Things
Our society is extremely dependent on the Internet to conduct a majority of our business, for a large percentage of our communications and financial transactions as well as entertainment. Internet dependence will only grow as more and more devices are added to the Internet of Things (IoT). Dependence will create significant vulnerabilities if these devices are not secure. Without security on every device, those devices will be subject to attack and failure.
Many IoT devices that are activated now will remain in service for many years, depending on the application. For example, utility meters are rarely changed. Communications infrastructure is designed to be compatible and operational for fifty 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 these new systems are not secure now, they could be disposable very quickly as threats grow.
To preserve user investments in smart devices and protect them from intrusion, security is an essential requirement for all new devices. Of the 50 billion IoT devices expected to go onto the Internet in the next few years, a huge percentage of them will be microcontrollers or small microprocessors with limited resources. Fortunately, these small devices can be more secure than much larger devices because they are more easily protected and are not subject to the same type of threats. This does not mean that security is easy, just that it is not as difficult if you properly exploit the features of MCUs and small MPUs. The remainder of this article discusses how to protect small devices on the Internet of Things.
Necessary IoT security features
To completely lock down an MCU or small MPU the following security features are generally required, although some may not be necessary for every system. Security using standard information technology security solutions are the core security mechanisms for deeply embedded MCU and MPU products. These security protocols include:
- IPSec / VPN
- Secure bootloader and automatic fallback
- SNMP v3
- Secure wireless links
- Encryption and decryption
- Encrypted file system
- 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 file system protect data through encryption either locally or as it is about to be transferred to another machine. 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.
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 as well. In the case of systems with dynamic loading, modification of executable files and other 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 review of the components or software elements (Figure 1) which provide various security features, the use of these components will be discussed, addressing each of the scenarios outlined above.
Figure 1: Internet protocol components that an IoT-ready operating system should include relating to security that will allow seamless integration across the entire set of protocols to provide high quality security.