[1089] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (Adam Shostack)
Wed Jun 25 12:11:33 1997
From: Adam Shostack <adam@homeport.org>
In-Reply-To: <v03007807afd60310b005@[198.115.179.81]> from Vin McLellan at "Jun 24, 97 09:26:09 pm"
To: vin@shore.net (Vin McLellan)
Date: Wed, 25 Jun 1997 09:58:02 -0400 (EDT)
Cc: cryptography@c2.net, coderpunks@toad.com
Vin McLellan wrote:
| Adam Shostack <adam@homeport.org> responded:
(Most of Vin's detailed explanation of how the Ace/Server searches
deleted. If you can hit the 21 minute window wrt to the clock, you
can (depending on configuration) get an Ace/Server to admit you've got
a sort of maybe valid tokencode, and ask you for a new one, allowing
you to confirm your attack.)
Also, its worth noting that this feature allows an
entertaining DOS attack, which has two steps. First, by observing a
card that has just been used, and playing with the way PINs are used,
you can extract a PIN from a card. (PINs are added to the displayed
number using no carry addition, and you can enter a new pin on the
card. By watching the number on the card, entering a new pin of "0",
and subtracting, you can find a pin. With the pin, you observe the
card again as you are leaving the office of your victim. You run back
to your desk, logging in as them with the tokens you just saw. This
causes the Server to adjust its clock drift estimate, and possibly
overskewing it. Not a real proble since it really requires knowing
the victim. Just fun with SecurID cards.
| Beyond the initial extension of the search window (as the
| ACE/Server drops the account into what ACE-mavens like Adam call "Next PRN"
| mode) the search window is further extended according to a simple formula
Actually, Ace mavens like me have another name for this, but
we don't repeat it in polite copany. :)
| (Actually, SDTI warranties that each SecurID token will never --
| over a three-year lifespan -- drift more than 10 minutes off GMT. Free
| replacement; no questions asked!) Ok, so much for the functional security
| issues.
There is however, no way to validate this claim. There is no
way to make your card be a clock, and no way to obtain the data on
clock drift from the Server thats documented.
| For a brute force attack on a SecurID's seed or secret key --
| presuming the attacker has somehow obtained the proprietary SecurID hash
| and a record of output -- the attack can thus presume, with fair odds, that
| the Current Time used as input in the hash is within that 21 minute window.
Getting the hash is relatively easy. The hard attack, which
unsubstantiated rumer says has been done several times, involves card
and electron microscope. The easy attack involves getting the
Ace/Server and disassembling it.
| Adam calculated:
| >
| > In conjunction with the time (to the minute), you need to find
| >the cards seed, which I think is also 64 bits.
| >
| > Time is calculated as (time(0)+N+1000000)/60
| >
| > N was a three every time I looked at it, but unlike the
| >million, was stored as data, not a constant.
| >
| > So, you need to search some number of time possibilities
| >(about 2^20 for a year, 2^11 for a day?) on top of 2^64 seeds.
|
| The 21 minute window is arguably a more managable solution-space
| than a day's worth of SecurID PRNs, certainly more feasible than a year's
| worth!
Quite, but I forgot that SDI calims a 10 minute max drift,
since the clock is secret.
| Even then, however -- given a sequence of token-codes and a
| corresponding Current Time, and rounding off a little for conceptual
| clarity -- I figure a brute force attack on a token's seed requires an
| average search of half of
|
| 21 (possible Current-Time(s) * 2 ^ 64 (possible seeds)
|
| Let's conservatively ballpark that at about 10^20 calculations.
|
| Adam suggested:
|
| >On the
| >bright side, the card hash runs on an 8 bit processor, and would
| >probably be way efficient on a pentium.
|
| I understand a moderately-optimized Pentium implementation of the
| SecurID hash can do1K calculations-per-second. Even assuming Peter Trei or
| some other optimizing wiz could improve that by an order of magnitude, a
| solution-space of that magnitude remains a challenge.
I'd be **very** suprised if this were true. Even if the
little chip does spend most of its time calculating the next card, its
a slow chip (8mhz?) operating on 8 bits at a time.
Also, the Server searches back and forth (which do have
performance difficulties) don't seem to involve problems with running
the hash. They have problems because of the nature of the loop, which
calls des, f2, card on a per try basis. (In 1.3 software, I expect
that this was fixed in 2.2 or 2.3)
I have to run to a meeting, I may add more real calculations
later.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
