Re: SecurID Token Emulator

[Vin McLellan <vin () SHORE NET>]

        In e-mail from Russia,  I.C. Wiener <icwiener () MAILRU COM> recently
posted to Bugtraq source code for an algorithm which he claimed to be the
hash used in RSA's SecurID hand-held authentication token, and in RSA's
various token-emulation SecurID software apps for PCs and Palm Pilots.

>Sample SecurID Token Emulator with Token Secret Import
(See: <http://www.securityfocus.com/archive/1/152525>)

        Mysterious gifts from the East are, of course, a Biblical
Christmas tradition -- more so in the Orthodox cultures (and centered on
this day, the Feast of the Three Kings!) than in the West. ("Pozdrevlyayu s
prazdnikom Rozhdestva s Novim Godom," Mr. Wiener!)  In the lore of
Chanukah, Judah and the Maccabees were also no strangers to the brutal
realpolitik of contested property rights, intellectual or otherwise.

        Tovarishch Wiener wrapped his gift in colorful taunts to the Borg
at RSA; tacked on an utterly unsupported claim that the SecurID hash is
"easily breakable" or reversible (which might put the data assets of some
five million current SecurID token-holders at risk)... and added a playful
suggestion that RSA should turn to Russian programmers (or, at least,
hackers who know how to use Russian email relays) for more efficient code.

        Yikes, the joy of Geeks bearing gifts;-)

        Bugtraq's publication of the alleged SecurID hash tossed a little
mud in the eye of RSA, the most prominent crypto vendor. It again
highlighted the fact that actors on the global Internet can easily escape
local accountability.  Yet, withal, it seemed like a relatively harmless
(and widely expected) revelation of the old algorithm used in the SecurID
-- itself an old (time-tested and widely-trusted;-) security gadget that
has dominated its market niche for a decade and a half.

        None of the more than 12,000 ACE/SecurID installations was placed
at risk.

        The SecurID hash -- designed in 1985 by John Brainard, still at
RSA Labs -- has been used, unchanged, to generate PRN token-codes (aka,
"one-time passwords") in all of the more than 8 million SecurID hand-held
authentication devices that RSA  have been sold over the past 14 years.

        (RSA Security, once known as Security Dynamics, bought RSA Data
Security in 1996 and subsequently renamed itself. RSA is today the dominant
vendor in two major InfoSec markets with its BSAFE cryptographic toolkits,
and SecurID authentication tokens. With its Keon Servers, RSA now bids to
be the contender in yet a third: PKI software.)

        On Bugtraq, SecurID-savvy engineers quickly posted comments which
affirmed that Wiener's code was indeed functionally identical to the
fabled, but never previously published, SecurID hash.

        Fed proper data -- a 64-bit secret "seed" (usually shared by only
a SecurID and the ACE/Server it authenticates to) and Current Time --
Wiener's code will apparently produce the same series of time-synchronized
pseudo-random token-codes that a real SecurID (configured with the same
seed and proper Time) would produce.

        This was independently confirmed in two Security Alerts mailed out
last week by the US-based System Administration, Networking, and Security
(SANS) Institute.

        Russian hackers have built up a certain reputation since Vladimir
Levin's Citibank scam netted $10M in '95, but it should be clear that
reverse engineering RSA's widely-distributed binaries to snag the SecurID
hash is -- on the scale of Morriarty the master criminal -- more of a
sophomoric prank.

        Reverse engineering compiled code is tedious, but when the target
is a single isolated function, it doesn't (beg pardon, I.C.) take a
humongous amount of talent.

        To judge by the code he posted, Mr. Wiener seems to have gone
about retrieving the hash the hard way: reverse-engineering a portion of
the compiled code from the multi-megabyte RSA authentication server, what
RSA calls the ACE/Server.  (Last summer, "2600," the Hackers' Quarterly,
offered to send a hot copy of the ACE/Server binaries to anyone who was
willing to analyze the code for weaknesses.)

        Over the past dozen or so years, I presume there were a hundred
curious programmers among the employees at RSA's 12,000 ACE customer
installations who did the same thing. (They just didn't publish it.)

        In recent years -- with over half a million SecurID-emulating
software apps for PCs and Palm PDAs in circulation -- others have
reportedly found much easier ways to isolate and study the SecurID
hash.  (They didn't publish it either;-)

        Even in the early years -- when Brainard's hash could be found
only in the epoxy-sealed SecurID hardware tokens and an ACE access-control
module for mainframes and minicomputers --  I know of crypto collectors
(and competitors;-) who picked the hash out of the ACE binaries.

        "Code similar to this has been quietly available for quite some
time," noted Adam Shostack <adam () homeport org> on Bugtraq.  Shostack -- who
in 1996 wrote a notable critique of an early (v.1.2) version of the ACE
client/server protocol, and founded SDAdmin, a mailing list which focused
on RSA's ACE authentication issues -- said he had been anonymously sent a
copy of the SecurID hash in '96... with an explicit request that he not
publish it.

        In 1996, for the first time, RSA had expanded its product line
beyond hardware SecurID tokens to offer token-emulation software clients
(then called "soft tokens," in the confusing idiom of the industry) for
PCs.  RSA -- which for years had preached a Gospel of a personal, physical,
hand-held authenticator; paired with a PIN for "strong" two-factor
authentication -- entered that market reluctantly, two years after SafeWord
and DigiPass, and only at the insistent request of several large customers.

        Selling the ACE infrastructure (with PC client software to emulate
the hardware SecurID), RSA hoped to bring stronger-than-password
authentication to a huge new population of prospective customers which
could not find the budget for hardware tokens.  RSA recognized, however,
that it could move into this new market only by accepting some significant
new risk exposures.

        RSA's product planners were preoccupied with the array of new
vulnerabilities their authentication service would confront in PCs with no
protected memory -- but they were also very aware that putting tens of
thousands of copies of the SecurID hash in circulation in PC software  was
going to make the Brainard hash vastly more accessible to any programmer
who could get a copy of the "SoftID" client.

        As I explained in the SecurID FAQ I wrote for RSA in '96:

.> No token-emulation software can ultimately resist being copied or
.> counterfeited. While the secret key or seed can be protected
.> cryptographically, when a program is executed in a PC it is in the
.> clear and "readable" to other internal processes within the computer
.> which hosts it. Various technical defenses can make this more
.> difficult, but with sufficient time, skill, and special knowledge any
.> program can be copied.

        In early 1999, the barriers were lowered yet again.  In April,
'99, RSA began distributing free SecurID (token-emulation) application code
for the Palm OS PDAs from its website.

        Inevitably, due to constraints inherent in the Palm development
platform, that 40K SecurID code module -- which obviously included the
Brainard hash -- was less copy resistant, and  generally more accessible,
to a much larger community of users, crypto hobbyists, PDA enthusiasts. To
any Palm hacker with the skill, curiosity, and patience to pick apart the
X86 binaries.

        RSA's successively broader distribution schemes inevitably placed
the SecurID hash in ever greater risk of revelation. The exposure grew from
binary code of the multi-megabyte ACE/Server in the hands of professionals;
to "SoftIDs" for PCs  distributed to thousands of corporate employees; to
the tiny SecurID app for Palm Platforms, freely available for anyone to
download from the RSA website (and designed so that the application itself
-- in demo mode; but crypto, GUI, and all! -- could be "beamed" from Palm
to Palm via IR).

        I don't think RSA was ever blind to this dynamic. As I saw it from
the sidelines, RSA simply ranked its priorities. The company labelled
customer security and new sales as its primary concerns, then tried to
manage the risks associated with its expanded marketing initiatives as
conservatively as it could.

        It was considered practical and reasonable to trade off,
successively, the more robust layers of  technical protection around the
Brainard algorithm for greater market penetration. The exposure of the
SecurID hash was simply never seen as a security risk, or something that
could undermine or weaken the ACE/SecurID scheme.

        There was a historic corporate promise not to publish, and there
was a routine effort to safeguard company-confidential information -- but
since exposure of the hash was expected to have no meaningful impact on ACE
security, there was no bunker mentality. No paranoia.

        A month ago, on the Firewall Wizards' mailing list,  Michael H.
Warfield <mhw () wittsend com> expressed surprised when he learned that the
SecurID hash was still  "unpublished."

> Was my
> understanding, from the same source that I got my SecureID app for
> my palm pilot, that the same process that had led to that
> application being available on the Palm Pilot had resulted in the
> algorithm being known.

        Cryptographer David Wagner <daw () mozart cs berkeley edu> replied:

| I believe the algorithm has been known to some subset of "hackers" for
| some time. However, I don't know of too many "good guys" who have had
| a chance to look at it (which presumably means that RSA is not able to
| benefit from analysis from the open cryptographic community).
|
| This suggests that keeping the algorithm secret may not have served its
| intended purpose. But then, secret design rarely does, when you are
| talking about long-term widely-deployed commercial systems...

        For some, the problem with the historic secrecy of the SecurID
hash has always been the question of Epistemology: the proper way to
discover and validate truth, sufficiency, trust, and integrity in
cryptography.

        Modern commercial cryptography today depends upon academic
cryptanalysis to validate the integrity and probable "strength" of a
cryptosystem.  Open publication and review are integral to this process.

        For at least four years, RSA has been committed to open
publication of the crypto to be used in a new version of the SecurID for
the new millennium, a token with a 128-bit secret, and the planned upgrade
of the ACE client/server protocol.  In public presentations on the future
of ACE/SecurID at the 1996 DIMACS Workshop on Network Threats, and the 1997
RSA Conference,  RSA Labs' principal engineer John Brainard committed the
future of ACE to open review.

        "The new protocol will be based on published algorithms and
standards, and will, as you recommend, be made available for peer review,"
wrote Brainard in '96 to Shostack, founder of the SDAdmin mailing list.
See: <http://www.homeport.org/~adam/brainard.html>

        The SecurID first came to market in an earlier era, when the
credibility of a cryptosystem was established not by "open review" but --
particularly in the financial industries and among US DoD contractors -- by
government evaluations and formal certification systems.

        The SecurID hand-held authenticator was certified and first placed
on the NSA/NIST "Evaluated Products" list -- approved for US government use
and recommended as cryptographically sound to industry -- on March 31,
1987. Since then, it has undergone periodic reviews; the SecurID is still
widely used within sensitive US installations.

        The SecurID hash has been an unpublished RSA trade secret for all
these years *not* because RSA felt the need to protect it from critical
review and cryptanalysis, but because -- when RSA (then Security Dynamics)
first brought the SecurID to market in 1987, the first customers for
ACE/SecurID were banks and other financial institutions which insisted that
the hash be kept secret.

        RSA -- giving its customers what they wanted -- made a commitment
that it would not publish the algorithm.

        There was, of course, virtually no independent academic crypto
community to offer "open review" or free cryptanalysis until well into the
1990s.  What there was did not have much credibility with corporate
purchasing agents.

        (Citing a government imprimatur is also an effective way to
sidestep responsibility or liability concerns about any potential flaw in
crypto -- an exotic tech few can effectively evaluate -- while exercising
proper due diligence.  The traditional system -- and its echoes in the
standardization process -- has its obvious benefits, hence the acclaim for
DES and the AES.)

        (The NSA, which controlled the most important certification
systems in the US [as well as the crucial export-control regime], also
liked the fact that the hash was not published -- although, frankly, that
was probably generic NSA policy, rather than concern about this particular
cryptographic hash. It has been suggested, however, that the secrecy of the
SecurID hash was a factor in getting a "blanket" export approval for
"authentication only" crypto tech in the early 1990s. For multinationals
which wanted to use token-based authentication, that was a big win.)

        Ironically, over the past decade, RSA has itself been a leading
corporate activist in the campaign to displace -- or at least, in the US,
expand and complement -- the old government-dependent certification system
with a new convention of publication and "open review" of proposed
cryptosystems by academic, corporate, and independent cryptographers.

        (Professional cryptographers still get commissioned to do
intensive reviews -- some estimate that there are only a few of hundred
cryptographers capable of a full cryptanalytic analysis of any particular
cipher or hash -- but publication opens the system up, counters untoward
government bias, and invites young, unrecognized, but  capable
mathematicians and crypto technicians to take a shot.)

        In the early 1990s, when NSA officials crushed -- in the name of
US "national security" -- private-sector efforts to standardize strong and
effective crypto for key exchange and digital signatures in the American
National Standards Organization and the American Bankers' Association's
X9  committees, RSA led an independent multi-vendor effort to define and
specify the seminal Public Key Cryptography Standards (PKCS) -- inarguably
the most influential "private" standardization effort in modern
cryptography. (See: <http://www.rsasecurity.com/rsalabs/pkcs/>)

        Since 1991, RSA's Crypto Challenge contests have sought to
establish and define the work needed -- with the best "known" attacks -- to
factor (RSA) public key crypto, with various size keys; and to brute-force
crack symmetric cryptosystems of given key-lengths. These contests have, by
any account, added enormous credibility to the "open review" paradigm in
commercial cryptography and US public policy.

        Notably, the 1997 RSA Crypto Challenge which led to Ian Goldberg's
3.5 hour successful brute-force attack on 40-bit "export grade" crypto, and
RSA's DES Challenge-II contest in '99 -- which led to the 56-hour EFF crack
of the (56-bit) DES -- were momentous events, with profound political,
legal, cultural, and technical ramifications.

        It was probably left mostly to crypto cognoscenti to appreciate
how the publication of the SecurID hash limned the ironies and
incongruities which inevitably haunt Commercial Crypto 2K -- an industrial
technology only just emerging from government control, and the
spook-sponsored "certification culture" associated with it.  At least in
the West.

        Russians like Mr. Wiener still need a FAPSI/KGB license to encrypt.

        Mr. Wiener claimed a Scriptural motivation for his decision to
publish RSA's trade secret, the SecurID hash. Paraphrasing Kerchkoff's
Principle -- the baseline assumption in all formal evaluations of a
cipher's "strength" and trustworthiness for over a century -- Wiener quoted:

> Once again, security of the cipher should be based entirely on the
> secrecy of the key, not the algorithm.

        Kerchkoff's Principle codifies the practical reality that secrets
which are stable, persistent, and ubiquitous are so difficult to keep
confidential that sensible men prefer not to rely upon our ability to do so.

        "In modern cryptography, where complexity is cheap, we trade off
complexity against secrecy," explained William Hugh Murray of Deloitte &
Touche <whmurray () optonline net>.  "That is to say, we make the mechanism
sufficiently complex that the cheapest form of attack is an exhaustive
attack against the key and, therefore, knowledge of the algorithm does not
(further) reduce the cost of attack.

        "That is not to say if one could keep such a secret that security
would not be enhanced," added Murray, noting an ongoing debate over the use
of multiple layered ciphers, to make it more difficult for an adversary to
know which of multiple ciphers were used to create a ciphertext.

        "Until recently, the [US] government insisted upon using only
secret algorithms, regardless of their complexity," he pointed out.
"Kerchkoff's Principle notwithstanding, they realize that anything of which
the adversary is ignorant may raise his cost of attack."

        Now, suppose RSA's early ACE customers were able to gain (say from
a NSA review of the SecurID for the US "Evaluated Products" list;-)
assurance that the SecurID hash was sufficiently complex to deter anything
less than a brute force attack.  Does it seem unreasonable for the managers
of those ACE sites to conclude that they would gain some additional
security --call it insurance -- by requiring RSA to keep secret whatever
need not be disclosed?

        Anyone who knows anything about the culture of corporate security
-- physical security, "InfoSec," "CompSec," "ComSec" --  would not be
surprised. To a security professional, hiding whatever need not be
disclosed is second nature, an occupational habit. (Very few corporate
purchasers of security products -- firewalls, authentication tokens,
intrusion detection systems, etc. -- permit their vendors to publicly
announce a purchase or installation, for example.)  In the traditional and
heavily-regulated bank and finance industries,  the presumption of all
security is reinforced by secrecy  has multiple vectors.

        While the contemporary community of private-sector and academic
crypto professionals would likely echo Mr. Wagner  -- and many have pressed
for the publication of the SecurID hash over the years --  it is perhaps
telling that I have never heard of a corporate ACE/SecurID customer which
demanded (or even asked;-) that RSA publish the SecurID hash.

        The market, clearly, had other channels by which it gained and
built trust in the integrity and cryptographic credibility of this
particular product.

        The SecurID did not become, among corporate network managers, what
one SANS survey described as the most widely recommended mechanism
<http://www.sans.org/newlook/publications/powertools.htm> for enhancing the
security of new networks, solely by virtue of RSA's stellar
salesmanship;-)  Network security managers are all born in Missouri.

        Nevertheless, it does seem likely that the SecurID hash will now
get the sort of "open review" that many crypto scholars, cypherpunks, and
independent crypto activists have, for years, urged all corporate buyers to
demand of all vendors of commercial cryptography.

        I don't think the scrutiny, per se, will trouble RSA;-)

        It would be rash for anyone to assume that just because the
SecurID has historically been proprietary and unpublished, it has not been
the subject of extensive and deeply intensive study by a large number of
independent professional cryptographers. (Some of whom, doubtless, would
have loved to count coup by finding a flaw in a RSA cryptosystem.)

        Over the past 14 years, hundreds of the world's most capable
crypto and protocol analysts have had direct access (under NDA) to the
SecurID hash and the ACE source code -- for customer pre-purchase
evaluations, and in various government certification and evaluation
programs (in the US and several other countries.)

        Each of those evaluations used the Kerchkoff base-line. Analysts
always presume that all adversaries have full access to the SecurID hash
and the ACE protocol -- full access to everything except the 64-bit seed,
the SecurID's "shared secret."

        Brainard's SecurID hash is an "irreversible one-way
function"  which takes as input a true-random 64-bit token-specific "secret
seed," places it head-to-toe with a 24-bit representation of Current Time,
and processes the concatenated input to generate a continuous series of 6-8
digit SecurID token-codes.

        In the SecurID's trademark rhythm, each PRN token-code is
displayed in an LCD on the face of the token for 60 seconds, whereupon it
rolls over to display another.

        [RSA's authentication engine, the ACE/Server, can validate the
identity of any token-holder registered to it because (knowing the "shared
secret" and CurrentTime) it can calculate what token-code each SecurID is
displaying, at any given moment.  In practice, and fundamental to the
SecurID design, the ACE/Server *always* requires a "two-factor"
authentication: the SecurID token-code, and a user-memorized PIN or password.]

        RSA customers and serious potential customers have always been
able to arrange for their chosen crypto experts to study the source code
and the design of the SecurID hash under NDA.  RSA has, I believe, also
been willing to assist independent reviewers by providing access to
cryptanalytic studies of the strength of the SecurID hash which RSA itself
has commissioned from leading independent cryptographers in the US and
elsewhere.

        (MIT Prof. Ronald Rivest  -- the "R" in RSA; and author of MD2,
MD4, and MD5; as well as RC2, RC4, RC5, and RC6 --  has also studied the
Brainard hash. His conclusions about it have been known to have also
reassured some prospective RSA customers.)

        Adam Shostack, now  Director of Technology at ZKS, has for years
been an outspoken advocate of the publication of the SecurID hash for open
review.  (Ironically,  Mr. Shostack's employer when he started the SDAdmin
mailing list in mid-90s was a financial services firm which, by my
recollection, was among the companies which had earlier insisted that the
SecurID hash not be published.)

        Mr. Shostack responded to the Bugtraq publication of the Wiener
code with a jubilant check-list of cryptanalytic basics which implied, it
seemed to me, that the SecurID had come to dominate its marketplace without
serious cryptanalytic review by anyone:

> Now that its publicly available, some smart cryptanalyst can easily
> test the assertion that the numbers displayed on the face of the card
> do not reveal enough information to determine the card secret.
> (John Brainard made this assertion at the [1996] DIMACs Network
> Threats workshop, and Steve Bellovin [who led the ATT Research team
> which evaluated ACE/SecurID before ATT purchased and installed the
> system] said that he'd looked at the issue as well.)
>
> There are lots of sub-questions here: Do the digits displayed leak
> information about the cycle, how long are the cycles, are all cycles
> of equal length?

        I postulate that it is widely accepted -- at least among RSA's
ACE/SecurID customers -- that this particular unpublished algorithm has
already survived far more demanding reviews (by skilled corporate
cryptographers, as well as spooky government analysts) than many -- even,
almost all -- "open source" or published cryptosystems.

        That, of course, is no guarantee that it is perfect <sigh>, but
open source or published crypto doesn't come with any guarantees
either.  With crypto, especially, what counts is *who* does the evaluation
-- not how long the code has been sitting in some freeware repository.

        (It is also justifiable to caution that when a flaw is discovered
in modern commercial crypto, it is almost always a problem in the
implementation -- rather than a problem with the algorithm, per se.)

        SANS' two most popular Alert summaries -- SANS' monthly report on
Windows Security issues; and the Security Alert Consensus,  a weekly
summary of all security alerts for network security mavens (jointly
published by SANS and Network Computing Mag) -- both used the publication
of Mr. Wiener's SecurID token emulator, and the revelation of the SecurID
hash, to lead their year-end-2000 editions:
<http://archives.neohapsis.com/archives/sans/current/0123.html> and
<http://archives.neohapsis.com/archives/sans/current/0122.html>.

        The headline in the SANS Windows Security Digest (v.3.12) was a
bit hysterical -- "RSA SecurID Token is Crackable" -- but the text,
thankfully, pulled up well short of that conclusion: "As of this writing,
it appears that observation of the numbers on the token is not enough,
however, to determine the card secret."  Explained the SANS WinSec Editor:

/> I.C. Wiener released sample code showing how to generate SecurID
/> token responses without having the physical token. According to the
/> advisory, the algorithm is easily breakable if one has access to the ASC
/>  files used to initialize the tokens.

        This is a weird analysis. I'm not sure if the author understood
ACE technology; or even realized that RSA sells both SecurID hardware
tokens and software apps which emulate SecurID tokens.

        With SecurID physical tokens, the tokens are initialized and
sealed at the end of the manufacturing process, while still within RSA, and
not at the customer site.

        When SecurID tokens are shipped to a customer -- already clicking
along at a token-code a minute -- RSA also sends an  ASCII file of the
64-bit true-random SecurID "seeds," indexed by serial number, which
correspond  to the keys embedded in that batch of tokens. (The local ACE
Administrator loads the obfuscated seeds or ASCII "key file" into the
ACE/Server as the first step in assigning SecurID tokens to individual
employees.)

        Obviously, if you've got access and the key, any lock can be
opened. The guy with the key doesn't have to "break" anything.  It is
bizarre to say that someone who obtains both the SecurID hash and the
secret seeds (for some installation's set of SecurIDs) can "break" the
algorithm.

        The purpose of cryptanalyzing or attempting to "break" the PRN
output of this or any other "keyed hash" is to obtain the secret key or seed.

        With both the algorithm and key file in hand, of course, a bad guy
could presumably get the proper time configuration data and use one of the
64-bit SecurID seeds to generate an apparently valid series of token-codes
for a particular SecurID.

        (Unless he had totally corrupted an installation's ACE/Server and
had access to its secured files, however, the attacker still would not know
to whom a particular SecurID token had been assigned.  Nor would he know
which PIN that particular user had selected to reinforce his SecurID
token-code.)

        Needless to say,  the SecurID seed files are typically handled
like crown jewels -- at RSA; while they are in transit, under the care of a
bonded courier; and (hopefully) at the customer site.

/> [Bugtraq's publication of the SecurID hash] is interesting
/> because RSA has claimed that part of the security of SecurID is the
/> security of the algorithm it uses. Now that this algorithm has been
/> duplicated, the security of the token is based only on the token
/> initializer and the PIN used to access the system protected by the
/> token.

        Unfortunately, this SANS WinSec report is inaccurate and may have
confused many readers. In fact, RSA has *never* claimed that the security,
or the integrity, or the trustworthiness of its ACE/SecurID authentication
was in any way dependant upon the secrecy of the Brainard hash.

        To the contrary, RSA -- in a hundred interviews, FAQs, articles,
newsletters, white papers, and online posts by RSA executives and RSA
evangelists (including me;-) -- has explained that the secrecy of the
SecurID hash was simply a market requirement (something demanded by many of
RSA's major customers in the 1980s and early '90s). They bluntly declared,
repeatedly, that the secrecy of the SecurID hash is not, never was, never
could be, and never should be, in any way "essential" to the security
architecture of a SecurID, or to ACE Authentication.

        In the 1996 SecurID FAQ, I tried to stress this fact. Here's how I
described the logical attributes of a SecurID token-code:

.>   As the product of a cryptographically solid one-way function, the
.> integrity of the token-code (its ability to defy cryptanalysis and
.> efforts to identify the token's secret-key) does not depend upon the
.> secrecy of the cryptographic algorithm.
.>
.>   It is unpredictable. This means it is computationally infeasible to
.> predict the next token-code or future token-codes in the series
.> (even given a list of prior token-codes and the hash algorithm which
.> produced them all.) This is why the SecurID token-code is called a
.> pseudo-random number or "PRN." There is no apparent relationship
.> among the numbers, or within a series of SecurID token-codes.
.>
.>   It is the product of an cryptographic hash algorithm sufficiently
.> complex and destructive (e.g. discarding digits at various stages of
.> the calculation) so as to make it impossible to "reverse engineer"
.> the hash and determine the original input values from the PRN
.> results, even if one knows or is able to estimate one of the input
.> values (e.g., Current Time).

        Bemused industry commentators typically labelled the publication
of the SecurID hash "interesting," then sat back to await further
developments.

        There remains, always, the possibility that the SecurID hash might
crumble in the sunlight of open publication and the rigors of public
review.  Comp128, CMEA, ORYX, the Firewire cipher, the DVD cipher, and the
Netscape PRNG were all cracked within months of each being subject to
"unauthorized publication."

        OTOH, RSA is probably the brand-name corporate poster child among
US firms which have lost control of valuable intellectual property -- in
RSA's case, crypto -- through its publication by anonymous or pseudonymous
actors on the Net.

        Famously, in 1994, someone reverse-engineered RSA's BSAFE code to
post Rivest's RC4 cipher (then an RSA-proprietary trade secret) to the
Net.  Again, in 1996, someone reverse-engineered Rivest's RC2 (another
RSA-proprietary trade secret) to post the algorithm to sci.crypt.

        Of course, RC4, and to a lesser extent, RC2, remain mainstays of
secure communications on the Net, in SSL/TLS and S/MIME, among other secure
protocols. Their mid-90s publication was, it seemed clear at the time,
largely intended to enable non-US developers to offer strong-crypto
products which could interoperate with SSL cryptosuites -- without a
license from RSA, but also  (in what was probably more crucial to those who
celebrated the revelations) without obtaining a US government permit for
the export of strong cryptography.

        Arguably, the illicit publication of RC4 and the
subsequent  development of SSLeay in Australia snapped the US Government's
control over who could obtain or use strong cryptography on the commercial
web. Some might say those events dramatically changed the world, certainly
e-commerce at the <blush> dawn of the 21st Century.  No one is making any
such claims about the publication of John Brainard's 15 year-old SecurID
hash, Grand Old Dame of InfoSec that she is.

Suerte,
           _Vin

PS.     Needless to say, I am a biased observer of these events. I have
been a consultant to RSA, and SDTI before it, since before the SecurID
first came to market, and a paladin for tokens even earlier. I also
apologize to the Listocracy for the length of this holiday post.  Blessing
of the Magi on all!
------

"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 + <vin () shore net>

-------------------