Frank Wang Talk – Sieve – System For Secure, Delegated Web Access

Sieve – System for Secure, Delegated Web Access

In today’s web, one user uses multiple services
Data’s spread out across everything (Name, Address, Phone, etc)

Problems:
Updates are difficult & user unfriendly
Sharing data among services is almost impossible
OAuth is broken – How people log into 3rd party services using FB
Sharing data can be useful in the world of wearables
The user technically owns her data, but has no control over how that data is being accessed

Solution:
Users manage their own data
Store their data like profile, etc are in their own cloud storage
Instead of storing their own data, web services interact with the Cloud Server for accessing & storing info
Not that far fetched

Challenges:
Penalty of a server compromise is larger
-Data’s not spread across multiple service providers
How to enforce access control?
Selectively expose data to the correct web services
We know how to do one of the two (prevent against compromise via encryption, access control), but it’s nontrivial to do both
Encryption to prevent server compromise
ACLS to enforce access control
Minimal user interaction to reduce depence on user for each data

Sieve:
new system for secure delegation that addresses above challenges

Threat Model
User is trusted
Cloud storage can be compromised
confidentiality and integrity
no guarantees on freshness and availability
A third part web service can be malicious
-Only reveal data that the user has agreed to disclose

How do we encrypt data and enforce access control
Normal symmetric encryption like AES is not sufficient
just encrypts but still has control issues
How do we selectively expose data to web services (Only give decryption rights to appropriate web service)
Access control issue
Uf server is compromised, can’t trust it

Attribute-based Encryption (ABE)
Normal encryption All of nothing
in ABE, your  decrypt key has a policy associated with it
in Conjunctive Normal Form/Disjunctive Normal Form – similar to SQL (can do ands and ors)
Cyphertexts have attributes associated with them (year, name, etc)
if attributes of ciphertext satify the key policy, the ciphertext can be decrypted
(reverse: policy can be on ciphertext & attributes can be on key)

Application of ABE and its properties
Easy Access control:
put attributes on data & give decrypt key with policy to web serive
Number of policies scales with number of web services
Policy generation is decoupled from object generation (just add tags to it)
Collusion Resistant
-If multiple parties collude, they can decrypt data only if one of the parties can already decrypt
Cryptographically strong guarantees of access control and encryption!

ABE is public key – similar to RSA
Anyone can encrypt
Public key encryption schemes are substantially slower than symmetric key encryption schemes, like AES
Solution: use hybrid encryption
Encrypt AES key with ABE, and encrypt data with that AES key

Notes:
once the web service receive data, Sieve has no control over what happens to it
Also provide an installed application model
Local program that strictly regulates data flow btwn. provider & local program
Similar to a desktop version of Slack
Access revocation is tricky
Scheme if you trust cloud provider at the time of revocation

Sieve is new access control system for web apps
User data is decoupled from apps & protected by ctryptographically strong

http://www.frankwang.org

Questions:
***I missed the first question – sorry***

Turning foxonomy into really useful taxonomy
Users already naturally interact with the data
If we tried to change that, nobody would adopt

Question: How does the ABE work in the math sense
You will give one key to each provider, each can decrypt a subset of the data

Answer: That changes every conference you go to
With a lot of crypto, the math itself changes
Multiple ABE Schemes
Latices
Bilinear Maps
Internal Tree structure, and they do stuff internally

Question: How is the user expected to store the key?  What happens if computer is compromised, or key is lost?

Answer: User generates keys on the fly, There’s usually a master key & if you lose that, you’re screwed.
This is why part of the threat model is that the user is trusted

Question: How do you handle ambiguous names.  Ex: I have uploaded a bunch of stuff to my cloud provider & there’s discrepancies btwn. the name I used there & fb … how do you handle those
Is there a notion of data types/etc

Answer: We abstract that away.  That’s mostly the application’s job.  If the app doesn’t get it right, or tries to mess with logic, API is too tied to data, and that creates security/mess issues.

Question: If user creates policy on the fly, how are all these keys generated, and where does it happen

Answer: AES key is random.  You generate it & then encrypt your data using ABE

Question: Does that mean that for every subset of data/key/policy that you generate, is there a different AES key?

Answer: No.  The hybrid encryption tries to take away the overhead used by ABE (it’s too computationally expensive otherwise).
All the web service sees is that it needs to decrypt the AES key, and then it uses the AES key decrypts the data.

Each data block is encrypted with AES keys.  Those are all encrypted with ABE.  This is the same as encrypting directly with ABE

Question: To update tags – how does that work

Answer: download the hybrid key, modify it & then re-encrypt with ABE

Question: How do I keep track of my data policies and whether I’m sending info to certain companies that I don’t want to

Answer: Either revoke access or encode new tag with ABE tag

Question: Is there a practical limit on number of tags, verbosity of policies, etc

Answer: It’s secure as many tags as you want.  The performance increases [Does this mean it’s more computationally expensive?  Or that it’s more efficient] with the number of tags & policies you create

Question: What Challenges…

Policy Issues: How do we force applications to buy into this?
We have a good story for Ads
You can selectively expose your data to Ad Networks now
If you don’t want to, you can pay money to the cloud provider directly & they won’t share them

Dealing with multiple users & they want to communicate with each other
P2P is really hard … it’s not provider to provider
You don’t want the other person to learn your data in a P2P sense
Secure multi-party permutation
Maybe you don’t want one provider, but want 10 instead

Question: If you don’t store the keys locally, can you figure out what services have access to that

Answer: You must store some information (policy metadata) locally – You don’t necessarily have to store the keys themselves
Can match the tag against the policy in order to check this

Question: Is there a provision for the service provider being able to upload or make changes to your data on your behalf

Answer: We don’t really allow that
Key Revocation: We assume the SP can make changes on your behalf
The cloud server can’t, but web services can
You run into a problem with integrity (is it from the user or not)
Under Sieve, the User signs their data. – They can give that service their own special key, or just the user’s key

Question: You mentioned ABE as similar to SQL.  If a web service provider (Facebook) asks for all photos from 2012 & I don’t want to upload a specific subset of those photos, will the web service know?

Answer: You have to specify that in the tag

Question: Does the web server know it’s not getting all the data it wanted?

Answer: It can see it in clear text currently, but you could encrypt that, and then it wouldn’t know.  This hasn’t been a huge issue yet.

Question: Can you do “Not” Policies?

Answer: Yes

Question: Would it solve some of the revocation issues if you had every provider have a provider-specific policy using “Not Facebook”

Answer: We thought about it, and if you start revoking web services, it doesn’t scale very well, and then you have bizarrely long tags
Revocation doesn’t happen a lot, but you can re-encrypt & decryption happens a lot

Question: Let’s say you have an object called name & an object called Alias.  Is there a way to map Facebook’s schema so that it directs to your Alias instead of your Name (when it wants your name)

Answer: We assume people agree on a schema so there isn’t all this redirection stuff.  When you start messing around with these APIs, they get more closely tied to the Data.  It creates too many problems & mess & makes everyone’s life harder.

Question: Let’s say there’s an identity schema.  You could have two objects that implement that schema & you could choose which one actually matches that policy.

Answer: Yeah, you could do that.

Question: Could user Signup for Service & then switch their information after the fact?

Answer: That would be difficult, because then you’d have to change your FB key, and it could still learn your new information pretty easily.
You’d probly have to use some revocation of the tags & not give Facebook permission

Question: If you have one-time use data, what do you do?

Answer: Just give it a specific policy & give it just to the specific provider.  Give them a tag that’s specifically their data & then tag data you don’t want them to see.

Question: How do you manage expiration of keys?  Is there a standard expiration?

Answer: You can put a timestamp on your data whenever you create it.  In your policy, you can specify a time in the future (can only access if time < xyz).  When Key expires, they can’t access newer data, but can access older data.  Most data is versioned anyway.  Revocation scheme allows storage providers to re-key data.  You can operate on the key without actually decrypting the data

Question: Attributes & Policies … when would you want to switch the encryption/access policy

Answer: Medical Data, HIPA law.  When you issue the key, you give different roles to different personnel.  Those are different attributes on the key.
Attributes = role definition

Question: Do attributes being modifiable create unintentional access?

Answer: Attributes are tied into encryption.  Attributes in the clear just makes it easier to see if they decrypt it.  It doesn’t allow unintentional access

Question: As someone who trusts google to get security policies better than themself, how do you account for this?

Answer: The point is, I’m trusting the local machine insomuch as I’m saying … The Threat Model I’m looking at is people targeting data (Rather than machines) … If that swapped, it might be easy to hack into your computer.  Data seems more valuable at present.  Stealing master key takes a lot more work.

Question: If Master Key is compromised??

Answer: It’s definitely an issue.  The point is that prior to that happening, your data is well-protected.

Question: … ***I spaced out***

Advertisements
Frank Wang Talk – Sieve – System For Secure, Delegated Web Access

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s