bit-tech.net

Reseachers grab encryption keys by listening

Reseachers grab encryption keys by listening

Simply placing a mobile phone near to a computer is enough to 'hear' what the CPU is doing and, with effort, to grab the private key being used for decryption, according to a paper by cryptology researchers.

Researchers have come up with what they claim is a means of extracting the private key used in cryptography from a system by simply listening to sounds made by the CPU - or even just by touching the PC's chassis.

The vast majority of modern cryptosystems rely on public-key cryptography, which relies on two pieces of information: a public key which can be provided to all without the need for secrecy, and a private key which - as the name suggests - must be protected from disclosure. Using the public key, anyone can encrypt a document in such a way that only the holder of the private key can decrypt it - with even the person who encrypted it in the first place having no way to recover the encrypted data if no copy was kept.

Keeping the private key private is of vital importance in public-key cryptography, but new research suggests it might not be as easy as first thought. A paper (PDF warning) by Daniel Genkin, Adi Shamir and Eran Tromer claims success in extracting a usable copy of a private key used with popular open-source cryptography package GnuPG - simply by listening to the sounds a computer's CPU makes during processing.

'Many computers emit a high-pitched noise during operation, due to vibration in some of their electronic components. These acoustic emanations are more than a nuisance: they can convey information about the software running on the computer, and in particular leak sensitive information about security-related computations,' the trio claim in their paper. 'The attack can extract full 4096-bit RSA decryption keys from laptop computers (of various models), within an hour, using the sound generated by the computer during the decryption of some chosen ciphertexts. We experimentally demonstrate that such attacks can be carried out, using either a plain mobile phone placed next to the computer, or a more sensitive microphone placed 4 meters away.'

The attack works by listening to the noise made by tiny vibrations in the capacitors and coils of a system's voltage regulation hardware as the CPU changes its power draw during computation. While these sounds aren't made by the CPU directly, they are influenced by whatever task the CPU is working on - and provide enough information to recover the private key, albeit with the proviso that the team forced the system to decrypt ciphertext they themselves had provided.

Even with that in mind, some claims in the paper have raised eyebrows - in particular that an unmodified mobile phone, placed 30cm away from a laptop computer, is enough to pick up the otherwise inaudible signals.

One name associated with the research, however, stands out: Adi Shamir is the 'S' in 'RSA,' one of a trio - with Ron Rivest and Leonard Adleman - who published the public-key cryptosystem that bears their names, and against which the attack is targeted, back in 1977. In other words: arguing the finer points of public-key cryptography with Shamir is likely to end with you on the losing side.

In some ways, the paper describes an attack similar to that of the military TEMPEST programme, but where TEMPEST relies upon capturing electromagnetic radiation the new method operates simply through audio - and can work, its authors claim, even on military-grade TEMPEST-shielded hardware. While the attack is claimed to be immune to fan noise due to the high-frequency nature of the audio, the team claim another attack channel: tapping in to the electrical potential of shielded cables connected to the target system, or even 'merely touching the laptop chassis with his hand, while surreptitiously measuring his own body potential relative to the room's ground potential.'

The concept isn't new, with the team having presented their original findings at a cryptography event back in 2004. Since describing it theoretically nine years ago, however, the trio have worked with others to produce verifiable proof of the attack's efficacy - including the full-key extraction attack levelled against GnuPG, along with a patch for the software which thwarts the methods used.

While hardly the easiest way of breaking encryption - threatening the key holder with torture or imprisonment, such as with the UK's Regulation of Investigatory Powers Act enforcing a two-year prison sentence on citizens who refuse to divulge passwords and encryption keys when asked, is a simpler and more reliable method - it's certainly a novel attack, and one which may give the military's TEMPEST-hardened hardware toters cause for concern.

14 Comments

Discuss in the forums Reply
edzieba 19th December 2013, 10:08 Quote
Side-channel attacks based on measuring the power consumption of CPUs are fairly well-known. If you can tie coil-whine and other noises closely to power delivery, then this certainly sounds like a viable attack.
Pricester 19th December 2013, 10:20 Quote
Presumably, significant multi-tasking of CPU-intensive tasks would also foil this attack?

"No boss, I'm not playing WoW on my second monitor for fun - I'm ensuring data security!"

For that matter, I would imagine that just playing MP3s at high volume would avert most of the problem - both adding noise to the microphone input, and affecting the CPU usage... bring on the Black Sabbath albums!
Corky42 19th December 2013, 10:30 Quote
Quote:
Originally Posted by Pricester
"No boss, I'm not playing WoW on my second monitor for fun - I'm ensuring data security!"
You just have to be careful of NSA and GCHQ spy's pretending to be orcs or dwarves and such
Gareth Halfacree 19th December 2013, 10:32 Quote
Quote:
Originally Posted by Pricester
Presumably, significant multi-tasking of CPU-intensive tasks would also foil this attack?
Addressed in the paper: running multiple threads on multi-core CPUs appears to actually make the attack easier, because the processor down-clocks compared to single-thread, single-core operation.
Quote:
Originally Posted by Pricester
For that matter, I would imagine that just playing MP3s at high volume would avert most of the problem - both adding noise to the microphone input, and affecting the CPU usage... bring on the Black Sabbath albums!
Also addressed in the paper: the frequencies are higher than music, higher than fan whine, higher than anything you can hear unaided - meaning it's easy to isolate what you need, even if you've got The Birdy Song going full-blast on repeat.
K.I.T.T. 19th December 2013, 10:59 Quote
Well this'll be gone shortly when new VRM stages push the switching frequency up even higher which means noise that's in MHz and completely inaudible if it happens at all.
Xlog 19th December 2013, 14:28 Quote
High frequency and GSM don't go hand in hand. GSM codec is ~7khz, not to mention shitty compression.
What if someone hacks your phone and streams hi quality audio you ask?
Well, microphones in phones are ~15-20KHz, there is no need to put anything higher quality (not to mention, anything with higher bandwidth probably would cost more than most phones). While VRMs these days usually operate in MHz range.
In conclusion - this paper is full of s**t or there was something seriously wrong with their equipment.

Now, getting this from integrated sound card background humm, I could believe.
Gareth Halfacree 19th December 2013, 14:48 Quote
Quote:
Originally Posted by Xlog
High frequency and GSM don't go hand in hand. GSM codec is ~7khz, not to mention shitty compression.
Who said they were transmitting via GSM?
Quote:
Originally Posted by Xlog
Well, microphones in phones are ~15-20KHz, there is no need to put anything higher quality (not to mention, anything with higher bandwidth probably would cost more than most phones). While VRMs these days usually operate in MHz range.
You did read the paper, right? This is all addressed in there.
Quote:
Originally Posted by Xlog
In conclusion - this paper is full of s**t or there was something seriously wrong with their equipment.
I love it when people who aren't massive names in the cryptography world and who didn't invent the most widely-used public-key cryptosystem decide that experts are the fools. No, really. Love it.

As I'm sure you've read the paper in full before coming to that conclusion, then I'm sure you'll remember Section 5.4 - in which the team describes the results of different experimental setups. You know, the one where they successfully do exactly what you just said was impossible. That section. Here, I'll quote it:
Quote:
Originally Posted by The Paper
Lowering the leakage frequency also allows us to use lower quality microphones such as the ones present in smartphones. As described in Section 2.3, we used mobile phones to perform the attack. Due to the lower signal-to-noise ratio and frequency response of the phone’s internal microphone, our attack is limited in frequency (about 24kHz) and in range (about 30 centimetres). However,it is still possible to perform it on certain target computers, simply by placing the phone’s microphone near to and directed towards the fan exhaust vent of the target while running the attack. Unlike previous setups, all that is required from the attacker in order to actually mount the attack is to download a suitable application to the phone, and place it appropriately near the target computer. No special equipment is required to perform the attack.
Deders 19th December 2013, 20:48 Quote
Surely different cpu's/voltages/VRM's/PSU's etc will vary the noise generated from different configurations.
Alecto 19th December 2013, 21:11 Quote
Quote:
Originally Posted by Deders
Surely different cpu's/voltages/VRM's/PSU's etc will vary the noise generated from different configurations.

Plus there are different codepaths for different hardware (a single program might be compiled with optimizations for AES-NI-capable processors for example, while still being able to function with older CPUs), different versions of one targeted program they went after, different versions for different operating systems etc. ... so many variables to account for.

@Gareth: it is common for such claims to be backed by something (an exploit code snippet, for example). Where can I find this smartphone application which will recover encryption keys ?
enciem 19th December 2013, 23:00 Quote
Does the 'potential to mount an attack' mean the app could provide the method of correctly recording or actually decipher the key? I read it first as meaning they were recording the sound with the app and then going and plugging away at all the math for a good while to work out the key. Guess I just thought it sounded pretty difficult.

...And no I didn't read the paper, that's why I read the article about the paper, so don't grump ;)
edzieba 20th December 2013, 01:30 Quote
Quote:
Originally Posted by Alecto
Where can I find this smartphone application which will recover encryption keys ?
The phone is just a convenient microphone in a non-suspicious package. The actual processing of the audio captured would be done off-line.
Gareth Halfacree 20th December 2013, 08:59 Quote
Quote:
Originally Posted by Alecto
@Gareth: it is common for such claims to be backed by something (an exploit code snippet, for example). Where can I find this smartphone application which will recover encryption keys ?
But this isn't an 'exploit' per se - and nor is it a posting to the Full Disclosure mailing list. It's an academic paper, and it would be rare for an academic paper to include a complete printout of all source. Add to that responsible disclosure guidelines - sure, GnuPG has a fix for the attack now but it's nowhere near widely deployed yet - and you should see why that's not included in the paper.
Quote:
Originally Posted by enciem
Does the 'potential to mount an attack' mean the app could provide the method of correctly recording or actually decipher the key? I read it first as meaning they were recording the sound with the app and then going and plugging away at all the math for a good while to work out the key.
Theoretically, you could do the analysis on the smartphone - but it'd be so much quicker to just move the recording onto a more powerful machine and do it there. It's not like the thing works in real-time, anyway - it takes about an hour to recover a single key.
Quote:
Originally Posted by edzieba
The phone is just a convenient microphone in a non-suspicious package. The actual processing of the audio captured would be done off-line.
^ Wot 'e said.
Andy Mc 20th December 2013, 10:02 Quote
Quote:
Originally Posted by Corky42
Quote:
Originally Posted by Pricester
"No boss, I'm not playing WoW on my second monitor for fun - I'm ensuring data security!"
You just have to be careful of NSA and GCHQ spy's pretending to be orcs or dwarves and such

That so remnds me of "Halting State" by Charles Stross.
law99 20th December 2013, 11:09 Quote
This stuff sounds really cool. May have to read it whilst at GFs parents for Christmas. Thanks for sharing.

But now; I must clean my kitchen!
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums