This was posted on Firewall Wizards, in the archive, by Vin McLellan (vin_at_theworld.com).
Glad to help. All versions of the SecurID use RSA's patented
technology to synchronize the use of Current Time in a SecurID token and its remote authentication server, what RSA calls the ACE/Server. (Typically, as you know, the link between the token-holder and the ACE/Server is through an intermediary -- an ACE/Agent or RADIUS agent -- which intercepts an authentication call and relays it to the ACE/Server for processing.)The classic SecurID, for 15 years, used a proprietary algorithm to hash a token-specific 64-bit seed and Current Time. The new 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.Conflated and hashed by the AES, these inputs generate the series of 6-8 digit (or alphanumeric) token-codes that are continuous displayed on the SecurID's LCD, rolling over every 60 seconds. (The standard mode of use, as you know, requires 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.)
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 salt blocks any attempt to pre-calculate a library of possible token-codes for all 128-bit seeds. That means that any brute-force attack on the AES SecurIDs would have be focused on a particular token.