MID-002: Hardware-backed Bootloader Authentication
Mitigation Tier: Intermediate
Description
A secure boot scheme where a hardware root of trust verifies the integrity of the bootloader will give a device strong security against bootloader tampering prior to boot time. A hardware root of trust gives a device the ability to securely store signatures and keys somewhere that they cannot be accessed before or after booting. This root of trust can then be used to perform boot-time integrity verification of the bootloader to ensure it was not previously modified or tampered with. Before a bootloader is executed, it should be authenticated by taking an integrity measurement (e.g., hash) of the bootloader, and verifying the integrity measurement against a signed integrity measurement stored in the hardware element. A device may have multiple bootloaders which operate in multiple stages, this mitigation may need to be implemented and executed across multiple times to ensure integrity of each stage.
Additionally, this hardware root of trust can be used to anchor a chain-of-trust flowing from the bootloader that can be used to verify the integrity of other modules on the device.
This implementation will vary based on different secure boot schemes and frameworks, along with device architectures and operating systems.
Note: This Mitigation requires that the device has a secure hardware root of trust. Please see PID-25 - Device includes software/hardware root of trust for information about related threats and mitigations.
IEC 62443 4-2 Mappings
- EDR / HDR/ NDR 3.14 - Integrity of the boot process
References
[1] Microsoft. “Secure boot.” microsoft.com. Accessed: Aug. 28, 2024. [Online.] Available: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot
[2] T. Lewis and M. Khandelwal. “Best Practices for UEFI Secure Boot Guidelines.” uefi.org. Accessed: Aug. 28, 2024. [Online.] Available: https://uefi.org/sites/default/files/resources/Insyde%20HPE%20NSA%20and%20UEFI%20Secure%20Boot%20Guidelines_FINAL%20v2%20%281%29.pdf
[3] ARM. “Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/den0006/d
[4] National Security Agency. “Boot Security Modes and Recommendations.” nsa.gov. Accessed: Aug. 28, 2024. [Online.] Available: https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-boot-security-modes-and-recommendations.pdf
[5] Intel. “Intel Hardware Shield - Below-the-OS Security.” intel.com. Accessed: Aug. 28, 2024. [Online.] Available: https://web.archive.org/web/20231220181349/https://www.intel.com/content/dam/www/central-libraries/us/en/documents/below-the-os-security-white-paper.pdf
[6] ARM. “Secure boot.” arm.com. Accessed: Aug. 28, 2024. [Online.] Available: https://developer.arm.com/documentation/PRD29-GENC-009492/c/TrustZone-Software-Architecture/Booting-a-secure-system/Secure-boot?lang=en
[7] Chromium. “Security in ChromeOS.” chromium.org. Accessed: Aug. 28, 2024. [Online.] Available: https://www.chromium.org/chromium-os/developer-library/reference/security/security-whitepaper/#hardware-root-of-trust-and-verified-boot
[8] 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