WARD.NU
Return to WWW.WARD.NU
This is a local copy of http://groups.google.nl/groups?hl=nl&lr=&selm=1f85b7d9.0408101834.1e0efb6c%40posting.google.com, the most elaborate description of the security and history of the RSA SecurID readily available by one of the consultants of RSA SecurID.
From: vin@theworld.com (Vin McLellan) Newsgroups: comp.security.misc Subject: Re: RSA SecurID authentication details Date: 10 Aug 2004 19:34:16 -0700 Organization: http://groups.google.com Lines: 172 Message-ID: <1f85b7d9.0408101834.1e0efb6c@posting.google.com> References: <cd8c8q$on7$1@nemesis.news.tpi.pl> NNTP-Posting-Host: 206.15.136.9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1092191657 28441 127.0.0.1 (11 Aug 2004 02:34:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 11 Aug 2004 02:34:17 +0000 (UTC) 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