Technology Solutions


Technology Solutions


Security: a universal requirement

We all witness new sophisticated attacks being discovered every day. The attacks target everything: industrial systems, IoT devices, financial institutes, military facilities, smartphones, medical equipment, airplanes, trains, connected cars. Historically, most commercial systems have been developed with haphazard attention to security concerns and it is often reflected in the newspapers headlines.

High-level overview of a “one-stage” secure boot and a trusted chain PikeOS Security Levels

To withstand ever growing and mutating attack vectors, the fundamental requirements for a modern secure system are

  • The security shall be built-in by design.
  • The security shall provide high-assurance for its functionality.
  • The security shall enable adaptation and update of the system to changing deployment environment and mutating attackers.

SYSGO PikeOS security competence covers these fundamental requirements as follows:

  1. Security by design via MILS
  2. PikeOS Security Assurance via independent security certification
  3. PikeOS Secure Lifecycle with secure boot and secure update
  4. Support of trusted modules TPM/HSM and cryptography

Due to hardware and software advancements as well as cost containment pressures, there is an increasing desire to house multiple systems on a single platform that can meet diverse and independent security requirements. This need led to the development of the MILS (Multiple Independent Levels of Security) architecture. While initially developed with defense systems in mind, MILS concepts are relevant to many different industry sectors that require security from different types of threats to be managed in a cost-effective manner. MILS offers a suitable architecture not only for military systems, but also applications as diverse as medical, industrial, and financial systems. MILS accomplishes the goal of supporting diverse levels of security by following a layered approach to implementing various security concepts.

Security standards are defined by the Common Criteria (CC), an international standard for security requirements. The CC defines multiple levels of security in the form of Evaluation Assurance Levels (EALs), with the highest level defined as EAL 7. Approaches to enforcing security must be layered and incremental in order to address an evolving environment populated by resourceful attackers. Again, this holds true in both military and commercial application domains.

Technology Services

Secure Boot

Secure boot is a mechanism preventing firmware attacks that can be used to boot other images, to monitor operating system internals, and to even trap access to devices like e.g. storage or network. Secure boot ensures that the hardware executes only a dedicated software, which has been tested, validated, and signed for the specific hardware by the OEM. A modification to the validated software will be detected during the secure boot process and the hardware will stop the booting process.

Root of Trust and Chain of Trust

The secure boot technology requires a so-called Root of Trust. The root of trust is typically a physically immutable data, e.g. SoC often have fuses which can be “burned” with the hash of the public key used in during secure boot process. The root of trust starts the chain of trust. In the chain of trust each steps check the integrity of the HW or SW in the next step before it starts its execution or give to it control. Thus, the main objective of the chain of trust is to guarantee the integrity of every piece of firmware and software deployed in a system.

The below figure depicts a high-level overview of a “one-stage” secure boot and a trusted chain. On power on, the hardware validates with the help of root of trust. After HW is operational, HW checks the integrity of the bootloader. If the check is successful, bootloader is executed, and then bootloader checks the image of PikeOS with deployed applications. If the check succeeds, then PikeOS will be launched.

Boot process with PikeOS

Some embedded system use-cases require more fallibility, e.g. applications come from different vendors and are signed by those vendors, or application can be updated in deployed system by the application vendor. In this case, one may need to decouple the signing and checking bootloader, the operating systems, and applications. In this case, PikeOS can be extended with an application loader, which continues the trusted chain and validates the 3d party applications.

A detailed description on secure boot and chain of trust technology is described in the whitepaper “Secure boot” (download HERE

 Secure Update

A device has to address 3 main challenges that need to be addressed:

  • Secure boot
  • Secure update and
  • Secure lifecycle

A secure update can be supported with PikeOS. It is a start of the secure lifecycle with multiple software updates via local, wired or wireless update mechanisms, such as patches over the air.

PikeOS Secure Update Archtitecture PikeOS Secure Update Archtitecture

An implementation of safety and security features in separated partitions reduces the attack surface and allows the realization of independent security checks thereby making the system more resilient to security attacks. This also is the baseline for security certification guidelines and requirements. A partitioned system architecture based on Separation Kernel (in which the ability of one application to influence others is strictly controlled) provides built-in security by construction. It also allows the safe deployment of hot-fixes or patches developed rapidly in response to a discovered vulnerability without having any undesirable consequences to a recertification of rest of the system. A hardware security module such as a Trusted Platform Module (TPM) is used to implement the security properties required for the update process.

Secure Product Elements

What is the build-in security in PikeOS Hypervisor?

  • Separation in time and space of user applications hosted in different user partitions from each other and from the TSF.

    • Separation of partitions and Virtual Machines (VM) from each other
    • Controlled information flow
    • Access control to resources
    • Availability of resources
    • White list security policy

  • Confidentiality of per-partition/VM resource usage.
  • Absence of residual information flow on partition/VM switch.
  • Abilities-based access control to PikeOS management API and PikeOS data.
  • PikeOS self-protection.
  • High-assurance for provided security functionality.
  • MILS Compliance.




MILS (Multiple Independent Levels of Security) is a high-assurance security architecture that supports the coexistence of untrusted and trusted components, based on verifiable separation mechanisms and controlled information flow.

Download MILS leaflet

The PikeOS real-time hypervisor is based on a MILS-conformant microkernel, which supervises every hardware access. Such a kernel must be sufficiently simple to enable a formal analysis of properties, and for each high-assurance subsystem to be modular so that it can be decomposed to elements sufficiently primitive to support analysis of security properties. PikeOS is built on a trusted microkernel consisting of about 5,000 lines of code. Its internal three-layer architecture is ideally suited to the design of secure systems with a minimal trusted computing base: the trusted microkernel operating in supervisor mode; system software / middleware running in user mode; and the application layer containing virtual machine “personalities” and hosting application modules.

Enjoying MILS architecture’s benefits through PikeOS

Although designed with defense systems in mind, PikeOS enables implementing MILS systems for non-defense systems requiring differing levels of security housed within a single system. This PikeOS capability relies on features for strong partitioning and control information flow as well as assurance for these features. Thus, PikeOS provides a modular approach to the optimal mix of tradeoffs between security, cost, and development schedule. The PikeOS approach provides developers with a decided competitive edge for such systems.


PikeOS has also been used for a product successfully evaluated by a French security test lab CESTI in 2011. The French CESTI lab is an accredited security evaluation laboratory for Common Criteria security evaluations. The product has been developed by a global company, leader for defense and security. As a result, a certificate called "Certification de Sécurité de Premier Niveau" (CSPN), also called First Level Security Certification was delivered by the French Network and Information Security Agency (ANSSI). More information is available HERE.

This certificate was a first but important milestone in the on-going process to certify PikeOS according to the highest levels of security initiated by SYSGO for several years.

Innovation speed of PikeOS is guaranteed by usage in different industrial and R&D projects. Industrial projects cannot be disclosed but early result on PikeOS ability to comply with Common Criteria standard.

To know more about SYSGO's participation in international projects focusing on security, please check Verisoft, TECOMSeSaM, EURO-MILS, CITADEL, cert-MILS  related information.

The current efforts, in particular through the already mentioned R&D projects, include formal code verification of the PikeOS micro-kernel for Common Criteria EAL 6/7, as well as involvement in various industrial projects requiring the highest level of security. As part of the Verisoft XT project, funded by BMBF (German Ministry of Education and Research), SYSGO is pursuing the formal verification (aiming at EAL 7) of PikeOS using an innovative enhanced code verification approach that provides:

  • Memory framing properties, that is, absence of illegitimate memory accesses on some sections of code and
  • Functional correctness, that is, implementation honoring the formal specification on some parts of the kernel.