Two amusing side channel attacks | Hacker News Reader

Two amusing side channel attacks

syhw.posterous.com

179 pointssnippyhollow27 comments

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.

Of course! It was not a direct advice to data center hardware admins (but I guess they know better). :) Anyway, with physical access, there are countless other ways to harm your encryption mechanisms.

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

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.

> 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 * pi0.15^2 / (2pi*(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.

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

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

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

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.

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

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

What kind of relationship is there between sample rate and the frequencies you can record?

I may remember it wrong, but I believe you need at least double the sampling rate vs the frequency you want to record. And even then it's a very crude representation of the acoustic signal (Basically a one-bit resolution).

You're thinking about the Shannon's theorem. Here it is about knowing what operations the CPU is performing/looping on. This frequency is not related directly to the frequency at which the CPU operates: it's related to the frequency at which the plates of the capacitor oscillates (which is related to the frequency at which the CPU draws power and so operates...).

As snippyhollow pointed out, you're right with regard to frequency and that is the Nyquist-Shannon sampling theorem. However, it is important to realize that the resolution of the sampled signal is separate from the sampling rate and so the second part of your statement is incorrect. In theory, a signal sampled at its Nyquist-Shannon rate may be perfectly reconstructed to its analog equivalent. In practice, quantization (the number of bits used to represent each digital sample) will cause distortion to occur, but the bit depth or resolution of a sampled signal is only limited by hardware - in other words, there is certainly a limitation but one-bit quantization would not be useful (and thus not used) for recording an ultrasound signal.

An RSA encryption requires doing the same operation over and over again, with some inputs the same each time, for much longer than 100,000 instructions.

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.

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.

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.

For AES, yes. For RSA, no.

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.

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

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

I believe it's VIA-only at the moment. I'm not quite familiar enough with Montgomery multiplication to say if PCLMULQDQ is comparable; I suspect it isn't, though.

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

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

yes but HOW?

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

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?

Reply on news.ycombinator.com