Re: F2 hash?

[vin@shore.net (Vin McLellan)]

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