Re: swc / ActivCard

[Michal Zalewski <lcamtuf () DIONE IDS PL>]

On Wed, 23 Aug 2000, Vin McLellan wrote:

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

Yes, I am asking, because I stated it applies to the tokens I've tested,
and the data I've published - nothing more. From my original post:

   I guess all of them were
   previously synchronized to same server (most of them lost
   synchronisation in the meantime), that's why I'm asking other people to
   collect some information and try to verify these observatios.

I'm not claiming I've found a way to break every token, just found some
rules within collected data.

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

No. I declared achievemnt regarding this portion of data I collected. As
you should know, it's ALWAYS possible to write a function, that will
return some set of values in specific points, but it does not mean this
function will behave properly outside sample set used to derive it. That's
why my post was only an informal call-for-discussion, not "hey dudes, we
cracked ActivCard"! Another quote:

   Thus, please threat this message as an attempt to start futher, more
   complete analysis *ONLY*. You shouldn't trust these statements
   before making sure they're true - and we can't take *ANY* kind of
   responsibility they are.


> 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 haven't shout anything. I just posted strictly technical
call-for-discussion document on the list I believe is related to analysis
of such risks - and nowhere else. All security-related services have read
my policy, disclaimer and comments, and didn't posted any information
regarding "ActivCard bug" - because I didn't stated there's any. I only
asked other people to verify my observations.

> [...] but I can certainly see why your claims and allegations, however
> qualified, freaked out many ActivCard customers.

That's really sad, because it shouldn't. I do whatever I can to make clean
there's no reason to panic, just to check it on yourself.

> You seek to have it both ways. You make a devastating accusation
> in a very public forum [...]

BUGTRAQ is technical list related to bugs. I posted a technical text
asking other people to confirm or deny my observations. Can't you see the
difference between this and sending this material to newspapers and
causing alarming headlines "Your money under fire!"?... I belive I did
everything I can to prevent hype.

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

Nah. I documented my work, giving data samples, visualisation tool, and
some observations (like binary pattern analysis). Yes, I'd like to start a
discussion, to make people think on their own. Sorry, if you feel it's
bad.

It's just like posting: "Hey, my Acme microvave oven is working strangely.
I've found it's overheating, you have temperature graph attached. I'm not
sure if it's failure of Acme products or if I'm simply missing something,
so please could you check it?" + disclaimers.

> Yet, your claims -- undocumented and certainly unproven --

Documented and not proven. Well, partially, because we realized that
ActivCard One responses are carrying two digits of "unpredictable"
information less than we thought (1) and that some binary sequences (like
"11110" in this case) are appearing much more often that they should (2),
there are quite long periods of strange results (like 10 even numbers in
one sequence - of course, it could be result of randomness, but that's not
the point; not every randomness can be used for cryptographic /
authorization purposes).

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

Because that's true.

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

That's bad as well - allows attacker to effectively deny your clients from
using your service. I believe we should be able to trust card, instead of
implementing such defense mechanisms, that has been proven as ineffective
years ago.

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

Gosh, I never said I'll be able to gain access to someone's account. I
just believe that numbers should be predictable with probability
equal to 1 / number of digits' combinations, and not more. If this
probability is thousands times smaller, it's bad. But I didn't even said
it is (I just noticed some things about data I've colected and asked
other people to analyse behaviour of their own tokens)!

> When you claim that ActivCard's tokencodes are not random, you
> strongly suggest that ActivCard's DES implementation is severely flawed.

Not really. I'm not suggesting anything. I believe it could be weak
representation of algorithm output -> decimal digits or so. Or even there
could be no bug, only some unfortunate conditions in my input data.

> 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 didn't claim it. I only claimed I've serious doubt about
unpredictability of data I've collected.

Simply, get this data. Strip two first digits (they're almost 100%
predictable), then:

- dump their binary image
- visualise these values on the Y axis

If you believe this gives good randomness, that can be used as completely
unpredictable passwords, I won't agree. It's weak. Some values / sequences
are much more possible than other. That's all!

I'm not saying it affects every AC card in the world. Test it. If not, the
case is closed. If yes, probably it's time for AC to re-design their
algorithm.

_______________________________________________________
Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=