# Frequency Throttling Side-Channel Attack

Chen Liu  Intel CorporationHillsboroORUSA<EMAIL_ADDRESS>,  Abhishek
Chakraborty  Intel CorporationHillsboroORUSA<EMAIL_ADDRESS>,
Nikhil Chawla  Intel CorporationHillsboroORUSA<EMAIL_ADDRESS>and
Neer Roggel  Intel CorporationRio RanchoNMUSA<EMAIL_ADDRESS>
(2022)

###### Abstract.

Modern processors dynamically control their operating frequency to optimize
resource utilization, maximize energy savings, and conform to system-defined
constraints. If, during the execution of a software workload, the running
average of any electrical or thermal parameter exceeds its corresponding
predefined threshold value, the power management architecture will reactively
adjust CPU frequency to ensure safe operating conditions. In this paper, we
demonstrate how such power management-based frequency throttling activity
forms a source of timing side-channel information leakage, which can be
exploited by an attacker to infer secret data even from a constant-cycle
victim workload. The proposed frequency throttling side-channel attack can be
launched by both kernel-space and user-space attackers, thus compromising
security guarantees provided by isolation boundaries. We validate our attack
methodology across different systems and threat models by performing
experiments on a constant-cycle implementation of AES algorithm based on AES-
NI instructions. The results of our experimental evaluations demonstrate that
the attacker can successfully recover all bytes of an AES key by measuring
encryption execution times. Finally, we discuss different options to mitigate
the threat posed by frequency throttling side-channel attacks, as well as
their advantages and disadvantages.

Power Management, Frequency Throttling, Side-Channel Analysis

††journalyear: 2022††copyright: acmcopyright††conference: Proceedings of the
2022 ACM SIGSAC Conference on Computer and Communications Security; November
7–11, 2022; Los Angeles, CA, USA††booktitle: Proceedings of the 2022 ACM
SIGSAC Conference on Computer and Communications Security (CCS ’22), November
7–11, 2022, Los Angeles, CA, USA††price: 15.00††isbn:
978-1-4503-9450-5/22/11††doi: 10.1145/3548606.3560682††ccs: Security and
privacy Side-channel analysis and countermeasures

##  1\. Introduction

Power management architectures of modern processor designs play a central role
in optimizing for and balancing between high performance and low power
consumption requirements, a product of decades of academic and industry
innovation (Rotem et al., 2012; Gough et al., 2015; Intel, 2022e; Bircher and
John, 2008; Haj-Yahya et al., 2018; Muralidhar et al., 2022). For example, a
widely-used power management architectural mechanism known as Dynamic Voltage
and Frequency Scaling (DVFS) is available on Intel®, AMD and ARM CPUs (Kogler
et al., 2022; Kim et al., 2008). DVFS dynamically adjusts CPU frequency and
voltage in order to reduce system power consumption, yielding higher
performance per Watt, or to quickly alter CPU frequency during workload
execution, in order to ensure that different electrical and thermal parameters
of the system remain below predefined safe limits (Intel, 2022e; AMD, 2022b;
ARM, 2022). Similar such throttling has been recently identified as enabling
covert channels (Haj-Yahya et al., 2021), given its reliance on shared
infrastructure across security domains. In this work, we investigate if such
workload-dependent CPU frequency adjustments yield exploitable side-channels.

Modern systems also provide multiple software-accessible telemetries which
allow users to characterize bottlenecks at scale (Ayers et al., 2019), monitor
resource utilization, power and performance (Noureddine et al., 2015; Colmant
et al., 2017; Fieni et al., 2020), and gain insights into system reliability
(Hochschild et al., 2021). Recently, researchers have demonstrated how a
processor’s energy telemetry reporting framework can be used maliciously to
perform power side-channel analysis attacks (Lipp et al., 2021; Liu et al.,
2021). These attacks allow a user-space attacker (having Ring 3 privilege) to
infer secret information from a targeted victim workload running inside a
Trusted Execution Environment (TEE). In order to thwart such side-channel
attacks, CPU vendors (both Intel and AMD) have provided security patches
(Intel, 2022b; AMD, 2022a) which remove Ring 3 software access to the energy
telemetry data via the Linux kernel module. In addition, Intel has also
provided a filtering-based mitigation patch (Intel, 2022c) to safeguard the
reported energy telemetry readings even from a kernel-space attacker (having
Ring 0 privilege).

In this paper, we study the potential threat posed by a new type of side-
channel information leakage source termed the frequency throttling side-
channel. Such a side-channel arises due to the dynamic adjustment of CPU
frequency when workload execution causes one or more electrical or thermal
system parameters to exceed predefined limits. Typically, in such a scenario,
the power management architecture throttles CPU frequency to a lower value to
ensure safe operating conditions of the system. Then, depending on the running
average of the parameter(s) in question, CPU frequency is again boosted to a
higher value until any limit threshold is violated. Therefore, increases and
decreases in CPU frequency (hereinafter, referred to as average throttling
frequency) during workload execution are dependent on the instantaneous
electrical and thermal parameters being capped by system-defined limits. The
average throttled frequency in turn affects the overall execution time of the
workload, even if its implementation follows constant-cycle coding principles
(Intel, 2022a), or it is being executed inside a TEE. The objective of a side-
channel attacker is to deduce the targeted secret from a victim workload by
monitoring fluctuations in its execution time for processing different inputs.
Unlike software-accessible telemetries, frequency throttling side-channel
leakage cannot be thwarted by enforcing access restriction or filtering-based
mitigation patches. This is because any presumed malicious Ring 3 software can
precisely monitor the execution time of a targeted process by reading
timestamp counter values (e.g., using the _RDTSC_ instruction).

In this work, we demonstrate the applicability of the throttling side-channel
attack to retrieve secret information from cryptographic primitives by
considering an AES-NI-based AES implementation as a case study, as considered
previously in the _Platypus_ attack (Lipp et al., 2021). While the _Platypus_
attack relies on power consumption information directly exposed to privileged
software through a telemetry interface, a frequency throttling side-channel
converts the power differences to power limit-induced execution time
differences, which are easily accessible by malicious software. It is to be
further noted that the _Platypus_ attack and the proposed frequency throttling
side-channel attack are two different attacks that exploit the same
information leakage source, namely data-correlated power consumption resulting
from inherent CMOS circuit properties. Also, both attacks require neither
physical access to the target platform nor any additional high-precision power
measurement setup as required in traditional side-channel attacks. The results
of our experimental evaluations reveal the effectiveness of such an attack in
successfully recovering the secret AES key, by performing statistical analysis
on the collected timing side-channel traces. In addition, we also discuss
potential mitigation options to thwart throttling side-channel attacks, and
their pros and cons. The main contributions of this paper can be summarized as
follows:

  * •

Presentation and comprehensive explanation of a new type of side-channel
attack which exploits the workload-dependent CPU frequency adjustments
performed by the power management architecture of modern processors

  * •

Detailed experimental evaluation of the frequency throttling side-channel
attack, showing extraction of cryptographic secrets (e.g., AES key) with
different reactive limits, attack models, and systems

  * •

Enumerating necessary conditions of a frequency throttling side-channel attack
and providing discussion of mitigation options thwarting each of the necessary
conditions

The rest of the paper is organized as follows: Section 2 presents background
information of power management algorithms and related side-channel attacks.
Section 3 presents detailed reasoning behind the frequency throttling side-
channel leakage and provides an overview of threat model and attack
methodology Section 4 showcases an attack using the throttling side-channel
against an AES-NI-based cryptographic implementation in various scenarios
Section 5 discusses different options to mitigate a frequency throttling side-
channel. Section 6 discusses related work. Section 7 concludes the paper.

##  2\. Background

###  2.1. Side-Channel Analysis and Mitigations

####  2.1.1. Power Side-Channel

Power side-channel analysis attacks exploit the fact that the dynamic power
consumption $P_{dyn}$ of a digital CMOS-based circuit is data-dependent in
nature (Kocher et al., 2011), as evident in the following equation:

(1) $P_{dyn}=\alpha\cdot C\cdot V_{DD}^{2}\cdot f$

where, $\alpha$, $C$, $V_{DD}$, and $f$ represent switching activity factor,
load capacitance, supply voltage, and clock frequency, respectively. The main
objective of a power side-channel analysis attack is to retrieve a targeted
secret by analyzing the data-dependent power consumption of a cryptographic
implementation during a selected time window. Traditional physical side-
channel analysis techniques such as Correlation Power Analysis (CPA) perform
statistical analysis on a large number of side-channel traces which are
collected by varying the input data (Mangard et al., 2008). In a typical CPA
attack, the attacker correlates the actual power consumption values $P_{a}$
from the collected power traces with the corresponding hypothetical power
leakage values $P_{h}$ (as calculated using standard Hamming weight or Hamming
distance power models). This is done for different key guesses using the
following measure:

(2) $\rho^{k}=\frac{cov(P_{a},P_{h}^{k})}{\sigma_{P_{a}}\sigma_{P_{h}^{k}}}$

where, $\rho^{k}$, $\sigma_{P_{a}}$, and $\sigma_{P_{h}^{k}}$, represent the
Pearson’s correlation coefficient for key guess $k$, the standard deviation of
the actual power values $P_{a}$, and the standard deviation of the
hypothetical power values $P_{h}^{k}$ for key guess $k$, respectively.

####  2.1.2. Telemetry Side-Channel

Software-accessible telemetry side-channel attack is an emerging topic
discussed in recent works (Lipp et al., 2021; Liu et al., 2021). Unlike the
traditional physical power side-channel attacks, telemetry side-channel
attacks can be conducted remotely by malicious software, exploiting telemetry
reading provided by the underlying hardware. For example, _Platypus_ (Lipp et
al., 2021) utilizes RAPL energy counter as the side-channel to deduce secret
information such as AES keys from Intel® Software Guard Extensions Enclave
(Intel® SGX Enclave). The variation in power consumption values due to
processing of different data as measured by existing CPU telemetry interfaces
(low sampling rates) is much less pronounced when compared to the variations
as captured by traditional physical side-channel setups (high sampling rates).
In addition, measurement inaccuracy and noise in the telemetry readings
further reduce the signal-to-noise ratio (SNR) of the collected side-channel
traces. However, in spite of these challenges, it has been demonstrated in
(Lipp et al., 2021) that the CPA attack is powerful enough to distinguish
minute secret-dependent biases in the telemetry readings and thus, can
successfully recover the underlying secret data. In this work, we also use a
variation of CPA attack (details in section 4.2.3) to perform statistical
analysis on collected telemetry traces.

A number of possible countermeasures to thwart power telemetry attacks were
listed in (Lipp et al., 2021). These mitigation strategies include restricting
user-space access (Ring-3 privilege) to _powercap_ driver in Linux and
limiting the measurement resolution of telemetry interfaces. In response to
the _Platypus_ attack, the Linux _powercap_ driver has been updated to
restrict unprivileged access to RAPL interface (Intel, 2022b; AMD, 2022a). In
addition, Intel issued a mitigation adding white noise to reported RAPL
interface readings, which is enforced when Intel SGX is enabled and can be
enabled by software via a software switch (Intel, 2022c). These approaches
effectively thwart the CPA attack leveraging software-accessible power
telemetry data.

####  2.1.3. Traditional Timing Side-Channel

In traditional timing side-channel analysis, an attacker exploits differences
in execution cycles of victim code to deduce the targeted secret. Such timing
differences can arise due to data-dependent execution cycles of the victim
process or mutual access of shared system resources (e.g., cache lines, branch
predictors, etc.) by the victim and attacker processes.

Several countermeasures have been proposed in related literature, which use
constant-cycle coding principles to address the issue of traditional timing
side-channel leakage (Intel, 2022a). A short summary of such coding principles
is as follows:

  * •

Ensure code processes secret data consistently (i.e., requires same number of
clock cycles irrespective of secret data values).

  * •

Ensure secret data values (or values derived from secret data) do not affect
the sequence of instructions executed due to a conditional branch or an
indirect branch target in the code.

  * •

Ensure memory access patterns (or the data size of load/store operations) are
invariant with respect to secret data.

Existing work largely assumes that traditional timing side-channel leakage can
be mitigated by applying these principles to the secret data-dependent
portions of the code.

###  2.2. CPU Power Management

We introduce how modern CPU power management algorithms control processors’
_power performance states_.

####  2.2.1. Processor Performance States

Intel processors implement performance states (referred to as $P$-$States$,
defined per ACPI (Corporation and B, 2000)), by realizing a DVFS mechanism for
optimizing power consumption. Such $P$-$States$ correspond to different
$voltage$-$frequency$ pairs, which can be proactively controlled either by the
operating system (using SpeedStep (Intel, 2022g)) or by the hardware (using
Speed Shift (Intel, 2022h)). As per convention, the highest CPU $P$-$State$ is
referred to as P$0$, and it corresponds to the highest achievable operating
frequency, as determined during manufacturing, enabling the processor to enter
the so-called turbo mode. AMD processors also implement various schemes to
optimize energy efficiency, including ACPI $P$-$States$ (Schöne et al., 2021).
The platform provides $P$-$States$ limits, status and voltage, frequency
definitions through MSRs (AMD, 2018b).

During execution of a workload, if any system-specific limit (electrical or
thermal) is violated, the processor $P$-$State$ is reactively controlled by
the power management algorithm. The remainder of the paper focuses on reactive
limits, which induce the frequency throttling side-channel. Depending on the
criticality of the limit being hit, reactive control of $P$-$States$ may be
performed with various response times (in the order of a few ms to tens of
seconds) to promptly bring the system back to safe operating conditions.

####  2.2.2. $P$-$State$ Control under Reactive Limits

The power management algorithm of a CPU periodically calculates different
running averages of electrical parameters (e.g., power, current, etc.) of
windows of pre-specified lengths. _Power budget_ is then computed as the
difference between the running averages and the respective reactive limit
values. Based on the power budget, the power management algorithm
$PL\\_ALG(\cdot)$ computes the new $P$-$State$ limit $f_{max}$, which is the
highest possible CPU operating frequency that satisfies all the reactive
limits of the system. An overview of the new $f_{max}$ selection process by
the controller is presented in Algorithm 1.

When none of the reactive limits are hit, all power budgets remain positive
and CPU operating frequency is not capped by $f_{max}$ (or, in other words,
$f_{max}$ is higher than the highest turbo frequency). If any of these
calculated running averages exceed a specific reactive limit (e.g., power
limit $PL$), the power management algorithm will trigger CPU throttling
activity and reduce $f_{max}$. In such cases, in order to maximize performance
while satisfying the reactive limits, the processor may run at the frequency
limit $f_{max}$, as governed by its feedback control mechanisms (Åström and
Murray, 2010).

Algorithm 1 Determination of new $P$-$State$ limit $f_{max}$

1:

2:(i) System reactive limit $PL_{i}$ with running average time window
$\tau_{i},i\in[1,N]$

3:(ii) Polling interval $T$

4:(iii) Current $P$-$State$ limit $f_{max}$

5:(iv) Power management control algorithm $PL\\_ALG(\cdot)$

6:New $P$-$State$ limit $f_{max}$

7:for every $T$ time units do

8: for $i$ from $1$ to $N$ do

9: $\overline{P_{i}}\leftarrow$ Calculate avg. power over $\tau_{i}$

10: $\Delta\leftarrow\overline{P_{i}}-{PL_{i}}$ /*Available power budget*/

11: $f_{max,i}\leftarrow PL\\_ALG(\Delta)$

12: if $f_{max}>f_{max,i}$ then

13: $f_{max}=f_{max,i}$ /*Throttling activity*/

14: end if

15: end for

16:end for

Figure 1. Conversion of power side-channel to timing side-channel leakage by
reactive limit-induced throttling.

####  2.2.3. Reactive Limits on Intel processors

We describe two of the _reactive limits_ present in several modern Intel
processors (Intel, 2022e).

  * •

Running Average Power Limit (RAPL): RAPL is a feature supported by Intel power
management architecture to cap the power consumption on the system. When the
configured power limit is exceeded, the CPU will be forced to run at a lower
frequency to maximize performance while meeting the power limit requirement.
Intel currently provides multiple power limit capabilities. The most commonly
used ones are the package-level power limit 1 (PL1) and package-level power
limit 2 (PL2). PL1 is used to track the long-term power consumption, so
typically its limit value is set to be lower and the time window $\tau$ is
longer (tens of seconds). On the other hand, PL2 is used to track the short-
time power burst events, so typically the limit is set to be higher than PL1
and $\tau$ is much shorter (several milliseconds). Ring 0 software can
configure the running average window $\tau$ and the power limit of each
capability through interfaces such as MSRs (e.g., _MSR_PKG_POWER_LIMIT_ for
package-level power limits).

  * •

Voltage Regulator Thermal Design Current Limit (VR-TDC): VR-TDC is a power
management feature supported by Intel power management architecture. It is a
current limit specified in Amperes, maintained in order to satisfy VR
electrical constraints. Generally, the algorithm monitors the running average
current in Amperes by reading the VR current sensor during the configured time
window. If the limit is hit, the processor will engage its frequency
throttling to reduce its frequency, in order to ensure current remains within
the limit and budget.

####  2.2.4. Reactive Limits on AMD processors

Precision Boost Overdrive (PBO) is a feature available on AMD Ryzen to
overclock processors to achieve more performance by controlling power/thermal
limits (Wikichip, 2021). Some of the reactive limits are described as follows:

  * •

Package Power Tracking (PPT): analogous to PL1 on Intel processors, this limit
caps the total power capacity of the processor socket in Watts (AMD, 2022d).

  * •

Package Power Tracking Fast (PPT Fast): analogous to PL2 on Intel processors,
this limit is a PPT limit with faster response time (shorter $\tau$).

  * •

Thermal Design Current (TDC): analogous to VR-TDC on Intel processors, this
limit caps the total current capacity in Amperes at the thermal throttling
limit of the processor (AMD, 2022d).

The aforementioned reactive limits can be configured from system software via
System Management Unit (SMU) mailbox interface with support from a kernel
driver (leogx9r, 2022; AMD, 2014). The SMU is a subcomponent of the AMD
processor that is responsible for a variety of system and power management
tasks during boot and runtime (AMD, 2018a). The command to configure the
reactive limits is described in (leogx9r, 2022). It specifies the SMU mailbox
ID and power/thermal limit value to set the reactive limit (leogx9r, 2022).
The SMU mailbox IDs for the reactive limits on different AMD platform are
described in (irusanov, 2021).

##  3\. Frequency Throttling Side-Channel

In this work, we demonstrate how an attacker can leverage reactive limit
triggered frequency throttling to create a novel source of timing side-channel
leakage during workload execution. We show that mere application of constant-
cycle coding principles is insufficient to thwart timing side-channel attacks,
as system clock frequency may vary during the code execution phase and may be
data-dependent to leak information.

###  3.1. Attack Primitives

In modern processors, a major source of throttling side-channel information
leakage is related to the workload-dependent reactive control of $P$-$States$
(line $11$ of Algorithm 1). Let us consider the example presented in Fig. 1 to
understand the underlying implementation details leading to such throttling
side-channel leakage. Suppose that the workload under execution is a constant-
cycle implementation of a function, foo (arg data), with input argument data.
As noted in section 2.1.3, such a constant-cycle implementation has no
traditional timing side-channel leakage. On the other hand, the power
consumption of the workload due to processing different data inputs
($data_{1}$ and $data_{2}$) might vary due to the differences in internal
data-dependent computations of the foo function. Without loss of generality,
let us assume that the processing of $data_{1}$ consumes higher power
($P_{1}$) compared to that of $data_{2}$ ($P_{2}$) (i.e., $P_{1}>P_{2}$). As
illustrated in Fig. 1(a), if both $P_{1}$ and $P_{2}$ are below all system-
defined reactive limits, there is no throttling activity and system frequency
$f_{default}$ remains the same irrespective of data consumed by foo.
Therefore, in this case, there is no data-dependent timing side-channel
information leakage, as the execution time of the workload is independent of
the inputs.

However, when power consumption reaches or crosses the system’s electrical
reactive limits (e.g., the limit is configured to a lower value, or a power-
hungry stressor code is executed in parallel with function foo) as illustrated
using Fig. 1(b), reactive limit induced throttling activity will be triggered,
resulting in a change to $P$-$States$, as shown in Fig. 1(c). Since
$P_{1}>P_{2}$, the average throttling frequency $f_{1}$ for data input
$data_{1}$ will be lower than the average throttling frequency $f_{2}$ for
data input $data_{2}$ to satisfy the same reactive limit. Both of these
throttling frequencies will be lower than the default system frequency prior
to throttling (i.e., $f_{1}<f_{2}<f_{default}$). _Crucially_ , as shown in
Fig. 1(c), the execution time of foo with frequency $f_{1}$ is higher compared
to its execution time with frequency $f_{2}$. Therefore, even though foo is a
constant-cycle workload implementation, its execution time becomes data-
dependent due to such frequency throttling activity. This forms a new type of
side-channel information leakage source in modern processors, which we refer
to as the frequency throttling side-channel.

Figure 2. Average power consumption and time elapsed of the same IMUL workload
with different operands (a) when throttling is not triggered, and (b) when
there is reactive limit induced throttling. Figure 3. Exploitation of
frequency throttling side-channel information leakage from a victim code.

To visually appreciate the primitive, we design and run a proof-of-concept
(PoC) code on an Intel E3-1230V5 system, plotted in Figure 2. The function foo
we use is composed of 2.8 billion IMUL instructions, which is a cycle-constant
instruction. Each IMUL instruction has one operand fixed and the other operand
set to either $data_{1}=0x0$ or $data_{2}=0xAA..AA$. In the first run, we
configure reactive limits to high values that will not be reached, to prevent
throttling from happening, and then execute foo with $data_{1}$ and
$data_{2}$, measuring aggregated package energy consumption and time elapsed
for foo. After repeating 100 times, we plot histograms of the average power
consumption (calculated from energy dividing by time) and the time elapsed in
Figure 2 (a), respectively. As can be observed, the $0xAA$ case consumes more
power than the $0x00$ case and the time it takes to execute foo for the two
operands is identical. The second run duplicates the first run, except for
reducing Power Limit 1 (PL1) to 8W and corresponding $PL1$ $\tau$ to 1s. With
this setting, PL1 is hit, and frequency throttling is triggered. As can be
seen from Figure 2 (b), power consumption distributions with different data
become indistinguishable and both are capped at 8W, which is the power limit.
Critically, foo now takes a longer time to execute with $0xAA$ compared to
$0x00$, while both are slower than the case without throttling. The results
confirm that reactive limit induced throttling converts a power side-channel
to a timing side-channel. Of note, Intel’s Platypus mitigation can hide the
information leakage exhibited in the power domain, but is not designed to
mitigate the frequency throttling side-channel. Therefore, the frequency
throttling side-channel is observable even if such mitigation is enabled.

###  3.2. Overview of Frequency Throttling Side-Channel Attack

####  3.2.1. Threat Model

We assume the following attack scenarios for an adversary exploiting a
frequency throttling side-channel against a victim workload across security
boundaries.

  * •

Attack Scenario 1: The attacker is a privileged software attacker, such as
kernel-space software or a hypervisor. The victim workload is executed inside
a Trusted Execution Environment (TEE), such as Intel SGX (Intel, 2022d; Costan
and Devadas, 2016) or AMD SEV (Kaplan et al., 2016; Morbitzer et al., 2021).
Such TEEs help protect secret information of the victim application from
direct access by even privileged software. In order to enable higher
throttling activity during the execution of code residing in a TEE, a
privileged attacker may alter reactive limit configurations. Discussion of
this scenario is provided in section 4.4.

  * •

Attack Scenario 2: The attacker is a user-space attacker with Ring 3
privilege, and the victim is another application or the kernel. Unlike the
previous scenario, the attacker does not have the privilege to alter the
values or $\tau$ of the reactive limits. A Ring 3 attacker instead may execute
a stressor code in parallel to the victim code to boost the system power
consumption beyond the default limits, such that throttling activity is
triggered. Note that the long $\tau$ and additional noise introduced by the
stressor code will make the attack harder. Discussion of this scenario is
provided in section 4.5.

In addition, we assume that the victim code under consideration is implemented
following the constant-cycle coding principles highlighted in section 2.1.3.
In order to attack such a workload, an attacker utilizes the reactive limit-
induced throttling (see section 3.1) to make the execution time of the code
vary for different known data inputs. The main objective of the attacker (for
both of the above attack scenarios) is to deduce the targeted secret
information of victim code by correlating the secret data-dependent
computations with the collected execution time of the code for different data
inputs.

####  3.2.2. Attack Methodology

Fig. 3 presents an overview of the throttling side-channel attack against a
constant-cycle implementation of victim workload. Such an attack consists of
the following three phases:

  * •

Configuration Phase: The attacker profiles a victim-like workload with a known
asset to either configure the related power management settings (Ring 0
attacker) or identify a suitable stressor code (Ring 3 attacker) such that
victim workload execution will result in triggering frequency throttling.

  * •

Online Phase: The attacker provides different data inputs to the victim code,
which in turn performs one or more secret asset-dependent computations. The
attacker also runs a monitor program in parallel to measure the execution time
of the victim code with various data inputs.

  * •

Analysis Phase: The attacker applies analysis methods (such as CPA) on the
collected execution time values, to deduce the targeted secret asset of the
victim code.

##  4\. Case study: Attack against AES encryption

In this section, we consider a victim workload comprising an AES-NI-based
implementation of AES-128 as a case study to illustrate the proposed
throttling side-channel attack. In order to assess the side-channel leakage
due to throttling activity, we use statistical analysis methods derived from
Test Vector Leakage Assessment (TVLA) (Goodwill et al., 2011; Standaert, 2017)
and correlation-based analysis.

###  4.1. Victim Workload

####  4.1.1. AES-128 Algorithm

AES is a block cipher established by NIST in 2001 (of Standards and
Technology, 2001). The algorithm encrypts a fixed size plaintext block of
128-bit using key-size of 128, 192, or 256 bits and outputs a 128-bit
ciphertext. In this work, we consider the AES-128 primitive to demonstrate
frequency throttling side-channel attack.

####  4.1.2. AES-NI-Based AES Implementation

AES-NI is an instruction set which improves the AES implementation by
accelerating its complex performance-intensive steps using dedicated hardware
(Gueron, 2010). AES-NI instructions also provide improved security against
side-channel attacks due to their constant-cycle implementations. AES-NI
instructions are supported by x86 processors of major vendors, including Intel
and AMD. To perform encryption, first individual round keys are derived using
the KeyExpansion procedure (Gueron, 2010). This is followed by the Initial
AddRoundKey operation, which computes the bitwise XOR between the plaintext
and the initial round key. AESENC instruction is then used to perform a single
round of encryption with round state and round key as the input operands. The
AESENCLAST instruction performs the last round of encryption and returns the
ciphertext.

###  4.2. Attack Methodology Details

As outlined in section 3.2.2, the frequency throttling side-channel attack
against a victim workload comprises three distinct phases: the configuration,
the online, and the analysis phases. Next, we present the details of each of
these phases as adopted in our case study, using power limit as an example.

####  4.2.1. Configuration phase

During the configuration phase, the privileged software attacker first
profiles the AES-NI-based victim workload to estimate $P$, which is the power
consumption of the victim workload without frequency throttling. Then, in
order to trigger throttling activity, a privileged software attacker may
adjust the system’s power limit value $PL$ such that $P>PL$. As per Algorithm
1, such an adjustment will lead to a change in $P$-$State$ that satisfies the
available power budget. In order to ensure that there is data-dependent
frequency throttling activity, the value of the reactive limit $PL$ should be
carefully adjusted$:$ setting the $PL$ value too high will not satisfy the
requirement of $P>PL$ whereas setting the $PL$ value too low will cause the
system to execute in a constant low frequency. For a user-space attacker who
does not have the privilege to configure $PL$, an alternative approach is to
run a stressor workload to boost power consumption. The details will be
discussed in section 4.5.

####  4.2.2. Online phase

During the online phase, the attacker inputs plaintext to the victim workload
and obtains the corresponding ciphertext as output. Note that due to PL-
induced throttling activity, different plaintexts will result in different
processing times which correspond to the side-channel traces. During the
$i^{th}$ trace collection, the attacker first records the starting time stamp
counter value ($T^{i}_{1}$) just before sending the $i^{th}$ plaintext to the
victim workload and subsequently, also records the end time stamp counter
value ($T^{i}_{2}$) just after receiving the $i^{th}$ ciphertext. Then, the
attacker calculates the corresponding execution time $T_{\delta}^{i}$ as
$T^{i}_{2}-T^{i}_{1}$. On most of the modern CPUs, incrementing of the time
stamp counter is _frequency-invariant_ so the $T_{\delta}$ captures wall clock
time of the victim’s execution time and will not be impacted by frequency
throttling (Intel, 2022e; AMD, 2022c).

Techniques to reduce Minimum Time to Disclosure: We define
$Minimum~{}Time~{}to~{}Disclosure~{}$(MTD) as the minimum time spent to
collecting enough side-channel traces to recover the secret information.
Reduction in MTD can be achieved by (i) increasing the Signal-to-Noise (SNR)
of the captured traces, or (ii) decreasing the collection time of each trace
(Mangard et al., 2008). In our experiments, we adopted the following
techniques to lower the MTD of frequency throttling side-channel attack:

  * •

Multiple instances of the victim workload were executed simultaneously across
different processor cores to amplify its average power consumption, which in
turn results in higher SNR of the collected traces.

  * •

Each instance of the victim workload was executed repeatedly $N$ times with
the same input to collect one trace. This approach not only ensured that the
on-chip sensors accurately sampled the average power consumption of the victim
workload during a reactive limit’s $\tau$ window but also boosted the SNR of
collected traces for a sufficiently large value of $N$ (which spans across
multiple $\tau$ windows) due to the denoising effect of averaging (Wu and
Picek, 2020).

  * •

Selection of a system reactive limit having the lowest possible configurable
value of $\tau$ to trigger throttling activity during victim workload
execution. For a chosen value of $N$, the trace collection time corresponding
to a reactive limit having lower $\tau$ will be shorter compared to that
corresponding to a reactive limit with higher $\tau$. Of course, such
selection or adjustment of a reactive limit is only applicable to a privileged
attacker.

####  4.2.3. Analysis phase

We utilize two statistical techniques to analyze potential side-channel
information leakage arising from throttling side-channel activity: (i) First,
in order to ascertain if different data exhibit different PL-induced
throttling behavior, we apply TVLA to the corresponding timing traces. (ii)
Second, depending upon the positive outcome of the TVLA, we perform a CPA
attack in order to determine if the targeted AES encryption key can be
recovered by analyzing the collected timing side-channel traces. Next, we
present the details of these statistical techniques as adopted in our
experiments.

TVLA: TVLA methodology utilizes t-scores generated from Welch’s t-test to
assess potential side-channel leakage in cryptographic implementations
(Gilbert Goodwill et al., 2011). Welch’s t-test defines a statistical measure,
t-score, as shown in equation (3) to compare two datasets A and B

(3)
$\text{$t$-$score$}=\frac{\mu_{1}-\mu_{2}}{\sqrt{s_{1}^{2}/N_{1}+s_{2}^{2}/N_{2}}}$

where, $\mu_{1}$, $\mu_{2}$ are sample means, $s_{1}^{2}$, $s_{2}^{2}$ are
sample variances, and $N_{1}$, $N_{2}$ are the number of samples in datasets A
and B, respectively. A |$t-score$| $>$ 4.5 rejects the null hypothesis with
99.999% confidence, indicating datasets A and B are statistically
distinguishable (Schneider and Moradi, 2015).

In this case study, we assess the throttling side-channel leakage of an AES-
NI-based AES implementation victim workload using the above-mentioned TVLA
methodology. We collect the timing traces corresponding to encryption of three
different sets of plaintexts: $All\\_one$, $All\\_zero$ and $Random$. We apply
TVLA test on timing traces for all possible pairs of chosen plaintexts.

CPA Attack: We also apply CPA attack to recover the secret key from the AES-NI
based victim workload by collecting timing traces $T_{\delta}$ corresponding
to different randomly generated plaintexts. Then, we utilized the following
equation to calculate the Pearson’s correlation coefficient metric
$\gamma^{k}$ for different key guess $k$.

(4)
$\gamma^{k}=\frac{cov(T_{\delta},T_{h}^{k})}{\sigma_{T_{\delta}}\sigma_{T_{h}^{k}}}$

where, $\sigma_{T_{\delta}}$ and $\sigma_{T_{h}^{k}}$ represent the standard
deviations of the actual PL-induced execution time traces $T_{\delta}$ and the
hypothetical execution time estimations $T_{h}^{k}$, respectively. Note that
similar to power estimates, such execution time estimates can also be obtained
using standard Hamming weight (HW) or Hamming distance (HD) models. This is
because the PL-induced execution time variations of the victim workload are
proportional to the corresponding power consumption variations.

The attacker may choose either the initial round (targeting initial
AddRoundKey round key $k_{0}$) or the last round (targeting last round key
$k_{10}$) of AES implementation as _point of attack_. Intermediate AES rounds
are typically not considered as attack points because in those cases the
corresponding hypothetical execution time values become a function of multiple
round keys, thus substantially increasing attack complexity. Selection of
hypothetical execution time model ($T_{h}^{k}$) is based on the point of
attack (Saab et al., 2016; Mestiri et al., 2012):

  * •

Round0-HW: To recover the initial round key $k_{0}$, the hypothetical
execution time values can be modeled using HW of the initial AddRoundKey
output.

  * •

Round10-HW:To recover the last round key $k_{10}$, the hypothetical execution
time values can be modeled using HW of last round input, derived using
ciphertext and hypothesis of $k_{10}$.

  * •

Round10-HD: Also, the attacker can model the hypothetical execution time
values using HD between last round input and ciphertext, derived using
ciphertext and hypothesis of $k_{10}$.

  * •

Round10-HW+HD: We also considered a leakage model comprising the sum of
Round10-HW and Round10-HD models, derived using ciphertext and hypothesis of
$k_{10}$.

We use _Guessing Entropy_ (GE) to evaluate the success of a CPA attack, based
on the metric from (Rivain, 2009). For byte $i$ of the round key, all possible
key guesses are sorted in descending order of their correlation coefficient,
to obtain the rank of the correct key byte. For all bytes of the guessed key,
the ranks are summed up (logarithmically) to get GE, as shown in Equation (5).

(5) $\text{GE}=\sum_{i=1}^{16}log_{2}[rank(k_{i}^{correct\\_key})]$

Lower GE indicates lower average ranks across all key bytes and, most of the
time, means more key bytes are recovered successfully. A value of GE=0 implies
all key bytes have been recovered. In practice, a successful CPA attack should
result in a GE value lower than a pre-defined threshold which allows the
recovery of the key bytes with reasonable computational complexity.

###  4.3. Evaluation

Table 1. Information and configurations of the systems under test.

Processor Number | # of physical cores | Max Turbo frequency | SMT | PL2/PPT Fast limit value | PL2 $\tau$
---|---|---|---|---|---
Intel E3-1230V5 | 4 | 3.8 GHz | disabled | 10W | 2ms
Intel i7-1185G7 | 2 | 4.1 GHz | disabled | 8W | 2ms
Intel Xeon Gold 6326 | 8/socket | 3.5 GHz | disabled | 50W | 2ms
AMD Ryzen 5 5600G | 6 | 3.2 GHz | disabled | 15W | -

Table 2. Pairwise t-score (absolute value) among $All\\_zero$, $All\\_one$,
and $Random$ traces. T-score greater than 4.5 are marked in bold and indicates
the set of data are statistically distinguishable.

| Intel E3-1230V5 | Intel i7-1185G7 | Intel Xeon Gold 6326
---|---|---|---
| All_zero_2 | All_one_2 | Random_2 | All_zero_2 | All_one_2 | Random_2 | All_zero_2 | All_one_2 | Random_2
All_zero_1 | 1.02 | 41.02 | 26.20 | 0.23 | 10.57 | 5.32 | 0.45 | 19.82 | 12.51
All_one_1 | 38.42 | 2.38 | 11.79 | 12.58 | 3.02 | 8.08 | 19.74 | 0.53 | 7.57
Random_1 | 24.07 | 14.28 | 2.36 | 1.32 | 9.23 | 3.84 | 11.27 | 7.72 | 0.68

In this section, we implement a Proof-of-Concept (PoC) code to demonstrate
secret key recovery from an AES-NI based victim workload as outlined in
section 4.1. Our experiments mainly focus on Intel systems, where we consider
both power limit induced and current limit induced frequency throttling
activity during trace collection. We also demonstrate cross-platform
applicability of the attack through experimental evaluation on an AMD
processor.

####  4.3.1. Experimental Setup

In our PoC, the AES encryption workload is repeated (with the same plaintext
and key for encryption) for many iterations. On the same thread, the
measurement code measures the aggregated execution time of the victim using
_time stamp counter_ and logs it a single trace. The number of iterations is
calibrated on each system such that every trace spans approximately 45ms
(i.e., $T_{\delta}$=45ms). To boost SNR, multiple instances of the same victim
workload are executed in parallel on the other cores.

For experimental evaluations, we considered three Intel systems: E3-1230V5,
i7-1185G7, and Xeon Gold 6326 and one AMD system: Ryzen 5 5600G. Table 1 lists
the details of different systems along with their corresponding PL2 (or PPT
Fast for AMD system) values as adjusted in the configuration phase of the
attack to introduce frequency throttling activity during workload execution.
The reason behind selection of PL2 (PPT Fast for AMD system) is due to the
lower default time window $\tau$, which can be configured further to a shorter
window of 2ms in an Intel system. Note that a lower $\tau$ value reduces the
minimal trace length and hence, reduces the MTD requirement as discussed in
section 4.2.2. Also, note that since Xeon Gold 6326 is a 2-socket server
system with power limits being defined independently per socket, we run the
victim workload on socket 0 and adjust only PL2 corresponding to socket 0.

We first report the experimental outcomes of TVLA tests to highlight potential
side-channel information leakage arising from frequency throttling activity.
Then, we present the results of a CPA attack to demonstrate how an attacker
can successfully recover the secret key by collecting timing side-channel
traces of the AES implementation. We first test the victim code outside a TEE
to showcase the behavior. Experimental results targeting a victim workload
inside SGX are presented thereafter in section 4.4, and experimental results
with a user-space attacker is presented in section 4.5.

####  4.3.2. TVLA Results

For every system under test, following the TVLA methodology described in
section 4.2.3, we collected $10,000$ timing traces of the victim workload
corresponding to the encryption of each of the plaintext sets (
$All\\_one\\_1$, $All\\_zero\\_1$ and $Random\\_1$). We repeated the trace
collection process with the same plaintext sets ($All\\_one\\_2$,
$All\\_zero\\_2$ and $Random\\_2$) in order to ascertain that there are no
false positives in the TVLA test outcomes due to issues associated with data
collection (e.g., inconsistent system behaviors or settings). Subsequently, we
first removed outlier traces followed by calculation of Welch’s $t$-$score$
measure using the remaining trace sets, which correspond to every possible
pairs of plaintext sets. The results of this experiment are presented in Table
2, where the $t$-$score$ values greater than 4.5 are marked in bold to
indicate that the pairs of datasets are statistically distinguishable. It can
be observed that across all the three systems, $t$-$score$ values between
trace sets corresponding to different plaintext sets are higher than 4.5 (the
only exception is the case $Random_{1}$ vs. $All\\_zero\\_2$ on i7-1185G7
system) while the $t$-$score$ values between trace sets corresponding to same
plaintext sets are lower than 4.5. This signifies that, due to power limit-
induced throttling activity, the CPU frequency changes in a data-dependent
manner, which leads even a constant-cycle victim code implementation to
exhibit data-dependent runtime differences.

Table 3. Converged Guessing Entropy (GE) on different systems with different
leakage models. Lower GE implies more key bytes are recovered.

| Intel E3 | Intel i7 | Intel Xeon | AMD Ryzen
---|---|---|---|---
Round0-HW | 17.5 | 27.5 | 2.6 | 2.0
Round10-HW | 85.7 | 73.3 | 86.0 | 3.16
Round10-HD | 0 | 27.3 | 81.2 | 35.8
Round10-HW+HD | 0 | 21.4 | 72.7 | 1.5

####  4.3.3. CPA Attack Results with Power Limit

With the TVLA tests exhibiting positive signs of potential side-channel
information leakage, we further investigated the applicability of a CPA attack
on the power limit-induced timing traces, to recover the secret AES key. On
each of the Intel systems, we collected 8 million timing traces of the PoC
code (with a fixed key) by providing randomly generated plaintexts. The trace
collection process took about 100 hours on average across different systems.
After the trace collection phase, we computed the median $\mu$ of the
collected traces and discarded the outliers of $[0.95\mu,1.05\mu]$.
Subsequently, we applied the CPA attack on the filtered trace dataset,
targeting the round keys $k_{0}$ and $k_{10}$.

In Figure 4, we present the GE trends (corresponding to different execution
time estimate models) versus the number of timing traces considered for the
CPA attack across multiple systems. Based on the data, we make the following
observations:

  * •

The general trend is that GE converges gradually when increasing number of
traces are used for analysis. This is because a larger number of traces helps
to reduce the effect of noise in the collected traces. Such GE trends
highlight the fact that all the execution time estimate models considered
correlate with the actual execution times of the PoC code. Also, it can be
observed that in all cases, GE values start from somewhere around 112. This is
because the expected value of the initial rank of correct key byte (without
parsing any side-channel traces) is 128 among the 256 possible key byte
guesses. Therefore, the expected value of initial GE value is
$E(GE)=\sum_{i=1}^{16}log_{2}(128)=112$.

  * •

Round0-HW model appears to be effective on all the three systems: GE converges
to 17.5 on E3-1230V5, 27.5 on i7-1185G7, and 2.6 on Xeon Gold 6326.
Especially, on Xeon Gold 6326, with this execution time estimate model, we
successfully recovered 14 out of the 16 bytes of the correct key. The ranks of
the remaining two key bytes are 2 and 3.

  * •

Round10-HW model converges the slowest among all the models tested. On both
E3-1230V5 and Xeon Gold 6326 systems, even after analyzing with 8M traces the
GE values remain above 80, signifying that the CPA attack was unsuccessful in
these cases. The lowest GE value obtained was 73.3 on i7-1185G7 system.

  * •

Round10-HD model shows distinctly different behaviors on different systems. On
E3-1230V5 system, for example, GE converges to 0 (all 16 key bytes recovered)
with less than 2M traces. Also, on i7-1185G7 system, for this model GE
converges to 27.3, similar to Round0-HW model. But in the case of the Xeon
Gold 6326 system, for this model the GE value reduces to only 81.2.

  * •

Round10-HW+HD model results in consistently lower GE values compared to the
Round10-HW model across all the three systems. However, compared to the
Round10-HD model, for this model the GE value converges slower on E3-1230V5
system whereas the GE values converge faster on i7-1185G7 and Xeon Gold 6326
systems.

Figure 4. Guessing Entropy trend with different amount of traces on (a)
E3-1230V5, (b) i7-1185G7, and (c) Xeon Gold 6326 systems with power limit-
induced frequency throttling

Note that for a given execution time estimate model, the difference in
behavior of GE trends on different systems is likely due to variations in the
underlying hardware micro-architecture designs and the fabrication
technologies used. Table 3 summarizes the outcomes of the CPA attack
corresponding to different execution time estimate models across systems.
These results demonstrate the fact that power-limit induced frequency
throttling activity can be successfully leveraged by an attacker to extract
secret information from cryptographic workloads.

Figure 5. Guessing Entropy trend with different amount of traces on i7-1185G7,
with current limit-induced frequency throttling Figure 6. Guessing Entropy
trend with different amount of traces on an AMD Ryzen 5 5600G processor with
PPT Fast limit-induced frequency throttling

####  4.3.4. CPA Attack Results with Current Limit

We also repeated the CPA test on the i7-1185G7 system with VR-TDC limit set to
7 Amperes to trigger frequency throttling. All other configurations were kept
the same as used for the power-limit induced frequency throttling experiments
in the previous subsection. The GE trends for different execution time
estimate models are shown in Figure 5. Similar to the power-limit experiments,
the GE value corresponding to the Round10-HW model converges the slowest
amongst all the models tested. The GE values for both Round0-HW and Round10-HD
models converge to around 20 after analyzing with 8M traces. The GE value
corresponding to Round10-HW+HD model converges to the lowest value (around 10)
for the CPA attack with current limit. These observations confirm the fact
that VR-TDC limit can also be leveraged by an attacker to mount the frequency
throttling side-channel attack.

####  4.3.5. CPA Attack Results on AMD Ryzen 5

We also repeated the CPA test on an AMD Ryzen 5 5600G system with PPT Fast
Limit set to 15W to trigger frequency throttling. The victim AES workload was
executed using the configuration mentioned in last row of Table 1 and the
number of iterations of the workload was calibrated such that every trace
spans approximately 50ms (i.e., $T_{\delta}$=50ms). We collected 4.5M traces
with trace collection time of about 63 hours.

Figure 6 shows the trend in GE against the number of traces collected for CPA
analysis across different execution timing estimate models. From the figure,
we can observe that GE converges much faster with Round0-HW model as compared
to other execution timing estimate models. The GE value converges to almost
zero for approximately 1 million traces (in 16 hours) with Round-0 HW model,
recovering 14 out of the 16 secret key bytes. A similar trend in GE was
observed for other models as well; the GE values converged to (a) almost zero
for approximately 3 million traces with Round10-HW and Round10-HW+HD models
and (b) about 40 for approximately 4.5 million traces with Round10-HD model.
Table 3 summarizes the final converged GE values with different execution time
estimate models on the systems we tested.

###  4.4. Attacking AES-NI inside Intel® SGX enclave

We also evaluated an AES-NI based AES implementation from Intel’s Integrated
Performance Primitives (Intel IPP) (Intel, 2022f) as the victim workload,
executed inside an Intel SGX enclave. The victim takes a 16-byte plaintext as
the input from Enclave Call (ECALL) and encrypts it using a secret key owned
by the enclave. Similar to the experiment setup in section 4.3, the victim
workload repeatedly encrypts the same plaintext many iterations to boost SNR:
ippsAESEncryptECB is invoked 10000 times per trace, and each invocation
encrypts 1024 16-bytes of the same plaintext. In entirety, 160 MB of data is
encrypted in each ECALL. Ciphertext is returned to the caller of the enclave
after encryption. Also, to boost SNR, we invoke multiple enclave instances,
executing on multiple cores in parallel with the same plaintext as input. Only
the execution time for one enclave is recorded as timing traces.

We performed the experimental evaluation on an Intel E3-1230V5 system, with
PL2 limit and $\tau$ set to 20W and 2ms, respectively. We followed TVLA test
methodology as described in section 4.2.3 and collected 10000 timing traces
corresponding to the encryption of each of the plaintexts ($All\\_one$,
$All\\_zero$ and $Random$). The pairwise t-scores are presented in Table 4. We
observed that the t-score values between timing traces corresponding to
different plaintexts are greater than 4.5, while the t-score values between
timing traces corresponding to the same plaintext are lower than 4.5,
indicating data-dependent leakage in the time domain, due to PL-induced
throttling activity. The only exception is _Random_2_ vs. _All_zero_1_ , which
shows a t-score value less than 4.5. Upon comparing the TVLA results on the
same system (E3-1230V5) for the victim workload outside an SGX enclave (Table
2), we observe the magnitude of the t-scores (in most cases) for the victim
executing inside an SGX enclave is lower. This is due to the additional noise
introduced during enclave transitions, as well as IPP crypto function calls.

Table 4. Pairwise t-score (absolute value) among $All\\_zero$, $All\\_one$, and $Random$ traces, test on E3-1230V5 with victim workload inside Intel SGX enclave. | E3-1230V5 (Intel SGX victim workload)
---|---
| All_zero_2 | All_one_2 | Random_2
All_zero_1 | 1.19 | 29.19 | 24.31
All_one_1 | 33.12 | 3.65 | 2.20
Random_1 | 26.47 | 6.17 | 0.96

In a CPA test, we collected 8 million traces with $T_{\delta}$=45ms per trace,
which took about 100 hours in total. The traces are analyzed with different
leakage models and the results are shown in Figure 7. With Round10-HD model,
guessing entropy converges to 6 (14 out of 16 key bytes recovered) with the 8
million traces, confirming that information is observable through the
throttling side-channel for the given victim. Compared to the previous CPA
result on E3-1230V5 system (Figure 4(a)), the additional noise results in
lower SNR, and hence slower guessing entropy convergence (less key bytes being
revealed with the same amount of traces) for all the leakage models. For
example, in the previous test on the same system (Figure 4(a)), a full key can
be recovered from a victim outside an SGX enclave with less than 2 million
traces (25 hours).

Figure 7. Guessing Entropy trend with different amount of traces on E3-1230V5,
with power limit-induced frequency throttling and victim in Intel® SGX
enclave. Table 5. Pairwise t-score (absolute value) among $All\\_0$,
$All\\_1$, and $random$ traces with different PL1 settings. T-score greater
than 4.5 are marked in red and indicates the set of data are statistically
distinguishable.

| PL1=80W, w/o stressor | PL1=110W, w/o stressor | PL1=110W, w/ stressor | PL1=140W, w/stressor
---|---|---|---|---
| All_zero_2 | All_one_2 | Random_2 | All_zero_2 | All_one_2 | Random_2 | All_zero_2 | All_one_2 | Random_2 | All_zero_2 | All_one_2 | Random_2
All_zero_1 | 0.37 | 16.34 | 8.11 | 1.72 | 2.18 | 1.88 | 1.76 | 19.74 | 13.85 | 0.65 | 0.54 | 0.18
All_one_1 | 17.09 | 0.76 | 8.64 | 3.50 | 3.97 | 3.66 | 17.67 | 0.85 | 5.04 | 1.39 | 1.30 | 0.55
Random_1 | 8.18 | 7.60 | 0.27 | 0.48 | 0.95 | 0.65 | 11.66 | 7.27 | 1.12 | 0.08 | 0.05 | 0.76

###  4.5. User-Space Attack

We studied the feasibility of a user-space attack following the threat model
assumed in Attack Scenario 2 (see Section 3.2.1). A user-space attacker also
follows the attack methodology as presented in section 3.2.2. However, unlike
a privileged attacker, a user-space attacker does not have the privilege to
configure the reactive limits and hence, has to utilize the existing reactive
limit settings. This results in two implications: first, for most of the time,
the attacker can only leverage the PL1 limit (or PPT limit on AMD system) to
trigger frequency throttling as the default PL1 limit is typically set lower
than the other reactive limits. However, PL1 limit usually has a much larger
default $\tau$ window (in the order of tens of seconds) compared to that of
PL2 limit, and hence, trace collection time due to PL1 limit-induced
throttling will be significantly longer as well (see section 4.2.2). Second,
it is possible that the power consumption of a victim workload does not exceed
even the PL1 limit, thus failing to trigger any throttling activity, requiring
the adversary to compensate.

In order to overcome the limitations of the second implication, the user-space
attacker can execute a suitable stressor code in parallel with the victim
workload to boost the cumulative power consumption $\overline{P}$ such that it
exceeds a reactive limit of the system. According to Algorithm 1 (line 8), a
significant boost in $\overline{P}$ will lead to a reduction of the available
power budget $\Delta$ below a certain threshold, which in turn will trigger
frequency throttling activity. Stressor code selection requires the following
careful considerations: first, power consumption of the stressor code should
be high enough to aid the workload to hit a system reactive limit. Second, the
variance in power consumption of the stressor code should be as low as
possible, so that it does not introduce significant additional noise in the
collected side-channel traces. Third, the stressor code should have minimal
resource contention (e.g., contention for ports or execution units) with the
victim workload, to further reduce noise. Additionally, the execution of the
stressor code should not cause the system temperature to exceed the thermal
limit, since in that case the collected side-channel traces will be affected
by noise introduced due to thermal throttling. Therefore, as evident from the
above requirements, the selection procedure of a suitable stressor code for a
given victim workload and system under test could be a challenging task for
the user-space attacker.

We performed experimental evaluations for the user-space attack scenario on an
Intel i7-10700K system using its available 8 physical cores/16 logical cores
(with SMT enabled). At first, we profiled the power consumption $P_{victim}$
of victim workload (AES-NI based AES implementation) by simultaneously
executing multiple instances of it on 8 different physical cores and observed
that $P_{victim}$ is about 83W. Next, we considered the following four test
cases by assuming the default PL1 limit at different levels (but with the same
$\tau$ window of about 56s):

  1. (1)

PL1 limit set to 80W. Only victim workload is executed.

  2. (2)

PL1 limit set to 110W. Only victim workload is executed.

  3. (3)

PL1 limit set to 110W. Stressor and victim workloads executed.

  4. (4)

PL1 limit set to 140W. Stressor and victim workloads executed.

For all the above cases, we performed TVLA tests, by collecting 1,000 timing
side-channel traces (with $T_{\delta}$ = 1s) corresponding to the encryption
of each of the plaintext sets as considered previously. Note that in these
tests, we set $T_{\delta}$ to a much larger value (compared to 45ms as used in
privileged attacker scenario) due to the high default value of PL1 $\tau$
window. Additionally, for cases (3) and (4), a stressor code consisted of
repeated execution of MOVB instructions across 6 different threads was running
in parallel with the victim.

The results of the test cases are reported in Table 5 from left to right. For
test case (1), when PL1=80W and is lower than $P_{victim}$, we observe high
t-score values between different pairs of plaintext sets, signifying
significant throttling side-channel leakage from the victim workload execution
even without stressor code. For test case (2), when PL1=110W and without any
stressor code, we do not observe any leakage after analyzing the collected
timing traces corresponding to the execution of victim workload. This is an
expected outcome, since in this case the limit is higher and $P_{victim}$
fails to trigger PL1-induced frequency throttling activity. This was the
reason for introducing stressor code. For test case (3), when the stressor
code was executed in parallel to the victim workload, the cumulative system
power consumption $\overline{P}$ hit the PL1 limit, leading to throttling
side-channel leakage, as evident from the corresponding high t-score values in
the third column. This shows that the stressor code is effective in inducing
throttling side-channel leakage. For test case (4), when PL1=140W, we observed
that the simultaneous execution of the victim and stressor workloads caused
system temperature to rise to 100∘C, thus triggering thermal throttling before
triggering PL1-based throttling. Thermal throttling degraded the SNR of
collected timing traces, thus leading to low t-score values as reported in the
last column of Table 5.

In this paper, for the user-space attack scenario, we limited our experimental
evaluations to TVLA tests, as it was infeasible to perform a CPA attack
against an AES-NI based AES implementation, because of its very high MTD
requirements for collecting millions of telemetry side-channel traces.
Importantly, in case of side-channel analysis of cryptosystems which require
low number of traces, a user-space attack exploiting frequency throttling
activity can be realized with a reasonable MTD. For example, in (Wang et al.,
2022), the authors demonstrate how a Ring 3 attacker utilizes the throttling
side-channel information to extract keys from a post-quantum key encapsulation
scheme within a few days, exploiting a corner case in the algorithm
implementation.

##  5\. Mitigation

In this section, we discuss different countermeasures to safeguard a victim
workload from being susceptible to frequency throttling side-channel attacks.
Before going to the details of the mitigation strategies, we first summarize
the conditions that must be satisfied to mount such an attack.

  * •

Condition 1 (Secret Dependency): The victim code processes a secret asset that
is vulnerable to a power side-channel attack. This requires (i) the victim
software implementation to be vulnerable to traditional physical side-channel
attacks and (ii) the underlying hardware system to exhibit variation in power
consumption profiles for processing different data.

  * •

Condition 2 (Controller Actuation): One of the reactive limits of the system
is being hit during victim code execution. This will cause the power
management architecture to trigger frequency throttling activity based on the
available power budget (see Algorithm 1 for details).

  * •

Condition 3 (Observability): The attacker can monitor the execution time (wall
clock time) of the victim code with sufficiently high resolution, or else an
equivalent quantity.

In order to thwart side-channel information leakage due to frequency
throttling activity, the designer should consider targeting the above-
mentioned necessary conditions. Next, we present different potential
countermeasure options along with their respective advantages and
disadvantages.

Table 6. Summary of mitigations against the frequency throttling side-channel

# | Mitigation Target | Mitigation Description | Applicable Layer(s) | Mitigation Effectiveness | Perf./Func. Impact
---|---|---|---|---|---
1 | Secret Dependency | Existing traditional power side-channel mitigations (e.g., masking, key refresh) | User App/System SW/HW | Vary | Vary
2 | Controller Actuation | Keep the system at lowest frequency or disable reactive limits | System SW/HW | Fully | High
3 |  | Reduce sensitivity of throttling control algorithm | HW | Partially | Medium
4 |  | Add randomness to the reactive limit | System SW/HW | Partially | Medium
5 |  | Avoid exposing reactive limit configuration interfaces to untrusted entities | System SW | Partially | Low
6 |  | Use modelled power instead of actual power in throttling control algorithm | HW | Fully | High
7 |  | Add noise to power input of throttling control algorithm | HW | Partially | Medium
8 | Observability | Utilize inherent noise or inject artificial noise to cryptographic operations | User App/System SW | Partially | Medium

###  5.1. Analysis of Secret Dependency

####  5.1.1. Necessary conditions of Secret Dependency

Since power side-channel is the fundamental root cause of frequency throttling
side-channel, the necessary conditions for the physical power side-channel
attack also need to be satisfied for throttling side-channel (except for the
physical access capability to measure power). First, the victim application
needs to process a secret asset (e.g., cryptographic key) with a
confidentiality requirement. Second, power consumption of the underlying
hardware processing the secret needs to correlate with the asset. Third, the
implementation of the victim application is susceptible to power side-channel
attack. For example, the victim application provides the capability for the
adversary to repeatedly initiate cryptographic operations with the same
sensitive key to collect enough data. Also, for block ciphers, the adversary
should have the ability to read input/output or inter-round state of the block
cipher primitives. Please note that the input/output is not necessarily the
plaintext or ciphertext. One example is the counter (CTR) mode of operation
for block ciphers, where the input to the block cipher is the concatenation of
the nonce and the counter instead of a plaintext.

####  5.1.2. Mitigations

Most of the existing countermeasures against traditional power side-channel
will be as effective against a frequency throttling side-channel. For example,
software-based masking (Prouff and Rivain, 2013) that splits a secret asset
into multiple random shares will randomize the power consumption of the
hardware, and will be useful against a frequency throttling side-channel.
There are several noteworthy exceptions. For example, shuffling-based
countermeasures that randomize instruction execution order, while being
effective in making trace alignment and identification of points of interest
harder for physical power side-channel attacks, are less effective in
mitigating a frequency throttling side-channel. This is because reordering
instructions at the cycle granularity is less likely to impact average power
consumption during the time window $\tau$ in the order or milliseconds or
longer. Also, since an adversary does not need to physically access the
hardware, any protection that physically isolates the system will not be
sufficient to prevent a frequency throttling side-channel attack.

For cryptographic applications based on existing cryptographic libraries, an
example of a generic countermeasure against power side-channel is _key
refresh_. One of the necessary conditions for power side-channel is
_amplification_ , or the ability to repeatedly kick off cryptographic
operations with the same sensitive key to collect a sufficient amount of
traces. If the secret key is refreshed before enough traces can be collected,
it will be harder for the attacker to fully deduce the secret. One important
design factor is how frequency the key should be refreshed, which could be
based on timing (e.g., refresh per several hours) or data volume (e.g., the
volume of data being encrypted with the same key). If the designer is
uncertain of the threshold to use, the lowest threshold that meets performance
and design requirements should be selected. Naturally, the practicality of key
refresh depends on the specific cryptographic use case (e.g., key refresh is
typically not applicable to disk encryption).

From a hardware perspective, secret dependency is satisfied for almost all
modern CPUs since power consumption difference due to circuit switching
behavior is an inherent property of CMOS circuits. Making the entire SoC
power-constant would of course address this condition, but is difficult to
achieve, if not impossible. A more feasible option is making specific
security-sensitive hardware components (e.g., hardware cryptography
accelerator) power-constant.

###  5.2. Analysis of Controller Actuation

This condition allows conversion from power differences to timing differences
during an attack. As described in Algorithm 1, the new frequency limit after
throttling $f_{max}$ is a function of the power budget, which is the
difference between the power limit $PL$ and the measured average power
consumption $\overline{P}$. A mitigation may target one of the components in
this conversion process: the control algorithm, $PL$, or $\overline{P}$.

####  5.2.1. Mitigations targeting the control algorithm

Since the purpose of reactive limits is to restrict a system from consuming
power or current beyond the limit while maximizing system performance, a
control algorithm is typically designed to select the highest possible
frequency limit that satisfies the reactive limits. A straightforward
mitigation option to change the control algorithm is to only allow the system
to run at the lowest frequency when reactive limits are hit. While it prevents
data-dependent frequency change, system performance is severely impacted.
Another option is to fully disable reactive limit based throttling, which is
usually not acceptable, since it is a critical power management feature and is
required for safety. An option to trade-off between security and functionality
is to reduce sensitivity of the control algorithm so that the switching of
frequency limit would be less correlated with the input.

####  5.2.2. Mitigations targeting reactive limits

Similarly, a firmware or system software may take a straightforward approach
to either configure the limit to a value too high to hit, or keep it very low
so that the system always runs at the lowest frequency. However, these changes
have severe negative impact on performance or functionality. One alternative
solution is to randomly "fuzz” the reactive limit. For example, instead of
configuring a static reactive limit to $PL$, firmware or system software may
define a range $[PL_{Low},PL_{High}]$, and randomly select a value in the
range, dynamically and routinely configuring the reactive limit. By doing so,
randomness will be introduced in the power budget, as well as CPU frequency.

As discussed, interfaces (e.g., MSRs) to configure reactive limits, if
accessible, could be utilized by an adversary to reduce the limits and trigger
the throttling side-channel attack. A cloud service provider (CSP) or system
software could prevent these interfaces from being exposed to untrusted guest
VMs or ring-3 software, and be aware of the risk if the interfaces have to be
exposed.

####  5.2.3. Mitigations targeting average power

The processor may decouple the calculated average power consumption from the
actual power consumption. One approach is to utilize modelled power
consumption instead of the actual power reading in the algorithm. If the model
is selected to exclude information of instruction operands, then the average
power will be independent of any secret data consumed by the victim
application. Another approach is for the processor to "fuzz” the average power
consumption by adding noise to the value before the control algorithm uses it
to compute the power budget. This is equivalent to the idea of fuzzing the
reactive limit, since power budget is the difference between reactive limits
and the average power. Please note that although fuzzing the power reading
will not directly change power consumption, it will alter $f_{max}$ and
indirectly impact power consumption and performance.

###  5.3. Analysis of Observability

One of the common countermeasures against side-channel attacks is to jam the
channel with noise to prevent the attacker from deducing the secret. As the
side-channel in this attack is frequency and timing information, noise can be
injected into the frequency transition or timing information. One method is to
leverage inherent noise during cryptographic application calls. As the
cryptographic library provider or cryptographic application provider, one may
restrict the maximal size allowed of processed data per API invocation, so
that more invocations of the API are needed to process the same amount of
data, and larger intrinsic noise will be introduced. Besides that, a
cryptography implementer may proactively inject random noise to cryptographic
operations to increase timing variation. To implement this countermeasure, the
developer may add dummy instructions that introduce sufficient power or
latency variation. The dummy instructions should be independent of the secret
data used in the cryptographic function. For example, timing variation can be
introduced using a loop of instructions with random iterations. In addition to
that, any power variation induced by the dummy instructions may also increase
the entropy of the frequency transition. To ensure randomness is introduced
for every frequency transition, it is recommended that some noise is injected
during every time window $\tau$ of the reactive limits that the attacker would
target. One possible way to trade-off security and performance impact is to
combine this scheme with a key refresh countermeasure, to increase the time
needed to perform a successful attack to a key lifetime that is acceptable.

###  5.4. Summary of Mitigation Options

A summary of the mitigation options is listed in Table 6, categorized based on
the condition to address, the layer(s) to apply, the security effectiveness in
mitigating the frequency throttling side-channel, and the performance or
functional impact. As can be seen, options that fully resolve the security
issue (e.g., #2 and #6) bring high performance or functional impact, while
options that partially reduce the security risk have low to medium impact.
Depending on the layer in which the mitigation is applied, different options
might be selected. For example, the developer of a user-space cryptography
implementation may consider options #1 and #8, which are the options available
to Ring 3 software.

##  6\. Related Work

Related work has demonstrated the vulnerability of software accessible energy
and power telemetry information to side-channel analysis attacks. In (Yan et
al., 2015), the authors highlighted the use of software-accessible battery
data of an Android phone to extract sensitive information from multiple
applications. It has been shown in (Fusi, 2016) that energy meter readings can
be used to infer control flow dependency as well as cache hit/miss patterns
for a program. (Mantel et al., 2018) demonstrated the utilization of energy
meter readings to distinguish keys of different Hamming weights for an RSA
implementation.

In addition to the above, several recent works have targeted a processor’s
energy consumption information (as exposed by RAPL interfaces in both Intel
and AMD processors) to perform side-channel analysis attacks. In (Lipp et al.,
2021), the authors demonstrate software-based power side-channel attacks
called Platypus to extract a key from a secure enclave, to break kernel
address space layout randomization (KASLR), and to establish a timing-
independent covert channel. In (Liu et al., 2021), the authors present a
methodology to perform side-channel risk assessment of different software-
accessible telemetries including RAPL energy, CPU frequency, voltage, and
temperature data.

Concurrent to our work, Wang _et al._ (Wang et al., 2022) also discovered the
frequency throttling side-channel and named the attack _Hertzbleed_. Wang _et
al._ highlight the concept of conversion of power side-channel information to
timing side-channel information and exploit it to recover a key from the SIKE
post-quantum key encapsulation algorithm. Compared to Hertzbleed, this paper
introduces and comprehensively explains the underlying mechanism and reasoning
behind the frequency throttling side-channel leakage. We demonstrate key
recovery by performing correlation power analysis on the widely used AES-NI
based AES implementation and further elaborate on the privileged software
attack scenario (sections 4.3 and 4.4), showing how reactive limit
configuration helps coerce information leakage. We discuss the unprivileged
attack scenario, which the Hertzbleed paper focuses on, showing that such an
attack is comparatively harder to achieve (section 4.5). In addition, this
paper provides a thorough discussion of mitigation options to thwart such
frequency throttling side-channel attacks. Wang _et al._ propose to disable
Turbo Boost or to disable SpeedStep and HWP from the BIOS, as a workload
independent mitigation, with the presumed intent of minimizing DVFS
transitions. While this has the effect of indirectly reducing power
consumption, such a mitigation does not affect the enforcement of reactive
limits nor the underlying behavior of Algorithm 1. Thus, if a reactive limit
is hit (e.g., as in the privileged attack scenario, by an adversary
sufficiently lowering the reactive limit), then information is still expected
to leak.

##  7\. Conclusion

In this paper, we present a novel frequency throttling side-channel analysis
attack. The root cause of such a side-channel is a power side-channel, which
is converted to a timing side-channel by the power management architecture
when reactive limits are triggered. We demonstrate the threat posed by
frequency throttling side-channel attacks by showing that the cryptographic
key can be successfully extracted from a constant-cycle implementation of AES
by measuring the executing time of cryptographic operations and apply
correlation power analysis. Finally, we present a set of options to thwart
such throttling side-channel analysis attacks, with analysis of pros and cons.
These mitigation options provide insights into the necessary conditions for
throttling side-channel information leakage and how to develop effective
countermeasures.

## References

  * (1)
  * AMD (2014) AMD. 2014.  Ryzen_Monitor.  https://github.com/hattedsquirrel/ryzen_monitor. (2014).  Accessed: 2022-05-01.
  * AMD (2018a) AMD. 2018a.  BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 15h Models 70h-7Fh Processors.  https://www.amd.com/system/files/TechDocs/55072_AMD_Family_15h_Models_70h-7Fh_BKDG.pdf. (2018).  Accessed: 2022-05-01.
  * AMD (2018b) AMD. 2018b.  Open-Source Register Reference For AMD Family 17h Processors Models 00h-2Fh.  https://developer.amd.com/wp-content/resources/56255_3_03.PDF. (2018).  Accessed: 2022-05-01.
  * AMD (2022a) AMD. 2022a.  AMD CVE-2020-12912.  https://nvd.nist.gov/vuln/detail/CVE-2020-12912. (2022).  Accessed: 2022-04-12.
  * AMD (2022b) AMD. 2022b.  AMD Ryzen Technology: Precision Boost 2 Performance Enhancement.  https://www.amd.com/en/support/kb/faq/cpu-pb2. (2022).  Accessed: 2022-03-12.
  * AMD (2022c) AMD. 2022c.  AMD uProf User Guide.  https://developer.amd.com/wordpress/media/2013/12/User_Guide.pdf. (2022).  Accessed: 2022-4-21.
  * AMD (2022d) AMD. 2022d.  Ryzen Master 2.9 - Reference Guide.  https://www.amd.com/system/files/documents/ryzen-master-quick-reference-guide.pdf. (2022).  Accessed: 2022-05-01.
  * ARM (2022) ARM. 2022.  ARMv8-A Power Management.  https://developer.arm.com/documentation/100960/0100/ARMv8-A-Power-management?lang=en. (2022).  Accessed: 2022-04-10.
  * Åström and Murray (2010) Karl Johan Åström and Richard M Murray. 2010.  Feedback systems.  In Feedback Systems. Princeton university press.
  * Ayers et al. (2019) Grant Ayers, Nayana Prasad Nagendra, David I. August, Hyoun Kyu Cho, Svilen Kanev, Christos Kozyrakis, Trivikram Krishnamurthy, Heiner Litz, Tipp Moseley, and Parthasarathy Ranganathan. 2019.  AsmDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computers. In Proceedings of the 46th International Symposium on Computer Architecture (ISCA ’19). New York, NY, USA, 462–473.  https://doi.org/10.1145/3307650.3322234
  * Bircher and John (2008) W. Lloyd Bircher and Lizy K. John. 2008.  Analysis of Dynamic Power Management on Multi-Core Processors. In Proceedings of the 22nd Annual International Conference on Supercomputing (ICS ’08). New York, NY, USA, 327–338.  https://doi.org/10.1145/1375527.1375575
  * Colmant et al. (2017) Maxime Colmant, Pascal Felber, Romain Rouvoy, and Lionel Seinturier. 2017.  WattsKit: Software-Defined Power Monitoring of Distributed Systems.  2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID) (2017), 514–523.  https://doi.org/10.1109/CCGRID.2017.27
  * Corporation and B (2000) Compaq Computer Corporation and Revision B. 2000.  Advanced Configuration and Power Interface Specification.  (2000).  http://www.acpi.info/
  * Costan and Devadas (2016) Victor Costan and Srinivas Devadas. 2016.  Intel SGX Explained.  Cryptology ePrint Archive, Paper 2016/086. (2016).  https://eprint.iacr.org/2016/086
  * Fieni et al. (2020) Guillaume Fieni, Romain Rouvoy, and Lionel Seinturier. 2020\.  SmartWatts: Self-Calibrating Software-Defined Power Meter for Containers.  2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID) (2020), 479–488.  https://doi.org/10.1109/CCGrid49817.2020.00-45
  * Fusi (2016) Matteo Maria Fusi. 2016\.  Information-Leakage Analysis based on Hardware Performance Counters.  Master’s thesis. The Polytechnic University of Milan.
  * Gilbert Goodwill et al. (2011) Benjamin Jun Gilbert Goodwill, Josh Jaffe, Pankaj Rohatgi, et al. 2011\.  A testing methodology for side-channel resistance validation. In NIST non-invasive attack testing workshop, Vol. 7.
  * Goodwill et al. (2011) Gilbert Goodwill, Benjamin Jun, Josh Jaffe, and Pankaj Rohatgi. 2011\.  P.: A testing methodology for side-channel resistance validation, NIAT.  (2011).
  * Gough et al. (2015) Corey Gough, Ian Steiner, and Winston Saunders. 2015.  CPU power management.  Apress, Berkeley, CA, 21–70.  https://doi.org/10.1007/978-1-4302-6638-9_2
  * Gueron (2010) Shay Gueron. 2010\.  Intel® Advanced Encryption Standard (AES) New Instructions Set.  (2010).  https://www.intel.com/content/dam/doc/white-paper/advanced-encryption-standard-new-instructions-set-paper.pdf
  * Haj-Yahya et al. (2018) Jawad Haj-Yahya, Avi Mendelson, Yosi Ben-asher, and Anupam Chattopadhyay. 2018.  Energy Efficient High Performance Processors Recent Approaches for Designing Green High Performance Computing.  https://doi.org/10.1007/978-981-10-8554-3
  * Haj-Yahya et al. (2021) J. Haj-Yahya, L. Orosa, J. S. Kim, J. Gomez Luna, A. Yaglikci, M. Alser, I. Puddu, and O. Mutlu. 2021\.  IChannels: Exploiting Current Management Mechanisms to Create Covert Channels in Modern Processors. In 2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). IEEE Computer Society, Los Alamitos, CA, USA, 985–998.  https://doi.org/10.1109/ISCA52012.2021.00081
  * Hochschild et al. (2021) Peter H. Hochschild, Paul Turner, Jeffrey C. Mogul, Rama Govindaraju, Parthasarathy Ranganathan, David E. Culler, and Amin Vahdat. 2021\.  Cores That Don’t Count. In Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS ’21). New York, NY, USA, 9–16.  https://doi.org/10.1145/3458336.3465297
  * Intel (2022a) Intel. 2022a.  Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.  https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/mitigate-timing-side-channel-crypto-implementation.html. (2022).  Accessed: 2022-05-02.
  * Intel (2022b) Intel. 2022b.  Intel CVE-2020-8694.  https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html. (2022).  Accessed: 2022-04-12.
  * Intel (2022c) Intel. 2022c.  Intel Running Average Power Limit Energy Reporting.  https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html. (2022).  Accessed: 2022-04-12.
  * Intel (2022d) Intel. 2022d.  Intel SGX.  https://software.intel.com/en-us/sgx. (2022).  Accessed: 2022-05-02.
  * Intel (2022e) Intel. 2022e.  Intel® 64 and IA-32 Architectures Software Developer Manuals.  https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html. (2022).  Accessed: 2022-05-02.
  * Intel (2022f) Intel. 2022f.  Intel® Integrated Performance Primitives Cryptography.  https://github.com/intel/ipp-crypto. (2022).  Accessed: 2022-04-07.
  * Intel (2022g) Intel. 2022g.  Overview of Enhanced Intel SpeedStep® Technology for Intel® Processors.  https://www.intel.com/content/www/us/en/support/articles/000007073/processors.html. (2022).  Accessed: 2022-04-07.
  * Intel (2022h) Intel. 2022h.  Overview of Intel® Speed Shift Technology.  https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/002/intel-speed-shift-technology/. (2022).  Accessed: 2022-04-07.
  * irusanov (2021) irusanov. 2021.  ZenStates-Core.  https://github.com/irusanov/ZenStates-Core. (2021).  Accessed: 2022-07-25.
  * Kaplan et al. (2016) David Kaplan, Jeremy Powell, and Tom Woller. 2016\.  AMD memory encryption.  (2016).  https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf Accessed: 2022-09-06.
  * Kim et al. (2008) Wonyoung Kim, Meeta S Gupta, Gu-Yeon Wei, and David Brooks. 2008\.  System level analysis of fast, per-core DVFS using on-chip switching regulators. In 2008 IEEE 14th International Symposium on High Performance Computer Architecture. 123–134.  https://doi.org/10.1109/HPCA.2008.4658633
  * Kocher et al. (2011) Paul Kocher, Joshua Jaffe, Benjamin Jun, and Pankaj Rohatgi. 2011.  Introduction to differential power analysis.  Journal of Cryptographic Engineering 1, 1 (2011), 5–27.
  * Kogler et al. (2022) Andreas Kogler, Daniel Gruss, and Michael Schwarz. 2022\.  Minefield: A Software-only Protection for SGX Enclaves against DVFS Attacks. In 31st USENIX Security Symposium (USENIX Security 22). Boston, MA, 4147–4164.
  * leogx9r (2022) leogx9r. 2022.  Ryzen SMU.  https://gitlab.com/leogx9r/ryzen_smu. (2022).
  * Lipp et al. (2021) Moritz Lipp, Andreas Kogler, David Oswald, Michael Schwarz, Catherine Easdon, Claudio Canella, and Daniel Gruss. 2021.  PLATYPUS: Software-based Power Side-Channel Attacks on x86. In 2021 IEEE Symposium on Security and Privacy (SP). 355–371.
  * Liu et al. (2021) Chen Liu, Monodeep Kar, Xueyang Wang, Nikhil Chawla, Neer Roggel, Bilgiday Yuce, and Jason M Fung. 2021.  Methodology of Assessing Information Leakage through Software-Accessible Telemetries. In 2021 IEEE International Symposium on Hardware Oriented Security and Trust (HOST). IEEE, 259–269.
  * Mangard et al. (2008) Stefan Mangard, Elisabeth Oswald, and Thomas Popp. 2008\.  Power analysis attacks: Revealing the secrets of smart cards. Vol. 31.  Springer Science & Business Media.
  * Mantel et al. (2018) Heiko Mantel, Johannes Schickel, Alexandra Weber, and Friedrich Weber. 2018.  How Secure Is Green IT? The Case of Software-Based Energy Side Channels. In European Symposium on Research in Computer Security (ESORICS 2018). 218–239.
  * Mestiri et al. (2012) Hassen Mestiri, Noura Benhadjyoussef, Mohsen Machhout, and Rached Tourki. 2012.  A Comparative Study of Power Consumption Models for CPA Attack.  International Journal of Computer Network and Information Security 5 (03 2012), 25–31.  https://doi.org/10.5815/ijcnis.2013.03.03
  * Morbitzer et al. (2021) Mathias Morbitzer, Sergej Proskurin, Martin Radev, Marko Dorfhuber, and Erick Quintanar Salas. 2021\.  SEVerity: Code Injection Attacks against Encrypted Virtual Machines. In 2021 IEEE Security and Privacy Workshops (SPW). 444–455.  https://doi.org/10.1109/SPW53761.2021.00063
  * Muralidhar et al. (2022) Rajeev Muralidhar, Renata Borovica-Gajic, and Rajkumar Buyya. 2022\.  Energy Efficient Computing Systems: Architectures, Abstractions and Modeling to Techniques and Standards.  Comput. Surveys (Jan. 2022).  https://doi.org/10.1145/3511094
  * Noureddine et al. (2015) Adel Noureddine, Romain Rouvoy, and Lionel Seinturier. 2015\.  Monitoring Energy Hotspots in Software.  Automated Software Engg. 22, 3 (sep 2015), 291–332.  https://doi.org/10.1007/s10515-014-0171-1
  * of Standards and Technology (2001) National Institute of Standards and Technology. 2001.  ADVANCED ENCRYPTION STANDARD (AES).  Technical Report. U.S. Department of Commerce, Washington, D.C.
  * Prouff and Rivain (2013) Emmanuel Prouff and Matthieu Rivain. 2013.  Masking against Side-Channel Attacks: A Formal Security Proof. In 2013 Annual International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT ’13). Berlin, Heidelberg, 142–159.
  * Rivain (2009) Matthieu Rivain. 2009\.  On the Exact Success Rate of Side Channel Analysis in the Gaussian Model.  Springer Berlin Heidelberg, Berlin, Heidelberg, 165–183.
  * Rotem et al. (2012) Efraim Rotem, Alon Naveh, Avinash Ananthakrishnan, Eliezer Weissmann, and Doron Rajwan. 2012\.  Power-Management Architecture of the Intel Microarchitecture Code-Named Sandy Bridge.  IEEE Micro 32, 2 (2012), 20–27.  https://doi.org/10.1109/MM.2012.12
  * Saab et al. (2016) Sami Saab, Pankaj Rohatgi, and Craig Hampel. 2016\.  Side-Channel Protections for Cryptographic Instruction Set Extensions.  Cryptology ePrint Archive, Paper 2016/700. (2016).  https://eprint.iacr.org/2016/700 https://eprint.iacr.org/2016/700.
  * Schneider and Moradi (2015) Tobias Schneider and Amir Moradi. 2015.  Leakage Assessment Methodology. In Cryptographic Hardware and Embedded Systems – CHES 2015. Springer Berlin Heidelberg, Berlin, Heidelberg, 495–513.
  * Schöne et al. (2021) Robert Schöne, Thomas Ilsche, Mario Bielert, Markus Velten, Markus Schmidl, and Daniel Hackenberg. 2021\.  Energy Efficiency Aspects of the AMD Zen 2 Architecture. In 2021 IEEE International Conference on Cluster Computing (CLUSTER). 562–571.  https://doi.org/10.1109/Cluster48925.2021.00087
  * Standaert (2017) François-Xavier Standaert. 2017\.  How (not) to Use Welch’s T-test in Side-Channel Security Evaluations.  Cryptology ePrint Archive, Paper 2017/138. (2017).  https://eprint.iacr.org/2017/138
  * Wang et al. (2022) Yingchen Wang, Riccardo Paccagnella, Elizabeth Tang He, Hovav Shacham, Christopher W. Fletcher, and David Kohlbrenner. 2022.  Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 679–697.
  * Wikichip (2021) Wikichip. 2021.  Precision Boost Overdrive (PBO) - AMD.  https://en.wikichip.org/wiki/amd/pbo. (2021).  Accessed: 2022-07-25.
  * Wu and Picek (2020) Lichao Wu and Stjepan Picek. 2020.  Remove some noise: On pre-processing of side-channel measurements with autoencoders.  IACR Transactions on Cryptographic Hardware and Embedded Systems (2020), 389–415.
  * Yan et al. (2015) Lin Yan, Yao Guo, Xiangqun Chen, and Hong Mei. 2015\.  A Study on Power Side Channels on Mobile Devices. In Proceedings of the 7th Asia-Pacific Symposium on Internetware. 30–38.