Here's my hypothesis for why they need to replace all devices.
The securid tokens are basically sealed, tamper-proof etc hardware pseudorandom generators. RSA knows the seed burned into the PRNG for every device they manufacture.
At customer premises, there's a RSA server component that simulates the same algorithm as the securid devices owned by that customer. This is how they verify that the number you enter is what it's supposed to be, hence proving that you possess the securid. To do this, the customer server needs to know the seeds of all of that customer's devices. This is a trivial computational burden btw, since securid generates a new number only once a minute.
I strongly suspect that RSA continued to store the seeds for their customer's tokens after selling them on an internet-connected computer on their premises. Somebody cracked into this database and stole the seeds for all RSA devices in use by all of RSA's customers.
Once the crackers have this information, they can predict the sequence of numbers for any device out there.
The only fix is to change the seeds: since the hardware is sealed, the only way to do so is to replace the tokens.
I think it's ULTRASTUPID of RSA to (1) keep the seeds after selling a device, (2) keep it on a internet-connected computer.
All the RSA tokens I've ever used had a PIN in combination with the number displayed on the device. So to successfully mimic a device the attacker would need to know the PIN (1:10000 guess) plus the seed for the device.
Good point. I had forgotten about the PIN. But that's simply yet another password that amenable to guessing/bruteforcing/keylogging etc. The securid is not vulnerable to such attacks which why is why this crack is a big deal.
exactly, I'm paying a lot for working two-factor authentication. If the algorithm generating one factor is known by hackers, and I simply have 2 passwords which the user could have written down somewhere or picked the most obvious or gotten keylogged, then what am I paying for?
The pin is only for local access, it doesn't get used to secure the generated code. I know this because I forgot my pin on a vasco device, called my bank and they gave me a code that allowed me to change the pin (and nobody else knows the new pin, not even the bank).
It does seem a bit weak to be relying on a system based on shared secrets nowadays. USB keys/smartcards that can do RSA aren't particularly expensive. The key can be generated on the devices themselves, so there would be no single database to compromise since nothing else would need to hold a copy of the private key.
I'm not sure if I understand how this would work, and I'm curious - I believe the majority of SecurID tokens are used as a part of two-factor authentication to further prove you have the credentials you state you do, in concert with a password - how would device-generated keys work for this?
See for example http://ftsafe.com/products/ePass1000.html. The device uses its own random number generator to create an RSA keypair. The private key never leaves the device. The public key will leave the device and be available for checking on the authentication server (usually by being signed and that signature checked on the authentication server).
When authentication is required, the server sends a challenge to the device ("sign this"). The device signs it with its private key, which no other device can do.
This way it's impossible for a single point of failure to compromise the entire system during operation, like it has here with SecureID. The authentication server might be compromised, but that could happen in any system and it would only need that server to be rebuilt.
There are attacks against this system too of course - for example the RNG could be compromised on the devices themselves, or there could be an attack allowing the extraction of a private key due to a design flaw. But the single point of failure as in this case doesn't exist.
They sent out warnings and did conference calls, but did not give details when people asked if the algorithm that generated the codes had been compromised, and if tokens should be replaced.
One prime contractor reportedly felt it necessary to change to another multifactor system (there are still a few real men)
Around May 21, Lockheed's network was breached by hackers who duped SecurID token codes
(submitted that one, sank like a rock and went nowhere LOL)
Now, June 6, they say they will replace the tokens, because, quote "customers don't want to tolerate any level of risk, whether it's real or perceived."
I would say after prime defense contractors have been breached, it's not a perceived risk, it's a hair on fire situation.
It's a bigger deal they didn't replace the devices when they found out.
I was surprised to find out that a large number of tokens were still in use. I think some of the problem may be with a few large organizations that simply didn't have the logistics in place to replace their tokens quickly.
Two organizations that I'm familiar with had each replaced their thousands of tokens by early May.
It's logistics, and also RSA to their eternal discredit did not recommend or pay for replacement. Those aren't cheap (like $50 apiece). If you're a CTO with 1000 users and rudimentary security knowledge, are you going to spend $50,000 and a bunch of time tracking down every single user (who will think it's all a terrible bore) and replace their token, if the company you rely on to keep you secure doesn't say it's necessary? I give credit to the people who didn't screw around, and switched vendors.
RSA to their eternal discredit did not recommend replacement
Is that just your assumption? I believe everyone who received guidance from RSA on the subject was asked to sign a non-disclosure, but I think some of them might be surprised to hear you say that.
I think most of what you say is generally assumed to be the case although they haven't disclosed this. I think you may have oversimplified cloning a token though.
In order to clone a given token you require the token seed, token serial and its current token code[1]. The attacker my have the token seeds and serial numbers from the RSA security hack but not a token code without physical access to the token or a keylogger.
If the attacker could install a keylogger on some employee computer they could perhaps capture a token code and then use that to start emulating say 20,000 tokens with the seed and serial pairs stolen from the database. Next time they capture a code compare it with all the tokens being emulated to see if there is a match, if yes, possible success, you have cloned their token and a keylogger will also capture their pin. If there is no match, move onto next set of seed serial pairs with the code you just captured.
I still dont understand why it's taken so long to get to the point where they're going to renew the tokens. Perhaps I'm misunderstanding SecureID implementation, but If an attacker had accessed the database with the token seeds and serials, wouldn't the security then essentially become little better than single factor authentication?
It almost seems like they didn't actually know for definite if the database had been stolen and where unwilling to burden the cost of replacing all the tokens as a precaution. Now with the Lockheed Martin incident they know it was compromised and are forced to.
19 comments
[ 3.5 ms ] story [ 51.8 ms ] threadThat's quite a danger sign! If your security relies on attackers not knowing the details of your system then your security is quite poor.
(As opposed to a random secret that has no particular meaning and is different for each device.)
The securid tokens are basically sealed, tamper-proof etc hardware pseudorandom generators. RSA knows the seed burned into the PRNG for every device they manufacture.
At customer premises, there's a RSA server component that simulates the same algorithm as the securid devices owned by that customer. This is how they verify that the number you enter is what it's supposed to be, hence proving that you possess the securid. To do this, the customer server needs to know the seeds of all of that customer's devices. This is a trivial computational burden btw, since securid generates a new number only once a minute.
I strongly suspect that RSA continued to store the seeds for their customer's tokens after selling them on an internet-connected computer on their premises. Somebody cracked into this database and stole the seeds for all RSA devices in use by all of RSA's customers.
Once the crackers have this information, they can predict the sequence of numbers for any device out there.
The only fix is to change the seeds: since the hardware is sealed, the only way to do so is to replace the tokens.
I think it's ULTRASTUPID of RSA to (1) keep the seeds after selling a device, (2) keep it on a internet-connected computer.
THIS IS A BIG DEAL, imho.
When authentication is required, the server sends a challenge to the device ("sign this"). The device signs it with its private key, which no other device can do.
This way it's impossible for a single point of failure to compromise the entire system during operation, like it has here with SecureID. The authentication server might be compromised, but that could happen in any system and it would only need that server to be rebuilt.
There are attacks against this system too of course - for example the RNG could be compromised on the devices themselves, or there could be an attack allowing the extraction of a private key due to a design flaw. But the single point of failure as in this case doesn't exist.
It's a bigger deal they didn't replace the devices when they found out.
a little background -
On March 17, RSA reported their security had been breached. http://www.nytimes.com/2011/03/18/technology/18secure.html?_...
Apparently they got targeted by a zero-day Adobe/Excel virus - http://news.cnet.com/8301-27080_3-20051071-245.html
They sent out warnings and did conference calls, but did not give details when people asked if the algorithm that generated the codes had been compromised, and if tokens should be replaced.
One prime contractor reportedly felt it necessary to change to another multifactor system (there are still a few real men)
Around May 21, Lockheed's network was breached by hackers who duped SecurID token codes
http://www.cringely.com/2011/05/insecureid-no-more-secrets/
(submitted that one, sank like a rock and went nowhere LOL)
Now, June 6, they say they will replace the tokens, because, quote "customers don't want to tolerate any level of risk, whether it's real or perceived."
I would say after prime defense contractors have been breached, it's not a perceived risk, it's a hair on fire situation.
Un-freaking-believable.
I was surprised to find out that a large number of tokens were still in use. I think some of the problem may be with a few large organizations that simply didn't have the logistics in place to replace their tokens quickly.
Two organizations that I'm familiar with had each replaced their thousands of tokens by early May.
Is that just your assumption? I believe everyone who received guidance from RSA on the subject was asked to sign a non-disclosure, but I think some of them might be surprised to hear you say that.
In order to clone a given token you require the token seed, token serial and its current token code[1]. The attacker my have the token seeds and serial numbers from the RSA security hack but not a token code without physical access to the token or a keylogger.
If the attacker could install a keylogger on some employee computer they could perhaps capture a token code and then use that to start emulating say 20,000 tokens with the seed and serial pairs stolen from the database. Next time they capture a code compare it with all the tokens being emulated to see if there is a match, if yes, possible success, you have cloned their token and a keylogger will also capture their pin. If there is no match, move onto next set of seed serial pairs with the code you just captured.
[1]http://seclists.org/bugtraq/2000/Dec/459
It almost seems like they didn't actually know for definite if the database had been stolen and where unwilling to burden the cost of replacing all the tokens as a precaution. Now with the Lockheed Martin incident they know it was compromised and are forced to.