RSA/SecurID data has been compromised.
What does this mean?? Security researchers have been discussion the latest news about hackers getting data from RSA related to the SecurID authentication token. I have one and used it for years. The SecurID fob is simple to use. Every 30 seconds a 6-digit number is displayed on the device. You log onto a computer by typing your username, your PIN, and your 6-digit number. Since that number is unique to your device, only the owner of the device can use it to log in.
I’ve seen many interesting discussions on the RSA Breach, but I felt the threat analysis was incomplete. Since RSA said nothing, I’ve made some assumptions, and analyzed those assumptions.
I’ve made some assumptions about what might have happened. If these turn out to be false, then the threats are not as severe. But let’s set the foundation.
The 128-bit SecurID algorithm has been obtained
It’s well known that in 2000, someone who claims to be I. C. Wiener published the source code to the algorithm. However, others have said this is the old 64-bit version of the algorithm, and that the newer algorithm is based on 128-bit AES. The Russian name Wiener looks like a joke, BTW. It really doesn’t matter. First of all. Kerckhoff’s Principle says that the security should not be based on secret algorithms. Besides, if the hackers were inside RSA, they could have obtained the algorithm. Alternatively – they can reverse engineer the client application for the iPhone, Blackberry, Android, etc.
We should not assume that the algorithm is secret. I have not seen it published, but that does not matter. We have to assume it’s known.
The files containing seeds and the corresponding serial numbers were obtained
The SecurID token generates seemingly random numbers, which are used to authenticate users on a computer. The numbers are predictable once you know the serial number of the device, the special seed number, and the time (as the numbers change every 30 seconds). The time is of course guessable. Each device has a clock and it might “drift” or get out of sync with the real time, but the server allows some “slop” in which number is valid, and it recognizes the drift each token has. If a device’s clock is always slow, the server can learn how much it is off, and accurately know which number is showing on the token. I’ve seen email from people who know that imply that this data was obtained. The files that identify the company by the token serial number was obtained If this is true, then knowing the serial number of the device will tell you the name of the company that purchased the device. I have an old version, and a new version, and both of them have serial numbers greater than a million. I don’t know if these are sequentially numbered. But there must be an algorithm, and if a company orders 10,000 tokens, it is likely the numbers are close together, if they aren’t sequential. Summary of the SecurID Technology This section is for those who don’t understand the algorithm.
Steve Bellovin used a nice way to describe the technology. Let’s call the number being displayed on the SecurID token the TokenValue. There is a hash algorithm H, such that TokenValue= H(Seed, Serial Number, ClockTick) The ClockTick is based on the date, and/or a counter inside the device. It’s not considered a secret. And when a customer logs into a server, they enter Username PIN+TokenValue The server uses the username to look up the serial number, and/or the SEED value (perhaps the serial number is used to look up the SEED value.). If the generated TokenValue matches the number provided, and the PIN is the same, the user is authenticated. I call this calculation a hash value, because cryptographers describe hash functions (also known as one-way functions) as something that is hard to reverse. Knowing the token value will not help you learn the seed and serial number. It’s difficult to make a whole potato and a slice of corned beef from a serving of hash.
When analyzing risks, it is important to consider that the goal of the attack is – what is the threat model? The SecurID token provides a one-time password (OTP). That is, if someone learns your password and pin, (from a keystroke logger, shoulder surfing, of man-in-the-middle attack) then they do not have the ability to gain access to your account. Other threats not related to the SecurID technology include Sniffing passwords on the wire – HTTPS prevents this Brute force attacks on a server – the server should detect this and block the account when too many attempts fail. The SecurID technology does not address these issues.
Let’s consider those pieces of information that are needed to do an attack. All five pieces of information is needed for an attack to be useful.
Can the attacker guess the SecurID Serial Number?
This information is written on the back of the SecurID fob. Some people attach it to their keychain, and it might be glimpsed. In addition, RSA may have records that associate the serial number to a company. If so, the search space is limited to the number of tokens issues. Let’s say a large order is 100,000 tokens, or about 2 to the 17th power (217). But it could be as small as 500 tokens. Let’s just say that the chances were formerly a snowball chance in Hell, but now the chance of a snowflake falling on your head.
Can the attacker guess the SecurID Username?
Of all of the values, I assume this is the easiest to guess. There are conventions used by each company and if you know this convention, you can predict the username. It could be a ID number, or a combination of letters from the user’s name. Usernames are rarely random. I therefore assume this is trivial.
Can the attacker guess the SecurID Pin?
This is also a concern. Some people, because of their belief that the SecurID token is secure, use a weak or trivial PIN. It may even be a 4-digit number.
Can the attacker guess the SecurID Company/Website?
Of course it’s essential to know where the token is useful. If the hacker has a SEED and serial number, they have to get the company, username and PIN. But we can’t assume this is a hard problem.
Can the attacker guess the SecurID Seed?
This is the crux of the issue. The largest threat is caused by the loss of the SEED files. Why is this? Because the seeds are the most valuable. The estimated number of stars in the Universe is 100,000,000,000,000,000,000,000. That’s a 1 followed by 23 zeros. The 128-bit seed, if generated correctly, should be a random number. The number of possible combinations are 2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 That’s 3 followed by 38 digits, which is about 3,000,000,000,000,000 times larger than the number of stars in the universe. By knowing which seeds are used, the difficulty drops from 2128 to the same as finding the serial number (217) or less.
As I see it, there are three major threats
- Brute force attack social engineering
- Observing and cloning a SecureID Token – An increased ability to do a brute force attack, and
- the ability to replicate the SecurID Token.
Before I go into depth of the analysis,
Threat of a Brute Force Attack on the SecurID Token
Let’s first assume that the attacker guesses of knows the user PIN. People use (and reuse) simple PINS, like “abc123.” The username is guessable. If we then assume the company has 1000 tokens, the problem is to find which token belongs to a person. If there are 1000 tokens, then the attacker can try 1000 times. The attacker can spread out this attack across several different IP addresses, and try several different accounts, over a period of months. If the company does not know of the increased number of failed attempts, they may not realize a brute force attack is happening. This attack is a real possibility. It could happen once a year.
Threat of using Social Engineering to obtain the SecurID Token
This attack is easier, if the support team is unsophisticated about social engineering attacks., A user can contact the help desk and say they got a new token, but it’s not working. Then they can read off the serial number (using one where they have the SEED value), and if the account is reset, the attacker can gain access to the account because they can generate the token value. The attacker can likewise ask them to reset the PIN.
Threat of SecurID Token Replication
The third attack can occur if the attacker is able to observe the actions of a legitimate user. They may get a glimpse of the token value, and the serial number on the back of the token. They may see the username, and guess the PIN. This can be done by watching someone log in. After all, people assume SecurID is secure, and the user may not care if they are closely watched during the login process. Knowledge of the token value gives the attacker a way to identify the serial number. by a brute force attack using the list of serial number and seed values obtained. The attacker has to include some “slop” in the synchronization. But a brute force attack on 217 combinations does not take long. Also, if someone is able to observe the login sequence once, and they have the SEED values, they can predict future sequences. This is a brute force attack, but the difference is that this is done off-line. In other words, it cannot be detected. This says that the ability of the SecurID token to provide one-time-passwords is significantly weakened. If the account is either watched (camera, shoulder surfing, keystroke logger, man-in-the-middle attack, etc.) then the credentials can be re-used without the owners knowledge.
In the worse case scenario, there are three threats that exist that did not significantly exist before. Two can be addressed. The third one cannot. Brute force attacks can be detected. Single accounts can be disabled, but if the brute force attacks are against all users, the only way to prevent this is to issue new tokens. Social engineering attacks are possible, and customers can be alert for them, and prevent them. However, the biggest protection of the SecurID One-Time-Password is broken. It can no longer be assumed that if the attacker can observe one authentication transaction, they will be unable to re-use those credentials. We has to assume the hackers who got into RSA are able to re-use SecurID credentials. That is, if they can observe one authentication sequence, they can replicate the credentials without being detected.