# ADR: SMI firmware update authentication

Status: rejected
Type: adr
Updated: 2026-07-12
Next Action: none; retain the deployed CRC-compatible update format
Campaign Reason: Historical record from campaign 010-qualify-firmware-negative-and-recovery-behavior; retained independently after campaign closure and requires no separate owner-queue execution.
Campaign: standalone
Parent: work/wp/active/wp-mitigate-smi-firmware-code-review-findings.md
Supersedes:
Superseded By:

## Context

SMI currently accepts a USB update based on an unkeyed CRC. Anyone able to alter
the file can recompute that CRC. The target is an S7G2 on SSP 2.6.1/GCC 10.3.1;
the checked-in SSP exposes AES/SCE APIs but no inspected, ready-to-use digital
signature verifier. Adding a primitive without validating its implementation,
footprint, licensing, and provisioning would create a false security boundary.

The update header is a deployed 256-byte version-1 format. Changing it affects
packaging, service media, factory provisioning, recovery, and potentially every
installed unit. These are product/security policy choices, not safe code-only
defaults.

## Decision

Declined on 2026-07-12 by the project owner. Do not add firmware signature
verification or change the deployed update format as part of this workpackage.
Retain the current CRC-based integrity check and the structural bounds/read
validation added for CR-02/07.

The authenticity risk is explicitly accepted: CRC can detect accidental damage
but cannot prove that an update was produced by High Point. Revisit this decision
only through a new ADR and compatibility/rollout plan.

## Rejected Proposal

Proposed direction:

- Introduce update format version 2 with a product identifier, monotonically
  increasing security version, payload digest, key identifier, and signature.
- Prefer an asymmetric signature so devices contain only a verification public
  key and compromise of one unit cannot authorize new firmware.
- Store the verification key in immutable/protected internal flash and keep the
  signing private key outside the source repository in controlled release
  infrastructure.
- Verify the complete manifest and payload before any QSPI erase or internal
  flash operation.
- Reject version-1/unsigned images by default. If deployed units require a
  migration path, authorize one specifically identified, time-bounded bridge
  release rather than a permanent compatibility switch.
- Reject security-version rollback using protected monotonic state, subject to
  confirming a power-fail-safe storage design.

This proposal was not approved and will not be implemented.

## Consequences

Positive:

- Removes CRC-only authorization and limits signing authority to release custody.
- Gives packaging and on-target verification one explicit contract.
- Makes wrong-product, altered, unsigned, wrong-key, and rollback cases testable.

Negative:

- Requires a vetted signature implementation compatible with this legacy SSP.
- Requires key provisioning, rotation/revocation, recovery, and migration work.
- Rejecting legacy images can disrupt field service unless rollout is planned.

## Alternatives Considered

- Keep CRC-only validation: selected to preserve deployed update compatibility,
  with the authenticity limitation explicitly accepted.
- Symmetric MAC using an SCE-held device key: smaller potential integration, but
  factory/key-custody complexity and fleet-wide compromise consequences require
  explicit analysis.
- Permanent acceptance of version-1 images: rejected because it preserves a
  bypass around the authenticated path.
- Software-only embedded public-key verification versus SCE-assisted verification:
  defer selection until both are measured and reviewed on the target toolchain.

## Supersession Notes

If this ADR replaces an earlier decision, link the old ADR in `Supersedes:` and update the old ADR's `Superseded By:` header. Keep superseded ADRs as history; move current operating truth into docs or README files.
