Secure edge model updates
Authenticate complete model bundles, enforce persistent freshness and compatibility policy, and promote candidates with a power-loss-safe recovery design.
On this page
The question for today
What you’ll understand
- Separate authenticity, integrity, freshness, compatibility and model-quality checks.
- Explain antirollback state and its interaction with deliberate recovery.
- Budget staged installation and test atomic promotion across crashes and power loss.
A signed model can still be old, incompatible, or inaccurate for the intended device. Secure update design combines authenticated metadata, content integrity, trusted freshness state, compatibility checks, and a recoverable installation protocol. The model bundle includes preprocessing, labels and other interpretation metadata, not just weights. This lesson uses TUF specification 1.0.33 and MCUboot 2.2.0 as concrete references while distinguishing software-distribution verification, firmware boot handling, and application-specific model promotion.
Verify authorization and the complete compatible bundle
A downloaded hash provides integrity only relative to a trusted expected digest; an attacker who can replace both file and untrusted hash has not been stopped. Authenticate metadata under provisioned trust roots, enforce authorized signing roles, and bind the artifact bytes and compatibility fields to that metadata. Include model format, runtime and kernel requirements, tensor schema, preprocessor version, class map and resource limits. A cryptographically intact file can still fail initialization or exceed memory on one device revision.
TUF separates metadata roles and specifies signature, version and expiration checks to resist several update attacks. Its target files are opaque artifacts: the application remains responsible for interpreting and installing a model. Freshness checks need persistent trusted state and the scheme’s time assumptions; a disconnected device with an unreliable clock cannot infer current repository freshness merely from an old valid signature. Plan key rotation and recovery before deployment rather than making an emergency bypass the ordinary trust policy.
Antirollback and recovery must agree on trusted state
A security generation prevents installing artifacts below an established security floor. It should not wrap like a circular buffer index, and its stored state must resist the attacker capabilities in the threat model. Ordinary model version labels and security generations serve different purposes: several quality revisions can share a security floor. MCUboot 2.2.0 documents hardware-based rollback protection using a signed image security counter and trusted nonvolatile state, but that firmware mechanism does not automatically protect a separately loaded model file.
A deliberate return to a known-good candidate must remain consistent with the security floor. If the floor has advanced past the older artifact, recovering by silently lowering it defeats the antirollback policy. Define an authorized recovery path and when security state is committed relative to trial execution and confirmation. Retain enough compatible data to recover from interrupted updates without accepting forbidden artifacts. The ordering and persistence protocol require fault tests; a statement that the pointer change is atomic does not by itself make every related metadata write durable.
Stage, validate, promote and test every interruption point
Write a candidate to an inactive location, verify authenticated metadata and content, validate compatibility and initialization, and run the required health or quality checks before promotion. Switch the active reference using a storage protocol that can recover to one consistent version after power loss, including related state migrations. MCUboot’s test-and-confirm firmware flow is a useful concrete analogy, not an automatic model-updater feature. Exercise failure after each persistent write, during verification, during promotion, and before confirmation; inspect both the active bundle and security state after restart.
The modular lab illustrates why wrapped counters are unsuitable as a freshness order. Reset, set modulus m to 8 and additive step a to 1, predict residue zero after eight Steps, then take those Steps. Compare a fresh Reset with both m at 16 and a at 1 before eight Steps: residue eight. One Step is one addition. This finite cyclic toy implements neither a monotonic trusted counter nor signatures, secure storage, authenticated metadata, or atomic promotion.
Work it through
Reserve a staged bundle and enforce the floor
An update design retains a 6 MiB active bundle, a 6 MiB candidate, 1 MiB scratch and 64 KiB journal on a 16 MiB storage budget. A download link provides 256 KiB/s. The trusted security floor is seven; compare candidate generations six and eight, assuming other verification checks are still pending.
Concurrent installation storage is 6 + 6 + 1 + 64/1,024 = 13.0625 MiB, leaving 2.9375 MiB before unlisted filesystem or wear-management overhead.
The 6 MiB candidate contains 6 × 1,024 = 6,144 KiB, requiring at least 6,144/256 = 24 seconds of data transfer, excluding setup, retries and verification.
Generation six is rejected by the floor. Generation eight passes only the generation comparison; it still needs valid authorization, integrity, compatibility and health checks. Advancing the floor to eight would forbid ordinary recovery to a generation-seven bundle.
Storage, authenticity, compatibility, freshness and recoverability are separate conditions that must be satisfied by the same update design.
The living notebook
Explore the model
Interactive lab · modular
A wrapped residue is not a trusted security generation
Reset, set m = 8 and a = 1, predict residue 0 after eight Steps, then take those Steps. Compare a fresh Reset with both m = 16 and a = 1 before eight Steps: residue 8. Each Step is one modular addition. This deliberately wrapping toy is not an antirollback implementation, secure counter, signature verifier or atomic installer.
- Residue r0
- 0
- Orbit period · m/gcd(m,a)
- 12
- Distinct residues visited
- 1 of 12
Addition modulo m starts at zero: rₙ = na mod m. Playback advances two additions per second. The orbit has period m/gcd(m,a), including period one for a = 0. This is not a cryptographic security test or a primality algorithm. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA security freshness order needs persistent monotonic policy rather than modular wraparound.
Pause & reason
Check your understanding
Your turn
Try it yourself
A staged design needs 4 MiB active, 4 MiB candidate, 0.5 MiB scratch and 128 KiB journal. Find total storage and margin under a 10 MiB budget. If the floor is three, does generation four with a matching untrusted hash suffice for acceptance?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Use 1 MiB = 1,024 KiB. A downloaded digest must itself be bound to trusted authenticated metadata.
Compare with the solution
Total storage is 4 + 4 + 0.5 + 128/1,024 = 8.625 MiB, leaving 1.375 MiB before other overhead. Generation four satisfies the numeric floor comparison, but a matching hash from an untrusted source does not establish authorization or integrity relative to a trusted artifact. Verify authenticated metadata, content, compatibility and the defined health checks, then apply the tested promotion and persistence protocol.
Keep the idea
Take it with you
- Authenticate the whole compatible bundle, not only an untrusted digest.
- Persistent security floors and deliberate recovery must obey one policy.
- Power-loss-safe promotion requires a concrete storage protocol and interruption tests.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.