Re: F2 hash?

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