INFORMATION HANDLING SYSTEMS AND RELATED METHODS TO PREVENT TAMPERING AND VERIFY THE INTEGRITY OF NON-VOLATILE DATA STORED WITHIN NON-VOLATILE MEMORY

Various embodiments of information handling systems (IHS) and related methods are provided to prevent tampering and verify the integrity of non-volatile data stored within non-volatile memory, such as but not limited to non-volatile random access memory (NVRAM). More specifically, information handling systems and methods are provided herein to: (a) prevent tampering of non-volatile data stored within non-volatile memory by preventing unauthorized write operations to the non-volatile memory, and either (b) verify the integrity of the non-volatile data read from the non-volatile memory, or (c) detect tampering, if the integrity of the non-volatile data cannot be verified.

FIELD

This invention relates generally to information handling systems (IHSs), and more particularly, to systems and methods that may be used to ensure that data written to non-volatile memory has not been tampered with.

BACKGROUND

Information handling systems (IHSs) typically include a boot system such as, for example, a Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI). The boot system code is generally implemented as boot firmware, which is stored in non-volatile memory, such as read only memory (ROM), non-volatile random access memory (NVRAM) and/or Flash memory. Upon system start-up or reboot, a processing device (such as a host processor and/or an embedded controller) may execute program instructions within the boot firmware to test and initialize the IHS hardware components, perform a Power-On Self-Test (POST) to ensure the hardware configuration is valid and working properly, and load an operating system (OS) from a computer readable storage device into system memory. Additional boot services may also be available for execution when the boot firmware owns the system platform during a pre-boot phase before the OS is loaded and running. Once the OS assumes control of the system platform, the boot system may continue to provide runtime services for the operating system and other application programs executed in the OS environment.

Non-volatile memory (such as ROM, NVRAM and Flash memory) is critical to the information handling system boot process. In conventional information handling systems, however, data stored within non-volatile memory is not secured and can be compromised by malicious actors. In some cases, for example, an authenticated BIOS interface using public key infrastructure (PKI) to authenticate manageability commands may store public key data within NVRAM, so that it can be subsequently used to verify signatures generated by a private counterpart. Because the data stored within NVRAM is not secured or protected against tampering, a malicious actor can write their own public key data to the NVRAM (using, e.g., a DXE driver or runtime driver). Since there is currently no way to prevent an unauthorized write operation to NVRAM, the public key data provided by the malicious actor would be accepted. The malicious actor could then send a remote configuration command (e.g., a remote data-wipe command) signed by their own private key to the information handling system. The remote configuration command would be executed because the driver performing signature verification does not have the capability to determine if the public key data stored within the NVRAM has been tampered with.

In another example, a malicious actor could tamper with BIOS configuration data stored within NVRAM. Like the public key data example mentioned above, any modifications made to the BIOS configuration data by the malicious actor would be written to NVRAM, since there is currently no method available to prevent unauthorized write operations to the NVRAM. When the information handling system is rebooted, the modified BIOS configuration data would be retrieved from NVRAM and used to configure the BIOS, potentially putting the system in a less secure state. For example, a malicious actor could modify BIOS configuration to disable security configurations (such as Secure Boot), change password requirements, enable pre-boot ports (which may put the system in a undesired security state), turn off other security features (such as, e.g., Intel VT-d) and more.

SUMMARY OF THE INVENTION

The following description of various embodiments of information handling systems and related methods is not to be construed in any way as limiting the subject matter of the appended claims.

According to various embodiments of the present disclosure, information handling systems and methods are provided herein to prevent tampering and verify the integrity of non-volatile data stored within non-volatile memory. More specifically, information handling systems and methods are provided herein to: (a) prevent tampering of non-volatile data stored within non-volatile memory by preventing unauthorized write operations to the non-volatile memory, and either (b) verify the integrity of the non-volatile data read from the non-volatile memory, or (c) detect tampering, if the integrity of the non-volatile data cannot be verified.

The embodiments disclosed herein use a hash-based message authentication code (HMAC) to detect tampering of the non-volatile data written to non-volatile memory by a data owner, or verify the integrity of non-volatile data read from the non-volatile memory. All write operations to the non-volatile memory are accompanied by an HMAC calculation of the non-volatile data, which was written to the non-volatile memory by the data owner. To prevent tampering, all write operations are confirmed with the data owner before writing the non-volatile data and the HMAC of the data to the non-volatile memory. During read operations, the HMAC of the non-volatile data read from non-volatile memory is recalculated and compared to the HMAC stored within the non-volatile memory to either verify the integrity of the non-volatile data read from the non-volatile memory or detect tampering of the non-volatile memory data stored therein.

According to one embodiment, an information handling system (IHS) in accordance with the present disclosure may generally include a non-volatile memory, a computer readable memory and at least one processing device. The computer readable memory may store boot firmware and a plurality of boot firmware drivers, including trusted boot firmware drivers, untrusted boot firmware drivers and a property service driver. The at least one processing device may be configured to execute program instructions within the boot firmware when the IHS is powered on or rebooted to initialize a system platform of the IHS, load the plurality of boot firmware drivers and launch a bootloader to load an operating system (OS) for the IHS. In the present disclosure, trusted boot firmware drivers are loaded during an early boot phase of the boot firmware, and untrusted boot firmware drivers are loaded during a late boot phase of the boot firmware or during OS runtime.

The at least one processing device may also be configured to execute a first set of program instructions within at least one trusted boot firmware driver to send a data-write request to the property service driver for writing non-volatile data to a protected namespace within the non-volatile memory. In addition, the at least one processing device may be configured to execute program instructions within the property service driver to receive the data-write request from the at least one trusted boot firmware driver, store the non-volatile data within the protected namespace, and prevent the untrusted boot firmware drivers from modifying or tampering with the non-volatile data written to the protected namespace by the at least one trusted boot firmware driver.

In some embodiments, the at least one processing device may execute program instructions within the at least one trusted boot firmware driver before sending the data-write request to the property service driver. For example, the at least one processing device may execute the first set of program instructions within the at least one trusted boot firmware driver when the at least one trusted boot firmware driver is loaded to: send a hash-based message authentication code (HMAC) key request to an embedded controller (EC) of the IHS to obtain an HMAC key from the EC, and store the HMAC key within a trusted memory region of volatile memory, which is only accessible by the trusted boot firmware drivers, if the HMAC key is received from the EC.

In some embodiments, the information handling system may further include an embedded controller (EC). In some embodiments, the EC may store the HMAC key within an encrypted memory region of the EC, and may provide the HMAC key to the at least one trusted boot firmware driver only if: (a) the HMAC key request is received by the EC before the end of the early boot phase, and (b) the HMAC key request is the first HMAC key request received by the EC during a current system boot.

In some embodiments, the data-write request sent to the property service driver may include the non-volatile data to be written to the protected namespace, a hash-based message authentication code (HMAC) of the non-volatile data and a namespace identifier, which identifies the protected namespace and a data owner of the non-volatile data. In some embodiments, the at least one trusted boot firmware driver may use an HMAC key, which was previously obtained by the at least one trusted boot firmware driver from an embedded controller (EC) of the IHS when the at least one trusted boot firmware driver is loaded, to generate the HMAC of the non-volatile data included within the data-write request.

Upon receiving the data-write request from the at least one trusted boot firmware driver, the program instructions within the property service driver may be further executed by the at least one processing device to: (a) contact the data owner to determine whether the data-write request received from the at least one trusted boot firmware driver was sent from the data owner; (b) reject the data-write request and discard the non-volatile data, if the data owner confirms that the data-write request was not sent from the data owner; and (c) store the non-volatile data and the HMAC of the non-volatile data within the protected namespace, if the data owner confirms that the data-write request was sent from the data owner.

In some embodiments, the at least one processing device may be further configured to execute a second set of program instructions within the at least one trusted boot firmware driver to verify the integrity of the non-volatile data stored within the protected namespace when the non-volatile data is read from the protected namespace. For example, the at least one processing device may be configured to execute the second set of program instructions within the at least one trusted boot firmware driver to send a data-read request to read the non-volatile data stored within the protected namespace of the non-volatile memory, and receive the non-volatile data read from the protected namespace along with a hash-based message authentication code (HMAC) of the non-volatile data, which was stored within the protected namespace along with the non-volatile data. Similar to the data-write request, the data-read request may include a namespace identifier that identifies the protected namespace containing the non-volatile data to be read.

After receiving the non-volatile data and the HMAC read from the protected namespace, the second set of program instructions within the at least one trusted boot firmware driver may be further executed by the at least one processing device to recalculate an HMAC of the non-volatile data read from the protected namespace, and compare the recalculated HMAC of the non-volatile data to the HMAC of the non-volatile data stored within the protected namespace. In some embodiments, the second set of program instructions may verify the integrity of the non-volatile data stored within the protected namespace, if the recalculated HMAC of the non-volatile data matches the HMAC of the non-volatile data stored within the protected namespace. In other embodiments, the second set of program instructions may detect tampering of the non-volatile data stored within the protected namespace, if the recalculated HMAC of the non-volatile data does not match the HMAC of the non-volatile data stored within the protected namespace. If tampering is detected, the at least one processing device may be configured in some embodiments to execute the second set of program instructions within the at least one trusted boot firmware driver to restore the non-volatile data originally stored within the protected namespace.

According to another embodiment, a computer-implemented method performed by at least one processing device of an information handling system (IHS) is provided herein to prevent unauthorized write operations to a non-volatile memory included within the IHS. The computer-implemented method disclosed herein may generally include: (a) receiving a data-write request from a boot firmware driver to write non-volatile data to a protected namespace within the non-volatile memory, wherein the data-write request includes the non-volatile data to be written to the protected namespace and a namespace identifier, which identifies the protected namespace and a data owner of the non-volatile data; (b) contacting the data owner to determine whether the data-write request received from the boot firmware driver was sent from the data owner; and (c) rejecting the data-write request and discarding the non-volatile data, if the data owner confirms that the data-write request received from the boot firmware driver was not sent from the data owner.

In some embodiments, the computer-implemented method may further include storing the non-volatile data to the protected namespace, if the data owner confirms that the data-write request received from the boot firmware driver was sent from the data owner.

In other embodiments, the computer-implemented method may further include storing the non-volatile data and a hash-based message authentication code (HMAC) of the non-volatile data to the protected namespace, if the data owner confirms that the data-write request received from the boot firmware driver was sent from the data owner.

In some embodiments, the computer-implemented method may include additional method steps prior to said receiving. For example, the computer-implemented method may further include executing boot firmware when the IHS is powered on or rebooted to initialize a system platform of the IHS, load boot firmware drivers and launch a bootloader to load an operating system (OS) for the IHS. As noted above, trusted boot firmware drivers may be loaded during an early boot phase of the boot firmware, and untrusted boot firmware drivers may be loaded during a late boot phase of the boot firmware or during OS runtime.

Prior to said receiving, the computer-implemented method may further include: sending a hash-based message authentication code (HMAC) key request from the boot firmware driver to an embedded controller (EC) of the IHS to obtain an HMAC key from the EC; receiving the HMAC key from the EC only if: (a) the HMAC key request is received by the EC before the end of the early boot phase, and (b) the HMAC key request is the first HMAC key request received by the EC during a current system boot; and storing the HMAC key within a trusted memory region of volatile memory, which is only accessible to the trusted boot firmware drivers, if the HMAC key is received from the EC. In some embodiments, the computer-implemented method may further include using the HMAC key stored within the trusted memory region of volatile memory to generate the HMAC of the non-volatile data.

According to yet another embodiment, a computer-implemented method performed by at least one processing device of an information handling system (IHS) is provided herein to verify the integrity of non-volatile data read from a non-volatile memory included within the IHS. The computer-implemented method disclosed herein may generally include: (a) sending a data-read request to read non-volatile data stored within a protected namespace of the non-volatile memory, wherein the data-read request includes a namespace identifier that identifies the protected namespace containing the non-volatile data to be read; (b) receiving the non-volatile data read from the protected namespace along with a hash-based message authentication code (HMAC) of the non-volatile data, which was stored within the protected namespace along with the non-volatile data; (c) recalculating an HMAC of the non-volatile data read from the protected namespace; (d) comparing the recalculated HMAC of the non-volatile data to the HMAC of the non-volatile data stored within the protected namespace; and (e) verifying the integrity of the non-volatile data read from the protected namespace, if the recalculated HMAC of the non-volatile data matches the HMAC of the non-volatile data stored within the protected namespace, or (f) detecting tampering of the non-volatile data read from the protected namespace, if the recalculated HMAC of the non-volatile data does not match the HMAC of the non-volatile data stored within the protected namespace. If tampering is detected in step (f), some embodiments of the computer-implemented method disclosed herein may further include restoring the non-volatile data originally stored within the protected namespace. In some embodiments, the computer-implemented method may further include using the non-volatile data read from the protected namespace only if the integrity of the non-volatile data is verified.

While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the disclosure to the particular form disclosed, but on the contrary, the present disclosure is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present disclosure provides various embodiments of information handling systems and related methods to prevent tampering and verify the integrity of non-volatile data stored within non-volatile memory.FIG.1is a block diagram of an information handling system100(e.g., a desktop computer, laptop computer, tablet computer, server,

Internet of Things (IoT) device, etc.) as it may be configured according to one embodiment of the present disclosure. As shown inFIG.1, IHS100may generally include a host processor110, a system memory120, a graphics processor unit (GPU)130, a display device140, and a platform controller hub (PCH)150. In addition, IHS100may include a computer readable memory160for storing boot firmware162and boot firmware drivers164, a computer readable storage device170for storing an operating system (OS)172and other software modules and data, and an embedded controller (EC)180for storing EC firmware185and a hash-based message authentication code (HMAC) key187.

IHS100may also include various forms of non-volatile memory for storing non-volatile data. For example, IHS100may include non-volatile random access memory (NVRAM)154, as shown inFIG.1. As described in more detail below, techniques are disclosed herein to prevent tampering and verify the integrity of non-volatile data stored within NVRAM154. Although described herein in the context of NVRAM154, one skilled in the art would understand how the techniques described herein may be used to prevent tampering and verify the integrity of non-volatile data stored within other forms of non-volatile memory including, but not limited to, non-volatile rewritable memory.

It is expressly noted that the IHS configuration shown inFIG.1is exemplary only, and that the methods disclosed herein may be implemented on any type and/or configuration of information handling system having non-volatile memory for storing non-volatile data, a computer readable non-volatile memory for storing boot firmware and boot firmware drivers, and one or more processing devices (such as an embedded controller and/or host processor) for executing program instructions (or computer program code) to prevent tampering and verify the integrity of the non-volatile data stored within the non-volatile memory. It will be further understood that while certain components of the information handling system are shown inFIG.1for illustrating embodiments of the present disclosure, the information handling system disclosed herein is not restricted to including only those components shown inFIG.1and described below.

Host processor110may include various types of programmable integrated circuits (e.g., a processor, such as a controller, microcontroller, microprocessor, ASIC, etc.) and programmable logic devices (such as a field programmable gate array “FPGA”, complex programmable logic device “CPLD”, etc.). According to one embodiment, host processor110may include at least one central processing unit (CPU) having one or more processing cores. The CPU may include any type of processing device, such as an Intel Pentium series processor, an Advanced Micro Devices (AMD) processor or another processing device.

System memory120is coupled to host processor110and generally configured to store program instructions (or computer program code), which are executable by host processor110. System memory120may be implemented using any suitable memory technology, including but not limited to, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), non-volatile RAM (NVRAM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), Flash memory, or any other type of volatile memory.

Graphics processor unit (GPU)130is coupled to host processor110and configured to coordinate communication between the host processor and one or more display components of the IHS100. In the illustrated embodiment, GPU130is coupled to display device140(e.g., a display screen or monitor) to provide visual images to the user. In some embodiments, GPU130may also be coupled to one or more display ports to support additional display functions. Although shown inFIG.1as a separate integrated chip coupled to host processor110via a bus, GPU130may alternatively be integrated with the host processor as a silicon-on-chip (SoC) processor.

Platform controller hub (PCH)150is coupled to host processor110and is generally configured to handle I/O operations for the IHS100. As such, PCH150may include a variety of communication interfaces and ports for communicating with various IHS components, such as SPI Flash memory chip152, NVRAM154, computer readable memory160, computer readable storage device170and EC180. Examples of communication interfaces and ports that may be included within PCH150include, but are not limited to, a Peripheral Component Interconnect (PCI) interface, a PCI-Express (PCIe) interface, a Serial Peripheral Interface (SPI), an Enhanced SPI (eSPI), a Serial AT Attachment (SATA) interface, a Low Pin Count (LPC) interface, a Small Computer Serial Interface (SCSI), an Industry Standard Architecture (ISA) interface, an Inter-Integrated Circuit (I2C) interface, a Universal Serial Bus (USB) interface and a Thunderbolt™ interface.

Computer readable storage device170may be any type of persistent, non-transitory computer readable storage device, such as one or more hard disk drives (HDDs) or solid-state drives (SSDs), and may be generally configured to store software and/or data. For example, computer readable storage device170may be configured to store an operating system (OS)172, in addition to other software modules and data. OS172may contain program instructions (or computer program code), which may be executed by host processor110to perform various tasks and functions for the information handling system and/or for the user. More specifically, OS172may include operating system files, applications (including user interface applications), services, hardware drivers, etc., which may be executed by host processor110during OS runtime. Although not restricted to such, OS172may be one of the many Windows® operating systems provided by Microsoft.

Computer readable memory160may include any type of non-volatile (NV) memory including, but not limited to, read-only memory (ROM), Flash memory and non-volatile random-access memory (NVRAM), and may be generally configured to store software and/or firmware modules. The software and/or firmware modules stored within computer readable memory160may generally contain program instructions (or computer program code), which may be executed by one or more IHS processing devices to instruct components of IHS100to perform various tasks and functions for the information handling system.

As shown inFIG.1, computer readable memory160may be generally configured to store boot firmware162and boot firmware drivers164. Boot firmware162may be implemented as a Basic Input/Output System (BIOS) and/or a Unified Extensible Firmware Interface (UEFI). When the IHS100is powered on or rebooted, boot firmware162may be executed by one or more IHS processing devices (e.g., EC180and/or host processor110) to boot the information handling system and perform other functions. As such, boot firmware162may include firmware modules for specifying hardware configuration settings, system date/time, boot sequence, etc. Boot firmware162may also include a wide variety of boot services (which are available for execution when the boot firmware162owns the system platform during a pre-boot phase before the OS172is loaded and running) and runtime services (which are available for execution during OS runtime).

Computer readable memory160may also store a wide variety of boot firmware drivers164. As shown inFIG.2, for example, boot firmware drivers164may store trusted drivers190and untrusted drivers192. As described in more detail below, trusted drivers190are drivers that are loaded during the early boot phase, and thus, contain program instructions (or computer program code) that is trusted by the system platform. Untrusted drivers192are drivers that are loaded during a late boot phase, or during OS runtime, and thus, contain untrusted program code.

Property service driver194is a trusted boot firmware driver, which is stored within computer readable memory160and loaded during the early boot phase. As described in more detail below, property service driver194provides an interface that allows other boot firmware drivers to read from and/or write to non-volatile memory, such as NVRAM154. In addition to facilitating read/write access, property service driver194prevents unauthorized drivers (such as untrusted drivers192) from writing to NVRAM154. In doing so, property service driver194prevents unauthorized drivers from storing their own non-volatile data within NVRAM154, or tampering with the non-volatile data previously stored within NVRAM154by trusted drivers190.

NVRAM154is one example of non-volatile rewritable memory that may be used to store non-volatile data. In some embodiments, NVRAM154may be included within a Serial Peripheral Interconnect (SPI) Flash memory chip152, as shown inFIG.1. In other embodiments (not shown), NVRAM154may be coupled directly to PCH150. Although described in the context of NVRAM, other forms of non-volatile rewritable memory (e.g.,

Flash memory, erasable programmable read-only memory, “EPROM,” electrically erasable programmable read-only memory, “EEPROM,” etc.) may also be included within IHS100for storing non-volatile data. Although particularly useful for securing non-volatile rewritable memory, such as NVRAM154, the embodiments disclosed herein may also be used to prevent tampering and verify the integrity of data stored within substantially any form of memory, including volatile memory, non-volatile memory and non-volatile rewritable memory.

In the embodiment shown inFIG.1, EC180includes read only memory (ROM)182for storing a boot block, random access memory (RAM)184for storing EC firmware185, and non-volatile memory (NVM)186for storing persistent data (such as, e.g., HMAC key187). EC180also includes a processing device188(e.g., a controller, microcontroller, microprocessor, ASIC, etc.) for executing program instructions that are stored within its internal memory (e.g., ROM and RAM) and/or fetched from computer readable memory160and/or SPI Flash memory chip152.

In some embodiments, EC180may be configured to boot the information handling system and perform other functions. For example, processing device188may execute program instructions (e.g., a boot block) stored within ROM182to initiate a boot process for the IHS100. After the boot process is initialized, processing device188may execute program instructions (e.g., EC firmware185) stored within RAM184to determine if an HMAC key187should be generated and/or provided to a boot firmware driver requesting access to the HMAC key, as described in more detail below in reference toFIGS.4and5.

Upon system start-up or reboot, processing device188may initiate a boot process for the information handling system by executing the boot block stored within ROM182while PCH150and host processor110are in reset. As used herein, an IHS “boot process” is a process or set of operations performed by an information handling system component (e.g., EC180and/or host processor110) to load and execute a boot system (e.g., BIOS and/or UEFI) and prepare the system for OS booting. When host processor110comes out of reset, the host processor retrieves the boot firmware162from computer readable memory160, stores a local copy of the boot firmware within system memory120, and executes the boot firmware to configure hardware components of the IHS, perform a Power-On Self-Test (POST) to ensure the hardware configuration is valid and working properly, discover and initialize devices, and launch a bootloader to load OS172. Once launched, the bootloader within boot firmware162retrieves OS172from computer readable storage device170and loads it into system memory120. Additional details regarding an exemplary boot process are shown inFIG.3and described in more detail below.

FIG.3illustrates a conventional UEFI boot process300that may be used to boot the information handling system. When an information handling system is powered up or rebooted, EC180may be used to execute pre-RAM code during the Security (SEC) phase310to initialize host processor110, create a temporary memory store and provide a root of trust for the system. The EC root of trust ensures that any code executed during platform initialization is cryptographically validated, thereby creating a secure boot environment. Once the SEC phase310ends, the Pre-EFI Initialization (PEI) phase320occurs to complete initialization of host processor110, allocate and initialize the system memory120and determine the boot mode (e.g., cold boot, S3, S4, etc.).

After the PEI phase320, control passes to the Driver Execution Environment (DXE) phase330, which is responsible for loading various drivers (e.g., device, bus and/or service drivers), runtime services and any boot services required for the operating system to start. Once the DXE phase330ends, control passes to the Boot Device Selection (BDS) phase340, which may initialize any remaining devices before loading and executing a selected boot entry to launch a bootloader in the Transient System Load (TSL) phase350. The bootloader is executed during the TSL phase350to load OS172and prepare the final OS environment before control of the system platform is passed to the OS during OS runtime360.

As shown inFIG.3, drivers loaded during the UEFI DXE phase330are usually considered to be trusted drivers190containing trusted program code. In other words, drivers loaded early in the boot phase (i.e., the trusted drivers190) are trusted because they are protected by additional security assurances, such as trust chaining from the EC root of trust. Any drivers loaded after the DXE phase330ends (e.g., after the “End of DXE”), such as during BDS phase340, TSL phase350or OS runtime360, are not protected by additional security assurances, and thus, are considered to be untrusted drivers192containing untrusted program code.

The non-volatile data stored within NVRAM154is often critical to the information handling system boot process. For example, NVRAM154may be used to store BIOS configuration data, public key data used to authenticate manageability commands, and/or other persistent data blobs used to trace system or security state across boot cycles. In conventional information handling systems, however, the non-volatile data stored within NVRAM is not secured and can be compromised by malicious actors. For example, a malicious actor can utilize a runtime driver (e.g., an untrusted driver192), or even a DXE driver (which is usually considered to be a trusted driver190), to write their own non-volatile data to the NVRAM. The data provided by the malicious actor would be accepted, since conventional information handling systems do not provide a mechanism for preventing unauthorized write operations to NVRAM. This may cause a wide variety of problems within the information handling system (e.g., data corruption, security breaches, etc.), depending on the data provided by the malicious actor. In addition to failing to prevent unauthorized write operations to NVRAM, conventional information handling systems fail to provide a mechanism for verifying the integrity of the non-volatile data stored therein. Without such verification, conventional information handling systems cannot detect tampering of non-volatile data or provide a mechanism for restoring the data that has been tampered with.

To overcome the above-mentioned problems, the present disclosure provides various embodiments of improved information handling systems and related methods to prevent tampering and verify the integrity of non-volatile data stored within NVRAM (or another type of non-volatile memory). As described in more detail below, some of the embodiments disclosed herein may prevent tampering of non-volatile data by preventing unauthorized write operations to NVRAM. Other embodiments disclosed herein may verify the integrity of the non-volatile data stored within NVRAM when the non-volatile data is read.

FIGS.1,2and4illustrate one embodiment of an improved information handling system (IHS)100in accordance with the present disclosure. The IHS100shown inFIGS.1,2and4improves upon conventional IHSs by providing mechanisms to prevent tampering and verify the integrity of non-volatile data stored within NVRAM154(or another non-volatile memory). More specifically, IHS100includes various hardware and firmware components that may be used to: (a) prevent tampering of non-volatile data stored within NVRAM154by preventing unauthorized write operations to the NVRAM, and either (b) verify the integrity of the non-volatile data read from the NVRAM, or (c) detect tampering, if the integrity of the non-volatile data cannot be verified. Examples of hardware and firmware components that may be used to perform the techniques described herein are illustrated inFIG.4. It is noted that, while certain IHS components are illustrated inFIG.4, IHS100may include additional and/or alternative hardware and/or firmware components to implement the techniques described herein.

In the embodiments disclosed herein, IHS100uses a hash-based message authentication code (HMAC)198to detect tampering of non-volatile data196written to NVRAM154by a data owner, or verify the integrity of non-volatile data196read from the NVRAM. All write operations to NVRAM154are accompanied by an HMAC198calculation of the non-volatile data196written to the NVRAM by the data owner. To prevent tampering, all write operations are confirmed with the data owner before writing the non-volatile data196and the HMAC198of the data to the NVRAM. During read operations, the HMAC of the non-volatile data196read from NVRAM154is recalculated and compared to the HMAC198stored within the NVRAM to either verify the integrity of the data196read from the NVRAM or detect tampering of the data196stored therein.

In the present disclosure, an HMAC key is used to calculate the HMAC of the non-volatile data196written to and read from NVRAM154. In some embodiments, an HMAC key187may be generated by EC180at the first system boot (i.e., the first time the system platform is booted) and may be stored securely within the system platform. For example, processing device188of EC180may execute EC firmware185stored within RAM184to generate an HMAC key187at the first system boot. Once the HMAC key187is generated, EC180may store the HMAC key187within an encrypted memory region of NVM186of the EC until a data owner or another trusted driver190requests access to the HMAC key187.

At each subsequent system boot, one or more boot firmware drivers190/192may send an HMAC key request to EC180when the driver(s) are loaded. EC180may provide the HMAC key187to the first trusted driver190(i.e., a boot firmware driver loaded during the DXE phase330) that requests read access to the HMAC key. After the HMAC key187is read for the first time, EC180rejects all subsequent HMAC key requests until the next system boot. If EC180does not receive an HMAC key request before the end of the DXE phase330, EC180locks the HMAC key data and rejects all read requests to access the HMAC key187until the next system boot.

Once the HMAC key187is received by the first trusted driver190requesting access to the key, the HMAC key187may be stored within a trusted memory region of the system memory120(or another volatile memory), which is only accessible to trusted drivers190. In one example, the HMAC key187may be cached within System Management RAM (SMRAM)122, as shown inFIGS.1and4. This allows only trusted drivers190to retrieve and use the HMAC key187to calculate the HMAC of the non-volatile data196written to and read from NVRAM154.

As noted above, property service driver194provides an interface, which allows other boot firmware drivers190/192to read from and/or write to NVRAM154. In addition to facilitating read/write access, property service driver194prevents unauthorized drivers from writing to NVRAM154by ensuring that only data owners can write to protected namespaces within the NVRAM. As used herein, unauthorized drivers include both untrusted drivers192and trusted drivers190that do not “own” the data and/or the protected namespace where the data is written.

In the present disclosure, a “data owner” is a trusted driver190(i.e., a driver loaded during the early boot phase of the boot firmware) that owns the data and/or the protected namespace where the data is written. In order to write non-volatile data196to a protected namespace, a data owner may send a data-write request to property service driver194containing the non-volatile data196to be written to NVRAM154, an HMAC198calculation of the non-volatile data196and a namespace identifier, which identifies the protected namespace and the data owner. Upon receiving the data-write request, property service driver194may confirm that the data-write was requested by the data owner before writing the non-volatile data196and the HMAC198of the data to the protected namespace identified by the namespace identifier. By requiring confirmation of “ownership,” the property service driver194prevents unauthorized write operations to NVRAM154, and as a result, prevents tampering and/or modification of the non-volatile data stored therein.

A data owner (or another driver) may also send a data-read request to the property service driver194to read non-volatile data196stored within NVRAM154. Upon receiving a data-read request, property service driver194may return the non-volatile data196and the HMAC198of the data stored within NVRAM154to the data owner without confirming “ownership.” Once the requested data196and HMAC198are received, the data owner may recalculate the HMAC of the data196read from NVRAM154and compare the recalculated HMAC to the stored HMAC198. The data owner may verify the integrity of the non-volatile data196read from NVRAM154, if the recalculated HMAC matches the stored HMAC198. Otherwise, the data owner may detect tampering of the non-volatile data196within NRAM154and may take action(s) to restore the non-volatile data196originally stored therein.

FIGS.5-7illustrate various embodiments of methods in accordance with the present disclosure. For example,FIG.5illustrates one embodiment of a method500performed by various hardware and firmware components of the IHS100shown inFIGS.1,2and4to allow only trusted drivers (such as, e.g., a data owner) to write non-volatile data to NVRAM154(or another non-volatile memory).FIG.6illustrates one embodiment of a method600performed by various hardware and firmware components of the IHS100shown inFIGS.1,2and4to enable a trusted driver (e.g., the data owner or another trusted driver) to verify the integrity of non-volatile data read from NVRAM154(or another non-volatile memory).FIG.7illustrates one embodiment of a method700performed by various hardware and firmware components of the IHS100shown inFIGS.1,2and4to prevent untrusted drivers from: (a) accessing the HMAC key stored within the EC180, and (b) writing to protected namespaces within NVRAM154(or another non-volatile memory).

The methods shown inFIGS.5-7are computer implemented methods performed, at least in part, by one or more processing devices of an information handling system. According to one example implementation, EC180and host processor110of IHS100may perform the method steps shown inFIGS.5-7by executing program instructions stored within RAM184(such as, e.g., program instructions contained within EC firmware185) and computer readable memory160(such as, e.g., program instructions contained within trusted drivers190, untrusted drivers192and property service driver194). Unlike conventional information handling systems, the computer implemented methods shown inFIGS.5-7improve the way in which an information handling system functions, in at least some respects, by: (a) preventing tampering of non-volatile data stored within NVRAM154(or another non-volatile memory) by preventing unauthorized write operations to the NVRAM, and either (b) verifying the integrity of the non-volatile data read from the NVRAM, or (c) detecting tampering, if the integrity of the non-volatile data cannot be verified.

FIG.5illustrates one embodiment of a method500that allows only trusted drivers (such as, e.g., a data owner) to write non-volatile data to NVRAM154(or another non-volatile memory). When an information handling system is powered on or rebooted, boot firmware may be executed by one or more processing devices of the IHS to initialize the system platform, load boot firmware drivers and launch a bootloader to load an operating system for the IHS. The method500shown inFIG.5may generally begin when a trusted driver190is loaded during an early boot phase of the boot firmware (in step505), such as during the DXE phase330of the UEFI boot process300shown inFIG.3.

When the trusted driver190is loaded (in step505), the trusted driver may request an HMAC key from EC180(in step510) by sending an HMAC key request to the EC. Upon receiving an HMAC key request, EC180executes EC firmware185to determine if the HMAC key request was received by a trusted driver190or an untrusted driver192before generating and/or returning the HMAC key to the driver requesting access to the key. As shown inFIG.5, for example, EC180may execute EC firmware185to determine if the HMAC key request was received before the end of the DXE phase (in step515), since only trusted drivers are loaded during the DXE phase.

If the HMAC key request is received before the end of the DXE phase (YES branch of step515), EC180executes EC firmware185to determine if the current system boot is the first system boot (i.e., the time the system platform has been booted) (in step525). If EC180determines that the current system boot is the first system boot (YES branch of step525), EC180executes EC firmware185to generate an HMAC key and store the generated HMAC key within an encrypted memory region of the EC (in step530) before returning the HMAC key to the trusted driver requesting access to the key (in step535).

If EC180determines that the current system boot is not the first system boot (NO branch of step525), EC180executes EC firmware185to determine if the HMAC key request is the first HMAC key request received during the current system boot (in step540). If EC180determines this is the first time the HMAC key has been requested (YES branch of step540), EC180returns the HMAC key to the trusted driver190requesting access to the key (in step535). Upon receiving the HMAC key, trusted driver190stores the HMAC key within volatile memory (in step545). In some embodiments, the trusted driver190may store HMAC key within a trusted memory region of the system memory120(e.g., SMRAM122), which is only accessible to trusted drivers190. In doing so, the trusted driver190ensures that only trusted drivers loaded during the early boot phase will be able to retrieve and use the HMAC key.

In some embodiments, EC180may return an error (in step520) and the method500may end, if EC180determines that: (a) the HMAC key request was received after the DXE phase ended (NO branch of step515), or (b) the HMAC key request was not the first HMAC key request received during the current system boot (NO branch of step540). In doing so, EC180prevents untrusted drivers192, which are loaded after the DXE phase ends, from gaining access to the HMAC key.

Sometime after the HMAC key is stored within volatile memory (in step545), the trusted driver190may send a data-write request to the property service driver194to write non-volatile data to a protected namespace within NVRAM154(in step550). The data-write request sent in step550may include the non-volatile data to be written to NVRAM154, an HMAC of the non-volatile data and a namespace identifier, which identifies the protected namespace and the data owner. The trusted driver190may use the HMAC key stored in volatile memory in step545to generate the HMAC of the non-volatile data prior to sending the data-write request in step550.

Property service driver194receives the data-write request to write non-volatile data to the protected namespace identified by the namespace identifier (in step555) and determines if the data-write was requested by the data owner of the protected namespace (in step560). To confirm “ownership,” property service driver194contacts the data owner identified by the namespace identifier, which was sent with the data-write request in step550. Property service driver194may store the non-volatile data and the HMAC of the data within the protected namespace of NVRAM154(in step570), if the data owner of the protected namespace confirms that they sent the data-write request (in step565). If confirmation is not received from the data owner, property service driver194returns an error (in step575) and the method500ends.

FIG.6illustrates one embodiment of a method600that enables a trusted driver (e.g., the data owner or another trusted driver) to verify the integrity of non-volatile data read from NVRAM154(or another non-volatile memory). The method600shown inFIG.6may be performed late in the boot process (e.g., after the end of DXE) and/or during OS runtime to verify the integrity of non-volatile data read from NVRAM154. As shown inFIG.6, method600may begin when a trusted driver190sends a data-read request to the property service driver194to read data stored within a protected namespace in NVRAM154(in step605). Like the data-write request sent in step550ofFIG.5, the data-read request sent in step605ofFIG.6may include a namespace identifier, which identifies the protected namespace containing the data to be read.

Upon receiving the data-read request (in step610), property service driver194reads the non-volatile data and the HMAC of the non-volatile data stored within the protected namespace of NVRAM154(in step615) and returns the non-volatile data and the stored HMAC to the trusted driver190requesting the data. Once the requested data and HMAC are received, the trusted driver190recalculates the HMAC of the data read from NVRAM154using the HMAC key stored in volatile memory (in step620) and compares the recalculated HMAC to the HMAC read from the NVRAM (in step625). The trusted driver190may verify the integrity of the non-volatile data read from NVRAM154(in step635), if the recalculated HMAC matches the HMAC read from the NVRAM (YES branch of step630). The non-volatile data read from NVRAM154is used only if the integrity of the non-volatile data is verified in step635. By verifying the integrity of the non-volatile data read from NVRAM154before it is used, the method600shown inFIG.6prevents corrupted data (i.e., non-volatile data that has been modified by an untrusted boot firmware driver or malicious actor) from being utilized within the IHS.

If the recalculated HMAC does not match the HMAC read from NVRAM154(NO branch of step630), the trusted driver190may detect tampering of the non-volatile data read from NRAM154and may take action(s) to restore the non-volatile data originally stored therein (in step640). For example, if tampering is detected, the trusted driver190may fetch a copy of the non-volatile data from a trusted location and may use the copy of the non-volatile data to replace or restore the non-volatile data originally stored within the protected namespace of NVRAM154.

FIG.7illustrates one embodiment of a method700that prevents untrusted drivers from: (a) accessing the HMAC key stored within the EC180, and (b) writing to protected namespaces within NVRAM154(or another non-volatile memory). The method700shown inFIG.7may generally be performed during a late boot phase (e.g., after the end of DXE) and/or during OS runtime to prevent unauthorized write operations from untrusted drivers192. As shown inFIG.7, method700may begin when an untrusted driver192(e.g., a malicious driver) is loaded (in step705) after the DXE phase ends. When an untrusted driver192is loaded (in step705), the untrusted driver may request an HMAC key from the EC180(in step710) by sending an HMAC key request to the EC. Similar to the embodiment shown inFIG.5, EC180may execute EC firmware185upon receiving an HMAC key request to determine if the HMAC key request was received before the end of the DXE phase (in step715). Since untrusted drivers are loaded after the end of DXE (NO branch of step715), EC180returns an error to the untrusted driver192(in step720). This prevents untrusted drivers192from gaining access to the HMAC key, which is used in the present disclosure to verify the integrity of non-volatile data stored within NVRAM154.

In some cases, an untrusted driver192may attempt to tamper with non-volatile data stored within NVRAM154. For example, the untrusted driver192may send a data-write request to property service driver194to write their own non-volatile data to a protected namespace within NVRAM154(in step725). The data-write request sent from the untrusted driver192may include the non-volatile data to be written to NVRAM154and a namespace identifier, which identifies the protected namespace and the data owner. Property service driver194receives the data-write request to write non-volatile data to the protected namespace identified by the namespace identifier (in step730) and determines if the data-write was requested by the data owner of the protected namespace (in step735). To confirm “ownership,” the property service driver194contacts the data owner identified by the namespace identifier sent with the data-write request. In the embodiment shown inFIG.7, the data owner informs the property service driver194that the data-write was not requested by the data owner of the protected namespace (in step740). Since “ownership” is not confirmed, the property service driver194rejects the data-write request and discards the non-volatile data (in step745) and returns an error (in step750). In step755, the untrusted driver192receives the error indicating that the data-write attempt failed and the method700ends.

It will be understood that one or more of the tasks, functions, or methodologies described herein may be implemented, for example, as firmware or as a computer program of instructions embodied in a non-transitory tangible computer readable medium that is executed by a CPU, embedded controller, microcontroller, processor, microprocessor, FPGA, ASIC, or other suitable processing device.

While the invention may be adaptable to various modifications and alternative forms, specific embodiments have been shown by way of example and described herein.