23
LH* RE : A Scalable Distributed Data Structure with Recoverable Encryption Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Embed Size (px)

Citation preview

Page 1: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

LH*RE: A Scalable Distributed Data Structure with Recoverable

Encryption

Sushil Jajodia, George Mason UWitold Litwin, U Paris Dauphine

Thomas Schwarz, S.J., U Católica Uruguay

Page 2: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Scalable Distributed Data Structures store data in the potentially hostile environment of distributed systems, clouds, P2P

Standard protection for confidentiality, integrity, and authentication is encryption◦ Client-Side Encryption

Challenge: Key management Clients loose keys, keys need to be revoked, … Could use Key Escrow

Not widely used

◦ Server-Side Encryption Challenge: Key management

Client has no control over her/his data

SDDS

Page 3: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Build on top of LH*, distributed version of linear hashing◦ Data distributed into buckets, each at a different server◦ Gracefully adjusts to growth of file◦ Very efficient access via record identifiers

Uses client-side encryption All key are copied in LH* itself:

◦ Each key broken into k + 1 shares through secret sharing Generate k random strings of same size as key C These form first k random shares Ck = C0 C1 C2 ... Ck-1 C is the last share.

◦ Key shares stored in Share Records

LH*RE

Page 4: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

LH* data stored in records consisting of RID and non-key field (payload)

LH*RE adds three fields:◦ I-field: Identifies application, …◦ F-field: Flag that distinguishes between data

records and key share records◦ T-field: Identifies key being used

File Structure and Addressing

Page 5: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Client records are LH* records Data records translated in LH*RE format

Operations on Data Records

Page 6: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Key Management◦ Clients maintain their key chain in a table T◦ Each key broken up into key share◦ Each key share stored as a share record

Key Recovery:◦ Use LH* scan operation to find all key shares

belonging to a certain application Key Revocation:

◦ Find all key shares◦ Find all records ◦ Delete, re-encrypt and reinsert records

Encryption Key Operations

Page 7: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

LH*RE is k-safe◦ Attack into up to k servers is not successful

Security Analysis

Page 8: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Threat model◦ Servers are autonomous, no common

vulnerabilities: Physical access Administrative access Common configuration

Assurance◦ Probability that x intrusions did not yield records to

the attacker Disclosure

◦ Expected proportion of records obtained by an intrusion into x servers

Security Analysis

Page 9: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Single Key

5 10 50 100 500x

0.986

0.988

0.990

0.992

0.994

0.996

0.998

1.000Assurance

16

K 4

1024

5 10 50 100 500x

0.986

0.988

0.990

0.992

0.994

0.996

0.998

1.000Assurance

16

K 8

1024

5 10 50 100 500x

0.986

0.988

0.990

0.992

0.994

0.996

0.998

1.000Assurance

16

K 1 6

1024

Page 10: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Single Key

5 10 50 100 500x

0.999970

0.999975

0.999980

0.999985

0.999990

0.999995

1.000000Assurance

16

K 4

1024

5 10 50 100 500x

0.999970

0.999975

0.999980

0.999985

0.999990

0.999995

1.000000Assurance

16

K 8

1024

5 10 50 100 500x

0.999970

0.999975

0.999980

0.999985

0.999990

0.999995

1.000000Assurance

16

K 8

1024

Assurance in an LH* file with K = 4, 8, and 16 key shares (top to bottom) extending over 16, 32, 64, 128, 256, 512, and 1024 servers. The x-axis is chosen to show the 99.999% (five nines) assurance level.

Page 11: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Single Key

50 100 150 200 250x

0.988

0.990

0.992

0.994

0.996

0.998

K 4

K 8

K 16

Ratio r of assurances with random placement over assurance with the LH*RE placement scheme for N = 256 sites, K = 4, 8, and 16.

Page 12: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Multiple Keys

5 10 50 100 500x

0.986

0.988

0.990

0.992

0.994

0.996

0.998

1.000Assurance

16

K 4 r 1 0

1024

5 10 50 100 500x

0.986

0.988

0.990

0.992

0.994

0.996

0.998

1.000Assurance

16

K 4 r 1 0 0

1024

Assurance in an LH* file with K = 4 and r = 10 and r = 100 keys. We vary N from 16 to 1024. The x-axis shows the two nines assurance level

Page 13: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Expected Disclosure

◦ N number of sites, K number of key shares, x number of intruded sites

◦ Independent of number of keys used!

Security Analysis: Multiple Keys

Page 14: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Conditional Disclosure◦ Expected proportion of records assuming that a

successful intrusion has occurred

is the probability of a successful attack into one bucket

r number of keys

Security Analysis: Multiple Keys

Page 15: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Multiple Keys Contour Graph for the

conditional disclosure. We vary N, the number of sites, and r, the number of keys. We set K, the number of shares to 8, and show figures for x = 8, 9, 16 and 32 intrusions. The upper right corner of each picture has close to zero conditional disclosure.

Page 16: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Refined Disclosure Costs◦ Costs of a disclosure of data depends on

The fact of disclosure Negative publicity, Costs of filing with authorities and

penalties, Costs of incident analysis … The number of records disclosed

◦ Model costs of disclosure by assuming that α of maximum disclosure is fixed

Security Analysis: Multiple Keys

Page 17: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Security Analysis: Multiple Keys

10 20 30 40 50

0 .0001

0 .0002

0 .0003

0 .0004

0 .0005 r 1

r 1 0

0

r 1 0 0

10 20 30 40 50

0 .0005

0 .0010

0 .0015

0 .0020

r 1

r 1 0 0 .1 r 1 0 0

10 20 30 40 50

0 .001

0 .002

0 .003

0 .004

0 .005

0 .006

0 .007

r 1

r 1 0 0 .5

r 1 0 0

10 20 30 40 50

0 .002

0 .004

0 .006

0 .008

0 .010

0 .012

0 .014

r 1

r 1 0 1 r 1 0 0

Refined Disclosure Proportion for N = 100, K = 8, α = 0, 0.1, 0.5, 1, and x (x-axis) varying between 0 and 50. Notice the different scales on the y-axis

Page 18: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

On Balance:◦ While maintaining # of nines of safety, can

introduce more keys as file extends over more sites

◦ Number of keys has no impact on expected disclosure

◦ Number of keys has positive impact on conditional disclosure

◦ Number of keys has negative impact on refined disclosure costs

Security Analysis: Multiple Keys

Page 19: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Up till now, we assumed an attacker without knowledge of the LH* layout◦ With knowledge where buckets are (e.g. from

observing traffic flow), a “savvy attacker” has an advantage

Savvy Attackers

Page 20: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Assume initial number of buckets is 3, but now grown to 6:◦ One key share in Buckets 0 and 4◦ One key share in Buckets 1, 3, and 5◦ One key share in Bucket 2

Optimal attack uses key share distribution and size◦ Optimal 3 attack plan:

Attack either 0 or 4 Attack 3

It has half the records descending from original Bucket 1

Attack 2◦ Success rate is ½ * ½ * 1=0.25

Savvy Attacker

Page 21: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Savvy attacker needs to optimize bucket intrusions

Advantage higher if:◦ There are buckets of different size◦ The initial number of buckets is not a power of 2

Savvy Attacker

1 2 3 4 5 6x

0.2

0.4

0.6

0.8

1.0D isclosure

F ig . 1 1 to p

s a v v y

a g n o s t i c

Page 22: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Savvy Attacker

5 10 15 20 25 30x

0.02

0.04

0.06

0.08

0.10

0.12

0.14

D isclosure

N 64, K 3

s a v v y

a g n o s t i c

5 10 15 20 25 30x

0.01

0.02

0.03

0.04

0.05

0.06

D isclosure

N 64, K 4 s a v v y

a g n o s t i c

5 10 15 20 25 30x

0.005

0.010

0.015

0.020

0.025

D isclosure

N 64, K 5

s a v v y

a g n o s t i c

Page 23: Sushil Jajodia, George Mason U Witold Litwin, U Paris Dauphine Thomas Schwarz, S.J., U Católica Uruguay

Management of number of keys High availability

Variants