
RSA finally comes clean: SecurID is compromised - guan
http://arstechnica.com/security/news/2011/06/rsa-finally-comes-clean-securid-is-compromised.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
======
mixmastamyk
Steve Gibson and Leo have been talking about this for weeks on the Security
Now podcast. Interesting story if you'd like to listen. Amazing how a well
known security company kept its crown jewels within reach general employees
with Windows boxes. When are they gonna learn?

~~~
iwwr
Not only that, they have employed a security-by-obscurity strategy:

 _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._

~~~
edanm
In their "defense", keeping it secret might have had more to do with saving
their public image than with any belief that it was actually better security.

------
16s
I've programmed some for OTP devices. Vasco primarily, but some RSA too.
Normally, the OTP algorithm takes two args... a "shared secret" (each customer
has a different secret) and the exact date/time. All the fobs and the back-end
server know/share the secret.

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.

~~~
jeffreyg
> 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?

------
AndyNemmity
Our securid's from RSA were replaced weeks ago in mass. I work for a well
known large company, is it just the news is late?

~~~
Devilboy
Yes the Lockheed Martin thing happened last month, it's just taken this long
for RSA to publicly admit that it has a serious problem.

~~~
dekz
> It's taken this long for the RSA Lawyers to allow a public statement

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.

~~~
timson
> The only "serious problem" was storing seeds for some unknown reason.

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.

~~~
ceejayoz
> 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.

It'd be a very _profitable_ operation for RSA, so I doubt this explanation.

------
adulau
There is fundamental issue about those kind of tokens. The customer is not
able to renew or set the private key (seed in RSA terms) of their tokens. It's
a kind of insecure business model where the customer has no control over the
tokens and is bound to the security of the supplier (if the supplier is
compromised...). There are solutions like Yubikey or other compliant HOTP/TOTP
tokens where the customer has the control of the private keys inside the
token.

~~~
jvdh
True, but the positive fundamental property of these tokens is that it is very
very unlikely that someone ever messes with your device without you knowing
it. Which prevents a MITM attack.

~~~
InclinedPlane
But as we've seen that security is only as good as the security on RSA's
servers. Imagine if someone more sophisticated had (has?) attacked RSA's
servers and avoided RSA becoming aware, how secure would your token be then?

------
eik3_de
Can anyone compare this to Google's two-factor authentication using the
Authenticator App? The app is open source (<http://code.google.com/p/google-
authenticator/>) and the private key(correct?) is provided via a QR scan.

~~~
eli
It's the same concept, yes. And if the servers running the Authenticator at
Google were hacked this system would likely be broken (but you'd also have
much bigger problems)

~~~
blibble
there's no online component... your phone takes the current time (divided by
some value), the secret key, and performs a cryptographic function on it, then
the system you're logging into does the same thing and compares the results.

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.

~~~
dsl
> you can generate and input the key yourself, so that Google never sees it.

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.

~~~
devicenull
Right, but a compromise of your token for Google's services would not mean
your token for your job was compromised as well. You could even generate a new
key for each machine you connect to, if you were paranoid enough.

------
rdl
This is one of those cases where I really hate NDAs.

------
KiwiNige
If I'm understanding this correctly, then an attacker still has to know which
seed is linked to my token in order to use it?

Or can they reverse engineer that if they catch sight of one number?

Edit: Spelling

~~~
jvdh
Quote from the article:

 _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.

~~~
chmike
So the seeds are in fact equivalent to a signature made with symmetric keys...
If the SecureID card used asymmetric keys with a truly private key, such
incident could not have happened.

Using private keys stored in a hardware carried with the owner with a
challenge Q&A seems more secure.

~~~
jongraehl
The SecureID device S computes S(s,t) without any input from the server the
user is authenticating to. t is synchronized time and available to everyone. s
is a secret specific to that device. I don't know if it's a shared secret, but
the compromise suggests that either it is, or RSA kept the 'private key' part
on their servers for convenience.

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.

------
7952
Although RSA were absolutely at fault it seems like a design failure that the
seeds cannot be revoked. Give the keys 4 possible seeds and put 3 of them in a
safe. Security is about having defence in depth.

~~~
sliverstorm
How do you update the tokens though? They need to be simple, no hooking into
the internet.

~~~
guan
They could maybe have a single button that allows you to switch to a backup
seed with some elaborate sequence of presses.

------
skimbrel
This is nitpicky, but shouldn't the title (on Ars I guess, since it was used
verbatim) be "was compromised" since this was a one-time data theft that
rendered all currently-live SecurID tokens useless?

~~~
jvdh
True, on the other hand there are still 40 million of those tokens out there,
which are all compromised and have to be replaced. So that is still very much
present tense.

~~~
dekz
It's hard to tell from the information given if ALL seeds have been
compromised or just SOME which RSA may have been holding.

~~~
ceejayoz
Given RSA's reluctance to come clean on this, I don't think anyone's going to
trust "oh, but _your_ SecureID wasn't compromised" from them.

------
kprobst
Funny thing that, I'm holding a SecureID token in my hand right now, having
just remoted into the corp network via VPN.

Thanks RSA.

------
johno215
It is sad how the comments here are much better than at Ars.

[I wish Ars would implement threading and a silent karma system]

------
drivebyacct2
Didn't we know this when the breach originally occured? Or after there was a
major break in?

Oh, it's "official" now. Good thing they were responsible about it.

~~~
zitterbewegung
Happened last month. [http://www.engadget.com/2011/03/18/rsa-hacked-data-
exposed-t...](http://www.engadget.com/2011/03/18/rsa-hacked-data-exposed-that-
could-reduce-the-effectiveness-o/) Lockheed Martin Breach
[http://www.infoworld.com/t/hacking/lockheed-hack-should-
put-...](http://www.infoworld.com/t/hacking/lockheed-hack-should-put-the-us-
high-alert-329) (This happened a few weeks ago) I remember hearing it earlier.

~~~
drivebyacct2
Yeah, that was my point.

------
tedjdziuba
Hm, defense contractors were attacked, and it's taken so long for RSA to
acknowledge the compromise to the rest of the world? It's was most definitely
perpetrated by a government, and it's taken so long for them to respond
because _our_ government has been assessing the damage.

