Threat modeling for the IoT device bootloader
Cited article (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.
-
An OTA update delivers a faulty or malicious image that bricks the device.
Mitigation example
- The bootloader starts a hardware watchdog timer that triggers rollback to the previous image. (Factbird Duo does this)
-
An attacker patches the bootloader to bypass image verification so the device will accept unsigned images.
Mitigation examples
- The bootloader is in ROM (read-only memory), and cannot be modified. (Factbird Duo does this)
- The bootloader is in OTP (one-time-programmable memory), and cannot be modified.
- The bootloader is in the secure zone of ARM TrustZone, and cannot be modified.
-
An attacker replaces the verification certificate so the device will accept malicious images.
Mitigation examples
- The certificate is in a cryptographic co-processor, and cannot be modified. (Factbird Duo does this)
- The certificate is in ROM (or OTP, or secure zone), and cannot be modified.
Further threat modeling
This threat model considers only the bootloader. Further threat modeling could improve overall security. A recommended method is to list the adversary's goals, the assets targeted by those goals, and points of entry to the assets. A list of threats can be made by considering attacks on the points of entry to gain control of the assets. The following are lists of examples of goals, assets, and entry points for an IoT device. These lists are not exhaustive, and are intended to spur further thought.
Adversary's goals
- Extort money
- Ruin reputations
- Falsify data
- Divert resources
- Remotely spy on a target
- Gain physical access to a site
- Wreak havoc
- Instill terror
Key assets
- Private keys
- Client certificate
- CA root certificates
- Security credentials and tokens
- Customer's personally identifiable information
- Implementations of trade secrets
- Sensor data
- Cloud analytics data store
- Cloud infrastructure
Entry points
- DHCP response
- DNS response
- MQTT over TLS
- HTTPS response
- OTA software image
- Other, as dictated by application, for example, USB
- Physical access to bus
- Decapped IC