MID-026: Secure Firmware Update
Mitigation Tier: Foundational
Description
Firmware update mechanisms can provide a vector for threat actors to install malicious code, extract secrets from the firmware, or disrupt the device’s availability. A secure firmware update mechanism must ensure the authenticity of the firmware, encrypt the file or communication channel, ensure updates cannot be triggered at inopportune times, and prevent rollback to insecure versions. Key functions of a secure firmware update are provided below.
1- Authenticity and Integrity: The device should validate that the firmware update has not been tampered with before installing it on the device. The vendor should digitally sign the firmware using a protected private key, while the device should include an associated public key or public key hash to verify the signature scheme [1]. The digital signature should be computed across the entire firmware file. To sign a firmware image, the firmware signer should compute a hash of the firmware and run that hash through a signing software. The device can then take a hash of the firmware that it receives and use the public key to verify the signature from the signed hash to compare the two hash values [7].
2- Encryption: Encrypting firmware in-transit and at-rest is an effective way to prevent adversaries from reverse engineering the firmware to extract secrets or discovering vulnerabilities.
At-rest: If the firmware deployment requires firmware to be manually downloaded and transferred, stored on intermediary devices before reaching the target device, or stored anywhere on the device before loading into flash memory, then the firmware file should be encrypted. Encryption on-device could be implemented by encrypting all sections of the firmware and having the bootloader decrypt the firmware when it needs to be loaded. The bootloader would check the authenticity and integrity of the encrypted firmware, as mentioned in step 1, and then would decrypt the firmware if all the checks pass. The firmware would then be available for execution [8][9].
In-transit: If the firmware is deployed using an over-the-air update scheme (i.e., the firmware file will not reside on any intermediary systems), encryption should be provided by using an encrypted and authenticated communication protocol with public key-based authentication [9].
3- Update Initiation: If a device can have its firmware update process initiated at any time, threat actors may be able to cause a denial-of-service attack against the device by initiating it at an unwanted time. To prevent these scenarios, all manually initiated firmware updates should only be initiated by authenticated and authorized privileged administrative users. In the event that the device is using automatic firmware updates, any requests to initiate the firmware update should go over an encrypted and authenticated protocol.
4- Rollback Protection: Optionally, rollback protections can be added to the firmware update process to prevent threat actors from reinstalling an older, vulnerable version of firmware for future exploitation. Adding rollback protections are not always needed and may complicate device processes. See MID-030 - Firmware Rollback Protections for more information.
Additional Threats: This mitigation depends on multiple cryptographic mechanisms, protocols, and keys, which are all potentially vulnerable to different threats (listed below), which should also be considered with the implemented solution.
TID-330 Cryptographic Timing Side-Channel
TID-214 Secrets Extracted from Device Root of Trust
TID-411 Weak/Insecure Cryptographic Protocol
TID-318 Insecure Cryptographic Implementation
TID-317 Predictable Cryptographic Key
IEC 62443 4-2 Mappings
- EDR / HDR / NDR 3.10 - Support for updates (1) Update authenticity and integrity
References
[1] K. Goldman, E. Palmer, T. Block, C. Engel, and D. Heller. “Best Practices for Firmware Code Signing.” opencompute.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.opencompute.org/documents/ibm-white-paper-best-practices-for-firmware-code-signing
[2] A. Regensheid. “NIST 800-193 - Platform Firmware Resiliency Guidelines.” nist.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf
[3] K. Masica. “Firmware Management Best Practices Guide for Energy Infrastructure Embedded Control Devices.” dtic.mil. Accessed: Aug. 28, 2024. [Online.] Available: https://apps.dtic.mil/sti/trecms/pdf/AD1135234.pdf
[4] J. Beningo. “5 Elements to a Secure Embedded System, Part 5: Secure Storage.” designnews.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.designnews.com/embedded-systems/5-elements-to-a-secure-embedded-system-part-5-secure-storage
[5] Embedded Staff. “Building a security-optimized embedded design using protected key storage.” embedded.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.embedded.com/building-a-security-optimized-embedded-design-using-protected-key-storage
[6] S. Garg. “Protecting Security Critical Firmware.” linaro.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.linaro.org/blog/protecting-security-critical-firmware/
[7] Chipkin. “What Is Signed Firmware.” chipkin.com. Accessed: Aug. 28, 2024. [Online.] Available: https://store.chipkin.com/articles/what-is-signed-firmware
[8] G. Garcia. “Securing Firmware Updates With AES.” memfault.com. Accessed: Aug. 28, 2024. [Online.] Available: https://interrupt.memfault.com/blog/firmware-encryption-with-python
[9] D. Pang. “Cryptographic Techniques for Safer Firmware.” electronicdesign.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.electronicdesign.com/technologies/embedded/article/21163055/neuronicworks-cryptographic-techniques-for-safer-firmware
[10] J. van Woudenberg. “Top 10 Secure Boot mistakes.” Presented at hardware.io Hardware Security Conference and Training, Santa Clara, CA, USA, 2019. [Online]. Available: https://hardwear.io/usa-2019/presentations/Top-10-Secure-Boot-Mistakes-v1.1-hardwear-io-usa-2019-jasper-van-woudenberg.pdf