SecurIDs (was Re: Australian "calculatorcard")

[vin@shore.net (Vin McLellan)]

        amp <Alan.Pugh@internetMCI.COM> described his SecurID:

>> 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.

        David Lesher <wb8foz@nrk.com> asked:

>Do these card systems use a window to handle clock-slip?

        SDI's ACE/Server or ACE access control module (ACM) has a Progress
RDBS built in which maintains a constantly-updated historical record of the
_relative_ drift in a particular token's clock-chip, relative to the clock
in the server or host.  When it receives the first identifier from a user
(Name) submitting a SecurID authentication call, the server checks the
database for the recorded drift and then predicts what that particular
token will use as Current Time.  CT, together with a token-specific secret
key, is then hashed to generate a token-code which is matched with that
submitted by the user,  together with the user's memorized PIN.

>I'd think you could have the server safely accept # N, N-60 sec, and
>N+60 seconds; and adjust the server's idea of your card's clock speed
>from that.

        You have it almost exactly right (or, at least, that's how SDI's
ACE/SecurID system handles it;-) SDI throws in a couple other factors:  the
ACE system handles Current Time in 30 or 60-second blocks (depending on the
model of SecurID token being authenticated,) so it needs a little leeway to
handle a token which, because of drift, slips into the next time-slot or
the one behind.

        The ACE system actually pre-calculates three token-codes -- each a
pseudo-random number, so one will not inform your guess of another -- as it
waits for a user's incoming authentication call to be completed.  The
server will approve access if it receives a token code generated from
either its _projected_ Current Time (for this particular token,) or the
token-codes generated from Current Time plus or minus one time-slot.

        When the ACE database indicates that this particular SecurID token
has not been used in the past 60 days (many sysadmin make this 90 days) it
also kicks in a search mode to minimize the false rejections.  In search
mode it calculates a series of prospective card-codes, sweeping out to a
maximum of 10 time-slots (the actual scope of the search is defined by the
sysadmin) fore and aft of whatever the database suggests this token should
consider Current Time.  If it finds a match between the token-code
submitted from a long-unused SecurID and one of those calculated by the
server in search mode, it updates its database projection for the drift of
that particular token and then requests the use to submit another PRN
token-code.  A search-mode "match" alone will never result in a user being
authenticated -- it only sets him or her up for a second formal
authentication cycle where a new PRN card-code is matched against a new set
of three token-codes.

        There are also a number of additional security devices and rules
which the server enforces to protect against security threats, racing
spoofs, stolen PINs, stolen tokens, etc.  The most obvious is a secured
record of all incoming authentication calls, recorded by token-code and GMT
time.  All incoming authentication calls are checked against this file. A
SecurID PRN token-code is never accepted twice, and the virtual
"time-stamp" within an incoming SecurID token-code must always be later and
in proper sequence to all other recorded authentication calls.
>
>What new risk would that create?

        If the SDI hash algorithm is of sufficient strength, very little, I
would think.

        (SDI just asked me to create an FAQ for their SecurID, so all
queries are welcome -- on-line or off.)

        Suerte,
                        _Vin


    Vin McLellan +The Privacy Guild+ <vin@shore.net>
 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
                <*><*><*><*><*><*><*><*><*>