RSA finally comes clean: SecurID is compromised
arstechnica.com
arstechnica.com
RSA Security Chairman Art Coviello said that the reason RSA had not disclosed the full extent of the vulnerability because doing so would have revealed to the hackers how to perform further attacks.
On the fob thingy, one calculation occurs. The fob can be physical or virtual. So you may have a physical key fob or a virtual software fob for your blackberry, iPhone, Droid, etc. They even work with dumb phones over SMS. Either way, the same calculation occurs. Again, it looks something like this:
const unsigned int OTP ( const string& shared_secret, const time& time_of_day ) { return OTP; }
So when you push the button on the fob (or just look at it if it's the always on type), it returns an OTP. On the server, the exact same calculation occurs except that it calculates a range of OTPs (in case the time on the fob has drifted... and this does indeed occur). A minute or so worth of calculations. The fob's OTP must fall into the server's calculated range, if not, the OTP will fail and the fob will need to be recalibrated (resync its clock).
So, if this story is true, then the list of customer shared secrets was stolen and whoever has them now knows that company X uses secret Y on their fobs. It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that.
If you don't believe it, what other attack/compromise do you suppose took place?
Fixed that for you. Customers were notified and I believe many a secureid token was replaced, at least for all mission critical businesses.
That letter to the public would have been second to the priority of customer notifications, even sony was late in their press release -- carefully wording their response to forgo accepting blame. Since the attack was "thwarted" we can assume that RSA did in fact communicate with these businesses and shared the knowledge of the potential attack.
It's not a "serious problem" like if the fundamental cryptology is flawed or implemented with a level of security through obscurity. The only "serious problem" was storing seeds for some unknown reason. If your seed wasn't stored then you have nothing to worry about, and I can only assume if you were contacted by someone from RSA(personally) than you should probably assume your seed was stored.
One would hope that a business like Lockheed Martin then setup a honey pot to try and gather information on the attackers logging in with these compromised SecureIDs.
I read somewhere else that the seeds are stored by RSA as an additional backup for the customers. In the event that the customer accidentally loses their seed database, it would be a very costly operation to replace all the SecurID hardware tokens.
But... well... they are forced to replace all the SecurID hardware tokens anyway.
It'd be a very profitable operation for RSA, so I doubt this explanation.
Errrmmm, I'm not entirely sure that's correct - I wonder how many of Sony's private keys are in scriptkiddies hands right now?
The webserver needs access to the private key. Anyone who gets root on the webserver can read the private key.
[1] http://www.thales-esecurity.com/Products/Hardware%20Security...
For example, let's say you collected a large amount of https traffic by listening in on wifi hotspots or such like, then you attacked a certificate authority and managed to gain access to everything they have. This would be very bad, but you wouldn't be able to decrypt the traffic you'd recorded because you still wouldn't have each of the private keys used. That's very different from the problem of RSA tokens. Gaining access to RSA's servers resulted in compromising every token. Decentralization is often key to security.
with secureid the secret key is fixed in the hardware (and RSA keep a copy of the key), whereas with Google authenticator you can generate and input the key yourself, so that Google never sees it.
I can confirm that. The app doesn't require any permissions. I rebooted my phone while in flight mode and the Google login via Authenticator code works as expected.
Google still needs to know the secret. All authenticators are based on a shared secret model, so the same possible attack vector that bit RSA.
Or can they reverse engineer that if they catch sight of one number?
Edit: Spelling
Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised. The algorithm is already public knowledge.
As a result, SecurID offered no defense against the hackers that broke into RSA in March. For those hackers, SecurID was rendered equivalent to basic password authentication, with all the vulnerability to keyloggers and password reuse that entails.
So they got a lot of the seeds and then were basically down to trial and error, similar to know passwords.
Using private keys stored in a hardware carried with the owner with a challenge Q&A seems more secure.
You're right that a different device S' that received a challenge c from the server and computed S'(c,s,t) could offer more security via public key crypto. But it would take more power (if communicating to the client machine to avoid user transcription of the challenge) or have a more cumbersome UI. I'll bet such devices are already sold.
One would have hoped that the LMC admins would have detected a brute force attack against their RSA servers, I guess they were already infested with keyloggers?
Thanks RSA.
[I wish Ars would implement threading and a silent karma system]
Oh, it's "official" now. Good thing they were responsible about it.