Secure Boot and Key Management
Overview
Secure boot establishes a trusted execution environment by ensuring that only authenticated and untampered firmware can run on the device. It forms the foundation of the system’s hardware root of trust.
Key management governs how cryptographic keys are:
- generated
- stored
- derived
- distributed
- rotated
- revoked
Because secure boot and key management underpin all higher‑level security mechanisms, they are prime targets for attackers attempting to:
- bypass authentication
- inject malicious code
- downgrade firmware
- extract secrets
- manipulate lifecycle states
A secure system must guarantee authenticity, integrity, freshness, and confidentiality from the first instruction executed.
Secure Boot Threats
Firmware tampering
Modifying boot images to insert backdoors or disable protections.
Rollback attacks
Loading older, vulnerable firmware versions that bypass security patches.
Bootloader manipulation
Altering boot configuration, mode bits, or boot order to load unauthorized code.
Fault injection during boot
Glitching voltage or clock to skip signature checks or force invalid states.
Key extraction from boot ROM
Probing or exploiting weaknesses in the immutable root of trust.
Unsigned peripheral firmware
Loading malicious code into co‑processors or external modules.
Debug interface abuse
Using JTAG/SWD/UART to bypass secure boot or inject code.
Figure 1 — Secure Boot Chain of Trust
Each stage verifies the next using signatures and version counters. No stage runs unless authenticated and newer than the previous.
Key Management Threats
Key extraction
Probing, side‑channel analysis, or memory attacks to retrieve secret keys.
Weak key storage
Keys stored in unprotected flash, registers, or buffers.
Key reuse and stale keys
Using the same key across devices or failing to rotate keys.
Insecure provisioning
Exposing keys during manufacturing or field updates.
Unauthorized key updates
Attackers replacing or disabling keys.
Entropy manipulation
Influencing RNGs to weaken key generation.
Supply‑chain compromise
Inserting malicious keys or certificates before deployment.
Secure Boot Mechanisms
Immutable root of trust
A ROM‑based or hardware‑anchored component that verifies the first stage of boot.
Digital signatures
Authenticating firmware using asymmetric cryptography (RSA, ECC).
Hash‑based integrity
Verifying firmware integrity using SHA‑based digests.
Anti‑rollback counters
Monotonic counters or OTP fuses prevent downgrades to vulnerable firmware.
Measured boot
Recording boot measurements for attestation.
Secure update integration
Ensuring updated firmware is authenticated and integrity‑protected.
Debug port lockdown
Disabling or authenticating debug access during secure boot.
Figure 2 — Anti‑Rollback Enforcement
Firmware must always move forward. Even a valid signature cannot bypass version checks.
Key Management Mechanisms
Hardware security modules (HSM/TPM/SE)
Keys isolated in dedicated secure hardware.
Key derivation functions (KDFs)
Generating per‑device or per‑session keys from a master secret.
Secure key storage
Encrypted memory, OTP fuses, PUF‑derived secrets, or secure registers.
Key rotation and refresh
Periodically updating keys to limit exposure.
Secure provisioning
Injecting keys in trusted environments with encrypted transport.
Access control
Restricting which components can use or request keys.
Entropy sources
Using TRNGs and validated entropy pools for strong key generation.
Figure 3 — Key Hierarchy and Derivation
A root key never leaves secure hardware. All operational keys are derived and scoped.
Relationship with Safety
Safety
Ensures correct system behavior under random faults.
Security
Ensures correct system behavior under malicious manipulation.
Overlap
- Fault injection during boot resembles brown‑out or timing faults
- Integrity checks (hashes, signatures) support both domains
- Secure boot ensures safety mechanisms cannot be disabled by malicious firmware
Related Pages
All real, existing pages:
