AES cache timing attack

Jerrold Leichter jerrold.leichter at smarts.com
Wed Jun 22 07:19:32 EDT 2005


| > 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.  However, if the protocol authenticates its messages,
| > you'll never get any response to an injected message.  At best, you might
| > be able to observe some kind of reaction to the injected message.  But
| > that's a channel that can be made very noisy, since it shouldn't occur
| > often.  (BTW, if you use encrypt-then-authenticate, you're completely
| > immune to this attack, since the implementation won't ever decrypt the
| > injected message.  Of course, there may be a timing attack against the
| > *authentication*!)
| 
| I agree with your comments about the injection, but I
| don't see why the attack doesn't work on the session
| passively.  Are you assuming that because it is a
| session, it's in some way not plausible to match the
| inbound packets with outbound packets?  I would
| have thought that was possible with things like keep
| alives and so forth.  The only drawback I can see is
| that there might not be enough data (hence desire to
| tickle things along with an injection).
That's basically it.  You need to pair up packets that have known (or at least
recognizeable) plaintext - or, more accurately, input to the encryptor.  (In
CTR mode, what matters is the value of the counter, not the plaintext.)
Unless the protocol required some externally-visible response to a keep-alive,
it would provide you with no information - *nothing* would pair with the keep-
alive packet.  (Well, I suppose one can imagine an implementation that uses 
absolute time on its system to a very high degree of precision to determine 
when to send a keep-alive, and then posit an attacker who can get access to 
the system time.  But given any reasonably typical keep-alive mechanism, 
this seems pretty unlikely.)

A low-level ack to a received message might work.  Any higher-level response - 
one that came from semantic processing of the actual data, not from the 
low-level bits - is likely to contain so much noise that pulling useful timing 
out will take more paired, guesssable packets than an attacker will ever see 
(yet another reason for periodic rekeying, of course).

This does point out some interesting interactions.  For example, a mode like
CBC is harder to attack because you need to know more actual plaintext to
determine the input to the encryptor.  On the other hand, a mode like CTR may
be particularly vulnerable since the input can be determined independently of
the actual plaintext.  Pre-whitening, even with a (secret) constant (for a
particular connection) - something that generally seems pointless - would
help.

							-- Jerry


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



More information about the cryptography mailing list