RSA SecurID authentication details
Michał Wilkowski
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.
--
Regards
Michal Wilkowski
Konsultant
WOLA Info S.A.
ul. Wynalazek 4
02-677 Warszawa
tel. (+48) 22 6070536 wew. 305
tel. kom. (+48) 600995603
John Elsbury
<michal.w...@wolainfo.com.pl> wrote:
>Hello,
>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.
>
>--
>Regards
>Michal Wilkowski
>Konsultant
I believe the SecurID algorithm is proprietary, your best bet is to
ask RSA Security directly. If you want to develop software which will
interoperate with it, they might license the information to you
subject to an NDA. If you are developing your own token, the
principle of the SecurID is well understood, and almost any algorithm
would do.
Please remove "nospam" from mailto address
when replying
Vin McLellan
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.e...@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 *
v...@theworld.com Chelsea, MA. USA
p...@icke-reklam.ipsec.nu
> Micha Wilkowski <michal.w...@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.
If you choose the "digipass" series sold by vasco you will get an open
product where support is included in tis-toolkit ( i know i made it
myself)
digipass has replacable batteries, is field-reprogrammable ( with
an external device) and is much cheaper.
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
kad...@chicagotribune.com
In article <cfe167$urj$1...@nyheter.ipsec.se>, Peter Håkanson wrote:
>
>Vin McLellan <v...@theworld.com> wrote:
>
>> Micha Wilkowski <michal.w...@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.
Unofficial SecurID information (include some info on reverse-engineering
attempts) is published at the unofficial SecurID users forum:
http://groups.yahoo.com/group/securid-users/
RSA has patents on several aspects of time-synchronous authentication,
there is a list of these patents with summaries in the members area at Yahoo.
>If you choose the "digipass" series sold by vasco you will get an open
>product where support is included in tis-toolkit ( i know i made it
>myself)
Question: Is this using the old X9.9 mode of the Digipass?
(If not, ignore the rest of this message)
The ANSI X9.9 authentication standard has been shown to be
cryptographically weak, and easily compromised, and was officially
retracted by the X9 Standards Committee in 1999.
The X9.9 standard (with 56-bit DES) is the algorithm behind the Secure Net Key
(Digital Pathways SNK-004), Axent challenge-response tokens (now PassGo?),
CRYPTOCard, ActivCard, the Gauntlet firewall, and TIS Firewall ToolKit (FWTK).
Most commercial products have since changed their primary authentication
mechanism away from X9.9, but still provide backwards-compatible (and thus
vulnerable) X9.9 modes in their hardware and software tokens.
If the open standard used by the Digipass also uses DES and 56-bit keys,
it is likely to have similar vulnerabilities. One published paper suggests
that the shared secret key may be deduced from observing as few as two
challenge-response transactions!
These issues are not unique to X9.9, many hash-based shared secret
authentication schemes suffer from similar issues. Approaches to mitigation
of these risks vary. Options include substition of a stronger algorithm
(e.g. S/Key moved from MD4 to MD5 and eventually may move to SHA-1), use of
a larger seed key space (SecurID moved from 64-bits to 128 bits in
the new AES tokens), moving from challenge-response to event-synchronous,
and ensuring that the one-time passwords do not leak information about the
secret key (adding additional hash input data).
I've been tempted to develop a SNK-like authentication solution using AES,
but lack the time (and the hardware to deploy on a platform offering more
hardware security than PalmOS).
Kevin Kadow
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQEVAwUBQRwPEGsJt/Fo0vf5AQG05Af/Q08yhnK7Ti66ZblJR1beu9dfYgkQIRZn
WodbHFt32B04g3hbPJXUsGiSqhJbY+234+VdNk425yjdybJbGRb0kLSBjeN0gMI7
ce0ABAK3bQSARBDaPQChTdaTXWMq72gY9euMW0jb8419L/LeUI1f+ubEFzFeyXJD
0r+dv7tvimCqnHnfs7xiVnCnO7Lyn/fc8AfvpXniSQvHOW9t0Ft9H5k2aCv6tHF2
6Ww4mBiBgrq4qHRZgrxaCfE4ttFRJzLcrjTpalN4LivTsCa/BvGzRwOeQmdpx8l5
f9GZCnl+ga+ELiAteN6nO0EjCCLM3hTreSfQaqZcYXtCfuWN6viLDQ==
=kXV3
-----END PGP SIGNATURE-----