Victor E. Luz <[EMAIL PROTECTED]> queried the Coderpunks Listocracy:
>I'm searching for a paper on cryptanalysis of Security Dynamics
>SecurID or ACE Server that was posted to the list a while ago.
>I've searched the archive, but I haven't found that mail.
>Can someone help me?
Bom día, Victor:
To the best of my knowledge, there is no published paper which
offers a cryptanalysis of the 14 year-old John Brainard hash used in the
SecurID token. SDTI still handles Brainard's SecurID hash as proprietary
and secret -- a fact which seems to greatly offend some people, and to
please others no end.
(The SecurID hash puts "current time" and a unique token-specific
random "seed" number through a one-way function to generate the series of
6-8 digit "token-codes," or "one-time passwords," which a SecurID
continuously and automatically displays in a small LCD on the face of the
token. SecurID token-codes change every 60 seconds.)
Brainard, now with RSA Labs, an SDTI subsidiary, is a one-time
student of Ron Rivest. In 1985, JB was hired to be the security architect
and cryptographer for the ACE/SecurID system. Rivest himself, under
contract to SDTI, wrote the so-called L2 hash which was incorporated into
the ACE client/server protocol introduced in 1991. (The L2 hash is also
SDTI proprietary.)
SDTI has always insisted that the secrecy which has somewhat
protected the SecurID hash is not -- and has never been -- critical or
necessary to ensure the security or integrity of ACE/SecurID user
authentication.
Any competent technical evaluation of the ACE/SecurID system must
presume that an attacker has full knowledge of the hash algorithm and its
workings. That's Kerckhoff's Assumption: the base-line premise for
evaluating any cryptosystem.
The only real and necessary secret in a SecurID -- or any of the
SecurID token-emulation applications -- is the token-specific secret seed.
As SDTI engineer Peter Trei <[EMAIL PROTECTED]> put it in a recent
discussion of the SecurID emulation code for the PalmPilot:
>>The app is not security-sensitive - only the
>>seed file is.....
The SecurID is obviously an artifact of an earlier era in commercial
crypto -- a cryptographic product from before there was much private-sector
crypto expertise, let alone a community with the will, desire, or curiousity
to offer ad hoc cryptanalysis of an algorithm, new or old. (SDTI's new Keon
PKI system, by contrast, is built around SSL, other standardized crypto,
and a published protocol.)
Many of SDTI's early customers demanded and received a commitment
that the algorithm would remain a SDTI trade secret.
Even now -- with RSA, among the most productive sources of modern
commercial crypto, an SDTI subsidiary; and ACE/SecurID system being
absorbed into SDTI's new Keon architecture -- the SecurID's hash remains
unpublished because of those promises.
As commercial infosec products go, the SecurID is a Grand Dame, but
scarcely virginal. SDTI customers and potential customers can review the
algorithm under NDA upon request, and the SecurID has been evaluated and
cryptanalyzed by many companies and governments over the past 14 years.
The best known attempt at analyzing the ACE client/server protocol
is probably, "Apparent Weaknesses in the Security Dynamics Client Server
Protocol," the 1996 paper by Adam Shostack, then the founder/moderator of
the SDAdmin mailing list, now Director of Technology at Netect
<http://www.netect.com> in Boston.
Actually, it was at that 1996 DIMACS conference on Network Security
that I heard the only public comment I've ever heard from a major SDTI
customer about a cryptographic evaluation of SecurID hash.
Steve Bellovin of AT&T Research, who led a team that evaluated
ACE/SecurID for AT&T, told Shostack and the DIMACS crowd that Adam and his
friends shouldn't waste too much time trying to dig Brainard's hash out of
the SecurID microchip.
Steve said it was his opinion -- and the opinion of AT&T
cryptographers who had studied the SecurID hash at his request -- that
Brainard's hash was "sufficiently lossy" -- i.e., designed to discard bits
at various stages within the hash's algorithmic calculation -- to make it
impossible to invert the hash and discover the token's secret seed from a
series of SecurID token-codes.
(I've always understood Bellovin's off the cuff remarks to be
implicitly qualified as cryptographers always qualify such comments in any
more formal evaluation. I think what he meant to say was that the SecurID
hash seems to surfice for the specific function it is being used for in this
particular application. What a professional cryptographer would say --
actually, what the AT&T cryptographers probably told Steve -- was that they
couldn't figure out how to crack it yet. Period. Extent of endorsement.)
Mr. Shostack had used my SecurID FAQ and his own creative efforts at
reverse engineering of the ACE client/server protocol to suggest a potential
spoof attack on the client server interaction in circa 1994 (v. 1.2) ACE
authentication servers.
The flaw was real, but it had been spotted nearly two years earlier
by SDTI Engineering VP Jim Kotanchik and quietly fixed with a modification
of the client/server interaction in ACE/Server v. 1.3 -- a "mandatory" (and
I think free) 1994 upgrade of the ACE authentication server.
Mr. Shostack has a copy of his paper online at:
<http://www.homeport.org/~adam/dimacs.html>
Adam also has a copy of John Brainard's pre-publication comment on
his draft paper posted at the same website:
<http://www.homeport.org/~adam/brainard.html>
An earlier and more hyperkenetic attempt to analyze the ACE
protocol for weaknesses was the NIS/Network Associates white paper,
"Weaknesses in SecurID," by PeiterZ and a handful of other hopeful giant
killers with abbreviated handles. See:
<http://web1.nai.com/products/security/advisory/papers/index.asp>
I've always been a bit mystified at the fact that my response to the
PeiterZ paper is among the most widely distributed articles I've ever posted
online. It seems to have been translated into more languages than the NIS
white paper itself was. You can pick it up (in English) at:
<http://www.njh.com/latest/9609/960910-03.html>
Jim Kotanchik of SDTI also wrote a response to the PeiterZ "white
paper." The SDTI webmistress tried to take it down a couple of times
because she felt it, and the PeiterZ attack, were both dated -- but it
keeps being put back on the web by popular demand. Read another articulate
engineer at:
<http://www.securitydynamics.com/products/whitepapers/2897.html>
I've been a consultant to SDTI for many years, so I'm reasonable
well informed, if not particularly objective. My old 1995 SecurID FAQ is a
little dated, but you might find it useful. See:
<http://www.oga.co.th/syncom/securid/Resources/FAQs/sdfaq.html>
Feel free to follow up with questions, publicly or privately. I'm
going to copy this over to the Firewalls and Cryptography mailing lists
where you will find well-informed communities with expertise in handling
these issues, and many with experience administering ACE/SecurID security
systems. They will know if I've overlooked anything important.
Surete,
_Vin
--------
"Cryptography is like literacy in the Dark Ages. Infinitely potent,
for good and ill... yet basically an intellectual construct, an idea,
which by its nature will resist efforts to restrict it to bureaucrats
and others who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
