Mark DiodatiWhile we wait for more information from RSA about the recent attack on its SecurID tokens, I’d like to revisit a potential attack vector that I discussed in my first blog entry on the topic (March 18). The OTP device’s seed and the serial number are present during the manufacturing process. What if the OTP device’s symmetric key (AKA seed) can be derived from the OTP device serial number? Can something private be derived from something public?
Every SecurID OTP device has a serial number. The serial number is plainly visible on the back of the OTP device, the shipping packaging, in electronic form in many places, and (potentially) on shipping documentation. OTP devices that are shipped to customers are sequentially numbered.
It is easy to imagine the disclosure of one OTP serial number, including direct visualization, social engineering, insider knowledge, etc. The attacker would need to know the username associated with the OTP serial number as well as the user’s PIN. I discuss the ways this information can be captured in my last blog entry on the topic (March 21). If the attacker can acquire even one customer OTP serial number, it can get many customer serial numbers because the devices are sequentially numbered.
If the attack on the SecurID OTP system enables the calculation of the seed based upon the serial number, it presents risk to customer deployments. I am keen to hear more actionable information from RSA on its recent attack. Our clients are asking us for guidance. Without knowing exactly what transpired, we have to be mindful of the worst outcome and advise accordingly.
Category: Uncategorized Tags:
2 responses so far ↓
1 Ross Macdonald March 23, 2011 at 7:58 am
The breach at RSA just goes to show that security by obscurity never works. It’s a fundamental principle in security called Kerckhoff’s principle – you must assume your enemy has the details of your system. If your authentication relies on some level of operational system “secrecy” to work, it is just a matter of when, not if, the system will be compromised. The problem with traditional shared secret tokens, outside of cost, deployment and custody issues, is that they do nothing to establish context of the mutual authentication. They are merely additional layers of “secret passwords”, regardless of how those factors are generated or delivered. Another flaw is that their use is dependent on user input into the browser, the very vehicle that has not yet established trust. The primary issue involved in this breach is the wide applicability of the “secret” elements that were compromised. In a properly architected authentication system, any security failure should be at worst, a one-in-a-row event. Clearly, a new way of thinking regarding privacy, security and identity is required that departs from the 20th century notion of shared secrets.
2 Mark Karlstrand March 24, 2011 at 12:03 am
Good points Ross. Modern security solutions must be dynamic and fully embrace a layered approach to be effective against current and future forms of attacks. The basic premise that credential based authentication (password, OTP, fingerprint, cert, iris, etc.) of any “strength” is enough protection for sensitive applications and services has been a fallacy from day one. Doing so presents a single point/points of failure and does nothing to prevent insider fraud or session hijacking. That’s not to say that credential based authentication doesn’t have it’s place in a solution but it is not a solution in itself. To truly combat all types of threats a security solution must employ layers of behavioral profiling, real-time situational risk analysis, risk-based authorization and multiple identity verification methods which can include strong authentication.