Transcript Building web applications on top of encrypted data using Mylar

Building web applications on top
of encrypted data using Mylar
Presented by
Tenglu Liang
Tai Liu
Motivation
• Web application use servers to store and process
confidential information.
• Problems
– Anyone who gains access to the server can obtain all
of the data stored there.
• Solution?
– Give each user their own encryption key, encrypt a
user’s data with that user’s key in the web browser,
and store only encrypted data on the server.
Shortcomings
1. a compromised server could provide malicious
code to the browser and extract the user’s key
and data.
2. It does not provide data sharing between users.
3. It is often impractical that all of the application
logic runs in a user’s web browser.
Mylar
• Goal: help the site owner protect the confidential
data of users in the face of a malicious or
compromised server operator.
• Computing over encrypted data
• Data sharing
• Verifying application code
Architecture
• Browser extension: Verify that the code of application has not been tampered
with.
• Client-side library: Intercepts data sent to and from the server, and encrypts or
decrypts that data.
• Server-side library: Performs computation over encrypted data at the server.
• IDP: Verify that a given public key belongs to a particular username.
Mylar for developers
• Assumption
– The web application will not send user data or keys to untrustworthy
recipient, and cannot be tricked into doing so by exploiting bugs.
– IDP correctly verifies each user’s identity when signing certificates.
– The user checks the web browser’s security indicator and the URL of
the web application they are using, before entering any sensitive data.
• Security overview
– Verify the application code running in the browser
– The client code encrypts the data marked sensitive before sending it
to the server
– Perform keyword search over documents encrypted with many
different keys
Sharing data between users
• Access graph
– Key chaining
• Certification graph
Computing the encrypted data
• Multi-key search
– Only need to provide a single search token
– Use delta to adjust one token to another.
– Enable the server to compute token by itself.
– For security, our scheme guarantees that the server
does not learn the word being searched for, and does
not learn the content of the documents.
Computing the encrypted data
• Cryptographic construction
Static Principals
• Access Control
• Certify Other Principals
-
Similar to IDP
Example: Student accounts are manually created by
staff
User Principals
• creat_user(uname, password, auth_princ)
-
auth_princ can be either static principal or IDP
auth_princ helps generate certificate
Straw Man Solution when
Sharing Data
• Rely on the server
-
Compromised server tricks the client application into
using the public key of an adversary
• Hard to prevent such attacks
-
Wrapped keys stored at the server
Mylar Solution: Certification
Graph
• One principle vouches for another
• Principles from the access graph together
with some authority principals
• Certificate chains
• princ_lookup(name1, name2,…..,namek,
root)
Data Integrity
• All encrypted data is authenticated with a
MAC
-
An adversary can still replace the ciphertext of one field with
any other ciphertext encrypted using the same key
• Solution: an authentication set of fields
-
MAC: the values of all fields in the set
Chat room application: message body, client generated
timestamp
• Roll back the whole authentication set to an
earlier version, but cannot roll back a subset
of an authentication set
Verifying Client-Side Code
• Same-origin policy
• Straw man solution: sign this code and
verify the signature in the browser
-
If an image is loaded in the context of an <IMG SRC=….>
tag
Loaded as a top-level page
Developer inadvertently includes a malicious image file in
the application
Two-Origin Signing
• The primary origin: top-level HTML file
-
Signed by site owner’s private key
Can be rolled back
• Secondary origin: all other files
-
Image, CSS style sheets and Javascript code and so on
Include a mylar_hash=h parameter in the query string, which
prevents an adversary from tempering with that content or
rolling it back to an earlier version.
Browser Extension
• Make use of Two-Origin Signing to verify
that applications are properly signed
• The site owner’s public key is embedded
in the X.509 certificate of the web server
hosting the web application
• Decrypt the signature signed by web site
owner’s
• Test whether hash(response) matches
mylar_hash=h
Performance Evaluation
• Developer effort
• Performance overheads
Developer Effort
• Average lines of code added per application:
36
• Little developer effort is required to protect
a wide range of confidential data
Latency
Overall, latency is acceptable and the
application still feels responsive
Latency and Throughput
Modest throughput overhead
Conclusion
• Keywords search over documents encrypted with
different keys
• In the presence of an active adversary, share keys and
encrypted data safely
• Verify Client-side application code
• Few changes to an application, and modest
performance overheads
• Cannot guarantee data freshness, or correctness of
query results.