AES cache timing attack

Ian Grigg iang at systemics.com
Tue Jun 21 20:28:24 EDT 2005


On Tuesday 21 June 2005 23:00, Jerrold Leichter wrote:
>  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).

When I was thinking about "use a mode" I was more
thinking about how a mode could be the cover needed
to hide the decrypt time.  A straight CBC mode would
probably make matters worse because it is a known
length and the key doesn't change, so plausibly the
longer the total packet, the better the time estimate.

But if the key were to change for each block in a
decrypt-dependent fashion, this would presumably
render the total time as an average over many decrypts
of many block keys.  The longer the packets, the more
the cover, and no key gets used more than once anyway.

So, hypothetically a mode that XOR'd the previous output
with the key before encryption (heaven knows whether
that would be cryptographically sound, but something
along those lines, anyway).

Alternatively, if one is in the unfortunate position of being
an oracle for a single block encryption then the packet
could be augmented with a cleartext random block to be
xor'd with the key each request.

iang
-- 
Advances in Financial Cryptography, Issue 1:
   https://www.financialcryptography.com/mt/archives/000458.html
Daniel Nagy, On Secure Knowledge-Based Authentication
Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products
Ian Grigg, Pareto-Secure

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



More information about the cryptography mailing list