Privacy Preserving Access Control for Third Party Data Management Systems

Mohamed Nabeel

Advisor: Prof. Elisa Bertino

7/12/2012

Outline

• Introduction

• Group Key Management (GKM) – Attribute Based Systems and GKM Requirements

– Broadcast GKM (BGKM)

– Attribute-Based GKM (AB-GKM)

• Privacy Preserving Pull Based Systems – SLE (Single Layer Encryption) Approach

– TLE (Two Layer Encryption) Approach

• Privacy Preserving Subscription Based Systems

• Summary

Before Data Outsourcing (and cloud computing)

Data

Organization

Bob

Alice

Tim

In The Cloud Computing Era

Data

Organization

Bob

Alice

Tim Cloud

1

2

2

2

Top Concerns

(Source: IDC 2009)

(Source: Lockheed Martin 2010)

In Cloud Computing Era

Encrypted Data

Organization

Bob

Alice

Tim Cloud

1

2

2

2 H Encrypt & upload

Download & decrypt

How to Control Access?

• Different users have access to different data

– Bob is a doctor and has access to Medical Records

– Alice is a nurse and has access to Clinical Records

MR1 MR2

MR3 MR4

MR5

CR1

CR2

CR3 CR4

Bob Alice

Key2 Key1

What Cryptosystem to Use?

• Public Key Cryptosystems (PKC)

– Traditional PKC (e.g. RSA, ElGamal, etc.)

– Attribute Based Encryption (ABE)

– Proxy Re-Encryption (PRE)

• Symmetric Key Cryptosystem (SKC)

– Group key management (GKM)

Traditional PKC Systems

Organization

Bob

Alice

Tim Cloud

1

H PubB

(MR1) (doctor)

(nurse)

(doctor)

PubT

(MR1) PubA

(CR1)

PubB

(MR1) PubT

(MR1) PubA

(CR1)

PubB

(MR1)

PubT

(MR1)

PubA

(CR1) 2

3

PubB/PriB

PubA/PriA

PubT/PriT

Proxy Re-Encryption (PRE)

Organization

Bob

Alice

Tim Cloud

1

H PubO

(MR1) (doctor)

(nurse)

(doctor)

PubO

(CR1)

PubB

(MR1) PubT

(MR1) PubA

(CR1)

PubB

(MR1)

PubT

(MR1)

PubA

(CR1) 2

4

PubB/PriB

PubA/PriA

PubT/PriT

PubO/PriO

3

Attribute Based Encryption (ABE)

Organization

Bob

Alice

Tim Cloud

1

H Doctor

(MR1) (doctor)

(nurse)

(doctor)

Nurse

(CR1)

Doctor

(MR1) Nurse

(CR1)

Doctor

(MR1)

Doctor

(MR1)

Nurse

(CR1) 2

3

PriB

PriA

PriT

Symmetric Key Cryptosystems

• Orders of magnitude faster than PKC

• But traditional SKC also has limitations

• Limitations of the traditional SKC/GKM – Many symmetric keys

– Need to agree on the encryption keys “BEFORE” the secure communication

– Difficult to revoke user

• What can we do about it? – (SKC – limitations) => Broadcast group key

management

Outline

• Introduction

• Group Key Management – Attribute Based Systems and GKM Requirements






• Summary

Attribute-Based Systems

User Attribute * *

Role = Doctor

Age = 51

Level = senior

Role = Nurse

Level = senior

Role = Doctor

Level = junior

Policies over Attribute Conditions

Role = Doctor ˅ (Role =

Nurse ˄ Level >= senior) Role = Nurse

Role = Doctor ˄ Level

>= senior

GKM Requirements: Backward Secrecy

Leave Time

GKM Requirements: Forward Secrecy

Join

Time

GKM Requirements: Collusion Resistance

Outline

• Introduction







• Summary

Traditional Policy Based GKM

Group 1 Group 2

Group 3

K1

K2

K3

Single Encryption

Easy to handle joins/leaves

Easy to manage keys

A Key Observation

Users DO NOT require the key until they want to decrypt something

DO NOT issue decryption keys to users upfront +

Allow users to dynamically derive symmetric keys at the time of decryption

Broadcast GKM (BGKM)

Instead of giving keys, give some secrets to derive the key

using public information

Public Info GC +

S1

S2

S3 Contains the policy

How BGKM Works

GC (1) Issue secrets

S3

S2

(2) Using secrets generate Symmetric key K and Public Info PI

K

PI

(4) Download encrypted data and PI

Ek(Data)

PI

(3) Upload encrypted data and PI

Data

Data

(6) DK(EK(Data))

S1

S2

S3

Bob

Alice

Tim

K (5) Derive key using PI

K’ (5) Derive key using PI

BGKM Algorithms

• Setup(l) → Param

• SecGen(Usri) → si

• KeyGen(S) → (k, PubInfo)

• KeyDer(PubInfo, si) → k

• Update(S’) → (k’, PubInfo’)

• Our construction: ACV-BGKM (Access

Control Vector BGKM)

KeyGen and KeyDer Algorithms

1 a1,2 a1,m

1 a2,2 a2,m

1 an,2 an,m

Access Control Matrix

… …

…

ai,j = H(si || zj), j = 2, …, m

1

b1,1 b1,2 b1,m

bt,1 bt,2 bt,m

Null Space

…

…

T 2

K+c1,1 c1,2 c1,m

Access Control Vector (ACV)

… T 3

ar,1 ar,2 ar,m

1 Key Extraction Vector (KEV)

ar,j = H(sr || zj), j = 2, …, m

KEV ∙ ACV = K

2 Group key

Security Analysis

• We prove that ACV-BGKM is

– Correct

– Sound

– Key hiding

– Backward key protecting

– Forward key protecting

Problem: Secure but not Efficient

• KeyGen (O(n3)), KeyDer (O(n)) and PubInfo (O(n)) in the current ACV-BGKM is proportional to n (number of users)

– Does not scale!

• How to reduce the complexity and improve the efficiency?

– Bucketing

– Subset cover techniques [Naor et al. 2001]

Selected Experimental Results

(a) Average time to generate keys

(b) Average time to derive keys

(c) Average time to generate keys with different bucket sizes

(d) Average time to derive keys with different bucket sizes

Outline

• Introduction







• Summary

Attribute Based GKM (AB-GKM)

Role = Doctor

Age = 51

Level = senior

Role = Nurse

Level = senior

Role = Doctor

Level = junior S1

S2

S3

S4

S5

S6

S7

AND

Level >= senior Role = Doctor

OR

Level >= senior Role = Nurse

Bob Alice Ted

AB-GKM

• A set of secrets per identity attribute

– SecGen(Usri) SecGen(Usri, Attrj)

• Three schemes

– Inline AB-GKM

– Threshold AB-GKM

– Access tree AB-GKM

• Based on ACV-BGKM and Shamir’s secret sharing scheme [Shamir 1979]

Access Tree AB-GKM - Idea

• Convert the policy into an access tree T [Benolah 1998]

OR

Role = Doctor AND

Level >= senior Role = Nurse

q1(x) = s

q2(x) = s + ax

q1(0) = s

q1(0)

q2(1) q2(2)

Access Tree AB-GKM - Example

• A hypothetical policy

– Policy = “A senior nurse supporting at least two insurance plans can access Medication of any patient”

– Policy = Role = Nurse ˄ Level = Senior ˄ 2-out-of-

4 in {MedA, MedB, MedC, ACME}


AND

2-of-4

Plan = MedB Plan = MedA

q1(x)

Role = Nurse Level = Senior

Plan = ACME Plan = MedC

q2(x)

PubInfoNurse PubInfoSenior

PubInfoMedA PubInfoMedB PubInfoMedC PubInfoACME

KeyGen

KeyDer

Policy = Role = Nurse ˄ Level = Senior ˄ 2-out-of-4 in {MedA, MedB, MedC, ACME}


AND

2-of-4

Plan = MedB Plan = MedA

q1(x)

Role = Nurse Level = Senior

Plan = ACME Plan = MedC

q2(x)

PubInfoNurse PubInfoSenior

PubInfoMedA PubInfoMedB PubInfoMedC PubInfoACME

Policy = Role = Nurse ˄ Level = Senior ˄ 2-out-of-4 in {MedA, MedB, MedC, ACME}


Role = Doctor

Bob

Alice

Ted

Roy

Role = Doctor

Level = senior

Role = Nurse Level = senior

Role = Nurse Level = junior

Plan = MedA

Plan = MedA Plan = ACME

Plan = MedB

Plan = MedC

Bob Roy + ? Collusion Resistance!


(a) Average time to generate keys for different group sizes

(b) Average time to generate keys for different number of attributes

Outline

• Introduction







• Summary

Traditional SLE (Single Layer Enc.)

Group 1 Group 2

Group 3

K1

K2

K3

Traditional SLE (Single Layer Enc.)

User

Owner

Third Party Server

(1) Register

(2) Keys

(4) Download & Decrypt

(3) Selectively encrypt & upload

(5) Download to re-encrypt

Issues with the Traditional Approach

• Key management does not scale

– When the group dynamics change, all users need to be rekeyed

– Rekeying requires establishing private communication channels

• Privacy of the identity attributes is not preserved

Privacy Preserving of Id. Attributes

• Registration:

“I am a doctor”

“Here’s a secret”

Tim

Server

Privacy Preserving of Id. Attributes

• Privacy Preserving Registration*:

Commitment(“I am a doctor”)

Server

Envelope(“Here’s a secret”)

User • Sever does not learn credentials. • User can open the envelope only if her credential satisfies the condition.

*OCBE – Oblivious Commitment Based Envelope OACerts: Oblivious Attribute Certificates by J. Li et al.

Unconditionally hiding and computationally binding

com(m) = gmhr

An encrypted message

Server

Overall Scheme

• Identity Token Issuance

• Identity Token Registration

• Data Management

Our SLE (Single Layer Enc.) Approach

User

Owner Cloud

(4) Download & Decrypt

(3) Selectively encrypt (AB-GKM) & upload

(5) Download to re-encrypt

User IdP

(1) Identity Attribute

(2) Identity Token

(1) Register identity token

(2) Envelope (Secret)

OCBE

Extending the SLE Approach

• In the SLE approach

1. The Owner has to manage all the identity attributes and perform the fine grained encryption

2. If the user credentials or access control policies change, the owner has to download, decrypt, rekey, re-encrypt and upload

Can we reduced the load at Owner?

• How can we delegate the access control enforcement to the cloud?

– Use two layer encryption

• A naïve approach

– The owner encrypts each data item according to the ACPs

– The Cloud re-encrypts according to the ACPs again

Two Layer Encryption

• In order to reduce the load at the Owner, the ACPs should be decomposed to two such that – The owner performs a coarse-grained encryption

– The cloud performs a fine-grained encryption

• At the same time – The confidentiality of the data should be assured

– The two layers together should enforce the ACP • ACP = ACP1 ˄ ACP2

Data

Owner

Cloud

Policy Decomposition Problem

• In order to minimize the load at the Owner – The Owner should manage only the minimum of

number of attributes

• Policy Cover Problem: Find the minimum number of attribute conditions in ACPs that assures the confidentiality from the Cloud. – NP-complete (Proof in the thesis)

– Two approximation algorithms • Random

• Greedy

A Simplified Example

ACP1 = (“role = doc” ˅ (“role = nur” ˄ “type >= junior”), CI) ACP2 = (“role = doc” ˄ “yos >= 5”, BI) ACP3 = (“role = doc” ˄ “ip = 2-out-4”, CR) ACP4 = (role = nur” ˄ “type = senior”, TR)

All ACPs 1

type =

senior

role =

nur

role =

doc

ip =

2-out-4

yos >= 5

type > =

junior

Policy Graph 2

Minimal ACC = {“role = doc”, “role = nur” }

Greedy Policy Cover 3

ACP11 = (“role = doc” ˅ “role = nur”, CI) ACP21 = ACP31 = (“role = doc”, BI, CR) ACP41 = (role = nur”, TR)

ACP12 = (“role = doc” ˅ “type >= junior”, CI) ACP22 = (“yos >= 5”, BI) ACP32 = (“ip = 2-out-4”, CR) ACP42 = (“type = senior”, TR)

Owner enforced sub ACPs

Cloud enforced sub ACPs

Decomposed ACPs

4

Overall Scheme

• Identity token issuance

• Policy decomposition

• Identity token registration

• Data management

Two Layer Encryption Approach

User

Owner Cloud

(6) Download & Decrypt twice

(4) coarse-grained enc. &

upload docs & modified policies

(1) Decompose policies

(5) Re-encrypt to enforce policies

User IdP

(1) Identity Attribute

(2) Identity Token


(3) Secrets

OCBE


OCBE

(3) Secrets


(a) Size of ACCs for 1000 attributes (b) Size of ACCs for 1500 attributes

(c) Average time to generate keys for SLE vs. TLE

(d) Average time to derive keys for SLE vs. TLE

Outline

• Introduction







• Summary

Publish Subscribe Systems

Notification

Subscription

Third party broker network

Data owners

Users

Pub1

Pub2

Bro1

Bro2

Bro3

Bro4

Bro5 Sub1

Sub3

Sub2

Notifications and Subscriptions

• Notifications

– Produced by publishers

– Consist of set of attribute-value pairs

– Example: { symbol = ”MSFT”, price = 30.9, size = 1000 }

• Subscriptions

– Produced by subscribers

– Specify a condition on one or more attributes in a notification

– Examples: (symbol = ”GOOG” AND price > 578), (1000 <= size <= 2000)

Security and Privacy

• Publication confidentiality

– Hide the notifications from brokers

• Subscription confidentiality

– Hide subscriptions from brokers

• Challenge: How to allow matching at third party brokers while assuring confidentiality?

– Existing approaches have limitations (e.g. False positive, limited expressiveness, and so forth.)

Two “Encryptions” Approach

Value

Blinded Value

Enc Value

Broadcast encryption based on AB-GKM

Modified Paillier encryption

Matching Access Control

An Example

• The original notification: Symbol = MSFT Price = 31

• Blinded/Encrypted notification: Symbol = blind(MSFT) Price = blind(31) encryptK(Symbol = MSFT, Price = 31)

Modified Paillier Cryptosystem

1. Shifting the computation so that matching and covering operations at brokers are efficient

2. Allowing Publishers and Subscribers to blind without having to share secret keys

3. Not allowing to decrypt individual values, but allowing to compute the difference by simply multiplying a notification and a subscription

4. Allowing brokers to compute only a randomized difference

Randomized Matching x = notification v = subscription

x >= v not utilized x < v n/2 n - 2l 0 2l

n

x – v in (0, 2l ) x – v in (n - 2l , n)

(a) Deterministic matching

x >= v x < v

(b) Randomized matching

n/2 n - 2l 0 2l n

x – v in (0, 2l ) x – v in (n - 2l , n)

Diff Decision

<= 2l x >= v

> n – 2l x < v

Randomized Diff

Decision

<= n/2 x >= v

> n/2 x < v

Broker learns the difference

Broker does not learn the difference

Overall System

Pub1 Bro1

Sub1

TTP

Manages Keys and MPC

(1) Register

(2) Secret + MPC parameters

(1) MPC parameters

(2) Secrets of all Subs + MPC parameters

(4) Notification

Blinded AVPs Encrypted payload

(6) Encrypted payload

(7) Derive key & Decrypt

(3) Subscription

(5) Match


(a) Blinding for different n (a) Blinding for different domain size l

(a) Match/Cover for different n (a) Match/Cover for different domain size l

In Summary

• Defended the thesis that with novel AB-GKM scheme and cryptographic techniques can be used to construct privacy preserving access control on third party data management systems – Assure the confidentiality of the data – Preserve the privacy of identity attributes

• Two models – Pull model – Subscription model

• The techniques proposed have applications outside of the thesis – AB-GKM – Modified Paillier cryptosystem

Publications Related to the Thesis

Thesis sub topic Publications

Group Key Management ICDE2010 CCS2011 (Poster paper) IEEE TDSC (Submitted for publication) IEEE TKDE (Submitted for publication)

Privacy Preserving Pull Based Systems SIGMOD2010 (Demo paper) CollaborateCom2011 Invited Paper, IEEE IRI2012 IEEE TKDE (Submitted for publication)

Privacy Preserving Subscription Based Systems

SACMAT2012 ICDE2013 (Under preparation)

Future and On-going Work

• Key management and authentication in smart grids

• Secure data sharing in public clouds using certificateless cryptography

• Oblivious classification in public clouds

• Privacy preserving relational data management in public clouds

Q&A

Thank You!

Technology

Privacy Preserving Access Control for Third Party Data Management Systems