Ship a Bluetooth module with unsigned firmware and you have implicitly trusted anyone who can flash it. A competitor clones your product, an attacker drops a backdoor, or a bad OTA bricks the field — and you cannot tell the difference between your image and theirs at boot time. Secure boot closes that gap: the hardware cryptographically verifies a signature before any code is allowed to run. This article is the engineering side — root of trust, the signature chain, key provisioning, anti-rollback, secure OTA, debug lockdown, and the tradeoffs you sign up for.
Why secure boot exists
The threats are concrete:
- Cloning. An unsigned image can be read off one unit and flashed onto a thousand counterfeits.
- Malicious OTA. If the update channel is not authenticated, anyone who reaches it owns the device.
- Supply-chain tampering. A compromised build server or contractor ships code you never wrote.
- Persistent implant. A bootloader-level implant survives app updates because the app verifier runs *under* it.
Without secure boot the only boundary is “can the attacker physically flash or reach the port”. With it, the boundary becomes “does the attacker hold the private signing key”.
Root of trust
Everything rests on an immutable ROM bootloader burned into the silicon at manufacture. It contains the vendor’s verification logic and a one-time-programmable slot (OTP / eFuse) holding the *hash of your public key* — never the private key.
- The private key lives only on an offline signing server and never touches the device.
- The chain of trust runs ROM -> bootloader -> application. Each stage verifies the signature of the next before handing over control.
A standard layout:
ROM (fixed) --verifies--> Bootloader (signed) --verifies--> Application (signed)The signature scheme
The mechanism is asymmetric signing:
1. The image is hashed (SHA-256) and the hash is signed with your private ECDSA P-256 (or Ed25519) key offline.
2. The bootloader, on power-up, recomputes the hash and verifies the signature against the public key it trusts.
3. Only if verification passes does it jump to the image.
Storing the full public key in eFuse wastes scarce bits, so most designs store a SHA-256 of the public key. The bootloader first checks that the key in the image matches the eFuse digest, then verifies the signature with that key.
A minimal verify:
def verify_image(img, pk_digest, sig):
if sha256(img.public_key) != pk_digest:
return FAIL # wrong key
if not ecdsa_verify(img.public_key, sig, sha256(img.code)):
return FAIL # bad signature
return OKAnti-rollback
A signed image is not enough if an attacker can flash an *old, vulnerable* signed image you shipped last year. The fix is a monotonic version counter in eFuse:
- The image carries a version number; the device stores the highest version it has run.
- Boot refuses an image whose version is lower than the stored counter.
- eFuse bits are one-way, so the counter plan must be fixed before production — you cannot “add more” later.
Secure OTA
The same signature that protects the factory image must protect updates. The flow:
1. CI signs the new image with the offline key; the device verifies it on download.
2. Use a dual-bank layout: write the update to slot B, verify, then swap. If verification fails, slot A keeps running — no brick.
3. The OTA signing key must match the eFuse key, so the update channel is authenticated end-to-end.
Debug interface lockdown
A Bluetooth module with SWD/JTAG left open is an open book: full code read and reflash. Secure boot is only as strong as the debug port:
- Lock the debug interface after provisioning.
- Provide a controlled re-open — typically “erase-all-to-unlock” or a challenge-response — so returns/RMA can be wiped but never read out.
- A comparison of common implementations:
| Control | nRF Secure Boot (NSIB) | ESP32 Secure Boot v2 | Generic eFuse SoC |
|---|---|---|---|
| Key store | eFuse hash of pubkey | eFuse pubkey digest | OTP hash |
| Signature | ECDSA P-256 | RSA-3072 / ECDSA | ECDSA |
| Anti-rollback | Monotonic counter | Version in eFuse | Manual |
| Debug lock | CTRL-AP lock | JTAG disable eFuse | SWD lock |
| Secure OTA | MCUBoot / SUIT | Native | Custom |
Crypto hardware on the module
Modern BLE SoCs ship the primitives you need: a TRNG, AES, and ECDSA accelerators (nRF52/53, ESP32, DA1459x). A signature verify on a Cortex-M4 takes tens of milliseconds and draws mA-scale current for that burst — trivial against a boot that happens once. Use the vendor bootloader libraries; do not hand-roll the crypto.
Tradeoffs and failure modes
Secure boot is not free:
- Brick risk. Lose the private key and you can never sign again — no more field updates. Key custody is the single most important asset.
- No downgrade. A bad new version cannot be escaped by flashing the old one (the counter blocks it). You must push a *newer* fixed build.
- Provisioning yield. eFuse burns are one-way; a misburn bricks the unit on the line. Validate the golden unit before mass burning.
- Recovery. Plan a signed “recovery” image path up front; retrofitting one later is hard.
What an OEM must do
If you build a Bluetooth module that leaves your factory, the minimum:
1. Generate the key pair on an offline HSM / signing server. The private key is never on a developer laptop or CI runner.
2. Burn the public-key hash to eFuse in a protected provisioning step; verify on a golden unit before mass production.
3. Sign every artifact — bootloader, application, OTA — in CI with the offline key.
4. Enable anti-rollback and lock the debug port.
5. Keep a recovery path (signed recovery image) and a key-rotation / revocation plan.
Bottom line
Secure boot moves trust from “who can flash” to “who holds the key”. It is cheap to add at design time and nearly impossible to retrofit. Build it in, lock the debugger, and guard the private key like the crown jewels — because to an attacker, your firmware signature is the only thing standing between them and your product.
