HEscalona
March 18, 2011 at 5:42 pm
I believe that exist other scenario that is related to attacker get access to the backdoor that RSA put for government access inside the products and algorithms and all the complete system can be in danger.
I still thinking that: If RSA accept a success attack (a company that is alive for security) the real impact must be bigger than the actual acceptation.
jgajek
March 18, 2011 at 11:18 pm
The algorithm to generate the tokencodes is known to be AES-128. So most likely the breach has something to do with the token seeds. These would almost certainly have been stored in a database by RSA for scalability reasons during token distribution to customers.
Anonymous
March 19, 2011 at 10:11 am
This information is not correct for every type of token. In fact, most of these token do not produce a specific pre-determined sequence of numbers. What they do is that they perform an operation based on their seed an the current time which they keep using a small battery, and using these two inputs produce a 6 digit number. When the user inputs the number to the authentication server, the server performs the same operation based on his clock (and readjusts it to match the users, or discards the number if not within a 3 minute period for example).
Anonymous
March 19, 2011 at 10:15 am
And a sixth scenario (similar to the first): What they got may be an algorithm and a master seed used to derive the each token’s seed based on the serial number of the token.
Anonymous
March 19, 2011 at 10:25 am
A better analysis on the operation of SecureID from a world-renown security professor (Steven Bellovin) http://www.cs.columbia.edu/~smb/blog/2011-03/201
incognito
March 23, 2011 at 6:10 pm
I wouldn’t say it’s better, but it’s lower-level and a nice complement to this discussion. Thanks for the link.
bitexploder
March 19, 2011 at 11:44 am
To Anonymous regarding the numbers not being predetermined. For any given point in time the token code must be predictable. So, if you were to record a tokencode every second for a given seed it would be the same tokencode stream the server has. The server will know every token code in the future as well due to this. You can pick any specific point in time with a given seed and that token will not change as long as these algorithms are relying on a shared secret and the time as the only two basic inputs. Very basic things about these tokens would not work if the stream were not predictable for a given seed. The seed is the shared secret and magic. After that everything is predictable (but the seed is theoretically very hard to guess).
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
Darth Null
March 19, 2011 at 4:44 pm
First, thanks for the great responses!
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:
-
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.
-
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.
-
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.
-
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!
Steve
March 22, 2011 at 10:07 am
For reference, in response to a comment above, RSA state that the algorithm they use is “built upon the Advanced Encryption Standard (AES) algorithm”. http://www.rsa.com/node.aspx?id=3050
jgajek
March 22, 2011 at 4:38 pm
The reasoning for RSA keeping a database of token seeds is as follows:
- The token seeds are truly random, i.e. there is no way to compute them based on any information about the token, customer, etc.
- The token seeds are injected into the tokens during production.
- 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.
- 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).
Myguess
April 5, 2011 at 9:22 pm
I’ll go with #4 – the master seed theory. It seems too tempting to eliminate the need to track millions of seeds. Likely there is no single master seed because that would be stupid. My guess is that there is a new master seed used for every lot manufactured and the list of those seeds are what get stored and what was compromised. Since the hardware tokens are only good for a couple years, assuming the breach has been rectified, that’s how long the bad guys have until the stolen seeds are useless. RSA is advising using good pins and probably just crossing their fingers for the next two years.