AES cache timing attack

[Thor Lancelot Simon]

On Tue, Jun 21, 2005 at 10:38:42PM -0400, Perry E. Metzger wrote:
> 
> Jerrold Leichter <jerrold.leichter at smarts.com> writes:
> > Usage in first of these may be subject to Bernstein's attack.  It's much 
> > harder to see how one could attack a session key in a properly implemented 
> > system the same way.  You would have to inject a message into the ongoing 
> > session.
> 
> I gave an example yesterday. Perhaps you didn't see it.
> 
> The new 802.11 wireless security protocols encrypt the on-air portion
> of communications, and are typically attached to ethernet bridges.

Sorry I didn't respond to this earlier -- I was on vacation last week.

It is simple to practice this attack against an 802.11 network that is
behind a NAT or routing firewall, rather than just a simple Ethernet
bridge.  It's only moderately harder when the 802.11 network is separated
from the public Internet by a proxy firewall.

In fact, I can run it right here in my house:

>From the west-facing window of my apartment building, I can see over
50 different 802.11 networks as I scan the buildings across the street
with a reasonably tight antenna.  Many of those networks are connected
to the public Internet by a cablemodem network to which I also have
access.

A small number of those networks use WPA with AES (I'm lucky I have so
many networks to choose from; this isn't common on residentail networks --
yet).

So, to obtain encryption timing data, I can:

1) Do two quick tcpdumps, imported them into SPSS, and look for the
   best-correlated wireless and wired activity times.  This gives me a
   good guess as to which wireless network had which public address (it
   also, presumably, gives me en/deryption timing data, for known, even,
   but not chosen plaintext; but that's just gravy).

2) Look at the tcpdump for the wired segment again (or run a new one) to
   find some open TCP connections.  These will pretty much all correspond
   to open TCP connections on the "inside"; routing firewalls and almost
   all NAT boxes will just pass packets sent from the outside straight
   through (a proxy firewall will require an application-layer attack)

3) Send duplicate ACKs (or wholly spurious ACKs) to the public address
   of the firewall in question and watch the wireless segment to see
   how long it takes to encrypt them.  Oh, by the way, they're chosen
   plaintext...

Thor

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