1) The token seeds are truly random, i.e. there is no way to compute them based on any information about the token, customer, etc.

2) The token seeds are injected into the tokens during production.

3) The token seeds need to be loaded into the customer’s Authentication Manager server so that it is able to process logins for those tokens.

4) The tokens need to be distributed to the customer through a third-party vendor, who must not have access to the token seeds.

It follows that the process must be such that the customer, upon receiving the physical tokens from a third-party vendor, then contacts RSA directly with the serial numbers of the tokens they purchased, and obtains the token seed records from their database.

At this point, RSA could theoretically delete the token seeds for the customer’s tokens (and apparently can be requested to do so), but most customers do not make that request. Instead, the token records are kept in RSA’s database in case the customer ever needs them again (e.g. to rebuild a crashed authentication server).

jgajek: I’ve read that they use AES, but hadn’t seen anything authoritative I could cite. For this analysis, though, the algorithm doesn’t matter — the risks depend on whether seeds were compromised.

Also, I still don’t see why RSA would need to keep a database of seeds. It’s been argued that they’re necessary in case a customer loses their copies, but that’s why they should have backups. You’ve mentioned scalability, but I’m not sure I follow that. Finally, some might say a list of issued seeds is needed to avoid duplicate tokens, but with a 128-bit space, the chances of that happening are so infitissemally small that I’m not sure it’s even worth protecting against.

Truth is, if I were an RSA customer, using SecurID to protect high-value systems, I wouldn’t want anyone other than my own people having access to any seed values. Ever.

Anonymous (1): The algorithm isn’t public, and I don’t know it firsthand, so I felt it wrong to be too specific in how I described it. I’ve seen speculation that it’s time-based, and since “time is an arrow,” the end result will still be a pre-determined sequence of numbers. Further, I don’t know if it’s based on clock time, or simply the time since the token was powered on.

I didn’t explain my (theoretical) attack in detail, so here’s a quick description:

1. Observe two consecutive tokencodes, possibly by performing a man-in-the-middle attack, or directing the target to a fake login page. This also gets the attacker the PIN, which they’d need later.

2. Presume some list of seed values has been compromised. This could be a list of actual issued seeds, or a way to generate them which significantly reduces the valid seed attack space.

3. For each seed on that list (or reduced seed space), iterate the algorithm forward until you see the two tokencodes recorded in step 1. Set a limit for how far you’ll go forward — a token which changes every 30 seconds would display just over 5.25 million codes in 5 years, so that’s probably a good place to stop.

4. If you didn’t find the code, go to the next seed, and do it again.

I’ve personally had tokens “re-synchronized” by providing two consecutive codes to customer support, so that kind of drove my understanding of the system. (Or at least that’s how I recall it — it’s been a while). When activating a new token, a similar step would be performed, essentially, establishing a known good offset between the arbitrary “token time” and real clock time.

However, if tokens use absolute clock time, then it actually makes the attack easier. In this case, the attackers only need to observe a single tokencode, note the time, and simply try all known seed values against that time value.

Finally, thanks to Anonymous (3) for the link to Bellovin’s analysis. He pretty clearly explained a lot of what I’ve been thinking, or trying to describe here, but did it in nice, clean, mathematical terms. Unfortunately, he also doesn’t know any more than the rest of us about how the actual algorithm works, nor what data RSA may store on their systems. In the end, though, I believe bitexploder was correct — Bellovin’s analysis is saying the same thing we are, just in different terms, for different audiences.

Again, thanks for your comments…keep ‘em coming!

Regarding professor Bellovin’s analysis, I feel we were addressing the same concerns for different audiences. We were aiming for a higher level risk analysis this time vs. digging into the technical details.

Thanks,

@bitexploder