Re: Token based OTP: SafeWord or SecurID?

[Vin McLellan <vin () shore net>]

        Tommy Ward <tommy () 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 () 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 () 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 () 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 () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards