Overview

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:

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 few seconds.

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.

We also revisit two traditional physical side channels and demonstrate
their applicability to software running on PCs:

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.

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.

Q&A

Q1: What information is leaked?

This depends on the specific
computer hardware. We have tested numerous laptop computers, and found the
following:

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.

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.

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.

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 and peripherals?

There are still two attacks that require only proximity, not direct
contact:

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
paper.

New attack channels. The new channels discussed here are
physically different than the acoustic channel, and result in
different attack scenarios.

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 means.

Q8: How vulnerable is GnuPG now?

We have disclosed our attack to GnuPG developers under CVE-2013-4576
and CVE-2014-5270,
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
implementations?

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
GnuPG?

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.

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).

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 cache
attacks).

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 RSA ciphertexts:

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 keys,

Q14: How do you extract the secret key
bits?

This depends on the attack type. In the paper we present two types of
attacks.

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.

Acknowledgements

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
Shtibel, Ezra
Shaked and Oded
Smikt assisted in constructing and configuring the experimental
setup. Assa Naveh
assisted in various experiments, and offered valuable suggestions. Sharon Kessler provided
copious editorial advice. We thank Werner
Koch, lead developer of GnuPG, for the prompt response to our
disclosure and the productive collaboration in adding suitable
countermeasures. Erik Olson's
Baudline 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 Division in the Framework of "Science for Peace".