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.
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.
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... )
"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."
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.
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.
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)."
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 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).
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.
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...).
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.
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.
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?
If it's that important, fill the hole with epoxy. Thicken it to a peanut butter consistency so it doesn't run all over.