Enforcing Location and Time-based Access Control on Cloud-stored Data
-
Upload
centro-de-investigacion-para-la-gestion-tecnologica-del-riesgo-cigtr -
Category
Technology
-
view
280 -
download
0
description
Transcript of Enforcing Location and Time-based Access Control on Cloud-stored Data
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]