Something you knowPhysical hardware tokens, like RSA's SecurID, fall into the second category of "something you have". Software tokens, also like RSA's software SecurID, pretend to fall into that same category ... but they are really just another example of "something you know".
Something you have
Something you are
Physical tokens are designed to be tamper resistant, which is an important property. By design, if a physical token is tampered, the internal storage of the token's "seed record" (symmetric key) is lost, in an attempt to prevent a physical attacker from duplicating the token. [Note the words "tamper resistant" not "tamper proof".]
Soft tokens, however, do not share this property. Soft tokens are comprised of two components: 1) the software application code that implements the one time password function and 2) the seed record used in the application to generate the one time password function's output.
"Perfect Duplication" is a property of the Internet/Information Age that is shaking the world. The Recording/Movie Production Industries are having a hard time fighting perfect duplication as a means to circumvent licensed use of digital media. Perfect duplication can be a business enabler as well, as it is with news syndication services that distribute perfect copies of their stories throughout the far reaches of the world in a matter of seconds. In the case of soft tokens, though, perfect duplication is a deal breaker.
Soft tokens are designed to be flexible. It's difficult to provision a hardware token to an employee halfway around the world the same day of the request, but with soft tokens provisioning is a piece of cake. Likewise, it's easier to recover soft tokens when that same employee is terminated. Soft tokens run on virtually any platform. RSA supports everything from Windows Desktops to Browser Toolbars to Mobile Devices-- all you need to do is import the seed record.
There's the rub ... Distributing the seed record requires a confidential channel to ensure that it is not perfectly duplicated in transit. Distributing seed records to many of the supported platforms of soft token vendors involves plaintext transmission, such as sending the seed record as an email attachment to a Blackberry client. An administrator may provision the seed record encrypted using an initial passphrase that is distributed out-of-band, but it is common practice for seed records and initial passphrases to be distributed side-by-side. Whereas a physical token can only be in one place at a time, a soft token could be perfectly duplicated by an eavesdropper, even complete with its initial passphrase (especially when it isn't distributed out of band). If Alice receives her soft token and changes its passphrase, Eve could keep her perfect copy with the intial passphrase or choose to change the passphrase-- either way, the back end of the one-time-password authentication system will receive a valid token code (time value encrypted with the seed record).
Likewise, a soft token employed on a malware-ridden remote PC could have its stored contents uploaded to an adversary's server, capturing the seed record. If the malware also captures keystrokes (as software keystroke logging is so common these days), then another opportunity for a perfect duplicate exists. Soft tokens are vulnerable to severe distributed key management problems. Bob (the administrator in this case) cannot know if the one time password was generated by Alice's soft token application or Eve's perfect duplicate.
In short, a soft token can prove a user "has" the token, but it cannot prove the user exclusively has the only copy. Therefore, soft tokens are not truly "something you have"; they are "something you know" (i.e. the passphrase to unlock a seed record).
For organizations seeking soft tokens as a method of achieving multi-factor authentication, a password plus a soft token is simply two instances of "something you know". Thus the organization must ask itself: "Does the complexity of properly distributing seed records in a secure channel as well as the expense of managing and supporting the software token application code really provide sufficient benefit over a simple--yet strong-- password only method?" My prediction is the answer to that question will be: "No, it doesn't".
...
UPDATED 12/11/2007 - Sean Kline, Director of Product Management at RSA, has posted a response [Thanks for the heads up]. Perhaps we will have some interesting dialog.
4 comments:
Hi,
Great piece! I wanted to let you know that RSA's Sean Kline has published a response to this blog.
Sean's blog entry
Greetings. I too have posted a response on my blog. It just points out that our software tokens use public key encryption and not a symmetric, seed-based system. This pushes the security to the initial validation/registration system where admins can make some choices about trade-offs.
Second, I submit that any device with malware on it that successfully connects to the network is bad. So you're better off saving money on tokens and spending it on anti-malware solutions, perhaps at the gateway, defense-in-depth and all.
Third, I point out that our PC tokens provide https mutual authentication, so if you are confident in your anti-malware systems, and are concerned about MITM attacks at the network, which are increasingly likely for a number of reasons, you should consider https mutual auth in your two-factor thinking.
Here's the whole thing:
On the security of software tokens for two-factor authentication
and thanks for stimulating some conversation!
Hi Nick,
Thanks for dropping by.
I am not familiar with your WikID solution, but I found a WikID Whitepaper Download on Sourceforge, so I'll review it and your code and hopefully post a follow-up on how your solution is better (or not, whichever the case may be ;).
Your second point is dead on: malware is a show stopper. In that case, how can any organization make a trust decision regarding the trustworthiness of a remote user (whether employee, business partner, or customer), since all of the popular OSes upon which these critical software functions reside or so fundamentally flawed-- they all have separation of code and data problems. I think that's what Dan Geer was getting at with his suggestion to rootkit your customers for secure transactions (although I think there are some faulty assumptions in using one-time-use rootkits, such as rootkits trumping rootkits).
Third, I'm not convinced (at least not yet) that mutual auth can guarantee that a transaction is free from MITM attacks. If a MITM sits in the browser (ala browser rootkits) information can be stolen and transactions can be forged ... even with mutually authenticated public key crypto and a reasonably intelligent end-user.
I enjoy the conversation, so let's keep it going!
Please note that I was careful to say 'network-based MITM attacks' :). I think given today's technology, combining mutual authentication with a defense-in-depth approach to malware (on the client and the gateway, basically) is the best you can do as a corporation. I think that is a reasonable trade-off of risk for the benefits of remote access.
The man-in-the-browser is a tough one for financial transactions (and this is very different from the corporate remote access scenario). The use-once rootkit might help. I also think that an out-of-band digital signing mechanism will be necessary in the long run. We've thought about extending our wireless token client to do that, but are really focusing on the corporate vpn market at this time (mostly due to the PCI requirements for two-factor authentication).
If you want some more whitepapers, you can email me at nowen at wikid systems .com. And don't worry, we don't have spamish marketing system.
Post a Comment