Are you only doing one thing on your computer? No.
Does your Memory vibrate when the data is stored? No.
Can data be transferred via acoustics over a 2 conductor 16 gauge wire at the speeds memory is accessed or is sent to the CPU? No.
Think of something you have heard "hum". Is the noise pattern of your Amp and another the same if the "hum is anything other than 60hz? No. Because manufacturing tolerances are not such that the flaws are the same.
This is really great FUD. Likely designed to get People to think that they are constantly at risk, and have the CIA and FBI spend billions buying acoustic shields for their computers.
If this is real. And does work, fine, just run a background task that puts multiple random RSA's through the paces in alternate threads so the extraction can't take place because of garbled data.
EDIT:
Apparently I forgot that HackerNews You get downvoted if you present common sense in face of a fallacy that those with limited understanding want to hold true, as seen by the mass of links to wikipedia made by those with out the foggiest about audio, capacitance, RSA, or Electrical engineering.
This is a very weak dismissal. Have you read the actual details they claim?
Side-channel attacks (like power analysis) in the presence of other activity are well established.
Electrical signals causing audible frequency output are also well established. Look up the piezoelectric effect[1], or magneto/electrostiction[2][3]. The demand for miniaturisation of everything means even at low voltages, there are quite substantial electric fields across small distances, which are enough to flex the material audibly.
On the magnetostriction side, the flyback transformer in old CRT televisions is a perfect example. Myself and many people have been able to tell whether the TV was powered up (even if totally muted) from outside the room (and yes, double-blind tested repeatedly).
What does wire gauge have to do with anything?
On the practicality/data rate issue, a nice quote from the very intro of their paper states:
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.
(emphasis mine)
It seems that the main focus of their work is to fingerprint the crypto and identify that a particular key was used (but not necessarily what the key is), which is a much easier problem than the one they talk about here, which requires specially crafted input over a substantial period of time.
Your solution might work, or it might just lower the SnR of the signal and require filtering larger quantities of data to extract the desired signal again.
The road to crypto-hell is paved with people who thought that they could use their "common sense" to reason intuitively about their problem. But to paraphrase Feynman, Mother Nature is not swayed by persuasive arguments.
I am one of those people who can hear a CRT television from a room or two over. Comes across as a very distinctive high pitched squeal. I always assumed that other people couldn't hear it simply because it was too high.
It actually seemed worse when my LCD TV broke last year and I pulled out my old CRT to watch a movie in the meantime. I don't know if I had just grown unaccustomed to hearing it or what, but it was annoying me even through the sounds of the movie.
Whoa, I had to reread your comment twice to understand it properly. In the context of RSA, and particularly speaking about its weaknesses, for me "CRT" automatically stands for "Chinese Remainder Theorem"… :-D.
If that interest someone, look for the BellCoRe attack on CRT-RSA [1,2]. I'm also working on the countermeasure as part of my PhD [3,4], and it's quite some fun!
Thanks for your constructive reply. Your exact statement was:
Can data be transferred via acoustics over a 2 conductor 16 gauge wire at the speeds memory is accessed or is sent to the CPU? No
Which is of course true, if you're talking about >GB/s signals over wide buses.
But we're not. So I don't see why it's relevant here.
These attacks are not "sniff the actual data the CPU is flinging around by coupling to signal traces", so they don't need anything like full data-rate capability.
Edit: On re-reading your claim again, I noticed the phrase "transferred via acoustics over a 2 conductor 16 gauge wire" is a bit ambiguous.
Do you mean transferred electrically over those wires, but limited to the typical acoustic frequency band (say, 0-20kHz)? Or do you mean actually acoustically coupled as mechanical vibrations of the wire itself? I can't imagine it makes any difference to my argument above, but I do wonder.
just run a background task that puts multiple random RSA's through the paces in alternate threads so the extraction can't take place because of garbled data.
Adding randomness does not remove detectable, statistically-significant information. It just takes more trials to extract it. This is the basis of many side-channel attacks. Super-trivial example: if you roll a super-weighted die and it shows 6 every time it's obvious, but if it's only barely weighted it'll still be detectable with enough rolls, to the same level of confidence (since getting 6 one hundred times in a row is not impossible with a fair die).
Roll a 24 sided di a 6 sided di a 12 sided di and 2 dozen di picked of random sizes each roll, and a Di that always rolls 6 but is only included once every Random rolls.
Determine a method given only the SUM of the di to determine the value of the weighted di.
Since the attacker has control over when the weighted die is added in this case (an on/off switch that includes it once in every 6 rolls, but we don't know how many rolls it takes to "use" it), yes, you can.
Roll the die with it "off" a few billion times. You now have a very-consistent prediction about the range and probability of each value. Throw the switch to "on", roll a few times until you're sure it has been used up, then turn it off. Repeat a few billion times. Since the computation finishes at some point, the weighted die's influence will exist most-strongly at the beginning.
You're left with a crap-ton of random-ish fluctuations that over time shows a slight bias to being larger at the start (compared to "off"), after you turned it on. Since you know it's included once every 6 times (I'm assuming random here, to make it harder), it will be the distribution for 1/6th the size of the weighted value (or something similar, I forget exactly). If it wasn't randomly included, then you should see spikes every 6th round.
--
Note that this does not require knowing that you had dice at all, nor knowing how many, nor knowing that there is always a 6, 12, and 24 sided die in the mix and 2 dozen others. If you knew that, you could be more confident about what a normal distribution looked like, so you could finish earlier.
No. The attacker has control over what time period, not how many rolls.
You don't have the level of control you think. You are assuming that you will know exactly. When in truth you will only know approximately.
The human analogy falls down because we are slow. But with computers you would be controlling it from a distance, and latency would mean you wouldn't know exactly when.
Latency is just another bit of randomness. There have already been examples of using latency across the internet to extract encryption keys because e.g. someone didn't compare the checksum to the entire string and simply stopped once it was clear it wasn't valid. That's detecting nanosecond differences across a hundred-millisecond extremely noisy channel.
Besides, if you can get the output, you can tell how many rolls occurred, so it doesn't really matter. And this is a "chosen cyphertext" example, so the attacker has some idea of how long the computation will take under certain circumstances.
Really? That's why we took so many years building HDMI? You can send that kind of data over the air as sound? and down a cable? What were we thinking? All this bother with radio waves, and compression, and hundreds of conductors?
Telephone with two cans and a string works. But not well enough that you can convert your Vinyl to OGG.
I most certainly hear noises other than 60Hz hums, coming from capacitors which correspond to what the computer is doing, including from my current PC. It's called the piezoelectric effect: http://product.tdk.com/capacitor/mlcc/en/faq/faq00031.html
I'll add that it is obvious when certain types of calculation start, too. It's neat to be able to point to this and say I wasn't crazy to a few friends who didn't believe me.
On an older computer an animated gif on a web page caused my speakers to feedback differently than playing video (and this worked even when the sound card was muted). And the signals never fully masked each other. I always suspected it was a grounding fault, but it was subtle and generally unobtrusive so I never tried to fix it (it's almost a feature, like a blinking hard drive light).
Notably it is far easier to hear through the amplifier that is the sound card, but even with no speakers, a quiet room will still show the same. As others noted above, CRT monitors are notoriously loud, and you can definitely hear different image patterns.
I can also get a good idea whether the CPU is idle or doing some particular task just by listening to the motherboard. This isn't any sort of paranormal effect, it's quite audible. I suspect most of it comes from the inductors on the CPU vcore DC-DC converter.
For me, the sounds I hear are somewhat like this:
Animated GIF = chuff-chuff-chuff, one chuff per frame transition
Scrolling terminal window = low hissing, like someone slowly breathing out
Dragging window around the screen = high-pitched whine
CPU stress test = very high-pitched whistling
Loading a big app = a more noisy hiss than scrolling the terminal window, interspersed with HDD sounds
I was tested at a young age to have above-average hearing range, so maybe that also has a factor in how well you can hear these things; I don't listen to loud music or subject myself to loud noises either.
And again, if you your only doing one thing at a time that might work. But if you are doing multiple things you aren't going to extract that.
If you had an old 286 you might be able to hear peizo's but your laptop doesn't have many of the old style caps that hum with any appreciable noise. Your power isn't clean enough that you can separated the other noises, and with Wifi enabled you have all sort of other noises.
What is described here isn't possible with acoustics. Anyone with even a rudimentary understanding of Audio can see that.
Brandon Wirtz
SMPTE Committee Member for the H.264 and VC1 audio and video standards (someone with rudimentary understanding of audio)
Have you read the paper yet? You might be interested in figures 7-9, which show spectrographic measurements of exactly what you're claiming is impossible. Sections 4 and 5 go on to describe how you can use these measurements to get fairly accurate timing information about individual RSA key operations. What you seem to be missing is that, even though the audio bandwidth isn't nearly high enough to resolve individual CPU instructions, aggregated timing measurements can still leak a substantial amount of information. This is well-established in the crypto literature, and it's now standard practice to write code robustly to this sort of attack by making the timing data-independent.
As a side note: it's not clear to me what being an "SMPTE committee member" entails, or why it confers any special expertise about cryptographic side-channel attacks. I only point that out because you've mentioned it in two separate comments now, and I don't see why it's relevant.
SMPTE in this case is relevant because the claims aren't defensible under the rules of Physics. You can't push the stuff they are claiming though Air, or with microphones. There is one claim in there about the capacitance of a human that I can't provide counter claims for, because I really don't know, but basically you can't move the kinds of data they are talking about via Air, sound, and mic cables.
Once you realize that doesn't work everything else is irrelevant.
If you can name a single specific claim that you don't think is defensible, I might be inclined to take your argument more seriously. But so far, everything you've said is a vague generality that continues to support my theory that you haven't read the paper and don't understand the method being described.
The claim that there is a significant difference in the emitted sound from a capacitor based on the value of an RSA Key. May or may not be true.
That that sound is significant enough that you can use a microphone, to pick it up from a distance greater than a fraction of an inch is implausible.
That the sound difference is such that it can be captured with any of the setups pictured in the paper is impossible. There are systems designed for frequency isolation that do megahertz sampling rates which you could convince me are capable of reading the 1's and 0's out of a 286. The frequencies of modern electronics that is simply not possible.
That the sound difference is such that it can be captured with any of the setups pictured in the paper is impossible. There are systems designed for frequency isolation that do megahertz sampling rates which you could convince me are capable of reading the 1's and 0's out of a 286. The frequencies of modern electronics that is simply not possible.
They are claiming to pick up a rather large algorithm change in code that runs for dozens of milliseconds to extract a single bit. A loop taking a bit over 26 vs. a bit over 28 microseconds in the example (or something reasonably close to that description). Why would this need such high-end equipment to pick up?
That's a claim that the authors aren't making. As has been repeatedly pointed out, the attack depends on timing the execution of blocks of code which take much longer than a single instruction, so the 44.1kHz sampling rate described in the paper is sufficient.
Are you only doing one thing on your computer? No.
You seem to be implying that doing multiple things on a computer means that every single side channel will be masked by noise indistinguishable from random. This is obviously false. Cryptographically secure random data doesn't just appear out of nowhere.
I'm not even concerned with the credibility of this article; side channel attacks are old news and will continue to be a threat for a long time (I'm guessing we don't even understand physics well enough yet to eliminate them completely, so there will still be new breaks all the time for the near future). Luckily, everyone is still too busy trying to remove their remote code vulnerabilities to deal with real issues like side channel attacks.
Comments
This is a really well written fake.
Use some common sense.
Are you only doing one thing on your computer? No.
Does your Memory vibrate when the data is stored? No.
Can data be transferred via acoustics over a 2 conductor 16 gauge wire at the speeds memory is accessed or is sent to the CPU? No.
Think of something you have heard "hum". Is the noise pattern of your Amp and another the same if the "hum is anything other than 60hz? No. Because manufacturing tolerances are not such that the flaws are the same.
This is really great FUD. Likely designed to get People to think that they are constantly at risk, and have the CIA and FBI spend billions buying acoustic shields for their computers.
If this is real. And does work, fine, just run a background task that puts multiple random RSA's through the paces in alternate threads so the extraction can't take place because of garbled data.
EDIT: Apparently I forgot that HackerNews You get downvoted if you present common sense in face of a fallacy that those with limited understanding want to hold true, as seen by the mass of links to wikipedia made by those with out the foggiest about audio, capacitance, RSA, or Electrical engineering.
-Brandon Wirtz SMPTE
This is a very weak dismissal. Have you read the actual details they claim?
Side-channel attacks (like power analysis) in the presence of other activity are well established.
Electrical signals causing audible frequency output are also well established. Look up the piezoelectric effect[1], or magneto/electrostiction[2][3]. The demand for miniaturisation of everything means even at low voltages, there are quite substantial electric fields across small distances, which are enough to flex the material audibly.
On the magnetostriction side, the flyback transformer in old CRT televisions is a perfect example. Myself and many people have been able to tell whether the TV was powered up (even if totally muted) from outside the room (and yes, double-blind tested repeatedly).
What does wire gauge have to do with anything?
On the practicality/data rate issue, a nice quote from the very intro of their paper states:
(emphasis mine)
It seems that the main focus of their work is to fingerprint the crypto and identify that a particular key was used (but not necessarily what the key is), which is a much easier problem than the one they talk about here, which requires specially crafted input over a substantial period of time.
Your solution might work, or it might just lower the SnR of the signal and require filtering larger quantities of data to extract the desired signal again.
The road to crypto-hell is paved with people who thought that they could use their "common sense" to reason intuitively about their problem. But to paraphrase Feynman, Mother Nature is not swayed by persuasive arguments.
[1] https://en.wikipedia.org/wiki/Piezoelectricity
[2] https://en.wikipedia.org/wiki/Magnetostriction
[3] https://en.wikipedia.org/wiki/Electrostriction
I am one of those people who can hear a CRT television from a room or two over. Comes across as a very distinctive high pitched squeal. I always assumed that other people couldn't hear it simply because it was too high.
It actually seemed worse when my LCD TV broke last year and I pulled out my old CRT to watch a movie in the meantime. I don't know if I had just grown unaccustomed to hearing it or what, but it was annoying me even through the sounds of the movie.
Whoa, I had to reread your comment twice to understand it properly. In the context of RSA, and particularly speaking about its weaknesses, for me "CRT" automatically stands for "Chinese Remainder Theorem"… :-D.
If that interest someone, look for the BellCoRe attack on CRT-RSA [1,2]. I'm also working on the countermeasure as part of my PhD [3,4], and it's quite some fun!
[1] http://cryptome.org/jya/smart.pdf
[2] http://eprint.iacr.org/2012/553
[3] http://eprint.iacr.org/2013/506
[4] http://eprint.iacr.org/2013/810
If you have to ask any of the rest of your arguments are invalidated.
Thanks for your constructive reply. Your exact statement was:
Which is of course true, if you're talking about >GB/s signals over wide buses.
But we're not. So I don't see why it's relevant here.
These attacks are not "sniff the actual data the CPU is flinging around by coupling to signal traces", so they don't need anything like full data-rate capability.
Edit: On re-reading your claim again, I noticed the phrase "transferred via acoustics over a 2 conductor 16 gauge wire" is a bit ambiguous. Do you mean transferred electrically over those wires, but limited to the typical acoustic frequency band (say, 0-20kHz)? Or do you mean actually acoustically coupled as mechanical vibrations of the wire itself? I can't imagine it makes any difference to my argument above, but I do wonder.
Apparently you didn't read it, but nevermind.
Specifically this:
Adding randomness does not remove detectable, statistically-significant information. It just takes more trials to extract it. This is the basis of many side-channel attacks. Super-trivial example: if you roll a super-weighted die and it shows 6 every time it's obvious, but if it's only barely weighted it'll still be detectable with enough rolls, to the same level of confidence (since getting 6 one hundred times in a row is not impossible with a fair die).
Roll a 24 sided di a 6 sided di a 12 sided di and 2 dozen di picked of random sizes each roll, and a Di that always rolls 6 but is only included once every Random rolls.
Determine a method given only the SUM of the di to determine the value of the weighted di.
Since the attacker has control over when the weighted die is added in this case (an on/off switch that includes it once in every 6 rolls, but we don't know how many rolls it takes to "use" it), yes, you can.
Roll the die with it "off" a few billion times. You now have a very-consistent prediction about the range and probability of each value. Throw the switch to "on", roll a few times until you're sure it has been used up, then turn it off. Repeat a few billion times. Since the computation finishes at some point, the weighted die's influence will exist most-strongly at the beginning.
You're left with a crap-ton of random-ish fluctuations that over time shows a slight bias to being larger at the start (compared to "off"), after you turned it on. Since you know it's included once every 6 times (I'm assuming random here, to make it harder), it will be the distribution for 1/6th the size of the weighted value (or something similar, I forget exactly). If it wasn't randomly included, then you should see spikes every 6th round.
--
Note that this does not require knowing that you had dice at all, nor knowing how many, nor knowing that there is always a 6, 12, and 24 sided die in the mix and 2 dozen others. If you knew that, you could be more confident about what a normal distribution looked like, so you could finish earlier.
No. The attacker has control over what time period, not how many rolls.
You don't have the level of control you think. You are assuming that you will know exactly. When in truth you will only know approximately.
The human analogy falls down because we are slow. But with computers you would be controlling it from a distance, and latency would mean you wouldn't know exactly when.
Latency is just another bit of randomness. There have already been examples of using latency across the internet to extract encryption keys because e.g. someone didn't compare the checksum to the entire string and simply stopped once it was clear it wasn't valid. That's detecting nanosecond differences across a hundred-millisecond extremely noisy channel.
Besides, if you can get the output, you can tell how many rolls occurred, so it doesn't really matter. And this is a "chosen cyphertext" example, so the attacker has some idea of how long the computation will take under certain circumstances.
I don't think Adi Shamir is interested in writing fake articles and a fake paper about the same topic:
http://www.tau.ac.il/%7Etromer/papers/acoustic-20131218.pdf
Of course you can.
Really? That's why we took so many years building HDMI? You can send that kind of data over the air as sound? and down a cable? What were we thinking? All this bother with radio waves, and compression, and hundreds of conductors?
Telephone with two cans and a string works. But not well enough that you can convert your Vinyl to OGG.
Of course you don't need anything approaching OGG or HDMI fidelity in the attack described.
Do some reading about processing on cyclostationary signals. Correlation is basically God's own free lunch.
I most certainly hear noises other than 60Hz hums, coming from capacitors which correspond to what the computer is doing, including from my current PC. It's called the piezoelectric effect: http://product.tdk.com/capacitor/mlcc/en/faq/faq00031.html
I'll add that it is obvious when certain types of calculation start, too. It's neat to be able to point to this and say I wasn't crazy to a few friends who didn't believe me.
On an older computer an animated gif on a web page caused my speakers to feedback differently than playing video (and this worked even when the sound card was muted). And the signals never fully masked each other. I always suspected it was a grounding fault, but it was subtle and generally unobtrusive so I never tried to fix it (it's almost a feature, like a blinking hard drive light).
Notably it is far easier to hear through the amplifier that is the sound card, but even with no speakers, a quiet room will still show the same. As others noted above, CRT monitors are notoriously loud, and you can definitely hear different image patterns.
I can also get a good idea whether the CPU is idle or doing some particular task just by listening to the motherboard. This isn't any sort of paranormal effect, it's quite audible. I suspect most of it comes from the inductors on the CPU vcore DC-DC converter.
For me, the sounds I hear are somewhat like this: Animated GIF = chuff-chuff-chuff, one chuff per frame transition Scrolling terminal window = low hissing, like someone slowly breathing out Dragging window around the screen = high-pitched whine CPU stress test = very high-pitched whistling Loading a big app = a more noisy hiss than scrolling the terminal window, interspersed with HDD sounds
I was tested at a young age to have above-average hearing range, so maybe that also has a factor in how well you can hear these things; I don't listen to loud music or subject myself to loud noises either.
And again, if you your only doing one thing at a time that might work. But if you are doing multiple things you aren't going to extract that.
If you had an old 286 you might be able to hear peizo's but your laptop doesn't have many of the old style caps that hum with any appreciable noise. Your power isn't clean enough that you can separated the other noises, and with Wifi enabled you have all sort of other noises.
What is described here isn't possible with acoustics. Anyone with even a rudimentary understanding of Audio can see that.
Brandon Wirtz SMPTE Committee Member for the H.264 and VC1 audio and video standards (someone with rudimentary understanding of audio)
Have you read the paper yet? You might be interested in figures 7-9, which show spectrographic measurements of exactly what you're claiming is impossible. Sections 4 and 5 go on to describe how you can use these measurements to get fairly accurate timing information about individual RSA key operations. What you seem to be missing is that, even though the audio bandwidth isn't nearly high enough to resolve individual CPU instructions, aggregated timing measurements can still leak a substantial amount of information. This is well-established in the crypto literature, and it's now standard practice to write code robustly to this sort of attack by making the timing data-independent.
As a side note: it's not clear to me what being an "SMPTE committee member" entails, or why it confers any special expertise about cryptographic side-channel attacks. I only point that out because you've mentioned it in two separate comments now, and I don't see why it's relevant.
SMPTE in this case is relevant because the claims aren't defensible under the rules of Physics. You can't push the stuff they are claiming though Air, or with microphones. There is one claim in there about the capacitance of a human that I can't provide counter claims for, because I really don't know, but basically you can't move the kinds of data they are talking about via Air, sound, and mic cables.
Once you realize that doesn't work everything else is irrelevant.
If you can name a single specific claim that you don't think is defensible, I might be inclined to take your argument more seriously. But so far, everything you've said is a vague generality that continues to support my theory that you haven't read the paper and don't understand the method being described.
The claim that there is a significant difference in the emitted sound from a capacitor based on the value of an RSA Key. May or may not be true.
That that sound is significant enough that you can use a microphone, to pick it up from a distance greater than a fraction of an inch is implausible.
That the sound difference is such that it can be captured with any of the setups pictured in the paper is impossible. There are systems designed for frequency isolation that do megahertz sampling rates which you could convince me are capable of reading the 1's and 0's out of a 286. The frequencies of modern electronics that is simply not possible.
They are claiming to pick up a rather large algorithm change in code that runs for dozens of milliseconds to extract a single bit. A loop taking a bit over 26 vs. a bit over 28 microseconds in the example (or something reasonably close to that description). Why would this need such high-end equipment to pick up?
That's a claim that the authors aren't making. As has been repeatedly pointed out, the attack depends on timing the execution of blocks of code which take much longer than a single instruction, so the 44.1kHz sampling rate described in the paper is sufficient.
You seem to be implying that doing multiple things on a computer means that every single side channel will be masked by noise indistinguishable from random. This is obviously false. Cryptographically secure random data doesn't just appear out of nowhere.
I'm not even concerned with the credibility of this article; side channel attacks are old news and will continue to be a threat for a long time (I'm guessing we don't even understand physics well enough yet to eliminate them completely, so there will still be new breaks all the time for the near future). Luckily, everyone is still too busy trying to remove their remote code vulnerabilities to deal with real issues like side channel attacks.