Managing Secure Firmware Updates Over-the-Air

In this lesson, you will learn how to implement an Over-the-Air (OTA) update mechanism that mandates version freshness and cryptographic authority to thwart malicious downgrades and unauthorized code execution.

Preventing Rollback Attacks

A secure OTA system must protect against "rollback attacks," where an attacker intercepts a legitimate, older (but signed) firmware image and forces your device to install it. Because the older image is cryptographically valid, standard signature verification would accept it. To prevent this, we maintain an anti-rollback counter within non-volatile, tamper-resistant storage (like an eFuse or secure EEPROM).

The update process follows these steps:

1. Manifest Validation: The device downloads a signed manifest containing the firmware hash, target hardware ID, and a version number.
2. Signature Verification: Using the public key stored in the Hardware Root of Trust, the device validates the digital signature of the manifest.
3. Version Check: The device compares the version number in the manifest against the stored_version counter in secure memory. If manifest_version <= stored_version, the update is rejected.
4. Flash & Commit: Once the image is verified and installed, the device updates the stored_version counter to the new manifest version.

Implementation Logic

Below is the logic for verifying the version during the update routine:

bool verify_firmware_update(Manifest *m, uint32_t current_version) {
    // 1. Verify digital signature using device's public key
    if (!verify_signature(m->signature, m->payload, public_key)) {
        return false; 
    }

    // 2. Anti-rollback check
    if (m->version_number <= current_version) {
        // Prevent downgrade to vulnerable/older version
        return false; 
    }

    return true;
}

By coupling the version check with the immutable signature verification, you ensure that the device only advances to newer, authorized states. Crucially, the anti-rollback counter must be updated atomically after a successful installation; if the power fails during this step, the device should remain in its existing valid state rather than entering an inconsistent one. This architecture ensures that even if an attacker possesses an old, signed firmware image, they cannot force the device to revert to a state with known security flaws.

Key Takeaway: Secure OTA updates require both cryptographic verification of authenticity via digital signatures and monotonic version enforcement via hardware-backed anti-rollback counters to maintain a secure device state.