[1095] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (Vin McLellan)
Thu Jun 26 22:57:26 1997
In-Reply-To: <199706251358.JAA01041@homeport.org>
Date: Thu, 26 Jun 1997 15:30:09 -0500
To: Adam Shostack <adam@homeport.org>
From: Vin McLellan <vin@shore.net>
Cc: cryptography@c2.net, coderpunks@toad.com
Vin McLellan <vin@shore.net> suggested:
>| 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.
Adam Shostack <adam@homeport.org> responded:
> 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.
<sigh> That unsubstantiated rumor -- of a physical attack on a
token to retrieve the SecurID hash -- is an odd tale that has buzzed around
ACE/SecurID several times over the past decade. In another version, a
notably flamboyant US security consultant (with a private beef with SDTI
over a cancelled consulting contract) is alledged to have physically
disassembled the token to retrieve both the hash and the token-specific
secret key.
I think the idea of attacking the token for the hash is inherently
silly, given (as Adam notes) the relatively accessible alternatives in a
well-funded attack. (To my knowledge, at least two versions of the
ACE/Server code are in circulation in the hacker community.)
Like cracking the token to get the hash, attacking the physical
SecurID to obtain the token's secret seed would also likely require time,
talent, pricey equipment, and special knowledge -- but, of course, it's
possible! As W.H. Murray put it: "With a big enough hammer, anything can
be broken."
But let's look at the security implications. Note that this is an
inherently destructive attack on the SecurID token. Even if it were
successful, a valid token-code must also be supplemented with the user's
memorized PIN -- so just stealing the target's token is not enough. There
are layers of technical defences within the token, but the system's core
defense revolves around the user. When a SecurID is reported lost or
stolen, it's account is disabled and the token immediately becomes useless.
Someone assigned a SecurID typically can't do his job without his
token -- so it's loss (or destruction) is unlikely to be ignored and cannot
be hidden. The sort of high-value environment which might potentially
justify this attack typically has users with a corresponding sense of
security consciousness. (The White House staffers who carry SecurIDs would
not hesitate to quickly report a "missing" token -- just as they are
unlikely to allow anyone to look over their shoulder when they type in
their PIN.)
Physically attacking the token for its secret seed is marginally
feasible, but scenarios for this attack are typically torturously
far-fetched -- with a cost/benefit ratio that looks utterly absurd next to
the elegant simplicity of a .22 caliber Saturday Nite Special used to
threaten the token-holder or his family.
On the cryptoanalytic side, I ball-parked the solution-space to be
searched in a brute force attempt invert the SecurID hash and obtain a
single token's secret seed at about 10^20 calculations:
>| [....] 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)
Adam had earlier suggested:
>| >On the
>| >bright side, the card hash runs on an 8 bit processor, and would
>| >probably be way efficient on a pentium.
So I came back with some helpful calculations.
I estimated 300,000,000 Pentiums could do the job in a year. As I
wrote:
>| 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.
To which Adam retorted:
> 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.
You might be working off **faulty** information;-)
The SecurID chip is a 4-bit CPU, operating at 32 kilohertz. The
algorithm that hashes "Current Time," and a token-specific secret key, to
produce SecurID's PRN has been highly optimized for a 4-bit CPU. It takes
a SecurID chip ten seconds to generate each of the token-codes that roll
over every 60-seconds.
Muscular 32-bit Pentiums are apparently not all that efficient when
running streamlined 4-bit software.
Suerte,
_Vin
PS. I don't work for SDTI, but I've been a consultant to the
company since the beginning of Time. Under contract to SDTI, I also wrote
their SecurID FAQ.
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-- <@><@> --
