[3260] in cryptography@c2.net mail archive
RE: Time Based Token?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Thu Aug 27 10:42:29 1998
Date: Wed, 26 Aug 1998 20:47:35 -0400
To: tzeruch@ceddec.com
From: Vin McLellan <vin@shore.net>
Cc: cryptography@c2.net
<tzeruch@ceddec.com> started an interesting thread by explaining:
>Now that I am playing with my palm III, something came up that made me
>think of that token which displays a different number every 30 seconds.
>
>Would something that would do a SHA1 of about 1K of random data (as a
>shared secret), and the current time be secure? Or would it have to be
>more elaborate?
You'll want to use a PIN or password somewhere in your design to
make it a two-factor authentication, I think. This could be done either in
the Palm III to access the authentication module, or (if the PIN is
transmitted with the "token-code") at the authentication server.
I don't see any problem with a SHA1 hash.
A SecurID puts a 64-bit true-random secret, concatonated with a
32-bit representation of "Current Time," though a proprietary one-way
function to continuously generate 6-8 digits (or alphanumeric characters,)
with a new token-code every 30 or 60 seconds. SDTI is expected to soon
shift to MD5 or SHA1 for the SecurID too.
The traditional advantage of SecurID time-synched tokens over a
Challenge/Response token -- besides the fact that it is not DES-based;-) --
is ease of use. The SecurID user does not have to tap the Challenge into
the hand-held device to encrypt or calculate the authenticating Response
(the OTP or one-time password.) You just read off the SecurID token-code
and type it in at the keyboard, along with the memorized PIN, like any
longish password.
(For a home-brew system in a personal network environment, however,
there are also adaptions of the C/R design that effectively match that ease
of use with less engineering. One keeps the previous Response and assumes
it to be the next Challenge. I have problems with this in a large user
population, but I'd probably consider it for a personal host. From the tone
and context of your message, I'm going to presume this is a personal system
you are protecting. For large multi-user environments, the complexity of
managing user records -- and the pending integration of Single Signon and
PKI service options -- make commercial OTP systems with more robust servers
attractive to many, despite their cost.)
Other people have mention most of the things you have to guard
against in designing a time-synch authentication system: playback attacks,
race attacks (which aren't a problem with C/R tokens,) MitM attacks, clock
roll-ahead attacks, and -- of course -- the whole genre of active "session
hijack" network attacks. You will also want an auto-shut down if your
system is being bombarded and you have X authentication failures on a given
account, or Y guesses on the PIN (with the right OTP.) These latter
controls open you up to DoS attacks, of course, but the tradeoff is that
the system fails safely, with the door closed.
As others have also said, you should look at encryption for secure
remote access too. Authentication without a secure link can be nearly as
dangerous as encryption with weak or no user-authentication. If you are
rolling your own, you might as well be self-conscious about whether the
potential threats against your resource demand strong user authentication
-- with or without a encrypted channel -- or whether the authentication of
your client/desktop (or PKI certs held on the client/desktop) is enough,
when used with or without encryption. As with any network design issue,
there are tradeoffs and a variety of options.
I think the potential value of the resource you are protecting --
and whether you are authenticating over the Net, or directly by phone --
makes a difference in evaluating your risks and need for crypto. Others
are more religious, one way or the other. Today, I'd incline to design the
VPN in, if your remote client environments can handle it.
Although there is still a large group of ACE/SecurID sites which
use just authentication to secure remote sessions on telephone lines; for
the past several of years, most new ACE/SecurID installations have probably
married crypto and strong authentication.
(Most of the commercial VPN market, 19 vendors, have integrated
ACE/Agent code to support SecurIDs for strong two-factor user
authentication, and 12 of the commercial firewalls -- including several
with FW/FW and client/FW crypto -- also ship "SecurID Ready," as the promos
put it. There's a list at: http://www.securitydynamics.com/partners/)
Ssh, besides offering robust crypto, has user-authentication
options for both the SecurID, generic Challenge/Response tokens, and
x509v.3 certs. If it were me building a home-brew system (and I've been a
consultant to SDTI since forever,) I think I'd consider SSh with the C/R
option (something stronger than DES) or certs -- just because building and
maintaining it might be much easier.
Managing two (or more) sources of Time can be more complex than it
sounds.
I don't know what your host is, and I don't know how stable the
Palm-III's clock is, but the traditional difficulty in managing a
time-synch OTP system is keeping the hand-held token's clock and the
server's clock in synch. (PCs, for instance, have clock-circuits of
distinctly variable quality.) Network time can help stabilize this, but
that raises other potential problems.
The SecurID uses a patented self-synch mechanism whereby the
server, with each use of the token, continuously tracks and records (at the
server) the relative drift of the token's clock-chip, vis-a-vis the
server's Current Time. When a particular user sends in a PIN and token-code
combination, the ACE/Server then refers first to its user-records to get
PIN/seed record for that user, and the delta it should use for that
particular token in calculating Current Time for the hash. Then is makes
sure that the token-code is not a repeat. And then it hashes the seed in
its records and Current Time to match against the token-code coming in with
the authentication call -- using what it _expects_ that particular token
will have used as Current Time.
Even with the auto-synch process, the SecurID system allows user
authentication with a hash for the predicted Current Time, and two more
hashes: one calculated for the 30/60 second time-slot before the expected
token-code, and the second for the 30/60 second time-slot after the
expected token-code. If the SecurID hasn't been used for awhile, and the
drift is outside of expectations, the ACE/Server may also demand two
sequential token-codes to validate an incoming authentication call. Then if
updates its projected drift record on that token.
It's an engineering pain, but it is relatively easier to use than
other C/R OTP tokens. Frankly, while I see all the advantages of PKI
supported by smartcards, I think we are going to regret the loss of the
simplicity that we see in all these classic tokens which do just one thing
and, demonstratably, nothing more than that one thing.
Pardon the length of this note. As is often the case, the strength
of this type of cryptosystem stands or falls on the protocol and
architecture used to implement it. Devil in the details, etc.
Suerte,
_Vin
-----
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-- <@><@> --
