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
- PikeOS Security Assurance via independent security certification
- PikeOS Secure Lifecycle with secure boot and secure update
- Support of trusted modules TPM/HSM and cryptography
MILS - Multiple Independent Levels of Security
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 different 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 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 in order to address an evolving environment populated by resourceful attackers. Again, this holds true in both military and commercial application domains.
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 & 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 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.
Trusted Chain and 3d Party Applications
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 3d party applications.
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 the 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 re-certification 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.
Security-approved hardware and components
Secure boot cycle
Building a root of trust
Secure over-the-air software update
Security event monitoring in field
Secured development via deterministic prevention of remote code execution
Bundles with 3rd party Security components to keep speed of innovation