April 20, 2011

DropBox, Security, Encryption, FIPS 140-1 and Illusions

Lately there has been some brouhaha on the Interwebs about the lack of proper security on the DropBox application. Users are rather incensed that they were told their data was securely encrypted, only to find out later that the encryption keys themselves were store in the databases at DropBox in a recoverable manner.

One of my pet peeves is when people ask me whether a product is FIPS 140-2 compliant. The question is so specific, and means one very specific thing is implemented correctly, the algorithm that implements the AES encryption and decryption activity itself. However, the question does not touch on whether or not the implementation of that encryption is done correctly. FIPS 140-2 compliance is something I would expect any graduate programmer to be able to accomplish in an implementation of AES.

What is missing is the secure implementation and design of the product that utilizes the AES algorithm, most notably the secure implementation of the key storage. For simplicities sake, imagine that AES is a specification of lock mechanism and encasement. When you lock up your secrets in this encasement, it is protected by one thing - the key. Where do you put the key to protect it? How do you share the key with others who may need it? How do you store it in a place that you can get to it from whatever device you're accessing it from, including the web and mobile devices.

Users of Dropbox made an assumption that the security of the encryption key was secured by the password that protected their Dropbox account. I, myself, made the assumption that Dropbox uses an algorithm such as PBKDF2 to create the key to protect my files at Dropbox. Of course, there was a point that I missed - if Dropbox were to do this, my files would be unrecoverable if I ever forgot my password. And obviously, some engineer at Dropbox had figured on this as well, because Dropbox can do password resets while my data can still be recovered. And thus, the slippery slope begins....security weaknesses introduced to account for the weakness of the weakest link.....the fallibility of the user. Dropbox implemented a solution whereby they store my key for me rather than make it unrecoverable. SHOCK!! DISMAY!! There's even more to the story, because other compromises were made as well in the interest of convenience, according to other accounts I've read, including generating unique security keys for each device that allowed them to authenticate to my dropbox without even my current password. This last piece, I don't even see as 'user-convenient' because it puts the onus on the user to remember to lock out any device that they've lost control of (and they may not even know they've lost control of the device!!).

The illusion of security in products that the mainstream uses is often touted as secure and covered with all kind of marketing like 'FIPS 140-2 Compliant'!! However, the reality is that true security will always get back to the security of the key. If you want to evaluate the true security of a device or a security implementation, there's a simple checklist the consumer can ask himself when buying the device:

1. Identify the 'key' that gives you access to your stuff.
This could be a password, a 'smart card' or a SecurID token.

2. Can I store my key to allow me to access without asking me every time?
The answer needs to be NO. If your devices store your key without you having to enter it (or provide something external like a secure token), the key isn't really the key, or it's replicated in the implementation. You don't want copies of your key being stored.

3. If I lose my key, is there a mechanism for me to recover my key that does not require another, perhaps more secure, key?
The answer needs to be NO. The key needs to actually be a part of what is needed to unlock the lock. If you can lose your key but still access the data later without it, it wasn't really the key - it was a token to get your key. Key Recovery is a whole practice in and of itself. Sure, we can encrypt and store your key info - but now we need to make sure that's locked up just as tight, if not tighter than the original data.

4. Can key recovery be done without my participation (providing the more secure key)?
The answer needs to be NO!! Again, if your data can be unlocked without you providing the key or an alternate key - it's not really the key at all! It's just a laundry ticket to pick up your key.

Those four questions are a good start - and there's even more to think about for advanced users (e.g. Can the key be used on the data without the system itself?)

Don't fall for the illusion - ask yourself these questions to get a feel for how secure your 'encrypted' data is. Then ask yourself which you want, convenience or lock-it-up-and-swallow-the-key security. If history is any indication - you'll choose convenience. I may still be a DropBox user, but my truly private data is encrypted before I store it there. Let's hope I don't get Alzheimer's and lose THAT key.

No comments: