Bugtraq mailing list archives
Re: swc / ActivCard
From: Michal Zalewski <lcamtuf () DIONE IDS PL>
Date: Wed, 23 Aug 2000 11:17:09 +0200
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. <=-----=
Current thread:
- swc / ActivCard Michal Zalewski (Aug 18)
- Re: swc / ActivCard Alan DeKok (Aug 18)
- Re: swc / ActivCard John Fulmer (Aug 21)
- Re: swc / ActivCard Alan DeKok (Aug 21)
- Re: swc / ActivCard Michal Zalewski (Aug 21)
- Re: swc / ActivCard Vin McLellan (Aug 23)
- Re: swc / ActivCard Michal Zalewski (Aug 23)
- Re: swc / ActivCard Alan DeKok (Aug 25)
- Re: swc / ActivCard Michal Zalewski (Aug 25)
- Re: swc / ActivCard Michal Zalewski (Aug 25)
- Re: swc / ActivCard Alan DeKok (Aug 18)
- Re: swc / ActivCard Steve VanDevender (Aug 25)
- <Possible follow-ups>
- Re: swc / ActivCard Vasilios Katos (Aug 18)