[PD] [OT] high-frequency birdsong

Chris McCormick chris at mccormick.cx
Tue Jun 7 06:22:34 CEST 2016


Hi Jonathan,

On 06/06/16 08:21, Jonathan Wilkes via Pd-list wrote:
> I'm trying to wrap my head around this:
> http://m.cacm.acm.org/magazines/2016/6/202646-physical-key-extraction-attacks-on-pcs/fulltext
>
> So to answer the question-- yes, the mic has to respond.  So if the
> worry is cellphone microphones, I simply don't see how the mic could
> deliver any useful data whatsoever to the analysis software.

As Andy pointed out, the situation you describe with the birdsong is not 
analogous this attack and his AM radio for-loop rig on the TRS-80 is 
much closer.

The useful data does not occur in the GHz range: PGP decryption on a 
4096 bit key takes on the order of tens or hundreds of milliseconds. The 
spectrum of that many-millisecond event varies depending on the 
adaptively-crafted cyphertext that has been sent. For each bit of the 
secret a crafted cyphertext is sent which causes the multi-millisecond 
decryption process to yield a recognisable frequency spectrum depending 
on whether the bit of the secret key they are cracking is a 0 or a 1. 
This happens using exactly the mechanism Andy describes - different 
operations executed repeatedly in loops inside the decryption library. 
They also coerce the algorithm to amplify the effect using the same 
technique affecting a different portion of the code.

So they send 4096 individually and adaptively crafted cyphertexts 
designed to provoke the algorithm to behave in one way or another 
depending on whether a 0 or a 1 is present in the secret key at each 
position, and they measure the acoustic frequency spectrum of the 
multi-millisecond decryption of each cyphertext to determine whether 
it's a 0 or 1 at that position.

This works because the decryption algorithm will run different bits of 
code depending upon a) the crafted cyphertext input b) the secret key.

"In some cases, it even suffices to record the target through the 
built-in microphone of a mobile phone placed in proximity to the target 
and running the attacker's mobile app."

I'm guessing the "some cases" where it is possible depend on the quality 
of the phone mic and the level of accoustic leakage of the target device.

 > But a public-facing server would regularly be "tweeting", no?

Note that it's not just a matter of the server emitting the "tweets" as 
you describe them - you have to actively prompt it to emit a certain 
type of biased accoustic signature for each bit of the secret key and 
then examine the audio spectrum of the decryption event to see what the 
value of the bit actually was.

The acoustic attack works on any target device that you can compel to 
perform a decryption of some cyphertext multiple times, and that leaks 
accoustic side-band information that you can collect. So you'd need 
physical access to a public-facing server (in which case several other 
classes of attacks may be more feasible) in order to collect the 
acoustic signature.

Although maybe you could do this:

https://news.mit.edu/2014/algorithm-recovers-speech-from-vibrations-0804

The attack in the paper was on GnuPG but if SSH or HTTPS implementations 
are similarly vulnerable to this attack then you could provoke the 
server to perform a decryption several times easily without any human 
intervention since unlike GnuPG those servers decrypt in a completely 
automated way.

They mention OpenSSL explicitly in the conclusion:

"Turning to mobile phones and tablets, as well as to other cryptographic 
libraries (such as OpenSSL and iOS CommonCrypto), electromagnetic key 
extraction from implementations of the Elliptic Curve Digital Signature 
Algorithm has also been demonstrated, including attacks that are 
non-invasive, low-bandwidth, or both."

Dan Bernstein's NaCl crypto library (elliptic curve not prime 
factorization) is specifically designed to avoid some of these pitfalls:

https://cr.yp.to/highspeed/coolnacl-20120725.pdf

"NaCl features: no data flow from secrets to load addresses; no data 
flow from secrets to branch conditions; no padding oracles; centralizing 
randomness; avoiding unnecessary randomness; extremely high speed; and 
cryptographic primitives chosen conservatively
in light of the cryptanalytic literature."

Fascinating paper, thanks for sharing.

Cheers,

Chris.

-- 
http://mccormick.cx/



More information about the Pd-list mailing list