I have no inside knowledge about the RSA hack, but based on what has been published over the last few days, we have to assume that token serial numbers, seeds, device ownership, and the algorithm have been compromised.
Since the algorithm that powers RSA SecurID soft tokens runs on PCs and smart phones, it can’t be that hard to reverse engineer it without any material from the RSA hack.
There are two inputs into the SecurID algorithm; the time of day and the secret seed. If you know both, you can generate the response number displayed on the token. But you need to know the targeted employee’s username, static password, and what specific SecurID the user has in his possession.
What I am gleaning from the news stories is that attackers have been able to drop malware on targeted PCs which allows them to capture keystrokes including the user name, status password, and the one time password (OTP) generated by the RSA token.
Normally this would not help the attacker, since the OTP can be used only once and since it was already used by the authorized employee when it was captured, it cannot be used a second time by the attacker.
Sure, the attacker might be able to “look over the shoulder” of the employee, but the attackers would need to be patient while they waited for the employee to look at information that was of interest to them.
But with access to the RSA algorithm, knowledge of what tokens are assigned to what companies, and a list of the seeds in those tokens, it becomes a bounded brute force exercise to figure out which token a specific employee is using.
Let me break this down into the steps used to hack into a network using this information. While it seems like I am giving away trade secrets, attackers apparently have already used this knowledge to hack into Lockheed Martin.
- Drop malware onto a targeted PC owned by XYZ company that will install a keylogger.
- Capture the user name, password, and RSA token response when the user logs in to the XYZ corporate network from the targeted PC.
- One at a time, input the time that the OTP was captured by the keystroke logger along with one of the stolen seeds that belong to the RSA tokens owned by XYZ company into the SecurID algorithm. One of the seeds will generate an OTP that matches the captured value.
Using the information from step 3, you can determine which token is in use by the targeted employee. You know have his user name and static password and can use the seed and the current time to generate as many OTPs as you like.
While it’s easy to take shots at RSA, this is not just an RSA problem. It is a problem with all OTP tokens. Because the token and an authentication server have to generate and match the same OTP, they must have a shared secret. And as we have seen, once the algorithm and shared secret get out, the protection is broken.
My next blog entry will talk about the use of smart cards and public key infrastructure (PKI) eliminate the problems of using a shared secret for authentication and will show by this finally might be the year that smart card authentication becomes mainstream.
