Re: swc / ActivCard

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

Michal Zalewski <lcamtuf () DIONE IDS PL> wrote:
>    Some time ago, we performed brief, comparative analysis of one-time
>    passphrases returned by different tokens (SecurID and ActivCard,
>    mainly) in short time periods (collecting successive one-time
>    passwords returned by token).

  The ActivCard product uses the industry standard X9.9
challenge-response algorithm.[1] SecurID uses another, proprietary
method.  The two cards should not generally not be mentioned in the
same advisory, as it could cause confusion between two independent,
and unrelated, products.

>    Theoretically, default ActivCard 8-digit display can handle up to
>    100,000,000 combinations.

  To summarize X9.9, a DES key K is used to encrypt an 8-digit
ASCII numeric challenge, C.  The response is calculated via DES:

  R = E_K(C)

  The response is converted to ASCII by printing the first 4 octets of
R as hexadecimal, and then converting 'a..f' to '0..5'.  The resulting
8 digits comprise the challenge.

  This method is used by all X9.9 cards to calculate responses to
challenges.

>    First, while analysing output returned by different tokens kindly
>    provided to us, we thought ActivCard uses alarmingly small (within
>    around 1-2% of possible number space), but random positive increments in
>    random length sequences.

  This is obviously a security problem, but it is NOT related to
X9.9, and it does NOT affect other X9.9 cards.

  To repeat your earlier quote, you were:

> ... (collecting successive one-time passwords returned by token

  So far as I recall, X9.9 does NOT define a method for calculating a
series of one-time passwords.  It assumes that the challenge is
a random number.  (i.e. generated via a cryptographically strong
method.)

  So when the ActivCard displays high correlation in it's challenges,
it is a problem with ONLY ActivCard products.  This vulnerability does
NOT apply to other X9.9 cards, unless they're re-selling the ActivCard
tokens.


  The feature which converts an X9.9 card from a challenge/response
card, to one which displays a series of challenges is customer
driven.  There are situations where it is impossible to deliver a
challenge to the end user[2], forcing the authentication to use some
form of synchronized method.

  This method is one where the next challenge in sequence is
predictable, based on the knowledge of the last seen correct
challenge/response, and on the DES key K.  These algorithms inherently
result in challenges which are more predictable than purely random
ones.  To be secure, they should derive their sequences solely from
DES operations on the publicly known C and R, with the key K.


  In the interests of full disclosure, I used to work for CRYPTOCard
Inc.[3].

  Their card generates synchronized challenges of the form:

C_0: 12345678
R_0: 90123456
      ^ ^ ^ ^

C_1: 0246xxxx
R_1: yyyyyyyy


  Where the alternate digits of the response is used to calculate the
first 4 digits of the next challenge.  This reduces the possible
challenge space drastically, but there are still 10^4 (10,000)
possible challenges.

  The remaining 4 digits of the next challenge are calculated via the
publicly known C_0 and R_0, and a DES operation using the key K.
Therefore, those digits are only as predictable as the digits from any
DES operation.

  I won't go into further details, to avoid conflict of interest.



  In summary, the successive challenge algorithm is vendor-specific
for X9.9 cards.  Vendors should take care to ensure that their
implementation is cryptographically strong.  The obvious method,
C_1 = E_K(R_0) does not appear to have been implemented by any vendor
I'm aware of.


  Alan DeKok.


References
----------
[1] http://www.safeword.com/activcd.html
[2] RADIUS implementations which ignore RFC Access-Challenge requests,
    or HTTP authentication.
[3] http://www.cryptocard.com/