Sieve: Cryptographically Enforced Access Control for User Data in - - PowerPoint PPT Presentation

sieve cryptographically enforced access control for user
SMART_READER_LITE
LIVE PREVIEW

Sieve: Cryptographically Enforced Access Control for User Data in - - PowerPoint PPT Presentation

Sieve: Cryptographically Enforced Access Control for User Data in Untrusted Clouds Frank Wang (MIT CSAIL) , James Mickens (Harvard), Nickolai Zeldovich (MIT CSAIL), Vinod Vaikuntanathan (MIT CSAIL) 1 Motivation Boston Marathon NY Marathon


slide-1
SLIDE 1

Sieve: Cryptographically Enforced Access Control for User Data in Untrusted Clouds

Frank Wang (MIT CSAIL), James Mickens (Harvard), Nickolai Zeldovich (MIT CSAIL), Vinod Vaikuntanathan (MIT CSAIL)

1

slide-2
SLIDE 2

Motivation

2

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

slide-3
SLIDE 3

Motivation

2

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

slide-4
SLIDE 4

Motivation

2

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

slide-5
SLIDE 5

Motivation

2

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-6
SLIDE 6

Problem: Curious storage provider or external attacker

3

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-7
SLIDE 7

Problem: Curious storage provider or external attacker

3

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-8
SLIDE 8

Naïve Approach: Encrypt Data under 1 key

4

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-9
SLIDE 9

Naïve Approach: Encrypt Data under 1 key

4

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-10
SLIDE 10

Naïve Approach: Encrypt Data under 1 key

4

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-11
SLIDE 11

Naïve Approach: Encrypt Data under 1 key

4

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

How does the user selectively disclose her data?

slide-12
SLIDE 12

Another Approach: Encrypt each piece of data individually

5

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-13
SLIDE 13

Another Approach: Encrypt each piece of data individually

5

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-14
SLIDE 14

Another Approach: Encrypt each piece of data individually

5

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-15
SLIDE 15

Another Approach: Encrypt each piece of data individually

5

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-16
SLIDE 16

Contributions

  • Sieve: a new platform that allows users to

selectively and securely disclose their data

– Sieve protects against server compromise – Sieve hides key management from users – Reasonable performance – Sieve supports revocation – Sieves allows users to recover from device loss – Good for web services that analyze user data

6

slide-17
SLIDE 17

Outline

  • Sieve

– Protocol – Optimizations – Revocation – Device Loss

  • Implementation
  • Evaluation

7

slide-18
SLIDE 18

Sieve Overview

8

slide-19
SLIDE 19

Sieve Overview

8

Storage Provider User Web services

slide-20
SLIDE 20

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

slide-21
SLIDE 21

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial

slide-22
SLIDE 22

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial

slide-23
SLIDE 23

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness )

slide-24
SLIDE 24

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness )

slide-25
SLIDE 25

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness

slide-26
SLIDE 26

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness

slide-27
SLIDE 27

Sieve Overview

8

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness

slide-28
SLIDE 28

Threat Model

  • Storage provider is a passive adversary

– Adversary can read all data – Follows protocol

  • Web services trusted with user data they are

given access to

  • User and her devices trusted

9

slide-29
SLIDE 29

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

slide-30
SLIDE 30

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

slide-31
SLIDE 31

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

Policy: (Year < 2013

AND type=Fitness)

private

slide-32
SLIDE 32

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

(Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private

slide-33
SLIDE 33

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

(Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private Attributes:

Location=US, Year=2012, Type=fitness

public

slide-34
SLIDE 34

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private Attributes:

Location=US, Year=2012, Type=fitness

public

slide-35
SLIDE 35

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private Attributes:

Location=US, Year=2012, Type=fitness

public

slide-36
SLIDE 36

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private Attributes:

Location=US, Year=2012, Type=fitness

public

slide-37
SLIDE 37

Our approach: Attribute-based encryption (ABE)

  • Assume that user-specific ABE public/private key pair
  • Three main functions

10

GenerateDecKey Encrypt Decrypt

Note: attributes and policy are in cleartext

Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness (Year < 2013 AND Type=Fitness )

Policy: (Year < 2013

AND type=Fitness)

private Attributes:

Location=US, Year=2012, Type=fitness

public

slide-38
SLIDE 38

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

slide-39
SLIDE 39

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial

ABE Encrypt

slide-40
SLIDE 40

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial

ABE Encrypt

slide-41
SLIDE 41

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness )

ABE Encrypt ABE GenerateDecKey

slide-42
SLIDE 42

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness )

ABE Encrypt ABE GenerateDecKey

slide-43
SLIDE 43

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness

ABE Encrypt ABE GenerateDecKey

slide-44
SLIDE 44

Sieve with ABE

11

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

Location=US, Year=2012, Type=fitness Year=2015, Type=financial (Year < 2013 AND Type=Fitness ) Location=US, Year=2012, Type=fitness

ABE Encrypt ABE GenerateDecKey ABE Decrypt

slide-45
SLIDE 45

Challenges with ABE

  • Performance
  • Revocation
  • Device Loss

12

slide-46
SLIDE 46

Reduce ABE Operations

  • ABE is a public-key cryptosystem so slower

than symmetric key cryptography

  • Optimizations

– Hybrid Encryption – Storage-based data structure

13

slide-47
SLIDE 47

Hybrid Encryption

14

slide-48
SLIDE 48

Hybrid Encryption

14

symmetric

slide-49
SLIDE 49

Hybrid Encryption

Data

14

symmetric

slide-50
SLIDE 50

Hybrid Encryption

Data

14

symmetric ABE symmetric GUID

slide-51
SLIDE 51

Hybrid Encryption

Data

Metadata block

14

symmetric ABE symmetric GUID

slide-52
SLIDE 52

Hybrid Encryption

Data

Metadata block

14

symmetric ABE symmetric GUID

Index Attr1 Attr2 Attr3 Attr4 Attr5

meta meta meta meta meta

Index

GUID1 GUID2 GUID3 GUID4 GUID5

data data data data data

slide-53
SLIDE 53

Hybrid Encryption

Data

Metadata block

14

symmetric ABE symmetric GUID

Index Attr1 Attr2 Attr3 Attr4 Attr5

meta meta meta meta meta

Index

GUID1 GUID2 GUID3 GUID4 GUID5

data data data data data

slide-54
SLIDE 54

Hybrid Encryption

Data

Only have to perform symmetric key operations in future

Metadata block

14

symmetric ABE symmetric GUID

Index Attr1 Attr2 Attr3 Attr4 Attr5

meta meta meta meta meta

Index

GUID1 GUID2 GUID3 GUID4 GUID5

data data data data data

slide-55
SLIDE 55

Storage-based data structure

  • Extension of hybrid encryption

15

slide-56
SLIDE 56

Storage-based data structure

  • Extension of hybrid encryption

15

Data

symmetric

Data

symmetric

Data

symmetric

slide-57
SLIDE 57

Storage-based data structure

  • Extension of hybrid encryption

15

Data

symmetric

Data

symmetric

Data

symmetric

GUID GUID GUID

symmetric

slide-58
SLIDE 58

Storage-based data structure

  • Extension of hybrid encryption

15

Data

symmetric

Data

symmetric

Data

symmetric

GUID GUID GUID

symmetric ABE symmetric GUID

slide-59
SLIDE 59

Storage-based data structure

  • Extension of hybrid encryption

15

Data

symmetric

Data

symmetric

Data

symmetric

GUID GUID GUID

symmetric ABE symmetric GUID

slide-60
SLIDE 60

Challenges with ABE

  • Performance
  • Revocation
  • Device Loss

16

slide-61
SLIDE 61

Revocation

17

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-62
SLIDE 62

Revocation

17

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-63
SLIDE 63

Revocation

17

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

slide-64
SLIDE 64

Revocation

17

NY Marathon Boston Marathon Insurance

FitBit Cloud Server

type=race type=running type=fitness

  • Web service still has cached keys
  • Need to re-encrypt data
slide-65
SLIDE 65

Re-encryption with Hybrid Encryption

  • Need to re-encrypt metadata and data

– Easy to re-encrypt metadata block – How do we re-encrypt data object?

  • Download, re-encrypt, and upload
  • Requires substantial bandwidth and client-side

computation

18

slide-66
SLIDE 66

Solution: Key Homomorphism

  • Allows changing key in encrypted data

– Symmetric cipher that provides in-place re- encryption

  • Does not learn old key, new key, or plaintext
  • More specifics on scheme are in the paper

19

slide-67
SLIDE 67

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

slide-68
SLIDE 68

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

slide-69
SLIDE 69

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

δ( , )

slide-70
SLIDE 70

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

δ( , )

slide-71
SLIDE 71

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

symmetric

δ( , )

slide-72
SLIDE 72

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

symmetric symmetric

ABE (attrs, epoch = 1)

δ( , )

slide-73
SLIDE 73

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

symmetric symmetric

ABE (attrs, epoch = 1)

δ( , )

slide-74
SLIDE 74

Full Revocation Process

Data

symmetric

ABE (attrs, epoch = 0)

symmetric

20

Metadata Block

Issue new keys to web services whose data access has been changed and affected by revocation symmetric symmetric

ABE (attrs, epoch = 1)

δ( , )

slide-75
SLIDE 75

Challenges with ABE

  • Performance
  • Revocation
  • Device Loss

21

slide-76
SLIDE 76

What if a user loses her device?

  • User has ABE private key
  • Loss of key requires reset of system

– Re-encrypting all her data and issuing new keys

  • Is there a way for a user to recover from device

loss?

22

slide-77
SLIDE 77

Solution: Secret sharing

  • User splits her ABE private key across devices
  • Requires a threshold to reconstruct secret

– Reconstruct before using ABE private key

  • When a device is lost, gathers devices to

reconstruct secret and issue new “shares”

23

slide-78
SLIDE 78

Outline

  • Sieve

– Protocol – Optimizations – Revocation – Device Loss

  • Implementation
  • Evaluation

24

slide-79
SLIDE 79

Sieve Implementation

25

Cryptography:

  • Libfenc with Stanford PBC for ABE
  • AES (no revocation) and randomized counter mode with

Ed448 (revocation)

slide-80
SLIDE 80

Sieve Implementation

25

Storage Provider User Web services Sieve user client Sieve storage daemon Sieve data import

  • ~1000 LoC
  • MongoDB and

BerkeleyDB

  • ~1400 LoC
  • Service-specific

Cryptography:

  • Libfenc with Stanford PBC for ABE
  • AES (no revocation) and randomized counter mode with

Ed448 (revocation)

slide-81
SLIDE 81

Evaluation

  • Is it easy to integrate Sieve into existing web

services?

  • Can web services achieve reasonable

performance while using Sieve?

26

slide-82
SLIDE 82

Evaluation Setup

  • Multicore machine, 2.4 GHz Intel Xeon
  • Web servers ran on machine’s loopback

– Minimize network latency – Focus on cryptographic overheads

27

slide-83
SLIDE 83

Case Studies

  • Integrated with 2 open source web services

– Open mHealth, health: small data

  • Visualize health data
  • One week’s health data: 6 KB

– Piwigo, photo: large data

  • Edit and display photos
  • One photo: 375 KB

28

slide-84
SLIDE 84

Easy to integrate with Sieve

  • Lines of code required for integration

– Open mHealth: ~ 200 lines – Piwigo: ~ 250 lines

29

slide-85
SLIDE 85

Acceptable performance for Open mHealth and Piwigo

Seconds 1.5 3 4.5 6 Open mHealth Piwigo Write Read

30

Ed448 with key caching

slide-86
SLIDE 86

Performance gap between AES and Ed448

Seconds 1.5 3 4.5 6 Open mHealth Ed448 Open mHealth AES Write Read

31

slide-87
SLIDE 87

Server per-core throughput is good

  • Open mHealth

– Storage write: 50 MB/s – Web service import: 70 users/min (Ed448)

  • Piwigo

– Storage write: 200 MB/s – Web service import: 14 photos/min (Ed448)

32

slide-88
SLIDE 88

Revocation performance is reasonable

  • Re-encrypt a metadata block (10 attrs): 0.63 s
  • Re-key 100 KB data block: 0.66 s
  • Generate new 10 attribute key: 0.46 s

33

slide-89
SLIDE 89

Secret sharing is fast

  • For 5 shares and threshold of 2:

– Splitting ABE key requires 0.04 ms – Reconstructing key requires 0.09 ms

34

slide-90
SLIDE 90

Summary

  • Required < 250 LoC to integrate with case studies
  • Read and write data in reasonable amount of time
  • Good per-core server throughput for storage writes

and application data imports

  • Revocation functions take < 1 second
  • Secret sharing takes negligible time

35

slide-91
SLIDE 91

Related Work

  • Untrusted Servers

– ShadowCrypt, SUNDR, Depot, SPORC, CryptDB, DepSky, Bstore, Mylar, Privly

  • ABE and Predicate Encryption Storage

– Persona, Priv.io, Catchet (ABE) – GORAM (Predicate)

  • Access Delegation Schemes

– OAuth, AAuth, Macaroons

36

slide-92
SLIDE 92

Related Work

  • Untrusted Servers

– ShadowCrypt, SUNDR, Depot, SPORC, CryptDB, DepSky, Bstore, Mylar, Privly

  • ABE and Predicate Encryption Storage

– Persona, Priv.io, Catchet (ABE) – GORAM (Predicate)

  • Access Delegation Schemes

– OAuth, AAuth, Macaroons

36

Solve different problems than Sieve

slide-93
SLIDE 93

Related Work

  • Untrusted Servers

– ShadowCrypt, SUNDR, Depot, SPORC, CryptDB, DepSky, Bstore, Mylar, Privly

  • ABE and Predicate Encryption Storage

– Persona, Priv.io, Catchet (ABE) – GORAM (Predicate)

  • Access Delegation Schemes

– OAuth, AAuth, Macaroons

36

Solve different problems than Sieve No complete revocation and/or ability to recover from device loss

slide-94
SLIDE 94

Related Work

  • Untrusted Servers

– ShadowCrypt, SUNDR, Depot, SPORC, CryptDB, DepSky, Bstore, Mylar, Privly

  • ABE and Predicate Encryption Storage

– Persona, Priv.io, Catchet (ABE) – GORAM (Predicate)

  • Access Delegation Schemes

– OAuth, AAuth, Macaroons

36

Solve different problems than Sieve No complete revocation and/or ability to recover from device loss Less secure and expressive than Sieve

slide-95
SLIDE 95

Conclusions

  • Sieve is a new access control system that allows

users to selectively and securely expose their private cloud data to web services

  • Efficiently use ABE to manage keys and policies
  • Complete revocation scheme compatible with

hybrid encryption using key homomorphism

  • Easy to integrate and reasonable performance

37