Re: swc / ActivCard

[Vin McLellan <vin () SHORE NET>]

>         Of the ActivCard's 8-digit tokencode, Alan DeKok
> <aland () STRIKER OTTAWA ON CA> wrote:
>
> > 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>, who initiated this
discussion, replied:

> To make everything clear - as I noticed, I just wanted to start a
> discussion and futher investigation of this ActivCard One synchronous
> token issue. None of my statements cannot be threated as true without
> checking it independently (what I saild clearly, as well, because I was
> using only a few sources of input data for my analysis and it's quite
> possible I've made bad assumptions somewhere). Sadly, some people (both
> from ActivCard representatives and not related to this company), didn't
> understand the nature of my post - and I guess it can be only a bad will,
> because I stated it clearly, _twice_.

        With due respect, Mr. Z, when you claim to have developed a method
which allows you to predict-- within 100 guesses, one-third of the time --
the *next* tokencode from a specific ActivCard two-factor authentication
token, you are not just asking for a collegial statistical review of an
ActivCard's tokencode output.

        Whatever waffling qualifications you placed around that claim, you
declared an achievement which implied that those institutions -- a large
portion of them European banks -- which use ActivCard to secure network
access, and enable commercial funds transfers, have placed themselves,
their customers, and probably billions of zloty, at risk.

        From you, if from no one else.

        We have a legal convention about "free speech" in the US which
suggests that while anyone can say almost anything, a person who shouts
"Fire!" in a crowded theater -- almost sure to panic the audience, with
substantial risk of injury to many -- should be held liable for injuries,
deaths, and damages caused by his irresponsibility (no matter whether his
intentions were playful, curious, or malevolent.)

        I don't think even your initial post rises to that level -- and I
suppose discussion of individual (as opposed to vendor) responsibility for
dangerous speech sounds incongruous when click-'n-kill exploit code is
freely distributed to the script kiddies by self-righteous activists in the
InfoSec community -- but I can certainly see why your claims and
allegations, however qualified, freaked out many ActivCard customers.

        You seek to have it both ways. You make a devastating accusation
in a very public forum, then you deny the material consequences of your
claim by refusing to document your work, and asking others to validate or
invalidate your results. You claim prodigious results, then you declare
your own uncertainty about your own methods.

        Yet, your claims -- undocumented and certainly unproven --
nevertheless sounded vaguely credible. (Polish mathematicians and
cryptanalysts, even young ones, have a certain reputation;-) Even a pro
like Alan DeKok accepted your damning statements about predictable
ActivCard tokencodes at face value. I presume that there has been a
significant disruption in the business of at least some ActivCard
customers, probably with associated monetary losses.

        The fact that you had not made the most cursory inquiry into the
source and structure of ActivCard's 8-digit tokencode -- didn't bother to
find out that an ActivCard uses DES to generate only the bottom *six*
digits of its tokencode, and thus you went off to chart the top two digits
of the ActivCard tokencode as if their cycle indicated something other than
your inability to read ActivCard's white paper <www.activcard.com> on its
"synchronous" token -- doubtless reassured ActivCard and some of its bigger
customers that you were too ill-informed to be a serious threat.

        Others will still be, understandably, worried about your claims.

        As you dryly noted: "Predictability of passwords is definitely
against idea of such tokens."

> It's really bad, both to us and ActivCard, to spread FUD. So, it's time to
> state the facts:
>
> - we agreed that in 8-digit display, 2 first digits are highly
>   predictable, partially exposing some bits from internal counters
>   (I'm not sure what for). There numbers are almost 100% predictable;
>   as a result, we ha 10^6 combinations instead of 10^8 - which sounds
>   better for crackers,

        I don't know ActivCard's server, but there is a trivial defense
against brute force attacks on an authentication server: a self-imposed
Denial of Service. On RSA's ACE/SecurID, the token-based authentication
system with which I am most familiar, a user's account is frozen after
anyone makes more than a few erroneous guesses about a specific SecurID's
PIN or current tokencode.

        Given the presumed value of resources or applications which the
user is being vetted for access, it is reasonable to live with the risk of
a potential DoS on the user's access account, in order to assure that the
authentication system fails safely, denying access, when under attack.

> - in my set of information (the one I included in my post and for which
>   I have some troubles - but that's other issue), by dumping binary
>   image of these values, I found several uncommon conditions, like
>   alarmingly long sequences of even values (lowest bit set to zero),
>   some bit sequences appearing eg. with 75% probability where I should
>   expect something around 7-8% and so on. This lead me to perform
>   attempts to guess next values with good precision within reasonable
>   amount of tries. No, I didn't wrote magic program than can predict
>   next value returned by any token with 100%, but I feel alarmed by
>   my observations, and that's why I posted this strictly informal
>   call-for-discussion. Within it, I repeated several times these
>   observations might be not objective and MUST be verified; in some
>   subsequences of this input set, I reached probability of several
>   promiles, which actually isn't bad - especially because it's nothing
>   hard for computer to perform eg. 1000 attempts, which makes this
>   probability much higher.

        Michal, you may indeed have discovered some statistical
correlation that I can't see in the few numbers you provide.  I don't have
an ActivCard myself, and you provide no documentation on the series of
recorded ActivCard tokencodes you worked with. Your initial post provided
nothing at all on the method, algorithm, or protocol by which you were --
you said -- able to predict future ActivCard tokencodes with such
unexpected success. This second post isn't much better.

        The DES, as we all know, should produce a statistically random
(PRN) output for the bottom six digits of the ActivCard output -- whatever
the real or potential weaknesses in the three-variable ActivCard protocol
which feeds into that DES calculation.

        When you claim that ActivCard's tokencodes are not random, you
strongly suggest that ActivCard's DES implementation is severely flawed.
(Since ActivCard seems to install its "one-time password" generator on all
of the ActivCard smartcards, as well as the firm's "ActivCard One" tokens,
this raises the possibility that the crypto used in those smartcards may
also be flawed too.)

        Your concern about statistically "uncommon" patterns in the
ActivCard's tokencode series is doubtless a worthy subject for further
analysis, but your claim that you are able to "guess next values with good
precision within reasonable amount of tries" is where the sky threatens to
fall.

        With various corporate crown jewels and large monetary transaction
systems at immediate risk, that claim was (and is) far more incendiary than
a merely academic postulate raised for collegial discussion: the wimpy
"strictly informal call-for-discussion" that you now declare it to be.

        If you can, Michal, please provide evidence of exactly how you
were "able to guess next number with about 35% chances without 100
attempts." Even a simple work record of what you did -- what series of
recorded tokencodes you used as a base, and the method by which you came up
with which predicted tokencodes -- would help validate your concern, and
probably raise serious questions about the DES implementation used by
ActivCard.

> It's bad to debate about algorithm (or, better: implementation) weakness
> when in doubt. Unfortunately, we have no way to really discover the way
> this token uses to expose / hash it's internal state but by observation.

        Doubts are healthy. Curiosity is healthy. Calls for further study
are practical. Concrete claims that an ActivCard's tokencodes are
predictable -- allegations that you are unable or unwilling to substantiate
-- are dangerous, misleading, and unprofessional.

        (I don't want to sound patronizing, Michal, but you seem
bewildered and defensive about the reaction your post elicited from
ActivCard and ActivCard customers. That may merely indicate your youth or
inexperience, or it may have something to do with the fact that English is
probably not your native language. Since ActivCard has apparently chosen to
remain silent here, I thought I might -- graybeard that I am -- usefully
clarify what is at stake when a guy like you makes such an explosive, but
potentially credible, claim about a commercial product like an ActivCard
token in a forum like Bugtraq.)

>  I guess ActivCard users can easily verify my observations or try to
> perform more detailed analysis of information supplied by me or obtained
> on their own. Someone with good (better than mine) practical knowledge of
> cryptoanalysis and discrete systems' predictability should spent some time
> with it, for sure.

        I think you can take it for granted that hundreds of folks were
today trying to validate or disprove your analysis;-) Unfortunately, those
researchers can only speak about their analysis of the tokens they have at
hand. If they don't find anything untoward, they will likely remain silent.

        Only you can document the series of ActivCard tokencodes you
worked on, and explain the assumptions and procedures you used to so
accurately predict future token-codes.

        If you can, I urge you to do so. If you can not, you might
reconsider your belief that you confront only critics of ill will and bad
faith.

        Suerte,

                _Vin

Vin McLellan
The Privacy Guild
Chelsea, MA USA

PS:     RADIUS maven Alan DeKok, formerly with CryptoCard, cautioned that
Mr. Z should not have blithely mentioned both ActivCard and RSA's SecurID
in the same advisory, when he was discussing flaws found in only one:

>>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.

        I've been a consultant to RSA for many years.

        While the ActivCard and RSA's SecurID are both two-factor
authentication tokens -- something known; something held -- I obviously
agree with Mr. DeKok that the distinctions between the two should not be
lost, particularly when Mr. Zalewski is attempting to gut one or the other.

        A SecurID and an ActivCard are distinct and competitive products
from different companies. It is not, however, quite accurate to say they
are wholly unrelated.

        The unusual three-variable calculation (token-specific secret,
clock, & event-counter)used by "ActivCard One" was shaped and constrained
by RSA's mid-90s law suit against ActivCard for infringement of RSA's
patent for a time-synched hand-held authentication token, and the
subsequent settlement agreement.

        The mysterious "customer driven" demand that Mr. DeKok credited
with forcing the development of "synchronous" Challenge/Response tokens was
simply a market requirement that no hand-held authentication token be more
difficult to use than the SecurID, which was, in the early 1990s, trouncing
its C/R competitors.

        (In large part, the early success of the SecurID was due to its
popularity among users, mere token-holders -- although the ease-of-use bias
of the wee folk had not previously had any significant influence on the
policies and purchase decisions of many corporate security managers.
Fortunately for RSA, CEOs were, in this case, ranked among the users;-)

        In classical C/R authentication, a random Challenge is issued by
the host to a user seeking access privileges. The user taps a
user-memorized PIN and the server's PRN Challenge into a keypad on the C/R
token, and the Challenge is encrypted within the token with a
token-specific key to generate the Response: a one-time password which is
returned to the authentication server for yea or nay.

        By contrast, the SecurID cryptographically hashes Current Time and
a token-specific secret to produce a series of 60-second tokencodes, which
are continually displayed on the token's LCD. The user-memorized PIN and
the SecurID tokencode are together submitted to the remote server like one
longish password (today, often through an encrypted channel.)

        In the place of a random Challenge from the host, various "event
synchronous" C/R tokens often held the previous Response in memory and used
it, usually with input from a sequential counter which recorded successive
authentication calls or events, as elements of a pseudo-Challenge which
could be again encrypted with a secret key to generate the next "Response."

        Thus, the synchronous C/R tokens escaped the need for the C/R
round-robin exchange with the server, yet still kept the token
"synchronized" with the authentication server.

        ActivCard authentication uses a proprietary compound design.  An
ActivCard client or token uses both an event-counter and a clock variable
to maintain synchronization between the token and the server. It is a
complex and ingenious protocol, on which ActivCard holds several patents.

        (This is a longer than I intended it to be. I beg the pardon of
the List for the burden on the bandwidth.)

        _VbM