RSA Token (Two-Factor Authentication Technology)

SecurID, now known as RSA SecurID, is a mechanism developed by Security Dynamics (later RSA Security and now RSA, (The Security Division of EMC) for performing Two-Factor Authentication for a user to a network resource.

The RSA SecurID authentication mechanism consists of a "token" — either hardware (e.g. a

RSA SecureID's

USB dongle) or software (a soft token) — which is assigned to a computer user and which generates an authentication code at fixed intervals (usually 60 seconds) using a built-in clock and the card's factory-encoded random key (known as the "seed"). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased. On-Demand tokens are also available, which provide a tokencode via email or SMS delivery, eliminating the need to provision a token to the user.

The RSA SecureID token is currently based upon a proprietary algorithm & provides  6 to 8 digit token code as output. This output is said to be a "new, unpredictable code" displayed at 30 or 60 second intervals. The algorithm being used as of this writing was originally designed for & used on a cutom 4 bit microcontroller with an operating speed of less than 1 megahertz. Given these operational & computational capabilities, the use of a 64 bit time value & a 64 bit secret component in a destructive algorithm were responsible choices to protect authentication over non-promiscuous channles.

If the tokencodes are presented over a medium that can be monitored by an attacker or are viewed on a temporarily borrowed token device, the SecurID implementation is left vulnerable if an attack exists to determine the secret component by viewing previously generated or successive tokencodes. Additionally, with the advent of soft-tokens existing on popular operating systems and not dependent on specific hardware, the level of effort needed to retrieve the proprietary algorithm and secret component has been greatly reduced. If the algorithm is reversible or the initial components to the algorithm are deducible, the risk of cloned cards or prediction of future tokencodes is very real. The protective measures become simple: ensure the integrity and handling of hardware and software token devices, authenticate through encrypted communications, and, as recommended in, ensure that the backend communications with the application server to the ACE authentication server are not implemented over public links. With the above stated, the rest of this document will examine areas of concern within the algorithm.

Algorithm Concerns

The tokencodes generated by the algorithm are derived from two internal values :

High–level process of tokencode generation.

a 64-bit time value and a 64-bit secret. The result of the algorithm is then run through a final convert routine which further obfuscates the true algorithm output and produces a value suitable for display on a hardwareor software-based token. The value output by the convert routine is 64-bits in length and is split into multiple tokencodes depending on the token device and display interval.

Time

The variable input into the SecurID algorithm representing the current time is a 64-bit value. However, examination shows that this 64-bit value is generated from a 32-bit representation of the current time (GMT) in seconds since midnight on 01/01/86.

INT64 time64;

INT32 time;

UCHAR byte;

time = gettimeofday(); // Seconds since 01/01/86, 00:00

// Round down time

time = time / 30;

time = time / 4;

time = time * 4;

// Expand time into 64-bits, duplicate least significant byte

byte = time | 0xFF;

time = time << 8;

time = time | byte;

time64 = time;

time64 = time64 << 32;

time64 = time64 | time;

Pseudo–code for the 64–bit time computation routine.

Collisions in Tokencode Cycle

Analyzing tokencode cycles for a small sample of pseudo-randomly generated 64-bit secrets yields interesting results. Out of the 8,388,608 possible tokencodes (2 tokencodes produced for each value of time), ¼8 million of those tokencodes are unique and occur only once per cycle. The remaining ¼300,000 are repeating or “colliding” values.
Collision Percentage = (1 - unique tokens  ) x 100
                                       total possible tokens
Hence, 4% of the tokencode cycle consists of repeating values. We believe this is partly due to the convert routine.

Conclusions

The concerns mentioned in this brief hope to motivate further public assessment of the current SecurID algorithm. Do they negate the usefulness of an infrastructure utilizing this technology? No. However, it does point to the possibility that companies might be assuming more risk than they need to. Hopefully, the detailed concerns provide an opportunity for companies to evaluate how they have deployed this product.

By encrypting the communications, limiting access to back-end communications, and ensuring the integrity and whereabouts of the token generator, the risks of promiscuous viewing of the user authentication and tokencodes and potential retrieval of the secret component are minimized greatly. SSH, DESTelnet, SSL, and other encryption mechanisms can be deployed to help minimize these risks. IPSec, separate back-end management networks, and other means can be implemented to protect the back-end authentication that occurs between the application server and the ACE/Server.

Users are encouraged to vigilantly protect their hardware token cards or software token key files and not to loan their devices to other people. In addition, extra caution must be taken when utilizing software-based tokens to verify that the host system is not easily compromised.

We are planning for the release of a more thorough analysis of RSA’s SecurID algorithm in the near future, which will further detail the statistical irregularities described in this paper. We plan to explore methods of determining the secret component by viewing previously generated tokencodes. Additionally, we will examine exhaustive attack scenarios and solutions based upon hypothesized deployment scenarios.

Resulting Attacks

In April 2011, unconfirmed rumors cited L-3 Communications as having been attacked as a result of the RSA compromise.

In May 2011, this information was used to attack Lockheed Martin systems. However Lockheed Martin claims that due to "aggressive actions" by the company's information security team, "No customer, program or employee personal data" was compromised by this "significant and tenacious attack". The Department of Homeland Security and the US Defense Department have offered help to determine the scope of the attack.

RSA consist of 2 factors which are password and Personal Identification Number (PIN) that are used to protect network resources that are stored within a USB token called the Authenticator. Since the RSA SecurID system computes what number the token is supposed to be showing at that moment in time, checks it against what the user entered, and makes the decision to allow or deny access. A unique passcode combination that consists of the authenticator token and the user's PIN that will eventually be provided by a security engine that are used by the Authentication Manager Software in order to ultimately achieve authentication verification requests. RSA Secure ID is utilized by various attempts that are made by the user through user name/ID and pass code credentials are intercepted by the RSA Authentication Agent.