Understanding the security framework behind RSA SecurID
Source: Mohit Arora

Figure 1: RSA SecurID Device
RSA SecurID is trusted two-factor Authentication protocol often used to authenticate VPN clients enabling users to login to secure servers. Every physical RSA Secure ID device has a unique serial number written on the back of the device.

During manufacturing individual SecurID devices are assigned a random 128-bit secret key with the manufacture maintaining a database that map the device’s externally visible serial number to its internal 128-bit secret key.

For every 60 seconds, the processor in the SecurID device takes in a 64-bit current time and 128-bit seed record that generates a very large number (via algorithm) that is finally hashed down to produce 6 or 8-digit output.

The algorithm typically used during this step is based on the AES-128 Symmetric cryptography standard. Though confusing, it is important to note that this has no resemblance to RSA public key cryptography that is based on Asymmetric keys or Public-Private key pair. Nonetheless, from the 8-bit output, it is impossible to reverse engineer to generate the 128-bit seed record.

As shown in    Figure 2, below, token code generated is supplied to the website or VPN Client that pass the token to the authentication server run by RSA. Once the user enters the username, RSA takes in the user-name and searches their database to find what seed record is associated with the token and runs the same hashing algorithm thereby taking in current time and seed record to generate the 8 digit output that must match the 8 digit output entered by the user along with the username. Once matched, user is allowed access to the remote server.

Figure 2: Secure ecosystem and dataflow around RSA SeureID (To view larger image, click here)

If numbers don’t match, server will take the current time and add a minute and generate another 8 digit number. Server will also remove a minute from the current time and come up with another 8 digit number.

If either of these numbers match, server will treat it as right token assuming clock to have slightly drifted. Clock can often drift due to different environment conditions between the user and the server side. If token is running one minute fast, server will store the settings for the user and when user log-ins at some point in the future, it takes the current time and adds a minute to calculate the 8 digit token output.

In case the token does not match three different passcodes (current time , +1 minute, -1minute), the server then tries the same but with a bigger timing window (current time, +10 minutes, - 10 minutes) . If one of the passcode matches, the server will send a challenge to the user asking the user for the next 8 digit number(next Token code) that appear on the SecurID device

If it is correct, the server will allow the user to login else the process will be repeated all over again. This ensures if attacker happens to guess the passcode once, unless he/she knows the very next number right in the minute, server won’t authenticate the connection. 8-digit passcode would mean 108 combinations that would be impossible to guess in a minute.