Security: Threats & Defense · Study deck
Secure OTA Updates
Picture a smart lock offered a new software package overnight.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- explain why an update is only as safe as its full delivery and install path
- define install-state vocabulary and the negative tests an update must pass
- Explain: Under the Hood examines version policy, stored state, first-start proof, return cases, staged rollout, key change, and negative tests.
- Explain: The update service can deliver the right bytes and still offer them to the wrong model, send an older version, or lose power during the first start.
Major section
Start With the Update That Does Not Install
Under the Hood examines version policy, stored state, first-start proof, return cases, staged rollout, key change, and negative tests.
- Firmware is the software stored on a device.
- A completed download is not proof of a safe update.
- This opening does not choose one signing system or slot layout.
Major section
Start With the Update That Does Not Install (continued)
The update service can deliver the right bytes and still offer them to the wrong model, send an older version, or lose power during the first start.
- A remote service may guide the rollout, but it must not erase the local known-good path.
- The important security story is not only the successful install.
- Without that chain, "OTA is secure" is only a slogan.
Major section
Overview: An Update Is Only as Safe as Its Path
Over-the-air updates are a security control only when the update path is itself controlled.
- If you only need the intuition, this layer is enough: secure OTA needs both authenticity (the right, signed, targeted firmware) and recovery (a way back to known-good firmware if the update fails).
Major section
Overview: An Update Is Only as Safe as Its Path (continued)
Authenticity without recovery can still leave a device unusable.
- A protected transport path helps, but it does not prove the update is authorized, targeted to the correct device class, or safe to install.
- The package store can make files available, but the signed manifest and device-side verification decide whether a package is accepted.
- Those named elements make the claim concrete rather than merely directional.
Major section
Overview: An Update Is Only as Safe as Its Path (continued)
A release team should be able to show a normal update, a bad-signature rejection, a wrong-target rejection, a rollback-policy rejection, and a recovery decision after a failed health check.
- The delivery path is not the root of trust; the device verifies a signed manifest before writing any firmware.
- That order separates cryptographic validity from device acceptance and healthy operation, preserving the chapter's chain-of-trust argument.
- If you can state why authenticity and recovery are both required, you can stop here.
Major section
Practitioner: Review a Candidate Update End to End
A secure OTA design normally separates the manifest from the firmware package.
- The manifest is small enough to verify first and should describe everything the device needs to decide before installing anything.
- Both trust the same release key, but their motor driver, flash layout, bootloader contract, and safe output polarity differ.
Major section
Practitioner: Review a Candidate Update End to End (continued)
Recovery time is a release gate, not a support afterthought.
- If the L200 image is accurately signed and delivered to an L100, signature and hash checks can both pass while installation still bricks the actuator or leaves the lock in an unsafe state.
- The target tuple belongs inside signed metadata and must also be checked locally; a cloud-side fleet label alone can be stale or wrong.
- Signature, target, or version check fails.
Major section
Practitioner: Review a Candidate Update End to End (continued)
A successful L200 cohort says nothing about L100 compatibility, even when the application feature and signing key are shared.
- The candidate remains a trial until it reports health from the new image.
- This distinction prevents a device that merely reached main() from being counted as a healthy lock.
- Hash mismatch; keep current slot.
Major section
Practitioner: Review a Candidate Update End to End (continued)
The known working firmware remains intact while the candidate slot is written.
- If safe recovery depends on the same network path or application image that just failed, the design has not preserved an independent recovery route.
- Model, revision, bootloader, and partition changes are explicit retest triggers.
- Signature result, target match, version-policy result.
Major section
Practitioner: Review a Candidate Update End to End (continued)
The package can move over an ordinary delivery path, but the device compares it with the signed manifest before writing it to an install slot.
- Transport protection still matters, but it is a separate control, not a replacement for manifest and package verification.
- The hand-off gives substance to install layout: the current slot stays known-good while the candidate is written, verified, and health-checked.
- Downloaded package matches the manifest hash.
Major section
Practitioner: Review a Candidate Update End to End (continued)
A gateway receives a firmware update through a management service.
- The boot choice changes only after the candidate passes signature, hash, and version checks.
- A failed health check returns to the known working slot when recovery is allowed, and the result is reported.
- Signed by the release authority; target and version match.
Major section
Practitioner: Review a Candidate Update End to End (continued)
Manifest identifies one side of the problem, candidate path names the controlling distinction, and record and retest reveals the resulting state.
- Downgrade attack installs an older signed firmware to reopen a fixed weakness; this must be blocked.
- Verification fails before boot switch.
- Health-check result and accept/reject/revert report.
Major section
Practitioner: Review a Candidate Update End to End (continued)
A sound policy allows defined recovery while blocking unsafe downgrade, and the minimum accepted version should be device-enforced rather than only checked by a service.
- A weak review says "the update is secure because it is signed." A stronger review separates the claim into manifest, install, and rollout evidence.
- Health check fails; revert to known-good and report.
- If you can review manifest, install, and rollout evidence, you can stop here.
- Recovery revert returns to the last known working slot because the candidate failed health checks; this is desirable.
Major section
Under the Hood: Install-State Vocabulary and Negative Tests
Require at least one controlled negative-case test: a deliberately invalid package, tampered hash, or version-policy violation that the device should reject before install.
- The deeper layer makes the rollout reviewable across systems.
- The firmware the device runs in normal operation.
- Passed signature, hash, and version checks, or was rejected before install.
Major section
Under the Hood: Install-State Vocabulary and Negative Tests (continued)
Without a rejection record, the verification claim is supported only for the allowed case.
- Secure OTA review does not end at signature verification: a release can be authentic and still fail health checks, so the device, gateway, and update service must describe the same states with the same names.
- The exact naming varies by system, but a consistent vocabulary lets reviewers confirm that the update service, gateway logs, and device reports use matching state names.
- The same logic applies to recovery: a tested revert after a failed health check is what supports the availability claim.
Deck summary
Key takeaways
Under the Hood examines version policy, stored state, first-start proof, return cases, staged rollout, key change, and negative tests.
- The update service can deliver the right bytes and still offer them to the wrong model, send an older version, or lose power during the first start.
- Over-the-air updates are a security control only when the update path is itself controlled.
- Authenticity without recovery can still leave a device unusable.
- A release team should be able to show a normal update, a bad-signature rejection, a wrong-target rejection, a rollback-policy rejection, and a recovery decision after a failed health check.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A device downloads a firmware package from the expected update path, but the signed manifest does not verify. What should it do next?
Show answer
Answer: A The device should not install a package when the signed manifest cannot be verified.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2Why should the minimum accepted firmware version be enforced on the device, not only in the update service?
Show answer
Answer: A Service-side rules help, but a network attacker, misconfigured cache, or stale package store could still present an older signed package.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3An OTA review shows only successful updates and consistent "accepted" logs. Why is this not sufficient evidence for the verification claim?
Show answer
Answer: C Verification must be demonstrated by rejecting a bad package, not only by accepting good ones, and the states must be named consistently.
Print reference
Answers
Answer key.
- A · The device should not install a package when the signed manifest cannot be verified.
- A · Service-side rules help, but a network attacker, misconfigured cache, or stale package store could still present an older signed package.
- C · Verification must be demonstrated by rejecting a bad package, not only by accepting good ones, and the states must be named consistently.