Secure boot and firmware updates (OTA) in IOT Protocols - Deep Dive

Overview - Secure boot and firmware updates (OTA)

What is it?

Secure boot and firmware updates over-the-air (OTA) are methods to keep IoT devices safe and up-to-date. Secure boot ensures a device only runs trusted software when it starts. OTA updates let devices receive new software remotely without physical access. Together, they protect devices from attacks and bugs while making maintenance easier.

Why it matters

Without secure boot, devices could run harmful software that steals data or breaks functions. Without OTA updates, fixing bugs or adding features means manual work, which is slow and costly. These technologies keep devices safe, reliable, and current, which is critical as IoT devices control important things like home security or medical tools.

Where it fits

Before learning this, you should understand basic IoT device architecture and software concepts. After this, you can explore advanced IoT security, device management platforms, and network security for IoT.

Mental Model

Core Idea

Secure boot verifies device software integrity at startup, and OTA updates securely deliver new software remotely to keep devices safe and functional.

Think of it like...

It's like a locked mailbox that only accepts letters with a special seal (secure boot), and the mail carrier can deliver new letters without opening the mailbox (OTA updates).

┌───────────────┐       ┌───────────────┐
│   Device      │       │  Update Server│
│  Secure Boot  │◄──────│  Sends OTA    │
│  Checks Code │       │  Firmware     │
└──────┬────────┘       └──────┬────────┘
       │                       │
       │ Runs trusted code     │
       │                       │
       ▼                       ▼
  Device boots          Firmware updated
  only if trusted       securely over air

Build-Up - 6 Steps

1

Foundation

What is Secure Boot in IoT

Concept: Introduce the idea of secure boot as a safety check during device startup.

Secure boot is a process where the device checks if the software it is about to run is trusted. It uses cryptographic signatures to verify the software's origin and integrity. If the software is not trusted, the device stops booting to prevent harm.

Result

The device only starts if the software is verified as safe.

Understanding secure boot is key to preventing unauthorized or harmful software from running on devices.

2

Foundation

Basics of Firmware and OTA Updates

Concept: Explain what firmware is and how OTA updates work to change it remotely.

Firmware is the software that runs on IoT devices, controlling their functions. OTA updates let devices receive new firmware wirelessly, so they can get fixes or new features without manual intervention.

Result

Devices can update their software remotely, improving functionality and security.

Knowing how OTA updates work shows how devices stay current and safe without physical access.

3

Intermediate

How Secure Boot Uses Cryptography

🤔Before reading on: do you think secure boot checks software by scanning for viruses or by verifying a digital signature? Commit to your answer.

Concept: Secure boot uses digital signatures and cryptographic keys to verify software authenticity.

When the device boots, it checks the software's digital signature using a stored public key. If the signature matches, the software is trusted. This prevents tampering because only software signed by the trusted key can run.

Result

Only software signed by the trusted authority runs on the device.

Understanding cryptographic verification explains why secure boot is strong against attacks.

4

Intermediate

Secure OTA Update Process

🤔Before reading on: do you think OTA updates send firmware in plain form or encrypted and signed? Commit to your answer.

Concept: OTA updates must be encrypted and signed to ensure security during transmission and installation.

The update server signs the firmware and may encrypt it. The device verifies the signature before installing. This prevents attackers from sending fake or harmful updates. The device also checks the update version to avoid rollback attacks.

Result

Devices install only authentic and authorized firmware updates.

Knowing the security steps in OTA updates prevents common vulnerabilities like fake updates.

5

Advanced

Rollback Protection and Update Failures

🤔Before reading on: do you think devices allow installing older firmware versions after updates? Commit to your answer.

Concept: Devices implement rollback protection to prevent installing older, vulnerable firmware versions.

Rollback protection stores the highest firmware version installed and rejects older versions. Devices also use dual partitions or backup copies to recover if an update fails, ensuring the device remains functional.

Result

Devices stay protected from old vulnerabilities and recover safely from bad updates.

Understanding rollback protection and recovery mechanisms is crucial for reliable and secure device updates.

6

Expert

Hardware Roots of Trust in Secure Boot

🤔Before reading on: do you think secure boot keys are stored in software or hardware? Commit to your answer.

Concept: Secure boot relies on hardware-based roots of trust to securely store keys and enforce boot policies.

Hardware elements like TPMs or secure enclaves store cryptographic keys and perform verification. This prevents attackers from extracting keys or bypassing secure boot. The hardware enforces that only signed code runs from the very first instruction.

Result

Secure boot is hardened against physical and software attacks by hardware protections.

Knowing the hardware foundation explains why secure boot is trusted in high-security IoT devices.

Under the Hood

Secure boot starts with a small piece of code in hardware called the root of trust. This code holds cryptographic keys and verifies the next software stage's signature before running it. This chain continues until the full firmware is loaded. OTA updates are downloaded, verified by checking digital signatures, and then installed safely, often using dual partitions to allow rollback if needed.

Why designed this way?

This design ensures trust starts from hardware, which is hard to tamper with, creating a secure chain of trust. OTA updates are designed to be secure and reliable because IoT devices are often remote and unattended, so manual updates are impractical. Alternatives like manual updates or software-only checks were rejected due to security risks and operational costs.

┌───────────────┐
│ Hardware Root │
│  of Trust     │
└──────┬────────┘
       │ verifies
       ▼
┌───────────────┐
│ Bootloader    │
│ (checks next │
│  stage)      │
└──────┬────────┘
       │ verifies
       ▼
┌───────────────┐
│ Firmware      │
│ (runs if      │
│  verified)    │
└───────────────┘

OTA Update Flow:
Update Server ──> Signed Firmware ──> Device verifies ──> Install or Reject

Myth Busters - 4 Common Misconceptions

Quick: Does secure boot protect against all types of device attacks? Commit yes or no.

Common Belief: Secure boot makes devices completely immune to hacking.

Reality: Secure boot only ensures the device runs trusted software at startup; it does not protect against all attacks like runtime exploits or hardware tampering.

Why it matters: Overestimating secure boot can lead to ignoring other critical security layers, leaving devices vulnerable.

Quick: Can OTA updates be safely applied without verifying signatures? Commit yes or no.

Common Belief: OTA updates are safe as long as the device downloads them from the internet.

Reality: Without verifying signatures, devices can install malicious or corrupted firmware, risking security and functionality.

Why it matters: Skipping verification can lead to device takeover or bricking, causing costly failures.

Quick: Do you think rollback protection allows installing any firmware version? Commit yes or no.

Common Belief: Devices can freely install older firmware versions if needed.

Reality: Rollback protection prevents installing older, vulnerable firmware to avoid security risks.

Why it matters: Ignoring rollback protection can expose devices to known vulnerabilities and attacks.

Quick: Is storing secure boot keys in software as safe as in hardware? Commit yes or no.

Common Belief: Storing keys in software is just as secure as hardware storage.

Reality: Hardware storage protects keys from extraction and tampering, which software storage cannot guarantee.

Why it matters: Using software-only keys risks attackers stealing keys and bypassing secure boot.

Expert Zone

1

Secure boot implementations vary by hardware vendor, affecting compatibility and security guarantees.

2

OTA update mechanisms must balance security with device resource constraints like memory and power.

3

Rollback protection can be bypassed if version counters are not securely stored or updated atomically.

When NOT to use

Secure boot and OTA updates may be unsuitable for extremely resource-limited devices where cryptographic operations are too costly. In such cases, physical security and manual updates might be alternatives.

Production Patterns

In production, devices often use multi-stage secure boot with hardware roots of trust, combined with encrypted and signed OTA updates delivered via secure device management platforms. Dual-partition firmware schemes enable safe rollback and update recovery.

Connections

Public Key Infrastructure (PKI)

Secure boot and OTA updates rely on PKI for managing cryptographic keys and certificates.

Understanding PKI helps grasp how trust is established and maintained in device software verification.

Continuous Integration/Continuous Deployment (CI/CD)

OTA updates are part of CI/CD pipelines for IoT devices, automating software delivery and updates.

Knowing CI/CD concepts clarifies how firmware updates are tested, signed, and deployed securely and efficiently.

Supply Chain Security

Secure boot and OTA updates protect against supply chain attacks by verifying software authenticity from origin to device.

Recognizing supply chain risks highlights why end-to-end verification in secure boot and OTA is critical.

Common Pitfalls

#1 Not verifying firmware signatures before installation.

Wrong approach:

Device downloads firmware and installs it without checking any signature or hash.

Correct approach:

Device verifies the firmware's digital signature using a trusted public key before installation.

Root cause:

Misunderstanding that downloading firmware alone guarantees safety, ignoring the need for cryptographic verification.

#2 Allowing rollback to older firmware versions.

Wrong approach:

Device installs any firmware version sent by the server, including older ones.

Correct approach:

Device checks firmware version and rejects any older than the current installed version.

Root cause:

Not implementing or misunderstanding rollback protection mechanisms.

#3 Storing secure boot keys in writable software memory.

Wrong approach:

Keys are stored in device flash memory accessible to software.

Correct approach:

Keys are stored in hardware secure elements or TPMs, inaccessible to software tampering.

Root cause:

Underestimating the risk of key extraction and tampering without hardware protection.

Key Takeaways

Secure boot ensures devices only run trusted software by verifying digital signatures at startup.

OTA updates allow remote, wireless firmware upgrades but must be securely signed and verified to prevent attacks.

Rollback protection prevents installing older, vulnerable firmware versions, maintaining device security.

Hardware roots of trust provide a strong foundation for secure boot by protecting cryptographic keys from tampering.

Ignoring secure boot and OTA security steps can lead to device compromise, costly failures, and loss of trust.

Practice

1. What is the main purpose of secure boot in IoT devices?

easy

A. To ensure only trusted software runs on the device

B. To speed up the device startup time

C. To allow any software to run without restrictions

D. To backup device data automatically

Solution

1. Step 1: Understand secure boot concept

   Secure boot checks the software's authenticity before running it on the device.

2. Step 2: Identify the main goal

   The goal is to prevent untrusted or malicious software from running.

3. Final Answer:

   To ensure only trusted software runs on the device -> Option A

4. Quick Check:

   Secure boot = trusted software only [OK]

Hint: Secure boot means only trusted software runs [OK]

Common Mistakes:

• Thinking secure boot speeds startup
• Believing secure boot allows any software
• Confusing secure boot with data backup

2. Which of the following is the correct command to verify a firmware update signature using openssl?

easy

A. openssl verify -CAfile ca.pem firmware.sig

B. openssl sign -verify firmware.bin

C. openssl dgst -verify ca.pem -signature firmware.sig firmware.bin

D. openssl check firmware.sig firmware.bin

Solution

1. Step 1: Recall openssl dgst verify syntax

   The correct syntax to verify a signature is: openssl dgst -verify [pubkey/cert] -signature [signature] [file].

2. Step 2: Match the command with syntax

   openssl dgst -verify ca.pem -signature firmware.sig firmware.bin matches this syntax exactly for verifying firmware signature.

3. Final Answer:

   openssl dgst -verify ca.pem -signature firmware.sig firmware.bin -> Option C

4. Quick Check:

   Verify signature = openssl dgst -verify [key] -signature [sig] [file] [OK]

Hint: Verify signature uses 'dgst -verify' and '-signature' flags [OK]

Common Mistakes:

• Using 'openssl sign' instead of 'dgst'
• Missing '-verify' or '-signature' flags
• Using wrong command like 'openssl check'

3. Given this pseudo-code for OTA update verification:

if verify_signature(firmware, signature, public_key):
    install_firmware(firmware)
else:
    reject_update()

What happens if the signature does not match?

medium

A. Update is rejected and not installed

B. Signature is ignored and update proceeds

C. Device reboots automatically

D. Firmware is installed anyway

Solution

1. Step 1: Analyze the conditional logic

   If verify_signature returns false, the else branch runs.

2. Step 2: Understand else branch action

   The else branch calls reject_update(), meaning the update is not installed.

3. Final Answer:

   Update is rejected and not installed -> Option A

4. Quick Check:

   Signature mismatch = reject update [OK]

Hint: If signature fails, update is rejected [OK]

Common Mistakes:

• Assuming firmware installs despite bad signature
• Thinking device reboots automatically
• Ignoring signature verification result

4. You wrote this OTA update script snippet:

if verify_signature(firmware, signature, public_key):
    install_firmware(firmware)
else:
    install_firmware(firmware)

What is the main problem here?

medium

A. Firmware is never installed

B. Signature verification function is missing

C. Public key is not used in verification

D. Firmware is installed even if signature verification fails

Solution

1. Step 1: Review the else branch code

   Both if and else branches call install_firmware(firmware).

2. Step 2: Understand security impact

   This means firmware installs regardless of signature check, breaking security.

3. Final Answer:

   Firmware is installed even if signature verification fails -> Option D

4. Quick Check:

   Else installs firmware = security risk [OK]

Hint: Else should reject update, not install firmware [OK]

Common Mistakes:

• Ignoring else branch code
• Assuming verification function is missing
• Confusing public key usage

5. You want to implement a secure OTA update system that:
- Verifies firmware signature
- Supports rollback if update fails
- Uses secure boot to prevent unauthorized code

Which sequence of steps best achieves this?

hard

A. Enable secure boot -> Install firmware -> Verify signature -> Rollback if failure

B. Enable secure boot -> Verify signature -> Install firmware -> Rollback if failure

C. Verify signature -> Install firmware -> Enable secure boot -> Rollback if failure

D. Install firmware -> Verify signature -> Enable secure boot -> Rollback if failure

Solution

1. Step 1: Enable secure boot first

   Secure boot must be active to prevent unauthorized code from running at startup.

2. Step 2: Verify firmware signature before installing

   Check the update is trusted before installation to avoid bad firmware.

3. Step 3: Install firmware and support rollback

   Install only if verified, and rollback if update fails to keep device safe.

4. Final Answer:

   Enable secure boot -> Verify signature -> Install firmware -> Rollback if failure -> Option B

5. Quick Check:

   Secure boot first, verify, install, rollback [OK]

Hint: Enable secure boot first, then verify before install [OK]

Common Mistakes:

• Installing firmware before verifying signature
• Enabling secure boot after installation
• Skipping rollback support