Presented by
Tenglu Liang
Tai Liu

• 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.

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.

• 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

• 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.

• 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

• Access graph
– Key chaining
• Certification graph

• 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.

• Cryptographic construction

• Access Control
• Certify Other Principals
Similar to IDP
Example: Student accounts are manually created by staff

• creat_user(uname, password, auth_princ)
auth_princ can be either static principal or IDP
auth_princ helps generate certificate

• 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

• One principle vouches for another
• Principles from the access graph together with some authority principals
• Certificate chains
• princ_lookup(name
1
, name
2
,…..,name k
, root)

• 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

• 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

• 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.

• 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

• Developer effort
• Performance overheads

• Average lines of code added per application:
36
• Little developer effort is required to protect a wide range of confidential data

Overall, latency is acceptable and the application still feels responsive

Modest throughput overhead

• 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.