The foundational security principle for embedded systems—physical and network isolation—has been shattered. For decades, devices in industrial, medical, automotive, and aerospace sectors were protected by an "air gap." Today, the proliferation of IoT, 5G, and edge computing has connected these systems to the internet, exposing them to a new class of sophisticated threats. This reality demands a shift from the failed model of perimeter defense to one of intrinsic, hardware-anchored trust.

The consequences of a breach are no longer theoretical; they are catastrophic, affecting critical infrastructure like power grids, patient care systems, and autonomous vehicles. The vulnerabilities are systemic and arise from three core challenges:

1. Legacy Code: A vast amount of embedded code is written in memory-unsafe languages like C and C++, making it susceptible to common exploits like buffer overflows. The cost to rewrite and recertify this code in memory-safe languages is often prohibitive, estimated to be in the billions of dollars
2. Expanded Attack Surface: Retrofitting devices with network stacks exposes them to remote attacks, data exfiltration, and supply chain vulnerabilities inherited from third-party and open-source software
3. Extended Lifecycles: Embedded systems often operate for decades, long outliving vendor support and security patches. This creates a landscape of devices frozen in a state of perpetual vulnerability

The Limits of Software and the Mandate for a Hardware Root of Trust

In this hostile environment, software-only security measures are insufficient. Firewalls and antivirus software are rendered useless if an attacker can compromise the system before the OS boots, using a malicious bootloader (bootkit) or compromised firmware. Security can no longer be an application you run; it must be an intrinsic property of the platform.

This architectural requirement leads to the Hardware Root of Trust (HRoT)—a secure, immutable component within the system's hardware. An HRoT provides a protected environment for cryptographic functions and sensitive data storage, shielded from the main CPU and vulnerable software. The industry-standard implementation of this concept is the Trusted Platform Module (TPM), defined by the Trusted Computing Group (TCG). The TPM is the bedrock upon which a resilient embedded security architecture must be built.

Anatomy of Trust: The three Pillars of TPM 2.0

A TPM is a secure cryptoprocessor that performs cryptographic operations and stores sensitive artifacts (keys, certificates) behind a hardware barrier. Its power lies in three synergistic pillars of functionality that establish a chain of trust from silicon to software.

The modern standard, TPM 2.0, is defined by the international standard ISO/IEC 11889 and is available in several form factors:

• Discrete TPM (dTPM): A separate, tamper-resistant chip offering the highest security
• Integrated TPM (iTPM): Integrated into another chip, offering strong software attack resistance
• Firmware TPM (fTPM): A firmware-based solution running in a Trusted Execution Environment (TEE) on the main CPU

Pillar 1: Platform Integrity via Measured Boot

The TPM’s most fundamental function is to create an incorruptible record of the system’s boot process. This is achieved through Measured Boot, which, unlike Secure Boot, logs every component without halting the system.

1. Upon power-on, the immutable Core Root of Trust (part of the UEFI/BIOS) takes a cryptographic hash of the next component in the boot chain
2. This hash is sent to the TPM and "extended" into a Platform Configuration Register (PCR). An extend operation is a one-way function: PCR_new = HASH(PCR_old + new_hash)
3. This process continues sequentially for the firmware, bootloader, and OS kernel

PCRs cannot be arbitrarily written to, creating a verifiable cryptographic fingerprint of the boot process. Any unauthorized change results in a different final PCR value.

Pillar 2: Data Confidentiality via Sealing

The TPM leverages these integrity measurements to protect data. The most powerful mechanism is Sealing, which binds data not only to a TPM-managed key but also to a specific platform state defined by PCR values.

The classic example is full-disk encryption like BitLocker. The disk encryption key is sealed against the PCR values of a known-good boot. On the next boot, the TPM will only "unseal" (decrypt) the key if the current PCR values exactly match the sealed values. If a bootkit has tampered with the bootloader, the PCRs will differ, the TPM will refuse to release the key, and the encrypted data remains secure.

Pillar 3: Remote Verification via Attestation

Remote Attestation allows one machine (the Attester) to cryptographically prove its identity and software state to another (the Verifier). This relies on two key types:

• Endorsement Key (EK): A unique key pair burned into the TPM by the manufacturer, serving as the TPM's ultimate root of identity
• Attestation Identity Key (AK): A signing key used for attestation, certified by a Privacy CA to prove it resides in a genuine TPM without revealing the specific device's EK, thus preserving privacy

The attestation flow provides cryptographic proof of a remote device's integrity:

1. The Verifier sends a nonce (a random, one-time number) to the Attester to prevent replay attacks
2. The Attester instructs its TPM to generate a Quote—a signed data structure containing the current PCR values and the nonce, signed with a private AK
3. The Attester returns the signed Quote and the public AK certificate to the Verifier
4. The Verifier checks the certificate chain, verifies the signature, confirms the nonce, and compares the PCR values to a "golden measurement" list of known-good values

If all checks pass, the Verifier has high confidence in the Attester's identity and integrity. This is the foundation of Zero Trust architectures.

The Virtualization Challenge: From System Consolidation to sharing the Root of Trust

To reduce Size, Weight, and Power (SWaP) and cost, modern embedded systems consolidate multiple functions onto single multi-core processors. This creates mixed-criticality systems, where a real-time flight controller and a non-critical infotainment system must coexist securely on the same hardware.

The enabling technology for this is a Type-1 hypervisor, which partitions hardware resources into secure, isolated virtual machines. For high-assurance systems, a specialized separation kernel is required. Its primary function is to enforce strict, non-bypassable isolation between partitions.

PikeOS, a leading European certified hard RTOS and hypervisor, is built on a small, fast, and safe separation microkernel that enforces:

• Spatial Partitioning: Hardware-enforced separation of memory, I/O, and CPU cores, preventing interference between partitions
• Temporal Partitioning: Guaranteed CPU time allocation for critical partitions, ensuring hard real-time determinism

This rigorously enforced separation, creating a minimal and formally analyzable Trusted Computing Base (TCB), allows PikeOS to be certified to the highest industry standards, including DO-178C (avionics), ISO 26262 (automotive), and Common Criteria EAL5+ for security.

However, virtualization creates a new challenge: A physical TPM is a singular, stateful device. How can its hardware-rooted security be provided to multiple, isolated virtual worlds concurrently?

Solving the Conundrum: A superior Architecture for virtual TPMs (vTPM)

The solution is the virtual TPM (vTPM), a software-based representation of a TPM provided to each guest VM. This allows each VM to use features like disk encryption or attestation as if it had its own dedicated chip. There are three architectural models for implementing vTPMs:

1. Pure Software vTPM (Emulation): The hypervisor emulates TPMs in software. This is scalable but lacks a hardware root of trust, making it as vulnerable as the hypervisor itself.
2. Direct Passthrough: One VM is granted exclusive access to the physical TPM. This is secure for that one VM but completely unscalable.
3. Resource-Managed vTPM (The Optimal Model): The hypervisor hosts a privileged service that manages and multiplexes access to the single physical TPM, providing hardware-backed vTPM instances to multiple guests. This architecture requires a TPM Resource Manager (RM) to manage scarce TPM memory and an Access Broker (TAB) to serialize commands.

The following table makes the superiority of the resource-managed approach clear:

The SYSGO Solution: A Certified, Full-Stack Approach

A resource-managed vTPM architecture is only as secure as the hypervisor that hosts it. The TPM Resource Manager is the gatekeeper to the hardware root of trust; if compromised, the entire system's security collapses. Running this critical service on a general-purpose OS like Linux, with its massive TCB and vast attack surface, introduces unacceptable risk.

This is where the unique value of the PikeOS separation kernel is paramount. Its foundational principle is TCB minimization. The TPM Resource Manager is deployed in its own dedicated partition, protected by the same Common Criteria EAL 5+ certified, hardware-enforced separation that isolates all other guests. A compromise of a Linux guest has no way to affect the integrity of the TPM manager.

The TPM provides the Root of Trust for Measurement, and the PikeOS separation kernel provides the Root of Trust for Separation. Together, they form a high-assurance platform where hardware-rooted trust can be safely and scalably extended to any number of virtualized guests.

Component 1: The PikeOS TPM 2.0 Driver

At the base of the stack, SYSGO provides a robust, low-level driver that forms the secure bridge between the PikeOS hypervisor and the physical TPM 2.0 chip.

Component 2: The PikeOS TPM 2.0 Resource Manager and Access Broker

Building on this foundation, SYSGO provides the key enabling technology: A security-critical service that implements the superior resource-managed vTPM architecture. Hosted in a dedicated, secure PikeOS partition, it delivers hardware-backed vTPM instances to multiple guests, allowing Linux, Android, Windows, POSIX, ARINC 653, and other systems to leverage TPM security simultaneously and safely.

A Partnership for Secure Innovation

Developing high-assurance systems requires more than off-the-shelf products. SYSGO's advanced TPM support is available for integration in concrete customer projects, allowing organizations to collaborate directly with our experts to design next-generation secure systems for automotive, avionics, and defense. This positions SYSGO as a dedicated technology partner committed to solving the most difficult security challenges.

The modern embedded landscape demands a paradigm shift anchored in a hardware Root of Trust. As systems adopt virtualization, a certified separation kernel like PikeOS is the only secure foundation. SYSGO provides both the certified foundation and the expert-developed components to realize this architecture.

Get in contact with us to secure your next-generation embedded project.

TPM Support in ELinOS for Enhanced Security in Embedded Systems

With Trusted Platform Module (TPM) support integrated into our embedded Linux development platform ELinOS, developers can leverage advanced cryptographic services and robust hardware-based protections. From secure boot and file encryption to system integrity verification, TPM brings a new layer of trust to embedded Linux environments.

Read the Press Release