Firmware Signing vs Encryption: Secure Updates, Secure Boot, and Read-Only Embedded Systems

Imagine an industrial controller receiving a firmware update over Ethernet, or a technician inserting a USB stick into an embedded Linux gateway. How does the device know the file came from its manufacturer? Can someone replace it with malicious code? Can a competitor read the software? What happens if power fails halfway through installation?

These are different problems. Signing proves authorization and detects modification. Encryption protects confidentiality. A reliable update mechanism protects recoverability. A product often needs all three, but they are not interchangeable.

This guide explains the choices for embedded Linux, bare-metal firmware, and RTOS-based microcontrollers. The practical starting recommendation is: use signed updates and a protected boot chain; add firmware encryption when the threat model actually requires secrecy.

For the broader download, installation, and A/B workflow, see OTA Firmware Updates: How to Update Embedded Devices Safely.

The Short Answer

A signed file may be public. An encrypted file may still be unauthorized. A signed and encrypted file may still contain a serious bug.

Why We Need Firmware Protection

A firmware update replaces software that may control network access, credentials, sensors, actuators, or an entire operating system. Accepting arbitrary update files gives an attacker a direct path to persistent control.

Consider these concrete threats:

• A compromised download server distributes a modified image.
• Someone substitutes a different file on a service USB stick.
• A person with physical access rewrites removable storage after installation.
• An attacker installs a genuine but old release containing a known vulnerability.
• A copied update exposes proprietary algorithms or model data.
• A legitimate release targets the wrong board revision or fails during a power interruption.

The last case is not necessarily an attack. Secure updates must address both deliberate interference and ordinary operational failures.

Security, safety, and reliability are related, not identical

Security concerns unauthorized access or changes. Functional safety concerns unacceptable risk from malfunction. Reliability includes staying usable after interrupted writes or failed boots.

A valid signature cannot prove that a motor controller uses a safe limit or that a medical device meets a safety standard. Security controls can support a safety argument, but they do not replace hazard analysis, validation, or the required certification process.

For safety-related equipment, define when updating is permitted, how outputs enter a safe state, what happens during reboot, and how verification failure affects operation. Repeatedly rebooting on an integrity error may be unacceptable if the device controls a physical process.

Digital Signing Explained Without the Mathematics

A digital signature is like a manufacturer seal that is mathematically tied to the exact contents of the package. Changing the protected contents makes verification fail.

The manufacturer has two related keys:

• Private signing key: Kept in the release-signing infrastructure. It authorizes releases and must not be shipped in devices.
• Public verification key: Provisioned into the device, or trusted through a certificate chain. It can verify signatures but cannot create them.

The release system signs the image or an authenticated manifest containing its digest. The device verifies that signature using a key it already trusts. It must reject an attacker-supplied public key unless that key is authorized by an existing trust anchor.

The public key does not need secrecy. It needs integrity: if someone can replace the device’s trusted public key, they can install their own signed firmware.

What should the signature cover?

Protect not only the payload but also the metadata that determines how it is used:

• Product identifier, hardware revision, and component identity
• Payload digests, sizes, and installation destinations
• Release version and security counter
• Dependencies between bootloader, kernel, root filesystem, and MCU firmware
• Any executable installation hooks or scripts
• Relevant encryption parameters and recipient metadata, as specified by the chosen format

For example, an attacker must not be able to move an authorized MCU image into a Linux bootloader slot simply by editing an unsigned filename or destination field.

Prefer an established image or bundle format rather than designing a signature footer and parser yourself. RSA, ECDSA, and EdDSA are common signature families; choose the algorithms and parameters supported by the boot ROM, bootloader, update framework, and applicable requirements. Verification cost and image overhead matter on small MCUs.

Is a hash enough?

Not when an attacker can replace both the firmware and its advertised hash. SHA-256 detects a change only when the expected digest comes from a trusted source. A signature provides that authenticated reference.

A MAC such as HMAC can authenticate data to parties sharing a secret, but every verifier holding that secret may also be able to forge it. Public-key signatures are usually a better fit when thousands of devices should verify releases without possessing the manufacturer’s signing capability.

Encryption Explained Simply

Encryption makes firmware unreadable without the appropriate decryption key. It can protect an update stored on a public server, a service USB stick, or external staging flash.

It answers “Who can read this?”, not necessarily “Who approved this release?”

Authenticated encryption, such as AES-GCM in a correctly designed format, detects changes and authenticates data relative to its encryption key. That still is not the same trust model as a manufacturer signature. If a device holds a shared encryption secret, extracting that secret may allow forgery under a symmetric-only design.

Use separate signing and encryption keys. A confidentiality-key compromise should not automatically give an attacker release-signing authority.

Hybrid encryption: practical for large images

An established encrypted-update format commonly uses this approach:

1. Generate a fresh random symmetric content key for the update.
2. Encrypt the large firmware payload with that key.
3. Wrap or encrypt the content key for the intended recipient devices.
4. Authenticate the image and relevant metadata using the format’s prescribed mechanisms.

The device recovers the content key using its decryption credential, decrypts the payload, and verifies authorization according to the format. Do not invent the wrapping scheme, nonce construction, or key derivation yourself.

Where is the firmware actually confidential?

Encrypting the delivery package does not automatically encrypt the installed root filesystem. Do not promise resistance to firmware extraction without examining debug access, flash readout, DMA, memory access, and the actual hardware threat model.

Avoid embedding passwords, production credentials, or fleet-wide secrets in firmware, even if the update package is encrypted. Provision device-specific credentials through a separate protected process.

Signing Only or Encryption Plus Signing?

Signing only: a strong default for authenticity

For a gateway whose software does not require confidentiality, signing-only updates can be the right choice. Combine them with secure boot, protected trust anchors, rollback policy, and a reliable installation process.

Advantages: Simpler manufacturing, no firmware-decryption secret to provision, easier field diagnostics, and straightforward distribution of the same signed artifact to a fleet.

Limitations: Anyone possessing the update can inspect it. Signing alone does not hide proprietary code, keys accidentally included in the image, or installed storage contents.

Encryption plus signing: add a concrete confidentiality requirement

A controller containing valuable proprietary algorithms may need signed and encrypted updates, especially when images pass through distributors or untrusted removable media.

Advantages: Prevents casual inspection of protected update contents and can restrict decryption to intended recipients while retaining manufacturer authorization.

Limitations: Adds key provisioning, rotation, recovery, storage, and processing costs. A compromised authorized device may still reveal plaintext. Lost decryption credentials can prevent future updates.

Encryption without manufacturer authorization

Encryption alone is not an adequate general-purpose release-authorization policy. Do not equate “the device successfully decrypted it” with “the manufacturer approved it.” Use the framework’s authenticated, signed image format and enforce its trust policy.

Should We Sign Before or After Encryption?

There is no universal command order that applies to every firmware format.

One format may sign the plaintext image and verify it while decrypting. Another may authenticate a signed manifest and a ciphertext hash tree. Encrypt-then-sign can permit signature verification before payload decryption, but only if the package binds all required metadata correctly.

Use the ordering defined by the selected implementation. MCUboot signs/hashes the unencrypted image contents and validates encrypted images through its decryption path. RAUC’s crypt format uses an encrypted payload with verity protection and an encrypted signed manifest.

For a custom envelope, use a reviewed design with authenticated encryption where appropriate, strict length bounds, and authenticated metadata. Nonce reuse with the same key can break security in common encryption modes. Decryption errors must not release executable plaintext or activate a partially authenticated image.

Large images may be authenticated incrementally. Writing unverified bytes into an isolated inactive slot can be part of a documented streaming design; making them executable or activating that slot before complete authorization is not.

Signed Updates and Secure Boot Solve Different Problems

Update verification checks a package during installation. Secure boot checks software before execution. If someone rewrites flash after installation, a one-time update check will not detect the later change.

A Linux boot chain might look like this:

Protected ROM trust anchor
  -> authenticated first-stage bootloader
  -> authenticated later bootloader / trusted firmware
  -> authenticated kernel + device tree + initramfs + boot policy
  -> trusted dm-verity root hash
  -> verified read-only root filesystem

The exact chain depends on the SoC. Some devices store a public-key digest in OTP or eFuses; others provide different protected trust mechanisms. Authentication must cover every relevant transition, not just the final kernel file.

U-Boot FIT signatures or UEFI Secure Boot may provide part of this chain when correctly configured. Neither automatically proves that the preceding stage is trusted or that the entire Linux rootfs is protected. Measured boot records measurements for attestation; measurement alone does not necessarily refuse execution.

Also close bypasses: unsigned recovery images, alternate SD/USB boot modes, an unrestricted bootloader console, mutable boot arguments that disable verification, unprotected keyrings, and production debug ports. Follow the vendor’s provisioning procedure carefully: some fuse settings are irreversible and can permanently disable recovery.

Read-Only Filesystems: Useful, but Not a Signature

A Linux filesystem mounted read-only reduces accidental writes and makes immutable image updates easier to reason about. SquashFS is read-only by design; ext4 can also be mounted read-only.

However, read-only is a write policy, not proof of authenticity. A privileged attacker may remount a suitable filesystem, write its underlying block device, or alter removable media on another machine. SquashFS compression does not provide cryptographic integrity.

dm-verity: check blocks against a trusted image

dm-verity verifies blocks as they are read using a cryptographic hash tree. Its root hash represents the expected contents of the immutable image.

The crucial condition is that the root hash and verification configuration must themselves be authenticated. If an attacker can replace both the filesystem and the expected root hash, the new malicious image can pass its own checks.

Bind the root hash to a signed boot artifact or use the kernel’s supported root-hash signature verification path with a protected trust policy. Ensure boot arguments cannot simply select an unverified root device.

dm-verity detects altered blocks when read; it does not encrypt them or prevent every physical write. Define the response to corruption: I/O failure, authenticated recovery, or another controlled action. Do not silently ignore corruption in a security-enforcing design.

dm-crypt, fs-verity, and IMA are different tools

• dm-crypt/LUKS: Storage confidentiality when keys are properly protected. Common default disk-encryption configurations do not provide equivalent per-block authenticity to dm-verity.
• fs-verity: Integrity checking for individual supported files, with a trusted digest/signature policy supplied by the consuming application or enforcement mechanism.
• IMA appraisal: Can enforce file integrity/authenticity under a configured policy and trust model; it is not enabled merely by having Linux installed.

Verified immutable system images and encrypted writable data can coexist. Layering encryption and integrity requires a documented design and a tested boot/key-unlock flow.

A Practical Embedded Linux Storage Layout

Protected boot chain and verification policy
Boot A + rootfs A + verity metadata A
Boot B + rootfs B + verity metadata B
Persistent data: configuration, databases, device identity
Volatile storage: /run, /tmp, bounded temporary logs
Authenticated recovery path

Keep the active rootfs read-only. The updater writes the inactive slot’s underlying storage; it does not need to make the active root filesystem writable. After verification, select the new slot for a trial boot and confirm it only after meaningful health checks.

What about writable /etc and /var?

Use dedicated writable directories, selected bind mounts, or carefully scoped overlays for the state that genuinely needs persistence. Use tmpfs for transient state where losing it on reboot is acceptable. Plan machine identity, SSH host keys, time state, logs, and network settings rather than assuming a fully read-only /etc works unchanged.

A persistent overlay can undermine a verified lower filesystem. An attacker may place a replacement executable or service configuration in the writable upper layer. dm-verity still validates the lower image, but Linux can use the upper replacement instead.

Do not allow writable state to shadow trusted executables or security policy without an explicit integrity model. Keep data out of executable search paths, validate configuration, enforce permissions, and consider nodev, nosuid, and noexec where appropriate. noexec alone does not stop an interpreter from reading a script from that filesystem.

Practical Example 1: See What a Signature Actually Does

This disposable workstation demonstration, using OpenSSL and an existing test file named firmware.bin, shows signing and verification. It is not a production updater or an MCU image format. It creates an unencrypted demo private key; never use it as a release key.

openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 -out demo-signing-private.pem
openssl pkey -in demo-signing-private.pem \
  -pubout -out demo-signing-public.pem

openssl dgst -sha256 -sign demo-signing-private.pem \
  -out firmware.sig firmware.bin

openssl dgst -sha256 -verify demo-signing-public.pem \
  -signature firmware.sig firmware.bin

Verification reports Verified OK for the matching bytes. Make a copy, change it, and verify using the original signature:

cp firmware.bin firmware-modified.bin
printf '\001' >> firmware-modified.bin
openssl dgst -sha256 -verify demo-signing-public.pem \
  -signature firmware.sig firmware-modified.bin

The modified file must fail verification. The firmware itself remains readable throughout: the signature has not encrypted it. A real release format must also protect the hardware identity, versions, destinations, and other metadata described earlier.

Practical Example 2: Signed Linux Updates With RAUC

RAUC is an established Linux image-update framework. A minimal illustrative bundle manifest inside an existing bundle-input directory can look like this:

[update]
compatible=example-gateway-v1
version=2.4.0

[bundle]
format=verity

[image.rootfs]
filename=rootfs.ext4

Create a signed bundle on the release host with a pre-provisioned signing certificate and key:

rauc bundle --cert=release-cert.pem --key=release-key.pem \
  bundle-input update.raucb
rauc info --keyring=release-ca.pem update.raucb

On the device, rauc install update.raucb is an installation operation, not a harmless inspection command. Use it only on a configured test target with the correct slot layout, keyring, bootloader integration, and recovery plan. The commands here do not create that configuration.

RAUC’s verity bundle protection is not automatically dm-verity protection for the installed rootfs. Runtime rootfs verification must be designed separately; an ext4 image extracted from a verified bundle is not automatically immutable or verified at boot.

For encrypted delivery, supported RAUC versions provide format=crypt. The documented workflow creates the crypt bundle and then encrypts its signed manifest for recipient certificates:

rauc bundle --cert=release-cert.pem --key=release-key.pem \
  bundle-input crypt-stage.raucb
rauc encrypt --to=recipient-certs.pem --keyring=release-ca.pem \
  crypt-stage.raucb encrypted-update.raucb

This second example assumes the manifest has been changed to format=crypt. Do not publish the intermediate crypt-stage.raucb: its signed manifest still exposes the payload encryption key. Publish only the finalized encrypted bundle. The target needs a configured recipient decryption key, appropriate kernel support, and the signing trust policy. Check the documentation for the exact RAUC release you deploy.

Practical Example 3: Signed MCU Firmware With MCUboot

For a Cortex-M device running an RTOS or bare-metal application, MCUboot provides established image verification and update mechanisms on supported ports.

A typical design is:

1. Provision the trusted verification key or key digest through the port’s protected mechanism.
2. Use MCUboot’s imgtool to produce an image with the required header, signature, version, and layout parameters.
3. Transfer it into the secondary slot over the chosen transport.
4. Let the configured bootloader validate and perform the supported upgrade procedure.
5. Use trial/confirmation behavior where supported so an unhealthy image can revert.

Header size, slot size, alignment, signing algorithm, and upgrade mode must match the built bootloader. Do not copy a signing command from another board without checking those parameters.

MCUboot also supports encrypted images, with important boundaries: in the documented secondary-to-primary upgrade flow, firmware is decrypted into the primary slot. This protects transport or external staging storage, not against reading decrypted execution flash through JTAG or a runtime vulnerability.

The encryption documentation also calls out scratch-area key handling: where scratch is external, configurations such as MCUBOOT_SWAP_SAVE_ENCTLV matter to avoid exposing plaintext decryption keys. Review the complete threat model for the selected upgrade mode and version.

Key Management: Where Most Designs Become Difficult

Signing keys

Protect production private signing keys using an HSM or suitably controlled signing service where practical. Separate development and production trust. Restrict release authorization, keep audit records, and retain tested backups or recovery capabilities according to policy.

A protected key does not make an untrusted build safe. Protect build inputs, dependencies, CI permissions, and release approval; an attacker who can persuade the signing service to approve malicious code does not need to extract its key.

Decryption keys

Use hardware-backed keys when the platform and chosen algorithms support them. A TPM, secure element, or TEE is not a universal fix: check whether it supports the required operations, whether plaintext reaches normal RAM, and which compromised software can request decryption.

Do not store a decryption key beside the ciphertext on freely readable flash. Do not reuse firmware-signing keys for TLS identity or encryption. Do not print secrets in update logs, CI output, or diagnostic exports.

Rotation, revocation, and devices that are offline for years

Plan a transition that authorizes the new key before removing the old one, while keeping recovery paths compatible. Revocation requires a protected way to update policy; disconnected devices cannot magically learn that a key was compromised.

Certificate-based systems also need a trustworthy time policy. A reset RTC can complicate expiry checks, while disabling checks without a considered alternative weakens the design. Test long-offline devices and expired credentials explicitly.

Anti-Rollback vs Recovery Rollback

A genuine old release still has a valid signature. Without anti-rollback policy, an attacker may reinstall it to restore a known vulnerability.

Use authenticated security-version metadata and enforce a minimum permitted security level using protected state, such as an appropriate monotonic counter or authenticated storage supported by the platform. A normal writable version text file is not a robust trust anchor.

Recovery rollback returns to a known-good slot after a failed trial. Anti-rollback blocks versions below a security floor. Design them together: raising an irreversible security counter too early can make the only working fallback image unbootable.

Specify when counters advance, which fallback images remain authorized, what happens if power fails during the transition, and how authenticated recovery works. A signed version field alone does not implement this policy.

For Linux-plus-MCU products, check cross-component compatibility. Linux rolling back while the MCU remains upgraded can break the product, and MCU anti-rollback may prevent simply restoring its old firmware.

What Signing and Encryption Still Do Not Solve

• Bad authorized releases: Use testing, staged rollouts, and post-boot health checks.
• Power loss: Use documented atomic or recoverable writes, trial boots, and robust boot metadata.
• Writable data migrations: Preserve compatibility or snapshots so fallback software can still read persistent state.
• Runtime exploitation: Patch vulnerabilities, isolate services, minimize privileges, and harden debug and network interfaces.
• Freeze attacks: A server can withhold new updates even if it cannot forge them. Define freshness policy and trusted-time assumptions; frameworks such as TUF address update metadata threats.
• Physical attacks outside the design: Debug lockdown and device-bound keys help, but sophisticated extraction, fault injection, and side channels require a specific hardware assessment.

Bootloader and trust-policy updates deserve particular care. A/B rootfs slots cannot recover from every broken earlier boot stage. Factory programming, service recovery, and offline installation must enforce the intended policy too, rather than becoming unsigned backdoors.

Production Test Checklist

• A one-byte payload change is rejected.
• Modified metadata, wrong hardware identity, and oversized or malformed packages are rejected safely.
• A development key and an unknown signer cannot authorize production firmware.
• Old signed releases below the security floor are rejected through every supported install/boot path.
• Alternate boot media, recovery, debug access, and boot arguments cannot bypass verification.
• Power cuts during download, decryption, writing, slot selection, and confirmation preserve recoverability.
• Unhealthy trial boots fall back to a compatible, authorized image with readable persistent data.
• Key rotation, revocation, expiry, and lost-key scenarios work on long-offline devices.
• Encrypted staging, scratch, temporary files, crash dumps, and logs do not expose unexpected plaintext or keys.
• Installed rootfs tampering is detected under the selected integrity policy, not merely at update time.
• Writable overlays and configuration cannot silently replace trusted code or disable protection.
• Integrity failures and update reboots place physical equipment in the required safe state.

Conclusion

Start with the requirement, not the cipher name. If the goal is to prevent unauthorized firmware, signatures and a protected verification chain are fundamental. If the goal also includes hiding firmware in delivery or storage, add encryption with a realistic key-management and extraction threat model.

For embedded Linux, signed updates, verified boot, a dm-verity-protected immutable rootfs, separate writable data, and a recoverable A/B process form a useful architecture when the hardware and product requirements support it. For MCUs, use a supported secure bootloader and image format with protected keys, appropriate rollback policy, and power-loss-tested installation.

The strongest practical design is not simply “encrypt everything.” It is one that verifies authorization, protects secrets where needed, survives failure, and remains maintainable throughout the product’s life.

References

• NIST SP 800-193: Platform Firmware Resiliency Guidelines - Protection, detection, and recovery principles for firmware.
• IETF RFC 9019: A Firmware Update Architecture for Internet of Things - Firmware-update roles, requirements, and architecture.
• RAUC Advanced Topics - Signing trust, encryption workflows, key management, and data migration.
• RAUC Reference - Bundle formats and target configuration.
• MCUboot Signed Images - Image format and signature handling.
• MCUboot Encrypted Images - Encryption design, threat model, and scratch-area considerations.
• Linux Kernel dm-verity Documentation - Read-only block integrity and root-hash trust.
• U-Boot FIT Signature Verification - Signed boot images and verification-key handling.
• The Update Framework Specification - Signed update metadata, key roles, and rollback/freeze attack protections.