Re: swc / ActivCard

[Alan DeKok <aland () STRIKER OTTAWA ON CA>]

  The ActivCARD vulnerability seems to have been documented in another
form on their web site.  Details on the ActivCARD synchronous
challenge mechanism can be found at:

http://www.activcard.com/activ/services/library/synchronous_authentication.pdf

  To quote from page 6:

> Synchronous Authentication: Details
>
>  The following steps delineate synchronous user authentication using
> an ActivCard client (token or smart card) and ActivCard software. This
> password generation is based on three variables - a synchronous
> technology that is patented by ActivCard. (See Figure 4.)

  That isn't necessarily impressive.

> The first series of tasks is performed by the client:
>
> 1. The client builds an internal challenge (independently of the
> server) using two variables (the client clock counter value and the
> client event counter value).
>
> 2. The client encrypts this internal challenge with the DES algorithm
> (which utilizes in its mathematical formula a third variable  a
> derived secret key that is unique to that specific client and is used
> ONLY for that specific encryption session.)
>
> 3. The client selects the two least significant digits (one each from
> the event and clock counters) and pre-fixes them to the encrypted
> challenge. The encrypted challenge and special digits together form a
> one-time-use password, which is sent to the server during a request
> for authentication to restricted resources.

  It is step (3) here which appears to make the passwords at least
partially "predictable".

  The original list of passwords posted was:

Michal Zalewski <lcamtuf () DIONE IDS PL> wrote:
>   05314080                                 .
>   06401172     < increment around 1.1M     : --- sequence of increments
>   07332504     < increment around 0.9M     |
>   08957912     < increment around 1.6M     |
>   09134516     < increment around 0.2M    /
>   00104910     < large decrement
>   ...                                     \

  The first two digits of the password are trivially derived from
highly predictable counters, which explains why they're so regular.
It does not, however, explain why the the *rest* of the digits are so
predictable:

Michal Zalewski <lcamtuf () DIONE IDS PL> wrote:
> Even basing on our rough estimations and basic analysis, we were
> able to guess next number with about 35% chance within 100 attempts -

  To me, this would appear that the method used by ActivCard to derive
synchronous passwords is *highly* flawed, despite their claimed
reliance on DES for calculating the final 6 digits of the password.


further quoting from synchronous_authentication.pdf:
> 4. The client increments its event counter by one and derives a new
> secret key, which overwrites the secret just used in the above
> encryption session. (Again, please refer to Figure 4 for an
> illustration of "client-side" password generation based on three
> variables.)


  I had misread the original post to mean that the challenges were
predictable.  This is not necessarily bad.  But having the responses
predictable is unforgivable in a security product.


  A properly designed synchronous algorithm would not find it
necessary to leak information about the internal state of the card,
and would not result in highly predictable "DES encrypted" results for
the final 6 digits of the password.

  As I pointed out in my last message, the method used by CRYPTOCard
to calculate synchronous passwords does not suffer from ANY of the
flaws of the ActivCard method.  The CRYPTOCard tokens, therefore, are
not vulnerable to this attack.


  The method used by ActivCard for generating synchronous algorithms
also seems to be overly complex.  Steps (2) and (4) describe a
"derived secret key".  I would suspect that this derivation process is
the source of the flaw.  Instead of relying on DES for security, the
ActivCard designers relied on "patented" algorithms, which caused
almost all of the security of DES to be bypassed.

  Alan DeKok.