Get Your Hands Off My Laptop:
Physical Side-Channel Key-Extraction Attacks On PCs
| Daniel Genkin
| Itamar Pipman
|Technion and Tel Aviv
||Tel Aviv University
||Tel Aviv University
| assisted by numerous others
This work will be presented in CHES
2014 and published in its proceedings. An extended version is
available as PDF
(5.3MB) and on IACR
We demonstrated physical side-channel attacks on a popular software
implementation of RSA and ElGamal, running on laptop computers. Our
attacks use novel side channels and are based on the observation that the
"ground" electric potential in many computers fluctuates in a
computation-dependent way. An attacker can measure this signal by touching
exposed metal on the computer's chassis with a plain wire, or even with a
bare hand. The signal can also be measured at the remote end of Ethernet,
VGA or USB cables.
Through suitable cryptanalysis and signal processing, we have extracted
4096-bit RSA keys and 3072-bit ElGamal keys from laptops, via each of
these channels, as well as via power analysis and electromagnetic probing.
Despite the GHz-scale clock rate of the laptops and numerous noise
sources, the full attacks require a few seconds of measurements using
Medium Frequency signals (around 2 MHz), or one hour using Low Frequency
signals (up to 40 kHz).
We have extracted keys from laptops of various models, running GnuPG
(popular open source encryption software, implementing the OpenPGP
standard). The attacks exploit several side channels, enumerated below:
We also revisit two traditional physical side channels and demonstrate their
applicability to software running on PCs:
- Chassis potential. The electric potential
on the chassis of laptop computers fluctuates in reference to the mains
earth ground. This potential can be measured by a simple wire,
non-invasively touching a conductive part of the laptop (such as the
metal heatsink fins or shielding of USB, Ethernet, VGA, DisplayPort and
HDMI ports), and connected to a suitable amplifier and digitizer. The
chassis potential, thus measured, is affected by ongoing computation,
and our attacks exploit this to extract RSA and ElGamal keys, within a
Scenarios. The wire can be fixed in advance in a location where
the target laptop will be placed (e.g., a cluttered desk), or put in
contact with the laptop by a passerby.
- Far end of cable. When a cable is plugged
into one of the laptop's IO ports (such as USB, Ethernet, VGA,
DisplayPort and HDMI), the port's shield typically contacts a plug
shield, which in turn is connected to a conductive cable shield running
the length of the cable. Thus, one can measure the chassis potential
from the far side of cables connected to the aforementioned
ports. Ethernet cables, for example, often span long distances, across
and between building floors. An attacker who gains access to the far
side of the cable, or taps the shield along the way, can measure the
approximate chassis potential.
Scenarios. A simple voltage measurement device, perhaps located
in the cabinet or server room to which the cable leads, could capture
the leakage. This is hard to check, since Ethernet wiring and
projectors' VGA cables are often hidden out of sight and cannot easily
be tracked by the user.
- Human touch. The attacker can measure the
chassis potential by merely touching a conductive part of the laptop
chassis with his hand, while surreptitiously measuring his own body
potential relative to the ground potential of the room. (This attack is
especially effective in hot weather, since sweaty fingers offer lower
electric resistance.) If good contact cannot be made using exposed metal
parts of the chassis, a metallic pen can be used to make good contact
with the laptop's heatsink fins.
Scenarios. The attacker positions himself in physical proximity
to the target laptop and touches it with his bare hand or a conducting
pen. Surreptitiously, the attacker carries the requisite equipment for
measuring his body potential relative to some nearby grounded object. In
the non-adaptive attack, a few seconds'
contact will suffice; in the adaptive attack,
1 key bit can be extracted approximately every 4 seconds.
In a recent paper, we also demonstrated attacks using acoustic
emanations, i.e., using microphones to record the sound made by
computers' electronics and deducing the secret keys.
- Electromagnetic (EM). We performed key
extraction by measuring the induced EM emanations, using an antenna
(near-field probe) placed near the laptop.
Scenarios. Electromagnetic probes are easily hidden in
nearby objects. A glove, containing a concealed probe loop and hovering
over the target laptop, would unveil its key within seconds.
- Power. Likewise, we extracted keys by
measuring the electric current draw on the laptop's power supply. Our
attack works even though PCs use complex switching power supplies, which
partially decouple the power source from the CPU load, and moreover
employ large capacitors, chokes, and shields for electromagnetic
compatibility (EMC) compliance — all of which attenuate and disrupt the
signals sought in traditional power analysis.
Scenarios. A public charging station can be easily augmented
with a current meter, logger, and transmitter. Even a regular power
supply "brick" can be similarly augmented, and such laptop power
supplies are often shared, offered to guests, or left unattended.
Q1: What information is leaked?
This depends on the specific
computer hardware. We have tested numerous laptop computers, and found the
A good way to visualize the signal is as a spectrogram, which plots the
measured power as a function of time and frequency. For example, in the
following spectrogram, time runs vertically (spanning 10 seconds) and
frequency runs horizontally (spanning 0-2.3 MHz). During this time,
the CPU performed loops of different operations (multiplications, additions,
memory accesses, etc.). One can easily discern when the CPU is conducting
each operation, due to the different spectral signatures.
- In almost all machines, it is possible to distinguish an idle CPU
(x86 "HLT") from a busy CPU.
- On many machines, it is moreover possible to distinguish different
patterns of CPU operations and different programs.
- Using GnuPG as our study case, we
can, on some machines:
- distinguish between the spectral signatures of different RSA
secret keys (signing or decryption), and
- fully extract decryption keys, by measuring the laptop's chassis
potential during decryption of a chosen ciphertext.
Q2: Why does this happen?
The electric potential on a laptop computer's chassis (metal panels, shields
and ports) is ideally equal to that of the mains earth ground potential, but
in reality it fluctuates greatly. Even when the laptop is grounded (via its
power supply or via shielded cables such as Ethernet, USB or VGA), there is
non-negligible impedance between the grounding point(s) and other points in
the chassis. Due to currents and electromagnetic fields inside the computer,
voltages of large magnitude develop across this impedance
(often 10mV RMS or more, after filtering out the 50 or 60 Hz mains
frequency). This is the voltage we measure.
Q3: Does the attack require special equipment?
While the attack is most
effective using professional lab equipment, a regular mobile phone is
sometimes good enough. For example, we have used a mobile phone to measure
the key-dependent chassis potential from the far side of a 10m Ethernet
cable, as shown here:
The above picture shows a mobile phone (Samsung Galaxy S II) being used to
measure the chassis potential of the laptop from the far side of a 10 meter
long Ethernet cable (blue). An alligator clip connected to a plain wire
(green) taps the shield of the Ethernet cable where it connects to an
Ethernet switch. The signal passes, through a simple passive filter, into
the microphone/earphone jack of the phone, where it is amplified and
digitized. The phone itself is grounded to mains earth via its USB port. It
is possible to perform the adaptive attack using this setup.
Q4: What if I can't physically touch the computer or any of its cables
There are still two attacks that require only proximity, not direct
- Electromagnetic emanations, measured via an antenna, convey
essentially the same leakage and (as we show in the above
paper) can be used for key extraction.
- Acoustic emanations (sound), measured via a microphone, can
also be used to extract keys, as we showed in a previous
- New attack channels. The new channels discussed here are
physically different than the acoustic channel, and result in different
- New cryptographic technique. In addition to the bit-by-bit
adaptive attack presented in the previous paper, which requires
thousands of decryption operations for key extraction, we employ a
new non-adaptive attack that recovers the complete key using the leakage
obtained by just a few decryption operations. This reduces the attack
time from an hour to a few seconds.
Q6: Can an attacker use power analysis instead?
Yes, power analysis (measuring the current drawn from the laptop's DC
power supply) is another way to perform our low-bandwidth attack.
Traditional power analysis would measure power consumption at a frequency
comparable to the CPU's clockrate (a few GHz), and is foiled by dampening
emanations at these frequencies. Our attack extracts the key using much
lower bandwidth (a few kHz to a few MHz, depending on settings and
duration). Our attack is also more resilient to filtering and noise.
Q7: How can low-frequency (kHz) leakage provide
useful information about a much faster (GHz) computation?
This is the key idea behind our technique. Individual CPU operations are too
fast for our measurement equipment to pick up, but long operations (e.g.,
modular exponentiation in RSA) can create a characteristic (and detectable)
spectral signature over many milliseconds. Using a chosen-ciphertext, we are
able to use the algorithm's own code to amplify its own
key-leakage, creating very drastic changes, detectable even by low-bandwidth
Q8: How vulnerable is GnuPG now?
We have disclosed our attack to GnuPG developers under CVE-2013-4576
suggested suitable countermeasures, and worked with the developers to test
them. New versions of GnuPG 1.x and of libgcrypt (which underlies GnuPG
2.x), containing these countermeasures and resistant to the key-extraction
attack described here, were released concurrently with the first public
posting of these results.
GnuPG version 1.4.16 onwards, and libgcrypt 1.6.0 onwards, resist the
key-extraction attack described here. Some of the effects we discovered
(including RSA key distinguishability) remain present.
Q9: How vulnerable are other algorithms and cryptographic
This is an open research question. Our attack requires careful cryptographic
analysis of the implementation, which so far has been conducted only for the
GnuPG 1.x implementation of RSA. Implementations using ciphertext blinding
(a common side channel countermeasure) appear less vulnerable.
Q10: Is there a realistic way to perform a chosen-ciphertext attack on
We found a way to cause GnuPG to automatically decrypt ciphertexts chosen
by the attacker. The idea is to use encrypted e-mail messages following
the OpenPGP and PGP/MIME
protocols. For example, Enigmail
(a popular plugin to the Thunderbird e-mail client) automatically decrypts
incoming e-mail (for notification purposes) using GnuPG. An attacker can
e-mail suitably-crafted messages to the victims, wait until they reach the
target computer, and observe the target's chassis potential during their
decryption (as shown above), thereby closing the attack loop.
Q11: What countermeasures are available?
Physical mitigation techniques include Faraday cages (against EM attacks),
insulating enclosures (against chassis and touch attacks), and photoelectric
decoupling or fiberoptic connections (against "far end of cable" attacks).
However, inexpensive protection of consumer-grade PCs appears difficult,
especially for the chassis channel.
Alternatively, the cryptographic software can be changed, and algorithmic
techniques employed to render the emanations less useful to the attacker.
These techniques ensure that the rough-scale behavior of the algorithm is
independent of the inputs it receives; they usually carry some performance
penalty, but are often used in any case to thwart other side-channel
attacks. This is what we helped implement in GnuPG (see Q8).
Q12: Why software countermeasures? Isn't it the hardware's
responsibility to avoid physical leakage?
It is tempting to enforce proper layering, and decree that preventing
physical leakage is the responsibility of the physical hardware.
Unfortunately, such low-level leakage prevention is often impractical due
to the very bad cost vs. security tradeoff: (1) any leakage remnants can
often be amplified by suitable manipulation at the higher levels, as we
indeed do in our chosen-ciphertext attack; (2) low-level mechanisms try to
protect all computation, even though most of it is insensitive or does not
induce easily-exploitable leakage; and (3) leakage is often an inevitable
side effect of essential performance-enhancing mechanisms (e.g., consider
Application-layer, algorithm-specific mitigation, in contrast, prevents
the (inevitably) leaked signal from bearing any useful information. It is
often cheap and effective, and most cryptographic software (including
GnuPG and libgcrypt) already includes various sorts of mitigation, both
through explicit code and through choice of algorithms. In fact, the
side-channel resistance of software implementations is nowadays a major
concern in the choice of cryptographic primitives, and was an explicit
evaluation criterion in NIST's AES and SHA-3 competitions.
Q13: What does the RSA leakage look like?
Here is an example of a spectrogram (which plots the measured power as a
function of time and frequency) for a recording of GnuPG decrypting several
In this spectrogram, the horizontal axis (frequency) spans ranges from 1.9
MHz to 2.6 MHz, and the vertical axis (time) spans 1.7 seconds. Each yellow
arrow points to the middle of a GnuPG RSA decryption. It is easy to see
where each decryption starts and ends. Notice the change in the middle of
each decryption operation, spanning several frequency bands. This is
because, internally, each GnuPG RSA decryption first exponentiates modulo
the secret prime p and then modulo the secret prime q
, and we can actually see the difference between these stages.
Moreover, each of these pairs looks different because each decryption uses a
different key. So in this example, by simply observing the chassis potential
during decryption operations, we can distinguish between different secret
Q14: How do you extract the secret key bits?
This depends on the attack type. In the paper we present two types of
- Non-Adaptive attack. Here, we are able to extract all the
bits from the leakage obtained by measuring the chassis potential during
just a few decyption operations using a single ciphertext. The attacker
generates a suitable ciphertext and triggers decryptions of it while
analyzing the chassis potential of the target. The picture below is a
typical result of such a recording (after signal processing).
While this already allows the extraction of some key-bits, notice the
interrupt (marked by a green arrow), which "hides" some of the key bits.
A few additional recordings are needed in order to recover all the bits.
- Adaptive attack. This technique (similar to the one used in acoustic cryptanalysis)
finds the secret key bits one by one, sequentially. For each bit, the
attacker crafts a ciphertext of a special form, in which the leakage
depends specifically on the value of that bit. The attacker
then triggers a decryption of that chosen ciphertext, records the
chassis potential, and analyzes it. The following demonstrates a typical
stage of this attack, focusing on a single secret key bit. If this bit
is 0, then decryption of the chosen ciphertext will look like the
left-side spectrogram (with a strong component at 26.5 kHz). If the
secret bit is 1, the decryption will look like the right-side
spectrogram (where the strong component is at 31.5 kHz).
Using automated signal classification, the attack distinguishes these
cases and deduces the secret key bit.
We are indebted to Adi Shamir for insightful
discussions and suggestions, and to Lev Pachmanov for writing much of the
software setup used in our experiments. Avi
, Ezra Shaked
and Oded Smikt
in constructing and configuring the experimental setup. Assa
assisted in various experiments, and offered valuable
suggestions. Sharon Kessler
provided copious editorial advice. We thank Werner
, lead developer of GnuPG, for the prompt response to our
disclosure and the productive collaboration in adding suitable
countermeasures. Erik Olson
signal analysis software
was used for some of the analysis. We thank numerous volunteers for access
to test-target machines.
This work was sponsored by the Check
Point Institute for Information Security
; by the European
Union's Tenth Framework Programme
(FP10/2010-2016) under grant
agreement 259426 ERC-CaC; by the Leona M. & Harry B. Helmsley
Charitable Trust; by the Israeli
Ministry of Science and Technology
; by the Israeli
Centers of Research Excellence I-CORE Program
(center 4/11); and
by NATO's Public Diplomacy
in the Framework of "Science for Peace".