The attack on RSA that the company revealed last week raises a multitude of questions about the security of the company’s network and its own internal procedures. But the most important issues the RSA attack brings to the surface concern exactly what the attackers may have been after and what the successful compromise means for the integrity of the tens of millions of SecurID tokens deployed around the world.
RSA officials have said little about the details of the attack, aside from saying that the incident resulted in some data about SecurID being stolen and that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.” That statement is intentionally vague and leaves a lot of room for interpretation.
There’s been no shortage of speculation and dark predictions in the wake of the RSA compromise, but there’s been precious little clear-eyed analysis of what exactly it might mean if the attackers were able to gain access to some of the secret cryptographic material used in the SecurID product.
If that’s indeed what happened–and it may be quite a while before that’s known for sure–there are a number of scenarios that could result from the attack, ranging from somewhat worrisome to disastrous. The seriousness of the problem is directly related to what, if any, of the cryptographic material the attackers got hold of, Steve Bellovin of Columbia University wrote in his analysis of the attack.
“Fundamentally, a SecurID is a display, a clock T, a secret key K, and a keyed cryptographic hash function H, all in a tamper-resistant package. Every 30-60 seconds, the token calculates H(K, T) and displays the result on the screen. When you log in, you supply your userid, the displayed value, and a PIN. The system consults one database to map your userid to the serial number of your token; it consults another to find the secret key for your token. It then does the same H(K, T) calculation to make sure the results match what you sent; it also checks your PIN. If everything is ok, the login is successful,” Bellovin wrote.
“Is the risk that the attackers have now learned H? If that’s a problem, H was a bad choice to start with…The second big risk is compromise of the confidentiality of the key database. If RSA stored copies of customer databases, these could be at risk. That would be nothing short of a disaster for any affected company. “
As troublesome as these scenarios are for SecurID users, perhaps the more likely target of the attack on RSA is the source code for the software that’s used to administer and run the token deployments at customer sites, Bellovin said. RSA, having been in the security business for nearly 20 years, understands the risks to its network and its products, especially SecurID, which is used in some of the top financial services companies and government agencies in the world. The company likely had the key database and other cryptographic assets properly protected.
“There’s a lot of code needed for maintaining databases, adding and deleting users, making backups, synchronizing master and secondary copies of databases, and more. An attacker who could penetrate these administrative systems doesn’t have to worry about key generation or cryptanalysis; they could simply steal existing keys or insert new ones of their own. To quote myself, ‘you don’t go through strong security, you go around it.’ The crypto may be strong, but what about the software?,” Bellovin wrote in his analysis.
As others have said many times over the years, a given cryptosystem is unlikely to be the softest target in a security system. An implementation mistake or software bug is much more likely to be the most efficient way in.
