Threat modeling for the IoT device bootloader

Original article from AWS: https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html

Background

As a working definition, the embedded IoT devices referenced by this threat model are microcontroller-based products that interact with cloud services. They may be deployed in consumer, commercial, or industrial settings. IoT devices may gather data about a user, a patient, a machine, or an environment, and may control anything from light bulbs and door locks to factory machinery.

Threat modeling is an approach to security from the point of view of a hypothetical adversary. By considering the adversary's goals and methods, a list of threats is created. Threats are attacks against a resource or asset performed by an adversary. The list is prioritized and used to identify or create mitigations. When choosing mitigations, the cost of implementing and maintaining them should be balanced with the real security value they provide. There are multiple threat model methodologies. Each is capable of supporting the development of a secure and successful IoT product.

The Factbird offers OTA ("over-the-air") software updates to IoT devices. The update facility combines cloud services with on-device software libraries and a partner-supplied bootloader. This threat model focuses specifically on threats against the bootloader.

Bootloader use cases

• Digitally sign and encrypt firmware before deployment.
• Deploy new firmware images to a single device, a group of devices, or an entire fleet.
• Verify the authenticity and integrity of new firmware after it's deployed to devices.
• Devices only run unmodified software from a trusted source.
• Devices are resilient to faulty software received through OTA.

Data Flow Diagram

Threats

Some attacks will have multiple mitigations; for example, a network man-in-the-middle intended to deliver a malicious firmware image is mitigated by verifying trust in both the certificate offered by the TLS server and the code-signer certificate of the new firmware image. To maximize the security of the bootloader, any non-bootloader mitigations are considered unreliable. The bootloader should have intrinsic mitigations for each attack. Having layered mitigations is known as defense-in-depth.

Threats:

• An attacker hijacks the device's connection to the server to deliver a malicious firmware image.

  Mitigation example

  • Upon boot, the bootloader verifies the cryptographic signature of the image using a known certificate. If the verification fails, the bootloader rolls back to the previous image. (Factbird Duo does this)

• An attacker exploits a buffer overflow to introduce malicious behavior to the existing firmware image stored in flash.

  Mitigation examples

  • Upon boot, the bootloader verifies, as previously described. When verification fails with no previous image available, the bootloader halts. (Factbird Duo does this)
  • Upon boot, the bootloader verifies, as previously described. When verification fails with no previous image available, the bootloader enters a fail safe OTA only mode.

• An attacker boots the device to a previously stored image, which is exploitable.

  Mitigation examples

  • Flash sectors storing the last image are erased upon successful installation and test of a new image. (Factbird Duo does this)
  • A fuse is burned with each successful upgrade, and each image refuses to run unless the correct number of fuses have been burned.