Mitigation-page

MID-011: OS Driver/Peripheral Authentication

Mitigation Tier: Foundational

Description

OSes should prevent the execution of malicious drivers by authenticating the drivers before they are loaded and executed on the device. This can be done by only allowing drivers that have been signed and authenticated with a vendor private key to load. These signatures can be checked locally on the device and accepted if and only if the signature passes verification.

Additionally, a central operating system is sometimes responsible for loading firmware at runtime onto peripheral devices (often by way of an associated driver). The operating system should verify the authenticity of those peripheral firmware packages as part of, or alongside, the checking the driver prior to loading them on the peripheral hardware (e.g., an FPGA, sub-component microcontroller, etc.)

This authentication scheme should be coupled with MID-001- Software Only Bootloader Authentication or MID-002 - Hardware-backed Bootloader Authentication, where the device authenticates the bootloader and then leverages that trusted bootloader to verify all the drivers that are going to be run on the device. Therefore, drivers are verified by the bootloader, which is in turn given security guarantees from the root of trust.

IEC 62443 4-2 Mappings

  • CR 3.4 – Software and information integrity

References

[1] H. Sidhpurwala. “How to use the Linux kernel’s Integrity Measurement Architecture.” redhat.com. Accessed: Aug. 28, 2024. [Online.] Available: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture

[2] Gentoo Authors. “Signed kernel module support.” gentoo.org. Accessed: Aug. 28, 2024. [Online.] Available: https://wiki.gentoo.org/wiki/Signed_kernel_module_support

[3] Allen-Bradley. “ControlLogix EtherNet/IP Module.” rockwellautomation.com. Accessed: Aug. 28, 2024. [Online.] Available: https://literature.rockwellautomation.com/idc/groups/literature/documents/rn/1756-rn659_-en-p.pdf