Slashdot Mirror
RSA Keys Can Be Harvested With Microphones (theregister.co.uk)
Researchers have now demonstrated that even with modern laptop, desktop, and server computers, an inexpensive attack can harvest 4,096-bit encryption keys using a parabolic microphone within 33 feet -- or even from 12 inches away, using a cellphone microphone.
An anonymous reader quotes this article from The Register:
In both cases it took an hour of listening to get the 4,096-bit RSA key... As a computer's processor churns through the encryption calculations, the machine emits a high-frequency "coil whine" from the changing electrical current flowing through its components... The team recommends encryption software writers build in "blinding" routines that insert dummy calculations into cryptographic operations. After discussions with the team, GNU Privacy Guard now does this.
How is this not a reiteration of this old attack from 2014: http://www.tau.ac.il/~tromer/h...
Play an MP3 at the same time so they get a audio download then send them a DCMA takedown notice :)
33 feet which is 10 meters, easy to spot, hardly "low key" (ehm) eves dropping. I would imagine the eves dropper would get a bloody nose before getting to the door...
I'll remember you said that when you discover that "innocent" cell phone charger sitting in the corner of your office is actually a microphone with a 64GB microSD card and SIM card inside, dumping a day's worth of key listening across a covert channel, to include your voice conversations.
Or perhaps the device listening will be your cell phone itself. After all, those never get hacked.
Perhaps you should start considering the fact that it's hardly a human sitting in the room listening to high-frequency whine, nor does it need to be. Good luck with your bloody nose defense.
Can someone explain, vaguely, possibly with a car analogy, how they go about determining keys with coil whine? Is it because the same calculations are made over and over as it churns through data encrypting/decrypting it, so after listening long enough some kind of clues can be gathered about what bytes are in the key? I mean, I assume it's not as a simple as listening and going "Ooh, 14.5Khz, that's 0xBE."
systemd is Roko's Basilisk.
That most likely won't work as they can simply discard all noise not part of the frequency range they are looking for which is trivial if the other sounds don't emit that range. As these are ultra-high frequency sounds, no MP3s or even FLAC files will have them as these ranges are discarded to keep the file size down. You'd have to be running the ultra quality studio files to even have a chance of having these ranges play but, as these are ranges that humans can't hear, they are only going to be there by accident, not intent and you won't be able to tell if they do or don't. Now, it would be possible to create audio tracks with these ranges for the express purpose of fouling these sort of attacks but, there would need to be many of them so there can be some form of randomness to prevent prediction attacks. Updating encryption systems to add junk processes at random would be an easier method of thwarting these however, it will take some time for everyone to update.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
Stronger PSU -> Bigger coils. It's the coil core that whines due to magnetostriction.
A laptop won't be of much help. There are a number of buck-boost voltage converters on the motherboard that provide all the different voltage levels needed by the CPU, memory, logic, etc. They use switch mode topologies, which incorporate coils. The alternative, linear regulators, produce a lot of heat due to inefficiency. So laptops are likely going to be better targets.
Have gnu, will travel.
There is a great deal of "carefully selected hardware" in the world, especially in secure civilian and military installations, equipment which could present a broad and lucrative attack surface to such tools. And a good security vulnerability report is also much like a good scientific experiment: enough detail is included to allow clear repetition of the attack, without accidental disparities in the testing conditions obscuring the results.
Glad I stuck to my guns and stayed with rot13
Not if you're looking at a server in a datacentre. The bad guys can just rent a space in the next rack over and you're totally unaware that they're busy vacuuming up your keys for later exploitation.
Just install some of those oldschool EMC storage towers that sound like jet engines running 24/7. Sure your DC employees will go deaf but your keys won't leak!
I browse on +1 so AC's need not respond, I won't see it.
Especially since that loud knocking my hard drive's been making for the past week would totally drown out the coil whine.
I'm hoping that knocking sound goes away. Sometimes these things fix themselves, you know?
Well the good news is that it's pretty much guaranteed to go away on it's own. Now as for the bad news....
I browse on +1 so AC's need not respond, I won't see it.
Reminds me of a differential power analysis attack but that requires physical access to the machine. With this microphone attack you just need to know which type of machine it is and proceed in a completely covert manner.
It always amazes me how inventive a determined attacker can be. On a defense project back in the 90's we had to keep our analog phones six feet away from CRTs to prevent monitor EMI from entering the phone line. That EMI could be analyzed by a third party to recreate the monitor's image.
There is no way on a real system this would work.
Famous last words.
Along with:
"He'll stop, we have the right of way!"
"I'm sure it's unloaded."
"Of course I'm sure that the other guy shut the power off."
"If taking one of these pills is good, taking three means it'll work really fast."
"Oh yeah, it's strong enough to hold us."
"Watch this!"
Just cruising through this digital world at 33 1/3 rpm...
https://youtu.be/DU-HruI7Q30
In GOD we trust, all others we monitor.