Secure Firmware Updates with a Secure Element: Building Trust Into the Bootloader

Imagine your embedded device is deployed somewhere in the field - a smart meter, an industrial sensor, a vehicle ECU. You find a critical bug. You push a fix. The device downloads the new firmware over the air and flashes it.

But here's the uncomfortable question: how does the device know that firmware actually came from you?

Anyone sitting on the same network could send a firmware package. A compromised update server could serve a malicious binary.

Without a proper trust mechanism, your device is one bad OTA away from running someone else's code.

This is the problem a Secure Element solves - and this post walks through exactly how it works, from the chip itself to the bootloader verification flow.

What Is a Secure Element?

A Secure Element (SE) is a small, tamper-resistant chip whose one job is to safely store cryptographic keys and run crypto operations - without ever exposing those keys to the outside world.

Think of it as a locked safe soldered onto your board. Even if an attacker gets full control of your main CPU, dumps your flash, or probes your bus lines, the keys inside the SE remain out of reach.

It protects against:

• Physical attacks (chip probing, decapping, glitch injection)
• Software attacks (privilege escalation, memory dumps)
• Side-channel attacks (power analysis, timing attacks)

Common SE chips used in embedded systems: ATECC608A, SE050, TPM 2.0.

What Can a Secure Element Do?

A secure element is not just a key storage box - it is a self-contained cryptographic engine. Here is what it can do:

1. Key generation and storage** - private keys are created and stored inside the chip and never leave it, not even during factory programming

2. Digital signatures (ECDSA - Elliptic Curve Digital Signature Algorithm / Ed25519) - signs or verifies data using stored keys; the core operation behind firmware verification

3. Key agreement (ECDH - Elliptic Curve Diffie-Hellman) - two parties derive a shared encryption key from exchanged public keys, without the secret ever crossing the wire

4. Symmetric encryption (AES - Advanced Encryption Standard) - encrypts and decrypts data directly on-chip; used to protect firmware package contents in transit

5. Hashing (SHA-256 - Secure Hash Algorithm) - computes a fixed 32-byte fingerprint of any data; one byte changed equals a completely different hash

6. True random number generation (TRNG) - hardware entropy source for generating nonces, session keys, and signature randomness

7. Monotonic counter - a number that only goes up, never down, even across power cycles; blocks firmware downgrade attacks

8. Certificate storage - stores X.509 certificates to prove device identity during TLS(Transport Layer Security) or OTA authentication

Why Firmware Updates Need Signature Verification

When a device receives an OTA update, it has no way of knowing by default whether that firmware is genuine or has been tampered with.

An attacker could:

• Intercept the OTA transfer and swap in malicious firmware
• Replay an older, vulnerable firmware version
• Extract a key from plain flash memory, sign a fake binary, and serve it

Signature verification closes this. The firmware is cryptographically signed by the manufacturer before it ever leaves the build system. The bootloader verifies that signature on the device before touching a single flash sector. If verification fails, nothing gets flashed.

The Secure Element is what makes this guarantee solid - the verification key lives inside hardware-protected storage, not in flash memory where it can be read or replaced.

The Verification Flow - Step by Step

On the Manufacturer Side

1. Firmware binary is compiled, and a version header is attached (version number, hardware revision, and magic bytes).
2. A SHA-256 hash of the entire firmware is computed - a fixed 32-byte fingerprint of the binary.
3. That hash is signed using an ECDSA private key stored in a Hardware Security Module (HSM - Hardware Security Module) on the build server. The result is a signature.
4. Package is uploaded to the OTA server. The final package ships as:

{ firmware binary + version header + ECDSA signature }

On the Device Side - Inside the Bootloader

1. Firmware package arrives and is written to a staging area in flash.
   (Primary firmware slot is untouched at this point.)

2. Bootloader reads the firmware header:
   - Magic number   → is this a valid package format?
   - Hardware rev   → is this firmware built for this exact hardware?
   - Version number → is this newer than what is currently running?

3. Bootloader computes SHA-256 over the full firmware binary.
   → 32-byte hash of exactly what was received.

4. Bootloader hands the hash + the signature to the Secure Element:
   SE.verify(hash, signature, public_key)

5. Secure Element runs ECDSA verification internally:
   - Uses the public key it has stored inside it
   - Mathematically checks whether the signature was produced
     by the matching private key over this exact hash
   - Returns PASS or FAIL - nothing else leaves the SE

6a. PASS:
    → Erase the primary firmware slot
    → Copy firmware from staging to primary slot
    → Increment the SE monotonic counter (locks out older versions)
    → Reboot and jump to new firmware entry point

6b. FAIL:
    → Erase the staging area
    → Boot the existing firmware as a safe fallback
    → Log the failure for reporting on next server connection

The key insight: the private key that signed the firmware on the build server never exists on the device. Only the public key is on the device - locked inside the SE. A public key can verify signatures but cannot create them. So even if an attacker fully dumps the device's flash, they cannot forge firmware that passes verification.

Anti-Rollback: Why a Valid Signature Is Not Enough

Here is a subtle attack worth understanding. Firmware v1.2 had a vulnerability - you patched it in v1.3. But v1.2 was real firmware, signed by your real private key. Its signature is completely valid.

An attacker replays the old v1.2 package. Signature check passes. Device flashes vulnerable firmware. You are back to square one.

The fix is the SE monotonic counter - a number stored inside the SE that only ever increments.

SE stores: minimum_allowed_version = 1.3

Bootloader receives firmware v1.2:
  1.2 < 1.3  →  REJECTED, even though signature is valid.

After successfully flashing v1.4:
  SE increments counter → minimum_allowed_version = 1.4
  This cannot be undone by software.

Because the counter is inside the SE, no software attack - not even a full OS compromise - can reset it.

Conclusion

Firmware security is not just about encryption or passwords. It is about establishing a chain of trust - from the moment code leaves your build system to the moment a device executes it.

The Secure Element is the hardware anchor of that chain. The private key stays with you. The public key stays locked in silicon on the device. The bootloader does the verification. And the monotonic counter makes sure there is no going back.