Reflections on the RSA Break-in

Some of you may have heard of the break-in at RSA and may now be wondering “what does this mean to us?” and “what can be done?”. Not being an expert on RSA SecurID at all – I’ve been involved in some projects, however not on the technical implementation side but on the architecture or overall [risk] management side – I’ll still try to contribute to the debate 😉

Feel free to correct me either by comment or by personal email in case the following contains factual errors.


My understanding of the way RSA SecurID tokens work is roughly this:

a) The authentication capabilities provided by the system (as part of an overall infrastructure where authentication plays a role) are based on two factors: a one-time-password (OTP) generated in regular intervals by both a token and some (backend) authentication server and a PIN known by a user.

c) the OTP generation process takes some initialization value called the “seed” and the current time as input and calculates – by means of some algorithm at whose core probably sits a hash function – the OTP itself.

d) the algorithm seems publicly known (there are some cryptanalytic papers listed in the Wikipedia article on RSA SecurID and a generator – needing the seed as input – has been available for some time now). Even if it wasn’t public we should assume that Kerckhoff’s principle exists for some reason 😉

e) So, in the end of the day, an OTP of a given token at a given point of time can be calculated once the seed of this specific token is known.

This means: to some (large) degree, the whole security of the OTP relies on the secrecy of the seed which, obviously, must be kept. [For the overall authentication process there’s still the PIN, but this one can be assumed to be the “weaker part” of the whole thing.]


RSA SecurID tokens, and those of other vendors as well, are sold in two main variants:

– as hardware devices (in different sizes, colors etc.) Here the seed is encoded as part of the manufacturing process and there must be some import process of token serial numbers and their associated seeds into the authentication server (located at the organization using the product for authentication), and some subsequent mapping of a user + PIN to a certain token (identified by serial number, I assume). The seeds are then generated on the product vendor’s (e.g. RSA’s) side in an early stage of the manufacturing process and distributed as part of the product delivery process. Not sure why a vendor (like RSA) should keep those associations of (token) serial numbers and their seeds (as I said, I’m not an expert in this area so I might overlook sth here, even sth fairly obvious ;-)) once the product delivery process is completed, but I assume this nevertheless happens to some extent. And I assume this is part of the potential impact of the current incident, see below.
– as so-called “soft tokens”, that are software instances running on a PC or mobile device and generating the OTP. For this purpose, again the seed is needed and to the best of my knowledge there’s, in the RSA space at least, two ways how the seed gets onto the device:

  • generate it as part of “user creation” process on the authentication server and subsequent distribution to users (by email or download link), for import. For obvious reasons not all people like this, security-wise.
  • generate it, by means of an RSA proprietary scheme called Cryptographic Token Key Initialization Protocol (CT-KIP)  in parallel on the token and the server and thereby avoid the (seed’s) transmission over the network.

Btw: In both cases importing the seed into a TPM would be nice, but – as of mid 2010 when I did some research – this was still in a quite immature state. So not sure if this currently is a viable option.


For an attacker going after the seed I see three main vectors:
  • compromise of an organization’s authentication server. From audits in the past I know these systems often reside in network segments not-too-easily accessible and they are – sometimes – reasonably well protected (hardening etc.). Furthermore I have no idea how easy it would be to extract the seeds from such a system once compromised. Getting them might allow for subsequent attacks on remote users (logging into VPN gateways, OWA servers etc.), but only against this specific organization. And if the attacker already managed to compromise the organization’s authentication server this effort might not even be necessary anymore.
  • compromise of the (mobile) devices of some users of a given organization using soft tokens and copy/steal their seeds. This could potentially be done by a piece of malware (provided it manages to access the seed at all, which might be difficult – protected storage and stuff comes to mind – or not. I just don’t know 😉
    This is the one usually infosec people opposing the replacement of hard tokens by soft tokens (e.g. for usability reasons) warn about. There are people who do not regard this as a very relevant risk, as it requires initial compromise of the device in question. Which, of course, can happen. But why “spend energy” on getting the seed then as the box is compromised anyway (and any data processed on it). I’m well aware of the “attacker can use seed for future attacks from other endpoints” argument. One might just wonder about the incentive for an attacker to got after the seeds…
    It should be noted that binding the (soft) token to a specific device, identified by serial number, unique device identifier (like in the case of iPhones) or harddisk ID or sth – which can be done in the RSA SecurID space since some time, I believe since Authentication Manager 7.1 – might to some degree serve as a mitigating control against this type of attack.
  • attack vendor (RSA) and hope to get access to the seeds of many organizations which can then be used in subsequent targeted attacks. I have the vague impression that this is exactly what happened here.  Art Coviello writes in his letter:
    “[the information gained by the attackers] could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”
    I interpret this as follows: “dear customers, face the fact that some attackers might dispose of your seeds and the OTPs calculated on those so you’re left with the PIN as the last resort for the security of the overall authentication process”.
I leave the conclusions to the valued reader (and, evidently, the estimation if my interpretation holds or not) and proceed with the next section.
Mitigating Controls & Steps
First, let’s have a quick look at the recommendations RSA gives (in this document). There we find stuff like “We recommend customers follow the rule of least privilege when assigning roles and responsibilities to security administrators.”  – yes, thanks! RSA for reminding us, this is always a good idea 😉 – and equally conventional wisdom including pieces like “We recommend customers update their security products and the operating systems hosting them with the latest patches”. And, of course, it’s pure coincidence that they mention the use of SIEM systems twice… being a SIEM vendor themselves ;-))
From my part I’d like to add:
– in case you use RSA SecurID soft tokens, binding individual tokens to specific devices seems a good idea to me. (yes, this might mean that users using several devices have several, different, instances then. and, yes, I understand that in the shiny new age of user-owned funky smartphone gagdets used for corporate information processing, this might be a heavy burden to ask your users for 😉
– some of you might re-think their (sceptical) position as for hard tokens: in the RSA SecurID space soft tokens can be “seeded” by means of CT-KIP, so no 3rd party is involved or disposes of the seeds. I’m not aware of such a feature for hard tokens.
– whatever you do, think about the supply chain of security components, which parties are involved and which knowledge they might accumulate.
– replacing proprietary stuff by standard based approaches (like X.509 certificates) should always be reconsidered.
– whatever you do, authentication-wise, you should always have a plan for revocation and credential replacement. This should be one of the overall lessons learned from this incident and the current trend that well-organized attackers will go after authentication providers and infrastructures (see, for example, this presentation from the recent NSA Information Assurance Symposium).
Last but not least I’d like to draw your attention to this upcoming presentation on the current state of authentication at Troopers. I’d be surprised if Steve and Marsh would not include the RSA incident in their talk 😉

Leave a Reply

Your email address will not be published. Required fields are marked *