Security Within the Real-Time Operating System


by Kim Rowe

This article is the second in a two-part series. Read the first part here.

The security provisions discussed so far are aimed at access and connection. We must still attend to other deep security measures. For example, what if an unauthorized user were to get through anyway? Or what if code used for a field upgrade was somehow infected with malware? This speaks to safeguards that are actually built into the real-time operating system (RTOS), implementing a layered approach. To put it in the metaphor of a castle, “if the enemy breaches the wall, defend the keep.”

While the secure protocols can prevent unauthorized access and theft of data, a secure boot mechanism is required to prevent any unauthorized code from actually being booted and run. Any firmware running on such a system or uploaded to such a system must be signed—encrypted—so that it can be recognized by the system to use the decryption key. The decryption key is local so it does not have to be transferred and run the risk of being intercepted. Protecting the stored keys from unauthorized access can be further aided by hiding them with on-board crypto hardware. It helps immensely with time and cost to have these protocols included for integration with the final RTOS image (Figure 3).

Figure 3: 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.

Another essential element for a secure RTOS is that its application code should be executed from flash and not from RAM. RAM-based systems allow dynamic loading, which means software functions in addition to the existing code can be loaded and run. If one of those happens to be malware, it can mean disaster. Software in flash is a single image and must be partiallyreloaded—“reflashed”—in order to be updated or altered. That means a hacker would have to replace a portion of existing code image in addition to his malware using the stored key in order to embed his code into the code to be run and have the ability to reflash. In such a system all code executes from flash, but does use some RAM to store variables, etc., making it much harder to compromise.

A firewall is another key component of operational security and the operation it performs is filtering. Filtering allows the operator to eliminate connections and messages from the system based on specific ports (or protocols) and specific IP addresses or countries, and allow only specific IP addresses or messages on a subset or subsets of ports.   With effective filtering, unwanted messages can be eliminated and the desirable messages can be permitted making the system more secure.

The reason that filtering works effectively is that hackers will try and break into systems using the normal responses of the system in an unexpected way.   By providing strings that are too long to a web server (buffer overrun error) or by using a service that the developers or administrators failed to disable, information may be extracted from the system which leads to more sophisticated attacks until entry is gained.  Ensuring filtering is present as an intrinsic function of the operating system and that it is properly configured is an essential part of security and the first line of defense against hackers.

There are, of course, other aspects to security, some of them more in the physical realm, such as keeping devices in locked, secure rooms or containers. If there is an intruder, that person will have a limited time in such an environment to gain access, so a number of restricted access mechanisms can be important. An intruder will need to enter or present something to gain access at all and then on another level to decrypt data, which should always be stored in encrypted form.

Beyond a secure location, access can be set up to depend on three things: something you know, something you have and something you are. The first is obviously a password and perhaps multiple passwords for different levels of access. What you have can be a card with an RFID chip that the system recognizes to grant access. What you are can be a number of things such as a fingerprint, which is popular with small devices because fingerprint readers based on DSP chips have become very compact an inexpensive. Others are retinal scan and face recognition, which while effective, involve more complexity and expense.

For all this, it is important to accept that security is never absolute. We have all seen examples in the news of massive security breaches, both intentional and accidental. There are doubtless other examples whose severity we can only speculate about, that we will probably never hear of. No matter how carefully security has been set up, it is imperative to also implement measures that can assess, limit and mitigate the effects of such a failure when and if it does occur.

One such measure is the Security Impact Analysis (SIA) to examine how changes can be made to the system’s security to better prevent attacks and their damaging effects and develop better security strategies. It is also important to consider the effects of a breach on users and customers by means of a Privacy Impact Analysis (PIA). A good knowledge of the effects and possible extent of any breaches that may occur can aid in developing strategies for recovery. Security is a multifaceted and vital technology for connected IoT devices and their server systems. It must begin at the first level of design and build consistently throughout development. Having the right integrated platform to build upon will greatly enhance the quality of the final design as well as time to market and user confidence.

Kim Rowe is the CEO and founder of RoweBots.

 

Leave a Reply

IoT Innovator

IoT Innovator