Privacy Preserving Access Control for Third Party Data Management Systems

Mohamed NabeelAdvisor: 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) Bob Alice Data Tim Organization

In The Cloud Computing Era Bob 2 1 2 Alice Data 2Organization Tim Cloud

Top Concerns (Source: IDC 2009) (Source: Lockheed Martin 2010)

In Cloud Computing Era Download & decrypt Bob 2 Encrypt & upload H 1 2 Alice Encrypted Data 2Organization Tim Cloud

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 CR1Key1 MR3 MR4 CR2 Key2 Bob Alice MR5 CR3 CR4

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 1 PubB PubB PubT PubA 3 (MR1) Bob(MR1) (MR1) (CR1) (doctor) PubB/PriB PubA H 2 (CR1) PubB PubT PubA Alice (MR1) (MR1) (CR1) (nurse) PubA/PriAOrganization PubT Tim Cloud (MR1) (doctor) PubT/PriT

Proxy Re-Encryption (PRE) 1 PubB PubO PubO 4 (MR1) Bob (MR1) (CR1) (doctor) PubB/PriB 3 PubA H 2 (CR1) PubB PubT PubA Alice (MR1) (MR1) (CR1) (nurse) PubA/PriAOrganization PubT Tim PubO/PriO Cloud (MR1) (doctor) PubT/PriT

Attribute Based Encryption (ABE) 1 Doctor Doctor Nurse 3 (MR1) Bob (MR1) (CR1) (doctor) PriB Nurse H 2 (CR1) Doctor Nurse Alice (MR1) (CR1) (nurse) PriAOrganization Doctor Tim Cloud (MR1) (doctor) 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 – 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

Attribute-Based Systems User * * Attribute Level = seniorRole = Doctor Role = Nurse Role = Doctor Age = 51 Level = senior Level = junior

Policies over Attribute Conditions Role = Doctor ˅ (Role = Role = Nurse Nurse ˄ Level >= senior) Role = Doctor ˄ Level >= senior

GKM Requirements: Backward Secrecy Leave Time 

GKM Requirements: Forward Secrecy  Time Join

GKM Requirements: Collusion Resistance

Traditional Policy Based GKM K1 K2 Group 2 Group 1 Group 3  Single Encryption Easy to manage keys K3 Easy to handle joins/leaves

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 S1 GC Public Info + S2 S3 Contains the policy

How BGKM Works (5) Derive key S1 K’ using PI S3 Alice (5) Derive key GC (1) Issue secrets S2 using PI K  Bob (6) DK(EK(Data)) Tim S3 (2) Using secrets generate Data S2 Symmetric key K and Public Info PI (4) Download encrypted data and PI K (3) Upload encrypted data Ek(Data) and PI PI PI Data

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 Algorithms1 Access Control Matrix 1 a1,2 … a1,m 1 Key Extraction Vector (KEV) 1 a2,2 … a2,m ar,1 ar,2 ar,m 1 an,2 … an,m ar,j = H(sr || zj), j = 2, …, mai,j = H(si || zj), j = 2, …, m 2 Group key2 Null Space T KEV ∙ ACV = K b1,1 b1,2 … b1,m bt,1 bt,2 … bt,m3 Access Control Vector (ACV) T K+c1,1 c1,2 … c1,m

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 (c) Average time to generate keys with different bucket sizes(b) Average time to derive keys (d) Average time to derive keys with different bucket sizes

Attribute Based GKM (AB-GKM) S3 Level = senior S4 S6Role = Doctor Role = Nurse S5 Role = Doctor S7S1 Age = 51 Level = senior Level = junior S2 Bob Alice Ted  OR AND Role = Nurse Level >= senior Role = Doctor Level >= senior

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] q1(x) = s OR q1(0) = s Role = Doctor q2(x) = s + ax AND q1(0) Role = Nurse Level >= senior 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}

Access Tree AB-GKM - ExamplePolicy = Role = Nurse ˄ Level = Senior ˄ 2-out-of-4 in {MedA, MedB, MedC, ACME}KeyGen q1(x) AND q2(x) 2-of- Role = Nurse Level = Senior 4 PubInfoNurse PubInfoSenior Plan = MedA Plan = MedB Plan = MedC Plan = ACME PubInfoMedA PubInfoMedB PubInfoMedC PubInfoACMEKeyDer

Access Tree AB-GKM - ExamplePolicy = Role = Nurse ˄ Level = Senior ˄ 2-out-of-4 in {MedA, MedB, MedC, ACME} q1(x) AND  q2(x)  2-of- Role = Nurse Level = Senior 4 PubInfoNurse PubInfoSenior Plan = MedA Plan = MedB Plan = MedC Plan = ACME PubInfoMedA PubInfoMedB PubInfoMedC PubInfoACME

Access Tree AB-GKM - Example Role = Doctor Level = senior Plan = MedABobAlice Role = Nurse Level = senior Plan = MedA Plan = ACME  Role = Doctor Plan = MedBTed Role = Nurse Level = junior Plan = MedCRoyBob + Roy ?  Collusion Resistance!

Selected Experimental Results (a) Average time to generate keys for different group sizes (b) Average time to generate keys for different number of attributes

Traditional SLE (Single Layer Enc.) K1 K2 Group 2 Group 1 Group 3 K3

Traditional SLE (Single Layer Enc.) (3) Selectively encrypt & upload Third Party Owner Server (5) Download to re-encrypt (1) Register (4) Download & Decrypt (2) Keys User

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” Server “Here’s a secret” Tim

Privacy Preserving of Id. Attributes• Privacy Preserving Registration*: Unconditionally hiding and An encrypted message computationally binding com(m) = gmhr Commitment(“I am a doctor”) Server Envelope(“Here’s a secret”) Server• Sever does not learn credentials. User• 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.

Overall Scheme• Identity Token Issuance• Identity Token Registration• Data Management

Our SLE (Single Layer Enc.) Approach (1) Identity Attribute User IdP (2) Identity Token (3) Selectively encrypt (AB-GKM) & upload Owner Cloud (5) Download to re-encrypt (4) Download & OCBE (1) Register Decrypt identity token (2) Envelope (Secret) User

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 Cloud Data Owner

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 All ACPs Policy GraphACP1 = (“role = doc” ˅ (“role = nur” 1 2 role˄ “type >= junior”), CI) type = type >= = docACP2 = (“role = doc” ˄ “yos >= 5”, senior juniorBI)ACP3 = (“role = doc” ˄ “ip = 2-out-4”, role = ip = yos >= nur 2-out-CR) 4 5ACP4 = (role = nur” ˄ “type =senior”, TR) Owner enforced sub ACPs 4 ACP11 = (“role = doc” ˅ “role = nur”, Decomposed ACPs CI) ACP21 = ACP31 = (“role = doc”, BI, CR) Greedy Policy Cover ACP41 = (role = nur”, TR) 3 Cloud enforced sub ACPsMinimal ACC = {“role = doc”, “role =nur” } ACP12 = (“role = doc” ˅ “type >= junior”, CI) ACP22 = (“yos >= 5”, BI) ACP32 = (“ip = 2-out-4”, CR) ACP42 = (“type = senior”, TR)

Overall Scheme• Identity token issuance• Policy decomposition• Identity token registration• Data management

Two Layer Encryption Approach (1) Identity Attribute User IdP (2) Identity Token (1) Decompose (5) Re-encrypt to policies enforce policies (4) coarse-grained enc. & Owner upload docs & modified Cloud policies (2) Register identity token OCBE (2) Register OCBE identity token (3) Secrets (3) Secrets (6) Download & Decrypt twice User

Selected Experimental Results(a) Size of ACCs for 1000 attributes (b) Size of ACCs for 1500 attributes (c) Average time to generate keys (d) Average time to derive keys for SLE vs. TLE for SLE vs. TLE

Publish Subscribe Systems Third party broker network UsersData owners Bro5 Sub1 Bro1 Pub1 Bro3 Sub2 Pub2 Bro2 Bro4 Sub3 Notification Subscription

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 Enc Value Value Modified Paillier Broadcast encryption encryption based on AB-GKM 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 Cryptosystem1. Shifting the computation so that matching and covering operations at brokers are efficient2. Allowing Publishers and Subscribers to blind without having to share secret keys3. Not allowing to decrypt individual values, but allowing to compute the difference by simply multiplying a notification and a subscription4. Allowing brokers to compute only a randomized difference

Randomized Matching x = notification v = subscription Diff Decision x >= v not utilized x < v <= 2l x >= v0 2l n/2 n- 2l n > n – 2l x<v x – v in (0, 2l ) x – v in (n - 2l , n) (a) Deterministic matching Broker learns the difference Randomized Decision x >= v x<v Diff0 2l n/2 n - 2l n <= n/2 x >= v x – v in (0, 2l ) x – v in (n - 2l , n) > n/2 x<v (b) Randomized matching Broker does not learn the difference

Overall System Manages Keys and MPC TTP (1) Register (2) Secrets of all Subs + (2) Secret + MPC parameters MPC parameters (1) MPC parameters (3) Subscription Pub1 Bro1 Sub1 (4) Notification (6) Encrypted (5) Match payload (7) Derive key & Decrypt Blinded AVPs Encrypted payload

Selected Experimental Results (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 SACMAT2012 Systems 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!

http://mohamednabeel.blogspot.com	269
http://mohamednabeel.blogspot.in	41
http://mohamednabeel.blogspot.co.uk	15
http://mohamednabeel.blogspot.de	14
http://mohamednabeel.blogspot.ca	11
http://mohamednabeel.blogspot.se	9
http://mohamednabeel.blogspot.be	7
http://mohamednabeel.blogspot.com.es	5
http://mohamednabeel.blogspot.fr	4
http://mohamednabeel.blogspot.com.au	3
http://mohamednabeel.blogspot.it	3
http://mohamednabeel.blogspot.hu	1
http://mohamednabeel.blogspot.com.br	1
http://flavors.me	1
http://mohamednabeel.blogspot.tw	1
http://mohamednabeel.blogspot.hk	1
http://mohamednabeel.blogspot.sg	1
http://mohamednabeel.blogspot.co.nz	1
http://mohamednabeel.blogspot.dk	1
http://mohamednabeel.blogspot.jp	1
http://mohamednabeel.blogspot.kr	1
http://mohamednabeel.blogspot.cz	1
http://mohamednabeel.blogspot.fi	1
http://mohamednabeel.blogspot.pt	1
http://mohamednabeel.blogspot.nl	1

Privacy Preserving Access Control for Third Party Data Management Systems

by Nabeel Mohamed on Jul 13, 2012

Accessibility

Categories

Upload Details

Usage Rights

25 Embeds 395

Statistics

Privacy Preserving Access Control for Third Party Data Management Systems Presentation Transcript