[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