Friday, February 1, 2008

WiKID soft tokens

I promised Nick Owens at WiKID Systems a response and it is long overdue. Nick commented on my "soft tokens aren't tokens at all" post:
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!

Here is their whitepaper on their soft token authentication system.

Unfortunately, I would like to point out that WiKID is first and foremost vulnerable to the same sort of session stealing malware that Trojan.Silentbanker uses. It doesn't matter how strong your authentication system is when you have a large pile of untrustworthy software in between the user and the server-side application (e.g. browser, OS, third party applications, and all the malware that goes with it). I'll repeat the theme: it's time to start authenticating the transactions, not the user sessions. I went into a little of what that might look like.

Nick is aware of that, which is why he said point number two above. But here's the real problem: the web is designed for dynamic code to be pulled down side-by-side with general data, acquired from multiple sources and run in the same security/trust context. Since our browsers don't know which is information and which is instructions until runtime AND since the instructions are dynamic (meaning they may not be there for the next site visit), how is it NOT possible for malware to live in the browser? I submit that it is a wiser choice to NOT trust your clients' browsers, their input into your application, etc., than to trust that a one time password credential really did get input by the proper human on the other end of the software pile. I suggest that organizations should spend resources being able to detect and recover from security failures (out of band mechanisms come to mind-- a good old fashioned phone call to confirm that $5,000 transaction to a foreign national, perhaps?), rather than assuming the money they invested in some new one time password mechanism exempts them from any such problems.

Microsoft published a document titled "10 Immutable Laws of Security" (nevermind for now that they are neither laws, nor immutable, nor even concise) and point number one is entirely relevant: "Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore". How does javascript, a Turing Complete programming language, fall into that? If you completely disable script in your browser, most applications break. But if you allow it to run, behaviors you cannot control can run on your behalf. Taking Nick's advice, we should be spending all of your time and resources solving the code and data separation problem on the web, not implementing one time passwords (and I agree with him on that).



Second, I have a hard time calling WiKID a token-- not that it couldn't fit that definition-- it's just that it is a public key cryptography system. I never have referred to a PGP key pair as a token, nor have I heard anyone else. Likewise I don't really ever here anyone say "download this x509 token" ... instead they say "x509 certificate". Smart cards might be the saving grace example that allows me to stretch my mind around the vocabulary; generally speaking, a smart card is a physical "token" and smart card implementations can have a PKC key pair. So, I'll have to extend my personal schema, so to speak, but I guess I'll allow WiKID to fit into the "token" category (but just barely).

The x509 cert example is a great analogy, because under the hood that's basically how WiKID works. Just like an HTTPS session, it swaps public keys (which allows for the mutual authentication) and then a session key is created for challenge/response-- the readout of the "soft token" that the user places into the password form, for example.


There is one concerning issue with WiKID. It uses a relatively unknown public key encryption algorithm called NTRU. NTRU aims to run in low resource environments like mobile phones, which is undoubtedly why WiKID employs it. NTRU is also patented by NTRU Cryptosystems, INC (the patent may have some business/political ramifications similar to PGP's original IDEA algorithm). However, when choosing an encryption algorithm, it is best to use that which has withstood significant peer review. Otherwise, Kerckhoffs' Principle that we have come to know and love as "security by obscurity" will eat us alive when the first decent attack reduces our security to rubble. Googling for "NTRU cryptanalysis" returns around 3,000 hits. Googling for "RSA cryptanalysis" returns around 186,000-- two orders of magnitude higher. This is not the nail in WiKID's coffin, though, but it could be betting the company on Betamax. It is undoubtedly less popular than, say RSA or Eliptic Curve. In most aspects of life, supporting the underdog can result in a great time. Doing it in crypto, however, may not be a good idea.

Before somebody reads the above paragraph and goes in the extreme in either direction, please note my point: the workhorse of WiKID, the NTRU encryption algorithm, has an unknown security value. One could argue that RSA, likewise, has only a mostly known security value, but you decide: "mostly known" or "unknown"? There may not be any problems in NTRU and it may be perfectly safe and secure to use. Conversely it may be the worst decision ever to use it. That's what peer review helps us decide.


...
To sum up ... WiKID is cheap, open source, interesting, and ... still vulnerable to malware problems. And don't forget: you have to choose to use a less popular encryption algorithm.

2 comments:

Nick Owen said...

Thanks for taking the time to review our white paper and technology.
Your analogy to X509 certs is fairly accurate. I would add that instead of managing the nightmare that is white lists/black lists, we process a PIN through the keys to validate the user. This prevents an offline passive attack as the PIN must be validated on the server. It also means that user management is very simple. A few thoughts on your analysis:


1. You seem focused on online banking, which we are not. We are not targeting banks directly. We do have a great partner in Online Banking Solutions that has embedded our software in their corporate banking software, which adds a great deal of security to their solution. However, our main target market is corporate VPN/remote access. Thus, most of our (http://www.wikidsystems.com/documentation/howtos) documentation is about VPNs, SSH, Go-To-MyPC, etc.

2. You repeat the call for transaction authentication, which is something I have also (http://www.wikidsystems.com/WiKIDBlog/two-factor-phish-against-citibank-demonstrates-the-need-for-mutual-authentication and http://www.wikidsystems.com/WiKIDBlog/mitm-attacks-tokens-vs-phishing-and-mutual-authentication) espoused for some time. Moreover, because WiKID supports completely separate public keys for different domains (even on the same WiKID server) transaction authentication can be cryptographically distinct from the session authentication mechanism (http://www.wikidsystems.com/learn-more/technology/transaction_authentication).

3. The PC token clients (which support mutual https authentication) use RSA encryption. The wireless token clients use the Ntru algorithm. We considered using ECC and RSA for the wireless token clients, but because we are purists and we believed that the private keys needed to be generated on the devices, we could not. The key gen times for open source RSA and ECC algorithms were unbearable. RSA key gen on a J2ME phone was estimated to be 14 days and ECC was 14 hours! For Ntru, the key gen time is closer to 4 seconds. The Ntru algorithm was published in 1996 and has had significant review (http://www.ntru.com/cryptolab/scrutiny.htm) - none fatal. Judging a cryptosystem by the number of google hits is a bit simplistic, don't you think? There is very little interest these days (IMO) in cryptosystems because 1. it's not a very good business and 2. there is far more risk in implementation than in someone attempting to break the hard math. You may hear more about ntru if quantum computing becomes a reality as quantum computing does not seem to speed up attacks on Ntru (http://www.ntru.com/cryptolab/faqs.htm#twentyoneA). Swapping crypto for WiKID is not too difficult (we already support two algorithms and as wireless devices increase in power, we may consider that. Ntru is a great partner though and their stuff is solid. Please note that there are no commercial J2ME ECC packages - because they know that their keygen times won't cut it.

So, if I may, I would sum up WiKID this way: It is an extremely reasonably-priced two-factor solution for enterprises, with an open source version, and some interesting capabilities that are applicable to online banking, but it can't defeat malware, validate electronic voting machine result or fight hunger :).

securology said...

Nick,

Excellent comments, especially around authenticating transactions and the NTRU algorithm.