Who cares about side-channel attacks?

[Peter Gutmann]

Wouter Slegers <wouter at yourcreativesolutions.nl> writes:

>Timing analysis is quite possible to pull of in straightforward
>implementations as demonstrated over the Internet on OpenSSL prior to their
>implementation of blinding (
>http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I have
>never heard of such an attack actually being used in the field. Real side
>channel analysis (DPA, EMA etc) seems mostly limited to academics and labs,
>not the field.

One of the XBox attacks, allowing rollback to a vulnerable kernel, was a
timing attack.  I'd heard it was also tried in some form (unsuccessfully)
against the Wii as part of the breadth-first attack approach.

>I'm afraid that the best at this moment is mostly rumors. There is some
>knowledge about attacks in the field but it is spread out a lot and the ones
>that aggregate this information are not sharing this (it also gives the
>attackers a view on what works and what not).

You can see this with the games-console hacking, the attackers try and release
the least amount of information possible so they've got something in reserve
when the countermeasures appear.  In some cases they use attack method A to
find a weakness and then exploit it using unrelated method B, allowing reuse
of method A once B is patched by the vendor.

>As I read his story, he eavesdropped the bus between the bridge chip and the
>CPU to recover the real bootloader code with the real RC4 key,

Sorry, I was referring to two different attacks in the same sentence, and on
re-reading managed to make the result quite unclear :-).  The timing attack
didn't directly recover the authentication key directly but avoided the need
to know it, thus allowing unauthorised vulnerable kernels to be loaded.

>not the incorrect one in the ROM (very nasty trick, kudo's for the Microsoft
>development team there ;-) ).

Often the simplest tricks are the most effective, e.g. stick a PGP header on
the data to be protected and the attackers spend forever trying to decrypt it
when in fact the processing function is (in pseudocode):

  seek( file, 16 );    // Skip red-herring junk at start
  processData( file );

(the problem with this one was that they memcpy()'d the fixed header on and
the lengths were wrong, but apart from that it would probably have distracted
attackers for some time).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com