Secure Boot verifies firmware integrity by enforcing a cryptographically chained trust model that starts in immutable hardware and extends all the way to the loaded firmware and operating system. On IBM systems (IBM Z / IBM Power), this is implemented through a hardware root of trust + signature verification + measured boot process.

The core idea is:

Only firmware that is cryptographically signed and verified by trusted keys stored in hardware is allowed to execute.

1. Core idea: chain of trust

Secure Boot works like a “trust chain”:

Hardware Root of Trust
        ↓
Bootloader / IPL code
        ↓
Firmware components
        ↓
Hypervisor / OS kernel

Each stage:

• verifies the next stage before executing it
• refuses to run untrusted or modified code

2. Hardware Root of Trust (starting point)

At power-on:

• CPU starts from immutable code in hardware (ROM / secure firmware)
• this root is cannot be modified
• it contains embedded or securely stored public verification keys

👉 This is the foundation of trust.

3. Step-by-step firmware verification process

Step 1: Power-on reset

• CPU executes initial boot code from secure ROM

Step 2: Load first-stage firmware

• system firmware (e.g., PHYP on Power or Licensed Internal Code on Z) is loaded

Step 3: Signature verification

Hardware or trusted firmware checks:

• firmware image hash (SHA-256 or stronger)
• digital signature (RSA / ECC / PQC-ready mechanisms)

It verifies:

Signature(public_key, firmware_hash) == VALID

If invalid:

• boot is halted
• system enters recovery mode

Step 4: Integrity measurement (optional but common)

• firmware is measured (hashed)
• measurements stored in secure registers or TPM-like subsystem

Step 5: Chain continues

Each loaded component:

• verifies the next component
• extends trust chain upward

4. Where keys are stored

Verification depends on secure key storage:

A. Hardware root keys

• embedded in secure processor firmware
• immutable or securely fused

B. Trusted certificates

• stored in secure boot database
• managed by IBM firmware/security layer

5. What is being verified

Secure Boot verifies:

A. Integrity

• code has not been modified

B. Authenticity

• signed by trusted IBM/vendor key

C. Version policy

• prevents rollback to vulnerable firmware

6. Role of cryptography in verification

Secure Boot uses:

• digital signatures (RSA/ECC)
• cryptographic hashes (SHA-2 / SHA-3)
• optionally quantum-safe algorithms in future-ready systems

Flow:

1. compute firmware hash
2. decrypt signature using public key
3. compare results

7. Protection against tampering

Secure Boot prevents:

A. Firmware modification attacks

• unsigned firmware is rejected

B. Bootkit/rootkit attacks

• malicious bootloaders cannot execute

C. Downgrade attacks

• older vulnerable firmware blocked

D. supply chain attacks

• only trusted signed firmware allowed

8. IBM Z / Power-specific enhancements

A. IBM Z (LIC + secure boot chain)

• Licensed Internal Code (LIC) is verified at multiple levels
• PR/SM hypervisor is part of trusted chain
• CF and cryptographic services depend on verified firmware

B. IBM Power (Secure Boot + PHYP)

• Power Hypervisor (PHYP) is verified early
• LPARs only start after trusted hypervisor is confirmed

9. Measured boot vs secure boot

IBM systems often use both together.

10. Role of secure hardware (TPM-like functions)

Hardware stores:

• root keys
• boot measurements
• integrity state

This ensures:

• tamper resistance
• cryptographic attestation capability

11. Simple mental model

Think of Secure Boot as:

A multi-layer cryptographic checkpoint system where each stage of system startup must prove its identity and integrity before it is allowed to execute, starting from immutable hardware keys and extending up to the operating system.

Key takeaway

Secure Boot verifies firmware integrity by:

• Starting from a hardware root of trust
• Using cryptographic signatures to validate firmware
• Building a chain of trust from boot to OS
• Blocking any untrusted or modified firmware
• Ensuring only authenticated code executes during startup