Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enforcing Location and Time-based Access Control on Cloud-stored Data

997 views

Published on

Claudio Soriente. Grupo de Seguridad de Sistemas D-INFK / D-INFK Systems Security Group. ETH Zurich.

Summer Course "Disruptive innovation in security technologies". URJC's Vicálvaro Campus.

Curso de Verano "Innovación Disruptiva en tecnologías de seguridad". Campus Vicálvaro de la URJC.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Enforcing Location and Time-based Access Control on Cloud-stored Data

  1. 1. LoTAC: Enforcing Location and Time-based Access Control on Cloud-stored Data Claudio Soriente Institute of Information Security, ETH Zurich claudio.soriente@inf.ethz.ch dinnoTSec14 1
  2. 2. must store files Access Control (AC) 2 Alice (Owner) File Policy Policy Enforcement Point (PEP) Bob Charlie David Access to File – Allow Bob or Charlie must identify users Users
  3. 3. AC + Location Location-based rewards – Similar to targeted advertisement – Collect vouchers by visiting premium locations • E.g., stores, landmarks, ... 3
  4. 4. AC + Location Geo-fencing – Virtual perimeter of a geographic area • Trigger event when users moves in or out – Regulation compliance • Customer data accessed only within national boundaries – Security • The Symantec Smartphone Honey Stick Project – Lost or stolen devices 4
  5. 5. AC + Location + Time • Location-based rewards – Visit locations at specific times • Opening time, off-peak hours • Geo-fencing – Access data during business hours – Restriction to part-time staff 5
  6. 6. AC + Location + Time Access to File – Allow Bob or Charlie • If in Madrid on 30/06/2014 between 9.00am and 6.00pm • and in Bilbao on 01/07/2014 between 9.00 am and 10.30 am • and ... Alice PEP must identify users must locate users must store files 6
  7. 7. Deployed Systems L-RBAC [Ray et al. @ICISS’06] T-RBAC [Bertino et al. TISSEC’01] LoT-RBAC [Chandran et al. @WISE’05] Shy Mayor [Carbunar et al. ACNS’12] Location proofs [Saroiu et al. HotMobile’09] 7
  8. 8. Policies • Formal languages to define AC policies – RBAC extensions with Location and Time • Pros – Policy expressiveness • Define roles and arbitrary combinations of locations and time intervals • Cons – PEP must locate users – PEP is fully trusted • to access data • to enforce policies correctly L-RBAC [Ray et al. @ICISS’06] T-RBAC [Bertino et al. TISSEC’01] LoT-RBAC [Chandran et al. @WISE’05] 8
  9. 9. Deployed systems • Users check-in at premium locations – GPS coord. on user’s smartphone • Check-ins = points – Points entitle to prizes 9
  10. 10. Deployed systems • Pros – No need to locate users • PEP must only identify users • Smartphones’ GPS • Cons – GPS location can be spoofed • Users can abuse the system – PEP fully trusted 10
  11. 11. Location Proofs • Localization Infrastructure (LI) ≠ PEP – Issues Location Proofs • “Bob, Lat: 40.282929, Lon:-3.819948, 30/06/14, 11:07” • Digitally signed • PEP – Checks validity of proofs presented by the user – Checks proofs against policy Shy Mayor [Carbunar et al. ACNS’12] Location proofs [Saroiu et al. HotMobile’09] ? 11
  12. 12. Location Proofs • Pros – Separate PEP from Localization Infrastructure • PEP does not locate users • Users cannot spoof their location • Cons – PEP must trust the Localization Infrastructure – PEP is fully trusted Shy Mayor [Carbunar et al. ACNS’12] Location proofs [Saroiu et al. HotMobile’09] 12
  13. 13. Design Space • Policy enforcement, storage, localization • PEP only – All of the above – Alternatively, rely on phone’s GPS • PEP + Localization Infrastructure – PEP • Storage, policy enforcement – Localization Infrastructure • Locate users • All trust the PEP – to access data – to correctly enforce the policies 13
  14. 14. LoTAC: Location and Time-based Access Control No trusted Policy Enforcement Point – No-one should have access to data • Apart from authorized users – Enforcement by means of encryption Cloud Storage Servers – Ubiquitous data storage or access – No localization Cellular Network Operators – No storage – Only choice for ubiquitous localization Storage + Network – Seamless integration • Interfacing may never happen • Policy enforcement, storage, localization 14
  15. 15. LoTAC – Design • Cellular network operator – Can locate/identify users – Area divided in locations (ℓ) • Cells of the 3G network • One Location Server (LS) for each location ℓ – Base station controller – Key-pair pkℓ, skℓ • Think of ℓi = LSi = pkℓi pkℓ3 pkℓ1 pkℓ2 pkℓ4 LS2 LS4 LS1 LS3 skℓ1 skℓ3 skℓ2 skℓ4 ℓ2 ℓ1 ℓ4 ℓ3 15
  16. 16. LoTAC – Design • Storage server – Ubiquitous data storage and access – No Access Control • Anyone can download (encrypted data) • Users – Key-pair pku sku • Bound to the SIM card 16 pkB pkC pkD Bob Charlie David skB skC skD
  17. 17. LoTAC – Operations • Encryption + Upload • Download • Localization – Location Server processes ciphertext – Based on User ID, current location, current time • Decryption Decrypt Encrypt skB Access Set Contexutal policy 17
  18. 18. Tools: Tag-based Encryption • Public key encryption scheme – Encryption takes message + public key • and tag τ (arbitrary public string) • Security definition: – Tag-based non-malleable against adaptive chosen ciphertext attacks (TNM-CCA2) – Simply put, one cannot decrypt without the original τ Encrypt τpk1 Decryp t sk1 Decryp t τ’sk1 τ ≠ τ’ ≠ τ pk1 sk1 Public key Secret key 18
  19. 19. El-Gamal Tag-based Encryption • Based on hashed El Gamal – Group of positive quadratic residues – TNM-CCA2 if Strong RSA assumption holds 19
  20. 20. Tools: Onion Encryption Encrypt Encrypt Encrypt Decryp t Decryp t Decryp t • Add consecutive layers of encryption – Cascade encryption routines • Decryption requires removing all layers – One by one pk1 pk2 pk3 sk1 sk2 sk3 pk1 pk2 pk3 sk1 sk2 sk3 Public keys Secret keys 20
  21. 21. LoTAC – Main Idea • Onion Encryption – Access Set • Encryption layer with pk of user(s) – E.g., Bob ∈ Access Set then add layer with pkB » Only Bob can decrypt (with skB) – Contextual Policy • Outer encryption layer(s) with pk of Location Servers – E.g., if ℓ1 ∈ Contextual Policy, → add layer with pkℓ1 » Only LS1 can decrypt (with skℓ1 ) • Tag-based Encryption – Tags encode time • E.g., “16/07/2014 10:00 - 10:30” • Decryption requires the original tag – Tag cannot be modified Access Set Contexutal policy Encrypt 21
  22. 22. LoTAC – Encryption + Upload • Give access to if – he is in ℓ1 on 14-20/07/2014 – AND in ℓ2 on 16/07/2014 10:00 - 10:30 or 15:00 - 16:00 pkB pkC pkD pkℓ3 pkℓ1 pkℓ2 Tag-based ElGamal (pkℓ1 ) τ1 = 14-20/07/2014 Tag-based ElGamal (pkℓ2 ) τ2 = 16/07/2014 10:00 - 10:30 or 15:00 - 16:00 Access set Contextual Policy ElGamal (pkB) skB skC skD skℓ3 skℓ1 skℓ2 LS1 Bob David LS2 LS3 Charlie 22
  23. 23. LoTAC – Download • Any user can download the ciphertext – Storage server does not enforce access control Tag-based ElGamal (pkℓ1 ) τ1 = 14-20/07/2014 Tag-based ElGamal (pkℓ2 ) τ2 = 16/07/2014 10:00 - 10:30 or 15:00 - 16:00 ElGamal (pkB) • Decryption – skℓ2 + τ2 (only LS2 can decrypt) – skℓ1 + τ1 (only LS1 can decrypt) – skB (only Bob can decrypt) 23
  24. 24. LoTAC – Localization τ2 1. LS2 identifies and locates Bob 2. BOB sends ciphertext and tag τ2 to server LS2 3. LS2 compares τ2 with current time – skℓ2 to remove one encryption layer – sends back the chiphertext pkℓ2 LS2 pkB Bob τ2 ≈ ? skB skℓ2 24 Access to Bob if he is in ℓ1 at τ1=14-20/07/2014 and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
  25. 25. LoTAC – Localization τ1 • Similar interaction with LS1 • When all outer layer have been removed – Bob uses his secret key to remove the innermost layer pkℓ1 LS1 pkB Bob τ1 ≈ ? skB skℓ1 25 Access to Bob if he is in ℓ1 at τ1=14-20/07/2014 and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
  26. 26. Collusion pkℓ1 LS1 pkℓ2 LS2 pkB Bob pkD David skB skD skℓ1 skℓ2 26 τ2 τ1 Access to Bob if he is in ℓ1 at τ1=14-20/07/2014 and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
  27. 27. Tools: Re-randomization • Ciphertext can be re-randomized – Used for privacy issues (e.g, mix-networks) Encrypt pk1 Decryp t sk1 pk1 sk1 sk2pk2 Public keys Secret keys ≠ Decryp t sk1 pk1 Re-randRe-rand Decryp t pk2 sk2 Decryp t sk1 * *Only in some ciphertext groups * 27
  28. 28. LoTAC – Localization τ2 • LS2 identifies and locates Bob • Bob sends ciphertext and tag τ2 to server LS2 • LS2 compares τ2 with current time – skℓ2 to remove one encryption layer pkℓ2 LS2 pkB Bob τ2 ≈ ? skB skℓ2 Ciphertext re-randomized with pkB 28
  29. 29. Collusion Resistance pkℓ1 LS1 pkℓ2 LS2 pkB Bob pkD David skB skD skℓ1 skℓ2 29 τ2 τ1 Access to Bob if he is in ℓ1 at τ1=14-20/07/2014 and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00 Re-randomized with pkD Re-randomized with pkB
  30. 30. Macro-locations • ℓ is the basic unit of space – 3G cell – Served by a Location Server • Macro-locations – A neighborhood • 2/3 valid Location Servers – A city • 10s of valid Location Servers – One county • 100s of valid Location Servers 30 ℓ1 ℓ2 ℓ4 ℓ5 ℓ6 ℓ3 Access to – If he is in Vicálvaro on 01/06/2014
  31. 31. Tools: Re-encryption • Transform ciphertext under – In ciphertext under pk1 sk1 sk2pk2 Public keys Secret keys Encrypt pk1 Decryp t sk1 Decryp t sk2rk1→2 Re-Encrypt rk1→2 = re-encryption key from pk1 to pk2 31 pk1 pk2 pk2sk1 Key Extraction rk1→2 ?
  32. 32. LoTAC – Macro-locations • Loc. infrastructure creates a location hierarchy – The leaves are locations ℓ1, ℓ2, ℓ3, … • Served by LS1, LS2, LS3, … – Inner nodes are neighborhoods, cities, counties, … – Publishes public keys and re-encryption keys 32 LS1pkℓ1 LS2pkℓ2 LS3pkℓ3 LS4pkℓ4 LS5pkℓ5 LS6pkℓ6 LS7pkℓ7 LS8pkℓ8 pkMadrid pkVicálvaro pkSerrano pkChamberí Re-encryption key Serrano Chamberí Vicálvaro Madrid
  33. 33. LoTAC – Macro-locations • Access to – If he is in Vicálvaro on 01/06/2014 33 LS6pkℓ6 LS7pkℓ7 LS8pkℓ8 pkVicálvaro pkℓ8 LS8 pku1 Bob skB skℓ8 Re-Encrypt rkVicálvaro → ℓ8 rkVicálvaro → ℓ8 τ
  34. 34. Prototype Server Client Custom GSM Network 34
  35. 35. LoTAC – Performance 35
  36. 36. LoTAC – Performance Avg. (ms) Std. Dev. (ms) Download (U) 2990.1 124.4 Interaction (U-LS) Communication 2071.6 67.1 Computation 92.8 4.7 Decryption (U) 66.6 6.5 • Download takes constant time – Independent of the policy (# users, # locations, ...) • Interaction with one LS takes constant time – Repeat for # locations • Final decryption takes constant time – Standard ElGamal decryption 36
  37. 37. Conclusion • Location + Time in AC = New app. and business models – Security issues • Blend of system design and crypto • Only one Localization Infrastructure – Cellular network operators – Must be included in the design • Location Privacy – Active research field 37
  38. 38. References 1. I. Ray and M. Kumar and L. Yu, “LRBAC: A Location-Aware Role-Based Access Control Model”, ICISS 2006 http://dx.doi.org/10.1007/11961635_10 2. E. Bertino and P.A. Bonatti and E. Ferrari, “TRBAC: A temporal role-based access control model”, ACM TISSEC 4:3 2001 http://doi.acm.org/10.1145/501978.501979 3. S.M. Chandran and J.B.D. Joshi, “LoT-RBAC: A Location and Time-Based RBAC Model”, WISE 2005 http://dx.doi.org/10.1007/11581062_27 4. S. Saroiu and A. Wolman, “Enabling new mobile applications with location proofs”, HotMobile 2009 http://doi.acm.org/10.1145/1514411.1514414 5. B. Carbunar and R. Sion and R. Potharaju and M. Ehsan, “The Shy Mayor: Private Badges in GeoSocial Networks”, ACNS 2012 http://dx.doi.org/10.1007/978-3-642-31284-7_26 6. E. Androulaki and C. Soriente and L. Malisa and S. Capkun, “Enforcing Location and Time-based Access Control on Cloud-stored Data”, ICDCS 2014 http://www.syssec.ethz.ch/people/sorclaud 7. Symantec Inc., “The Symantec Smartphone Honey Stick Project” http://www.symantec.com/content/en/us/about/presskits/b-symantec-smartphone-honey-stick-project.en-us.pdf 38
  39. 39. Thanks! ? Elli Androulaki IBM Zurich Luka Malisa ETH Zurich Srdjan Capkun ETH Zurich joint work with: Claudio Soriente claudio.soriente@inf.ethz.ch 39

×