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