×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Scientists Extract RSA Key From GnuPG Using Sound of CPU

Soulskill posted about 4 months ago | from the noisy-fans-are-now-a-feature dept.

Encryption 264

kthreadd writes "In their research paper titled RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis, Daniel Genkin, Adi Shamir and Eran Tromer et al. present a method for extracting decryption keys from the GnuPG security suite using an interesting side-channel attack. By analysing the acoustic sound made by the CPU they were able to extract a 4096-bit RSA key in about an hour (PDF). A modern mobile phone placed next to the computer is sufficient to carry out the attack, but up to four meters have been successfully tested using specially designed microphones."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

264 comments

My ass has open sores! (-1, Troll)

Anonymous Coward | about 4 months ago | (#45730725)

But open sores is more secure!!!

Remember TEMPEST? (5, Interesting)

Bruce Perens (3872) | about 4 months ago | (#45730735)

TEMPEST was a details-secret government requirement meant to defeat means of eavesdropping on classified computer data from its electromagnetic emissions. I guess they need to include audio too.

My impression is that the noise comes from the power supply, not the CPU. I can certainly hear it with some computers, and it is related to work on the video card in my experience. I'm astonished that you can actually pull data from that, and in fact I'd like to see independent confirmation before I believe it.

Re:Remember TEMPEST? (4, Insightful)

Hatta (162192) | about 4 months ago | (#45730767)

Seems like GPG could defeat this pretty easily by putting in some random HLTs.

Re:Remember TEMPEST? (1)

Desler (1608317) | about 4 months ago | (#45730815)

In almost all machines, it is possible to distinguish an idle CPU (x86 "HLT") from a busy CPU.

Since they can detect when its idle how would your idea work? Making it "random" doesn't make it undetectable.

Re:Remember TEMPEST? (-1, Troll)

mythosaz (572040) | about 4 months ago | (#45730883)

Also, since it's open source, and you can compile it yourself, your programmer can remove them or your compiler can ignore the HLTs.

Re:Remember TEMPEST? (1)

Opportunist (166417) | about 4 months ago | (#45731143)

But with plenty of different compilation and optimization options, not to mention a lot of compilers to choose from, the "sound" of the CPU should definitely change from binary to binary.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731149)

Since it's open source, your programmer can add a "Send private key to Eve" feature. What's your point?

Re:Remember TEMPEST? (1)

Cid Highwind (9258) | about 4 months ago | (#45731001)

Right, but all the sound reveals is whether the CPU is busy or idle (or more likely, how much current it's drawing). Adding random-length pauses exactly at the steps where knowing whether the CPU goes idle leaks part of the key would break this sort of listening attack.

With multi-core processors it might even be possible to mask the sound by starting up another thread to do useless work that sounds like encryption but isn't...

Re:Remember TEMPEST? (5, Interesting)

Desler (1608317) | about 4 months ago | (#45731049)

Q12: Won't the attack be foiled by loud fan noise, or by multitasking, or by several computers in the same room?

Usually not. The interesting acoustic signals are mostly above 10KHz, whereas typical computer fan noise and normal room noise are concentrated at lower frequencies and can thus be filtered out. In task-switching systems, different tasks can be distinguished by their different acoustic spectral signatures. Using multiple cores turns out to help the attack (by shifting down the signal frequencies). When several computers are present, they can be told apart by spatial localization, or by their different acoustic signatures (which vary with the hardware, the component temperatures, and other environmental conditions).

Re:Remember TEMPEST? (1)

Bruce Perens (3872) | about 4 months ago | (#45731269)

Using multiple cores turns out to help the attack (by shifting down the signal frequencies).

Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?

Re:Remember TEMPEST? (1)

muridae (966931) | about 4 months ago | (#45731463)

Using multiple cores turns out to help the attack (by shifting down the signal frequencies).

Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?

Cache misses

Re:Remember TEMPEST? (2, Insightful)

Bruce Perens (3872) | about 4 months ago | (#45731329)

The "audio" in question is most likely all below 24 kHz, that being the Nyquist limit for the 48 kHz sampling hardware, unless it happens that some phones can actually sample faster, and have microphones that can respond to higher frequencies.

The instruction rate of the CPUs in question is many times that frequency.

It doesn't sound likely.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731431)

It's been too long since I learned signal processing, but the Nyquist limit is for unaliased signals. Higher frequencies would be present in the audio samples, just aliased to lower frequencies. So long as there are no confusing lower frequencies, would it be that hard to pick out details from the aliased higher frequencies?

Re:Remember TEMPEST? (1)

chuckugly (2030942) | about 4 months ago | (#45731051)

The article says the second to last revision of the crypto did this, and that the change made it more vulnerable. Apparently it's a difficult problem.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45730981)

GPG already defeated this by adding basic anti-DPA measures (random whitening value).

Re:Remember TEMPEST? (1)

K. S. Kyosuke (729550) | about 4 months ago | (#45730867)

I don't think you need that. It shouldn't be all that surprising. It's all a matter of the signal/noise ratio of how a "slice" of a program's execution trace maps onto something you can measure from the outside. I'm more wary of the "one hour" requirement. If it's one hour of continuous execution of RSA routines, it's not exactly practical. But it shows how dangerous making assumptions can be ("hardware protection (386 protected mode, HW virtualization etc.) is sufficient for preventing information leaks!"). I can't wait until someone starts breaking TPM modules and such.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45730965)

It also needs to include LEDs. In fact, some other security standard already warns against this.

People used to hook LEDs almost directly to serial data buses (or, to be exact, a high-impedance LED driver was hooked directly to the serial data bus) to implement "activity" LEDs, and was quite an effective data leak for a very wide range of frequencies.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731205)

Good luck with that on anything approaching modern transmission speeds. Can a consumer grade LED actually switch fast enough to leak 56kbps, much less 50mbps?

Re:Remember TEMPEST? (5, Interesting)

DaveAtWorkAnnoyingly (655625) | about 4 months ago | (#45730983)

I'm not a computer scientist by trade, I'm an engineer (nukes), and this sounds dubious. Perhaps I'm way behind the curve on acoustic engineering, but being able to pull a 4096 bit key from noise that not only is pretty polluted, but also, surely depending on what the PC is doing, could be dependent of lots of other things?

Also, it's Bruce Perens. Hi!

Re:Remember TEMPEST? (-1, Flamebait)

zlives (2009072) | about 4 months ago | (#45731115)

i would be more liable to believe this if they had worked the porn angle in some how, but for now i stand with you.

Re:Remember TEMPEST? (1)

scottbomb (1290580) | about 4 months ago | (#45731157)

I was wondering how far I'd have to scroll down to see someone call BS on this. Wish I had mod points now.

Re:Remember TEMPEST? (4, Insightful)

Opportunist (166417) | about 4 months ago | (#45731239)

Well, think of it like trying to hear an opera singer in between a lot of traffic noise. Even your ear can do that to some degree, but for software it is fairly trivial to separate the song from the other noises, especially if you know what opera is being sung. The singer might not be singing in the key you know or he might have a bit of variety in the way he interprets the song, but you know in general what it should sound like so you know what to look for, and then you work from there.

Re:Remember TEMPEST? (1)

zlives (2009072) | about 4 months ago | (#45731337)

I am sure it is my shortcoming:
i wonder if a single core processor with a single repeating process in isolation could eventually reveal the process if additional processes are added later, but then again i am flabbergasted as to how it actually reveals the code... to me it has the sense of dousing for encryption keys...

Re:Remember TEMPEST? (1)

Bruce Perens (3872) | about 4 months ago | (#45731343)

Hi.

the Nyquist limit of the audio sampling hardware of a cell phone over instruction rate of a modern CPU is a pretty small fraction.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731453)

Hi Perens, I could have sworn you were incinerated at grid control.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731005)

I remember tempest being specific to displays. More specifically CRT displays because of how they operated.
CRT displays are high voltage electronics that modulate at high frequencies to turn on an off an electron beam (And use electric magnets to move the beam over the screen in a zig-zag pattern) These sorts of things happen to generate a whole lot of radio signals that are easy to pick up from a distance. Really, you just have to find the "song" the electronics that modulate the electron beam sings and it's not hard to extrapolate an image out of that.

You could buy "tempest shielded" displays (and an infamous black tempest shielded compact Macintosh) that were basically housed in Faraday cages.

Re:Remember TEMPEST? (1)

ArbitraryName (3391191) | about 4 months ago | (#45731113)

I remember tempest being specific to displays.

You remember incorrectly. TEMPEST covers compromising emanations of any types, from teleprinters to LCD displays to blinkenlights to keypress sniffing. The most "famous" demonstration was van Eck and CRTs, which is probably what you remember.

Re:Remember TEMPEST? (1)

phantomfive (622387) | about 4 months ago | (#45731361)

Thus far, it seems theoretical more than practical. Not only is it a chosen-plaintext attack, it also requires the user repeatedly decipher the text many times before the key can be extracted. I can't think of any practical way of getting people to do that (unless you can somehow get to the key in a Visual Basic Outlook script or something). That's my understanding of the paper, with this relevant quote:

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

Since microphones can't grab frequencies in the Ghz range (where CPUs operate), they can't directly observe individual instructions. But with multiple passes over the same operation, they can use statistics to determine what the instructions were.

Re:Remember TEMPEST? (0)

Anonymous Coward | about 4 months ago | (#45731461)

"Boss, we have a new security requirement for protecting our keys. It's called 'music'. We need to have music playing at every workstation."

cool (0)

Anonymous Coward | about 4 months ago | (#45730743)

That is seriously cool...

Not a Problem (1)

Anonymous Coward | about 4 months ago | (#45730757)

I will be playing Nirvana at max volume whenever I am decrypting shit from now on

Re:Not a Problem (2)

Edward Kmett (123105) | about 4 months ago | (#45730955)

They note that noisy environments don't really help.

OTP (0)

Anonymous Coward | about 4 months ago | (#45730761)

The use of one time pads is the only way to be sure you have secured your data, and even then, you must still be vigilant. There is no way I would ever use anything else.

NSA wants to access microphone. Allow/disallow? (4, Insightful)

sideslash (1865434) | about 4 months ago | (#45730773)

This makes me re-think the push toward quiet, fanless computers. Now I am thinking that I want a white[/some other color] noise generator to add privacy to my personal computing.

Re:NSA wants to access microphone. Allow/disallow? (1)

Desler (1608317) | about 4 months ago | (#45730831)

Did you miss the part about the secondary attack vector?

We demonstrated another low-bandwidth channel: the electric potential of the laptop's chassis. In many computers this "ground" potential fluctuates (even when connected to a grounded power supply) and leaks the requisite signal. This can be measured in several ways, for example:

Re:NSA wants to access microphone. Allow/disallow? (1)

sideslash (1865434) | about 4 months ago | (#45730941)

(What is this article of which you speak? I barely skimmed the summary.)

It seems to me that just about any web page I visit can (given the right software vulnerabilities) snoop on my computer's microphone. So that seems like a much larger vulnerability than the ground potential. Maybe for some people in more public places it might be different.

It's not the fan or mechanical components (5, Interesting)

LNO (180595) | about 4 months ago | (#45730871)

It's more awesome than that. The white noise generated by the fan doesn't matter at all.

"The acoustic signal of interest is generated by vibration of electronic components (capacitors and coils) in the voltage regulation circuit, as it struggles to maintain a constant voltage to the CPU despite the large fluctuations in power consumption caused by different patterns of CPU operations. The relevant signal is not caused by mechanical components such as the fan or hard disk, nor by the laptop's internal speaker."

The attack scenarios are even more fantastical. I have no idea how plausible they are, but wow, regardless:

"We discuss some prospective attacks in our paper. In a nutshell:
Install an attack app on your phone. Set up a meeting with your victim, and during the meeting, place your phone on the desk next to the the victim's laptop (see Q2).
Break into your victim's phone, install your attack app, and wait until the victim inadvertently places his phone next to the target laptop.
Have a web page use the microphone of the the computer running the browser (using Flash or HTML Media Capture). Use that to steal the user's GnuPG key.
Put your stash of eavesdropping bugs and laser microphones to a new use.
Send your server to a colocation facility, with a good microphone inside the box. Then acoustically extract keys from all nearby servers.
Get near a TEMPEST/1-92 protected machine, such as the one pictured to the right. Put your microphone next to its ventilation holes and extract its supposedly-protected secrets."

Re:It's not the fan or mechanical components (1)

sideslash (1865434) | about 4 months ago | (#45730901)

It's more awesome than that. The white noise generated by the fan doesn't matter at all.

Right, I mentioned the fan as one source of noise to act as a countermeasure (not a good one, of course, since you want something random).

Re:It's not the fan or mechanical components (4, Informative)

LNO (180595) | about 4 months ago | (#45730937)

Even that gets filtered out:

"Q12: Won't the attack be foiled by loud fan noise, or by multitasking, or by several computers in the same room?

Usually not. The interesting acoustic signals are mostly above 10KHz, whereas typical computer fan noise and normal room noise are concentrated at lower frequencies and can thus be filtered out. In task-switching systems, different tasks can be distinguished by their different acoustic spectral signatures. Using multiple cores turns out to help the attack (by shifting down the signal frequencies). When several computers are present, they can be told apart by spatial localization, or by their different acoustic signatures (which vary with the hardware, the component temperatures, and other environmental conditions)."

Re:It's not the fan or mechanical components (0)

Anonymous Coward | about 4 months ago | (#45731073)

Want it to be *really* worrisome? Some HSMs are certain to be vulnerable to this. In fact, anything that is not very well *primarily* hardened against power-measurement attacks (i.e. which doesn't depend on external shielding for the hardening -- since that shield is unlikely to have been designed to twart acoustic profiling, as evidenced by the attack on a TEMPEST-shielded box) will be.

Acoustic sound? (0)

Anonymous Coward | about 4 months ago | (#45730795)

Traveling through gaseous air?
On a more serious note, they're doing power analysis using DC/DC coil whine as a proxy.

Re:Acoustic sound? (0)

Anonymous Coward | about 4 months ago | (#45730961)

Traveling through gaseous air?
On a more serious note, they're doing power analysis using DC/DC coil whine as a proxy.

I suspect they meant "acoustic noise," noted to differentiate it from noise in signal processing [wikipedia.org] .

But who knows, maybe somebody would confuse "sound" between acoustics, water [wiktionary.org] , and medical probes [wiktionary.org] .

Daisy, Daisy... (4, Interesting)

jtara (133429) | about 4 months ago | (#45730813)

In High School, we had a program we would run on the IBM 1620 (this was in ancient history...) that would play a song on a transistor radio placed on the console. Somebody figured out what instructions to run to create different frequencies.

We used to just leave the radio there even when not running that program.

"That's a loop!"

"Whoa! A "FORMAT" statement!"

One can easily see how A leads to B.

Re:Daisy, Daisy... (4, Interesting)

Spiridios (2406474) | about 4 months ago | (#45730923)

In High School, we had a program we would run on the IBM 1620 (this was in ancient history...) that would play a song on a transistor radio placed on the console. Somebody figured out what instructions to run to create different frequencies.

We used to just leave the radio there even when not running that program.

"That's a loop!"

"Whoa! A "FORMAT" statement!"

One can easily see how A leads to B.

Back when the 486dx4 was out, I'd tune my FM radio to ~100mHz and listen to the weird whirs and buzzes that occurred during disk access or mouse movement. Many years later, during a security class of all things, when I suggested using this as a method to leak information out of a secure room, the speaker said using radio transmission to leak information was much too sophisticated to be a viable attack for anything but the government and military.

Re:Daisy, Daisy... (2, Funny)

Obfuscant (592200) | about 4 months ago | (#45731055)

Back when the 486dx4 was out, I'd tune my FM radio to ~100mHz

Wow. You have a radio that tunes that low? What signals did you hear? Nyquist tells us that the highest frequency you could modulate on that would be 50 mHz, well below the range of human hearing.

Re:Daisy, Daisy... (0)

Anonymous Coward | about 4 months ago | (#45731247)

MEGAhertz, not kilohertz.

100mhz is near the center of the North American FM broadcast radio band.

Re:Daisy, Daisy... (3, Informative)

Cimexus (1355033) | about 4 months ago | (#45731319)

You're missing the point. He typed mHz (millihertz) instead of MHz (megahertz).

Re: Daisy, Daisy... (1)

Anonymous Coward | about 4 months ago | (#45731275)

You're a dinosaur, too? We played the Star Spangled Banner on a chain drive IBM 1403 printer.

Re:Daisy, Daisy... (0)

Anonymous Coward | about 4 months ago | (#45730947)

One can easily see how A leads to B.

I agree that sure, but that time CPU-clock was considerably slower few MHz range. Now we are in GHz range instructions executed 1000 times faster and still there are detectable harmonic side channels that can be picked up by a microphone. Didn't have time yet to read full paper, but a apparently condenser which are very sensitive, but still a device made picking up kHz range is quite neat feat to pull.

Oh, I got an idea -- The Bat detector! (0)

Anonymous Coward | about 4 months ago | (#45731107)

I need to borrow one from biology lab tomorrow and see those sounds could be heard with that :)

What about what else the pc is doing... (0)

Anonymous Coward | about 4 months ago | (#45730865)

Was this a single core?

Or a dual+ core doing nothing else at the time?

Re:What about what else the pc is doing... (1)

Desler (1608317) | about 4 months ago | (#45730989)

They address that. It ms a very short "article" so you really should read.

In before "you must be new here".

Yeah right? (-1)

LWATCDR (28044) | about 4 months ago | (#45730905)

What sounds does a cpu make? Or better yet how does a CPU make sound? The clock speeds are in the GHZ range so it is so far outside of the sound range of any microphone it just is not funny.Throw in that all cpus today have more than one core you will have a more than one code stream executing at one time. Throw in the sound of the fans running to make picking up the sound just seem very unlikely. Until it is duplicated I would really doubt it.

Re:Yeah right? (0)

Mister Transistor (259842) | about 4 months ago | (#45730973)

This is obviously nonsense to you and me, but now the NSA thinks this is a viable vector! Imagine all the billions of tax $$ they will now waste researching and trying to crack it!

This is what we need - more crackpot theories of infection/subterfuge vectors to keep 'em busy.

Re:Yeah right? (2)

Desler (1608317) | about 4 months ago | (#45731031)

How is it "obviously nonsense"? Pardon the appeal to authority but do you know who, for example, who Adi Shamir is? He isn't some random quack.

Re:Yeah right? (1)

cold fjord (826450) | about 4 months ago | (#45731081)

This is what we need - more crackpot theories of infection/subterfuge vectors to keep 'em busy.

If so, this is definitely the right place to get them.

Unfortunately there are way more crackpot theories about what NSA are up to than there are about new attack vectors. Someone needs to step up production of the crackpot attack vectors. Any takers?

Re:Yeah right? (3, Informative)

Desler (1608317) | about 4 months ago | (#45731009)

You could have spent 5 minutes to skim the page where they address your questions.

Re:Yeah right? (1)

bob_super (3391281) | about 4 months ago | (#45731087)

You forgot to mention deep pipelines, out-of-order execution, cache hits and misses, interrupts, multitasking...

Yeah, I don't believe that one on regular PCs (and I don't think they'll bother to come break my keys to prove me wrong), and I'd like to see the amount of testing required for it to work on single-threaded single-core in-order non-cached micros, if they can find one.

Re:Yeah right? (1)

Desler (1608317) | about 4 months ago | (#45731109)

They address both multitasking and multiple cores. They say multiple cores makes the attack easier.

Re:Yeah right? (1)

r2kordmaa (1163933) | about 4 months ago | (#45731183)

CPU does not make a sound. Its current consumption does however swing wildly depending on what program its currently running. Variable current, all these chokes and coils in the way - you will get vibration and thus acoustics. Look up power analysis attack vectors on cryptography. These are old news and they work. Now the novel bit here is how you get the data for power analysis, instead of direct current measurement you measure acoustics. I guess thats plenty of data.

Re:Yeah right? (0)

Anonymous Coward | about 4 months ago | (#45731279)

Seriously. RTFA...

Re:Yeah right? (5, Informative)

amicusNYCL (1538833) | about 4 months ago | (#45731373)

What sounds does a cpu make?

They describe that in the paper's summary.

Or better yet how does a CPU make sound?

They describe that in the first line of the paper's summary, and also in question 2 of the Q&A.

The clock speeds are in the GHZ range so it is so far outside of the sound range of any microphone it just is not funny.

They address that at the end of the first paragraph of the paper's summary, and also in question 8.

Throw in that all cpus today have more than one core you will have a more than one code stream executing at one time.

They address that in question 12.

Throw in the sound of the fans running to make picking up the sound just seem very unlikely.

Also in question 12.

Until it is duplicated I would really doubt it.

OK, thanks for the valuable feedback.

A legit reason to have the radio on all the time! (4, Funny)

sandytaru (1158959) | about 4 months ago | (#45730925)

I'm totally going to use this if I'm ever asked to turn my music down in the office. "But sir, this is increasing my encryption security!"

Since 90% of the people in my office are not tech people, that just might work.

Re:A legit reason to have the radio on all the tim (-1)

Anonymous Coward | about 4 months ago | (#45731075)

No dice. All they need is a second microphone and they can cancel sounds that come from the farther mike. Of course, this can only filter out so much sound, so perhaps it'd still introduce enough noise to render the recording useless.

You'd be far better off encrypting something else concurrently, perhaps with a different (unpublished) key.

Easy fix (0)

Anonymous Coward | about 4 months ago | (#45730959)

Just run in the background a "Random Noise Generator"

Re:Easy fix (1)

bobbied (2522392) | about 4 months ago | (#45731165)

Just run in the background a "Random Noise Generator"

And what program do you propose to use that generates Random Noise?

Good thing im exempt (2)

nurb432 (527695) | about 4 months ago | (#45731021)

I run a quantum computer. Good luck getting noise from that.

Re:Good thing im exempt (1)

Valdrax (32670) | about 4 months ago | (#45731307)

I run a quantum computer. Good luck getting noise from that.

Haha. Mine is entangled with yours. Gives a whole new meaning to spooky action at a distance.

MON KEES COMING OUT OF MADONNA'S BUTT !! (-1)

Anonymous Coward | about 4 months ago | (#45731037)

Balderdash !!

New? (5, Interesting)

Anonymous Coward | about 4 months ago | (#45731045)

Wait, this is a new paper? Neat, they updated it since 2004. Um, this is a pretty old technique, I've seen it demonstrated, on GnuPG, no less, before. RSA squares and multiply have different loops. This one, I know, GCHQ did first.

It's one of the reasons we like Ed25519 and the other safecurves - constant time loops, no key-dependent branches, massively reduces side-channel attack potential.

NSA to Scientist: "Welcome to 1998" (1)

JoeyRox (2711699) | about 4 months ago | (#45731067)

I'm sure the NSA has been doing this for some time. Not to mention listening in on keyboard sounds and emissions from computer displays to get the same information.

Easy to guard against this (1)

OuchIAteMyself (799707) | about 4 months ago | (#45731139)

It seems like 'random' interference would be easy to produce by mimicking the behavior of these components in intervals in order to obscure the collected data. Even though the interference wouldn't be truly 'random', it would certainly increase the amount of data that needs to be collected in order to effectively remove it from the sound recording.

Requires continuous decryption of known texts (1)

Anonymous Coward | about 4 months ago | (#45731141)

This only works if the computer is decrypting known files for an hour. It would be very difficult to exploit in practice.

More "Don't Bother" FUD from the NSA (0)

Anonymous Coward | about 4 months ago | (#45731173)

We KNOW that the NSA has commissioned multiple academic papers - peer reviewed and widely published - pushing the absolute lie that properly erased data on a HDD can be recovered. Indeed, the owners of Slashdot, on multiple occasions, have ensured that such FUD about the safety of erased files has gained maximum promotion on this site.

A significant part of the NSA budget is set aside for media propaganda campaigns, in both the general and specialist 'press', that actively discourages people from deploying the best security protocols. This is a STATISTICAL game, where the active intent of the NSA is to ensure a significantly lower proportion of the systems they encounter through ALL their surveillance projects have good security.

"The NSA can hack it all anyway, so why bother with ANY inconvenient security measures- the commercial security packages are just as 'safe' as things like Truecrypt, Tor, etc."

Sounds like the thoughts of a moron, but the NSA know this is actually the thinking of most of you, after exposure to FUD campaigns on Slashdot and elsewhere.

CPUs don't make 'sounds', and modern processors handle encryption/decryption with such a tiny fraction of their computing power, 'reading' the 'algorithm' and 'data' use of the processor using analysis of power usage or EM radiation would be impossible, UNLESS the software had been specifically engineered (ie., anything from Microsoft or the like) to allow such attacks.

But here's a more recent example of technical FUD from NSA sources. Modern processors have instructions specifically created to improve the 'flow' of encrypted data- instructions that 'accelerate' parts of common encryption/decryption algorithms. While a naive person might think such instructions were a likely vector for an NSA sponsored hardware attack, they are in reality merely simply simple maths/data operations that happen to help the algorithm.

On the other hand, Intel, AMD and ARM licensees are all implementing NSA/GCHQ perverted FAKE random number generators that morons are encouraged to use as seeds etc for their encryption algorithms. ***NO*** valid security software will ever use these hardware random number units. Google, Microsoft and the usual suspects, however, mandate the use of these subverted units in the hackable, back-door riddled 'security' products they produce.

But my intended point is that technical sites are DELIBERATELY confusing their readers about the 'safety' of using the accelerating instructions as if they carry an identical risk to using the inbuilt FAKE random number generator. This is the common "all or nothing" FUD propaganda method in different clothes.

To put it simply, if it's promoted on Slashdot now, it's pro-NSA FUD. Once Slashdot bothered to hide its true colours. Today, they don't even see the need to do that. A bit like how Obama, in the midst of the full surveillance NSA scandal, launched a spy platform for his massively expanding war machine, decorated with a giant octopus swallowing the world, and a logo that effectively stated "F**k you sheeple". Needless to say, the blatant use of this obscene 'middle finger' to Humanity was not deemed worthy of 'promotion' on Slashdot.

Redundant summary is redundant (0)

henryteighth (2488844) | about 4 months ago | (#45731293)

I'm so glad to know they examined the *acoustic* sound (or the acoustic *sound*, even) instead of any sort.

Reminiscent of other attacks (5, Interesting)

cold fjord (826450) | about 4 months ago | (#45731295)

There have been other attacks previous discussed here as I recall, such as using power fluctuations or timing attacks, and so on, as cribs to retrieve a key. It appears this sort of attack that exploits the characteristics of the system performing the encryption will continue to be an attack vector of growing importance.

Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems [cryptography.com]

Abstract. By carefully measuring the amount of time required to perform private key operations, attackers may be able to find fixed Diffie-Hellman exponents, factor RSA keys, and break other cryptosystems. Against a vulnerable system, the attack is computationally inexpensive and often requires only known ciphertext. Actual systems are potentially at risk, including cryptographic tokens, network-based cryptosystems, and other applications where attackers can make reasonably accurate timing measurements. Techniques for preventing the attack for RSA and Diffie-Hellman are presented. Some cryptosystems will need to be revised to protect against the attack, and new protocols and algorithms may need to incorporate measures to prevent timing attacks.

Breaking DES with side-channel attacks [isy.liu.se]

This lab will demonstrate how power analysis of cryptographic hardware can reveal the key. We will be using basic electronic measurement tools such as oscilloscopes to demonstrate this side-channel attack.

You will be using a small hardware board (fig. 1) with a generic microprocessor programmed to perform DES encryption and decryption. The scenario is that you are the attacker and want to find out the secret key stored inside the board. There is no way of getting to the key directly, so you will need to perform a side-channel attack by measuring the power consumption of the board while the algorithm is running. The hardware board also allows the user to load a custom key in order to compare the power consumption.

And to think that there were people poopooing NSA for pulling cables and servers that Snowden had access to. More attack vectors for everybody!

The technology inside Apple’s $50 Thunderbolt cable [arstechnica.com]

A source within the telecom industry explained to Ars that active cables are commonly used at data rates above 5Gbps. These cables contain tiny chips at either end that are calibrated to the attenuation and dispersion properties of the wire between them. Compensating for these properties "greatly improves the signal-to-noise ratio" for high-bandwidth data transmission.

This is probably not a big deal (4, Informative)

DrJimbo (594231) | about 4 months ago | (#45731351)

What they are exploiting is that in naive implementations of RSA the amount of computer power needed during en/decryption varies with each binary digit in the key. If the digit is zero then no computation is done and if it is one that a tight loop is executed.

There have been other side channel attacks that exploit this weakness in naive implementations. The obvious fix is to slightly change the algorithm so the same computation is done whether the digit is a zero or a one. This reduces the efficiency by a factor of two but it makes these side channel attacks much more difficult.

In fact, the authors contacted GPG before publicly releasing this exploit and the fix is in place [tau.ac.il] :

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.

...

Q13: What countermeasures are available?

One obvious countermeasure is to use sound dampening equipment, [...]

Alternatively, one can employ algorithmic techniques to reduce the usefulness of the emanations to attacker. These techniques ensure the rough-scale behavior of the algorithm is independent of the inputs it receives; they usually carry some performance penalty, but are often already used to thwart other side-channel attacks. This is what we helped implement in GnuPG (see Q9).

TRS-80 (1)

CohibaVancouver (864662) | about 4 months ago | (#45731359)

Back when I had my TRS-80 Model 1 you could 'listen' to the 1.77 MHz Z80 processor do its thing on any AM radio nearby. Now get off my lawn.

random comments (1)

Anonymous Coward | about 4 months ago | (#45731379)

Despite all the random comments, this paper appears to have very solid grounding.

The attack they propose is a chosen-ciphertext attack where the computer is requested to decrypt a message encrypted by a public key which is sent by the attacker to the computer which is decrypting it with a private key using a known software library (GnuPG).

They note that it is possible to control the message so that two known paths are taken through the software depending on a specific intermediate computation and they were able to characterize different audible electromechanical oscillations in the power regulation circuitry of the CPU of when taking these two branches despite some safeguards in the library designed to prevent other side-channel attacks (e.g., timing and instruction cache occupancy).

Sorry, I can't believe this (1)

Anonymous Coward | about 4 months ago | (#45731457)

This is one of those things I won't believe until I witness it with my own eyes. Even then I'll be skeptical.
My intuition tells me there's no way this can be true. I don't care who wrote this paper.
If it is true it's the most incredible thing I've ever read, and either proves or disproves there really is a God, I'm not sure which.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...