Securing microcontroller RTOSes for the Internet of Things
This class of security protocols ensures that machine-to-machine communication is secure. There is a trust hierarchy to ensure that certain information can be relied upon and secure communications can be established.
TLS or the older and depreciated SSL is the most common means of providing communication security for TCP stream sockets or stream connections with in-order data and guaranteed delivery. DTLS is a newer protocol which provides secure delivery of UDP or datagram packets based on TLS. Both protocols assume application-to-application communication.
IPSec or a Virtual Private Network (VPN) uses virtual link security within the TCP stack. It is more difficult to setup but does allow applications to communicate across the link even if the applications do not offer security. In general, this is not used as broadly because of setup difficulty and the fact that many believe that NSA involvement in the algorithm development makes security questionable.
HTTPS is a secure web server access built on top of TLS. This provides secure application access. In the same way SSH provides secure terminal emulation access to remote users.
Secure wireless links ensure that wireless signals cannot be collected and data extracted by anyone with an antenna.
Secure email is used to ensure that data is not transmitted in the clear using email. One option is to encrypt the data before it is sent. A simpler and more universal solution is to provide email services over encrypted links which guarantees that all email data is secure to the server that manages the email.
Secure file transfer with SNMP
SNMPv3 encrypts data while encryption and decryption routines are used to protect data. If all the data is critical, then file encryption can be used albeit with a performance penalty.
Filtering and firewall protection. By providing the ability to filter all packets arriving via the network server, unauthorized access can be stopped. Using advanced filtering, designers can ensure that the correct users get access and that the system is secured against unauthorized access. These filtering rules may need to be setup on a device by device basis. Often this works in conjunction with SSH or SNMP.
Secure Bootloader. Secure boot is an essential part of a secure system (Figure 2). There is always a need to upgrade firmware and the ability to do this in a secure way is very important. This approach can eliminate all factory firmware upgrades and is greatly enhanced using an automatic fall back mechanism. With automatic fallback, the previously secure version will be used if the new (potentially corrupted version) fails to boot – part of a layered security mechanism.
Figure 2: 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 – 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,
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.
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.
All but one of the security scenarios listed above have been discussed. The issue of execution of a program which subverts the security system has not been considered. 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 reflashing 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.
MCU and small MPU systems can be completely locked down using standard IT security protocols, secure boot, and by restricting interpreter use. 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 founder of RoweBots, which offers the Unison RTOS along with complete one-stop product development of Internet of Things systems to OEM developers targeting the Internet of Everything. Kim has 30+ years of experience in systems engineering and holds both an MBA and an MEng.