RTOS: the foundation and first line of defense for IoT devices

BY WILLIAM E. LAMIE, President
Express Logic
www.expresslogic.com

The Internet of Things (IoT) is fueling explosive growth in connected embedded devices, the vast majority of which are based on 32-bit microprocessors and microcontrollers. Estimates are that, by 2020, there will be some 30 billion such devices connected to the web, controlling most of our vital infrastructure, including the power grid, transportation systems, chemical and manufacturing plants, and more. Recognizing the need to secure sensitive data, developers are scrambling to produce systems that are secure while also keeping up with the demand for rapid development and deployment of devices and systems.

Security, of course, is and should be an integral part of the reliability, safety, connectivity, and performance features of IoT devices and systems. Developing and building these devices on a platform formed by the combination of appropriate 32-bit hardware and a real-time operating system (RTOS) is proving to be the means of choice to bring together all of the features needed in an IoT device.

As 32-bit embedded devices gain in functionality and complexity, they also gain communication requirements and multi-threaded execution. These are all requirements that call for a real-time operating system. Using an RTOS brings in fast, guaranteed real-time performance, often along with a pre-built file system and communication stacks that the developer can simply include in the build image and access via the operating system’s application programming interface (API) without having to build and test them from scratch.

The existence of a standard API and multi-threaded execution means greater flexibility for adding new features while making it easier to migrate applications to new processor environments. It also makes it easier for different development teams to work on different aspects of an application project and bring their work together with confidence. And since many RTOSes are “pre-certified” by regulatory agencies, they can speed the process of certification of the overall project, reducing time-to-market and costs. In short, the use of an RTOS forms the reliable foundation on which to build innovative connected devices with high functionality and solid reliability.

RTOS enhances IoT security
The recent distributed denial of service (DDoS) attack that took down Netflix, Twitter, PayPal, and other major sites was caused by a netbot that looked for consumer devices (web cams, routers, etc.) in which the users had simply neglected to change the factory default user names and passwords. It simply worked from a list of common defaults and was able to penetrate many thousands of devices. A well-designed RTOS can help to ensure that passwords are well implemented and also used properly.

While it is important to provide for password and user names, it’s also critical to protect them from unauthorized access and compromise. This can be done by keeping them in a secure area of memory where they can be protected from other code that might be running on the system. More specifically, this area should not be used for data communications.

Breaching a password can grant access to a device as well as possibly its network, but there are other, more subtle ways that a hacker can gain a measure of control, as well as steal or otherwise compromise data. These involve connectivity mechanisms and communication protocols, as well as the internal memory management controlled by the RTOS.

Security requires awareness of the data flow from one entity to another: knowing who owns the data, who can write to and read from it, and the effects that those reads and writes might have on control. This has led to the development of a number of security communication protocols that have become integrated with today’s advanced RTOSes to protect data from eavesdropping and tampering.

One of the basics is the Transport Layer Security (TLS) protocol, which has succeeded the Secure Sockets Layer (SSL) protocol. TLS works by using a handshake session between client and server in which the client requests identification and is sent a certification that includes the server’s name and its public encryption key. The client sends a list of cipher suites that it supports and the server picks one. The server also sends its public encryption key, which the client uses to encrypt a random number. That number is used by both parties to generate a unique session key. The session key is used for encryption and decryption between the parties for that session only.

It is important to note that TLS does not itself perform encryption and decryption. That is done by separate software crypto engines using such mechanisms as the Advanced Encryption Standard (AES). AES and other crypto engines use the session keys generated via TLS to perform that task. TLS was released in January 1999 to create a standard for private communications. It forms the foundation of other security protocols and strategies and can be built into and used with them, such as with the Simple Mail Protocol (SMTP) or the HTTP Secure (HTTPS) protocol, which sits entirely on top of TLS, and can thus be encrypted itself.

Once the developer had to devote considerable time and effort to getting these different protocols to work together. Today, however, modern RTOSes offer integration with secure TCP/IP stacks that incorporate these protocols and allow developers to select the core protocols they need, such as IPv4, IPv6, UDP, etc., along with the higher-level add-on protocols, such as TLS, SSL, and DTLS (Fig. 1 ). That allows developers to focus on the secure communications strategy needed by the application.

Fig. 1: Modern TCP/IP network stacks come with core network protocols such as IPv4, IPv6, TCP, and UDP, as well as a complete suite of additional, higher-level add-on protocols.

Memory protection secures vital code
There are a number of approaches to protecting vital code from being compromised, and many involve some kind of separation scheme and memory protection. Protected memory resides in a safe area where external communications, or code that is loaded from somewhere else, cannot interfere with the core functionality of the code running the device.

These approaches include RTOSes that do not allow any dynamic loading of code, but instead require an update of a single executable image. They also provide for dynamic loading of threads but maintain certain inviolable areas of memory. These are sometimes referred to as “separation kernels,” in which there is at least one inaccessible area of memory along with several sections connected to networks, peripherals, and dynamically loaded functions.

RTOSes that do provide such memory protection offer levels of granularity — from one thread to an unlimited number — that can be protected and prevented from unintended or unauthorized access. This eliminates a common cause of difficult-to-diagnose program crashes and security breaches. These have opted to provide security while also offering flexibility and upgradeability without having to completely reload the system.

In a real-world implementation, Express Logic’s ThreadX kernel enables one or more application threads to be bundled into a “module” that can be dynamically loaded and executed in place (XiP) on the target (Fig. 2 ). Modules also have a completely separate address space from ThreadX itself. This enables ThreadX to place memory protection (via MPU or MMU) around the module such that accidental access outside the module will not be able to corrupt any other software component.

Fig. 2: In a real-world implementation, ThreadX enables one or more application threads to be bundled into a “module” that can be dynamically loaded and executed in place (XiP) on the target.

Security is a shared responsibility
There is also a growing trend to partner with hardware manufacturers such as ARM, who are building security measures into their processors. The newer versions of the Cortex-M MPUs, for instance, make it possible for enhanced RTOS security features, such as the new X-Ware secure platform from Express Logic, to cooperate with and enhance the overall security features. It should be noted that even the best security features offered by an RTOS represent a platform: a basis on which to build truly secure devices and applications.

The manufacturer OEM and the application developer share levels of responsibility to build on the security features offered by the platform. That allows them to implement things such as a secure boot loader and to use the TLS and DTLS protocols to protect sensitive data transmissions, to utilize the memory partitioning to create safe applications and, oh yes, to install strong password protection.

Conclusion
Today’s RTOSes provide a strong foundation for the construction of highly functional, reliable, safe, and secure devices and applications. And with well-designed security mechanisms, including a secure stack, good memory partitioning, and strong ecosystem and device-level partners, they offer a first line of defense against malicious attack.