Secure Ota

Secure Over-the-Air Updates

Purpose

Ensure OTA updates are authenticated, integrity-checked, atomic, and safely recoverable, with regulatory considerations for software changes.

When to Apply

• Adding or modifying OTA/update mechanisms (WiFi/BLE/cellular/USB bootstrap).

Requirements (testable)

1. Signed Packages: All update images are signed (ECDSA/Ed25519); verification before apply. Rationale: integrity/authenticity.
2. Transport Security: Fetch updates over TLS 1.3 (or strong 1.2) with server auth; consider mTLS for device auth. Rationale: in-transit protection.
3. Atomic Apply & Rollback: Use A/B or staging; ensure power loss-safe writes; rollback to known good on failure. Rationale: availability and safety.
4. Version & Anti-Rollback: Enforce monotonic versioning; reject older/vulnerable images. Rationale: prevent downgrades.
5. Manifest Validation: Validate length, hash, target slot, and compatibility before flashing. Rationale: prevent corruption/wrong target.
6. Policy & Approvals: Apply update policy (who/when); log approvals where required; align with change control and regulatory submission needs. Rationale: compliance.
7. Post-Update Verification: Self-test on first boot after update; revert if critical tests fail. Rationale: functional assurance.

Recommended Practices

• Limit update window/bandwidth; throttle retries.
• Use delta updates only if integrity is protected end-to-end.
• Log update attempts/results with reasons; expose for service.
• Coordinate with secure boot keys and rotation plan.

Patterns

Manifest structure (example):

// REQ-OTA-MAN-01; TEST-OTA-03
{
  "version": 12,
  "slot": "B",
  "len": 262144,
  "hash": "f3ab...",
  "sig": "3045...",
  "compat": "hw:rev2"
}

Apply flow (pseudo):

// REQ-OTA-APPLY-02; TEST-OTA-06
if (!verify_manifest(m) || !verify_sig(pkg, m->sig)) abort();
if (m->version <= current_version()) abort(); // anti-rollback
if (!write_slot(m->slot, pkg, m->len)) abort();
mark_pending(m->version, m->slot);
reboot();

Post-update self-test:

// REQ-OTA-VERIFY-03; TEST-OTA-09
if (!run_startup_tests()) {
    rollback();
    log_event("OTA_FAIL_SELFTEST");
}

Anti-Patterns (risks)

• Unsigned updates or signature ignored on failure -> risk: code injection.
• In-place single-slot updates without power-fail protection -> risk: bricking.
• No anti-rollback -> risk: reintroducing known vulnerabilities.
• Delta updates without end-to-end verification -> risk: patch tampering.
• Missing post-update self-test -> risk: latent defects in field.

Verification Checklist

• Updates signed and verified; failures abort safely.
• Transport over TLS with server validation (and mTLS if required).
• Atomic apply/rollback path implemented; power-fail safe.
• Anti-rollback/version checks enforced.
• Manifest validated (length/hash/slot/compatibility).
• Update policy/approvals logged; change control followed.
• Post-update self-test executes; rollback on failure; results logged.

Traceability

• REQ-OTA-### to TEST-OTA-###; link to secure boot requirements and change control records.

References

• NIST SP 800-193 (firmware resiliency).
• FDA Cybersecurity Premarket Guidance (updates/patching).
• MCU/vendor A/B or DFU application notes.

Changelog

• 1.0.0 (2026-01-04): Initial secure OTA skill with signing, atomicity, anti-rollback, and post-update verification.

Audit History

• 2026-01-04: Audit performed. Verified:
  • NIST SP 800-193 reference appropriate
  • A/B update patterns accurately described
  • Signature and manifest verification patterns technically sound