
RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis - longwave
http://www.cs.tau.ac.il/~tromer/acoustic/
======
wrongc0ntinent
The single coolest thing in the paper (other than Shamir's name): "On many
laptops (e.g., most Lenovo ThinkPad models), the chassis potential can be
easily reached by a human hand, through metal connectors and conductive
coating on metal surfaces. Thus, an attacker can measure the chassis potential
by merely touching the laptop chassis with his hand. Surreptitiously, the
attacker can simultaneously measure his own body potential relative to the
room’s ground potential, e.g., by having a concealed differential probe
touching both his body and some nearby conductive grounded surface in the
room. Perhaps surprisingly, even this circuitous measurement offers sufficient
signal-to-noise ratio for the key extraction attack."

~~~
dfox
I wonder whether this is specific to laptops (running from battery or
otherwise not grounded) or if it also works with properly grounded desktop
computers.

My HP notebook from ~2000 had measurable (although very high impedance) 110V
AC between exposed metal parts and PE in wall outlet when connected to
charger. Modern thinkpads (and probably all non-Apple laptops sold in Europe)
does not seem to have this problem as ground is connected through in charger,
not only AC coupled to both hot and neutral.

~~~
pilsetnieks
Macbooks can be grounded, too. The round metal thing that's holding the plug
in place also serves as a connection for ground. It is moot if you're using
the small plug which doesn't have ground but if you connect the cable instead
of the plug, or use a UK plug, the computer is properly grounded.

------
sillysaurus2
Playing loud music when encrypting/decrypting/typing in your password will
defend against acoustic attacks, right?

This other type of attack, however, isn't so easily guarded against:

 _Beyond acoustics, we demonstrate that a similar low-bandwidth attack can be
performed by measuring the electric potential of a computer chassis. A
suitably-equipped attacker need merely touch the target computer with his bare
hand, or get the required leakage information from the ground wires at the
remote end of VGA, USB or Ethernet cables._

This serves as a reminder that it's pretty much impossible to defend against
an attacker that has physical access to your box.

~~~
hawkharris
_Playing loud music when encrypting /decrypting/typing in your password will
defend against acoustic attacks, right?_

I recommend "Wrecking Ball" by Miley Cyrus. The strength of the attacker's
cryptanalysis will be moot because no one will go near you.

~~~
mathgladiator
or... it may increase people's interest in you, you know, for national
security.

~~~
hawkharris
Well, by Bradley Manning's account, he listened to Lady Gaga while leaking
classified military documents, so maybe hit pop songs are not as innocent as
they seem. :)

------
r0muald
Important stuff:

> Q9 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
> resisting our current key-extraction attack, were released concurrently with
> the first public posting of these results. Some of the effects we found
> (including RSA key distinguishability) remain present.

------
kken
This is really impressive work. After skimming through the detailed paper it
looks as if they are not picking up sound emitted from the CPU itself, but
from the switching power supply circuit.

The frequency variation is caused by load differences. So they are in fact
doing an indirect power analysis. A switching power supply will always change
frequency as a reaction to variations in supply current, this is inherent to
its design. I also believe that it will be very difficult to "muffle" all the
inductors and capacitors as they are subjected to very high pulse loads.
Magnetics will always find a way to emit sound...

It's interesting to note that the biggest difference seems to be between
register and memory instructions. This seems reasonable as memory instruction
may, in the worst case, require powering the external bus, which is very power
hungry. This will only get worse in future CPUs, as more and more clock gating
is introduced.

So, I guess some countermeasures could be:

\- If the CPU supports SMT or HT, load the other cores with a thread accessing
random memory positions.

\- Optimize the RSA code so that it's memory access and runtime pattern does
not depend on the key or clean text.

\- Try to localize the RSA code as much as possible to reduce memory accesses.
If memory access is required, do it all at once, for example by swapping
entire cache pages.

Some of these are highly CPU dependent.

------
__alexs
This is the patch they used to mitigate it afaict.

[http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=libgcrypt.git;a=co...](http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=dec048b2ec79271a2f4405be5b87b1e768b3f1a9)

------
Sami_Lehtinen
Nobody mentioned TEMPEST yet in this comment thread. It's old (60s) but very
interesting stuff.
[https://en.wikipedia.org/wiki/Tempest_%28codename%29](https://en.wikipedia.org/wiki/Tempest_%28codename%29)
It includes acoustical leaks as one side channel. Also see:
[http://www.nsa.gov/public_info/_files/cryptologic_spectrum/t...](http://www.nsa.gov/public_info/_files/cryptologic_spectrum/tempest.pdf)
It's cool that they were able to demonstrate it that well.

~~~
hardwaresofton
Came in here to make this exact comment -- the amount of things looked into as
ways to leak secrets was insane, even going as far as detecting screen
radiation IIRC.

~~~
midas007
Check out this researcher's papers:
[http://www.cl.cam.ac.uk/~mgk25/](http://www.cl.cam.ac.uk/~mgk25/) esp.
"Optical Time-Domain Eavesdropping Risks of CRT Displays"

------
Lagged2Death
_Using multiple cores turns out to help the attack (by shifting down the
signal frequencies)._

I don't understand how this would be, maybe because I don't understand what
they mean by "using multiple cores."

You'd think that running a decoy thread on another core would mask things
pretty effectively.

~~~
p4bl0
Disclaimer: I never worked with the sound side-channel, so maybe what I'm
going to say is not entirely true, but the general idea should be right.

Actually I think the job of the other core would be more difficult than just
doing random noises to _mask_ the noise from the actual secret computation.
Simply doing random computations (and thus, random noises) of the other core
is not effective since random noise would "easily" be canceled using
statistical tools (for instance, looking at the variance of the data instead
of looking at it directly will already reduce some type of noises).

What would be more effective would be to _balance_ the noise for instance,
maybe running the same computation with opposite data would balance it more
effectively. To picture what I'm saying better, here is a _completely
fanciful_ example (just to provide an idea). Imagine that during the RSA
exponentiation (where the private key is exposed), the operation that is done
when the bit of the secret key is 1 makes the sound "s_s_" and when it is 0
the sound is "_p_k". If you do the the same computation as the secret one on
the other core exactly at the same time, but with the opposite secret key,
then whatever the key is the attacker will always ear "spsk" at each clock
cycle. And that will be harder to attack than random noises (but is also more
difficult to achieve, of course).

That said, I don't know why the use of multiple cores would help the attack
(but I didn't read the paper, just a few sample of the linked web page).

------
BrownBuffalo
What's interesting are old school spy acounstic methods.
[http://en.wikipedia.org/wiki/Laser_microphone](http://en.wikipedia.org/wiki/Laser_microphone)
<\-- great primer. This played out in micro surface vibration in a cup of
coffee in the movie Eagle Eye (terrible movie btw). Either way, kind of a neat
way to spy on embassy windows from a far w/o even having to be in the room. A
little off topic was the KGB's bugging a government office with passive radio
transmission - virtually undetectable
[http://en.wikipedia.org/wiki/Thing_(listening_device)](http://en.wikipedia.org/wiki/Thing_\(listening_device\))
This stuff is so damn cool. :)

------
bhouston
Just to be clear, I believe this is from 2004.

~~~
longwave
This was originally presented was in 2004, but since then has been refined in
a number of ways. The detailed paper that includes the full key extraction
attack was only released today, coinciding with the GnuPG security update that
mitigates against the attack.

~~~
gwern
It took 9 years to fix GPG?

~~~
edwintorok
GnuPG 2.x wasn't vulnerable, just the old 1.x:
[http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/00033...](http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/000337.html) "GnuPG 1.4.16 avoids this attack by employing RSA
blinding during decryption. GnuPG 2.x and current Gpg4win versions make use of
Libgcrypt which employs RSA blinding anyway and are thus not vulnerable."

~~~
tripzilch
RSA blinding seems to protect against timing attacks, how does RSA blinding
protect against this acoustic attack?

------
cmansley
Random comment: Could similar attacks be used to extract the private key for
Bitcoin accounts?

~~~
sneak
These attacks are specifically for the operations involved in repeated use of
long-term RSA keys, and Bitcoin uses ECDSA keys a relatively small number of
times, so the attacks would be materially different.

However, I would not bet against the fact that your machine outputs
"compromising emanations" (be they acoustic or RF or otherwise) leaking _some_
information about your bitcoin keys.

There is less opportunity to execute such an attack in the bitcoin universe,
though, as bitcoin-qt doesn't reuse keys that much. (When you send a payment,
the "change" difference is sent to a new key.)

It's something to think about, but the attack surface is a lot smaller.
Perhaps there's something specific in the ECDSA algorithm that may make it
easier or harder? I don't have the requisite mathematical understanding of
elliptic curves to know how they're executed in-CPU.

------
bsaul
I've read the linked document, but this feels like magic to me. Is the general
idea something like : i can hear the CPU is doing 10 additions, then 20
substractions, twenty times in a row, so i can tell by knowing the algorithm
used that the CPU is computing a public key and that it must be between 1
billion and 1.5 billion ?

~~~
aidenn0
No, more like the CPU will, in some cases, need to do more work if the key is
X and less work if the key is Y, and we specially craft our plain-text to have
many X/Y pairs as possible, so that we can hear the capacitors working harder
when decrypting.

------
X4
Without taking party, I am deeply impressed at an increasing rate and with
honest respect to the ingenuity of the research that's coming from Tel Aviv,
Israel and from Switzerland. There is no other country except the USA which
makes such leaps in technological progress. That's my honest image of the
research. I'm personally reading many of their publications and from various
other journals too.

------
eyeareque
If three academic types can come up with this, just imagine what the NSA or
other foreign intelligence groups can find with a budget like they have.

Interesting for sure.

------
chromano
If that attack is available for us to know, I wonder what can possibly be
happening inside NSA?

I even wonder how these big guys/heroes like Julian and Snowden feel when they
find out about it. I mean, maybe they just don't care about the stuff they
have being accessed without their consent, it is supposed to be released
anyways, but what about their conversations that are supposed to be highly
confidential?

------
abvdasker
When I started reading I thought this must be a joke. As a dev with what I
like to think is a solid understanding of computer hardware I don't often
think of new tech as spooky/sci-fi-esque, but this is so unbelievably cool. I
have no words.

------
Sami_Lehtinen
Fixed GnuPG 1.4.16 version released: [http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/00033...](http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/000337.html)

------
artificialidiot
A good enough solution might be using appliances designed with older cpus with
little to no power management features but it is only practical for high
stakes stuff like military comms I guess.

------
oakwhiz
Some motherboards have programmable/adjustable VRMs. I wonder if the settings
can be changed to mitigate the threat.

------
midas007
I remember being able to hear a program run on an HP 32S (RPN) by placing it
up to my ear, so this isn't surprising.

------
gwu78
What about computers located in the datacenter, next to other people's
computers?

------
jgalt212
I really want to call B.S. on most of their claims, but I withhold any
judgement until there is a live demo performed. Have they announced a
timetable for a live demo?

~~~
p4bl0
Just go to any conference about cryptosystems' implementation security (like
CHES), or to any exhibition on this topic (like CARTES) and you will be
bluffed by demos of side-channel attacks, which are very real.

------
afsina
This sounds like BS, smells like BS.. But then again he is Shamir.. Still I
think it is BS

------
drakaal
This is a really well written fake.

Use some common sense.

Are you only doing one thing on your computer? No.

Does your Memory vibrate when the data is stored? No.

Can data be transferred via acoustics over a 2 conductor 16 gauge wire at the
speeds memory is accessed or is sent to the CPU? No.

Think of something you have heard "hum". Is the noise pattern of your Amp and
another the same if the "hum is anything other than 60hz? No. Because
manufacturing tolerances are not such that the flaws are the same.

This is really great FUD. Likely designed to get People to think that they are
constantly at risk, and have the CIA and FBI spend billions buying acoustic
shields for their computers.

If this is real. And does work, fine, just run a background task that puts
multiple random RSA's through the paces in alternate threads so the extraction
can't take place because of garbled data.

EDIT: Apparently I forgot that HackerNews You get downvoted if you present
common sense in face of a fallacy that those with limited understanding want
to hold true, as seen by the mass of links to wikipedia made by those with out
the foggiest about audio, capacitance, RSA, or Electrical engineering.

-Brandon Wirtz SMPTE

~~~
shabble
This is a very weak dismissal. Have you read the actual details they claim?

Side-channel attacks (like power analysis) in the presence of other activity
are well established.

Electrical signals causing audible frequency output are also well established.
Look up the piezoelectric effect[1], or magneto/electrostiction[2][3]. The
demand for miniaturisation of everything means even at low voltages, there are
quite substantial electric fields across small distances, which are enough to
flex the material audibly.

On the magnetostriction side, the flyback transformer in old CRT televisions
is a perfect example. Myself and many people have been able to tell whether
the TV was powered up (even if totally muted) from outside the room (and yes,
double-blind tested repeatedly).

What does wire gauge have to do with anything?

On the practicality/data rate issue, a nice quote from the very intro of their
paper states:

> In a nutshell, the key extraction attack relies on crafting chosen
> ciphertexts that cause numerical cancellations deep inside GnuPG’s modular
> exponentiation algorithm. This causes the special value zero to appear
> frequently in the innermost loop of the algorithm, where it affects control
> flow. _A single iteration of that loop is much too fast for direct acoustic
> observation, but the effect is repeated and amplified over many thousands of
> iterations, resulting in a gross leakage effect that is discernible in the
> acoustic spectrum over hundreds of milliseconds._

(emphasis mine)

It seems that the main focus of their work is to fingerprint the crypto and
identify that a particular key was used (but not necessarily what the key _is_
), which is a much easier problem than the one they talk about here, which
requires specially crafted input over a substantial period of time.

Your solution might work, or it might just lower the SnR of the signal and
require filtering larger quantities of data to extract the desired signal
again.

The road to crypto-hell is paved with people who thought that they could use
their "common sense" to reason intuitively about their problem. But to
paraphrase Feynman, Mother Nature is not swayed by persuasive arguments.

[1]
[https://en.wikipedia.org/wiki/Piezoelectricity](https://en.wikipedia.org/wiki/Piezoelectricity)

[2]
[https://en.wikipedia.org/wiki/Magnetostriction](https://en.wikipedia.org/wiki/Magnetostriction)

[3]
[https://en.wikipedia.org/wiki/Electrostriction](https://en.wikipedia.org/wiki/Electrostriction)

~~~
jdmichal
I am one of those people who can hear a CRT television from a room or two
over. Comes across as a very distinctive high pitched squeal. I always assumed
that other people couldn't hear it simply because it was too high.

It actually seemed worse when my LCD TV broke last year and I pulled out my
old CRT to watch a movie in the meantime. I don't know if I had just grown
unaccustomed to hearing it or what, but it was annoying me even through the
sounds of the movie.

~~~
p4bl0
Whoa, I had to reread your comment twice to understand it properly. In the
context of RSA, and particularly speaking about its weaknesses, for me "CRT"
automatically stands for "Chinese Remainder Theorem"… :-D.

If that interest someone, look for the BellCoRe attack on CRT-RSA [1,2]. I'm
also working on the countermeasure as part of my PhD [3,4], and it's quite
some fun!

[1] [http://cryptome.org/jya/smart.pdf](http://cryptome.org/jya/smart.pdf)

[2] [http://eprint.iacr.org/2012/553](http://eprint.iacr.org/2012/553)

[3] [http://eprint.iacr.org/2013/506](http://eprint.iacr.org/2013/506)

[4] [http://eprint.iacr.org/2013/810](http://eprint.iacr.org/2013/810)

