Internet of Things (IoT) is meant to bring seamless communication into the embedded device world. In the pre-IoT, era we used the term “connected devices” to describe the trend to link up embedded devices, so that the vision of intelligent fridges reporting that a particular food has been nearly consumed goes back to the last millennium. But, IoT has the clear mission to shift the usage of embedded devices to the next level of efficiency. By enabling seamless communication between embedded devices, we can capture more data about the ongoing process and are able to influence the process for optimization. The realization of seamless connectivity is favored by the broad availability of Ethernet and wireless communication. Even real-time requirements are covered by specific industrial Ethernet protocols, which are fast enough to drive high frequency control systems with a small amount of jitter.

With this seamless communication, security of IoT devices becomes a challenge. A communication channel is always a potential for vulnerability and can even compromise the safety of the system because of an unauthorized modification of the IoT device. For example, a security attack to a home automation system, which provides boiling water instead of tempered water, will definitely evolve to a safety problem for the user.

Security concepts shall ensure, that the system is not harmed/attacked by its environment and must be integral to the device’s functionality. But when adopting IT security concepts to IoT devices, some important differences must be taken into account:

• An IoT device is usually build for a dedicated task and its resources are optimized. That is, CPU power, RAM and storage is limited to the functionality it shall perform
• While IT security concepts target data confidentiality, IoT security is more about correct functionality and availability. For example IT administrators don’t worry that much if a mail system is unavailable for a short time, but data theft is not acceptable. Status data of an industrial automation device may not be critical, but improper function of the automation device may lead to tremendous money loss or evolve to a safety problem
• An IoT device may have passed a safety or security certification for its specific configuration. An update to such a device may require a recertification
• Remote access to a critical device may be prohibited because of safety concerns. That is, updates can only be applied at a specific time and location
• In some markets the expected product life-cycle is up to 30 years. Can third party software vendors offer security updates for such a long time

Tried and trusted security mechanisms like virus scanners, firewalls, packet filter, authentication, encryption etc. may not be applicable because of the above mentioned limitations of an IoT device. With these challenges in mind, we need to look for a more holistic security solution, which can be tailored for device specific needs.

In the functional safety domain the Separation Kernel is a well know safety and security by design concept, which bears safety and security in its architectural concept. In a nutshell, a separation kernel allows spatial and temporal separation between applications, by providing separated partitions for application execution and a concept for sharing CPU-time. A thoroughly separated application concept by using a separation kernel guarantees non-interference, so that errors cannot propagate from one application to another.

From a safety perspective this partitioning mechanism is used to isolate applications of different criticality (safety classes) so that risk reduction can be applied for each application/partition independently. The application isolation capabilities are also suitable for system security by isolating critical applications/data from non-critical applications/data and allowing only controlled information flow between isolated partitions. Controlled information flow is realized by:

• A white list policy for inter-partition-communication. That is, communication is generally prohibited and needs to be allowed explicitly, defined at system configuration, not at runtime.
• Using cryptography before exchanging data between partitions and with the outside world
• Applying a security policy for data communication so that communication is monitored and controlled

The next posts will use the PikeOS Separation Kernel as an example implementation and explains how safety and security aspects are covered by the separation kernel architecture.

More information also at www.sysgo.com/pikeos