From: vin@shore.net (Vin McLellan)
Date: Sun, 31 Dec 1995 17:35:43 +0800
To: cypherpunks@toad.com
Subject: Re: Australian "calculatorcard"
Message-ID: <v02130502ad0be4ca497f@[198.115.179.213]>
MIME-Version: 1.0
Content-Type: text/plain


Cees de Groot (cg@bofh.toad.com) tore himself from the tube to tell us:

CG> Yesterday, on UK Discovery, there was an item in the programme
CG> Beyond 2000 about an Australian card which implements a
CG> challenge-response protocol and can be used for banking, etcetera.
CG> Basically, you give your card number (over the phone), get a
CG> challenge number, enter your pin and the challenge, and then give the
CG> response. All in CC format...

        Could be one of seven or 8 vendors of so-called
"challenge/response" tokens or calculators.  Most of those sold in the US
and Australia use straight DES (and a token-specific key) to encrypt the
"random" challenge number in the token -- but it could be any secret-key
algorithm.

        Actually, the particular environment described -- phone
authentication -- is often used as the most notable example of a market
where so-called "time-synchonous" tokens hold a  notable advantage over
challenge/response token. A TS token generates its pseudo-random
token-codes continuously and automatically: no buttons, no input.

        With TS tokens, exact time and a token-specific key are used in a
keyed hash to generate a token-code displayed on an LCD on the token for 30
or 60 seconds.   The authentication server uses its database record of the
token-specific key, time, and the hash to generate the same token-code for
a match.  This allows a PIN and token-code two-factor authentication to be
submitted by touch-tone phone, and it avoids a lot of the hassle
(listen/tap/calculate/touch-tone) associated with C/R authentication.

        As amp <Alan.Pugh@internetMCI.COM> noted, the most prominent
international vendor of time-synch tokens is a US firm called Security
Dynamics, Inc.  I've done consulting projects for SDI, off and on, for
years.

>sounds like the card i use for remote dialup to certain non-public
>systems i use at work. it has a six digit number on the front that
>changes every 60 seconds. the card is registered to me. when i enter
>my username/password i'm prompted for the number.

        SDI's token is called a SecurID. <http://www.securid.com>  SDI uses
a <sigh> proprietary hash.  The most common app uses a SecurID in a
protocol which prepends the PIN, in the clear, to the PRN token-code. (In
client/server environments, of course, all communication between an SDI
ACE/Client and the ACE/Server is fully encrypted.)  SecurIDs can also be
loaded with up to three different seeds or keys -- with a pressure-point in
one corner to switch between each series of key-based PRNs.

        For greater security in open networks, SDI sells a PinPad token
with a keypad that allows a PIN to be "added" to the PRN token-code -- so
the LCD displays a 6-8 digit number (or alphanumeric) which still offers
two-factor authentication, without exposing a PIN.

> it's Pretty Good
>(tm) security, but like anything not biometric, it is vulnerable to
>black-bag attacks. physical possession being all that is required.

        Actually, all ACE/Server or ACE software modules _require_ a
user-memorized PIN.  Physical possession of a stolen token is not enough to
gain illicit access.

>if
>you know the algorithm and the serial number of the card and the
>time, even that isn't necessary.

        Bleep!  Earth to amp! Check your voltage, lately?  The token's
serial number has nothing whatsoever to do with the generation of a
SecurID's PRN token-code.

        Just because SDI ships its SecurIDs pre-loaded (most token vendors
ask the buyers to program their authentication tokens) SDI embosses a
serial number on the back of the token to manage shipping and distribution.
The serial number stuck to the back of a SecurID after it is programmed
with its secret key -- a unique PRN "significantly longer" than 56 bits --
but they are not the same thing.  The cpu in a SecurID doesn't even "know"
the serial number stuck on the back of the token.

        (It would be Pretty Stupid <TM> to glue or emboss a secret on the
back of the damn token, wouldn't it?)  I should note that Alan is just
regergitating one of the most widely circulated  rumors about SecurIDs --
which like any popular crypto device attracts a lot of wiLd & w00ly
speculation.

        Getting the algorithm for SDI's one-way hash is no big deal, given
that it sits in software in thousands of SDI customer installations,
protected only by contract and trade secret status.  (The integrity of the
product -- the unpredictability of the token-code PRN series, and the
secrecy of a specific token's seed or key -- rightly depends cryptographic
strength of the hash, not the secrecy of the algorithm.)  Getting a
token-specific secret key would hopefully be a much greater challenge.

CG> Can anybody provide me with pointers to more in-depth information
CG> about this device and the algorithm(s) behind it ?

>i don't know if there are any net sources for them, but i'd be
>suprised if not. my card references "security dynamics" of cambridge
>massachusetts.


        Suerte & Happy New Year to all,
                                                                 _Vin

<*><*>< Vin McLellan + The Privacy Guild + vin@shore.net ><*><**>

Heed, fellow citizens, Justice Felix Frankfurter (Butler v. Michigan):

       "The State insists that, by thus quarantining the general reading public
against books not too rugged for grown men and women in order to shield
juvenile innocence, it is exercising its power to promote the general
welfare. Surely this is to burn the house to roast the pig.... The incidence
of this enactment is to reduce the adult population of Michigan to reading
only what is fit for children."