Securing microcontroller RTOSes for the Internet of Things - Embedded.com

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:

  • TLS
  • IPSec / VPN
  • SSH
  • SFTP
  • Secure bootloader and automatic fallback
  • Filtering
  • HTTPS
  • 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.

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 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:

  1. An intruder moves a file onto the machine using email, ftp or some other means.
  2. The file is dynamically loaded and when it runs, it corrupts other executable files. It then cleans up and deletes itself.
  3. 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. Communication Security
This class of security protocolsensures that machine-to-machine communication is secure. There is atrust hierarchy to ensure that certain information can be relied uponand secure communications can be established.

TLS or the olderand depreciated SSL is the most common means of providing communicationsecurity for TCP stream sockets or stream connections with in-order dataand guaranteed delivery. DTLS is a newer protocol which provides securedelivery of UDP or datagram packets based on TLS. Both protocols assumeapplication-to-application communication.

IPSec or a VirtualPrivate Network (VPN) uses virtual link security within the TCPstack. It is more difficult to setup but does allow applications tocommunicate across the link even if the applications do not offersecurity. In general, this is not used as broadly because of setupdifficulty and the fact that many believe that NSA involvement in thealgorithm development makes security questionable.

HTTPS is asecure web server access built on top of TLS. This provides secureapplication access. In the same way SSH provides secure terminalemulation access to remote users.

Secure wireless links ensure that wireless signals cannot be collected and data extracted by anyone with an antenna.

Secureemail is used to ensure that data is not transmitted in the clear usingemail. One option is to encrypt the data before it is sent. A simplerand more universal solution is to provide email services over encryptedlinks which guarantees that all email data is secure to the server thatmanages the email.

Secure file transfer with SNMP
SNMPv3encrypts data while encryption and decryption routines are used toprotect data. If all the data is critical, then file encryption can beused albeit with a performance penalty.

Filtering and firewall protection.  Byproviding the ability to filter all packets arriving via the networkserver, unauthorized access can be stopped. Using advanced filtering,designers can ensure that the correct users get access and that thesystem is secured against unauthorized access. These filtering rules mayneed to be setup on a device by device basis. Often this works inconjunction with SSH or SNMP.

Secure Bootloader. Secure boot is an essential part of a secure system (Figure 2 ). Thereis always a need to upgrade firmware and the ability to do this in asecure way is very important. This approach can eliminate all factoryfirmware upgrades and is greatly enhanced using an automatic fall backmechanism. With automatic fallback, the previously secure version willbe used if the new (potentially corrupted version) fails to boot – partof a layered security mechanism.

Figure2: The Unison RTOS offers an additional secure boot feature at thelowest levels which completely locks down the system. Without aninterpreter or other means to load a program which would run and thenexploit a vulnerability of the system, it becomes extremely difficultfor the system to be attacked.

System security revisited
Nowconsider the security of a MCU or MPU with limited resources needing toapply most if not all of these protocols to achieve security. Toprovide practical examples, this will be considered for the Unison OS, atiny POSIX RTOS which has these features off the shelf in its tinyfootprint.

First, using secure communications protocols, allapplications talking to the target device can be made secure. Thisincludes phone applications, secure web based access to a tiny webserver and more. Tricks like buffer overflow attacks are not possiblebecause Unison is designed to run in minimal resources and must protectagainst any unreasonable resource use. Secure wireless links can beused. A VPN may be used.

To transfer files into the system SFTPcan be used. This guarantees that the data is not corrupted duringtransmission – important to secure the system updates.

Addingfiltering to the front end processing in the TCP server ensures thatonly authorized requests and updates are processed. This protects thedevice from intruders and significantly improves security.
In addition, SSH can be used to remotely setup the device using a terminal based approach which, 
compared to a web server, may be more conducive to a scripted approach. This guarantees that the setup of the device is secure as well.

Atthis point, the data flowing to and from the device is secure. Anychanges or setup is secure and authorized applications and users can getaccess to the device's data and features.

What if the device isstolen? To protect against this either encrypt the stored data on thedevice, keep no local data or use an encrypted file system. This willensure that the critical data on the device is secured.

If theuser has the device, and has a password, this is generally regarded asreasonable security. Additional security in terms of fingerprint scans,iris scans, palm prints and other devices can be added for additionalsecurity either with the device or connected to a secure access station.

Allbut one of the security scenarios listed above have been discussed. Theissue of execution of a program which subverts the security system hasnot been considered. In the case of an MCU and some MPUs, the program isa single linked image that runs from flash memory. In this case, it isnot possible to add anything to the system because the entire image runsfrom flash and if the boot mechanism or reflashing mechanism is secure,then an intruder can't introduce new code. This is true in the Unisoncase which makes the system extremely secure.

In the case wherean interpreter is in the system, the same cannot be said. An interpretedprogram could go and change the system image with unfettered access onan MCU or MPU unless elaborate security mechanisms are put into placesuch as use of a memory protection unit or MMU.

Conclusion
MCUand small MPU systems can be completely locked down using standard ITsecurity protocols, secure boot, and by restricting interpreter use.Security should not be an afterthought or something layered on top ofthe operating system – it should be designed into the system andintegrated and tested as a unit for true security.

Kim Rowe is the founder of RoweBots, which offers the Unison RTOS along with complete one-stop product development of Internet of Thingssystems to OEM developers targeting the Internet of Everything. Kim has30+ years of experience in systems engineering and holds both an MBA andan MEng.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.