Secure Boot in Fortanix FX3400 Appliance

Attackers target the boot process because it offers them a way to persist even after reboots or OS reinstalls. A bootkit or rootkit that loads before the operating system can remain hidden from defenses and maintain long-term control.

Secure Boot counters this by enforcing a chain of trust, allowing only verified, signed code to run at startup and blocking such deep, persistent compromises.

By combining Secure Boot with Intel SGX, Fortanix products implement a defense-in-depth security architecture that ensures platform integrity at boot and data confidentiality at runtime.

What’s Secure Boot?

Secure Boot is a security feature that ensures only trusted and verified software is loaded during the system startup process, protecting the integrity of the boot sequence.

This is achieved by establishing a hardware-based root of trust and a chain of trust on top of that until the full boot chain is verified and loaded securely.

In more practical terms it usually means that the first loaded component contains a hash or certificate and validates the next component before that component is executed. The subsequent component does the same, until full verification is achieved.

If at some point, the hash comparison fails or certificate is not trusted, the boot is halted to prevent untrusted code from executing.

Common Gaps in Secure Boot Implementations

Even though Secure Boot is meant to enforce a trusted chain, several pitfalls occur based on how it is really implemented. Following are some such scenarios:

• Ignoring firmware protection: Skipping protections like Intel Boot Guard or OBB verification leaves the firmware itself open to tampering. Once an attacker implants malicious code at the firmware level, they can bypass Secure Boot entirely and persist below the operating system.
• Using test keys in production: Test keys, intended only for development, have been mistakenly left in production systems in real world cases. When this happens, attackers can easily sign their own malicious binaries and boot them as if they were trusted.
• Relying on third-party keys: Many implementations depend on Microsoft’s keys for UEFI Secure Boot or BIOS vendor keys for OBB verification. This delegates part of your trust to external organizations, meaning that if those keys are compromised, or if a malicious insider acts within those organizations, your own platform can be compromised as well.

How Fortanix implements Secure Boot

Fortanix FX3400 Appliance uses two solutions to implement boot integrity: Intel Boot Guard and UEFI Secure Boot.

Intel Boot Guard

Intel Boot Guard provides a hardware based Static Root-of-Trust (RoT) for platform boot verification using Intel’s Authenticated Code Module (ACM). The module is signed by Intel and loads a public key hash from a fuse that Fortanix sets during manufacturing to validate the “OEM” and “ODM” keys set by Fortanix during BIOS compilation time.

These keys form a chain of trust that will finally authenticate the initial boot blocks (IBB), which is essentially the first BIOS code module. Additionally the ACM will authenticate the CPU microcode. In turn, the microcode will also verify the ACM code blob. If anything fails, the system will refuse to boot.

IBB and SEC/PEI Phases

The IBB phase consists of setting up the SEC(Security) phase where a new root of trust is established using a Fortanix provided certificate to validate the remainder of the BIOS.

It also executes the Pre EFI Initialization (PEI) phase, which defines the start of the OBB region. At this point in boot time there’s now enough memory to load the full BIOS and using the SEC RoT, all other BIOS regions are validated before finally entering the Driver Execution Environment (DXE-phase).

This will eventually load the UEFI Secure Boot DXE, which will use Fortanix signed Certificates as part of the UEFI Authenticated Variables to validate the Bootloader and Linux kernel. If anything fails, the boot process halts.

Moreover, our release testing includes tamper verification for each component, ensuring that any unauthorized modification reliably triggers a validation failure

Effective Secure Boot Key Management

In the complete chain of trust, multiple keys are involved:

• OEM and ODM keys used in Intel Boot Guard for authenticating the initial boot block
• The Root of Trust key in the SEC/PEI phase used to verify critical BIOS memory regions
• UEFI Secure Boot keys that verify the bootloader and kernel image

By storing these keys inside Fortanix Data Security Manager (DSM), we ensure strong security guarantees:

• the keys can never be exported
• every operation is logged and auditable
• access is tightly controlled through RBAC.

Furthermore, signing a new release of any boot component requires quorum approvals from multiple authorized individuals, preventing unilateral or unauthorized actions.

Why Fortanix Data Security Manager (DSM) Matters

Fortanix Data Security Manager (DSM) supports a broad range of use cases and enforces strong operational and security controls, as discussed above.

In addition:

• it integrates seamlessly with tools commonly used for Secure Boot signing
• is flexible enough to handle scenarios such as batch signing with quorum approval, for example, when dealing with kernel modules.

If this aligns with your needs, feel free to reach out to us to explore how Fortanix Data Security Manager can help.