Re: RSA SecurID authentication details

• Previous message: Ally: "Re: Deleted IE - now got a big problem"
• Next in thread: phn_at_icke-reklam.ipsec.nu: "Re: RSA SecurID authentication details"
• Reply: phn_at_icke-reklam.ipsec.nu: "Re: RSA SecurID authentication details"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 10 Aug 2004 19:34:16 -0700

Micha Wilkowski <michal.wilkowski@wolainfo.com.pl> queried the
newsgroup:

>does anyone have any documents concerning details of authentication
>with tokens? RSA Security publish only marketing whitepaper and I
>need technical details - algorithms, mathematical background, etc.
>If you have it,please send me.

Dzien' dobry Micha!

Sorry I didn't notice your post earlier.

If you are a current or potential RSA customer, John Elsbury
<john.elsbury@spamaway.clear.net.nz> gave you good advice when he
referred you to RSA itself for full details on the SecurID ciphers and
RSA's ACE client/server protocol.

The underlying math of the modern AES-based SecurID is largely
documented in the voluminous research associated with the US selection
of the Belgian cipher, Rijndael, as the US Advanced Encryption
Standard (AES), the successor to DES, and subsequent efforts to
standardize the AES modes. See: <http://csrc.nist.gov/>

All versions of the SecurID use RSA's patented technology to manage
potential drift among digital clocks and to synchronize "Current Time"
in both a SecurID token and in the remote authentication server, the
ACE/Server, that the SecurID (and the token-holder) is registered on.

RSA has, I believe, seven US overlapping patents associated with
various aspects of the SecurID design. See:
<http://www.uspto.gov/patft/>

The classic SecurID, for 15 years, used a proprietary algorithm to
hash a token-specific 64-bit true-random seed and Current Time to
produce the SecurID 6-8 digit (or alphanumeric) token-code.

The latest model SecurID -- introduced at the beginning of 2003 --
uses the AES block cipher, in standard ECB mode, to hash:

- a 128-bit token-specific true-random seed,
- a 64-bit standard ISO representation of Current Time
(yr/mo/day/hour/min/second),
- a 32-bit token-specific salt (the serial number of the token), and
- another 32 bits of padding, which can be adapted for new functions
or additional defensive layers in the future.

These inputs, conflated and hashed by the AES, now generate the series
of 6-8 digit (or alphanumeric) token-codes that are continuously
displayed on the SecurID's LCD as a "one-time password." In the
SecurID's trademark rhythm, these token-codes roll over every 60
seconds.

(The ACE/SecurID security paradigm, as you doubtless know, presumes
two-factor authentication: the token-holder is required to provide
both a SecurID token-code and a user-memorized PIN to the remote
ACE/Server to obtain access to protected resources.)

ECB mode in AES is executed on 128-bit blocks, of course, so it is
obvious that RSA had to pad the standard 64-bit expression of Current
Time with another 64 bits. (Using a token-specific 32-bit salt blocks
attempts to pre-calculate a library of possible token-codes for all
128-bit seeds. This, in turn, means that any brute-force attack on the
AES SecurIDs will have to target an individual token.)

SecurDs are sold with a sealed battery and a pre-programmed lifespan
of 2, 3, 4, or 5 years. The three-year SecurIDs remain the most
popular among corporate buyers, although average employee tenure in
the US seems to be somewhat less than that. RSA continues to support
both the classic 64-bit SecurIDs and the new AES-based 128-bit
SecurIDs, but over the past 20 months, millions of tokens in current
use at the 15,000 ACE/SecurID customer installations have been
gradually upgraded.

The 128-bit AES tokens are obviously more resistant to various attacks
than the old SecurIDs, but even those sites which continue to buy
64-bit SecurIDs -- usually because they haven't yet upgraded old
ACE/Servers -- have been getting a more secure token when they
routinely replace their depleted SecurIDs.

RSA has never changed the 64-bit SecurID hash, designed by RSA's John
Brainard in 1985, but for the past 20 months all 64-bit seeds embedded
in new SecurID tokens have been filtered to enhance their resistance
to statistical attacks that operate upon huge compilations of serial
SecurID token-codes.

When RSA began shipping its AES SecurIDs in early 2003, it also
changed its production process so that the seeds used in newly-minted
64-bit SecurIDs are now somewhat less than true-random. Before a
64-bit seed is installed in a new SecurID token, RSA now
pre-calculates the token-codes that this particular seed would
generate over the life-span of a token, and discards seeds which
generate hash-collisions that could be used in bulk statistical
attacks.

In 2002 and 2003, many RSA customers were briefed about this design
change in the old SecurIDs, and the statistical attack vector that led
RSA to implement it, but there was no public announcement from RSA
about the change.

This reticence on the part of RSA unfortunately led to some confusion
and angry accusations on the Net earlier this year.

Independent cryptographers have refined theoretical attacks on the
64-bit SecurID. These attacks are still improbable as real world
threats, since they typically require the surreptitiously collection
and extensive computer analysis of tens or hundreds of thousands of
SecurID token-codes, but the proposed attacks provided a valid basis
for concern. Some critics, unaware that RSA had a fix already in play,
demanded that RSA publicly acknowledge that exotic attacks against the
19 year-old Brainard hash were now computationally feasible. RSA
didn't respond, which further irritated the righteous. Meanwhile,
month by month, as depleted SecurID tokens were replaced, the
ACE/SecurID user base adapted to yet another exotic threat.

In fact, the statistical analysis of tens or hundreds of thousands of
SecurID token-codes is not, in all probability, the most dangerous
emerging threat. It is certainly not the only potential threat to
token-based authentication for which RSA has quietly developed and
implemented unannounced defenses. No surprise. Customers expect no
less from any responsible IT vendor.

There has never been a claim that any of these bulk statistical
attacks has actually been used to crack an old SecurID, but the matrix
of potential (and perhaps practical) threats against commercial
cryptosystems continues to evolve. This threat environment has changed
numerous times, often dramatically, over the 17 years that RSA's
SecurID has dominated the enterprise market for hand-held
authentication tokens. Intellectual property and assurance models for
commercial crypto turned topsy-turvy in the same span.

Mind you, SecurIDs were initially sold, back in 1987, with an NSA
endorsement and a contractual commitment from the vendor that the
SecurID cipher would be kept secret -- a customer requirement then
common, particularly in financial services. It was a different world.

As you probably know, RSA's RC2, RC4, and finally the SecurID hash --
all once-proprietary RSA ciphers, protected only by contract as RSA
trade secrets -- were each reverse-engineered and anonymously
published on the Internet. (For RC5 and RC6, RSA turned to patent
protection;-)

The 1985 Brainard hash used in the classic SecurID was the last to be
"outed." It was published on Bugtraq in December, 2000. (See "SecurID
Token Emulator" at: <http://www.securityfocus.com/archive/1/152525>.
You might also be interested in my comments at the time. See:
<http://www.securityfocus.com/archive/1/154899>.)

It's only recent critiques of the old SecurID that began to carry some
weight. To date, the most insightful deconstruction and analysis of
the Brainard hash have been in a 2003 paper by Biryukov, Lano, and
Preneel <https://www.cosic.esat.kuleuven.ac.be/pressReleases/ashf.pdf>
and another paper published earlier this year by Contini and Yin, two
former RSA cryptographers: <http://eprint.iacr.org/2003/205/>.

When they wrote their papers, neither team was aware that RSA had
already implemented a substantive defense against the class of
statistical attacks on 64-bit SecurID token-codes that they proposed.
Both teams urged the early adoption of the AES-based SecurID.

I hope this is helpful, Micha. I'm on vacation, escaping from real
work, so you maybe got more of a response than you bargained for. I
apologize to all for the burden on the bandwidth. I don't work for
RSA, but I have been a consultant to the company, off and on, for
nearly 20 years, and my bias is overt.

Suerte,
        _Vin

- - - - - - -
"Trust is only dangerous when you have to rely on it."
  * Vin McLellan * The Privacy Guild *
     vin@theworld.com Chelsea, MA. USA

• Previous message: Ally: "Re: Deleted IE - now got a big problem"
• Next in thread: phn_at_icke-reklam.ipsec.nu: "Re: RSA SecurID authentication details"
• Reply: phn_at_icke-reklam.ipsec.nu: "Re: RSA SecurID authentication details"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]