Re: AES securID Token

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Bongiorno LuMimmo!

You are confusing the contemporary 128-bit AES SecurID with the 64-bit
classic SecurID, which for 15 years relied upon a NSA-approved
RSA-proprietary Brainard hash to generate the SecurID "token-code."

RSA upgraded the SecurID four years ago to use AES and a 128-bit
token-specific secret in a new DPA-resistant design. These days, even
existing RSA customers need individual approval to "special order" the
old 64-bit SecurIDs.

I suspect, LuMimmo, you are being unduly optimistic to expect that your
application can tie in to the SecurID infrastructure without going
through the process of becoming an RSA partner. Your RSA Authentication
Manager (aka "ACE/Server") will only accept, register, or support
SecurID seed files which have been digitally signed by corporate RSA.

Quoted text here. Click to load it

You are not going to find the level of detail you seek. Like most
commercial crypto vendors, RSA does not disclose the implementation
details involved in their cryptographic products, unless under an NDA.
RSA has stipulated that the 128-bit AES token uses the AES block
cipher, in standard ECB mode, to pseudo-hash:

- a 128-bit token-specific true-random seed,
- a 64-bit standard ISO representation of Current Time
- 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 encrypted 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. (ECB mode in AES is executed on 128-bit blocks, as you
probably know, so RSA had to pad the standard 64-bit expression of
Current Time with another 64 bits. Including a token-specific 32-bit
salt in the mix will block attempts to pre-calculate a library of all
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.)

LuMimmo queried the Newsgroup:

Quoted text here. Click to load it

In, Juergen Nieveler responded:

Quoted text here. Click to load it

RSA's RC2, RC4, and 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 reverse
engineered from ACE/Server code and published on Bugtraq in December,
2000. See "SecurID Token Emulator" at:
< .

(I've been a consultant to RSA since Cain slew Abel, so you might also
be interested in my comments when the Brainard hash was published. See:
< .)

Almost immediately, there were hundreds, perhaps thousands, of young
programmers who used the published design to code SecurID emulators,
some of which are still available on the Web. It made a nice class
project. Cain & Abel < , a password
recovery utility for MS operating systems and protocols, is one of
several compilations of utilities for "penetration testers" which, for
a couple of years, included one of these SecurID emulators -- although
to what end, I could never figure out.  It's a cute toy, but it can't
emulate an existing SecurID without the token's secret seed.

Although theoretical attacks on the old 64-bit SecurID infrastructure
have been refined considerably over the past 20 years, no one has yet
claimed that they have managed to crack the old Brainard hash.

All of which, of course, is pretty much irrelevant in the 21st Century.

The AES-based SecurID set a new and much higher standard for security
and process integrity for hand-held token-based two-factor
authentication -- which is why, I suggest, it continues to dominate its
boisterous market, despite a slew of new and old competitors, many
well-funded and ambitious.

Good luck with your project, LuMimmo, but I suggest you plan it as a
stand-alone app. You might want to check out RSA Lab's One-Time
Password Specifications (OTPS), a series of guidelines, templates, and
proposed standards to aid developers who seek to safely integrate any
OTP-based authentication process into a variety of applications and
networked products.  See: <


Site Timeline