Cryptography-Digest Digest #269, Volume #9 Tue, 23 Mar 99 05:13:04 EST
Contents:
Re: Securid Card (Vin McLellan)
----------------------------------------------------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Securid Card
Date: Tue, 23 Mar 1999 04:02:35 -0400
The response to Loomis Farkle's query indicated both interest
and some confusion about the internals of the ACE/SecurID system, so
-- in an admittedly longish post (fair warning!) -- I thought to offer
some design details about the SecurID token, and answer the questions
that have been raised about how the SecurID interacts with Security
Dynamics' authentication engine, what SDTI calls the ACE/Server.
Loomis Farkle <[EMAIL PROTECTED]> asked:
>> Does anyone know what the protocol is in these cards? Is it
>> encrypting my PIN with a public key and the server is decrypting it
>> with a private key and matching it to the password database? Is
>> it symmetric with the PIN being the key and the only real defense
>> being the rapidly changing plaintext/ciphertext in the card?
Paul Rubin <[EMAIL PROTECTED]> responded:
> Symmetric key with the key being inside the card (the server has to
> know the card's serial number).
Not quite right. Both the SecurID tokens and the ACE
authentication server use a 14 year-old SDTI-proprietary hash -- by
John Brainard, now with RSA Labs, an SDTI subsidiary -- to generate
the "60-second" token-code that is displayed on the SecurID's LCD
screen. The server does know the card's serial number, but (for an
assigned SecurID) it need not. The records of about the token are also
indexed on the basis of the assigned user's name in the ACE/Server
database.
In a SecurID, a token-specific secret key (seed) and "Current
Time" are continuously and automatically hashed through Brainard's
one-way function to generate a series of 6 to 8 digit token-codes. The
LCD display on the SecurID changes every every 60 seconds. The
token-codes are one-time passwords (OTPs), which are valid only very
briefly, and then not at all.
SDTI has patents that covers the mechanics of how its
authentication server manages to synchronize its clock, on the fly,
with each SecurID token which is register to it. Those patents have
allowed SDTI to hold a virtual monopoly over this type of "time
synched" hand-held authentication (HHA) token.
The classic SecurID is a simple token -- either the size of a thick
credit card, or in a key fob form-factor -- which continuously
displays a changing 6-8 digit (or alphanumic) token-code. Most of the
several million which have been sold do not have any input pad; a
token-holder simply reads the token-code off the LCD with a glance and
types it in at a keyboard, pre-pended by a PIN, like a longish
traditional password.
[The SecurID Mr. Farkle described was a PinPad version of the
SecurID, an adaption of the traditional design for unencrypted network
links. With the PinPad SecurID, the PIN is input into the token on a
small keypad and literally added (no carry) to a pseudo-random numeric
token-code to secure the PIN against eavesdroppers.]
Buttressed by a memorized PIN, all versions of the SecurID
offer two-factor user authentication ("sometime known," plus
"something held"). The traditional SecurID became popular with users
largely because it offered a clear ease-of-use advantage over its
various competitors, which typically rely upon a challege/response
exchange. Historically, this advantage let ACE/SecurID dominate the
market for two-factor user authentication, particularly in corporate
environments with 1,500 or more seats.
I've been a consultant to SDTI for many years, so any opinions
I offer should be taken with an appropriate grain of salt. I also
wrote a widely-circulated SecurID FAQ in '95 -- now somewhat dated,
unfortunately.
When the SecurID first appeared a decade ago, I thought it was (from
the user's point of view) a model of delicious simplicity compared to
other token-based HHA systems. As IT professionals absorb the burdens
of PKI, I dare say that others will quickly gain a new appreciation
for the elegant simplicity that underlies this whole class of
hand-held authenticators.
[Compared to other costs involved in putting a user online,
HHAs are cheap; what they offer -- the assurance of strong user
authentication -- is often invaluable; and what they do is
transparent. Since HHAs have no direct circuit connection to the
user's network, workstation, or server, everyone can be utterly
certain that they do no more than what they appear to do. That's an
assurance difficult to obtain from any device that is wired directly
into the host or network. Even a plugged-in smartcard.]
How does it work? As others have noted, the ACE/Server
continuously records the relative "drift" of the token's clock-chip
(relative to the Server's clock, which is presumed <ahem> to be
perfectly accurate.)
When a user submits his name and a two-factor authentication
call -- the 6-8 digit SecurID token-code, and a 4-8 digit PIN -- to
the ACE/Server with a request for authentication of his pre-registered
identity, the Server routinely checks its historical record for the
relative "clock drift" associated with that particular token. Based on
that record, the ACE/Server adds or subtracts a delta to synchronize,
on the fly, the Server's calculation of "Current Time" and the version
of "Current Time" used in that particular SecurID.
The ACE/Server's database also hold an (encrypted) record of
the seed for each token. The Server grabs the seed, and what it
calculates to be the Current Time used in that particular token, and
hashes them into a token-code. The result is then compared against the
information submitted by the remote user seeking authentication.
(This is a closed system, so the term "Current Time" is a bit
of a misnomer. There is no need to have the ACE/Server's time set at
GMT, or to have any set relationship with Time in the real world,
unless there are other apps on the host which require it.)
Actually, the ACE/Server automatically generates three
consecutive (but pseudo-random) token-codes to match against the
token-code which -- with a user name and PIN -- is submitted to the
ACE/Server by a remote user. The three token-code spread or window is
an adaption deemed necessary to address the likelyhood of "drift" from
a precise time-line in either the token's clock-chip or the Server's
clock.
Only if the token-code submitted, with a valid PIN, by the
user matches one of these three token-codes -- hashed with consecutive
counts of Current Time, with one-minute intervals -- is the user's
identity authenticated by the ACE/Server and his access privileges
validated.
In the typical ACE client/server installation, a remote user
connects to an ACE/Client, and the ACE/Client uses the ACE protocol --
which depends upon DES and F2, another SDTI-proprietary hash (designed
by Ron Rivest)-- to further secure the authentication exchange between
the ACE/Client and the ACE/Server.
[Given that SDTI is the company that bankrolled RSA's DES
Challenge Contests, which have so flamboyantly documented the relative
weakness of DES, SDTI has -- IMNSHO -- been a little slow in upgrading
the crypto in their DES-based client/server protocol. Remember,
however, that the crypto in the ACE c/s protocol is only protecting an
OTP with a brief half-life: a token-code valuable only for a minute or
so. A year ago, at the RSA'98 Crypto Conference, SDTI published the
design of the standardized SSL-based strong-crypto protocol which is
gradually replacing the traditional ACE c/s protocol.]
Many third-party remote access apps (terminal servers and
firewalls, for example) now ship with integrated ACE/Client code.
VPNs, SSL, SSH, or other encryption systems are often used today to
secure the clear-text outward link -- from the user to the ACE/Client
-- to protect it against active network attacks (like TCP splicing)
and secure any subsequent transactions or data flow. Most of the
leading VPNs today ship with integrated ACE/Client code too.
ACE client/server applications are the norm, but there are
other SecurID authentication systems in which the "server functions"
are packaged in small stand-alone hardware boxes or, at the other end
of the scale, in the speedy (1,000+ authentications/second) systems
used by the huge ISPs (AOL, CIS, or MCI, for example) as a MVS or OS
390 mainframe app.
Bradley Yearwood <[EMAIL PROTECTED]> recalled:
|||> [...] From time to time, the server will decide to ask you to
|||> wait for the next code to appear, and enter that. Whether this
|||> is a measure to reinforce against some at least theoretical
|||> weakness, or to help resynchronize to a highly skewed token, I am
|||> not certain.
This is a routine ACE/Server protocol to resynchronize the
SecurID token's clock-crystal with the Server's clock. This protocol
-- what an ACE Admin would call "Next Token Mode" -- is used to
account for "drift" at either end: in a specific SecurID, or in the
Server that supports it. It can indicate a need to resynch a token,
but remember that the protocol works on the unlikely presumption that
the server's clock is stable and precise.
In fact, the token's clock-chip is quite stable -- far better
than the typical digital watch -- and the bothersome Next Token demand
is often required to address some hiccup or reset of the server's
host. It is surely a rank injustice that the poor SecurID usually gets
the blame, as in Mr. Yearwood's assumption that the irksome
once-in-a-while demand for two consecutive token-codes was caused by
"a highly skewed token."
Mr. Farkle asked:
/> [...] How does the server know the card's serial number?
When he receives a shipment of new SecurID tokens, the Admin
or owner of an ACE/Server also gets an encrypted disk with the secret
seeds (indexed by serial number) for all the tokens he has purchased.
The (unique, 64-bit, true-random) seeds have already been programmed
into each token by SDTI as part of the manufacturing process.
The ACE Administrator loads the list of seeds into the
ACE/Server RDBS. As he assigns the tokens to individual users (whose
identity has been vouched for "out of band") the Admin makes a
notation in the ACE/Server database as to which token has been
assigned to which user.
The token's serial number -- embossed on the back of most
SecurID cards or key-fobs; perhaps still sticker-labelled on others --
is used _only_ to index the seeds for the Admin's on-site assignment
of the token to the user. (A SecurID's serial number does not, of
course, figure at all in the calculation of a SecurID token-code.
There is an amazingly rich -- albiet ridiculous -- lore of rumor to
the contrary;-)
Two-factor authentication is the traditional definition of
"strong user authentication." With the first use of a SecurID, the
token is locked into what SDTI calls New PIN Mode: waiting for (a) the
user to define his or her 6-8 digit PIN, or (b) the user to accept and
acknowledge a PIN generated by the ACE/Server, or (c) for the user to
choose (a) or (b).
(The ACE Admin configures these options in accordance with his
local security policy. For the first logon with a new SecurID --
before a user can be dropped into New PIN Mode -- a token-holder is
usually told to use some fixed identifier, often his name, as the
initial PIN.)
Mr. Farkle asked:
>>Since this system relies rather heavily on the card and the server
>>being in sync, what is the accuracy of the card's time function?
Mr. Rubin replied:
>Similar to a digital watch. The server notices as the card's clock
>drifts, and adjusts for this.
The error range for the crystal used in a SecurID's clock-chip
is, as I recall, guarranteed to be less than ten parts per million --
which means the token should not drift off its absolute time-line by
more than a second every couple of days; maybe 2 minutes per year; ten
minutes over a SecurID's max five-year lifespan.
In manufacturing the SecurID, however, SDTI takes that
worst-case scenario and refines it by precisely measuring the drift in
a specific chip and coding a software correction for it into the
token. That cuts the SecurID's base-line drift in the hardware to
maybe a couple of seconds per month.
It's the unpredictable enironmental factors -- notably
climate; heat and cold -- that introduce wild cards that distort the
SecurID's time-line over the life of a token. The mechanics by which
the ACE/Server tracks those effects, and adapts to whatever
distortions they (and the management of the server) introduce into the
token/server synchronization is the patented heart of the ACE/SecurID
system.
Mr. Farkle:
/> How would the server be able to notice the clock drift?
It is not difficult to track a SecurID's clock-drift (relative
to the ACE/Server's version of "Current Time") as the token is used.
The ACE/Server maintains a record of how closely a particular
SecurID hews to the projected (and constantly updated) time-line the
ACE/Server calculates for it, each time it is used. The server's
database also records, for each user/SecurID, which token-codes have
been used, and when -- so it always knows how long it has been since a
particular SecurID was last used.
A lot of the predicable attacks on a Time-based system are
effectively blocked just because the ACE/Server will not accept the
repeat use of a token-code from the same SecurID.
Another ACE/Server guideline: any three consecutive "bad
logins" with a SecurID -- either a good-PIN/bad-token-code, or
bad-PIN/good token-code combination -- will result in the ACE/Server
disabling the account until it is reset by the Administrator.
Mr. Farkle:
/> [...] There's a potential of having several thousand users in this
/> system -- would the server really be deducing clock drift info from
/> a 6 digit number that also has to contain an authentication and
/> keep a database on all the users?
As Mr. Rubin dryly noted, this is "not a terribly large
database by today's standards." The ACE/Server's built-in Progress
RDBS has no problem managing this data for tens of thousands of users.
Also, the 6-8 digit SecurID token-code does not exactly "contain" an
authentication; it merely provides timely evidence that the remote
user has immediate access to that particular SecurID at this moment.
Tracking any drift in the token/server synchronization is not
particularly difficult (and it is simplified by the design decision
that has the token's clock brought into allignment with the
ACE/Server's clock, which is presumed to be accurate and stable.)
The SecurID token-code is a hash of Current Time and the
SecurID's secret seed. If the ACE/Server can calculate (or, failing
that, systematically guess) what the token is using for "Current
Time," the difference between whatever version of "Current Time" was
used to generate a particular token-code, and what the ACE/Server
expected that token to use as "Current Time," becomes self-evident.
(The ACE/Server has a routine to discover this, but it
separate and distinct from the authentication cycle that approves or
disapproves a particular authentication call.)
Lyal Collins <[EMAIL PROTECTED]> noted:
||> Apparently there is a parameter on how many minutes (sub-minute
||> drift is not an issue) the server is allowed to "try" either side
||> of the current server time.
The potential for unpredicable "drift" in one of the two
time-lines (token and server) being synchronized is what led the SDTI
designers to use a three token-code "window" as their target, when an
incoming authentication call requires a comparison and match between
the two.
In its authentication cycle, the ACE/Server automatically
calculates three token-codes when it receives a user's logon name: one
for the one-minute time-slot before, and one for the one-minute
time-slot after, whatever precise (to the minute) "Current Time" the
ACE/Server expects this particular SecurID to use in generating a
token-code.
Only if the user submits the correct PIN and one of those
three token-codes does the ACE/Server authenticate him.
In addition to this authentication cycle, however, the ACE
system has a reset cycle -- an attempt to minimize the number of valid
users who could have their logons rejected because of some drift in
their token's time-line, or some minor hiccup in the operation or
<blush> human administration of the ACE/Server's platform.
This is what happens: when a user submits a valid name and a
valid PIN -- but with a SecurID token-code that is not one of the
three pre-calculated by the ACE/Server -- the server automatically
drops into a search pattern, a reset mode, to check on whether there
has been some unexpected drift in the token's version of "Current
Time," or in the time-line generated by the ACE/Server itself.
Again: this is not an authentication cycle -- a PIN/SecurID
combination is validated (and the user's identify authenticated)
_only_ if the ACE/Server successfully matches an incoming
authentication call against one of the three token-codes it just
hashed, using its ACE database records of this token's secrets.
In its automatic reset mode, the ACE/Server expands the search
window slightly -- often one minute to either side of the three
token-code target -- to look for valid tokens with time-chips which
have, for whatever reason, fallen out of synchronization with the
ACE/Server.
The size of the window searched by the ACE/Server in reset
mode is configurable by the local ACE Admin, but it typically varies
according to how long it has been since that particular token
(identified by the user's name) has been used.
Minimally, reset mode calculates two additional time-codes --
for the one-minute time slot before and after the three token-codes
initially checked in the authentication cycle.
That window can be incrimentally expanded -- by one time-code
(a one-minute variance in Current Time) to either side for the base
three -- for every two weeks that this particular SecurID has not been
used, but only so far. Even if this SecurID has not be used for 6
months or more, the search window can not be extended to cover more
than a ten-minute drift from whatever the server initially expected
this SecurID to use as "Current Time."
Thus, for a SecurID that is used daily or even weekly, a good
PIN, but bad token-code, combination -- even a typo in the user's
routine input of the PIN/token-code at a keyboard -- will result in
the ACE/Server quickly calculating two additional token-code to make
certain that there was not some unexpected drift in the token's
time-chip.
For a token that has not been used in a six months to a year,
an ACE/Server may generate a list of 21 potentially valid token-codes
to compare against one submitted by a remote user who also had a valid
user name and PIN. (Local site policy may be tighter than this, and
many are, but it can not be any more expansive than this.)
Whether it was off by one or ten minutes, a match between an
incoming token-code and one of those calculated by an ACE/Server in
this extended search pattern _never_ results in that remote user being
authenticated. At best, it merely short-cuts the procedure of a second
logon -- and quickly gives him a second chance to prove that he holds
the SecurID assigned to him -- by inviting him to submit another valid
token-code.
To summarize the mechanics: if an ACE/Server drops into reset
mode, calculates this expanded list of two to 18 additional
token-codes, and discovers a match to the submitted token-code in this
expanded list, the database records the apparent drift of the token's
clock-chip.
The ACE/Server then rolls back into its authentication cycle
to demand a new and different SecurID token-code from the remote user.
This second SecurID token-code is then matched against a new
calculation of three token-codes, adjusted according to the new
information about that token's apparent drift.
<Whew!> I beg pardon for the wordy explanation, but the
mechanics involved in this resynch process -- and the statistical
impact of the reset upon the odds of someone trying to guess two
consecutive 6-8 digit random numbers out of that huge solution space
-- has confused bright people over the past decade.
Mr. Collins, more tersely than I, tried to summarize:
||> Greater time windows allows potential for token misuse, replay
||> etc. Narrow widows mean drift (ie battery voltage, temperature
||> etc) problems cause lock-outs.
In terms of the winner's circle of three token-codes which
will result in a remote SecurID user (who has the proper PIN) getting
authenticated, I guess this is overtly true. (Although, with a
SecurID, replay attacks are not an issue, since a given token-code is
not accepted twice from the same token.)
It is not accurate, however, to imply that the reset cycle --
looking for valid tokens which have drifted from their expected
time-time -- effectively expands that inner three-token-code window
and opens additional vulnerabilities.
If an illegitimate "user" was able to get a valid user's name
and also compromise that user's PIN -- but was unable to steal the
appropriate SecurID token -- to gain illicit access he would have to
be lucky enough to guess one of three random numbers in a solution
space of 100 million possible 8-digit numbers.
And with three consecutive bad guesses, the ACE/Server
automatically blocks the account.
If an attacker didn't guess one of the three -- but was lucky
enough to guess one of the 21 token-codes calculated in the
ACE/Server's extended search pattern -- the best he can expect is to
be given another chance to submit a second valid SecurID token-code.
So his odds go to hell and he is worse off.
The likelyhood of an attacker correctly guessing _two_
pseudo-random 8-digit token-codes in the correct sequence from among
the whole solution space of 8-digit possibilities run something like
one in 250 trillion.
Leadacid <[EMAIL PROTECTED]> suggested a type
of "attack" on the ACE/Server, but even he admitted that he didn't see
how it could benefit even a malicious valid user.
>/> [...] you could deliberately make it look like your card's clock
>/> was dying. A moment before you log in, jot down the number from
>/> the card. Wait say 2 minutes and log in. Just in case, write down
>/> the next number and delay that the same amount of time, in case
>/> the server asks for a second number. Next time you log in, write
>/> down the numbers and wait 3 minutes before logging in, etc.
>/> Pretty soon you'll have the server _expecting_ to see your numbers
>/> skewed by 10 minutes.
Awkward and difficult, and to what end? A valid SecurID user
could undoubtedly fake a gradual skew in his SecurID's token-code, but
even if he avoided a Next Token challenge (and/or a visit from an
irritated network security administrator), I don't see a vulnerability
here.
SDTI's ACE/SecurID system is one of the Grand Old Ladies of
computer security. Its foibles are known and its capabilities are well
understood by the corporate network managers who depend upon it. That
is why -- despite the fact that user authentication is now an
incredibly dynamic market with an wide array of new PKI and cert-based
technologies -- SecurIDs are likely to remain in widespread use.
SDTI now offers a new authentication system, Keon, which reveiled
SDTI's PKI, digital sig, and X.509 cert-based resource management
scheme with single signon: <http://www.securid.com>. One of the more
interesting aspect of this new family of RSA-based authentication
products is that it can use either traditional smartcards or "soft
smartcards" to hold user credentials.
The soft smartcard scheme uses a PSE or e wallet to hold the user's
encrypted credentials (certs and PKC keys) either locally on a
workstation or on a Keon Server elsewhere on the network. With an SSL
connection, the Keon Server can drop a symmetric decryption key to a
mobile user (or a user who can not adequately secure his workstation)
after the user submits a PIN and SecurID token-code to authenticate
himself.
I beg the indulgence of the Newsgroup for the length of this post. I
hope it addressed the questions that were raised. If anyone has any
additional questions, public or private, I'll try to answer them.
Surete,
_Vin
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
