After the publication of our article on car hacking we received a number of questions regarding KasperskyOS. People who wrote to us made the valid point that there are several good and reliable operating systems on the market, designed, among other purposes, for the automotive industry. The main argument used to demonstrate the technological superiority of competing solutions was that the principle of security domain isolation is not a new idea and many of the existing systems that are currently in use have numerous additional security features based on the current needs, such as implementations of cryptographic protocols, network filters and protection against network attacks. Some of these systems are even certified to meet various security standards!
All these additional features (including certification) are of course important, but is it this functionality that makes an operating system reliable and secure? To answer this question, we first need to answer another: what is a secure OS? From our viewpoint, a secure operating system should guarantee secure or trusted execution of components that are not secure (programs).
Our concept has two very important aspects. One is obvious: we do not trust third-party software and consider it insecure and unreliable by definition. The other, not-so-obvious aspect: we should trust the operating system and regard kernel functionality as trusted. To increase the level of trust (after all, gentlemen do not always believe each other’s word), the kernel should undergo formal and mathematical verification (the subject of verification would merit a large research paper of its own).
Taking this paradigm as a starting point, we did not just implement a secure architecture based on a trusted kernel, but learned from existing secure OS implementations, as well. The fundamental principles, such as security domain separation and a microkernel are only half the story. Studying other systems and their limitations helps not only to avoid known problems but also to find new ways to implement security properties. As a result, we have developed an OS that, on the one hand, is similar in its operating principles to other operating systems but, on the other hand, has features which help to overcome known limitations and improve the security characteristics of the system on which the OS is running.
As an example of such improvement, I would like to mention interprocess communication (IPC) typification. This technology, the idea of which might seem quite obvious, provides us with low-level control of the data sent in application calls, giving security policies a granularity of control that has never been implemented at this level. Another feature is combining different types of security policies, such as Flow Control and Type Enforcement, in one system. The resulting policy is a mix of stateful and stateless policies, offering the best of both worlds. Naturally, the possibilities of combining policies are not limited to these two types. No commercial operating system can boast this flexibility. This functionality provides tight control of all interprocess communication, which is based not only on the knowledge of the subject and object of communication (who requests and from whom) but also on the knowledge of the high-level context of communication (what is requested, when and what data is transferred).
Other KasperskyOS features include a flexible language for defining security policies and a policy verification system, which makes both creating and debugging policies significantly easier. There are many other things, as well. The uniqueness of our work is supported by US and Russian patents.
As a result, we believe we have developed an operating system which implements the principle of trusted execution of untrusted applications. This was achieved, among other things, by using the principle of security domain separation and control of interprocess communication that is tight and flexible at the same time. This means that in the OS, modules can only interact by following a strictly defined protocol, enabling them to call only allowed functions in a strictly defined sequence. For customers, this means that even if there is a vulnerability in some module that can be exploited by a hacker (and we admit that this may be the case), the OS works in such a way that the hacker will only be able to gain control of the vulnerable module and will not be able to interfere with the operation of other modules, because all communications are controlled.
An operating system can be compared to a shield. All additional built-in security capabilities, including firewalls, secure data transfer protocols, even certification, are rivets on the shield. They certainly add reliability to the whole thing, but they do not define the overall level of protection. What is more important is the architecture, the principles underlying the OS. This determines whether the shield will be made of paper, plywood or steel. Many operating systems have great rivets – but what kind of shield are they attached to?
Source: Kaspersky