Slashdot Mirror
Scientists Extract RSA Key From GnuPG Using Sound of CPU
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."
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.
Bruce Perens.
Impressive.
That is seriously cool...
I will be playing Nirvana at max volume whenever I am decrypting shit from now on
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.
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.
Traveling through gaseous air?
On a more serious note, they're doing power analysis using DC/DC coil whine as a proxy.
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.
Adi Shamir of RSA fame.
I'm turning off the web server right now!
#DeleteChrome
Was this a single core?
Or a dual+ core doing nothing else at the time?
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."
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.
Occasionally living proof of the Ballmer peak.
Just run in the background a "Random Noise Generator"
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.
-- You are in a maze of little, twisty passages, all different... --
You could have spent 5 minutes to skim the page where they address your questions.
I run a quantum computer. Good luck getting noise from that.
---- Booth was a patriot ----
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.
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.
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.
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?
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
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.
but up to four meters have been successfully tested
Were they all the same size?
systemd is Roko's Basilisk.
I need to borrow one from biology lab tomorrow and see those sounds could be heard with that :)
They address both multitasking and multiple cores. They say multiple cores makes the attack easier.
It stands to reason that it makes a sound that no knows... Perhaps Joff-tchoff-tchoff-tchoffo-tchoffo-tchoff?
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.
This only works if the computer is decrypting known files for an hour. It would be very difficult to exploit in practice.
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.
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.
Seriously. RTFA...
EOL.
Old age and treachery almost always overcome youth and skill.
I'm so glad to know they examined the *acoustic* sound (or the acoustic *sound*, even) instead of any sort.
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
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
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
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.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Blown.
"If any question why we died, Tell them because our fathers lied."
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:
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).
We don't see the world as it is, we see it as we are.
-- Anais Nin
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.
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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).
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.
It has been duplicated. This is not the first time sound has been used to crack crypto operations running. It's been done for decades to crack crypto machines and specialized chips, although I think this is the first time it's been published on as commonly used software as GnuPG.
It's in the class of side-channel timing attacks. Other published exploits in this class are leaks via network latency--where the attacker will systematically negotiate a ton of SSL connections and analyze timing--and via pre-emptive multitasking--where you can crack a key running on another process, or even another VM instance.
These attacks are so well known that most modern AES implementations, in both software and hardware, have been tweaked so they don't leak key material via timing vectors. Doing this for public-key cryptography is more difficult because of the extensive use of multiplication and division, and because you'd need to refactor the bignum libraries being used, which is pretty intrusive and might lead to other bugs.
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).
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 to cover, and i would guess that any attempt to counter this kind of attack would only make the situation worse.
as far as i can guess this kind of attack should be feasible on any block cipher.
did we not know this was coming?
block cipher in counter mode DOES NOT EQUAL csprng.
quod, as has been, demonstrandum.
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 are interested in the data. Doing an instruction on any data should cause the same power draw so how do they extract the data?
Then you have answer 8
"Individual CPU operations are too fast for a microphone to pick up, but long operations (e.g., modular exponentiation in RSA) can create a characteristic acoustic spectral signature over many milliseconds, and these can be detected. In the chosen-ciphertext key extraction attack, we carefully craft the inputs to RSA decryption in order to maximize the dependence of the spectral signature on the secret key bits."
So it can only work with some keys?
For the multi core issue CPUs have a single VCC so you have no idea what core is doing want if it is even possible to extract the pattern since the claim it is the power draw on the voltage regulators that cause the sound.
The summary really does not answer the questions. The idea that the sound can extract the data violates the Nyquist–Shannon sampling theorem. There should be no way a multi khz audio signal can carry the data of the exection of data at over 1 Ghz. Even the statement that they extract the key over half an hour is just illogical. How much data can a modern PC encrypt with half an hour execution time?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
rsa is usually run on a simple counter, and this output is only then xor'ed with your data.
Put toddlers around the office to drown out the CPU sound.
Table-ized A.I.
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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, ruined this approach by cutting up the signal of interest and mixing it with bits from other programs running "simultaneously". Then the march of Moore's Law and its variants nailed up the coffin by cutting the run time of most stuff of interest down to such short periods that even a bat couldn't get anything useful from their radio-to-accoustic signatures.
But modern cryptography involves deliberately long computations, on machines that are otherwise so fast that other tasks are mostly idle,. So the technique rises from the grave...
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
My machines are far too loud. it would be almost completely white noise from fans/pumps/ and hdd's. This concept seems a bit far fetched and would need multiple sources of confirmation to even start considering it's possible to extract any useful crypto information this way.
The idea that the sound can extract the data violates the Nyquist–Shannon sampling theorem.
Only if you apply the theorem like that to a one shot recording of some signal. if you have a repeating signal, you can get much more data out of it even if under-sampled. This is regularly used by ADCs to measure signals orders of magnitude faster than their sampling rate, by having a repeating signal that is recorded many times.
who swallowed a fly...
rsa is already busting it's square little heart trying to scramble your data, now you want another cipher to generate random noise to mask the regular patterns your initial cipher is making. what masks the patterns your new cipher produces - yet another cipher?
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?
>What sounds does a cpu make?
Obligatory (you knew it was comming): If a cpu falls in a forest, and no one hears it, does it make a sound?
OK, second try: If a cpu is decrypting in a forest ...
third try: If a cpu is decrypting in a forest and the NSA isn't listening ...
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.
Please help metamoderate.
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.
Sounds like this method relies on the encryption algorithm being known, possibly to the point of the exact instructions used in the encryption loop. If that's the case, then it can be easily beaten by generating a slightly mutated/modified version of the encryption algorithm (by adding superflous operations to it, that do not change the results and/or randomly replacing complex operations, like multiplications, by different number of additions, etc) periodically, at random intervals, and using that to encrypt the data streams. This would an additional variable - besides the encryption key itself - to the process, which in turn would prevent the encryption key itself being deduced by statistical means.
TFA did not mention the particular fix to the problem, so I'll speculate. They mentioned that zeros would cause a recognizable branch, so choices are: make the code non-branching, or make the timing of the branch for zero the same as not branching. Other possibilities include inserting pseudo-random delays in the code, processing sections of the message out of order (randomly), and interspersing decoding of bogus messages with the decoding of the real message.
Contribute to civilization: ari.aynrand.org/donate
Who cares what sound a CPU makes, what does the fox say?
Neither was Linus Pauling.
You can be a genius and a quack at the same time, as despite what you might think, they are not mutually exclusive.
They're interested specifically in the instructions.
They inject crafted data in to GnuPG designed to hit various branches in the code. Listening for which branches get hit and which ones don't give them clues to figure out the encryption key.
There's an if test in GnuPG's modulus implementation that is based on the size of the cypher text verses the size of the private key. So if you control the cypher text, you can cause one of two different outcomes from this comparison based on the next unknown bit of the private key.
In a loop with 2048 iterations, a decision is made from this intermediate value. Causing one of two different multiplication methods to be used for every iteration of this loop.
From listening to (probably) the noise of a capacitor in the CPU's power regulator you can hear the difference between these two code paths and extract one bit of the private key.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
http://it.slashdot.org/story/09/07/12/0259246/stealing-data-via-electrical-outlet
http://it.slashdot.org/story/09/03/26/1947246/laser-sniffing-captures-typed-keystrokes-from-50-100-feet
http://it.slashdot.org/story/09/03/12/2038213/researchers-sniff-keystrokes-from-thin-air-wires
http://hardware.slashdot.org/story/08/10/20/1248234/compromising-wired-keyboards
http://it.slashdot.org/story/08/05/01/0354211/nsa-releases-historical-documents-on-tempest
http://politics.slashdot.org/story/07/01/18/152205/deathblow-to-a-voting-machine
http://politics.slashdot.org/comments.pl?sid=217546&cid=17664882
http://it.slashdot.org/story/02/03/09/199242/crt-eavesdropping-optical-tempest
http://news.slashdot.org/story/01/11/26/2353252/generate-am-radio-broadcasts-with-your-monitor
http://yro.slashdot.org/story/01/01/16/139244/nsa-reveals-some-tempest-information
http://yro.slashdot.org/story/01/01/01/2310241/cryptome-posts-just-released-tempest-documents
http://yro.slashdot.org/story/99/11/08/093250/coming-to-a-desktop-near-you-tempest-capabilities
http://hardware.slashdot.org/story/99/08/21/1736251/making-music-with-cpu-activity
http://tech.slashdot.org/story/99/07/19/1324207/super-shielded-pc-cases
http://www.slideshare.net/daniel_bilar/acoustic-20131218
A link that's not Slashdotted (yet).
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
Shazam does this to a certain extent. I can use Shazam in s busy store with lots of background noise, or in my car driving on the freeway with a lot of engine and road noise and it still easily picks up and recognises a song through the noise. If a home brew phone app can do that, It's not beyond the realms of imagination that the clever people can build something similar with a lot more smarts.
I'm not sure I'd qualify that guy as a "peer" to review...
You, sir, are a moron.
The first piece of music played on a computer was done that way on an Apple ][. The song it playes was _Daisy_.
Supposedly, HAL sings that song as he dies as a sort of racial memory.
It would appear that this attack is only relevant to “dumb” systems that use RSA for bulk encryption/decryption. Properly designed systems (e.g. S/MIME) would always use a much more efficient symmetric (wrapping) key for “user-data” crypto and then RSA just to protect that tiny wrapping key. Similarly, RSA only needs to protect the small hash of a digital signature. In these systems, there is *no* bulk RSA decryption to listen in on!
From what I muster, it's far from exploitable in real-life scenario. Still impressive though, and this might broaden the way peoples see side-channel attacks on general computers, and not only on specific hardware.
Still, http://www.debian.org/security/2013/dsa-2821
For code signing at work, we got some Yubikeys. I imagine they are less vulnerable to this type of attack...
...only we're not in April.
If a CPU hums in a forest and no one is around to hear it, does it make a sound?
Changelog:
Changes for the versions:
Installed version: 1.4.11-3ubuntu2.4
Available version: 1.4.11-3ubuntu2.5
Version 1.4.11-3ubuntu2.5:
* SECURITY UPDATE: RSA Key Extraction via Low-Bandwidth Acoustic
Cryptanalysis attack
- debian/patches/CVE-2013-4576.dpatch: Use blinding for the RSA secret
operation in cipher/random.*, cipher/rsa.c, g10/gpgv.c. Normalize the
MPIs used as input to secret key functions in cipher/dsa.c,
cipher/elgamal.c, cipher/rsa.c.
- CVE-2013-4576
Just wow.
This is why you should always have your computer's volume set to 100% and to adjust speaker volume at the amplified speaker. And/or use a digital output.
Since they're attacking using high frequency sound, maybe have the machine emit some random noise in the same spectrum using its sound hardware while encrypting or decrypting or performing key generation. Wouldn't something like that jam such an attack (at least from a distance; if someone got microphones into your hardware that might be a different story)?
I wish I hadn't already commented, as I'd love to mod this a little higher.
I get that and the length of time to extract the data all would seem to make this a very improbable method for a practical exploit.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I did read the entire paper. Using the methods they used it does not seem to be a practical attack vector at all. In fact I would say that you would have to have detailed specific information of the computer being exploited. Not even just the model but the actual computer since things like the age of the caps will make a difference.
On a danger scale of 1 to 100 this is about a 1. I should have made it more clear that I was more suggesting that this is wildly impractical verses theoretically impossible. Frankly it might even work one week and not the next.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I recall the first gen sound cards would play a lot of bus-noise until they worked out how to properly isolate the dirty power from the amplifier.
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
Using most generally-available consumer equipment, it probably was. We've come a long way in terms of consumer tech though, especially in terms of miniaturization.
You assume there's just one Adi Shamir in the whole world? And even if that's true... there would not be any chance someone else would wrongly call themselves the name of a celebrity to get attention, right?
Its relevant to the ability of something taking audio sample at 8000 Hz being able to extract information that is being produced at rates that are order of magnitude greater.
Right, because most people use all their other cores to run a nice convenient infinite loop of ADD instructions.
It doesn't make the attack easier, it "could" make the attack easier, under a particular and highly unrealistic scenario.
Lots of things in this article made me suspicious or sometimes laugh out loud. Here are just a few: ...
The article has not been published in a journal.
It uses up valuable article real-estate to include a content-free picture of a tree with 64, then 32, then 16,
Listing the parts numbers of the setup like it came from a Radio Shack catalog
Elaborate description of how to place said Austin Powers style Radio Shack microphone.
Then saying that equipment barely matters and that we can crack all your codes using a cell phone or laser microphone
Power analysis of the AC outlet also reveals this signal!
Hypothesizing that the attack could be carried out with an agent's "bare hands"
You must harden your systems using cork.
Vague details of how the algo reveals the key one bit at a time. I'm not an expert but I know enough to know that you can't verify that you have found the high order bits of the key without the low-order bits.
what you say makes sense, is much appreciated.