Encrypted Firmware Is Not Authenticated Firmware: Separate Confidentiality from Boot Trust
Evaluate encrypted firmware at every place the image and its decryption state can reside. A confidential download is only one stage. The release review also needs to establish who may authorize executable bytes, which metadata remains visible, and what an interrupted update leaves in storage.
This guide examines MCUboot v2.2.0’s ordinary encrypted-image upgrade flow, especially swap using scratch. It does not cover every downstream port, RAM-load arrangement or hardware encryption engine. The worksheet below is a proposed qualification method; no device, secret key or production image was accessed.
1. Write three separate acceptance claims
Start with a short claim for confidentiality: which observer must be unable to recover which information, from which location? Then write an authenticity claim: which independent trust source authorizes the image? Finally, state applicability: which product and boot state may use it?
RFC 9124’s information model treats cryptographic authenticity, payload confidentiality and manifest confidentiality separately. The document is Informational; it is not evidence that a specific MCUboot integration implements every requirement.
A useful confidentiality claim might cover an update archive and removable secondary flash. It should not silently expand into protection against all physical access, all metadata disclosure or code execution under a compromised operating system. Define the intended observer before choosing evidence.
2. Map the exact encrypted representation
In the pinned encrypted-image design, the payload is encrypted while the header and TLVs remain clear. A validated upgrade is decrypted into the primary slot. The documented threat model excludes attacks that dump internal flash, including debug access.
Do not put confidential release identifiers, customer-specific data or other sensitive fields into an exposed metadata area merely because the file is called encrypted. Review the actual artifact field by field, with public and confidential classifications recorded separately.
The v2.2.0 validation source decrypts payload blocks before feeding their contents into the ordinary image hash. The selected signature-validation path remains a distinct requirement. Successful decryption alone does not establish an authorized signer.
3. Build a location-by-threat worksheet
For each region, name its owner, physical accessibility, retained lifetime and relevant boot state. Include intermediate storage rather than limiting the inventory to the two advertised image slots.
| Location or evidence | Disclosure question | Tamper question |
|---|---|---|
| Distributed update artifact | Which payload and metadata fields can a recipient inspect? | Which final verifier rejects unauthorized executable content? |
| Secondary storage | Is its exact stored representation within the confidentiality claim? | Are altered bytes rejected before activation? |
| Scratch and resume records | Does interruption expose information that defeats payload secrecy? | Can invalid recovery state be used without validation? |
| Primary execution storage | What separate controls govern access to installed code? | What validates the next boot under the actual configuration? |
| Logs and diagnostic captures | Could debugging export sensitive material? | Are results attributable to the frozen build and test case? |
A blank cell is an unresolved boundary, not a successful security result. Assign an owner to each missing answer. If a location falls outside the agreed claim, document that exclusion so a buyer or reviewer cannot mistake it for tested protection.
4. Examine interrupted-swap key storage explicitly
The documented scratch flow retains encrypted payload bytes there, but without MCUBOOT_SWAP_SAVE_ENCTLV it stores decryption keys in plaintext in scratch. The guide requires that option when scratch is outside internal flash. This is a concrete integration check, not a universal assurance about hardware resistance.
Review the resolved configuration, memory placement and linked implementation together. A build option mentioned in a design note is insufficient when the shipped binary differs, a downstream port changes storage, or manufacturing uses another layout.
Plan inspection points before an update, during each persistent recovery transition and after completion. Use authorized disposable devices and synthetic payloads under the organization’s security-testing procedure. Preserve original artifacts and never include real secret material in reports, screenshots or shared captures.
5. Separate negative controls by the property they exercise
| Proposed control | Required observation | What it does not prove |
|---|---|---|
| Authorized encrypted positive image | Selected validation and activation path succeeds | Confidentiality of every storage region |
| Decryptable image with unauthorized signing identity | Authentication rejects it under unchanged trust policy | Resistance to key extraction |
| Damaged ciphertext | Rejected with the failing stage identified | That signature enforcement caused the rejection |
| Interrupted update at a recorded persistence boundary | Observed retained representation matches the exposure policy | Behavior at untested transitions or on other hardware |
| Visible metadata inspection | Only intentionally public fields are disclosed | Payload authorization or runtime isolation |
The unauthorized-signer control must otherwise be well formed and usable by the selected decryption path. If it fails while parsing or unwrapping, record that result without claiming it tested image-signature enforcement. Keep a passing control for the same target and format.
Hypothetical external-scratch review
A fictional controller’s confidentiality requirement covers removable external storage. Its review initially checks only that a secondary-slot payload is unreadable. A later layout review places scratch on the same external device and finds no evidence for the required retained-key representation.
The correct decision is to withhold the external-storage confidentiality claim and qualify the affected integration. A valid image signature does not answer the disclosure question. Conversely, observing encrypted scratch payload bytes does not resolve the separate key-state question.
6. Approve bounded evidence
The release record should identify the bootloader binary, update mode, storage map, public trust identifiers, observed transitions and unresolved exposures. Include who reviewed the final configuration and which controls were actually executed.
Reopen the worksheet after changing flash placement, recovery behavior, debug policy or encryption integration. The useful outcome is a precise statement about protected information and authorized execution, with independent evidence for each. It is not a blanket product-security guarantee.
