In a message dated 95-11-26 12:41:43 EST, Padgett Peterson, PE writes:
>>Thanks to yet another person asking what I meant by "Time Synchronous
>>is a dead end", I finally realized what has been bothering me for
>>years about the TS vs C/R issues was really described a few years ago by
>>Willy the Barber.
>>
>In a nutshell, Challenge Response depends only on two things - a token with
>a key/seed and an algorithm, and a host with the same. The user may enter a
>PIN along with the challenge to release them but the basic dependancy is on
>these two items only.
Not true, Padgett. It also requires a random number generator to generate
the challenges. As you well know, this is a difficult problem.
>>
>>Time Synchronous introduces two additional elements - the clocks at each
>> end. Being known elements, they add nothing to the security but introduce
>>uncertainty into the equation, uncertainty that necessitates the use of
>>windows of acceptability, windows that allow not one specific password
>>but a range of them and requires a "synchronization factor" to be built
>>into the software (host) end.
Padgett, you are incorrigible. By being flip, you may mislead someone.
Before going any further, let me say that I am not a party to the Security
Dynamics technology or implementation. What I am going to say, I have
learned by inference. On the other hand, it is logically correct and
reliance upon it will not get anyone in any trouble.
It is true that there is a clock at each end but it is not true that it is a
known element, any more than the PRNG in challenge response system is a known
element. In fact, there are as many clocks at each end as there are known
parties, i.e., tokens. There is a logical clock for each token, a logical
clock for the system, and what you think of as the system clock. The setting
of the logical clock for each token and the token identity are the only
values that need be stored for the token. This is analogous to storing the
token identity and the seed for the challenge-response token. The logical
clock setting value looks like a random number and cannot be predicted from
real time.
There are also as many physical clocks as there are parties but the setting
of these clocks is arbitrary; the only thing about them that is used is the
tick.
Neither can the value of the logical system clock be inferred from real-time
or the system clock. The value of this clock is different from that of the
logical system clock for every other system in the world. The logical system
clock is set from the administrators token, not from the system clock or real
time. The only thing that the logical system clock takes from the system
clock is the tick or offset.
Thus, one way to think of the reconciliation is: from the value of logical
system clock, the tick, and the logical clock for the token, compute the time
for the administrators token. From the passcode, compute the offset time
that the token believes it to be. Store that value as the new logical time
for the token (i.e., self synchronising and self securing); reconcile the
users token time to the administrators token time. Note that this can be
done to any arbitrary degree of precision, i.e., confidence. If the result
is not within tolerance, repeat the whole operation (i.e., ask for another
passcode.) Since you have just re-synchronized, the result this time should
be correct. If not, then the token is not valid.
Note that this second operation is analogous to a challenge-response.
Note also, that this explaination is a gross oversimplification of what
happens. For security reasons all of these values are encrypted. While I
cannot infer from outside how this is done, you and I can both think of a
number of schemes that would work.
>>
>>In the past, this "fuzzy authentication" has been acceptable since the
>>risk is small and the users like not having to enter anything into the
card.
As I say, arbitrary but not at all "fuzzy." In no case is a passcode good
more than once. If you set the tolerance to ten seconds, it will still work;
just have to give the second passcode more often, not to say most of the
time. However, in a challenge response system one has to enter both the
challenge and the response every time.
>>However the great leveler - soft tokens where the user just enters a PIN
>>an all else is automatic - is considerably "fuzzier" where clocks are
>>concerned, and the first thing that goes when the CMOS battery decays is
>>the precision of the clock.
First, a reminder that Security Dynamics does not offer a soft-token.
However, if it did, the system would still work. In such a soft token
implementation, the software on the source system would have to take its tick
from the the CMOS clock (just as the DOS clock does and just as the target
system clock does). (It does not take real-time from this clock any more
often than these other clocks do; alternatively, it could take it from a
token.) This tick would be somewhat less reliable than that of the quartz
clock in the token. While this would mean that the second operation would be
required more often, it would all be invisible to the user. Thus in
software, the time synchronization system looks even more like the
challenge-response.
>>Further, use of tokens for creation of secure channels requires exact
>>precision - use the wrong key and you won't communicate (not saying you
>>cannot create a secure channel with TS - I discussed a means with the
>>people at Allwife Center over a year ago - just is more difficult).
At this point, it should be clear that synchronization is not an issue. At
any rate, who cares; the security is the same and the user does not see it.
>>So the bottom lime is that like "close shave Willie", I think the simplest
>>system that does the job is the right approach and that IMNSHO is C/R.
And as I have said before, it is a distinction without a difference.
Nothing in this system is any more deterministic than the PRNG in the
challenge response system. There are no more secrets to keep. That we are
using a tick from system clocks saves key strokes. Even though it is
counter-intuitive, the fact that each token has its own clock and that no two
are exactly alike adds to the security of the system. Nothing that anyone
can observe from one token will enable him to infer anything about the
system. It does not as you, Padgett or "Close-Shave Willie," suggest, make
it fuzzy.
William Hugh Murray, CISSP
New Canaan, Connecticut
|
|
