Signing Firmware: Build -> Sign -> Package -> Deploy

Signing firmware in real release pipelines

Good secure boot depends on release discipline as much as bootloader code.

What gets signed

At minimum:

• First-stage / second-stage bootloader artifacts (platform dependent)
• Kernel image
• DTB(s)
• Initramfs (if used)
• OTA package metadata and payload manifests

In stronger setups:

• Rootfs image hash tree metadata (dm-verity root hash signed in manifest)
• Recovery image

Who signs

• CI pipeline never owns long-lived private key material directly.
• Signing happens in controlled signer service/HSM-backed workflow.
• Developer keys are for local testing only and must be blocked from production channels.

Practical CI/CD flow

1. Build artifacts (u-boot.itb, Image, *.dtb, rootfs, OTA bundle).
2. Generate manifest with artifact hashes + version.
3. Send manifest for signing (release key only after approvals).
4. Package signed manifest + artifacts.
5. Deploy to update backend.
6. Device verifies signature + version gates before install/boot.

Public key provisioning to device

• Root key hash in ROM anchor (fuse/OTP).
• Bootloader keyrings embedded and versioned.
• Rotatable intermediate/release keys allowed by rooted policy.

Signature mismatch behavior

• Do not "boot anyway."
• Fail closed with explicit reason code.
• Attempt fallback slot if A/B available.
• Enter restricted recovery requiring authenticated image.

Pseudo commands (conceptual)

# Build FIT image with kernel + dtb
mkimage -f fit.its firmware.itb

# Sign FIT image with release key
mkimage -F -k keys/release -r firmware.itb

# Verify in U-Boot
bootm <addr>  # U-Boot checks signature before boot

Practical takeaway

Secure boot is a product of both boot-time verification and release-time key governance.

Misconception to correct

"Signing is just a final build step."
No. It is a controlled security process with approvals, key isolation, and policy enforcement.