Frequency Throttling Side Channel Software Guidance for Cryptography Implementations

When computing systems (such as CPUs, GPUs, SoCs, etc) process data, transistors are switched on and off depending on the data being processed, resulting in differing energy consumption. Consequently, running the same workload with different data may change the CPU’s power consumption. In most modern computing systems, the system power management unit routinely monitors power consumption. When power information is accessible to software, this information may potentially be used for power side channel attacks. This physical property may lead to malicious actors correlating the system’s reported power consumption with possible secret data being processed on the system. Refer to Intel’s Running Average Power Limit Energy Reporting technical article for more details on Intel’s mitigations for this scenario.

On the other hand, the system power management unit may also compare power consumption against internal power management¹ reactive limits. If any of the limits are exceeded, the power management algorithm will react to it and take actions to reduce power consumption to satisfy the constraints. Examples of such actions include reducing frequencies of components, parking components to idle, reducing duty cycles, and many others. In some scenarios, those actions may result in data-dependent behaviors that are observable by an adversary.

Reactive Power Limit Control Behaviors

Power side channels can be observed by different signals or by reactive power limits control. This section uses two example behaviors: CPU frequency throttling and the Hardware Feedback Interface (HFI) capabilities, to explain the power side channel in detail. 

CPU Frequency Throttling

One of the most common reactive power limits control actions taken by Intel’s power management algorithm is CPU frequency throttling. When the power management algorithm decides to perform CPU frequency throttling, it reduces the maximum allowed frequency of the CPUs. In this process, there is an inverse correlation between the average throttling frequency and the power consumption¹ before frequency throttling: a workload with higher power consumption before throttling tends to run at lower average throttled frequency, and vice versa. Furthermore, since the power consumption of a workload may be correlated with the data being processed, the throttling frequency may also be correlated with the data, which becomes a frequency side channel. The CPU frequency change also causes a difference in the execution time of the workload and results in a timing side channel. 

Figure 1 explains the side channel using an illustrative example. Figure 1(a) shows the same program executed twice with the input data 1 (in blue) and data 2 (in orange), respectively. Assuming the program is a constant-cycle implementation², the number of cycles with data 1 and data 2 are the same (c1=c2). On the other hand, power consumption of processing data 1 and data 2 might be different. Without loss of generality, we assume processing data 1 consumes higher power (p1) compared to that of data 2 (p2). When neither p1 nor p2 exceeds the default power limit (or any other reactive limit), there is no throttling, and the frequency stays at f_default when the program is running. As a result, the execution time of the program is the same with either data 1 or data 2. 

Assuming the total power consumption exceeds the power limit due to increased system power consumption (such as when stressor code starts to run in parallel with the function) or a reduction of the power limit, frequency throttling occurs. As shown in Figure 1(c), since processing data 1 consumes more power than data 2, the averaged throttled frequency of data 1 (freq₁) will become lower than that of data 2 (freq₂) to ensure the power limit is satisfied. Of course, both throttling frequencies are lower than f_default. Therefore, even if the number of execution cycles of the program is still data-invariant, the throttling frequency, and hence execution time, becomes data-variant. An attacker may utilize this side channel to extract secret data (such as cryptographic keys) from a constant-time cryptography implementation, since a typical constant-time implementation ensures only constant-cycle execution, and data-dependent variations in CPU frequency will result in data-dependent code execution time. This side channel is discussed in the research papers such as [2] and [3] in the References section.

Hardware Feedback Interface (HFI) Capabilities

Some Intel processors support Hardware Feedback Interface (HFI) feature, which provides guidance to the Operating System (OS) scheduler to perform workload scheduling across different cores. Under certain circumstances, when power limits are reached, the power management algorithm will update the content of HFI, suggesting OS to avoid using some cores. In this case, information related to the HFI content might be correlated with the power consumption of the workload. Researchers from Carnegie Mellon University published a research paper [4] discussing this side-channel, which is also covered by this guidance.

Power Management Reactive Limits

Intel® systems have several reactive limits related to power management, such as Running Average Power Limit (RAPL) and Voltage Regulator Thermal Design Current Limit (VR-TDC).

Running Average Power Limit (RAPL)

RAPL is a feature supported by Intel power management architecture to cap the power consumption on the system. Intel currently provides multiple power limit capabilities, including package-level power limits and platform-level power limits. Ring 0 software can configure both the running average window and the power limit of each capability through model specific registers (MSRs) such as, MSR_PKG_POWER_LIMIT for package-level power limit. Refer to Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 Section 15.10 “Platform Specific Power Management Support” for more details.

Voltage Regulator Thermal Design Current Limit (VR-TDC)

VR-TDC is a power management feature supported by Intel power management architecture. The feature introduces a current limit, naturally specified in amperes, that is to be maintained to preserve the electrical constraints on properties of the voltage regulator (VR). Generally, the control algorithm monitors the Exponential Moving Average (EMA) current, which is also measured in amperes, by reading current measurements from the VR. As with other control algorithms, this algorithm controls the power budget based on a given time window. 

Related Issues

Intel released microcode updates (MCUs) in IPU 2020.2 and IPU 2021.2 responding to Running Average Power Limit energy reporting vulnerabilities (CVE-2020-8694 and CVE-2020-8695). None of the MCUs are meant to mitigate the reactive power limits control side channel vulnerability. In the Software Guidance for Cryptographic Implementations section of this article, Intel provides software guidance for mitigating reactive power limits control side channels against cryptographic implementations. Intel recommends cryptographic library and application developers refer to the suggested methods in this article to assess and harden their code against the side channel known as "Hertzbleed".

Software Guidance for Cryptographic Implementations

This section provides cryptographic application and library developers³ with guidance to assess the risk and reduce the impact of power management reactive control side channels on cryptographic implementations. Remember that the root cause of the power management reactive control side channel is the power side channel, and the mitigation of it has been researched exhaustively. This document is not intended to provide comprehensive solutions to mitigate the power management reactive control side channel for all cryptography implementations, but instead provides recommendations to enable cryptography developers to evaluate the risks and to help harden their software implementations against this side channel. Intel recommends that cryptographic implementations follow existing guidance for developing constant-cycle code, as described in Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations [5], and the Data Operand Independent Timing Instruction Set Architecture Guidance.

Conditions of the Attack

Cryptographic implementations may be vulnerable to power management reactive control side channels when all the following conditions are met. If one or more of these listed prerequisites is not satisfied, the cryptography implementation should not be impacted by this type of side channel.

Check the list of conditions below to assess your implementation’s risk based on the nature of the implementation and your threat model. 

The Cryptographic Implementation is Vulnerable to Power Side Channel Attack

The power side channel is the fundamental root cause of the power management reactive control side channel. An implementation that is vulnerable to the power management reactive control side channel needs to satisfy all the prerequisites of physical power side channel attacks, except for the physical access capability to measure power. The prerequisites for a malicious actor to exploit the physical power side channel include, but are not limited to:

• The ability to repeatedly initiate cryptographic operations with the same secret key to collect enough data. 
• For block ciphers, the ability to read input/output or inter-round state of the block cipher primitives. Note that the input/output is not necessarily the plaintext or ciphertext. One example is the counter (CTR) mode of block cipher, where the input to the block cipher is the concatenation of the nonce and counter.

Ability to Ensure Victim Execution hits the CPU’s Reactive Limits

For the power management throttling algorithm to generate data-dependent behaviors, a reactive limit needs to be hit while the victim workload is running. There are several techniques that an attacker may take to meet this necessary condition.

• An attacker may run multiple instances of the same victim workload (using the same secret data) on multiple cores to increase power consumption of the package (to hit the limit) and increase Signal-to-Noise Ratio (SNR)³.
• An attacker may run stressor workloads in parallel with the victim workload to increase package power consumption. 
• An attacker with ring 0 privilege can reduce the limits through reactive limit configuration interfaces (for example, MSRs) to ensure the victim workload hits the limit.

Ability to Monitor Data Change or Related CPU Behaviors with Sufficient Resolution

The attacker needs to be able to sample CPU frequency while the victim workload is running, or else observe the execution time of the victim workload with sufficient resolution to identify data-dependent differences in the measured information. 

Software Implementation

The following guidance can help developers mitigate the reactive power limits control side channel. Additionally, this guidance can be used as a defense-in-depth mechanism even when not all conditions for the reactive power limits control side channel are met.

Applying Effective Solutions Against Power Side Channel

Most of the proven software-based countermeasures against power side channels on cryptographic primitives will also be effective against the reactive power limits control side channel. For example, mitigations that reduce power SNR of single instructions are effective for both the physical power side channel and the reactive power limits control side channel, since the SNR of average power consumption during the running average window is also reduced. Other techniques, such as software-based masking [6] [7], should be also effective against reactive power limits control side channels. 

Note that countermeasures that randomize the execution order of instructions, while being effective in making trace alignment and identification of point of interest harder for physical power side channel, are less effective at mitigating the power management throttling side channel. This is because reordering instructions at the cycle granularity is less likely to impact average power consumption during the averaging time window of milliseconds or longer.

For cryptographic applications, an example of a generic countermeasure against power side channel is key refresh. One of the necessary conditions for power side channels is the ability to repeatedly kick off cryptographic operations with the same sensitive key. If the secret key is refreshed before enough traces can be collected, it will be harder for the attacker to fully deduce the secret. Key refresh frequency may be based on timing (for example, refresh per several hours) or data volume (for example, the volume of data being encrypted with the same key). If the implementor is uncertain of which threshold to use, the lowest threshold that meets performance/design requirements should be selected. It should be noted that the practicality of key refresh depends on the specific cryptographic use case (for example, key refresh is typically not applicable to disk encryption).

Avoiding Unnecessary Exposure of Reactive Limit Configuration Interfaces

As stated in the Conditions of the Attack section, if an adversary has access to certain hardware interfaces (for example, MSR_PKG_POWER_LIMIT), they may configure and reduce the reactive limits to make it easier for the victim workload to trigger reactive power limit throttling. To reduce the attack surface, privileged software (for example, hypervisor or ring-0 software) that has access to these interfaces should avoid unnecessarily exposing those interfaces to untrusted entities (for example guest VMs or ring-3 software). If there is a business need to expose these interfaces, the designers of the privileged software should be aware of the potential security implication. 

Restricting Correlation of Observable Behaviors

One common countermeasure against side channel attacks, to restrict the correlation between the observed behavior and secret data, is to jam the channel with noise to deter the attacker from deducing the secret. Ideally, the noise should be injected into the power consumption of the system. If certain derived behavior (such as timing differences) due to this side channel is known as the main or sole channel the adversary may observe, adding noise to this channel to reduce SNR would also increae the bar for the adversary.  

One method to jam the channel with noise is to leverage the inherent noise during cryptographic application calls. The cryptographic library provider or cryptographic application provider may restrict the maximum size of the plaintext/ciphertext allowed per API invocation, so that more invocations of the API are needed to process the same amount of data, which introduces more inherent noise. 

Besides that, a cryptography implementor may proactively inject random noise into the 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 from the secret data using cryptographic functions. For example, timing variations 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 variance of the frequency transition. To help ensure every frequency change is impacted by noise, Intel recommends injecting some noise during the running time window of the reactive limits that may be leveraged by an attacker. One possible way to balance the trade-offs between security and performance is to combine this scheme with the key refresh countermeasure described in Applying Effective Solutions Against Power Side Channel section to increase the time needed to perform a successful attack to a key lifetime that is acceptable for your implementation.

Steps to Take to Protect Your Code

Cryptographic library application providers are advised to take the following steps to assess and protect their code:

1. Assess whether the implementation is impacted based on the threat model and the necessary conditions of the attack.
2. If the cryptographic implementation is impacted and mitigation is needed:
   1. Apply generic countermeasures against the power side channel on the cryptography primitive level (for example, masking) or cryptography application level (for example, key refresh).
   2. Restrict correlation between power consumption or derived behaviors. Examples include restricting maximum input data size per invocation and injecting random delay noise.
3. For privileged software or hypervisors, avoid unnecessary exposure of reactive limit configuration interfaces to untrusted entities.

Additional Notes

Cryptography developers need to be aware of compiler optimizations and their effects on generated code. Compilers with optimizers will look for ways to make the code faster, and sometimes the changes introduced by compilers can be quite unexpected. For any code that you write—whether it is C or hand-coded assembly—you must verify it in the environment where you expect to use it. Developers should weigh the trade-off between security and performance/QoS when considering solutions. The developers may provide options for cryptographic application users to opt-in/opt-out of the mitigations.

References

1. Intel's Running Average Power Limit Energy Reporting.
2. C. Liu, A. Chakraborty, N. Chawla and N. Roggel, "Frequency Throttling Side-Channel Attack," in 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022. 
3.  Y. Wang, R. Paccagnella, E. T. He, H. Shacham, C. W. Fletcher and D. Kohlbrenner, "Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86," in 31st USENIX Security Symposium, 2022. 
4. I. Chun, I. Siu and R. Paccagnella, "Scheduled Disclosure: Turning Power Into Timing Without Frequency Scaling," in 46th IEEE Symposium on Security and Privacy, 2025. 
5. Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.
6. S. Mangard, E. Oswald and T. Popp, Power Analysis Attacks: Revealing the Secrets of Smart Cards. 
7. E. Prouff and M. Rivain, "Masking against Side-Channel Attacks: a Formal Security Proof," in Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2013. 
    

Footnotes

1. For simplicity, in this document, we use power to indicate any electrical parameter (such as thermal, current, etc.) that exhibits similar behavior.
2. For developers implementing cryptographic algorithms, it is recommended to select instructions whose execution time is data-independent in order to mitigate timing side channels due to cycle differences. Intel has provided guidance for developing constant time/constant cycle code in Intel’s Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations.
3. The definition of application is the software that utilizes cryptographic library primitives and owns/manages cryptography keys. The definition of a library is the software that provides cryptography primitives but does not own the key. Instead, the cryptographic library relies on the application to provide the cryptography key to use.
4. Here, signal is the secret-correlated power consumption, and noise is the secret-independent power consumption.