11institutetext: Waseda University, 1-104 Totsukamachi, Shinjuku-ku, Tokyo
169-8050, Japan 22institutetext: Institute of Information Security., 2-14-1
Tsuruyacho, Kanagawa-ku, Yokohama-shi, Kanagawa 221-0835, Japan
33institutetext: NTT Security (Japan) KK, 4-14-1 Sotokanda, Chiyoda-ku, Tokyo
101-0021, Japan 44institutetext: Satoshi’s System Programming Lab
https://tandasat.github.io 55institutetext: NICT, 4-2-1 Nuki-kitamachi,
Kokubunji-shi, Tokyo 184-0015, Japan 66institutetext: RIKEN API, 15th Floor,
Nihonbashi 1-4-1, Nihonbashi, Chuo-ku, Tokyo 103-0027, Japan

# SmmPack: Obfuscation for SMM Modules with TPM Sealed Key

If you cite this paper please use the following reference:
Kazuki Matsuo  Satoshi Tanda  Yuhei Kawakoya  Kuniyasu Suzaki  and Tatsuya
Mori  “SmmPack: Obfuscation for SMM Modules  ” Proceedings of the 21st
Conference on Detection of Intrusions and Malware and Vulnerability Assessment
(DIMVA 2024)  July 2024  Satoshi Tanda 44 Kuniyasu Suzaki 22
0000-0003-0912-0087 Yuhei Kawakoya 33 0009-0005-9310-0493 Tatsuya Mori 115566
0000-0003-1583-4174

###### Abstract

System Management Mode (SMM) is the highest-privileged operating mode of x86
and x86-64 processors. Through SMM exploitation, attackers can tamper with the
Unified Extensible Firmware Interface (UEFI) firmware, disabling the security
mechanisms implemented by the operating system and hypervisor. Vulnerabilities
enabling SMM code execution are often reported as Common Vulnerabilities and
Exposures (CVEs); however, no security mechanisms currently exist to prevent
attackers from analyzing those vulnerabilities. To increase the cost of
vulnerability analysis of SMM modules, we introduced SmmPack. The core concept
of SmmPack involves encrypting an SMM module with the key securely stored in a
Trusted Platform Module (TPM). We assessed the effectiveness of SmmPack in
preventing attackers from obtaining and analyzing SMM modules using various
acquisition methods. Our results show that SmmPack significantly increases the
cost by narrowing down the means of module acquisition. Furthermore, we
demonstrated that SmmPack operates without compromising the performance of the
original SMM modules. We also clarified the management and adoption methods of
SmmPack, as well as the procedure for applying BIOS updates, and demonstrated
that the implementation of SmmPack is realistic.

###### Keywords:

UEFI SMM TPM2.0 Packing.

##  1 Introduction

System Management Mode (SMM) is the highest-privileged operating mode in x86
and x86-64 processors. The SMM module, a type of Unified Extensible Firmware
Interface (UEFI) module, operates in a memory area called the System
Management RAM (SMRAM), which is accessible only during SMM. Attackers can
arbitrarily modify the BIOS image and insert malware or bypass security
mechanisms, such as Virtualization Based Security (VBS) [32, 11], by
escalating privileges to SMM. Consequently, vulnerability researchers are
actively exploring SMM modules for exploits, as shown by rising CVE reports
[25].

Many vulnerabilities in CVEs are caused by implementation errors, such as
memory access outside the SMRAM [8, 6, 26]. To exploit these vulnerabilities,
attackers first need to analyze the SMM module. Unfortunately, there are
currently no security mechanisms that hinder attacker’s vulnerability
analysis. Consequently, developers of SMM modules are forced to implement
these modules without vulnerabilities to defend against the exploits. Existing
security mechanisms, such as secure boot, cannot prevent such attacks because
attacks utilizing these vulnerabilities do not require modification to the
UEFI firmware. Therefore, security mechanisms that increase the cost for
attackers are necessary.

We propose SmmPack as an obfuscation system to increase the cost of
vulnerability analysis of SMM modules to attackers. To the best of our
knowledge, this is the first study to cautiously explore the application of
obfuscation techniques to UEFI firmware while comprehensively elucidating the
required technologies, specific implementation procedures, feasibility, and
constraints, thus pioneering a new research domain in this area. Note that, in
this paper, the act of increasing the cost of vulnerability analysis is
defined as “obfuscation.”

The key technical concept of SmmPack involves sealing the key used for
encrypting the SMM modules in the TPM, preventing attackers from extracting
the key even on their own terminals. Key retrieval is restricted by the
Platform Configuration Register (PCR), making it impossible to obtain the key
after the OS has booted. Additionally, during the boot phase, if such SMM
module performing SMRAM dump is added, the PCR value changes, preventing key
acquisition. As a result, attackers are limited to methods such as cold boot
attacks involving memory transplantation and DMA within an extremely small
time frame, forcing them to resort to costly methods111The magnitude of these
costs is discussed in Section 5.4.. Furthermore, these methods may not be
feasible depending on the presence of other security mechanisms.

In this study, we first defined the threat model for SmmPack. Then, we
implemented a prototype and evaluated its effectiveness 222As an artifact of
this paper, the implementation code of SmmPack is shown at [21].. We conducted
an assessment to determine whether SmmPack can effectively prevent various
methods of acquiring SMM modules that attackers might attempt. Additionally,
we demonstrate that the boot time and BIOS size overheads are both within
practical limits. Finally, we explain the procedures for managing and adopting
SmmPack along with the process entailed in implementing BIOS updates and
substantiate the feasibility of incorporating SmmPack.

The contributions of this study have been summarized as follows:

  * $\bullet$

We presented SmmPack, the first obfuscation framework developed for platform
firmware, which is uniquely positioned as a pioneering solution that protects
SMM modules from attacker vulnerability analysis.

  * $\bullet$

We demonstrated the effectiveness of SmmPack as a defense against various
means of SMM module acquisition.

  * $\bullet$

We showed that the impact of SmmPack on the system’s performance is minimal,
indicating the practicality of its implementation.

  * $\bullet$

We clarified the management and deployment methods of SmmPack, as well as the
procedure for applying BIOS updates, and demonstrated that the implementation
of SmmPack is realistic.

##  2 Background

In this section, we first provide an overview of UEFI, SMM, and TPM. Next, we
explain what attackers can achieve by attacking SMM and discuss the types of
vulnerabilities in SMM. Finally, we explain the security mechanisms that
currently exist in UEFI.

###  2.1 UEFI

The Unified Extensible Firmware Interface (UEFI) is a set of specifications
maintained by the Unified EFI Forum [2] that defines the interface between the
platform firmware and the OS. A UEFI-compliant BIOS comprises numerous UEFI
modules, most of which reside within a Serial Peripheral Interface (SPI) flash
memory chip. The UEFI specifications partition the boot process into seven
distinct phases, with the following five phases representing the most
important stages of the procedure:

  * $\bullet$

SEC (Security): The initial code running and is the root of trust of the
system.

  * $\bullet$

PEI (Pre-EFI Initialization): Initializes permanent memory and handles the
different states of the system.

  * $\bullet$

DXE (Driver Execution Environment): Execute drivers that initialize platform
components.

  * $\bullet$

BDS (Boot Device Selection): Select the boot device and run the boot loader.

  * $\bullet$

RT (Runtime): The phase when OS executes. UEFI environment except runtime
services are discarded.

Firmware that runs earlier in the boot phase has a more platform-dependent
implementation. The phase until BDS is called the boot phase, and the phase
after the OS starts is called the runtime phase. In this study, we
specifically focused on the DXE phase, as this is where the SMM environment is
also set up. Most UEFI modules running in the DXE phase are known as DXE
modules. UEFI modules running after the PEI phase are usually in the PE
format.

UEFI defines a standardized format for EFI firmware storage devices abstracted
into Firmware Volumes (FVs). Typically, a BIOS contains multiple FVs, with one
FV containing DXE modules, including SMM modules, and another FV containing
PEI modules. UEFI modules in the DXE phase are individually dispatched by the
dispatcher, which implies that no modules run in parallel. The dispatcher
enumerates through the FVs to locate UEFI modules and execute them. FVs can
include apriori files listing module GUIDs. Modules in this list run first,
following the order of the file.

EDK2 is a full implementation of the UEFI specification developed by the open-
source Tianocore project [29]. It is also a UEFI module development
environment, which we used to build SmmPack.

###  2.2 SMM

The System Management Mode (SMM) is the highest-privileged operating mode of
x86 and x86-64 processors, intended for use by BIOS firmware to handle low-
level system management operations such as power management, system hardware
control, or proprietary OEM-designed code. SMM can only be entered through a
System Management Interrupt (SMI) and can only be exited with an RSM
instruction or reboot. UEFI modules that run in SMM are called SMM modules,
and these modules prepare SMI handlers that perform low-level system
management operations.

SMRAM. SMM modules are loaded into a separate memory region called SMRAM,
which can only be accessed during SMM and cannot be read via Direct Memory
Access (DMA). SMM is typically initialized during the DXE phase. In this
phase, SMM modules are also loaded and executed from their entry points. At
the end of the DXE phase, the SMRAM is locked by setting Model Specific
Registers (MSRs), which control the SMRAM. This locking makes these MSRs read-
only and restricts the visibility of SMRAM solely to SMM.

SMM System Table and Protocols. SMM has a data structure called the SMM system
table that allows access to the various functions used in most SMM modules.
One of the functionalities provided by the SMM system table is the protocol.
When a certain SMM module registers its provided function as a protocol in the
system, other SMM modules can utilize that function. Protocols primarily
consist of a GUID and a protocol interface structure. When the protocol is
used, functions such as SmmLocateProtocol of the SMM system table first find
the protocol interface structure based on the GUID. The specified function is
then called, referencing the function pointers in the protocol interface
structure. The protocol interface structure is usually defined in the data
section of the SMM module that installed that protocol. The actual functions
pointed to the protocol interface structure are also defined inside the SMM
module.

CommBuffer. There are several ways to communicate data between non-SMM and
SMM, the most common of which is to use the SMM communication buffer
(CommBuffer) via the SMM communication protocol or the Advanced Configuration
and Power Interface (ACPI) table. When using CommBuffer, SMI handlers should
call the SmmIsBufferOutsideSmmValid function to validate the data. This is
because if the data passed from the CommBuffer point to the data inside SMRAM,
the non-SMM code can manipulate the data inside SMRAM.

###  2.3 TPM

Trusted Platform Module (TPM) is a secure cryptoprocessor designed to
safeguard the artifacts used for platform authentication. TPM specification
has been developed by the Trusted Computing Group (TCG) [31]. Currently, TPM
2.0 is the latest version of the specification. In this study, we focused
primarily on TPM 2.0, with no discussion of TPM 1.2, its predecessor. TPM is
equipped with numerous anti-tampering mechanisms that enable it to effectively
resist a wide array of hardware and side-channel attacks.

PCR. One of the essential features of TPM is the Platform Configuration
Register (PCR), which provides a method for measuring the state of software.
The value stored in the PCR is a hash of the software code or configuration
data and can only be updated through an extend (or reset) operation. By
referencing the PCR value, the platform firmware ensures that no code executed
during the boot phase is altered. If an attacker attempts to run a tampered
UEFI module during the boot chain, the change in PCR values can detect
tampering. The extend operation hashes the concatenated value of the new
measurement and the current PCR value. A standard TPM comprises 24 PCRs, each
designated to store distinct types of measurements. In this study, we focused
solely on PCR0, where the system firmware measurements are stored. The DXE
phase measurement in the EDK2 framework was conducted at Firmware Volume (FV)
granularity using the Tcg2Pei module during the Pre-EFI Initialization (PEI)
phase [28].

Session. Many TPM commands require the use of sessions that can be divided
into the following three types: (1) Password, (2) HMAC, (3) Policy. Among
these three, policy session is the most powerful, allowing authentication
based not only on passwords but also taking into account PCR values and other
external information. In this study, we adopt a policy session.

Sealing. Storing secrets in TPM with the policy session using PCR is called
sealing. Sealing can confine the accessibility of stored data to specific
instances during the boot phase when platform integrity is assured.

NV space. A certain amount of nonvolatile (NV) space is available in the TPM
for user-configured storage. Authorization can be applied to the data stored
in NVRAM, allowing the data to be sealed inside. The data placed in NVRAM can
be accessed through a handle called the NV index.

###  2.4 Vulnerabilities and attacks in SMM

By escalating privileges to SMM, attackers can arbitrary write to SPI flash,
bypass hypervisor-based security mechanisms [32, 11], and provide stealthy
functions at OS runtime [4]. Moreover, all attacks that can be done by
infecting other UEFI modules are also possible from SMM modules.

Various types of vulnerabilities that can trigger the above attacks have been
identified in SMM modules, including SMM callout [8, 6], confused deputy [27],
and buffer overflow [10, 7]. Most CVEs are caused by implementation errors in
SMM modules. However, attacks against SMM are not widely known and obfuscation
to hide these vulnerabilities is not currently performed.

###  2.5 Existing security mechanisms

Existing security mechanisms for preventing attacks on UEFI include secure
boots and an Intel Boot Guard.

Secure boot or Verified boot. These security mechanisms are designed to ensure
the system integrity. The central idea is to ensure that the system firmware
has not been tampered with by verifying the hash of the firmware. Therefore,
it is impossible to prevent attacks that do not tamper with the code. Secure
boot mainly checks the integrity of the firmware after PEI and operates with
trust in the OEM platform firmware before DXE.

Intel Boot Guard. Intel Boot Guard [15] verifies the integrity of both the SEC
and PEI phases. The Intel Boot Guard is a hardware-based technology that
cannot be disabled by users. In AMD, similar functionality is implemented as a
Platform Secure Boot (PSB) [22], which also cannot be disabled by the user.

##  3 Threat Model

The purpose of SmmPack is to increase the cost of vulnerability analysis of
SMM modules by attackers. Therefore, the threat model of SmmPack is defined as
“attackers aiming to discover vulnerabilities in SMM modules.”

SmmPack is not intended to prevent attacks towards SMM. Its purpose is to
increase the cost of vulnerability analysis conducted prior to those attacks.
To the best of our knowledge, no research has been conducted on the encryption
or obfuscation of system firmware, including SMM modules. Consequently, there
are no existing threat models focused on the vulnerability analysis of SMM
modules. Therefore, there is a need to define a threat model targeting
attackers aiming to conduct vulnerability analysis on SMM modules.

Attackers who intend to analyze SMM modules to identify vulnerabilities can
obtain the modules from their own PC. Therefore, the threat model must
consider the Man-at-the-End (MATE) model [13]. In general, research
considering this model finds it challenging to completely prevent attackers
from conducting vulnerability analysis. Instead, the focus is on increasing
the costs for attackers.

It is necessary not only to address attacks on SMM but also to take measures
for the vulnerability analysis of SMM modules. This is because many attacks
that exploit vulnerabilities in the SMM modules cannot be prevented using
existing security mechanisms. Attacks such as buffer overflow through
CommBuffer [10, 7] and SMM callout attacks [8, 6] do not require tampering
with the SMM module. Thus, such security mechanisms like secure boot is
ineffective. It is highly challenging for developers to comprehend all SMM-
related attacks and implement all modules without any vulnerabilities.
Furthermore, even if vulnerabilities are identified, BIOS has the
characteristic of having a significantly longer period until a patched version
is released compared to regular software. Therefore, increasing the cost of
vulnerability analysis is an important countermeasure.

In this study, the threat model was classified into the following three
classes based on the attacker’s accessible scope. In this threat model,
attackers aim to obtain decrypted SMM modules and the key. Vulnerability
analysis is also prevented by preventing the acquisition methods. Class 3
attackers have greater access than class 1 attackers; however, they must
employ relatively expensive methods to obtain SMM modules.

Class 1 attacker: attacker with access to only BIOS update file.

Class 2 attacker: attacker with arbitrary software code execution above OS.

Class 3 attacker: attacker with hardware access and equipment.

Class 1 attacker. The lowest cost way to obtain SMM modules is to acquire them
from BIOS update files. These BIOS update files can be freely downloaded from
various manufacturer websites, making it cheaper than purchasing a device.

Class 2 attacker. A Class 2 attacker aims to obtain SMM modules by purchasing
a PC containing the BIOS image they want to analyze and obtaining SMM modules
from the software running on the OS. This attacker can attempt to dump SPI
flash from the software, attempting to access keys through software-based
access to the TPM using tools such as tpm2-tools [24], and trying to obtain
decrypted SMM modules loaded in memory through memory dumps.

Class 3 attacker. A Class 3 attacker can attempt to acquire SMM modules using
various methods, ranging from low-cost approaches, such as dumping the BIOS
image from the SPI flash chip, to more costly methods, such as acquiring the
decrypted SMM modules from memory via cold boot attacks, which require
considering various hardware-specific security mechanisms. Attackers can also
execute arbitrary SMM modules by flashing the SPI flash.

When evaluating using this threat model, the following assumptions are made:
(1) the TPM module is tamper-resistant, (2) attacks on cryptographic
algorithms themselves are considered out-of-scope, and (3) the integrity of
the SEC and PEI phases is hardware-protected by the Intel Boot Guard or AMD
PSB. Therefore, in this paper, we consider vulnerabilities in TPM itself,
weaknesses in cryptographic algorithms, and tampering of SEC and PEI phases to
be out of scope.

##  4 Implementation

In this section, we explain the implementation of SmmPack. First, we provide
an overview of SmmPack, followed by a description of the preparation of the
protocol used for the decryption, sealing, and unsealing of keys, and details
of the packer. In Section 7, we discuss the validity of the design.

###  4.1 SmmPack overview

Figure 1 illustrates an overview of SmmPack. SmmPack packs the SMM module by
encrypting its code section and adding the decrypt stub at its end. When the
packed SMM module is executed, the execution starts from the decrypt stub,
which calls the Unpack function of SmmPackProtocol that the SmmPackSmm module
installs. Subsequently, SmmPackSmm will decrypt the code section of the packed
SMM module using a key stored inside TPM.

Figure 2 shows the key operations related to SmmPack at a high level.
SmmPackSmm loads the decryption key from the TPM in the early DXE phase.
Because the key is sealed, the PCR value must be a specific value. The PCR
value was calculated in FV units in the PEI phase. After SmmPackSmm installs
the SmmPackProtocol, the packed SMM modules are executed, and once executed,
they remain decrypted in SMRAM throughout the runtime.

Table 1 lists the components used in SmmPack, and Table 2 presents the
environmental information. It is assumed that the packing of SMM modules will
be performed by the OEM before shipment by executing the packer program only
once. The keys are unique values for each BIOS implementation and are sealed
before shipment to the non-volatile area of the TPM.

Figure 1: SmmPack overview. Figure 2: High level core operations in SmmPack. Table 1: SmmPack components. name | description
---|---
SealKeyDxe | Seal key into the TPM
SmmPackSmm | Provides protocols for unpacking
smm-packer | Packer program
tiny-AES-c [19] | Library for AES
Table 2: Experiment setup. name | description
---|---
Visual Studio 2019 | for building packer program/C++
EDK2 | for building UEFI modules
UP Squared Pro Atom 04/64 [23] | for executing UEFI modules
CPU | Intel Atom® x7-E3950
BIOS | UNAPAM22
TPM | Infineon SLB9665

###  4.2 SmmPackSmm

SmmPackSmm mainly performs the following two processes: (1) Unsealing the key
from TPM and (2) Registering a protocol for decryption. SmmPackSmm is an SMM
module that installs an SMM-specific protocol called SmmPackProtocol for
unpacking packed SMM modules. When the packed SMM module is dispatched, it
starts execution from the decrypt stub added by our packer, and the decrypt
stub calls the Unpack function of SmmPackProtocol to decrypt itself. To pack
more SMM modules, the protocol must be installed before any packed SMM module
is executed. For this purpose, the GUID of SmmPackSmm should be written to the
apriori file of its FV. Despite multiple FVs, the protocol can be used across
FVs. Therefore, if SmmPackSmm is registered in the apriori file of the
initially executed FV, the modules in other FVs can also be packed.

Unsealing key from TPM.

Figure 3: Key unsealing commands.

To unseal the decryption key, SmmPackSmm sends commands to the TPM as shown in
Figure 3, using the Tpm2DeviceLib library in EDK2. Tcg2Protocol and similar
protocols cannot be used with SmmPack because they are not available until the
DXE module that installs them is executed. First, TPM2_StartAuthSession is
used to start a policy session, followed by TPM2_PolicyPCR to select the PCR
to use for authorization for this session. Finally, TPM2_NV_Read is used to
read the key from the nonvolatile storage of the TPM, with verification of the
current PCR value to ensure that it matches the enrolled PCR value specified
when the key was sealed. The key is then saved as a global variable in
SmmPackSmm. It is also possible to perform decryption inside the TPM without
loading the key into memory. However, this method requires SmmPackSmm to send
the encrypted data (the entire text section of the packed SMM modules) to the
TPM, which significantly increases the execution time. Loading the key into
memory does not increase the attack vectors in the context of this study, if
the key could be read from memory, so too can the unpacked SMM modules.

Registering a protocol for decryption. After the key is unsealed, SmmPackSmm
installs a protocol that decrypts the packed SMM modules. The protocol is a
table of function pointers, and in SmmPack, only one function, Unpack, is
required. The Unpack function takes the base address and the size of the
encrypted text section of SMM modules and decrypts it using the key stored in
the global variable. The encryption algorithm used in SmmPack is AES-128 in
CBC mode, which is implemented by using the open-source library tiny-AES-c.
However, this can be any similar-strength symmetric algorithm or implemented
using any other library. After the protocol is installed, the subsequent SMM
modules can locate it using its GUID and call the Unpack function.

###  4.3 Key sealing

Figure 4: Key sealing commands.

The key used by SmmPack must have a unique value for each BIOS implementation.
SmmPack aims to prevent the analysis of SMM modules; therefore, if the BIOS
code is the same, encryption using a different key is not required. Figure 4
presents an overview of sealing a key to a TPM. TPM2_NV_DefineSpace allocates
space to place a key inside the nonvolatile storage of the TPM. This command
is sent with a digest of the policy obtained from TPM2_PolicyGetDigest, which
contains the information on the PCR value that can access this space. This
information was specified by TPM2_PolicyPCR on a trial session initiated by
TPM2_StartAuthSession. SealKeyDxe, which performs this operation, should be
executed before packing any SMM module with SmmPack. Alternatively, this
process can be performed using other tools, such as tpm2-tools [24].

###  4.4 Packer design

Figure 5: Structure of packed SMM module.

The packer program was implemented separately from the other components as an
application running on top of the OS. This is also implemented using tiny-
AES-c because the algorithms used for encryption and decryption must be the
same. Figure 5 shows the structure of the packed SMM module. The packer first
encrypts the text section of the SMM module with AES. Then, the packer adds
the ext section (decrypt stub) containing the decryption code at the end of
the SMM module. The entry point of the module should also be moved to the
decrypt stub. SmmPack encrypts only the text section because the purpose of
SmmPack is to prevent vulnerabilities from being discovered by analyzing the
codes of the SMM module.

##  5 Security analysis

In this section, we assess the extent to which SmmPack increases the cost of
vulnerability analysis, utilizing the threat model defined in Section 3. We
presented the overall results in Table 3.

In summary, SmmPack can completely prevent all acquisition methods for Class 1
and Class 2 attackers and can restrict Class 3 attackers’ acquisition methods
to only cold boot attacks and DMA. However, neither of these acquisition
methods may be applicable because of the existence of specific security
mechanisms. Even if these security mechanisms were not present, performing
these acquisition methods against SmmPack would still be a highly cost-
intensive task. Detailed explanations are provided in Subsection 5.4. Hence,
using SmmPack, the avenues for attackers to acquire SMM modules are narrowed
down to methods with a significantly higher cost.

Table 3: Threat models and attacks SmmPack can address (O represents acquisition methods that can be prevented by SmmPack, while X represents methods that cannot be prevented by SmmPack.). class 1 | BIOS update file | O
---|---|---
class 2 | SPI flash dump (software) | O
| key read from TPM (software) | O
| memory dump from OS | O
class 3 | SPI flash dump (hardware) | O
| key read from TPM (hardware) | O
| SMRAM read from SMM module | O
| DMA | X
| coldboot attack (same device) | O
| coldboot attack (memory transplant) | X

###  5.1 Class 1 attacker

BIOS update file. Although changes to the BIOS update method are necessary,
distributing a BIOS image file containing SMM modules in an encrypted state
would prevent attackers from analyzing them because they would not possess the
decryption key. Further details regarding the BIOS update method upon adoption
of SmmPack are discussed in Section 7.

###  5.2 Class 2 attacker

SPI flash dump (software). In this case, the most reliable method for
obtaining SMM modules is to dump the BIOS from the SPI flash, which can be
performed using tools such as CHIPSEC [12] or RWEverything [1]. With SmmPack,
the obtained modules are encrypted; thus, attackers cannot analyze them.

key read from TPM (software). Even if the modules are encrypted, an attacker
capable of retrieving the key can still analyze their content. It is possible
to access the TPM from the software running on top of the OS using tools such
as tpm2-tools [24]. However, it is not possible to unseal the key from the TPM
on top of the OS because the PCR value has changed by then333To ensure
certainty, it is also possible to extend PCR0 in SmmPackSmm after unsealing
the key.. Therefore, even if a packed SMM module is obtained on top of the OS,
it cannot be analyzed.

memory dump from OS. Because the packed SMM modules are placed in memory in a
decrypted state after execution, attackers can obtain the decrypted modules
through a memory dump without the need to acquire both the encrypted SMM
module and the key. Although SMM modules exist in memory during runtime, they
are located in SMRAM, making it impossible for the software on the OS to read.
SMRAM is accessible only by SMM and SMM is entered only by SMI. Consequently,
SMRAM can only be dumped from SMM modules. Hence, Class 2 attackers cannot
obtain SMM modules using memory dumps.

###  5.3 Class 3 attacker

SPI flash dump (hardware). Using SmmPack, SMM modules within the SPI flash are
always stored in an encrypted state at any point in time. Therefore, this
method by itself does not allow an attacker to analyze the SMM module.

key read from TPM (hardware). To decrypt the encrypted module, the attacker
must obtain the key from the TPM. Note that the vulnerability of TPM’s tamper-
resistance feature is considered beyond the scope of this paper. Therefore, we
assume that the physical retrieval of the key is prevented.

SMRAM read from SMM module. While attackers can disable secure boot on their
PC and write an SMM module that performs an SMRAM dump, introducing any SMM
modules will alter the PCR value. As a result, neither the key nor the
decrypted SMM modules are loaded in the SMRAM by SmmPackSmm. PCR values are
usually measured in the PEI phase on a per-FV basis before transitioning to
the DXE phase [28]. Therefore, even when running SMM modules in the early DXE
phase, the PCR value changes.

DMA. An attacker can also read data from the memory via Direct Memory Access
(DMA) without requiring any additional modules to write. SMRAM is an area that
cannot be accessed via DMA, so generally, this is not feasible. However, the
exact point at which SMRAM becomes inaccessible is after the SMRAM is locked.
Consequently, performing DMA during the DXE phase after the execution of
SmmPackSmm is possible until SMRAM is locked. This allows for the retrieval of
decrypted SMM modules or keys.

Another possible method is a cold boot attack [3], which takes advantage of
the delay until the DRAM content is completely erased and the residual data
are read out. Cold boot attacks can be further categorized into two methods
based on their approach. The first method involves performing a cold reset
within the same device and then reading the residual data. The second method
involves freezing memory modules, transplanting them to another device, and
then reading the residual data on that device.

cold boot attack (same device). In this case, it is impossible to obtain the
decrypted SMM module for two reasons. To carry out this attack, an attacker
must follow steps similar to the following: (1) Power down the PC after all
SMM modules have been loaded, (2) Freeze the memory modules using cold spray,
(3) Write a DXE module that reads the residual data and stores it in the SPI
flash (configure it to run during the initial stages of the DXE phase, e.g.,
using apriori files), and (4) Boot up the PC again. An essential consideration
is that the module responsible for reading the residual data must run before
the BDS phase. This is because the residual SMRAM data are overwritten with
new data during the DXE phase. As a premise of SmmPack, as stated in Section
3, SEC and PEI phases are protected at the hardware level to prevent
tampering. Thus, attackers must read the residual data through a DXE module.
Furthermore, if the DXE module is added, the PCR value changes, halting the
boot process when SmmPackSmm is executed. Therefore, the DXE module must be
executed during the initial stages of the DXE phase before SmmPackSmm is
executed.

To insert a DXE module that reads the residual data, attackers must flash the
BIOS of the system. Typically, flashing a BIOS requires several minutes to
complete. However, modern DDR3 and DDR4 memory modules struggle to retain data
for more than a minute, even when adequately cooled [5, 34]. Therefore, it is
considered impractical to obtain residual SMRAM data through a cold boot
attack on the same system.

Furthermore, most systems employ the Memory Overwrite Request (MOR) mechanism
[30], which zero-clears the memory when a clean shutdown is not performed, as
in the case of a cold reset. For these two reasons, a cold boot attack on the
same system cannot retrieve the decrypted SMM modules.

cold boot attack (memory transplant). In this scenario, an attacker can freeze
the memory, transplant it to another PC containing the DXE module that reads
the residual SMRAM data, and then boot. MOR bit is not effective, because
performing a clean shutdown and setting the bit to zero on the target PC
beforehand would prevent memory zero-clearing during POST.

###  5.4 High cost of DMA and cold boot attacks

Although SmmPack may not prevent DMA and cold boot attacks involving memory
transplant, these methods may not be viable depending on the presence of
specific security mechanisms. Furthermore, even without those, attempting
these acquisition methods against SmmPack remains a highly challenging task.

DMA difficulties. There are two non-negligible reasons why the retrieval of
decrypted SMM modules or keys using DMA is an extremely challenging task.
First, the window of time between the initialization and the locking of SMRAM
is very brief. Consequently, it is difficult to time the DMA operation.
Attempts to insert a deadlock loop would alter the PCR values, preventing the
loading of keys and halting the execution in SmmPackSmm. This limits the
duration for which DMA can be performed, thereby increasing the cost for
attackers.

Second, modern CPUs include various security mechanisms for DMA protection,
including the DMA Protected Range (DPR) [17]. The memory region specified by
DPR is inaccessible to DMA, and typically, DPR covers the memory areas used by
SMRAM. If this security mechanism is active, attackers cannot use DMA to
retrieve decrypted SMM modules or keys. Even if an attacker attempts to modify
CPU registers to alter DPR settings, executing firmware to achieve this change
requires changing the BIOS firmware, which alters PCR values. Consequently, if
this security mechanism is enabled, DMA is unavailable.

Cold boot attack difficulties. Performing cold boot attacks requires
consideration of various security mechanisms present in memory modules and
system-on-chips (SoCs). DDR3 and later DRAM modules have a memory-scrambling
feature that allows only scrambled data in memory, which is descrambled only
within the SoC. Although descrambling of DDR3 and DDR4 DRAM modules are
possible [5, 34], this will significantly increase the attacker’s cost.

Moreover, certain SoCs employ technologies such as Intel’s Total Memory
Encryption (TME) [16], Total Memory Encryption Multi Key (TME-MK) [20], and
AMD’s Secure Memory Encryption (SME) [18]. With these features enabled, data
are always stored in an encrypted state in the memory and decrypted within the
SoC only. Cold boot attacks are thwarted when these features are active.
Although these mechanisms can often be disabled by the user from the BIOS
setup screen, if these features are designed such that they cannot be disabled
by design, attackers will be unable to perform cold boot attacks.

##  6 Performance evaluation

In this section, we evaluate the impact of SmmPack on system performance and
demonstrate that the introduction of SmmPack is realistic.

###  6.1 Evaluation method

Both the speed and size of the overhead depend on the number of SMM modules to
be packed. The number of SMM modules varies depending on the BIOS. In the case
of the BIOS used in this experiment, there were 39 SMM modules. Measurements
of clock cycles and size in bytes were calculated using this number of
modules; however, the overhead was represented as a percentage.

The boot-time delay caused by SmmPack is the sum of the execution times of
SmmPackSmm and the decryption stubs of multiple packed modules. The execution
time was measured by obtaining the number of clock cycles using rdtsc
instruction. Also, the execution time of decryption stubs is proportional to
the size of the text section to be decrypted. The SMM module included in the
BIOS used in our experiment had a text section size of approximately 3000 to
50000 bytes, so we measured the number of clock cycles required to decrypt
3000, 20000, and 50000 bytes. All clock cycle counts were calculated by
repeating the same work five times and taking the average value. The clock
cycles measured are shown in seconds when executed on a 2.0 GHz CPU.

The increase in size was calculated by the sum of the size of SmmPackSmm
itself and the sizes of the decryption stubs added to the packed SMM modules.
These sizes are fixed, but the total size of the decryption stubs scales
linearly with the number of SMM modules being packed.

###  6.2 Speed overhead

The required clock cycle counts and the corresponding execution times on a
2.0GHz CPU for using SmmPack are shown in Table 4. The number of clock cycles
required for SmmPackSmm execution was 460702429.0. This is about 0.23 s in a
2.0GHz CPU.

In terms of the decryption time, assuming 39 SMM modules, each with a text
section size of 20000 bytes, the overhead was approximately 0.13 s. When
combined with the execution time of SmmPackSmm, the total overhead in boot
time was approximately 0.36 s. This is approximately 2.77% of the entire boot
time in our experimental environment and can be considered a realistic value.

Table 4: Average clock cycles and time required in SmmPack. Measurement target |  Clock cycles | Time (s)
---|---|---
SmmPackSmm (whole) |  460702429.0 | 0.23035
SmmPackSmm (key retrieval) |  460638762.5 | 0.23032
Unpack 3000 bytes |  1019979.0 | 0.00051
Unpack 20000 bytes |  6766215.4 | 0.00338
Unpack 50000 bytes |  16914954.6 | 0.00846

###  6.3 Size overhead

The size of SmmPackSmm was 11648 bytes, and the size of the decryption stub
was 188 bytes. If 39 SMM modules are packed, the total size of the BIOS will
increase by 18980 bytes. This was approximately equal to the size of the
average UEFI module. This was only 0.1% of the total data stored in the UP
Squared Board Pro’s SPI flash chip. Therefore, the increase in size owing to
the introduction of SmmPack is negligible and can be considered a realistic
value.

##  7 Discussion

In this section, we discussed the value of SmmPack as well as the management
and adoption, and BIOS updates regarding SmmPack.

###  7.1 Value of SmmPack

There may be various opinions on whether the obfuscation provided by SmmPack
justifies its cost. Furthermore, considering the practical implementation of
SmmPack, there would likely be a need for discussions that extend beyond the
page count of this paper. However, the true value of this study lies in the
fact that it is the first to apply obfuscation to system firmware. We believe
that the value of this study lies in shedding light on the effects, costs, the
setup of threat models, and identifying critical points of focus when
evaluating obfuscation systems towards system firmware.

###  7.2 Management and adoption of SmmPack

To introduce SmmPack, OEM needs to perform certain tasks before and after
shipping the BIOS. The tasks performed before shipping the BIOS are as
follows: (1) determine the key for the BIOS, (2) pack each SMM module, (3)
obtain the PCR value when SmmPackSmm is executed, and (4) seal the key into
the TPM of the PC that uses the BIOS.

There are multiple methods to perform (4). One approach is to boot the OS with
the unpacked SMM module included in the BIOS and use tools such as tpm2-tools
on top of the OS to extract the key. After sealing, power off the system,
replace the BIOS with the BIOS containing packed SMM module, and verify if the
system boots properly. Alternatively, the code that seals the key to the TPM
can be executed as a UEFI module without booting the OS. One important
consideration is to restrict access to the key solely to the platform firmware
entity. Permitting access to the key by the owner entity can lead to the
erasure of the key, because of the TPM initialization process executed by the
operating system. The task that the OEM should perform after the BIOS is
shipped is the BIOS update, as described in the following subsection.

Regarding scalability, SmmPack can pack a single SMM module by running a
single-packer program. This task can be performed simultaneously with the SMM
module build process by incorporating it at the end of the build tool, such as
EDK2. Additionally, because SmmPack uses the same key and PCR values for PCs
of the same model, it does not require complex key management or provisioning
tasks. Moreover, it can be integrated into the existing BIOS update process as
explained in the following subsection. Therefore, it can be said that
scalability is not compromised.

###  7.3 BIOS update

Figure 6: UEFI capsule update with SmmPack (Figure adapted from [35] for this
paper.). Figure 7: Recovery from update failure.

To prevent the analysis of the modules obtained from BIOS update file, they
must be distributed in a packed state. Moreover, the key and the new PCR value
must be stored in the receiver’s TPM without being read by the receiver. The
key received from the BIOS update server must be sealed in SMM because placing
the key in a normal memory region during the update process can be easily
read. Therefore, it is desirable to receive the key in an encrypted state and
decrypt it inside the SmmPackSmm’s SMI handler. The difficulty in extracting
data from SMRAM is demonstrated in Section 5.

UEFI capsule update[33] can still be performed, even with the adoption of
SmmPack. Figure 6 illustrates the flow of the update process. The capsule
creator first constructs a capsule by including the packed SMM modules, a new
encrypted key, and a new PCR value. When the PC receiving the capsule reaches
the stage where the coalesce process is done and finishes writing the capsule
contents to the SPI flash, it passes the encrypted key and new PCR value to
the SMI handler mentioned above to seal the key.

If the key sealing process fails, recovery can still be performed. Figure 7
illustrates the flow of the recovery process. SmmPack targets SMM modules in
the DXE phase, leaving the PEI modules untouched. This allows the system to
boot, with or without SmmPack, up to the PEI phase. During the normal recovery
process (without SmmPack), when the BIOS update process fails, a specific PEI
module retrieves a recovery DXE FV from an external storage device and uses it
to boot and perform the remaining update operations [33]. With SmmPack, after
booting from the recovery image, the sealing process should be performed again
at this point. It should be noted that the DXE FV for recovery needs to
include an SMI handler that seals the key as described above. If the sealing
process still fails, it is possible to write the original BIOS back. In the
case of a failure occurring after the original key has been undefined but
before sealing the new key, it is recommended to save the original key value
in another NV space of the TPM before performing the undefine operation. Once
the new key has been confirmed to be successfully sealed, the original key can
be deleted. Therefore, the recovery process can also be performed with SmmPack
adopted.

###  7.4 Shared code problem

In reality, a non-negligible amount of shared code is found among different
vendors [14, 9]. Therefore, even if a company adopts SmmPack, an attacker can
analyze the vulnerabilities of the BIOS code of other companies that have not
adopted SmmPack and apply the exploit to the former company, if the code they
use is shared and this fact is known. However, the SMM modules that are most
security-conscious are those that will be introduced in the future. When these
new SMM modules are introduced in the future, SmmPack obfuscation can be
applied to make it significantly more difficult for attackers to analyze their
vulnerabilities. In addition, even if a packed SMM module contains shared
code, it is not possible to determine whether the shared code is actually
present in that module until its contents are analyzed.

##  8 Conclusion

We developed the first obfuscation mechanism in platform firmware, SmmPack.
SmmPack is a packing method that uses a key sealed inside the TPM as a
security mechanism to increase the cost for attackers who aim to acquire and
analyze vulnerabilities in SMM modules. Experimental results using a prototype
implementation showed that SmmPack had no adverse effects on the original
module, and the increase in boot time and BIOS size was realistic.
Furthermore, we clarified the management and adoption methods for SmmPack as
well as the procedure for applying BIOS updates.

#### Acknowledgements.

We would like to express our sincere gratitude to Xeno Kovah for his
invaluable expertise and guidance on UEFI security.

## References

  * [1] RWEverything Read & Write Everything. http://rweverything.com/ (2017)
  * [2] Unified Extensible Firmware Interface Forum. https://uefi.org/ (2021)
  * [3] et al., J.A.H.: Lest we remember: Cold boot attacks on encryption keys. In: Proc. of 17th USENIX Security Symp. pp. 91–98 (2008)
  * [4] ANT: DEITYBOUNCE ANT Product Data. https://www.eff.org/files/2014/01/06/20131230-appelbaum-nsa˙ant˙catalog.pdf (2013)
  * [5] Bauer, J., Gruhn, M., Freiling, F.C.: Lest we forget: Cold-boot attacks on scrambled ddr3 memory. In: Proc. of the Third Annual DFRWS Europe. pp. s65–s74 (2016)
  * [6] Binarly: [BRLY-2021-004] SMM callout vulnerability in SMM driver on multiple HP devices (SMM arbitrary code execution). https://www.binarly.io/advisories/BRLY-2021-004/index.html (2021)
  * [7] Binarly: [BRLY-2021-032] The heap buffer overflow vulnerability in child SW SMI handler on multiple HP devices. https://www.binarly.io/advisories/BRLY-2021-032/index.html (2021)
  * [8] Binarly: [BRLY-2021-040] SMM Callout Vulnerability In SMM Driver On Multiple HP Devices. https://www.binarly.io/advisories/BRLY-2021-040/index.html (2021)
  * [9] Binarly: Firmware supply chain is hard(coded). https://www.binarly.io/posts/Firmware˙Supply˙Chain˙is˙Hard(coded)/index.html (2021)
  * [10] Binarly: [BRLY-2022-016] Stack Overflow Vulnerability In SMI Handler. https://www.binarly.io/advisories/BRLY-2022-016/index.html (2022)
  * [11] Bulygin, Y., Gorobets, M., Furtak, A., Bazhaniuk, A.: Fractured Backbone: Breaking Modern OS Defenses with Firmware Attacks. https://www.blackhat.com/docs/us-17/wednesday/us-17-Bulygin-Fractured-Backbone-Breaking-Modern-OS-Defenses-With-Firmware-Attacks.pdf (2017)
  * [12] chipsec: chipsec. https://github.com/chipsec/chipsec (2023)
  * [13] Collberg, C., Davidson, J., Giacobazzi, R., Gu, Y.X., Herzberg, A., Wang, F.Y.: Toward digital asset protection. In: Proc. of the 2011 IEEE Intelligent Systems. pp. 8–13 (2021)
  * [14] Hudson, T., Kovah, X., Kallenberg, C.: Thunderstrike 2: Sith strike a macbook firmware worm. https://legbacore.com/Research˙files/ts2-blackhat.pdf#page=22 (2015)
  * [15] Intel Corporation: Intel® hardware shield – below-the-os security. https://www.intel.com/content/dam/www/central-libraries/us/en/documents/below-the-os-security-white-paper.pdf (May 2021)
  * [16] Intel Corporation: Intel® hardware shield – intel® total memory encryption. https://www.intel.com/content/dam/www/central-libraries/us/en/documents/white-paper-intel-tme.pdf (2021)
  * [17] Intel Corporation: Intel® trusted execution technology (intel® txt). https://cdrdv2-public.intel.com/315168/315168˙TXT˙MLE˙DG˙rev˙017˙4.pdf (2023)
  * [18] Kaplan, D., Powell, J., Woller, T.: Amd memory encryption. https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf (2021)
  * [19] kokke: tiny-aes-c. https://github.com/kokke/tiny-AES-c (December 2021)
  * [20] Lin, J.: Multi-key total memory encryption on windows 11 22h2. https://techcommunity.microsoft.com/t5/windows-os-platform-blog/multi-key-total-memory-encryption-on-windows-11-22h2/ba-p/3683043 (2022)
  * [21] MachineHunter: Smmpack. https://github.com/MachineHunter/SmmPack (2023)
  * [22] Malhotra, A.: Amd ryzen™ pro 5000 series mobile processors making defenses count: Designing for substantial depth. https://www.amd.com/system/files/documents/amd-security-white-paper.pdf (2021)
  * [23] shop, U.: Up squared pro atom quad core 04/64. https://up-shop.org/up-squared-pro-atom-quad-core-0464.html (2023)
  * [24] tpm2 software: tpm2-tools. https://github.com/tpm2-software/tpm2-tools (2023)
  * [25] The MITRE Corporation: CVE Search Results. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=smm (2023)
  * [26] TheSecMaster: Be Aware About these Six Unpatched SMM Vulnerabilities in HP Enterprise Devices. https://thesecmaster.com/be-aware-about-these-six-unpatched-smm-vulnerabilities-in-hp-enterprise-devices/ (September 2022)
  * [27] TianoCore Community: 38. SW SMI Confused Deputy SmramSaveState.c. https://edk2-docs.gitbook.io/security-advisory/sw-smi-confused-deputy-smramsavestate˙c (2021)
  * [28] TianoCore Community: Tcg trusted boot chain in edk ii. https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/3˙TCG˙Trusted˙Boot˙Chain˙in˙EDKII.html (March 2021)
  * [29] TianoCore Community: edk2. https://github.com/tianocore/edk2 (2023)
  * [30] Trusted Computing Group: Tcg platform reset attack mitigation specification. https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf (2008)
  * [31] Trusted Computing Group: https://trustedcomputinggroup.org/ (2023)
  * [32] Wojtczuk, R.: ANALYSIS OF THE ATTACK SURFACE OF WINDOWS 10 VIRTUALIZATION-BASED SECURITY. https://www.blackhat.com/docs/us-16/materials/us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security.pdf (2016)
  * [33] Yao, J., Zimmer, V.J.: A tour beyond bios capsule update and recovery in edk ii. https://github.com/tianocore-docs/Docs/raw/master/White˙Papers/A˙Tour˙Beyond˙BIOS˙Capsule˙Update˙and˙Recovery˙in˙EDK˙II.pdf (2016)
  * [34] Yitbarek, S.F., Aga, M.T., Das, R., Austin, T.: Cold boot attacks are still hot: Security analysis of memory scramblers in modern processors. In: Proc. of the 2017 IEEE HPCA Symp. pp. s65–s74 (2016)
  * [35] Zimmer, V., Kinney, M., Hughes, R.: Capsule update & lvfs: Improving system firmware updates. https://archive.fosdem.org/2020/schedule/event/firmware˙culisfu/attachments/slides/3709/export/events/attachments/firmware˙culisfu/slides/3709/FOSDEM˙2020˙Intel˙Capsule˙Update.pdf (2020)