[228] in Kerberos_V5_Development
Smartcards
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Fri Apr 20 19:42:39 1990
Date: Fri, 20 Apr 90 19:41:45 -0400
From: Jeffrey I. Schiller <jis@MIT.EDU>
To: bcn@CS.WASHINGTON.EDU
Cc: krbdev@ATHENA.MIT.EDU, geer@CRL.DEC.COM, lstans@SANDIA.GOV
In-Reply-To: Clifford Neuman's message of Fri, 20 Apr 90 10:42:51 -0700 <9004201742.AA00219@n1dmm.cs.washington.edu>
I suspect that the SmartCard type you are referring to is the
product available from Security Dynamics, which is of the kind you
described.
I spent some time thinking about how to do this. The problem
isn't in the human time delay (the card changes relatively slowly
compared to human response time), but instead it is the fact that the
clock on the card can drift. In the timesharing situation this problem
can be addressed as follows:
The system keeps track of the "seed" used for the number
generation of the card (and thus in theory can compute what number
should be displayed as a function of time t0, seed initialization
time, and the current time). It also keeps track of a drift value
which is a frequency offset of where the card tends to be relative to
true tick, and a phase offset, which is the known time offset as
measured when the card was last used. Finally you keep track of the
time the card was last used.
Basically when a user attempts to login with the card, you
compute the expected value given the known offset and drift value. You
then compute a set of values that are "around" the expected value. The
more time that has gone by since the card was last used, the more
values you have to put into the acceptable set. When a number (in the
acceptable set) is typed in, you use that value to correct the offset
error and drift values in the systems database.
Without modest modification to the initial ticket transaction,
it is difficult to provide the feedback to the system about which
value was successful (so the database can be kept up to date). What I
have come up with involves a new field to be added to the initial
ticket request which represents a requested "time shift" value. When
you first attempt to get a ticket you specify time shift value 0, the
default, which results in a TGT being encrypted in the expected value
on the card (possibly mixed with a fixed password for additional
security). If this cannot be decrypted (because of clock drift on the
card) you ask for either value 1 or -1 and try again. Basically the
client code hunts around with differing values of times shift until it
is successful, or until the server returns a "time shift error"
response which implies that an unacceptable time shift value has been
requested. The range of acceptable time shift values that the kerberos
server will accept depends on how long it has been since the card was
successfully used (which is a measure of how uncertain its displayed
value may be).
The server keeps track of the time shift values requested and
caches the last one requested in some short term memory (ie. a table
indexed by principal id that is not kept for more then a few minutes).
When a successful APPLICATION request (ie. use of the TGT) comes in
from the same location, the kerberos server updates its database to
indicate a successful "login" and uses the value of the last "time
shift" value requested to determine the necessary offset and phase
adjustments to store about the card (and the info can be removed from
the short term cache).
Comments?
-Jeff
