MID-001: Software Only Bootloader Authentication

Mitigation Tier: Foundational

Description

Under a software bootloader authentication scheme, the bootloader is authenticated using a software-based mechanism where the key, authenticated integrity measurement, and verification logic are stored within memory and the authentication is performed on a main/multipurpose processor. This performs 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 hash against a stored signed integrity measurement stored in a bootrom. A device may have multiple bootloaders which operate in multiple stages; therefore, this mitigation may need to be implemented and executed multiple times across the stages to ensure the integrity of each stage.

Lastly, authenticating the first and all subsequent bootloaders allows the device to build a chain-of-trust, through which a secure boot scheme can be made for the device. Secure boot schemes allow the device to use earlier-staged authenticated bootloaders to authenticate and launch subsequent bootloaders and software.

Because this mitigation stores the keys and authentication logic/mechanisms in memory and executes checks on the main CPU, this mitigation is vulnerable to key extractions (TID-214: Secrets Extracted from Device Root of Trust) and tampering with the authentication process (TID-214: Inadequate Bootloader Protection and Verification). To minimize this threat, the first stage of the bootloader that performs this check should be stored within ROM to prevent modification by possible malicious code injected at runtime.

Note: This mitigation is in contrast to a hardware-based bootloader authentication scheme (MID-002 - Hardware-backed Bootloader Authentication), where dedicated hardware is used to protect the key and authentication process.

Limitation: A software-based bootloader authentication scheme can be bypassed if a threat actor is able to physically extract symmetric keys from storage, memory, or through side-channel analysis of the processor while the key is in-use. Additionally, if the device is using asymmetric encryption, these protections can be undermined by changing the hash of the public key or the public key itself stored on the device.

IEC 62443 4-2 Mappings

EDR / HDR / NDR 3.14 - Integrity of the boot process

References

[1] Ubuntu. “Signing.” ubuntu.com. Accessed: Aug. 28, 2024. [Online.] Available: https://wiki.ubuntu.com/UEFI/SecureBoot/Signing

[2] U-Boot. “U-Boot Verified Boot.” u-boot.org. Accessed: Aug. 28, 2024. [Online.] Available: https://docs.u-boot.org/en/latest/usage/fit/verified-boot.html

[3] 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

[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] Android. “Implementing dm-verity.” android.com. Accessed: Aug. 28, 2024. [Online.] Available: https://source.android.com/docs/security/features/verifiedboot/dm-verity

[6] 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