RSA SecurID Breach Questions

Q: What was stolen from RSA? (based on Art Coviello's blog) and What is the current risk for SecurID users?

A: RSA says "..extracted information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation..." This is boiling water and everybody is trying to reverse engineer this statement.. What does RSA mean by reduced effectiveness? Without the full disclosure, all interpretations will be semi fictional.. Information sources are limited when RSA is silent. A very important sign of  RSA's response is "RSA SecurID Authentication Engine Security Best Practices Guide" document which was published in March 17.

Here are the 2 interesting statements from the March 17 Guide:

1 - "RSA recommends a defense-in-depth approach for protecting token data stored in your environment. RSA strongly recommends that your storage systems encrypt the token data with a separate key in addition to the encryption provided by RSA SecurID Authentication Engine. Using two separate keys maximizes the protection of stored token data."

My interpretation: Do not trust RSA authentication server's built-in encryption, use yours.This means 3rd party who "extracted information from RSA"  has a good understanding of how RSA obscures token data on the authentication server...It is usually possible to access stored encryption keys since they have to be accessed for operation anyway. So if source code is lost, this may happen faster..Risk: You had to secure auth server anyway, now the risks are higher but this specific risk does not require you to replace every single token in the field until your own auth server is hacked.. And believe me when your authentication server is hacked you have other serious problems as well (BTW I'am not sure how auth server will work if I encrypt token data with my keys at file level)

2- "Never give the token serial number, PIN, tokencode, token, passcode or passwords to anyone."

My interpretation: Let's analyze this one in-depth.. When you use SecurID, you enter passcode as your  password. A passcode is made up 2 pieces on RSA, a pseudo-number (that is dynamically generated on the token a.k.a. tokencode) and your PIN.. 

The beauty of multi-factor dynamic password tokens is that if I know your PIN I still need the tokencode (so the token).. If I steal your token, I still need the PIN... No attacks are effective until you get token for that specific 60 seconds+PIN combo.(in theory ; )....  The scary part of the warning above is the "token serial number", a number on the back of the token usually used as a subfactor for  enrollment and password resets... Directly losing ""token serial number" shouldn't have mattered . if it did, it was not supposed to be imprinted on the back of the token..So the hypothetical risk is that the guys who extracted data from RSA can generate a tokencode from the serial number.. I do not think this is the possibility since that eliminates the whole idea for the need for the token seeds..Hopefully RSA token's private algos are not that simple (serial number generates the seed).  Same argument is valid for tokencodes.. If I have to hide my tokencode where is the advantage of using a dynamic code generator?

Back Image with Token Serial Number

I will keep covering this topic until  we have a conclusive answer.

Using Certificates for Authentication ? Where to store them ?

Question: 

Has anyone deployed a VPN solution that leverages user certificates for authentication?

We are considering the possibility of leveraging digital certificates as an authentication factor for VPN. Has anyone implemented this or looked at solutions that do this? We are not comfortable with solely relying on a certificate and the security/integrity of the PC as an authentication mechanism. If you are currently using certificates, I would be interested in hearing how you are deploying this.

Answer:

.....,

The short answer is yes.  We did deploy several off-the-shelf certificate based authentication solutions for remote access VPN systems such as Cisco, Check Point, Juniper, Citrix, Nortel.. It is again very possible to deploy similar solutions over SSL VPN solutions (This time easier since browser is the client).   I worked with Entrust as the PKI integration provider.  When using certs, most of the questions/problems are generic PKI related questions (CRLs,  OCSP, identity management etc)

9 out of 10, enterprise shops store the certs on PC or mobile devices since they want to avoid using tokens/smart cards. Using a 3^rd party storage is ideal but to be honest smart cards share the fate of PKI for complexity so many solution sets avoid tokens/smart cards, unless the policies mandate certificates.

When smart cards are more expensive/complex (readers, personalization etc) enterprises use USB tokens to store certificates. (Several companies  provide tokens with certificate support, ActivIdentity, Aladdin, Authenex, Entrust, SafeNet (merged with Aladdin) , RSA (RSA has a hybrid token for OTP + certs)).

If you would like to use smart cards as the certificate container, or use the same certs for physical security simultaneously, you can simple take one of the ready to use HSPD-12 Personal Identity Verification (PIV) Card solutions (http://fips201ep.cio.gov/apl.php) so that you can avoid designing all components architecture yourself.

Of course do it yourself path is more fun, technically it is straightforward to integrate certs with any 802.1x based authentication server but as you know it usually gets more complex. We have deployed a complete system for enrollment, biometrics, cards, CMS etc, (took 3+ years)

cheers,

-     - yinal ozkan