Privacy Preserving Access Control for Third Party Data Management Systems

2,927 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,927
On SlideShare
0
From Embeds
0
Number of Embeds
719
Actions
Shares
0
Downloads
168
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Privacy Preserving Access Control for Third Party Data Management Systems

  1. 1. Mohamed NabeelAdvisor: Prof. Elisa Bertino 7/12/2012
  2. 2. 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
  3. 3. Before Data Outsourcing (and cloud computing) Bob Alice Data Tim Organization
  4. 4. In The Cloud Computing Era Bob 2 1 2 Alice Data 2Organization Tim Cloud
  5. 5. Top Concerns (Source: IDC 2009) (Source: Lockheed Martin 2010)
  6. 6. In Cloud Computing Era Download & decrypt Bob 2 Encrypt & upload H 1 2 Alice Encrypted Data 2Organization Tim Cloud
  7. 7. 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
  8. 8. 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)
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Attribute-Based Systems User * * Attribute Level = seniorRole = Doctor Role = Nurse Role = Doctor Age = 51 Level = senior Level = junior
  15. 15. Policies over Attribute Conditions Role = Doctor ˅ (Role = Role = Nurse Nurse ˄ Level >= senior) Role = Doctor ˄ Level >= senior
  16. 16. GKM Requirements: Backward Secrecy Leave Time 
  17. 17. GKM Requirements: Forward Secrecy  Time Join
  18. 18. GKM Requirements: Collusion Resistance
  19. 19. 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
  20. 20. Traditional Policy Based GKM K1 K2 Group 2 Group 1 Group 3  Single Encryption Easy to manage keys K3 Easy to handle joins/leaves
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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)
  25. 25. 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
  26. 26. Security Analysis• We prove that ACV-BGKM is – Correct – Sound – Key hiding – Backward key protecting – Forward key protecting
  27. 27. 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]
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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]
  32. 32. 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)
  33. 33. 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}
  34. 34. 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
  35. 35. 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
  36. 36. 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!
  37. 37. Selected Experimental Results (a) Average time to generate keys for different group sizes (b) Average time to generate keys for different number of attributes
  38. 38. 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
  39. 39. Traditional SLE (Single Layer Enc.) K1 K2 Group 2 Group 1 Group 3 K3
  40. 40. 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
  41. 41. 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
  42. 42. Privacy Preserving of Id. Attributes• Registration: “I am a doctor” Server “Here’s a secret” Tim
  43. 43. 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.
  44. 44. Overall Scheme• Identity Token Issuance• Identity Token Registration• Data Management
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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)
  51. 51. Overall Scheme• Identity token issuance• Policy decomposition• Identity token registration• Data management
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. Publish Subscribe Systems Third party broker network UsersData owners Bro5 Sub1 Bro1 Pub1 Bro3 Sub2 Pub2 Bro2 Bro4 Sub3 Notification Subscription
  56. 56. 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)
  57. 57. 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.)
  58. 58. Two “Encryptions” Approach Value Blinded Enc Value Value Modified Paillier Broadcast encryption encryption based on AB-GKM Matching Access Control
  59. 59. An Example• The original notification: Symbol = MSFT Price = 31• Blinded/Encrypted notification: Symbol = blind(MSFT) Price = blind(31) encryptK(Symbol = MSFT, Price = 31)
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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)
  66. 66. 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
  67. 67. Q&A Thank You!

×