MIT Researchers Create Platform To Build Secure Web Apps That Never Leak Data

rjmarvin writes: "Researchers in the MIT Computer Science and Artificial Intelligence Laboratory have developed a platform for building secure web applications and services that never decrypt or leak data. MIT researcher Raluca Ada Popa, who previously worked on the Google and SAP-adopted CryptoDB, and her team, have put a longstanding philosophy into practice: to never store unencrypted data on servers. They've redesigned the entire approach to securing online data by creating Mylar, which builds and updates applications to keep data secure from server breaches with constant encryption during storage, only decrypting the data in the user's browser. Integrated with the open-source Meteor framework, a Mylar prototype has already secured six applications by changing only 35 lines of code."

Comments

Never say never

[Anonymous Coward]

I feel like this is what they all said.

How can you search data

[CBravo]

How can you search or sort data and present it to a user when the data is encrypted? So you lose the sql storage which is essential for a web application imho.

Re: How can you search data

[Anonymous Coward]

Why do you need to search or sort credit card info?

Re:How can you search data

[gl4ss]

well.. you have all the clients connected all the time and when a search is done the server sends the search to all the clients and they decide if they want to answer that search query... ..... . .. .. ...

sounds real nice in a lab with 5 clients, right? but really shitty if you start to think about it at all.

(sure, plenty of web apps work nicely for that too because you don't do searches and only interact with a limited number of other clients..)

Re:How can you search data

[L-One-L-One]

It's called "searchable" encryption. It already exists in a few commercial products.

See for example:
http://www.ciphercloud.com/tec...

Re:How can you search data

[L-One-L-One]

Why is this even a thing? All reversible encryption (which in itself is a tautology) is searchable.

Plaintext record ID > Encryption+key+salt etc > Cyphertext record ID. Search for the cyphertext record ID. Bring encrypted record back from database. Encrypted record > Encryption > Plaintext record.

How is this a marketable product?!

Searchable encryption is more complicated than you think. For example if I encrypt the sentence "I like reading slashot" with traditional encryption I will get a block binary data that is meaningless. Now suppose I want to check if that block contains the word "slashdot"? Your "cyphertext record id" approach won't be of much help. You need a few tricks to do it correctly, notably adding some metadata and additional cryptographic mechanisms. To make things more complicated, you often need the encryption mechanism to be "format preserving": if you encrypt a string field you get a string field, if you encrypt a number field you get a number field, while traditional cryptography outputs binary data.

Note that you may have misunderstand how encryption works, if you believe that all reversible encryption is searchable. Good encryption is randomised: if you encrypt the same plaintext twice with the same key you get 2 different cypher-texts (to take your analogy, you must use different salts).

Re: How can you search data

[tepples]

An online store needs to search or sort the identities of products purchased with the credit card, as well as the shipping addresses for orders purchased with the credit card, in order to fulfill the orders. A store offering a subscription arrangement needs to search for upcoming expiration dates so that it can 1. notify each subscriber that the card on file with the store is about to expire and 2. charge the ETF on the last valid day if the subscriber fails to update the card by the expiration date.

Re:How can you search data

[Ronin Developer]

With symmetric encryption, when you encrypt with the same encryption key, you WILL get the same output that can be decrypted using the same key.

With password based encryption, you start with a passphrase and a salt, The passphrase and salt are combined and then run through a secure hash an agreed number of times. The resulting hash is the encryption key that is used with the cipher to perform the actual encryption. The salt and iteration count are why you can reuse the same passphrase.

In this context, if you alter the salt or number of iterations, you will get a different encryption key for the same passphrase and the resulting cipher text will be different. Of course, you should never encrypt using a straight block cipher but rather should use something like cipher block chaining (CBC) which uses the results of the previous encryption to seed the encryption of the next block to encrypt. This action helps to make cryptanalysis harder on the resulting encrypted code.

In simpler terms:
CipherText = Encrypt(passphrase, salt, interations, ciphermode, Plaintext).
PlainText = Decrypt(passphrase, salt, interations, ciphermode, CipherText)

I've implemented something similar

[xombo]

I've implemented a similar solution for one of my web apps.
It encrypts the data in the client with a password that they provide before it gets sent to the server. The client also decrypts the value when it receives it from the server.
The password is kept in LocalStorage (a feature of HTML5) so that it is never transmitted to the server.
Assuming the client application is not compromised, this is a great way to keep data secret even from the service operator.

Unfortunately, you won't see this scheme implemented in many apps because almost everyone's business model these days is all about scraping your data for use by advertisers.

Re: I've implemented something similar

[ModernGeek]

I agree in that this won't be implemented because of the business implications but would also go on to say that this solution is unoriginal and undeserving of all the pomp and circumstance that the media and the educational institutions are giving it, before we know it they're going to give out Ph.D's and there patents for a high school paper on using electrolysis to make hydrogen and oxygen. Call the press!

Re:I've implemented something similar

[phantomfive]

Honestly, I would be happy if every website I deal with encrypted their passwords. We still haven't passed that low bar yet.

Re:I've implemented something similar

[thegarbz]

There's another side to this too. You won't see this scheme implemented because encrypted data can not be de-duplicated, and can not be compressed. Effectively your solution increases the cost of doing business, both in terms of bandwidth and in infrastructure.

Re:I've implemented something similar

[GuB-42]

In many cases people prefer the ability to recover their data when they forget their password over the additional security of client-side encryption.

Did this in 2005

[renzhi]

Did something like this in 2005, with the data encrypted on the client side using the user's public key. The key pair is in a hardware USB token.

We also did something with this scheme for an electronic patient record project. Each doctor was issued a USB key with his/her own key pair, and when the doctor submitted any prescription to the system, the data were signed with his key, and the operation was logged into a central log database, each log record is linked to some previous log records in a Merkle tree so that we could detect if a log record has been tampered with or removed.

However, cryptography is hard to get right in applications, and clients are not willing to pay for it. Se stopped doing this after a while.