1458  OTA Updates and Security

1458.1 Firmware Updates and Over-the-Air (OTA) Security

This chapter covers the critical topic of securely updating IoT device firmware, including OTA (Over-the-Air) update architectures, code signing, rollback protection, and strategies for managing updates across large device fleets.

1458.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Design secure OTA update architectures
  • Implement code signing for firmware updates
  • Configure rollback protection mechanisms
  • Develop update strategies for large device fleets
  • Comply with regulatory requirements for software updates

1458.3 The Update Imperative

IoT devices face a critical challenge: they must be updateable throughout their 10-20 year lifespans, yet updates themselves can be attack vectors. A well-designed OTA system balances security with reliability.

1458.3.1 Why Updates Matter

Without Updates With Secure Updates
Known vulnerabilities persist indefinitely Patches deployed within days of disclosure
Device becomes part of botnets (Mirai) Security improvements continuously applied
Compliance violations (GDPR, HIPAA) Regulatory requirements met
Customer trust erodes Product value increases over time
Liability exposure increases Documented security posture

1458.3.2 OTA Update Architecture

%% fig-alt: "OTA update architecture showing build server creating firmware, signing server applying cryptographic signature with HSM-stored key, CDN distributing signed firmware globally, and IoT devices downloading, verifying signature, and applying update with rollback capability if verification or boot fails."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TB
    subgraph build["BUILD PIPELINE"]
        B1["Source Code"]
        B2["CI/CD Build"]
        B3["Testing"]
        B4["Firmware Binary"]
    end

    subgraph sign["SIGNING INFRASTRUCTURE"]
        S1["Signing Server"]
        S2["HSM (Private Key)"]
        S3["Signed Firmware"]
    end

    subgraph dist["DISTRIBUTION"]
        D1["CDN / Update Server"]
        D2["Manifest (version, hash, signature)"]
    end

    subgraph devices["IOT DEVICES"]
        E1["Check for Updates"]
        E2["Download Firmware"]
        E3["Verify Signature"]
        E4["Apply Update"]
        E5["Rollback if Failed"]
    end

    B1 --> B2 --> B3 --> B4
    B4 --> S1
    S2 --> S1
    S1 --> S3 --> D1
    D1 --> D2
    D2 --> E1 --> E2 --> E3 --> E4
    E4 -->|"Boot Fails"| E5

    style build fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff
    style sign fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style dist fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style devices fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff

1458.4 OTA Security Checklist

WarningSecure OTA Update Requirements

Before Release: - [ ] Firmware signed with ECDSA-P256 or RSA-2048+ key - [ ] Signing key stored in HSM, never on developer machines - [ ] Version number incremented (anti-rollback) - [ ] Manifest includes SHA-256 hash of firmware - [ ] Update tested on representative device sample

Distribution: - [ ] HTTPS/TLS 1.3 for all update downloads - [ ] Certificate pinning on devices - [ ] Geographic redundancy (CDN) - [ ] Bandwidth throttling to prevent network congestion

Device-Side: - [ ] Signature verification before any execution - [ ] Dual-bank (A/B) partition scheme - [ ] Automatic rollback on boot failure - [ ] Anti-rollback counter in secure storage - [ ] Update progress logging for debugging

Post-Update: - [ ] Device reports successful update to backend - [ ] Monitoring for update failures across fleet - [ ] Rollback metrics tracked - [ ] Staged rollout with pause capability

Diagram showing the code signing process: Developer creates software, generates hash of software, encrypts hash with private key to create signature, attaches signature to software. On verification side: User downloads software with signature, decrypts signature with public key to get original hash, computes hash of downloaded software, compares hashes - if match, software is authentic and unmodified.

Code Signing and Verification Flow

Source: NPTEL IoT Security Course

This diagram illustrates the fundamental code signing workflow used for firmware updates:

  1. Signing (Developer/Build Server):
    • Compute cryptographic hash (SHA-256) of firmware
    • Encrypt hash with private key = digital signature
    • Attach signature to firmware package
  2. Verification (IoT Device):
    • Download firmware + signature
    • Decrypt signature with public key to recover original hash
    • Compute hash of downloaded firmware
    • Compare: if hashes match, firmware is authentic and unmodified
Artistic visualization of the code signing process for IoT firmware updates. Shows the developer's build system generating a cryptographic signature using a private key stored in HSM, the signature traveling with the firmware through distribution channels, and the IoT device verifying the signature using the embedded public key before applying the update.
Figure 1458.1: Code Signing Process - Ensuring firmware authenticity from build to device
Modern diagram of secure OTA update architecture showing staged rollout from build server through signing infrastructure to CDN distribution, with IoT devices performing signature verification, A/B partition switching, and automatic rollback on failure.
Figure 1458.2: Secure OTA Architecture - End-to-end update pipeline with cryptographic verification

1458.5 Dual-Bank (A/B) Update Scheme

The A/B partition scheme ensures devices can always boot, even if an update fails:

%% fig-alt: "A/B partition scheme showing device flash divided into Bank A (active, running firmware) and Bank B (inactive, receives updates). Update process: new firmware written to inactive bank, signature verified, boot flag switched, device reboots to new bank. If boot fails, device automatically reverts to previous bank."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TB
    subgraph flash["DEVICE FLASH"]
        subgraph bankA["BANK A"]
            A1["Firmware v1.0"]
            A2["Status: ACTIVE"]
        end
        subgraph bankB["BANK B"]
            B1["Firmware v1.1 (new)"]
            B2["Status: PENDING"]
        end
        subgraph bootloader["BOOTLOADER"]
            BL["Boot Selector"]
        end
    end

    BL -->|"Current Boot"| bankA
    BL -.->|"After Update"| bankB

    style bankA fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style bankB fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style bootloader fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff

Update Process: 1. New firmware downloaded to inactive bank (B) 2. Signature verified 3. Bootloader flag set to boot from B 4. Device reboots 5. If B boots successfully, mark B as active 6. If B fails to boot, bootloader automatically reverts to A

1458.6 Anti-Rollback Protection

Prevents attackers from flashing older, vulnerable firmware:

%% fig-alt: "Anti-rollback mechanism using monotonic counter stored in eFuse or secure element. Each firmware version has a security version number (SVN). Device compares firmware SVN against stored counter - if firmware SVN is lower than counter, update is rejected even with valid signature. Counter incremented after successful security-critical updates."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#7F8C8D'}}}%%
flowchart TD
    A["New Firmware Received"]
    B["Extract Security Version (SVN)"]
    C["Read Counter from eFuse"]
    D{"SVN >= Counter?"}
    E["Verify Signature"]
    F["Apply Update"]
    G["Increment Counter if Security Fix"]
    H["REJECT: Version Too Old"]

    A --> B --> C --> D
    D -->|"Yes"| E --> F --> G
    D -->|"No"| H

    style D fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style H fill:#c0392b,stroke:#2C3E50,stroke-width:2px,color:#fff
    style G fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff

1458.7 Case Study: Chrysler 2015 OTA Vulnerability

What Happened: - Researchers demonstrated remote control of Jeep Cherokee via cellular connection - Uconnect entertainment system had no authentication for incoming connections - No network segmentation between entertainment and vehicle control systems

The Fix: - Chrysler had to recall 1.4 million vehicles - USB-based firmware update (no OTA capability at the time) - Added network segmentation and authentication

Lesson: OTA update capability would have allowed rapid response without physical recalls.

1458.8 EU Cyber Resilience Act Requirements (2024)

The EU CRA mandates security update requirements for IoT products:

Requirement Description
Update Capability Products must be designed for secure updates
Free Security Updates For minimum 5 years or product lifetime
Vulnerability Disclosure 24-hour notification to ENISA for exploited vulnerabilities
SBOM Software Bill of Materials must be maintained
Default Security Products secure out of the box
ImportantCommon Misconception: “We’ll Add Security Updates Later”

The Myth: “We can ship with basic update functionality and add security features in future firmware.”

The Reality: - If the bootloader doesn’t verify signatures, adding verification later doesn’t help - attackers can flash the old, unsigned bootloader - Anti-rollback counters must be in place from the start - Secure boot must be enabled at manufacturing time (eFuse burning) - Key rotation capability must be designed in from day one

The Truth: Security architecture decisions are made at design time. Retrofitting secure OTA is extremely difficult and often impossible without hardware recalls.

1458.9 Update Strategies for Large Fleets

1458.9.1 Staged Rollout

Stage Percentage Duration Purpose
Canary 1% 48 hours Detect critical bugs
Early Adopters 10% 1 week Broader testing
Gradual 25% 2 weeks Monitor for issues
Majority 50% 2 weeks Wide deployment
Complete 100% Ongoing Catch stragglers

1458.9.2 Update Scheduling

  • Maintenance Windows: Update during low-usage periods
  • Bandwidth Management: Limit concurrent downloads
  • Geographic Rollout: Start with specific regions
  • Device Grouping: Update by device type, firmware version, or customer

1458.10 Summary

This chapter covered OTA update security:

  • Code Signing: ECDSA/RSA signatures ensure only authenticated firmware executes
  • A/B Partitioning: Dual-bank schemes enable reliable updates with rollback
  • Anti-Rollback: Monotonic counters prevent downgrade attacks
  • Staged Rollout: Gradual deployment catches issues before fleet-wide impact
  • Regulatory Compliance: EU CRA mandates secure update capability

1458.11 What’s Next

The next chapter explores Hardware Vulnerabilities including hardware trojans, side-channel attacks, and supply chain security risks that threaten IoT devices at the physical level.

Continue to Hardware Vulnerabilities →