Bugtraq mailing list archives

Re: swc / ActivCard


From: Brian Kowal <bkowal () ACTIVCARD COM>
Date: Thu, 24 Aug 2000 21:46:07 -0000

For folks interested in this discussion, I would recommend 
that they read the ActivCard white paper on their 
Synchronous authentication found at:
http://www.activcard.com/activ/services/library/synchronous_
authentication.pdf

I also would like to make it clear that ActivCard employs 
two different methods of one-time use passwords.  
Synchronous and Asynchronous (X9.9 based Challenge Response)

Regarding the previous discussions about ActivCard's 
Synchronous method:

Mr Zaleski has made an interesting request for discussion 
regarding the predictability of the ActivCard Synchronous 
Algorithm.  Discussion is good, but unfortunately Mr 
Zaleski rides a dangerous line here by offering some 
statistical analysis that alludes to a perdictability 
vulnerability.  The unfortunate part of this is that Mr 
Zaleski's analysis is not complete - and thus there are 
some fatal flaws to some of his assumptions. Mr Zaleski has 
written that he tried "to collect the most accurate and 
representative data and provide objective and realible 
informations".  However, it becomes clear through his 
initial statements he did not read (or if he had, he did 
not understand) the Synchronous white paper that I 
mentioned earlier in this post.

Basically what Mr Zaleski has found is that the first two 
digits of our authentication code are the least significant 
digits of the clock and authentication counter, this is 
public information fully explained in the white paper. The 
purpose of these digits are resynchronisation of the token 
with the authentication server. The remaining digits of the 
code are the output of a DES operation, which is a proven 
and well scrutinized algorithm. And the length of the code 
is customizable meaning that if necessary the part of the 
code taken from the DES calculation result can be increased 
to more than 6 digits.

Mr Zaleski's initial posting also missed that the DES 
algorithm is part of the ActivCard Synchronous method. In 
this method a DES key K is used to encrypt a 64 bits 
digital challenge C.  The response is calculated via DES:

  R = E_K(C)

C is generated by concatenating a 32 bits event counter, 
and a 32 bits Clock counter. On top of that the Key K is 
derivated each time, meaning that it is always different. 
The next key Kn+1 is the result of a key derivation 
algorithm (following X9.24 standard) with the current Kn as 
input, and the Event counter.

The response R is then converted to ASCII, and 6 to 10 
digits of the result are then used as part of the response 
displayed on the screen. Two digits are appended on front 
of the ASCII string for resynchronisation purposes: The 
least significant digit of the clock, and the least 
significant digit of the counter. These two digits are the 
one identified by Mr Zalewski in his attack.

So between two authentications:

R = E_Kn(Clock||Counter)

R+1 = E_Kn+1 (Clock + Time || Counter + 1)

Where Kn+1 = E_Kn(Counter XOR Kn).

I hope that clairfies the issue of the "predictability" of 
the first two digits of the reponse which are as explained 
in the white paper used for resynchronisation purposes. 
Desynchornisation being one of the major operational of 
synchronous password, this feature is quite important to us.

So the key issue here is the "predictability" of the output 
of the DES algorithm, which would be linked to a the way we 
derivate our K keys. 
1) ActivCard uses an ANSI approved derivation algorithm 
based on DES
2) the algorithm using this key is a pure DES ECB

Thus the direction of Mr Zaleski's challenge/"research" 
should be is in the weakness of DES.

Vin McLellan also posted a well worded response regarding 
this thread - which for those new to the thread, I recomend 
going into the bugtraq archives to read.

Regards,
Brian A. Kowal
Systems Engineering - ActivCard


Current thread: