. Jüri Kaljundi <jk@stallion.ee> noted that "Mudge," a fabled hacker long associated with the elite clique "Cult of the Dead Cow," (honest!) had been scheduled to speak on SecurID vulnerabilities at DefCon in Vegas two weeks ago.
| At Defcon this year they promised to tell about some security | flaws in SecurID tokens, anyone know more about that?
Adam Shostack <adam@homeport.org> primed the pump:
My understanding is that the guy who was going to give the talk had nda difficulties. Vin? Did you make it out? The talk was going to be on race conditions, denial of service attacks, and the like.
Yup. SDTI asked me and their Principal Engineer, John Brainard, to wallow in the delights of Vegas and attend Mudge's scheduled speech at the DefCon hackers' convention. Not knowing that half of the people over 30 attending DefCon would be FBI agents (not undercover; wearing FBI/DefCon IV-embazoned polo shirts, and passing out _lots_ of G-man recruiting literature! No kidding!) the Powers That Be at SDTI selected John and I, from the girded ranks of their employees and sundry consultants, as either the least likely to squander our personal fortunes at craps, or the most likely to fit in among the (little)bit-perverted odd-balls who gather at DefCons. I refuse to speculate as to which (but I think I've finally got the knack of card-counting at blackjack;-) As Cerridwyn Llewyellyn <ceridwyn@wolfenet.com> reported, Mudge -- posed and celebrated on page 40-something of last month's WiRed -- told the DefCon audience that SDTI's lawyers were after him, threatening something dire, so he was not going to release his "white paper" on weaknesses in the ACE/SecurID system for several months. Instead, he delivered a talk on s/key vulnerabilities. This was weird, because I *knew* Security Dynamics had neither consulted nor asked their lawyers to do anything about Mudge's speech on SecurID vulnerabilities. It would have been a fool's ploy: silly and counterproductive. John and I took Mudge out for dinner right after that speech. He told us then that he had inadvertently misspoken when he blamed his temporary silence on SDTI's lawyers. The real problem, he said, was with bullying lawyers from two corporate clients he is now under contract to in his day job. (He didn't explain this further, but I understood that Mudge is working for two firms which have access to SDTI plans and trade secrets under non-disclosure agreements. The firms were apparently worried about their liability -- given their promises to SDTI and Mudge's work in their employ. Mudge may want to elaborate on this. Or not.) Mudge is a very sharp guy; a hacker in the old sense of a system maven -- despite his beer-swillin' Dead Cow Cult role-playing. Off stage, he spoke freely about which attack vectors he's been working on, but offered limited detail. (My impression was that when the conflict-of-interest stuff came up, Mudge put aside his analysis of SecurID authentication for awhile... but intends to work on it further, once free of other obligations.) He and SDTI's John Brainard got along well, nattering to each other in machine code (which another DefCon luminary who joined us, *Hobbit*, would ocassionally translate for me.) Mudge is deeply involved in analyzing the ACE client/server code for weakness; he too is also very interested in the F2 algorithm -- which he felt involves too much knowable information as input to the hash -- and, of course (like Shimomura, the self-styled Threat of the West,) Mudge is stolidly pounding away at the SecurID itself to retrieve and cryptoanalyze the algorithm that hashes Current Time and the token's secret key to generate a SecurID token-code. John Brainard -- who wrote the SecurID hash ten years ago -- openly admired Mudge's ingenuity but didn't seem to feel particularly threatened. Mudge and John also talked about various potential high-level protocol attacks on the network infrastructure and how they could possibly be used to isolate a Master ACE/Server from a (backup) Slave -- with an attacker able to both sniff incoming traffic to the Master and replay it to the Slave (after the Slave had been artificially trapped on an isolated subnet by the attacker.) The discussion was out of my league, but I enjoyed watching the vollying back and forth. The whole exchange was fun and reminded me of the healthy relationship hackers in the user community used to have with product designers. My beard is gray. I remember when the lead programmers for the best time-sharing companies used to send a bottle of good booze to anyone who alerted them to security problems in their systems. A good tradition, IMNSHO -- and one which I tried to continue when I picked up the check for our dinner and Mudge's choice of wine. (I'll bill SDTI;-) All the recent effort to bust the decade-old SecurID algorithm and the ACE network protocol seem a little anachronistic, of course. I suppose it's kind of a grand salute to an old security warhorse (and SecurIDs are still the first line of defense in most Fortune 500 companies.) There has been no formal announcement, but -- as Jüri suggested -- I think most of the ACE/SecurID user community expects that both the network protocol and the token's internal algorithm will be upgraded sometime in the very near future. (On a timeline SDTI established several years ago.) And any new ACE protocol will inevitably establish a stateful session for the authentication exchange -- which will make the current generation of race attacks historical novelties. SDTI Engineering (and most likely RSA Labs) have probably been banging away at the new design for a long time. RSA was deeply involved with SDTI long before their recent merger; RSA helped develop the F2 hash that is used in the ACE client/server security protocol. (It's this F2 hash that "Anonymous" is begging some Cypherpunk to steal, reverse-engineer, and publish for everyone to play with. Bad, bad, commercial crypto! Wouldn't want anyone to make money off strong cryptography, would we??) It remains to be seen where the merger of the top OTP firm and the top commercial crypto firm leads us -- but I, among many, hope the widely-installed ACE/Server (with its potent RDBS) will provide the key-management infrastructure that will allow the introduction of enterprise-wide crypto on a scale seen only in the nightmares of the NSA's congressional lobbyists. Mr. Gilmore is not the only one who has been plotting to vastly expand the installed base of strong crypto in the coming year. Suerte, _Vin Vin McLellan +The Privacy Guild+ <vin@shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>
Vin McLellan wrote: | John and I took Mudge out for dinner right after that speech. He | told us then that he had inadvertently misspoken when he blamed his | temporary silence on SDTI's lawyers. The real problem, he said, was with | bullying lawyers from two corporate clients he is now under contract to in | his day job. | Mudge is deeply involved in analyzing the ACE client/server code | for weakness; he too is also very interested in the F2 algorithm -- which | he felt involves too much knowable information as input to the hash -- and, | of course (like Shimomura, the self-styled Threat of the West,) Mudge is | stolidly pounding away at the SecurID itself to retrieve and cryptoanalyze | the algorithm that hashes Current Time and the token's secret key to | generate a SecurID token-code. | All the recent effort to bust the decade-old SecurID algorithm and | the ACE network protocol seem a little anachronistic, of course. I suppose | it's kind of a grand salute to an old security warhorse (and SecurIDs are | still the first line of defense in most Fortune 500 companies.) There has | been no formal announcement, but -- as J=FCri suggested -- I think most of | the ACE/SecurID user community expects that both the network protocol and | the token's internal algorithm will be upgraded sometime in the very near | future. (On a timeline SDTI established several years ago.) And any new | ACE protocol will inevitably establish a stateful session for the | authentication exchange -- which will make the current generation of race | attacks historical novelties. I'm not sure I buy this claim. The problem of syncronising multiple geographically seperate servers is tough. Its actually easier with challenge-response tokens, since you can simply have servers issue different challenges when they lose contact. (Mudge has a clever similar hack for the current version of securids.) | SDTI Engineering (and most likely RSA Labs) have probably been | banging away at the new design for a long time. RSA was deeply involved | with SDTI long before their recent merger; RSA helped develop the F2 hash | that is used in the ACE client/server security protocol. (It's this F2 | hash that "Anonymous" is begging some Cypherpunk to steal, | reverse-engineer, and publish for everyone to play with. Bad, bad, | commercial crypto! Wouldn't want anyone to make money off strong | cryptography, would we??) No, I (possibly unlike anonymous) want lots of people to make shitloads of money of strong crypto. I intend to do so. But strong crypto is published crypto, not trade secrets. SDTI should be in the business of selling the best code and most sturdy cards to work with their protocols, which should be publically open to review. I can't confirm my attacks without knowing F2*, and without knowing if the attacks work, I'm reluctant to publish. So, I think I'll publish based on what SDTI has published, which may or may not be correct. (I have told Mark Warner and Chris McNeil (?) of SDTI about the attacks, and will discuss their responses. *I'm not the one who asked for F2 to be published. I have told many people about my attacks, and its concievable that someone else found the same things. -- "It is seldom that liberty of any kind is lost all at once." -Hume
On Fri, 9 Aug 1996, Vin McLellan wrote:
As Cerridwyn Llewyellyn <ceridwyn@wolfenet.com> reported, Mudge -- posed and celebrated on page 40-something of last month's WiRed -- told the DefCon audience that SDTI's lawyers were after him, threatening something dire, so he was not going to release his "white paper" on weaknesses in the ACE/SecurID system for several months. Instead, he delivered a talk on s/key vulnerabilities.
This was weird, because I *knew* Security Dynamics had neither consulted nor asked their lawyers to do anything about Mudge's speech on SecurID vulnerabilities. It would have been a fool's ploy: silly and counterproductive.
John and I took Mudge out for dinner right after that speech. He told us then that he had inadvertently misspoken when he blamed his temporary silence on SDTI's lawyers. The real problem, he said, was with bullying lawyers from two corporate clients he is now under contract to in his day job.
(He didn't explain this further, but I understood that Mudge is working for two firms which have access to SDTI plans and trade secrets under non-disclosure agreements. The firms were apparently worried about their liability -- given their promises to SDTI and Mudge's work in their employ. Mudge may want to elaborate on this. Or not.)
Hrmmm. Let me set the record straight here. Lest people think I would violate nda agreements upon end of contracts. sigh. First, I am not under any NDA agreement with STDTI. All of my research and work on the SecurID token cards was done independently from any of the companies I am currently contracting for (I noticed that there were several problems with the system and that's enough to set me off on something). Second, while I did refrain from going into specifics on SecurID vulnerabilities at the talk - I did give one on some of the problems with OTP's in general. S/Key happened to be a good example to use in illustration as a large portion of the audience there was familiar with it. Many of the vulnerabilities mentioned there hold true to SecurID. Third, and most important, the reason I refrained from giving the SecurID talk was that the two companies I am doing some security related contract work for both employ this technology in varying degrees. I have explained the problems that I have found to these companies and they are quite concerned. I believe it would be un-ethical to give out instructions on how to break through SecurID, thus leaving networks vulnerable that I am being paid to help secure before the problem has been addressed locally (I like being able to put food on the table). The information will be made public in the near future. SDTI has been made aware of these problems (some of which were presented to them almost a year ago). I don't dislike SecurID. I am quite happy to have made Vin and John's acquaintance as they are both wonderfull people. I do feel that there are problems with SecurID that exist largely due to the card being sold into an environment that it was not designed for (a little thing called the internet). I just wanted to set the record straight as I realised that the inital statements that Vin made could be mis-interpreted and potentially impact my image to future employers (though I know that this was not his intention). cheers, .mudge PS I do not currently read / keep up with the cypherpunks list. So I probably will only see the bits of this thread that are forwarded to me.
participants (3)
-
Adam Shostack -
vin＠shore.net -
What we're dealing with here is a blatant disrespect of the law!