The Kry10 Secure Platform

The Kry10 Secure Platform is a new Operating System, management service, and hardware (future) aimed directly at Connected Devices. This post focuses on the Operating System and lightly touches on the direction of the services and the hardware.

These devices (sometimes called IoT, although that is a name we dislike) could be one or more of the computers in your car. They could be on a satellite, pumping water to your neighborhood, or running devices in a factory. They could be on construction equipment, running remote fish farms, or conditioning the air in a commercial building.

The common point is that all these devices perform a job that is worth more than the device itself. Accessing the device is either difficult or expensive, and the device (or rather the job it does) is a tempting and valuable target for attackers.

Unlike PCs and Servers, Connected Devices are typically deployed in the field, meaning that they are difficult to access (if you have to roll a truck or work beneath the ground) and most times have little or zero strict physical security. Either way, the attacker isn’t trying to hold the device for ransom, they want to capture your physical plant.

Each layer of the Kry10 Secure Platform is designed to operate in this environment. All the parts assume the minimum amount of trust between them. Everything is restartable and updatable. Where possible, mathematical proofs or correctness are used, as we will see in the main subject of this post - the Kry10 Operating System.

Kry10 Operating System (KOS)

The first major component of the platform is the Kry10 Operating System (KOS). This is a new Operating System built on the formally proven, seL4® Microkernel. The seL4 Microkernel is the right starting place for any system that needs high levels of assurance and is currently in use in military and critical infrastructure use cases.

Even with seL4 as a starting point, it is no small feat to set about building a new Operating System. They are complicated, need to support a diverse set of hardware and software, and are often taken for granted by the layers above. The good news is that by focusing on a smaller set of scenarios, the complexity can be reduced as long as you remain clear about what are your goals and non-goals.

KOS Goals

• Secure: All devices built today, especially those deployed in the real world, must have a deep and fundamental respect for security. This goes beyond network protocols, dives down through the OS, all the way into the hardware. While it is not currently possible to have perfect security, the Kry10 Secure Platform aims to be best in class.
• Robust: While security is about working in the face of purposefully crafted error injection, robustness is about running in a naturally uncertain environment, whether it is because of unexpected data or bugs, KOS is built to recover from errors at all levels of the stack.
• Great Performance: As the seL4 folks say, “Security is no excuse for poor performance”. The same holds true for robustness. We are going out of our way to think about things like cache coherency, thread migration and more. In the world of Connected Devices, performance is another way of saying cost, and we aim to be best in class.
• Ease of Coding: People in gaming/entertainment circles talk about “high production values”. It is not enough for something to be good and/or work, it must also be beautiful. We are embracing that philosophy in our code and tooling. The KOS APIs and tools are designed to be consistent, understandable, and usable.

There are more goals, but those are the biggest and central to all of our thinking.

KOS Non-Goals

It is also important to know your non-goals.

• In-App Assurance: Having a formally proven, high assurance kernel is a big deal. Applications running on KOS, however, are not normally formally proven. Instead, the goal is that if an app is under attack it can: a) be detected and restarted, and b) that attack does not laterally migrate to the next application or driver.
• All App Environments: We have given the application environments a lot of thought and are not going to support all the possibilities. For example, we don’t intend to support Python, Node, or other VMs by default unless they can meet our robustness requirements. If you want those environments, then please give the BEAM a good look first, then we can talk.
• “M” Class devices: There is a whole class of devices that run on batteries and communicate occasional or one-way data. Simple sensors and other devices that run on ARM “M” class CPUs are not a target for KOS. We depend on seL4, and seL4 requires hardware support (an MMU) to enforce the policies. We have no plans to run on those devices.
• Linux Support: Linux is the most common OS used on devices and it has lots of drivers and community support. The monolithic kernel design doesn’t meet our requirements, but if you need to use Linux, we highly recommend you look at the Nerves project.

The Operating System

Once you understand your goals and non-goals, designing and building the project can begin. We are hard at work building a usable Operating System that enforces strong application isolation via seL4 policies, while maintaining runtime flexibility, maintenance, and performance.

One way to think about KOS is that we use the seL4 policy enforcement to set up application secure domains that effectively have each app and/or driver running on its own virtual computer. We don’t have to do full OS-style virtualization to achieve this as we can use the formally proven seL4 policy enforcement. This gives us both very good isolation and performance at the same time.

System Layers

KOS effectively runs as three layers. At the bottom is the unmodified seL4 Microkernel. This provides formally proven policy enforcement of hardware resources, scheduling, thread contexts and more.

The middle layer is a set of KOS services that manage the policies that are enforced by seL4 and provides other services such as inter-application communications, virtualized networking, storage and more.

The third layer are the optional applications and drivers. These are the applications that make the machine do the job it does. Some of these applications will be provided by Kry10, but most will be written by the device makers. See the Application Environments section below.

Application Environments

There are two main, first-class environments for applications written for the Kry10 Operating System. The first is direct APIs for drivers or highly performance sensitive applications written in C or Rust. There are a robust set of kos_* APIs that provide low level access to hardware and system services.

The above example gives an introductory feel for the low-level APIs. It is subject to change before general availability.

The second, and perhaps main application environment is the Erlang BEAM. We are big believers in the robustness provided by OTP Supervision trees and fully endorse it as the right model for applications that need to keep working in the face of adversity. BEAM applications naturally scale across cores with a natural concurrency programming model and know how to restart portions of an app when errors occur.

There are many resources available to learn and use Elixir, Erlang and other BEAM languages. Many of these resources are oriented toward servers, but subjects about OTP supervision and high-availability are why it works so well for connected devices.

There are other application environments we are looking at for first-class support, but for now, the main two are direct APIs and the BEAM.

Management Service

As much as we enjoy talking about Operating Systems, we always have to come back to the job that a device performs.

Connected Devices are deployed in fleets ranging from 1 to millions of units and perform jobs that are more valuable than the devices themselves. The Kry10 Management Service is designed for the professional deployment manager and provides tools to manage part of or all of a fleet, monitor health, watch for attack patterns, collect data, and more.

There will be more to say about the Management Service, and developer tools as well, as we approach general availability.

Hardware

Security is no longer a question of good software or hardware design. They must be designed together, with knowledge of each other.

This lesson was taught to the world by the Meltdown and Spectre attacks in 2018. While both of these are hardware attacks in their nature, the best solutions require action from both the hardware and OS designers.

This is the new frontier in security and requires communication and cooperation between hardware and software vendors. While we are not saying anything specific about our work in this space at this time, we are well aware of this reality and working with our partners on really interesting solutions.

Progress

There is a lot going on in the above image. Amongst other things, seL4 brings up hardware in a qemu VM, KOS then boots and starts the core system services as isolated applications, inter-app communications are established, the Erlang BEAM (an unmodified OTP 23.1) is started in its own secure domain, and Elixir is in interactive mode responding to commands. There is quite a bit more than that, as anyone who has had to write their own threading library from scratch knows.

Progress is moving ahead at speed and we are now working closely with a few early partners on real-world devices. General Availability will still be a while as the tools and other components are still coming together. If you have a project that is a good fit and you understand that building on a platform that is also coming together requires cooperation and can be a lot of “fun”, then please let us know.