Secure boot is usually presented as a clean, almost elegant mechanism.
A root of trust verifies a firmware image. If the signature is valid, the system boots. If not, it refuses to execute untrusted code. Simple. Deterministic. Safe.
That mental model assumes something that does not exist in embedded systems.
Perfect state.
In reality, firmware is stored in flash memory that can fail, degrade, or be interrupted mid-write. Power loss happens. Brownouts happen. Writes are not atomic. Pages get partially programmed. Bits flip. Metadata drifts out of sync with data.
Secure boot, as commonly implemented, is not designed for this environment. It is designed for a binary world: valid image or invalid image.
Partial corruption lives in between.
And that is where things break.
<h3>The Assumption of Atomicity</h3>
Most secure boot designs implicitly assume that a firmware image exists in one of two states.
Fully valid or completely invalid.
Flash does not behave that way.
A firmware update may write hundreds or thousands of blocks. If power is lost midway, the device may contain:
<ul>
<li>A valid header but corrupted payload</li>
<li>A corrupted header but intact payload</li>
<li>Two partially overlapping images</li>
<li>Metadata pointing to an inconsistent region</li>
</ul>
If the boot process does not explicitly model these intermediate states, it will attempt to interpret them as something valid.
Not because the system is malicious, but because it has no concept of “incomplete.”
That is the first failure mode. Treating non-atomic storage as if it were atomic.
<h3>Validation Without Context</h3>
Signature verification is often treated as the ultimate gate.
If the signature checks out, the firmware is trusted.
But what exactly is being verified?
In many systems, the signature covers only a portion of the image. Or it covers the image, but not the metadata that defines how the image is interpreted. Or it covers the payload, but not the versioning information.
Under partial corruption, this becomes dangerous.
A system may verify a valid signature over data that is no longer semantically consistent with the rest of the system state. For example, a payload that was signed correctly, but is now paired with corrupted configuration or execution parameters.
Cryptographic validity does not imply semantic validity.
Secure boot must enforce both.
<h3>Boot Decision Ambiguity</h3>
When corruption is detected, the system must decide what to do.
This is where most implementations quietly fail.
Common fallback strategies include:
<ul>
<li>Boot the “last known good” image</li>
<li>Retry the current image</li>
<li>Enter recovery mode</li>
</ul>
These sound reasonable, but they rely on the assumption that the system can correctly identify what “last known good” means.
Under partial corruption, that assumption breaks.
If metadata is corrupted, the system may misidentify which image is valid. If version counters are inconsistent, rollback protection may be bypassed. If flags are partially written, the system may believe an update completed when it did not.
This creates ambiguity in the boot decision.
And ambiguity in a security-critical state machine is an attack surface.
<h3>Rollback Through Corruption</h3>
Rollback protection is often implemented using monotonic counters or version numbers stored in flash.
These mechanisms assume that the stored value is correct.
Partial corruption breaks that assumption.
If a version counter is partially written or corrupted, the system may interpret it as a lower value. This can allow an older, vulnerable firmware to be accepted as valid.
The attacker does not need to break the signature. They only need to influence the state of the counter.
In practice, this can be achieved through induced power loss or fault injection during writes.
Rollback protection, without integrity guarantees on its own state, is fragile.
<h3>Inconsistent Multi-Image Systems</h3>
Many embedded systems use dual-bank or multi-slot firmware layouts to allow safe updates.
The idea is simple. Keep one known-good image and one candidate image. Switch between them as needed.
Under partial corruption, this model becomes more complex.
If the update process writes to the inactive slot and is interrupted, the slot may contain a partially valid image. If the bootloader incorrectly marks this slot as active, the system may attempt to boot corrupted firmware.
Worse, if both slots experience partial corruption over time, the system may end up with no fully valid image, but still attempt to boot.
Redundancy does not guarantee correctness.
It only works if the transitions between states are strictly controlled and verifiable.
<h3>Metadata as a Single Point of Failure</h3>
Bootloaders rely heavily on metadata.
Flags indicating active slots.
Version numbers.
Integrity markers.
Update status indicators.
This metadata is often small, frequently updated, and stored in the same unreliable medium as the firmware itself.
Partial corruption in metadata is often more dangerous than corruption in the firmware payload.
A corrupted payload will usually fail verification.
Corrupted metadata may still look plausible.
This leads to scenarios where the system makes a logically consistent decision based on incorrect information.
The bootloader becomes confident and wrong.
<h3>Fault Injection as a First-Class Threat</h3>
Partial flash corruption is not always accidental.
Attackers can induce it.
Power glitching, voltage manipulation, and timing attacks can interrupt writes at precise moments. This allows an attacker to target specific transitions in the boot process.
For example:
Interrupting the write of a “firmware verified” flag.
Corrupting a version counter during increment.
Forcing a transition into a state that should be unreachable.
If the system does not treat transitions as critical operations requiring atomicity and verification, these attacks become practical.
<h3>Designing for Incomplete States</h3>
The core mistake is treating secure boot as a validation step, instead of a state machine.
A robust design must explicitly represent and handle incomplete and inconsistent states.
This means:
<ul>
<li>Defining states such as “update in progress,” “image incomplete,” and “recovery required”</li>
<li>Ensuring that no state allows execution of unverified or partially verified code</li>
<li>Making all transitions failure-atomic</li>
<li>Verifying not just payloads, but the entire boot context, including metadata</li>
</ul>
The system must never guess.
If the state is ambiguous, the only safe action is to refuse to boot into a potentially unsafe configuration.
<h3>The Real Invariant</h3>
The invariant secure boot must enforce is not “only signed code executes.”
It is stronger than that.
The system must guarantee that it never transitions from a higher-trust state to a lower-trust state, even under partial failure.
That includes:
<ul>
<li>No execution of partially written firmware</li>
<li>No acceptance of downgraded versions due to corrupted counters</li>
<li>No reliance on unverified metadata</li>
<li>No ambiguous interpretation of system state</li>
</ul>
If this invariant is not enforced, secure boot becomes a best-effort mechanism.
And best-effort security fails exactly when it matters most.
<h3>Closing</h3>
Secure boot is not broken because cryptography is weak.
It is broken because systems assume a world that does not exist.
Flash is unreliable. Power is unstable. State is imperfect. Attackers exploit transitions, not primitives.
If your secure boot design does not explicitly account for partial corruption, it is not secure.
It is optimistic.
And optimism is not a security property.

Mayckon Giovani

Secure boot implementations commonly assume firmware exists in only two states: fully valid or completely invalid. Flash memory, however, can fail mid-write due to power loss, brownouts, or bit flips, creating dangerous intermediate states. This analysis covers six major failure modes: treating non-atomic storage as atomic, signature verification without semantic context, boot decision ambiguity from corrupted metadata, rollback protection bypass through counter corruption, inconsistent multi-image/dual-bank systems, and metadata as a single point of failure. Fault injection attacks can deliberately induce these partial corruption states. The recommended fix is modeling secure boot as a full state machine that explicitly represents incomplete states, enforces failure-atomic transitions, verifies the entire boot context including metadata, and upholds the invariant that the system never transitions from a higher-trust to a lower-trust state under any failure condition.

The Failure Modes of Secure Boot Under Partial Flash Corruption