Securing user's data against an attacker that may gain server root

Question

I'm designing a web application that is going to handle very sensitive data, storing it on behalf of its users. A kind of online safe, if you will.

A user's secure data should only be visible to her, not even to the server software or owner. This opens the way to robust security practices, such as using an end-user password to directly encrypt/decrypt her data, or better, to encrypt a symmetric key used to encrypt her data. The latter would allow changing one's password without re-encrypting all the records on the DB.

Can I ensure an attacker cannot gain access to the protected data, even if they were to obtain root access to my server?

I came up with the notion that I need to encrypt/decrypt the user data on the client side. Modern browsers and hardware make it possible for the user's password and encryption key to never leave her browser. All other techniques I can think of have fatal flaws, whereby an attacker could read the memory of my running server software and find the encryption key.

But then, how can I avoid the attacker planting a web bug into my website, or just changing my client-side script, to send the users' encryption keys their way?

Is there a technology, supported by one or more browsers, where I can require all my website's client-side scripts to be signed with some certificate of mine? For the sake of this question, assume my users trust me to write good software, so they would trust my certificate.

Is there a browser extension that does such checks, that I could recommend my users to install?

In case there is not, how is this threat approached in the industry? Is auditing the only solution? For example, checking my website periodically from external IPs, to make sure that the client-side scripts have not changed cryptographic hash.

Should I forgo the notion of doing something like this with open web technologies and solve the issue by using a trusted software distribution system such as Apple / Google app stores? Would this just move the issue to somebody else's server, or does it actually address the underlying problem?

Can you recommend any good practical books / blogs / articles on the subject?

Answer 1

Perhaps one of the most interesting case studies of exactly this type of situation is www.blockchain.info, which employs client-side encryption and obviously has a lot at stake: the contents of millions of users' bitcoin wallets.

Their initial approach was a browser extension that verified the website's source assets against a predefined list of hash sums: http://web.archive.org/web/20120905110346/http://blockchain.info/wallet/verifier. This approach lasted for a year or two, when it was deprecated in favor of a browser extension that packages their entire client-side codebase in the extension itself.

Unfortunately I can't find a blog or article from them explaining this change, but googling for these terms will find you comments that suggest the "verifier" approach was not entirely bullet proof.

The extension approach certainly reduces the attack vector as the code responsible for the client-side encryption is only downloaded once, and additionally because app stores such as the Chrome Web Store or Google Play require updates to be signed with the same key as the initial version, ensuring that updates can't be tampered with - of course assuming that you manage to keep your private key secure, and that no exploits are found against the browser or app store platform.

You would definitely be interested in reading the famous "Javascript Cryptography Considered Harmful" article and the many follow-ups and rebuttals out there: http://matasano.com/articles/javascript-cryptography/

Answer 2

The problem with a browser extension approach is that many users would be either unwilling or enable to install it (eg logged in at their place of work they would not be able to install extensions). You also have to securely distribute the extension which is a problem itself.

One online banking approach I have seen the bank puts a custom browser bin/exe onto a credit card sized CD-ROM or USB stick. Each browser has user unique SSL keys and is run off of the read-only media. The webserver can then verify the browser connection belongs to the specific client. It could also have custom plugins to verify web resources.

These day's something like Apache Cordova or PhoneGap which packages HTML+JS into mobile apps built for all mobile platforms is probably a sweets spot. I am a customer of HSBC and their app looks and feels to be such packaged HTMl+JS app. It will do "downloading updates" occasionally when the app opens (which native mobile apps do not do) possible downloading new web resources into local storage. All App Store apps are signed and breaches of the big Apple or Google stores would be big news and quickly patched. They can afford more audits and will get more white hat attention than you going it alone.

You could run SRP password protocol rather than send the password in plain text. See Can I use the same password both for SRP and for client-side encryption? Text message the user a four digit code to enter as they try to login and you will also have two factor authentication.

If you cannot go the Cordova route and your uses insist in using arbitrary web browsers then, well, the risks are that their machine is full of viruses and is unpatched. You can patch your servers, pay for penetration testing, and subscribe to a service which monitors for fake sites, similar DNS registrations, poisoned DNS, phishing emails etc. NetCraft provide such a services. Internally you can run opensource tripwire to verify the hashes of all the files on your frontline boxes to confirm no root kits or web bugs have been uploaded. If the user has a compromised PC running a keyboard logger or a jail broken phone then there is nothing you can do for them. Running SRP, two factor authentication, client-side encryption and opensource tripwire intrusion detection on your website may be good enough.