Secure boot and firmware updates (OTA) in IOT Protocols - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of secure boot in IoT devices?

Secure boot is a critical security feature in IoT devices. What does it mainly ensure?

A It encrypts all data sent from the device to the cloud to protect privacy.

B It manages the device's power consumption during startup to save battery.

C It automatically updates the device firmware without user intervention.

D It verifies the authenticity of the firmware before execution to prevent unauthorized code from running.

💡 Hint

Think about what secure boot checks before the device starts running code.

Secure boot ensures that only firmware signed by a trusted source runs on the device, preventing malicious code execution.

💻 Command Output

intermediate

Output of OTA update status command

After initiating an OTA firmware update on an IoT device, you run the command ota_status. What output indicates a successful update?

IOT Protocols

ota_status

A Update successful: firmware version 2.1.0 installed

B Update in progress: 45% completed

C Update failed: signature mismatch

D No update available

💡 Hint

Look for a message confirming the new firmware version is installed.

A successful OTA update message confirms the new firmware version is installed without errors.

❓ Troubleshoot

advanced

Troubleshooting OTA update failure due to signature error

An IoT device fails to apply an OTA update and logs the error: 'Signature verification failed'. What is the most likely cause?

A The device's clock is out of sync, causing certificate validation to fail.

B The firmware image was corrupted during download.

C The firmware was signed with a private key not trusted by the device.

D The device ran out of storage space during the update.

💡 Hint

Consider what causes signature verification to fail specifically.

If the firmware is signed with a key the device does not trust, signature verification will fail, blocking the update.

🔀 Workflow

advanced

Correct sequence for secure OTA firmware update

Arrange the steps in the correct order for a secure OTA firmware update process on an IoT device.

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 1,4,2,3

💡 Hint

Think about verifying before applying the update and reporting after reboot.

The device must first download, then verify the signature before applying the update. After reboot, it reports status.

✅ Best Practice

expert

Best practice to prevent rollback attacks in OTA updates

Rollback attacks happen when an attacker forces a device to install an older, vulnerable firmware version. Which method best prevents this during OTA updates?

A Use a version number check to reject firmware with a version lower than the current one.

B Encrypt the firmware image with AES before sending it to the device.

C Require the device to reboot twice after each update to confirm stability.

D Disable OTA updates after the first successful update to prevent changes.

💡 Hint

Consider how the device can detect if a firmware is older than what it already has.

Checking firmware version numbers and rejecting older versions prevents rollback attacks effectively.

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