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.
Even if they have my RSA keys, they don't have my RSA locks!
How is this not a reiteration of this old attack from 2014: http://www.tau.ac.il/~tromer/h...
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. All this fancy tech can be beaten by a low tech method. A blow to the face. The same low tech method can also obtain passwords from victims.
Play an MP3 at the same time so they get a audio download then send them a DCMA takedown notice :)
Just look at the open source, and then adapt your eves dropping to accommodate. This is where closed source prevails. No leaking implementation details.
Some of us know how to RTFB.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
I wonder how vulnerable smart cards are. In particular, I've been using an YubiKey for most of my RSA needs.
The Open source implementation Is WEAKER since we now know HOW they perform the DUMMY CALCULATIONS.
Yes, because obviously they were going to perform exactly the same dummy calculations every time in exactly the same place.
Oh, no, wait, not everyone is as dumb as you.
systemd is Roko's Basilisk.
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." -
These "attacks" are always on carefully selected hardware running custom software. There is no way on a real system this would work.
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.
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.
upon the advice of my lawyer, i have no sig at this time
Wonkey monkey may not have done but ive got quite familiar with it over the last 3 days. Your assumption was pretty stupid to be fair. And incorrect.
Whilst I am prepared to accept the findings of this research and happy to accept that in principle it is possible to infer the calculations being performed by a computer system using nothing more than the "background noise", they produce, I have to believe that there are a myriad of easier ways that the same information could be obtained:-
https://xkcd.com/538/
It is likely that these attacks may be attempted by government agencies looking to crack encryption operated by foreign powers. However, in the majority of the cases I've personally looked at, I see poorly-implemented surrounding controls. Issues include having passphrase data stored on a computer so that an application can decrypt traffic without human intervention, only to have that passphrase file left protected by nothing more than local file system permissions. Let's be honest, owning the file with root and setting permissions to rw-/---/--- aren't going to pose much of a problem to a determined attacker, are they?
This is one of the fundamental issues with encryption: people believe that because they are using high strength key lengths that they are secure; no thought is given to local protection of critical data, to PRNG entropy, to side channel data.
Too many people get blinded by, "Oh, it's OK, it's encrypted", when that means squat if the related safeguards are compromised...
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.
This possibly can't be real or, these guys are geniuses. Certainly the coil whine will change depending on the load of the machine. However, there's so much stuff happening in a CPU and the system bus that I find it extremely hard to believe that you could listen to any specific numbers. There's also all sorts of power filtering going on and there's decoupling capacitors on the chips.
However, if this is real, then I assume that listening to network traffic would be doable as well.
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.
How the hell do they isolate the key from all that is going on around it?
The term is EAVESDROPPING.
In order to obtain the laboratory effect of single threaded decryption of 4,096 approximately 1Mbit files in sequence you would have to be root and generally have all "messy" asynchronous processing such as interrupts from the network card disabled. This is a lab-only non-realistic attack. If you had that much control over the CPU you might as well just read the key out of the registers as it is used.
If it has a self deploying parabolic microphone that aims at the target, I'll be firstly impressed, and secondly take it apart for the very cool servo deployable parabolic dish and aiming system.
Do not look at laser with remaining good eye.
https://youtu.be/DU-HruI7Q30
In GOD we trust, all others we monitor.
How do they come up with this stuff? Seriously?
If your outlet is in/near a corner, it's already got a half-assed parabolic to use. The casing could be modified to act like a stethoscope, no parabolic needed then.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Yep! Couldn't recall what the brand name on them were. Had a customer (big health care org) that had a dozen or so of them on their DC floor. It was virtually impossible to have a conversation anywhere near that area of the data center. I imagine if OHSA ever somehow wondered in there they would have had the admins wearing hearing protection by the end of the day. I felt bad for the EMC tech who always seemed to be there replacing a drive or other parts on them. Poor bastard was probably deaf.
I browse on +1 so AC's need not respond, I won't see it.
It's British humour (that's British English for humor). I love it. And it's much better website than all other copy-paste tech news sites with 50 ads and 200 trackers.
Saturation is more a factor of voltage, not current. But more current through an inductor requires a larger window (hole in core) and so more ferromagnetic material. Also, reducing saturation requires more winding turns (less volts per turn) and so a larger winding and bigger core. More core material will produce more sound, since magnetostriction is a percent change in the core dimensions due to flux density.
Mechanical damping is probably not feasible, since the materials (steel, nickel, cobalt, etc.) involved are very stiff and the damping structure would have to act against that. Encapsulating inductors in some sound deadening material could work. But it would interfere with thermal performance.
Have gnu, will travel.
Now I can't access the drive at ALL!! I'm really hoping it comes back I have a lot of photos and music that aren't backed up. Also, the knocking is still there.
d-_-b
This kind of defence (and, indeed, the masking described in TFS) don't normally work against this kind of side-channel attack. They increase the noise, but there's still signal. All that they do is drive up the number of samples that you need to be able to run the analysis. If you're lucky, then the number of samples that they need is more than the number of samples that they can record in the available time, but for long-lived keys this can be a very long time. It's also worth noting that with this kind of thing you don't need to recover the entire key - if you have the public key, then you can quickly verify whether a guess at the private key is correct. Over time, as you record the samples, you gain a greater probability of each bit being 0 or 1. You run a directed brute force attack, with the bits with the least confidence being flipped more frequently.
I am TheRaven on Soylent News
It doesn't matter. The dummy calculations add noise. You can filter it out by taking more samples (this is a well-known countermeasure in the side-channel literature). The attack is already designed to work with a noisy source, the defence just makes it more noisy.
I am TheRaven on Soylent News
Forgive my ignotance, but is this encryption running on a separate CPU with separate power supply coils etc from the mp3 decode?
The volume doesn't matter if you hit the right frequencies. With the wrong ones, they're usually still trivial to separate out on sophisticated equipment, though it might drown out a cell phone microphone. But, creating the audio files and playing them is fairly simple for anyone who knows what frequency range to hit. But, the simple act, much less the creation and implementation of these counter-measures puts it outside 90%+ of the worlds userbase. As usual, the biggest threat to IT security is the idiot between the keyboard and the chair.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
No but, I get the impression from reading all of this that the decryption sequence can somehow be isolated from all of the other high frequency noise the CPU puts out while doing other tasks. Don't ask me how; that's out of my pay grade.
"Be particularly skeptical when presented with evidence confirming what you already believe." -
I doubt the cellular phone even needs to be hacked. Half the people around you probably already have an app around that's already listening (but don't worry, they say they're not).
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.
Maybe we should go back to pen and paper and snail mail. Do you think that the microphone pickup of pen scratching could follow what was being written?
Why do we have to encrypt a file with AES and one key. Why not alternate allow encrypting 8/16 bytes with one key and the next 8/16 bytes with an alternative key. One algorithm or both could be AES, with the other, twofish. And use cypher block chaining.
Leslie Satenstein Montreal Quebec Canada
If your outlet is in/near a corner, it's already got a half-assed parabolic to use. The casing could be modified to act like a stethoscope, no parabolic needed then.
I wondered why the neighbor's satellite dish was pointed at my house, not the equator.
Star Trek transporters are just 3d printers.
They were sampling around 1.7 MHz for RSA keys.
Since human hearing tops out at 20-25 KHz, most speakers aren't built to emit sounds higher than maybe 30 KHz.
There isn't exactly a huge market for speakers in the ultrasonic range. I'm sure there are some niche cases, but don't expect to find usable hardware or audio samples at the local Best Buy.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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.
Maybe we should go back to pen and paper and snail mail. Do you think that the microphone pickup of pen scratching could follow what was being written? Why do we have to encrypt a file with AES and one key. Why not alternate allow encrypting 8/16 bytes with one key and the next 8/16 bytes with an alternative key. One algorithm or both could be AES, with the other, twofish. And use cypher block chaining.
Pen and paper? People are LAZY. They don't even type into their cell phones anymore, they speak to dictate commands, and use a fingerprint rather than a complex passcode. And while there are many of us that recognize the additional benefits of using multiple encryption methods/ciphers/algorithms, unless you make that the baseline, people will continue to be LAZY and do the bare minimum.
People despise real security because that takes effort to create those long complex passwords and remember them. It takes effort to remember where they put their 2FA token, so forget 2FA. It takes effort to click a few more buttons to encrypt backup files. I'm still amazed when I hear about someone being involved in an automobile accident how they would have been fine had they taken 5 seconds to buckle up. Even physical security can be a burden on the lazy human. Sad, but true.
Would it be possible to simply turn on a radio or have a random whine noise generating device?