How does Mylar ensure encrypted data remains secure even if the live app code is compromised

Question

Because Mylar does the decryption in the browser, the key is never stored on the server. Nice. This moves the threat to the browser, where, if the attacker is able to get a malicious script to be served to the browser along with the Mylar related app/data, then the script could just harvest the decrypted data.

So, how does Mylar ensure the app code that is served to the browser isn't malicious?

I see in this document: http://www.mit.edu/~ralucap/mylar.pdf

Verifying application code. With Mylar, code running in a web browser has access to the user’s decrypted data and keys, but the code itself comes from the untrusted server. To ensure that this code has not been tampered with, Mylar checks that the code is properly signed by the web site owner. This checking is possible because application code and data are separate in Mylar, so the code is static. Mylar uses two origins to simplify code verification for a web application. The primary origin hosts only the top-level HTML page of the application, whose signature is verified using a public key found in the server’s X.509 certificate. All other files come from a secondary origin, so that if they are loaded as a top-level page, they do not have access to the primary origin. Mylar verifies the hash of these files against an expected hash contained in the top-level page.

So an app code hash/signature is checked. Nice, assuming this hash/signature hasn't been compromised we can know the codebase is valid against a specific release. I also see that Mylar uses two origins. What if both origins are compromised? Also, could one of the origins be a specific git repo commit hash? What are the possible issues with somehow interfering with this verification step?

I'd love to understand more about how this specific security feature works and how it is secure.

Answer 1

Mylar requires using Meteor. Because of the separation of data and format in the Meteor framework, it can actually sign the application template. In a normal web app the browser receives the concatenation of the data and the presentation as one element; in a dynamic web app you can not sign the page because you don't know what the output will be at run time.

If the attacker doesn't also have the ability to sign the files being served, an error will happen because the signatures are not valid. If the attacker has the ability to impersonate the legitimate user for signing purposes, that's almost as bad as having the root CA keys in the PKI world, game over.