TFA-105 — Bootloaders & Secure Updates

Before you begin: TFA-102, TFA-106 and an understanding of hashes versus digital signatures.

Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.

Learning objectives

By the end of this module, you should be able to:

Describe a boot chain and its trust decisions.
Specify authenticity, integrity, compatibility and anti-rollback controls.
Design update states for power loss and interrupted transfer.
Define release, service and verification evidence for field updates.

Lesson 1

1. A bootloader makes a release decision

The bootloader decides which image is allowed to control the device. A secure design verifies authenticity and integrity before execution, checks that the image is intended for the hardware and enforces lifecycle rules such as minimum permitted version. Secure boot is a chain: each stage verifies the next using a trust anchor protected from ordinary software.

A checksum detects accidental corruption; it does not establish who produced the image. Authenticity normally requires a digital signature verified with a trusted public key.

Lesson 2

2. Define the update package and authority

Specify the signed material: image bytes, target product, hardware revision, version, security counter, configuration compatibility and package format. Define who may authorise an update, how signing keys are protected and how compromised or obsolete keys can be replaced.

Encryption may protect confidentiality, but it does not replace signature verification. Many devices need authentic updates even when the firmware itself is not secret.

Lesson 3

3. Design for interruption

An update is a state machine with durable checkpoints. A dual-bank design can write and verify a candidate without destroying the running image. A single-bank design needs another recovery mechanism. Define behaviour for loss of power during download, erase, programming, verification, activation and first boot.

A candidate should become permanent only after it passes cryptographic checks and any required start-up self-test. Failed activation must lead to a known recovery path rather than a boot loop.

Lesson 4

4. Control the lifecycle

Updateability creates ongoing obligations: vulnerability assessment, compatibility evaluation, release approval, distribution control, installation records and confirmation of installed versions. Design diagnostics so support can distinguish transfer failure, signature failure, incompatible package and application failure.

Lesson 5

5. Separate transfer, installation and activation

Receiving every byte does not mean an update is accepted. Treat download storage as untrusted until the complete package and signed metadata have been verified. Check target identity, image size, memory boundaries and supported format before using fields to control writes. Even signed packages need robust parsing because transport data can be malformed before verification.

Installation prepares a candidate image and any compatible configuration. Activation selects it for execution. Confirmation decides that it may become the normal image. Record these decisions durably with a scheme that detects torn writes; one mutable flag is vulnerable if power fails during programming.

For each durable state, specify what the next boot does. Recovery must work from physical flash contents, not a RAM variable lost on reset. Device-specific flash erase and programming guarantees determine which transactional design is credible.

Lesson 6

6. Resolve anti-rollback and recovery together

A security counter is not merely a human-readable version. It records the minimum permitted security level or update generation according to the product policy. If it advances before a candidate is known to work, the previous image may become forbidden and ordinary fallback may fail.

Choose when the irreversible floor advances and ensure an allowed recovery image remains available. This may require confirming the candidate first, updating both recovery and application, or using a protected recovery path that enforces equivalent security. Do not weaken the signature requirement to rescue a failed update.

Configuration migration adds another transaction. A candidate that rewrites persistent settings into an incompatible format may prevent the previous image from operating even if its code remains intact. Use versioned records, copy-on-write migration or a deliberately one-way update with an independently validated recovery procedure.

Lesson 7

7. Design the verification matrix

Test invalid signatures, unexpected keys, incompatible hardware, truncated images, oversized metadata, downgrade attempts and valid packages with failing self-test. Include interruption during metadata writes as well as image writes.

Update phase	Fault injection	Required observation
Download	Disconnect and corrupt a block.	Running image remains usable; package is not activated.
Installation	Cut power during erase/program.	Next boot selects a valid image or defined recovery.
Trial boot	Reset before confirmation.	Bounded trial policy and diagnostic reason.
Commit	Interrupt counter/configuration update.	No impossible combination of image and policy.

Count recovery attempts and detect boot loops. Test the actual bootloader, flash layout and compiler configuration of the release. An emulator is useful for many state sequences but cannot prove real flash behaviour.

Decision guide

Which recovery arrangement is appropriate?

Arrangement	Strength	Trade-off
Dual image / A-B	Running image remains available until candidate is accepted.	Requires additional non-volatile memory and careful state control.
Golden recovery image	Known recovery path independent of application.	Recovery image must itself be maintained and protected.
Service reprogramming	Minimal on-device complexity.	Requires physical access and may be unsuitable for deployed fleets.

Worked example

Worked example — service-installed controller update

Problem

A technician updates a controller connected by USB; power may be lost and older vulnerable firmware must not be restored.

Engineering approach

The service tool transfers a signed package containing product ID, hardware compatibility and security counter. The bootloader writes the inactive bank, verifies the signature and hash, records a pending state, then boots the candidate. After self-test and application confirmation it commits the bank. Failure returns to the previous image. The protected counter prevents rollback below the approved minimum.

Result

An interrupted or invalid update does not brick the controller, and update authority is independent of the transport channel.

Engineering evidence

What should the work produce?

Boot and update architecture

Shows stages, trust anchors, memory banks and states.

Update package specification

Defines signed metadata and compatibility rules.

Key-management concept

Defines generation, protection, rotation and revocation.

Update verification report

Covers interruption, tampering, rollback and recovery.

Common failure patterns

What goes wrong?

Treating CRC as authentication.
Validating the signature but not the target hardware or configuration.
Committing an image before successful first boot.
Protecting update transport while accepting unsigned local packages.

Applied exercise · approximately 25 minutes

Review a faulty A/B update policy

A candidate has security counter 8; the running image has counter 7. The design raises the minimum counter to 8 immediately after signature verification, before the trial boot. Configuration is migrated in place on first boot.

Explain two independent reasons fallback might fail.
Propose a confirmation and configuration strategy that preserves the intended security policy.
Write three interruption tests and their acceptance criteria.

Review a suggested approach

The old image becomes disallowed when the floor is raised, and its configuration may become unreadable after in-place migration. Retaining its flash bank alone therefore does not provide recoverability. Agree the permitted fallback interval and the point at which the security floor must advance.

One design keeps the old configuration until trial success and advances the counter only as part of a recoverable confirmation sequence. If policy forbids returning to counter 7 at any point, prepare an allowed recovery image before committing that policy. Test a reset before trial, a failure during migration and a torn confirmation write; each must reach an authenticated, compatible image or a controlled recovery state.

Completion criteria

The counter and configuration hazards are both identified.
Security policy is explicit rather than silently bypassed.
Every tested durable state has a deterministic next-boot outcome.

This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.

Practical check

Questions for your next design review

Is every executable stage verified before control is transferred?
Are product, hardware and version compatibility signed?
Can power fail at every update state without losing recovery?
Is rollback policy explicit?
Are signing-key lifecycle and compromise response defined?

Key takeaway

A secure update is a recoverable, authenticated state transition—not merely a file transfer.

References and further reading

Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.