Slashdot Mirror
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."
I feel like this is what they all said.
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.
nosig today
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.
Stick to HTML & CSS.
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), it all comes tumbling down.
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.
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 ElasticSearch?
So basically this is PGP, it's pgp for the web, but ultimately still PGP. How is this even remotely newsworthy? PGP is 23 years old, throwing it up on the web then calling what you are offering a "web service" is a joke. Real web services actually offer you know, services, beyond simple data retrieval, and I saw nothing in the paper that would allow for instance a server to scan a database table with user information in it in order to present the data in a useful fashion, or for the data to be useful at all beyond a pgp-encrypted file sharing/email service.
Monstar L
***** Hard to see how to avoid the hushmail scenario ***** http://www.wired.com/threatlev... ***** http://www.wired.com/threatlev... ***** https://www.hushmail.com/about... ("But I thought the data was always encrypted") *****
http://stephan.sugarmotor.org
Eventually the data has to be rendered and presented for use by the application user. I'll just screen-scrape, thanks.
--Russian hacker
I want to delete my account but Slashdot doesn't allow it.
Am I the only one who read the read the article?
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 under the assumption that it is much harder to compromise all the clients than a single server...unfortunately I don't think that claim holds up as there is nothing to prevent compromise of the clients if the server is compromised, via simple XSS-like attacks, which will be trivial since it will be same-origin.
IMHO, the only way to make something like this really work, would be hardened browser clients, with special encryption APIs which cannot be directly accessed by code that the server can inject (NOT JavaScript).
It's a few days early for the April Fools edition of Slashdot. I'm sure the MIT researchers in question think they really have something here but it would be nice if they would've looked around before beginning their research. It seems as though this system connects to a server which then sends back encrypted data. That data is then decrypted at the local client. And they made a browser plugin for it. How is this fundamentally different than public key encryption?
The performance is horrible. From the Mylar web site, "a 17% throughput loss and a 50 msec latency increase for sending a message in a chat application." A 17% throughput loss and 50ms latency is *huge* for something as trivial as a chat application. Imagine what happens when real data is being crunched.
There are still enough attack vectors that make this a non-starter. First off, the encryption itself is still brute-forceable by a determined attacker with enough resources. Second, it assumes a secure client environment. Finally, it assumes that your adversary plays by the rules and won't inject malicious code or backdoors into the software or encryption, with or without a complicit service provider. The client code can check authenticity? Cute, but only works if your adversary doesn't "require" that the service provider comply with a secret order to say that the code is authentic, even when backdoored.
Steve
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.
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.
Never until it does. When will we learn?
so far.
Circle the wagons and fire inward. Entropy increases without bounds.
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, FreeBSD jails, a dedicated user account for each application publisher (Android's approach), and other container technologies are for.
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.
It doesn't hurt to be nice.
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.
New things are always on the horizon
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...
http://en.wikipedia.org/wiki/R...
That method would at least eliminate all those pesky buffer overflow bugs in browsers.
New things are always on the horizon
"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 so.
New things are always on the horizon
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.
New things are always on the horizon
I've done an analysis based on what's in their paper and posted it to Schneier's blog. Link below.
https://www.schneier.com/blog/...
Spoiler: it's not trustworthy but it's good work in progress.
Nick P
Security Engineer
(High assurance security focus)
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 clauses, indexes, aggregations such as MIN()
* Searchable encryption - allows something like ILIKE on text columns
OPE is the most dangerous, but is rarely needed for the most sensitive fields. They've run CryptDB on top of phpBB and
some other thngs with acceptable overhead. Let me know if you have other questions.
Can you detail how can this support any of the features of a relational database? Filtering rows, joining tables, aggregation, ordering.