
Two amusing side channel attacks - snippyhollow
http://syhw.posterous.com/two-amusing-side-channel-attacks
======
jws
Before you go shorting a USB port to "blow its specific fuse" you might look
at the motherboard closely. Given that you can save money by omitting them,
you'll find some motherboards do just that. There are also thermal based, self
resetting fuses, so the port could come back.

If it's that important, fill the hole with epoxy. Thicken it to a peanut
butter consistency so it doesn't run all over.

~~~
oniTony
It's a matter of physical security and not allowing random people with
specialty tools near the sensitive hardware (which is applicable to all other
side channel attacks). Depending on the amount of access and tools, an
attacker could just power-saw a side of the case off (along with all that
epoxy) and hook up into the USB power rail.

Though obviously that is not very discreet. I wonder if "a very precise
voltmeter" can fit inside of a non-suspicious looking USB device...

~~~
marshray
_I wonder if "a very precise voltmeter" can fit inside of a non-suspicious
looking USB device_

I would think so. Since the signal is over such a small range that removes a
big engineering consideration. It's also a relative measurement at
(relatively) low frequencies. An off-the-shelf 12 or 16 bit A/D converter
would probably work just fine with the right input conditioning.

Also, don't overlook the possibility of pointing a telescope at an illuminated
LED being powered from the motherboard. It will vary in brightness just as (or
even more) accurately as the supply voltage from a USB port.

~~~
A1kmm
> Also, don't overlook the possibility of pointing a > telescope at an
> illuminated LED being powered from the > motherboard. It will vary in
> brightness just as (or even > more) accurately as the supply voltage from a
> USB port.

That is probably technically difficult from any significant distance, because
tiny differences in air temperature slightly alter the refractive index, and
add random error to your measured brightness that most likely would dwarf the
tiny fluctuations in light output.

On top of that, light output is a quantum phenomena, and this complicates any
analysis from a significant distance.

For example, suppose that there is a 630 nm, 2 mA average red LED attached to
the computer, with a clock speed of 1 GHz. Each photon has 6.6260695729E-34 *
299792458 / 630E-9 = 3.153088387521748e-19 J of energy, so the device emits
6.342987427548621e15 photons per second, or 6.342987427548621e6 per clock
cycle. Assuming those photons are radiated in a perfect semisphere, and a 15cm
telescope aperture at a distance of 100m, the number of photons per clock
cycle is 6.342987427548621e6 * pi _0.15^2 / (2_ pi*(100)^2) = 7.14 photons /
clock-cycle.

From such a small number of photons, trying to detect a <0.002% change in
voltage seems to be infeasible unless the attacker can make the computer
repeat the exact same sequence of operations with predictable timing enough
for an averaging procedure.

Obviously, if the attacker can get closer or use a massive telescope aperture,
the attack might be more feasible.

~~~
marshray
That's really interesting.

But the leaked information doesn't need to be collected at anything close to
clock-cycle sampling periods. For example, there have been successful timing
attacks demonstrated from sampling only the time taken by the overall private
key operation (millseconds). Note that these guys demonstrated a side channel
attack with an ultrasonic microphone.

Yes, the standard assumption is that an attacker will be able to prompt the
server to perform a large number of private key operations at predictable
times. This is not unrealistic, it usually only takes a half-dozen TCP packets
or so to get a web server to do it immediately. (e.g.
[http://thehackerschoice.wordpress.com/2011/10/24/thc-ssl-
dos...](http://thehackerschoice.wordpress.com/2011/10/24/thc-ssl-dos/) )

This paper discusses some effective attacks on LED leakage using telescopes.
[http://www.ma.rhul.ac.uk/static/techrep/2011/RHUL-
MA-2011-07...](http://www.ma.rhul.ac.uk/static/techrep/2011/RHUL-
MA-2011-07.pdf) :

"A practical upper boundary on data rates by optical emanations was estimated
at 10 Mbps (Megabits per second), but they thought that greater data rates may
be feasible."

------
jws
I'm missing something here. If you collect data up to 48kHz, then there are
still 100,000 or so instructions occurring in each sample. Getting from there
to breaking RSA should have some explaining.

~~~
oniTony
a citation from the article has an FAQ with just that question.
<http://tau.ac.il/~tromer/acoustic/#Q2>

~~~
cjg
And the answer given in that link is: "First, when the CPU is carrying out a
long operation, it may create a characteristic acoustic spectral signature:
for example, below we show how RSA signature/decryption sounds different for
different secret keys. Second, we get temporal information about the length of
each operation, and this can be used to mount timing attacks (see Q10),
especially when the attacker can affect the input to the operation (i.e., in
chosen-ciphertext attack scenario)."

------
1point2
I wonder if the PC they tapped was a single corer? I imagine > 1 core (if > 1
were being used) would muddy the signal somewhat. Also, peripheral device (or
even GPU) operations would do the same (muddy the signal) - so I guess like a
lot of attacks - they work best when conditions suit their vector.

~~~
snippyhollow
You're right, it was a single core Celeron (IIRC). I assume it would be way
harder with a quad core. Two (running) cores can be manageable, except if the
second core executes a program specifically designed to scramble the
ultrasonic signal.

~~~
zdw
Also, newer CPU's often will have instructions expressly created to perform
the cryptographic work. I'd posit that these, along with the reduced overall
time of the calculation, would greatly inhibit any attack of this nature.

~~~
duskwuff
For AES, yes. For RSA, no.

~~~
maaku
It's called Montgomery multiplication. VIA has had it in their CPUs for quite
some time now. I don't know about AMD or Intel.

~~~
marshray
Intel has the AES-NI instruction in some chips. This is said to reduce the
side channels considerably.

(Have fun figuring out if that laptop at the store actually has it though. The
"Core I7" designation isn't enough.)

~~~
duskwuff
Again, that's just for AES, which isn't what's being discussed in this
article. RSA is a totally different beast.

------
mef
Interesting approach, but is it accurate to say they broke RSA by figuring out
which CPU operations were being performed during encryption?

~~~
snippyhollow
Adi Shamir (the S in RSA) told us they actually did.

~~~
paolomaffei
yes but HOW?

~~~
salem
Because the algorithm takes a slightly different code path over time depending
on the bits of the key.

------
shurane
Is a side channel attack very feasible in a cloud computing setting? Say for
the server spaces of places like Amazon EC2, Rackspace, Linode, and other such
providers.

Also, could this sort of thing be circumvented by doing the encrypting and
decrypting inside a virtual environment and then interspersing random
computations throughout?

