TAG | authentication
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 😉
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.
- 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”.
Yesterday I took a long run (actually I did the full distance here) and usually such exercises are good opportunities to “reflect on the world in general and the infosec dimension of it in particular”… at least as long as your blood sugar is still on a level to support somewhat reasonable brain activity 😉
Anyhow, one of the outcomes of the number of strange mental stages I went through was the idea of a series of blogposts on architectural or technological approaches that are widely regarded as “good security practice” but may – when looked at with a bit more of scrutiny – turn out to be based on what I’d call “outdated threat models”.
This series is intended to be a quite provocative one but, hey, that’s what blogs are for: provide food for thought…
First part is a rant on “Multi-factor authentication”.
In practically all large organizations’ policies, sections mandating for MFA/2FA in different scenarios can be found (not always being formulated very precisely, but that’s another story). Common examples include “for remote access” – I’m going to tackle this one in a future post – or “for access to high value servers” [most organizations do not follow this one too consistently anyway, to say the least ;-)] or “for privileged access to infrastructure devices”.
Let’s think about the latter one for a second. What’s the rationale behind the mandate for 2FA here?
It’s, as so often, risk reduction. Remember that risk = likelihood * vulnerability * impact, and remember that quite frequently, for infosec professionals, the “vulnerability factor” is the one to touch (as likelihood and impact might not be modifiable too much, depending on the threat in question and the environment).
At the time most organizations’ initial “information security policy” documents were written (at least 5-7 years ago), in many companies there were mostly large flat networks, password schemes for network devices were not aligned with “other corporate password schemes” and management access to devices often was performed via Telnet.
As “simple password authentication” (very understandably) was not regarded sufficiently vulnerability-reducing then, people saw a need for “a second layer of control”… which happened to be “another layer of authentication”… leading to the aforementioned policy mandate.
So, in the end of the day, here the demand for 2-factor auth is essentially a demand for “2 layers of control”.
Now, if – in the interim – there’s other layers of controls like “encrypted connections” [eliminating the threat of eavesdropping, but not the one of password bruteforcing] or “ACLs restricting which endpoints can connect at all” [very common practice in many networks nowadays and heavily reducing the vulnerability to password bruteforcing attacks], using those, combined with single-auth, might achieve the same level of vulnerability-reduction, thus same level of overall risk.
Which in turn would then make the need for 2FA (in this specific scenario) obsolete. Which shows that some security controls needed at some point of time might no more be reasonable once threat models have changed (e.g. once the threat of “eavesdropping on unencrypted mgmt traffic from a network segment populated by desktop computers” has mostly disappeared).
Still, you might ask: what’s so bad about this? Why does this “additional layer of authentication” hurt? Simple answer: added complexity and operational cost. Why do you think that 2-factor auth for network devices can _rarely_ be found in large carrier/service provider networks? For exactly these reasons… and those organizations have a _large_ interest in protecting the integrity of their network devices. Think about it…