MIT Researchers Create Platform To Build Secure Web Apps That Never Leak Data 90
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."
Never say never (Score:2)
I feel like this is what they all said.
How can you search data (Score:3)
Re: How can you search data (Score:3, Insightful)
Why do you need to search or sort credit card info?
Re: (Score:1)
Why do you assume the only data stored on a server is a credit card number?
Re: (Score:3)
Re: (Score:2)
If you're using the card info purely as a primary key, then it should work just as well in an encrypted form as it would in it's original.
Re: (Score:2)
Re: (Score:2)
True, if that was part of the use case. Recurring payments weren't mentioned by the parent.
But yeah, if you *need* access to the data (any data) then it can't be encrypted only on the user side. At that point there's nothing you can do besides being dilligent in your security.
Re: (Score:2)
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.
Why do the expiration dates need to be encrypted? A thief can't do anything with just the expiration date without also knowing the CC number
Re: (Score:2)
Why do you need to search or sort credit card info?
search for upcoming expiration dates so that it can notify [customers]
Why do the expiration dates need to be encrypted?
They may not. But like credit card numbers, expiration dates are "credit card info", and notifying subscribers of cards due to expire is still "search[ing] credit card info". Besides, a store still needs to store the credit card numbers with which to charge the customer for each month, and the periodic billing process needs to store the key with which to decrypt the credit card numbers. So does the refund process for any store that sells physical goods and accepts returns.
Re: (Score:3)
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 (Score:5, Informative)
It's called "searchable" encryption. It already exists in a few commercial products.
See for example:
http://www.ciphercloud.com/tec... [ciphercloud.com]
Re: (Score:2)
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?!
Re: (Score:2)
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 mech
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
I think you don't understand what searchable encryption is. It means you can search the data without decrypting it. Once you find the records you need, you decrypt them.
The only data that is ever decrypted is the actual data that you want.
If you're like me, you probably had a brief moment of "OMG, how is that even possible?" when you first grasped it. And that is why it is an expensive software package for those who need it.
Re: (Score:1)
Re: (Score:2)
I can only see a future for private clouds.
Re: (Score:1)
A friend of mine did some work on this in grad school.
For a simple scheme, say you have a 32 bit integer as data but you store it in a 64 bit SQL field. You can come up with transformations that conserve ordering (e.g. 1 -> 15, 2 ->29, 3-> 54 and so on). You keep the key to that transformation in a local SQL proxy server and code and decode the data before sending it to the backend (in the cloud, for example). Nowadays this could be implemented in the model of your MVC application. The SQL server c
Re: (Score:2)
Well, if you're encrypting, it means the keeper of the data isn't supposed to know what it is, which means they can't do any data mining, selling, etc. of it anyway, which would be where the ability to do queries on the data would be useful. If you're encrypting everything, then all you need is to be able to find the records, and you could use hashed account names or something to index those.
So yes, it would be difficult to search/sort on the encrypted data, but then that's sort of the whole point...
I've implemented something similar (Score:5, Interesting)
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 (Score:5, Insightful)
Re: I've implemented something similar (Score:2)
Re: (Score:3)
Re:I've implemented something similar (Score:4, Interesting)
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: (Score:2)
How much of "the data" needs to be encrypted and how much can be stored unencrypted?
In a lot of applications there seems to a subset of data that is sensitive and needs to be encrypted while much of it seems like it could be left unencrypted. There may be situations where all of it needs to be encrypted, but I'm guessing that means its stored encrypted now which means its not available for dedupe or compression anyway.
Re: (Score:2)
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.
Encrypted data can be compressed...just you have to compress before encrypting.
Re: (Score:1)
So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible! This sounds like a terrible solution!
Re: (Score:2)
This.
I'd have to be on the support side of an application implementing this.
Re: (Score:2)
So what happens when your hard drive goes or you switch computers, then your data is gone because the key stored in the local storage that is no longer accessible!
Actually, that objection applies to all encryption systems. You must have a key - which must also be hard to guess, thus fairly long and random - and that key must always be available to YOU. Once you recognize the necessity, there are many ways to handle it. Two or three USB sticks, for example (in case you lose one).
More generally, the objections to this approach seem to be largely based on cost and inconvenience. That's fine: you simply have to take a view of how much security and privacy are worth to yo
Re: (Score:3)
In many cases people prefer the ability to recover their data when they forget their password over the additional security of client-side encryption.
Re: (Score:2)
So instead of keeping the password on the server, where you have some measure of control, you trust the client's unknown browser running on unknown hardware to keep it safe?
Re: (Score:2)
I'm tempted to rent a server from Amazon or DigitalOcean or whoever and put the application on it myself, so I can access my data from anywhere without dealing with advertisements and privacy concerns.
No localStorage in IE 8 (Score:2)
The password is kept in LocalStorage (a feature of HTML5)
Which breaks for businesses that have standardized on IE 8 because it's all their intranet apps support.
Re: (Score:2)
Theres a plugin that solves that problem.
Quit Using JavaScript! (Score:2, Insightful)
Stick to HTML & CSS.
Re: (Score:1)
You can do a lot with just HTML and CSS, but you're a bit small minded if you can't think of applications that need interactivity beyond basic HTML components.
And you obviously didn't RTFA, because their approach is about defending from security vulnerabilities on the server itself. Are we to stop using executable code on the server too?
JS haters want native apps instead (Score:2)
you're a bit small minded if you can't think of applications that need interactivity beyond basic HTML components.
JavaScript haters would prefer that such rich applications be made with Qt, not HTML+JavaScript.
Re: (Score:1)
JavaScript haters would prefer that such rich applications be made with Qt, not HTML+JavaScript.
So, they think that it's a good idea to go back to the days where every application had to be downloaded and given free reign to access every document on your computer?
Jailed native apps (Score:2)
So, they think that it's a good idea to go back to the days where every application had to be downloaded and given free reign to access every document on your computer?
Of course they don't. That's what Sandboxie [sandboxie.com], FreeBSD jails, a dedicated user account for each application publisher (Android's approach), and other container technologies are for.
Re: (Score:2)
If you read the article, you would find they download the signed application code and have a generic browser extension which verifies the signature of the code.
This is some what similar to what CryptoCat does, but the browser extension works only with CryptoCat.
But as their browser extension is generic then it can be made into a standard to be part of every browser, so their would be nothing to install.
/dev/null (Score:1)
/dev/null ?
Encryption alone isn't the holy grail. (Score:1)
Once decrypted, the data can be snooped on. If data can be decrypted in the browser, then the browser has everything that's necessary to decrypt it. If "Everything that's necessary to decrypt it" is provided by the server, then leaking is still possible. Browser-side decryption also makes this sound like a Javascript solution, which also means the site is potentially open to cross-site scripting attacks - if the application is not properly secured against that (and 35 lines of code hardly implies that it is
Re: (Score:2)
Re: (Score:2)
So because the NSA could install a keylogger on every gmail user's machine worldwide, google shouldn't bother to encrypt the data on their internal gmail servers where the NSA was previously snooping on all of it at once?
Of course there's always a weak point. Make that point less weak and the work to steal the data gets a little harder - maybe hard enough to defer the attacker - until the attacker adapts. Then fix the new weak point, and iterate until death.
Did this in 2005 (Score:3)
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.
Re: (Score:2)
Did you know Mozilla is building a new browser engine build in their new safe Rust language so fix that problem ones and for all ?
http://en.wikipedia.org/wiki/S... [wikipedia.org]
http://en.wikipedia.org/wiki/R... [wikipedia.org]
That method would at least eliminate all those pesky buffer overflow bugs in browsers.
What about complex sites though? (Score:1)
So, this is all well and good for really simple sites but what about larger, more complex sites that require server-side processing of data that, as I understand it, will only be available unencrypted to the client? Does this mean you need to expose your business logic on the client-side? This does not seem very secure to me no matter what promises they make about being able to detect client-side tampering...
Also, with regards to "searchable encryption", can this be applied to real search tools like Solr or
1991 called (Score:2)
hushmail (Score:2)
***** Hard to see how to avoid the hushmail scenario ***** http://www.wired.com/threatlev... [wired.com] ***** http://www.wired.com/threatlev... [wired.com] ***** https://www.hushmail.com/about... [hushmail.com] ("But I thought the data was always encrypted") *****
Re: (Score:2)
"How do I notice that the Javascript they serve me is secure, if I'm not to trust the server?"
They use a browser extension to very the signature of the downloaded Javascript code.
But their browser extension is generic, so it could be made into a standard so it will be part of the browser.
"The fact that Mozilla supports DRM now means that soon I can't even trust Firefox without any addons."
As far as I know Mozilla/Firefox does not support Encrypted Media Extensions and don't seem to have the intention to do
analog hole (Score:2)
Eventually the data has to be rendered and presented for use by the application user. I'll just screen-scrape, thanks.
--Russian hacker
Seriously? RTFM (Score:2)
The Mylar system supports searching of the encrypted data and encryption with multiple, separate keys allowing multiple users to have access to specific records without requiring any key sharing.
The server can operate in a completely compromised fashion (in theory), as the data is all encrypted on the client side, before it goes to the server, and the server will never have the plaintext or the key to decrypt the ciphertext.
They seems to be operating un
Re: (Score:2)
Re: (Score:2)
I wonder if you read the PDF, if you did you would know they use a browser extension to verify signed Javascript/HTML/CSS code.
So an attacked of the server can not modify the code unless they have the private key which is used for signing.
Re: (Score:2)
The attack they are trying to fix is a bad actor on the server.
If the software on the user's computer is compromised or the user is stupid enough to print it on paper and leave it at the desk unattended... then those kind of things are out of a web application programmer.
The real problem is eventually you have to present the clear text to the user, what the user does with the clear text isn't an easy problem to solve.
I'm glad if they at least solved the untrusted server problem.
April Fools Comes Early? (Score:2)
The performance is horrible. From t
Re: (Score:2)
First off, the encryption itself is still brute-forceable by a determined attacker with enough resources.
I realized you don't know what you're talking about right here. It would take until the heat death of the universe to brute force a 128-bit AES key.
Re: (Score:2)
I realized you don't know what you're talking about right here. It would take until the heat death of the universe to brute force a 128-bit AES key.
Seems like you're making an assumption that AES itself hasn't been backdoored and that the implementation of the same is also correct, neither of which I would assume. Steve
Re: (Score:2)
Never leaks until it does. (Score:2)
Never until it does. When will we learn?
Secure Web Apps That Never Leak Data (Score:1)
my security analysis at Schneier blog (Score:1)
https://www.schneier.com/blog/... [schneier.com]
Spoiler: it's not trustworthy but it's good work in progress.
Nick P
Security Engineer
(High assurance security focus)
Clarifications (Score:2)
To clarify all misconceptions in other posts, having been to a talk of hers a few days ago, here's the encryption types involved:
* RND (salted symmetric key encryption) - used for columns where no sql manipulation is needed
* DET (unsalted symmetric key encryption) - used for columns that need to be looked up by equality
* Partially homomorphic encryption - used for aggregation such as SUM()
* Order preserving encryption - useful for inequality where
Re: (Score:2)
Can you detail how can this support any of the features of a relational database? Filtering rows, joining tables, aggregation, ordering.