Download - 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

[email protected]

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



?

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



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


τ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


τ1 = 14-20/07/2014


τ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


τ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


26

Collusion

pkℓ1

LS1

pkℓ2

LS2

pkB

Bob

pkD

David

skB skD

skℓ1skℓ2

τ2τ1


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


τ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


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]