Scientists Extract RSA Key From GnuPG Using Sound of CPU 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."
Remember TEMPEST? (Score:5, Interesting)
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? (Score:5, Insightful)
Seems like GPG could defeat this pretty easily by putting in some random HLTs.
Re:Remember TEMPEST? (Score:4, Funny)
Or HCF, if you wanted to be really sure.
Re: (Score:3)
Re: (Score:2)
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? (Score:5, Interesting)
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: (Score:2)
Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?
Re: (Score:2)
Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?
Cache misses
clock speed changes with the # of cores in use (Score:2)
Well, if they're Intel turbo-boost processors, running more threads (and activating more cores) drops the frequency of all the cores. Fewer cores in use = higher core frequency.
Re: (Score:3)
but that doesn't really answer the question... ..how are the distinguishing between the "noises" from the core1 vs. core2 vs. core3.
all and all it sounds so whimsical some proof of concept actual practical doing of it would be nice(and what else could they get from the sounds of the cpu then...). .. and just with an android phone?? wtf? how are they hitting high enough sampling frequencies for it to be doable in the first place??
Re:Remember TEMPEST? (Score:5, Insightful)
Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?
It is not the cores specifically but a mathematical property commonly used in radio communication.
sin(a)*sin(b) = 1/2 * (cos(a-b) - cos(a+b))
A transistor working in the non-linear section will have an exponential function. This will give a function similar to (a+b)^2 = a^2 + 2ab + b^2 (Not really, but close, the important part is that you get the product of the signals. The rest will be high frequency noise.)
This means that if you have two frequencies that are cos to each other, like 3000000kHz and and 3000001kHz the interaction between them will create a component at 6000001kHz and one a 1kHz.
Pretty much all audio equipment you can find will gladly filter out the higher frequencies and let the 1kHz component through.
The frequency variations in the ~1kHz component will give you information about the runtimes of the instructions.
Re: (Score:3, Insightful)
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? (Score:5, Informative)
Your objection was directly addressed in the article:
"Cryptanalytic side-channel attacks typically require measurements with temporal resolution similar to the time scale of the target operation, but here the target cryptographic computation is many orders of magnitude faster....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
I dare suggest that sometimes even the experts need to RTFA.
Re: (Score:3)
the key extraction attack relies on crafting chosen ciphertexts that cause numerical cancellations deep inside GnuPG's modular exponentiation algorithm
So do this mean that they can analyze it only be introducing specific ciphertext into the communication?
That does not seem all that useful when you have no control over the hardware, and no influence on the communication.
Re:Remember TEMPEST? (Score:5, Informative)
Q11: Can you realistically perform the chosen-ciphertext attack on GnuPG?
To apply the attack to GnuPG, we found a way to cause GnuPG to automatically decrypt ciphertexts chosen by the attacker. The idea is to use encrypted e-mail messages following the OpenPGP and PGP/MIME. For example, Enigmail (a popular plugin to the Thunderbird e-mail client) automatically decrypts incoming e-mail (for notification purposes) using GnuPG. An attacker can e-mail suitably-crafted messages to the victims, wait until they reach the target computer, and observe the acoustic signature of their decryption (as shown above), thereby closing the adaptive attack loop.
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
It doesn't?
The attacker sends specially crafted encrypted messages to his target, records the side-channel information from the attacks and uses that information to determine the target's private key. Now the attacker is able to impersonate the target. I would call that a real-world problem since the private key is supposed to remain private.
That is why the paper points at the vulnerability of plugins that automatically decrypt messages for notification purposes or any application where the decryption proce
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Add a few HCF instructions here and there. You might be lucky enough for it to cause some consternation at the listener's end.
Re: (Score:2)
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: (Score:3)
It's not the CPU, it's ceramic capacitors [edn.com] that make the noise. You can actually buy special quiet capacitors.
Re: (Score:2)
exsept that would show up when you run a diff of the sourcecode
Re: (Score:2)
Re:Remember TEMPEST? (Score:5, Interesting)
Also, it's Bruce Perens. Hi!
Re: (Score:2)
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: (Score:2)
I was wondering how far I'd have to scroll down to see someone agree with me. Wish I had mod points now.
FTFY
Re:Remember TEMPEST? (Score:5, Insightful)
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: (Score:2)
you know in general what it should sound like so you know what to look for, and then you work from there
If it was just one opera singer it might be reasonable to "work from there", but keys need to be 100% correct unless they are combinign it with a brute force attack, but then they would still need to know whci hbits they heard correctly.
But i still call bullshit, what if there are more than one opera singers singing, or its some new age music that has elements of opera, but isnt really opera at all.
What if a bug flys into your fan ?
Re: (Score:2)
Re: (Score:3)
Your analogy may work if you add that the sound of the singer is at frequencies near 1GHz (a high-frequency coloratura soprano?), and the sound is filtered as usual through a 44kHz lowpass filter before being recorded.
Re: (Score:2)
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: (Score:2)
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: (Score:2, Informative)
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.
Also, potatoes are delicious. Both statements have very little to do with the paper in question.
Re: (Score:2)
They're not listening for individual instructions. they're listening for branches in specific loops.
Re: (Score:2)
Particularly relevant high-level from the PDF:
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.
Re: (Score:2)
In the situation in question, they fully control the load of the computer.
Re:Remember TEMPEST? (Score:4, Insightful)
Also, it's Bruce Perens. Hi!
Also, while we are still in 'appeal to authority' mode, the coauthor of the paper is Adi Shamir, the 'S' in RSA.
Re: (Score:2)
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 obse
Re: (Score:2)
Yet the processing for that key nevertheless stretches out quite a while in computing terms; Choose the right time scales at which to analyze the acoustic signal, and perhaps something like an RSA key can be recovered where most other types of info are beyond reach because they are processed only fleetingly.
Re: (Score:2)
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: (Score:3)
http://cryptome.org/tempest-time.htm [cryptome.org]
The US and UK later targeted the French embassy cypher machines in London and Washington until the early 1960's. France finally installed copper shielding in the early 1960's
The real trick
Re: (Score:2)
Yep!
As the saying goes.... "You must be new here" ;)
http://slashdot.org/story/02/03/06/1221224/led-lights-friend-or-foe [slashdot.org]
Re: (Score:2)
This article reminded me of that one. Nice to see that one again.
Jason.
Re: (Score:3)
Absolutely. Optocouplers are slow because of transistor storage time and not the LED which is why if you have access to the base of the transistor, you can make the optocoupler much faster.
NSA wants to access microphone. Allow/disallow? (Score:5, Insightful)
It's not the fan or mechanical components (Score:5, Interesting)
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: (Score:2)
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 (Score:4, Informative)
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: (Score:2)
Moving back to fan computers won't help so you can keep your ultra quiet fans. Read The Fine Article:
Q12: Won't the attack be foiled by loud fan noise, or by multitasking, or by several computers in the same room?
Re: (Score:2)
Moving back to fan computers won't help so you can keep your ultra quiet fans. Read The Fine Article:
*sigh* ... yes, I was aware of that. That was why in the next sentence I suggested adding a random/colored noise generator.
Re: (Score:2)
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.
Daisy, Daisy... (Score:5, Interesting)
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... (Score:5, Interesting)
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: (Score:2, Funny)
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... (Score:4, Informative)
You're missing the point. He typed mHz (millihertz) instead of MHz (megahertz).
Re:Daisy, Daisy..., and AC97 (Score:2)
On every motherboard I've owned the onboard audio always picked up noise from unrelated CPU, or maybe GPU, activity. Moving the mouse, opening a menu, and just typing would create random clicks and buzzes from the speakers. And, naturally, there was the white noise, no doubt from the poor quality hardware. The only way I could get sound to work well is with a discrete sound card.
All right, that's it! (Score:2)
I'm turning off the web server right now!
A legit reason to have the radio on all the time! (Score:5, Funny)
Since 90% of the people in my office are not tech people, that just might work.
Good thing im exempt (Score:3)
I run a quantum computer. Good luck getting noise from that.
Re: (Score:2)
Re: (Score:3)
It's no use, I looked in your box there and your cat is dead...
Re: (Score:2)
Lucky you, I am still eavesdropping on dial tones and deciphering by matching to digits. I am also faking dial tones and making long distance calls by whistling.
https://en.wikipedia.org/wiki/Phreaking [wikipedia.org]
Re: (Score:2)
So long, and thanks for all the fjords.
Re: (Score:2)
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.
Re: (Score:2)
So THAT is where that porn came from...
New? (Score:5, Interesting)
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" (Score:2)
How do you test a meter? (Score:3)
but up to four meters have been successfully tested
Were they all the same size?
Re: (Score:2)
=)
White Noise Generators As Countermeasure? (Score:2)
EOL.
Reminiscent of other attacks (Score:5, Interesting)
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 (Score:5, Informative)
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 (Score:2)
I used to carry a transistor radio for debugging. (Score:3)
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.
In those days I carried a transistor radio and used it for debugging - (on stuff substantially larger than a TRS-80). It gave subtle insights into how much time the machine was spending in different parts of algorithms. (The ear and its post-processing in the brain is really good at picking this stuff out.)
The rise of multitasking, with fine-grained time slices, ruine
Layman interpretation (generally) (Score:5, Informative)
Ok, I'm impressed.
For those that didn't want to RTFA, this works by letting the target computer spin on a carefully chosen piece of text. That text is chosen such that the CPU will do some predictable math (such as big equations that == 0). Then, those places where the CPU hits 0 can be heard through a sensitive microphone.
The neat part is that you're not looking for a 4096-bit key. Computers don't actually handle things with that large of a size, they have to break it down into 32-bit/64-bit chunks to be able to do the math. That's the real vulnerability - despite the key length itself being massive, because the number gets broken down into small chunks, you can start to handle it. The paper goes through a very complicated way of sensing each section of a large key, and then piecing it all together. This is not a case of hearing a specific noise, and looking it up in a table. It's not even a case of looking up 32-bit chunks in a table.
So, it is a real attack, that is mostly dependent on the breakdown of the 4096bit key into bitesize chunks, that go through known math routines. If you can get the target to nicely decrypt several well-crafted messages for you, and you can get a good microphone near their CPU while they do it, and you can let this process go on long enough (so the attack program can listen to the CPU for a while to build up a profile, etc.), it really can work.
I'll say that it needs kind of an ideal scenario to get all those things lined up, but it's not impossible.
Preventing it fully is really only possible with two ways. Either switch your CPU to not use those bite-size chunks, and have the decryption take place all in one massive math operation (not realistic), or change the math that occurs on the bite-size chunks to be irregular in terms of any recognizable patterns (very realistic).
Re: (Score:3)
Yours is the most useful comment on this fascinating story. Since you RTFA (sucka), what is the source of the CPU noise? What are its characteristics (frequency range, dynamic range) such that it can cut through other noises to register onto an at-distance audio mic?
BTW, I would have thought it bunk but for the name Adi Shamir in the author list, you know, the S of RSA.
The authors speculate that this is electro/magnetic-mechanical noise coming from the voltage regulators near the CPU (e.g., inductor "hum"). They note that it is hard to localize because the whole motherboard assembly is of course mechanically coupled together. The audio spectrum was characterized in a small range (35-39kHz) which is something that you can pick up with a standard microphone pickup. The dynamic range varied on different platforms, but in one case 0.5Hz separated the '0' and the '1' case.
in other words (Score:2)
rsa works by doing the same little set of manipulations over and over, masked downstream by a counter and/or how compressed your data is. this set of manipulations manifests as a (probably not very) musical note which repeats itself over and over in the cacophony every machine radiates, and unfortunately it is the constant repetition which gives the game away.
unfortunately it is the blindly repetitive nature of the operation which makes rsa even vagely feasible given the vast amounts of data we expect it t
Solution: (Score:2)
Put toddlers around the office to drown out the CPU sound.
Grid Computing? (Score:2)
I run grid computing using the BOINC and World Community Grid, so my four cores are running flat out all the time.
Would this be enough to blind any software that was trying to listen to the noise your CPU makes? Sort of a CPU white noise generator?
NSA Tempest fun fact (Score:2)
Back in the 80s when personal computers began to appear on every desk, the NSA was spending a ton of money to shield every PC they had. So when they built their new main offices at Fort Meade, they decided it was cheaper to shield the entire building.
Solution (Score:2)
Not practical in real life, but already fixed (Score:3)
Still, http://www.debian.org/security/2013/dsa-2821 [debian.org]
Re: (Score:3)
They note that noisy environments don't really help.
Re: (Score:2)
Re:Not a Problem (Score:5, Interesting)
I'll be playing a recording of my system decrypting data with my throw-away RSA key then.
Re: (Score:2)
I'd guess flooding with white noise in the right spectrum might.
Re: (Score:2)
Re: (Score:3, Informative)
You could have spent 5 minutes to skim the page where they address your questions.
Re: (Score:2)
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: (Score:3)
Re:Yeah right? (Score:5, Informative)
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.
Re: (Score:2)
I did and it just doesn't make any sense.
Where does the sound come from? Their answer is this.
"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 variable power load would very based on the instructions but we are not really interested in the instructions we
Re:Yeah right? (Score:4, Informative)
The variable power load would very based on the instructions but we are not really interested in the instructions we are interested in the data. Doing an instruction on any data should cause the same power draw so how do they extract the data?
There's an 8MB PDF linked from the summary that has your name all over it. Instead of asking questions like that and waiting for the answer and ignoring all of the work that they did in producing the paper, just read the paper and get the answers.
So it can only work with some keys?
It is a chosen-ciphertext attack, not a chosen-key attack.
The summary really does not answer the questions.
Yeah, no shit. The summary is not supposed to answer all of the question. You know what is supposed to answer the questions? The paper.
The idea that the sound can extract the data violates the Nyquist–Shannon sampling theorem.
Don't tell me, tell them. Review their paper, find the flaws in it, and tell them. That's what peer review is about.
Re: (Score:2)
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: (Score:3)
As long as you never need to decrypt your data ever again, you can make it 100% safe from prying eyes.
Re: (Score:2)
Just run in the background a "Random Noise Generator"
And what program do you propose to use that generates Random Noise?
Comment removed (Score:5, Funny)
Re: (Score:2)