Defending Against Rootkit Attacks and Avoiding Malicious Malware

A particularly insidious form of malware is firmware injected into the system via rootkit (or bootkit) attack because it loads before an operating system boots and can hide from ordinary anti-malware software. Rootkits also are difficult to detect and remove. One way to defend against rootkit attacks is to enable a system to use a Secure boot device that is designed to detect non-authorized firmware in the pre-OS environment.

Secure boot with hardware root of trust is critical because it protects a system against threats before they can be loaded into the system. The secure boot process only allows the system to boot using software trusted by the manufacturer. What makes secure boot secure? There are two primary aspects to secure boot:

• The secure bootloader is stored in memory that is immutable – in other words, it cannot be changed
• The secure bootloader authenticates the first-stage firmware bootloader before it is executed in-system to verify it has been signed by the trusted original equipment manufacturer (OEM). 

Let’s examine secure boot and how the embedded controller is used as the primary bootloader (i.e., root-of-trust) in embedded and PC platforms supporting secure boot.

Embedded Controller

The embedded controller has long been a part of personal computer (PC) mobile platforms including laptops, netbooks and tablets. The embedded controller also is an integral part of embedded designs in the server, industrial, telecommunications and industrial segments. Today’s embedded controller is highly configurable and is used by OEMs to implement differentiating features for their systems – including standby power sequencing, thermal monitoring, fan control and battery charging. 

The embedded controller also is used as the root-of-trust or a trust anchor in a system to support secure boot. Figure 1 shows an example of a system and its basic components.

There may be many embedded processors in the system used to execute firmware. Any processor executing firmware that can be updated in system must have the firmware authenticated before it is permitted to run. The embedded controller secure bootloader, which is immutable code stored in ROM, is the first code to be executed in the system. It is responsible for authenticating and executing the OEM’s first stage firmware bootloader stored in system flash.

Since the OEM first stage bootloader resides in flash and may be updated in system, this code cannot be considered immutable or a root-of-trust. It must be authenticated before it is executed in a system that supports Secure Boot. Secure Boot prevents malicious or unauthorized code from being executed in system. Once the system is fully operational and the main CPU is executing code, it can use either a local trusted platform module or a remote server to validate or attest to the integrity of the hardware platform.

System Boot Sequence

When power is applied to the system the immutable secure bootloader initializes the embedded controller subsystem then loads and authenticates the OEM firmware stored in system flash. The OEM firmware maintains the chain-of-trust by authenticating the next layer of firmware, such as the system BIOS, configures the system and starts the process to bring the system out of reset. Each layer of firmware authenticates the next layer until the secure boot process completes. Once the boot process completes the main system CPU is released from reset and begins to execute the operating system.

UEFI, Unified Extensible Firmware Interface specification, is a widely accepted standard for describing the interface between the firmware boot sequence and the system operating system. 

Secure Boot Authentication

Secure boot is the act of authenticating all firmware or software in the system before it is executed. A form of malware is firmware injected into a system via a rootkit attack that can replace the OEM's first-stage firmware bootloader and hide from anti-malware software, loading the normal operating system with no indication anything is wrong and remaining undetectable (see figure 2a).

Figure 2a: Example of a UEFI boot sequence.

Figure 2b: Example of a UEFI boot sequence with hardware trust anchor.

Microchip’s embedded controller is the firmware root-of-trust. Its job is to authenticate the digital signature of the OEM’s first stage bootloader. The OEM’s first stage bootloader will authenticate the second stage firmware loader which will in turn authenticate the next firmware or software code to run in system. This is referred to as the chain-of-trust. The embedded controller secure bootloader is the first link in the chain and is referred to as a trust anchor.

Digital Signatures

Digital signatures provide two functions: integrity checking and authentication. A root-of-trust or trust anchor provisioned with the digital signature’s public key can validate that the firmware image is the OEM’s approved code image for use in system.

To create a digital signature, the OEM first generates an asymmetric key pair that meets the requirements of the selected signing algorithm, like RSA-2048 or Elliptic Curve. The message (i.e., code message) is processed through a hashing algorithm (e.g., SHA-384) and signed using the private key (see figure 3).

To verify a digital signature, the message (i.e., code image) is processed through the same hashing algorithm used to sign the image. The digital signature is validated using the asymmetric Public Key generated compared to the public key provided during signing. If the two results are identical, then the authenticity of the image has been validated indicated the message has not been altered and is the same as the message that was originally signed (see figure 4).

Figure 4: Verifying a digital signature.

Microchip’s Embedded Controller Secure Bootloader

Microchip recently announced a new cryptography-enabled microcontroller (MCU), the CEC1712 MCU with Soteria-G2 custom firmware, designed to stop malicious malware injected by rootkit attacks for systems that boot from external Serial Peripheral Interface (SPI) flash memory.

A Microchip embedded controller secure bootloader refers to the firmware stored in the EC read-only memory (ROM) that executes trusted code used to load, authenticate and execute the OEM first-stage bootloader that configures and powers on a system. 

Microchip’s embedded controller is assumed to be trusted (i.e., trust anchor). Microchip’s embedded controller boot ROM is responsible for loading, authenticating and executing the OEM boot firmware that is stored in the external SPI Flash while holding the system in reset. By design, the embedded controller is the first component to be powered on in the platform. The secure bootloader, which is hardcoded in ROM, holds the rest of the system in reset until it loads and authenticates the OEM application firmware which is responsible for initializing the system, power sequencing and bringing the system out of reset.

When power is first applied, the application processor and higher-level components are held in reset until the embedded controller boot ROM has loaded, authenticated and executed the OEM boot firmware (see figure 5). 

Figure 5: Microchip's embedded controller in system.

The OEM programs the external SPI Flash with a signed image. The image is signed using the OEM’s private key, SHA-384 hash algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA). The Elliptic Curve used is the NIST standard P-384 elliptic curve. This key must always be kept secret by the OEM. The OEM programs the public key, used to verify the signature, in embedded controller’s OTP (one-time programmable) memory. The embedded controller secure bootloader authenticates the OEM firmware image using the ECDSA public key stored in OTP as part of the embedded controller secure boot sequence.

Embedded Controller Secure Boot Sequence

The following summarizes Microchip’s embedded controller secure boot sequence implemented in several devices, including the CEC1712:

1. Following a POR or chip reset, the RSMRST# pin is tristate and pulled low externally to hold the system in reset.
2. The embedded controller boot ROM initializes the device (i.e., samples straps, clears memories, etc.).
3. The embedded controller boot ROM executes the secure bootloader which validates the ECDSA signature of the SPI flash image.
4. If the image is loaded successfully (success = valid authentic image), the boot ROM secures the device (e.g., clears crypto memory, locks keys, etc.) and jumps into the firmware application code (i.e., OEM boot code).
5. If the image is not loaded successfully (i.e., signature check fails), the boot ROM secures the device (e.g., clears crypto memory, locks keys, etc.) and waits for POR event. The system will not boot.

With the rapid growth of the 5G cellular infrastructure, growing networks and data centers supporting expanding cloud computing, developers need new ways to ensure operating systems remain secure and uncompromised. 

Microchip’s new Soteria-G2 custom firmware on its full-featured CEC1712 Arm® Cortex®-M4-based microcontroller provides secure boot with hardware root of trust protection in a pre-boot mode for those operating systems booting from external SPI flash memory. Find out more about Microchip’s proven solutions here. 

If you’re concerned about any aspect of security or want to learn about the latest trends and developments for safeguarding your designs, explore our ShieldsUP! webinar series.