First post in a series (hopefully) related to general computer security.
When I first started my current many years ago I was issued of these keyfob thingies which displayed a 6 digit number that changed every minute. I just blindly accepted that it did some complex random number generation that allowed me to log in to systems securely.
Here's how it works (paraphrased from this).
The token is a completely standalone unit. It does not have any sort of connection to any other electronic device.
Each token contains a clock chip and a unique seed number, which I assume is displayed on the back of the token.
Every minute, the combination of the current time and the unique seed number as input of the algorithm and produces the six digit number you see on the token (I have no information on the algorithm itself).
The server performing the authentication (known as an ACE Server) knows your unique seed number, the algorithm being used, and the time. With this information, it performs the same function on the server. It receives your code and compares it to the code it computes. If the codes match you are authenticated.
Edit:
I found a more detailed breakdown after the original post is here:
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.