[1689] in cryptography@c2.net mail archive
Re: Kocher timing attacks revisited
daemon@ATHENA.MIT.EDU (Vin McLellan)
Fri Oct 3 14:35:14 1997
In-Reply-To: <199710022157.RAA28094@jekyll.piermont.com>
Date: Fri, 3 Oct 1997 13:57:15 -0500
To: cryptography@c2.net
From: Vin McLellan <vin@shore.net>
Perry <perry@piermont.com> reported:
>Van Jacobson's PATHCHAR program is a neat creation that determines the
>speed of far distant internet links by using statistical techniques on
>round trip times -- by noting tiny differences in timing between small
>and long packets on distant networks, the distinction between T1s,
>T3s, OC3s, etc. can be determined with astonishing accuracy.
>
>Why do I mention this? It occurs to me that the statistical methods he
>uses could also, probably, be used to carry out Kocher style timing
>measurement attacks on distant servers. I suspect that such attacks
>are far less infeasable than has been supposed by many.
>
>Are people using countermeasures for these methods yet, or are they
>still ignoring them?
I fear many vendors are still ignoring this threat... and not all
because they have had network latency to hide behind.
I know that SDTI immediately upgraded the internal code for their
SecurID -- which uses a 64-bit token-specific seed in an SDTI-proprietary
John Brainard hash to continuously generate a series of tokencodes for the
token's LCD -- to equalize the path thru the code for Os and 1s in the
seed.
Most of the 2 million SecurIDs now in use now take the same amount
of time to handle all seed-bits, and tens of thousands get the upgraded
tokens as users' SecurIDs expire each month. I don't know about the several
DES-based challenge/response tokens -- but they always seemed to me to have
been much more vulnerable to timing attacks with their 56-bit keys,
accessible battery leads, simple processors, and a clear beginning/end to
their OTP calculations. (Any grad students looking for a research project?)
SDTI also balanced the timing for tokencode calculations in the
last few version of their ACE authentication servers -- although with the
variable time for pulling up user data from the server's internal RDBS,
that seemed relatively secure against remote timing-based cryptoanalysis to
begin with.
Suerte,
_Vin
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which by
its nature will resist efforts to restrict it to bureaucrats and others who
deem only themselves worthy of such Privilege."
_ A thinking man's Creed for Crypto/ vbm.
* Vin McLellan + The Privacy Guild + <vin@shore.net> *
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
