By 2030, the number of  connected devices in the world is expected to reach 24 billion. This statistic includes a multitude of household systems and accessories: smart watches, fitness bands, speakers with intellectual voice assistants, and all the devices they control. It also covers smart ATMs, POS terminals, video surveillance cameras and the like. These are all devices users are accustomed to trusting with their sensitive data but are not quite able to control the security of. At the same time, internet-of-things (IoT) devices are becoming targets in a growing number of attacks. And although vendors try not to emphasize it, the IoT security problem gets more and more relevant — especially for ecosystems of several connected devices.

For example, back in 2020, Check Point researchers experimented with an attack on a network through a smart lightbulb. They succeeded in loading tweaked firmware into a smart lightbulb and using it to install malware on a device controlling the illumination system. From there, they penetrated the local network. The vulnerability was promptly closed, but what are the guarantees that a similar trick can’t be pulled off using other IoT security loopholes?

Another example — a situation involving a Korean KeyWe smart-locks vulnerability — looks even worse. In addition to key generation process flaws, researchers discovered some fundamental design problems. These made it fairly easy for attackers to intercept and decrypt the locks’ passwords. Moreover, it was found that it was impossible to update the firmware with a security patch — the vulnerability could only be patched in new locks that are free of the mentioned design flaw.

The latter example shows that IoT security gaps can originate at the system design level. To avoid such problems, a number of vendors have in recent years turned toward microkernel-based operating systems. In microkernel architecture, the kernel contains several times less code than kernel of a traditional system, and performs only strictly necessary functions — which makes it more reliable and fault-tolerant.

Microkernel OSs’ popularity outstripping that of Windows and Android

If you ask desktop computer users to name the most popular operating system they know of, you’re sure to hear Windows as the answer. Indeed, its share of the global OS market is 72% — if counted by the number of computers with Windows onboard. But very few users ever think of what’s going on a notch deeper: at the microchip and microcontroller firmware level. There, the most widespread operating system is MINIX, based on microkernel architecture. It’s the OS that comes with Intel ME 11 firmware. Today it’s present in all desktops and laptops equipped with Intel CPUs, which makes two thirds of the х86 CPU market.

There’s a similar picture in the mobile, portable and embedded devices market. Here the favorite is Android. However, again, if we probe deeper, microkernel OSs are no less common in that market, although they remain in the background. One of the oldest microkernel architecture implementations in the mobile market is QNX. This OS came about in 1980s in critical industrial machines, later being used in naval radar stations. Its more modern version, QNX Neutrino, worked in BlackBerry smartphones and in Cisco routers and is now to be found in firmware of hundreds of millions of motor vehicles.

Modern vehicle firmware interface proposed in 2017

Let’s not forget other devices with microkernel firmware; for example, there’s L4-kernel-family-based systems, including Qualcomm modems and automotive systems based on OKL4, whose popularity peaked in 2012.

MINIX and L4 are certainly not the most relevant applications out there. Some might even call them vintage. But the evolution of microkernel OSs didn’t stop there: their development was continued by a number of modern smart ecosystem vendors:

• A microkernel OS code-named Horizon forms the backbone of Nintendo Switch game consoles. The public has limited information about the OS itself as it’s a proprietary system.
• In January 2023, 9to5google journalists discovered that the all-new Google Nest speaker would most likely ship with Fuchsia ― an OS with the Zircon microkernel at its core.
• In November 2022, Huawei announced that 320 million of its devices are equipped with HarmonyOS ― a HongMeng-kernel-based microkernel operating system for wearable devices and IoT. By the end of 2022, devices equipped with HarmonyOS mace up 2% of total global sales of smartphones. And in April 2023, the new version HarmonyOS 3.1 was launched. According to the developers, they’ve come a long way in optimizing the system.

Why are vendors so active in this field? On the one hand, it’s because of the IoT market’s development. On the other, it’s because of a crisis of confidence in traditional superimposed protection that’s not effective enough in the IoT world.

Things helping microkernel firmware vendors protect IoT systems

As we’ve seen from the abovementioned smart lightbulb hijacking case, IoT ecosystems are often based on multiple interconnected microcontrollers and sensors. Attackers tend to specifically target the unprotected end devices to use them as an entry point to later take control over the whole system through escalation of privileges. Equipping each little device with sophisticated protection mechanisms is economically unviable. The situation gives rise to two fundamental problems:

• We all want to trust the system’s in-built protection. In IoTs, we’re dealing with multiple small elements that cannot be trusted. There are two ways to approach this problem: either try to make each one as protected as possible, or begin with recognizing their limitations and engineer the system to still be secure — even with such elements onboard.
• Control of interactions. In a big system, normally no elements operate in vacuum: they “communicate” among themselves and often have privileges to perform certain actions upon each other. In a system where we can’t trust all the elements, these interactions and privileges should be limited and monitored with some means of control.

This is how these problems can be addressed with microkernel OSs:

1. Microkernel OSs distinguish between trusted and untrusted components. Their architecture is built around multiple intercommunicating isolated components, which can be conveniently classified as untrusted or trusted. The kernel is among the trusted components: it performs only the most necessary functions and contains as few lines of code as possible; and all the drivers, file systems and the like are removed to separate components outside the kernel. This allows limiting the system elements whose code we are forced to trust to a necessary and sufficient minimum.
   
   The fewer lines of trusted code the system contains the better, for it’s both simpler and faster to check such code for errors. This is the reason why vendors try to make the microkernel as small as they possibly can: it simplifies validation of trust (more on that later).
2. Microkernel OSs isolate most privileged components and operate them in user mode. In microkernel OSs, the kernel is responsible for isolation of components: each one resides within its own address space. The microkernel provides a mechanism for exchanging messages among components, plans out the flows, and controls memory, timers, and interruptions.
   
   The trusted and untrusted components operated in user mode have just as many privileges as needed for them to perform their functions.
3. Microkernel OSs feature extra capabilities and tools for interaction control. In a microkernel OS, any action equates to the sending of a message (communication). As mentioned earlier, the microkernel controls the key messaging mechanism. Apart from that, microkernel OSs often employ the “object capabilities” mechanism, which allows, among other things, to control the establishing of new communication channels.

The only thing all these mechanisms tend to lack is trust verification options. Some components just have to be trusted, it’s true; but how about “try before you trust”? How do we migrate from “trusted” to “trustworthy”?

There are different ways to make sure an element is trustworthy: tests, different analysis methods, formal specification and verification. All these methods allow implementing verifiable security in which we base our confidence not on the vendor’s reputation but on the results of reproducible verification. This lies at the heart of many recognized security models, for example MILS, or security assessment standards and criteria such as the “common criteria”. We predict that these methods and models will be used more and more.

In the near future, new generations of microkernel OSs will help achieve verifiable security and Cyber Immunity

Following a long-term study of best protection practices, we’ve used verifiable security principles to develop our own Cyber Immune approach, which we’re going to use for building inherently secure IT systems. Cyber Immunity is an implementation of the Secure by Design approach, where information security is in focus at each and every development stage.

In Cyber Immune systems, all interactions are typified and verified: in particular, a special monitor is in control of all interprocess communications. This module is capable of introspecting all data exchanged among the processes and can use them when making security-related decisions. Trust is validated through tests, static and dynamic analysis, fuzzing, pentesting, and formal methods.

The microkernel-based KasperskyOS is the first operating system that supports this approach, acting as a platform for creation of Cyber Immune products. But in general the methodology combines the best security principles around and doesn’t depend much on which implementation tools are used. Therefore, we expect these principles to find their way into other microkernel device firmware applications.