Device security discussions often include: “The firmware is signed, so it is secure.”
That is only partly true. A firmware signature proves that the firmware was authorized by a trusted private key and was not modified. It does not automatically answer whether the firmware is encrypted, whether old versions can be rolled back, whether every boot stage verifies the next stage, how signing keys are protected, or whether the device can recover after update failure.
Secure Boot and OTA verification protect two chains:
boot chain: ROM -> Bootloader -> Kernel -> rootfs / app
update chain: update package -> staging slot -> verified boot target
The core question is not whether there is a signature file. The device must run only code that is authorized, unmodified, and allowed by version policy.
Signatures Protect Integrity and Origin
Firmware signing usually looks like:
firmware image
-> hash
-> sign hash with vendor private key
-> firmware + signature + metadata
The device verifies:
firmware image
-> hash
-> verify signature with trusted public key
-> boot or reject
This protects:
- firmware contents were not modified
- firmware was authorized by the holder of the vendor private key
- an attacker cannot simply repack the image and create a valid signature
A hash alone only provides a fingerprint. A signature binds that fingerprint to a trusted private key.
Signature Is Not Encryption
Signatures protect integrity and origin. They do not protect confidentiality.
If a firmware package is signed but plaintext, an attacker may still read it:
- reverse engineer business logic
- extract strings and interfaces
- analyze protocol implementation
- find vulnerabilities
- copy non-secret resources
The signature prevents modified firmware from being accepted. It does not prevent inspection.
If firmware contents need confidentiality, firmware encryption or key wrapping is required. But encryption does not replace signing. The device still needs to decide whether the image is authorized before or after decryption.
A useful distinction is:
signature: may this image run
encryption: can others read this image
They solve different problems.
Secure Boot Is Step-by-Step Verification
Secure Boot works when each boot stage verifies the next stage.
Typical path:
ROM verifies first-stage bootloader
bootloader verifies second-stage bootloader or kernel
kernel verifies initramfs / rootfs / modules / app policy
system verifies OTA target before switching
The first trust usually comes from chip ROM, a public-key hash in OTP/eFuse, immutable boot ROM logic, or secure boot configuration.
If ROM verifies the bootloader but the bootloader does not verify the kernel, an attacker can still replace the kernel. If the kernel verifies rootfs but arbitrary kernel modules can load, that can also bypass the chain.
Secure Boot is a chain, not a single switch.
Trust Anchor Must Not Be Rewritten by Normal Firmware
A device needs an initial trust anchor, for example:
- vendor public key embedded in ROM
- public-key hash in eFuse/OTP
- verification public key in a secure element
- SoC secure boot configuration
- protected public key in a read-only bootloader area
This trust anchor must not be replaceable by ordinary applications, normal firmware updates, or attackers.
If an unauthorized firmware can replace the public key, an attacker can install their own key and sign their own firmware. The whole chain collapses.
OTA Verification Protects the Update Entry Point
OTA verification decides whether a received update package is authorized by a trusted publisher.
A reliable OTA flow often includes:
download update
-> verify package signature and metadata
-> verify target hardware / product / version
-> write inactive slot or staging area
-> verify written image
-> switch boot target
-> boot and mark success
Update metadata matters. It often contains:
- product model
- hardware version
- software version
- image hash
- partition layout
- minimum acceptable version
- signature algorithm and key id
- package format version
If only the image is signed and metadata is not, attackers may tamper with version numbers, target devices, partition information, or downgrade policy.
Rollback Protection Is a Separate Problem
Signatures do not automatically block old versions.
If an attacker has an old, validly signed firmware package, and the device only checks the signature, the device may accept that old version. The old version may contain known vulnerabilities.
Rollback protection needs a version or security counter:
firmware version / security counter
-> compare with monotonic counter
-> reject lower version
The counter can live in:
- eFuse/OTP
- RPMB
- secure storage
- protected bootloader area
- server-side policy combined with device state
The hard requirement is that the counter itself must not roll back. A version file in ordinary flash cannot provide secure rollback protection if an old image can restore it too.
A/B Update Provides Recovery, Not Security by Itself
A/B partitions are common for reliable OTA:
current slot: A
write update to slot B
verify B
boot B
mark B successful
fallback to A if boot fails
A/B solves recovery after update failure. It does not automatically provide security.
Still required:
- verify signature before writing
- verify image hash after writing
- verify target slot at boot
- prevent rollback to vulnerable old slots
- update security counter after successful boot
- ensure fallback still follows version policy
Do not treat “has A/B” as “has Secure Boot”.
Signing-Key Leakage Affects the Whole Release System
The core secret in Secure Boot and OTA is the signing private key.
Devices usually store only the public key or public-key hash. The release system or HSM stores the private key.
Protect:
- whether private keys live in HSM or offline environments
- whether CI/CD can directly access production signing keys
- whether test keys and production keys are separated
- whether key id and algorithms support rotation
- whether devices can trust a new key after leakage
- whether old keys can be disabled
- whether manufacturing images accidentally include test public keys
If production devices trust a test private key, anyone with the test key can sign runnable firmware.
Verification Failure Must Stop the Trust Path
Continuing to boot after signature failure is a common Secure Boot break.
Dangerous behavior includes:
- signature failure only prints a warning
- debug mode remains enabled on production devices
- failure opens a writable shell
- fallback to an unverified partition
- network update failure runs an unverified cached package
- some partitions get only a hash check but no trusted signature source
Production failure policy must be explicit: reject boot, enter restricted recovery, wait for a trusted recovery package, or fall back only to a verified slot allowed by version policy.
Debugging Order
For replaceable firmware, rejected OTA packages, rollback problems, repeated A/B switching, or boot failure after enabling Secure Boot, inspect:
is the trust anchor protected from normal firmware writes
-> does ROM verify the first-stage bootloader
-> does bootloader verify kernel / next stage
-> does kernel restrict rootfs, modules, and critical app loading
-> is OTA metadata covered by the signature
-> does written image hash match signed metadata
-> is rollback counter protected from rollback
-> does A/B fallback still follow version policy
-> are test keys excluded from production trust
-> does signature failure stop boot or enter restricted recovery
Secure Boot and OTA verification protect that the device runs only authorized, unmodified code allowed by version policy. A signature is not encryption and not automatic rollback protection. It has to work with a trust anchor, staged verification, metadata, counters, A/B recovery, and signing-key management.