# secure-ota > Apply flow (pseudo): ```c // 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(); ``` - Author: Amin Alam - Repository: AminAlam/meddev-agent-skills - Version: 20260104204655 - Stars: 5 - Forks: 0 - Last Updated: 2026-02-07 - Source: https://github.com/AminAlam/meddev-agent-skills - Web: https://mule.run/skillshub/@@AminAlam/meddev-agent-skills~secure-ota:20260104204655 --- --- skill_id: SEC-SECURE-OTA version: 1.0.0 last_updated: 2026-01-04 applies_to: [Class A, Class B, Class C] jurisdiction: [Global] prerequisites: [SEC-SECURE-BOOT, SEC-ENCRYPTION, SEC-KEYMGMT] --- # 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): ```json // REQ-OTA-MAN-01; TEST-OTA-03 { "version": 12, "slot": "B", "len": 262144, "hash": "f3ab...", "sig": "3045...", "compat": "hw:rev2" } ``` Apply flow (pseudo): ```c // 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: ```c // 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