enforcing location and time-based access control on cloud-stored data
Upload: centro-de-investigacion-para-la-gestion-tecnologica-del-riesgo-cigtr
Post on 12-May-2015
280 views
DESCRIPTION
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.TRANSCRIPT
LoTAC:Enforcing Location and Time-based Access
Control on Cloud-stored Data
Claudio SorienteInstitute of Information Security, ETH Zurich
dinnoTSec14
1
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
AC + Location
Location-based rewards– Similar to targeted advertisement– Collect vouchers by visiting premium locations
• E.g., stores, landmarks, ...
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
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
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
7
Policies Crypto
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]
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]
9
Deployed systems
• Users check-in at premium locations– GPS coord. on user’s smartphone
• Check-ins = points– Points entitle to prizes
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
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]
?
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]
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
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
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
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 cardpkB
pkC
pkD
Bob
Charlie
David
skB
skC
skD
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
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
Decrypt
sk1
Decrypt
τ’sk1
τ ≠ τ’
≠
τ
pk1 sk1
Public key
Secretkey
19
El-Gamal Tag-based Encryption
• Based on hashed El Gamal– Group of positive quadratic residues– TNM-CCA2 if Strong RSA assumption holds
20
Tools: Onion Encryption
Encrypt Encrypt Encrypt
Decrypt Decrypt Decrypt
• 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
Secretkeys
21
LoTAC – Main Idea • Onion Encryption
– Access Set• Encryption layer with pk of user(s)
– E.g., Bob Access Set then add layer with pk∈ B
» 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
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
ContextualPolicy
ElGamal (pkB) skB
skC
skD
skℓ3
skℓ1
skℓ2
LS1 Bob
DavidLS2
LS3
Charlie
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)
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
Access to Bob if he is in ℓ1 at τ1=14-20/07/2014and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
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
Access to Bob if he is in ℓ1 at τ1=14-20/07/2014and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
26
Collusion
pkℓ1
LS1
pkℓ2
LS2
pkB
Bob
pkD
David
skB skD
skℓ1skℓ2
τ2τ1
Access to Bob if he is in ℓ1 at τ1=14-20/07/2014and in ℓ2 at τ2=16/07/2014 10:00 - 10:30 or 15:00 - 16:00
27
Tools: Re-randomization
• Ciphertext can be re-randomized– Used for privacy issues (e.g, mix-networks)
Encrypt
pk1
Decrypt
sk1
pk1 sk1
sk2pk2
Public keys
Secretkeys
≠
Decrypt
sk1pk1
Re-randRe-randDecrypt
pk2
sk2
Decrypt
sk1
*
*Only in some ciphertext groups
*
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
29
Collusion Resistance
pkℓ1
LS1
pkℓ2
LS2
pkB
Bob
pkD
David
skB skD
skℓ1skℓ2
τ2τ1
Access to Bob if he is in ℓ1 at τ1=14-20/07/2014and 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
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
ℓ1ℓ2
ℓ4 ℓ5
ℓ6
ℓ3
Access to – If he is in Vicálvaro on 01/06/2014
31
Tools: Re-encryption
• Transform ciphertext under– In ciphertext under
pk1 sk1
sk2pk2
Public keys
Secretkeys
Encrypt
pk1
Decrypt
sk1
Decrypt
sk2rk1→2
Re-Encrypt
rk1→2 = re-encryption key from pk1 to pk2
pk1
pk2
pk2sk1
Key Extraction
rk1→2
?
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
LS1pkℓ1LS2pkℓ2
LS3pkℓ3LS4pkℓ4
LS5pkℓ5LS6pkℓ6
LS7pkℓ7LS8pkℓ8
pkMadrid pkVicálvaro
pkSerrano pkChamberí
Re-encryption key
Serrano Chamberí Vicálvaro
Madrid
33
LoTAC – Macro-locations
• Access to – If he is in Vicálvaro on 01/06/2014
LS6pkℓ6LS7pkℓ7
LS8pkℓ8
pkVicálvaro
pkℓ8
LS8
pku1
Bob
skB skℓ8
Re-Encrypt rkVicálvaro → ℓ8
rkVicálvaro → ℓ8
τ
34
PrototypeServer Client
Custom GSM Network
35
LoTAC – Performance
36
LoTAC – PerformanceAvg. (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
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
38
References1. I. Ray and M. Kumar and L. Yu, “LRBAC: A Location-Aware Role-Based Access Control Model”,
ICISS 2006http://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 2001http://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 2005http://dx.doi.org/10.1007/11581062_27
4. S. Saroiu and A. Wolman, “Enabling new mobile applications with location proofs”, HotMobile 2009http://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 2012http://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 2014http://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
39
Thanks!
?
Elli AndroulakiIBM Zurich
Luka MalisaETH Zurich
Srdjan CapkunETH Zurich
joint work with:
Claudio [email protected]