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

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

PikeOS's Security competence covers these fundamental requirements as follows:

• Security-by-design via MILS
• Security assurance via independent Security certification
• Secure life cycle with secure boot and secure update
• 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 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 different levels of Security by following a layered approach to implementing various Security concepts.

As embedded systems become more connected, their exposure to cyber threats increases dramatically. Traditional perimeter-based defenses are no longer sufficient—Security must be built into the hardware itself. The Trusted Platform Module (TPM) provides a hardware root of trust, enabling secure boot, data encryption, and remote attestation. In Safety- and mission-critical sectors like Aerospace, Automotive, and Industrial Automation, TPM is essential.

TPM strengthens embedded platforms through measured boot, sealed storage, and virtualization. PikeOS enables secure, scalable TPM usage across virtualized environments.

Read more

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 levels of 6 and 7 for complete systems and EAL 1 to 5 for the software development-specific Security requirements. Approaches to enforcing Security must be layered and incremental to address an evolving environment populated by resourceful attackers. Again, this holds true in both military and commercial application domains.

Common Criteria Certification Kit

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.

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 during the secure boot process. The root of trust starts the chain of trust. In the chain of trust each step checks the integrity of the HW or SW in the next step before it starts its execution or give 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.

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 systems 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 3rd party applications.

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 re-certification of the system. A hardware Security module such as TPM (Trusted Platform Module) is used to implement the Security properties required for the update process.