Tommy Ward <tommy_at_securify.com> wrote:
>As far as (RSA's SecurID] algorithm, it is patented, and it is implemented
>in several software products, including the ACE/Server and the software
>version of the token. That means it is not really very secret....
As others have noted, the 14 year-old SecurID hash is an RSA trade
secret. It remains unpublished today largely due to commitments RSA (then
Security Dynamics) made to early customers, when such commitments were
demanded by many customers, particularly in banking and financial services.
The 1991 ACE protocol -- which secures communication between the
ACE/Agent and the ACE/Server (the RSA authentication server) -- is also
proprietary. It relies upon DES and an unpublished Ron Rivest hash ("F2").
Two year ago, RSA published the mechanics of a new RSApkc-based
protocol which will displace the current ACE protocol. RSA has also
promised that its upgrade for the SecurID's internal chip -- repeatedly
delayed, but widely expected to become available next year -- will use
published crypto.
The secrecy of the SecurID hash is very much a product of an
earlier era -- although there are major RSA customers that would still like
to see the next version of the SecurID also built around an unpublished
algorithm.
Needless to say, all of the various government and corporate teams
which have evaluated or certified the security of the SecurID, and the
ACE/SecurID system, have always presumed that any attacker would have full
knowledge of the SecurID hash and the full ACE protocol. That's Kerchoff's
Principal, basic to any cryptographic evaluation. (As others have noted,
RSA customers or serious potential customers have always had access to all
this information under an NDA.)
Last I heard, there are some 12,000 ACE/SecurID installations
world-wide, with some 5 million SecurIDs in current use. In the US,
SecurIDs are today widely used in government agencies known to periodically
review the status of their security technology. All White House staffers
carry SecurIDs; as do all US Senators; as do many employees of the NSA,
CIA, and US DoD. (The current director of the CIA has been known to toy
with his SecurID key fob during interviews, much to the delight of RSA's
observant salesfolk;-) In several nations outside the US, numerous
crypto-savvy corporations and government agencies also use the SecurID for
two-factor user authentication.
Mr. Ward, a vice president at Securify, suggested:
>What makes me wonder more about the "secret technology" involved in this
>case is the deduced limitation on the crypto used. If you think about the
>hardware based SecurID card having up to a 4 year battery life, and the most
>basic version displays a new OTP every 60 seconds whether you need it or
>not, there can't be a very large number of clock cycles involved in computing
>the OTP. By comparison, we used to see about a 2 year battery life on
>the old SNK token, which used an 8-bit processor to perform a single DES
>computation to generate its OTP, and only did so when you need a new
>OTP to authenticate with.
Ummmm. As Ben Nagy <ben.nagy_at_marconi.com.au> pointed out, battery
draw is not a meaningful measure of the security of a cryptosystem in use.
(I'm unclear how Mr. Ward, the guy who used to head up Securify's
prestigious infosec consulting practice, could come up with such a weird
criteria for estimating the strength of any cryptosystem -- but then, I've
probably tossed a couple hum-dingers, off the cuff, myself;-)
The SecurID uses a 4-bit processor whose power consumption, on
average, is less than one percent of that required by the 8-bit SNK processor.
(That, of course, is *not* to say that Mr. Ward's old SNK token
is/was 99 percent less secure than a SecurID;-)
The relative difference in battery-drain, however, does make the
SecurID a much more challenging target for a hands-on Differential Power
Analysis (DPA) attack than most other hand-held authentication tokens.
(The target of any DPA attack would, of course, be the SecurID's
token-specific 64-bit secret seed. That seed is the only critical secret in
a SecurID. While unpublished and protected by RSA's license, as Mr. Ward
noted, the SecurID hash is embedded in thousands of widely-distributed
pieces of RSA software. I've always assumed that if someone wanted it bad
enough, obtaining it would not be any big deal. RSA has always insisted
that the publication of the SecurID hash would not in any way diminish the
security of installed ACE/SecurID systems.)
Unfortunately, DPA -- in the hands of an attacker with
unrestricted access to the token; with time, specialized knowledge, and
instruments of sufficient sensitivity -- is a serious threat to all
token-held cryptographic keys. The DPA threat to smartcards has received
far more attention, of course, and for good reason. A SecurID token-holder
already has full access to whatever resources his SecurID can make
available. Smartcards, by contrast, are often used in protocols where the
smartcard is a mechanism to restrict the user's access to something (e.g.,
bank funds).
(The fact that a smartcard, or many smartcards, draws its
electrical power through a reader device can also make a DPA-bugged reader
a major threat to a whole community of smartcard users. A SecurID, or any
hand-held authentication token, is battery powered, and -- with no circuit
connection to the network -- tokens offer, at least in contrast to
smartcards, a certain elegant simplicity. Hand-held authentication tokens
do no more than what they appear to do... which is not an easy claim to
make about a networked smartcard.)
Any company or institution which issues SecurIDs to its staff must
necessarily depend upon those employees to both safeguard the physical
token and, if the token is stolen or lost, to immediately report the loss
to the responsible authorities. Using a SecurID or any two-factor token for
user authentication greatly enhances an organization's access control
scheme -- something Microsoft may have noticed recently;-) -- but it surely
doesn't obviate the need for user education, nor for a viable Security Policy.
Securify's Mr. Ward also suggested:
>I would guess that a brute force analysis should be able to compromise
>any given SecurID account in a short period of time. If you had only a
>few samples of plain text (the time of day) and cypher
>text (the OTP), this should be a computationally easy task.
Unhuh. <sigh>
SecurID 101: To generate a SecurID token-code, an expression of
Current Time and a 64-bit secret seed are concatonated and pushed through
the SecurID one-way function (a hash designed by John Brainard of RSA Labs)
to produce a 6 or 8-digit token-code which continuously rolls over every 60
seconds.
The input ("plaintext") that is hashed into a SecurID token-code
is a little more challenging, and a little less obvious, than the mere
"time of day." (To address a somewhat more common misconception, let me be
clear: The "secret seed" embedded in a particular SecurID is *not* the
serial number engraved on the back of the token. Honest. No matter what Mr.
Ward sez!) As Mr. Nagy noted, Distributed.Net's search for an 64-bit RC5
key (in one of the RSA Crypto Challenge contests) gives a healthy sense of
scale for the solution space that must be searched for a 64-bit secret.
Mr. Ward also noted:
> If you can pry it out of him, Mudge did enough work on this in about
> 1995 to prepare a paper on the subject, but he got "persuaded" not to
> release it.
For awhile, I think I carried a certain cachet as the guy who was
said to have bullied Dr. Mudge (now VP for R&D at @stake) into not giving a
speech on ACE/SecurID which he had promised to deliver at Defcon '95. Alas,
I was caught in the updraft of one of Mudge's Cult of the Dead Cow
smoke-'n-mirror displays. Anyone who knows anything about Mudge, or me,
would have found the tale unlikely, but Mudge, an irrepressible showman,
launched one of those self-perpetuating myths when he told the Defcon
audience that pressure from SDTI's lawyers had convinced him not to speak.
IANAL, but I caught the blow-back and the "credit."
Afterwards, in an exchange on Cypherpunks, Mudge corrected
himself. See my post on this subject:
<http://www.inet-one.com/cypherpunks/dir.96.08.08-96.08.14/msg00227.html>,
and Dr. Mudge's reply:
<http://www.inet-one.com/cypherpunks/dir.96.08.08-96.08.14/msg00316.html>
Mudge's concerns about ACE/SecurID in mid-90s were largely focused
on the dangers and risks associated with migrating this one-time password
technology, which had initially been developed for a non-networked EDP
environment, into the realm of the Internet and extranet connections to
protected resources. Mudge and others correctly noted that moving a
technology appropriate for a dial-in POTS environment into an IP network
environment -- particularly an Internet-connected network environment --
demanded a reexamination of both the predicable threat level and the
appropriate security required for the transport medium.
[Even in 1995-1996, the overwhelming majority of ACE/SecurID
installations (maybe 95 percent) were used to provide two-factor ("strong")
user authentication to enhance access controls over modem-based data links,
where remote users were making direct dial-up connections over telephone
lines.]
Then, the emerging threat of TCP splicing or "session hijacking"
-- among other "active" attacks, where an attacker manipulates packets to
spoof and exploit weaknesses within network protocols -- highlighted new
vulnerabilities that could only be addressed with link or network
encryption. [In a typical session hijack, an attacker fires an signal at
the valid user to kill his connection, then the attacker masquerades as
that legitimate user and takes over the good guy's (already authenticated)
session... with full access and all the privileges of the valid user.]
Historically, of course, the two-factor ACE/SecurID system -- with
the token's one-time password and the user-memorized PIN -- was initially
designed to block sniffing, password theft, and the replay attacks that
were (and are) so easy to exploit with reusable or static passwords.
Critics of one-time password tokens understood that, compared to
the Internet, racks of terminal servers on POTS modem lines was a pretty
sheltered environment. Tapping a telephone line is not, technically,
particularly challenging, but most IT managers seemed to believe -- through
the mid-90s, and to a degree, even now -- that telephone wiretapping (as a
slam-dunk felony, and one which requires a physical attack on a POTS switch
or telephone line to boot) demands a more focused and targeted attack than
the opportunistic scan that was their typical pre-Internet hacker threat.
The blithe hackers who began hitting on the firm's Internet
connection with far more methodical attacks soon convinced everyone that
the New World Order in the late 1990s was gonna be a much more demanding
InfoSec environment.
In the mid-1990s, hacking (in the modern sense of the term) was just coming
into its own with the Internet explosion.
There was, inevitably, an awkward period in which IT and network
managers had to come to terms with their new threat environment and the
necessity of reinforcing user authentication -- or any other trusted
transaction environment -- with network or link (VPN) crypto, to guarantee
both the integrity and the security of data traffic on the Net.
(At about the same time, firewalls, wholly creatures of the
network, went through a similar reappraisal of popular assumptions about
the integrity of the network protocols. Some, mostly masochistic
professionals, said this is an evolutionary process that should never end;-)
John Adams <jna_at_retina.net> and Ben Nagy also discussed the 1996
DIMACs paper by my friend Adam Shostack -- "Apparent Weaknesses in Security
Dynamics' Client/Server Protocol" -- and John Brainard's pre-publication
response to it. [Mr. Shostack's paper is at
<http://www.homeport.org/~adam/dimacs.html>. Mr. Brainard's reply is at:
<http://www.homeport.org/~adam/brainard.html>]
As Mr. Nagy noted, quoting an message I wrote on the GNAC
Firewalls List last year, a Security Dynamics engineer had discovered a
flaw in SDTI's ACE protocol in an internal security review and fixed it --
in 1994 -- in a free ACE/Server upgrade, which was flagged as addressing
unspecified security problems. Mr. Shostack, a talented security analyst
who had founded a mailing list to discuss ACE/SecurID issues, reverse
engineered a copy of the pre-patch ACE binaries to reveal a problem (which
was, indeed, the problem addressed in the ACE/Server 1.3 upgrade) and
explain its significance.
Mr. Nagy added:
> ...[T]hat was NOT a bug in the hash algorithm. As I read it, it was
> a bit of lazy protocol analysis that would allow a malicious user who had a
> large amount of control over the channel between the ACE client and server
> to spoof authorization messages to invalid login attempts. And even then it
> required access to the shared DES key.
>
> That doesn't frighten me a great deal. If an attacker has that much control
> over the trusted LAN they don't need to break in via dialup."
I think that is accurate.
Mr. Nagy also noted that Brainard's 1996 note made a confusing
reference to Shostack's paper, and suggested -- correctly, I think -- that
the two of them were talking about different things, using similar language.
[One of the base-line rules by which the ACE/Server protects
itself from replay attacks is to refuse to honor the same SecurID
token-code if it is submitted twice from the same
token-holder. Statistically, this probably happens, albeit rarely -- but
it is not a big problem. I think Adam's paper referred to the possibility
that the ACE protocol might, as a function of the protocol, block any
identical 8-bit token-codes from the same SecurID token-holder. (It
doesn't; the ACE/Server simply rejects repeat token-codes from the same token.)
[Brainard, in his comments on Shostack's paper, discussed the ACE
protocol's use of Rivest's F2 hash as a mechanism to secure the interaction
between the ACE/Client and an ACE/Server. JB was making the point that, in
this special context, the ACE protocol need only rely upon the one-way
functionality of the hash -- unlike,for instance, a digital signature
scheme which requires that a hash be both irreversible (i.e., one-way)
*and* collision free.]
In the ACE protocol, the F2 hash is used in a special-purpose
function in which the potential for collisions -- two different Time/Seed
inputs which hash down into the same 6-8 digit SecurID output -- is just
not particularly revealing.
Collisions in the SecurID hash, by contrast, could potentially be
somewhat more revealing. If an attacker could observe a number of such
collisions, he might be able to learn a few bits of the token's seed.
However, given the statistical randomness of the token's output,
and the relatively small number of outputs available to an attacker (even
recording all token-codes displayed on the SecurID over weeks or months),
Brainard said he considers this an unlikely and impractical attack.
Steve Bellovin <smb_at_research.att.com>, who led the AT&T team that
evaluated ACE/SecurID several years ago, noted:
.> First of all, I don't think the algorithm is patented. Rather, it's a
.> trade secret. The crypto is home-grown because they didn't have the
.> cycles to do DES. And you're not going to brute-force the algorithm.
.> Apart from the key being too long, it doesn't show all of the output.
.>
.> Yes, I've seen the algorithm, under NDA.
Ben Nagy mulled this and thoughtfully replied:
>Check me on this, Steve - just because the token doesn't show all the has
>output does not mean that you can't brute force it in O(2^secret bits)
>(which I believe is 64) at worst. You just have to check your guess with a
>different timestamp or two every time you think you've got the correct seed.
I think you are correct. Despite the fact that the hash is lossy
and the SecurID token-code (6-8 digit) display does not reveal all of the
hash's output -- with the Brainard hash in hand, and with a successful
brute force attack on the 64-bit solution space, an attacker who was able
to discover at least three CurrentTime/token-code pairs would have a
reasonably sure that he had calculated the correct 64-bit seed for that
particular SecurID. In practice, according to Brainard, uncertainty about
the token's internal time probably adds another factor of three or so to a
brute force attack.
(This statistical gem has led to another simple-minded rumor, that
a technique exists which can calculate the seed for a particular SecurID
with three accurate CurrentTime/token-code pairs. <sigh>)
As with any security technology, the design goal of a SecurID
token was not to make an attack upon it impossible, just impractical (and
more difficult and more costly than alternative attack options.) The next
generation of SecurIDs will push the bar still higher, since it will be
built around a 128-bit SecurID seed.
Suerte,
_Vin
Obligatory caution: I have an overt bias on this topic. No one by
RSA speaks for RSA, but I've been a consultant to RSA Security, and
Security Dynamics (SDTI) before that, for many years. Please appropriately
discount my comments about ACE/SecurID. I also apologize for the length of
this post, and for not getting into this exchange earlier.
Mr. Adams referred readers to one of my 1999 posts for the URLs of
papers which criticize RSA's ACE/SecurID system, and various responses to
them. Adam Shostack's Homeport links (cited above) are as solid as
Gibraltar, but others seem broken. Here are Google's latest suggestions of
updated URLs for those documents.
The SNI PieterZ "white paper" on ACE/SecurID is at:
<http://www.nai.com/products/security/advisory/papers/securid.ps>
SDTI's response to PieterZ is at:
<http://www.oga.co.th/syncom/securid/Resources/WhitePapers/2897.html>
My comments on the PieterZ paper:
<http://lists.gnac.net/firewalls/mhonarc/firewalls.199609/msg00288.html>
------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_nfr.com
http://www.nfr.com/mailman/listinfo/firewall-wizards
Received on Dec 09 2000
Intro
