Saman Zarandioon

Defense Committee: Danfeng Yao (co-advisor), Vinod Ganapathy (co-advisor), Rebecca Wright, Uli Kremer, William Horne (HP Lab)

Improving the Security and Usability of Cloud with User-centric Security Models

2

Introduction

What is Cloud?

Computation/Resource as a

Service

Hardware Virtualization

Web Services

Distributed Computing

System AutomationUtility Computing

Attractive Features:ElasticityPay-as-you-go Pricing ModelCost EffectivenessGlobal-scale AccessibilityEasy Maintenance

EC2

4

Introduction

Integration Scenarios :Internal IntegrationCloud-to-Cloud (C2C)Enterprise-to-Cloud (E2C)SaaS to SaaS/on-premises

S3

DynamoDB

enterprise.com

5

IntroductionIntegration Challenges:

Diversity and distributed nature of cloud More versatile and adaptive integration

Security and Privacy Challenges: Hardware and software span multiple trust domains Dynamism and fluidity of data Multi-tenancy services

Contributions: K2C: Crypto. Access Control Protocol for Untrusted Storage OMOS: Client-side Integration Framework Web2ID: User-centric identity management solution

User Authentication Single Sign-on Authorization Delegation Attribute Exchange

6

Access Control to Untrusted Cloud

Contributions: Scalable and secure key-updating scheme for access

hierarchies and attribute-based signature scheme Cryptographic access control protocol for existing

untrusted cloud services with scalable revocation Open crypto lib for KP-ABE and HIBE encryption

schemes

7

HIPAA

Public Cloud for Sensitive Data Health-care provider, Public cloud

storage HIPAA (Health Insurance Portability and

Accountability Act) Protected Health Information (PHI) Access Control Collaboration and Easy Sharing Distributed Administration

Traditional Access Control Omniscient reference monitor Cloud? Untrusted Consumer? Un-scalable

Crypto. Access Control Shared/untrusted file systems

Related Work Shared/distributed/untrusted file systems

Tradeoff between scalability and granularity (wrt. Key Management)1.A key list along with every data object, one entry for each user, access key encrypted with user’s public key (BFS , Farsite, PASIS, PAST, SiRiUS)

2.Grouping Files: file-groups, lockbox-key, key rotationPlutus: Kallahalla et. al., “Scalable secure file sharing on untrusted storage,” in Proc. of FAST’03

Granular and Scalable?Shucheng Yu et. al., “Achieving secure, scalable, and fine-grained data access control in

cloud computing.” INFOCOM’10

Access revocation -> Re-encryption (Un-scalable wrt. revocation)

1. Our solution: Granular enough for hierarchies, scalable with respect to both key management and revocation

8

Key Management/Revocation Key-updating Schemes

o Lazy Revocation, first introduced in Cepheus, postpones re-encryption until the next change

o Reduces the overhead of revocation at the price of slightly lowered security

o Adopted by all majors cryptographic file systems

o Key Fragmentation, Key Regressiono Traversing time backward o Key Updating Schemeo Formalized and Studied:

Backes et al, “Secure Key-Updating for Lazy Revocation”. In Research Report RZ 3627, IBM Research, pages 327-346. Springer, 2005.

o Flat 9

Bob

a

b

d

1t 2t

Time

c

a

C

Alice

D

A B

/Bh

Key Management/Revocation Key-updating Schemes Hierarchical Key Management Schemes

o Access classes form a hierarchyo Access to a class assumes access to all of

its descendantso Enables user to derive keys of descendantso Traversing space forwardo Formalized and Studied:

Blanton , “Key Management in Hierarchical Access Control Systems, 2007. PhD Thesis, Purdue University, Aug. 2007.

“Dynamic and Efficient Key Management for Access Hierarchies”. In Proceedings of the ACM Conference on Computer and Communications Security, 2005.

o Static with respect to time10

D

BA

/b

e

d

c

a

C Efg

h

Bob

/B/D/f

Key Management/Revocation Key-updating Schemes Hierarchical Key Management Schemes Hierarchical Key Updating (HKU) Schemes

11

None of these schemes are capable of handling key regression and hierarchies simultaneously!

Key Management/Revocation Key-updating Schemes Hierarchical Key Management Schemes Hierarchical Key Updating (HKU) Schemes

o Formal definition of HKU Schemes and their securityo Cryptree (Grolimund et al, Symposium on Reliable

Distributed Systems, 2006)• Wuala (A Distributed Online File System)• A tree constructed by cryptographic links• Complex data structure, high performance cost (updating O(n)

keys), unscalable, centralized administration

• AB-HKU: Concrete construction for HKU scheme• No complex data structure, Cloud Storage API, Scalable• Based on Key-Policy Attribute-based Encryption (KP-ABE)

Scheme

12

D

BA

/b

e

d

c

a

C Efg

h

Time

1t 2t

Space

/h

/Bh

/B/Dh

Bob/Bh

Read /B/D/f

Background: KP-ABE

Very Expressible Decisional Bilinear Diffie-Hellman

(BDH) assumption Vipul Goyal, et al, CCS ’06 Ciphertexts labeled with sets of

attributes Private keys associated with access

structures Ciphertext’s atts satisfy key's access

structure => key can decrypt

14

Setup abePubk1

MK

KeyGen Decrypt

M

Encrypt

FA,

C

M

Delegate

)()( FADGA

H

Our AB-HKU Scheme

15

),1( TInit k

Root user; Publishes the public parameters, outputs root key

)),;(,( jii vvKTDerive Root, reader, writer; derive a key to descendant node

),( oTEncryptWriter; encrypt data with path and local time instances; Returns the ciphertext

),( ),( CKDecryptiiv

Reader; Decrypt cipher text using a recent key of its access class or one of its ascendants; return the object.

),( ivTevokeRRoot, reader, writer; Lazily revokes users’ access

).

.....

).

.....(

)1(

)()1(

)1(

)(1)1(

1

j

n

vnd

undud

jnd

nndd

ttL

ttLttL

vvL

uvLuvL

}.,.,...,.

,.,.,...,.{

100

1100

ii vivnv

iiii

ttLttLttL

vvLvvLvvL

Our AB-SIGN Signature Scheme

16

PK

MSSign

VerifyP(A)=True?

A

K2C needs a signature scheme to: Verity the data is produced by

authorized user Integrity of stored data Verify validity of request (Request

Signature) (Anonymous)

KP-ABE, signature scheme?

REM

SKDecrypt

MSAREncryptE

RandomR

),(

)})ˆ{(@,(

MP SK))M(@S,PDelegate(K ˆ

:),Sign( MKP

:),,Verify( AMSM

17

/a

/a/b/d

/a/c

Read /a/d/f

/a/c/g

K2C Access Control Protocol Participants

• The Root User (System Admin)

• Readers/Writers

• Meta-data Directory: RAR, WAR

• Data Store: Actual content

• Keystore

Key Distribution• Client-side

• Decentralized

18

K2C Protocol

Write(p,data)WriteKey(p)

Get RAR Vector (p)

RAR(p)

Encrypt AB-HKU

Sign AB-SIGNPut(p, [e,S]), RS

Validate RSDone!

Done!

19

K2C Protocol

Read(p)ReadKey(p)

Get(p), RS

Decrypt Data

Validate S

Validate RSValue(p) = [e,S]

Data

Implementation KP-ABE / HIBE Crypto Library

Key policy language: S-Expression (and role=manager (> age 18))

Basic Construction Large Universe Construction Random Oracle Model

• li = 355 : [li@0=1, li@1=1, li@2=0, li@3=0, li@4=0, li@5=1, li@6=1, li@7=0, li@8=1, li@9=0]

• (< li 358) : (2 li@9=0(1(2 li@7=0(1(1(2 li@4=0(2 li@3=0(1 li@1=0 li@2=0)))li@5=0)li@6=0))li@8=0))

Pre-computing/Caching

20

ntpp p|t|

c

avac

ava

n 1policy Composite)...]orand([

operator ecomparativ a is

& attribute numberical a is )(

attribute symbolic a is

211

*}1,0{ G 23 ms

Performance Evaluation

23

Performance Evaluation

25

26

Client-side Integration Framework

Contributions: Design, implementation of a secure integration

framework specifically designed for client-side integration

Privacy-preserving user-centric identity management protocol

27

Service Integration Server-side Integration Client-side Integration

Pros: More aligned with AJAX architecture Reduces expensive HTTP calls

Cons: Lack of flexible and secure communication protocols,

development tools/frameworks Traditional security/communication protocols (WS-

Security, SSL) and identity management solutions such as SAML not applicable

Service providers use ad-hoc non-secure techniques Consumers need to fully trust service providers

Server-side Integration

Design Goals To ensure integrity of client-side service providers and consumers and

provide them with a secure infrastructure for interaction with each other and the end-user.

To provide a powerful abstraction that is flexible and easy to understand and use by mashup developers.

To support privacy-preserving and user-centric IDM To be compatible with all major browsers without any change or

extension to the browsers.

Prototype Webtop

28

OMOS Framework

29

Related Work

MashupOS, H. J. Wang, et al, (SOSP) 2007 , Microsoft Research

Sophisticated abstraction

OMash, S. Crites, et. al. ACM CCCS, 2008.

Inspired by MashupOS Simplifies the abstraction and removes the reliance on same origin policy

JSONRequest, Douglas Crockford

Subspace, C. Jackson, et al 2007, Microsoft Research

“throw-away” subdomains Mashlet’s cannot directly perform XMLHtmlRequest

SMash, F. D. Keukelaere ,et. al., 17th International Conference on World Wide Web, 2008, IBM Research

Hub mediates and coordinates all the communications

30

c.comService C

a.coma.com

Service A

b.comb.com

Service B

Secure Communication APIs

a.com b.com

c.com

OMOSA

CL

Phishing Attack Detector

Identity Management Protocol

High-level Architecture  

Co

nta

ine

r

Data Transfer -- Background1) Fragment Identifier/postMessage Channel: A. Barth, et. al., Stanford

University, “Securing frame communication in browsers”, June 2009, Commun. ACM

2) postMessage HTML5: S. Hana, et. al., University of California, Berkeley, “The Emperor's New APIs: On the (In)Secure Usage of New Client-side Primitives”, W2SP 20101) Studied two prominent users of the postMessage primitive, the “Facebook Connect”

and the “Google Friend Connect” protocols

2) Discovered many security vulnerabilities

3) Inconsistency: "In our evaluation, we also observed a strange inconsistency —developers, belonging to the same organization and sometimes of the same application, used the primitives safely in some places while using them unsafely in others." 31

o Optional: o Confidentiality: targetOrigin can be all-permissive ‘*’ literalo Authenticity: Manual sender’s origin validation

o “Requires repetitive custom sanity check”.o “Tedious exercise which can be easily forgotten”o “In complex cross-domain interactions validating the origin becomes nontrivial”

32

Communication Stack

b.com

Remote Procedure Call

Request/Response

Socket API

postMessage/Proxy iframeDatalink

Mashup Datagram Protocol(MDP)

MHTTP

JSON-RPC

Datalink

Mashup Datagram Protocol(MDP)

MHTTP

JSON-RPC

a.com

Actual transfer of data, Addressing: DOM ref (iframe[i])(De)Fragmentation/Reordering (arbitrarily big data obj.)Piggybacking, lazy-send, frequent events/small objects

Handles connection managementConnection establishment (3-way handshake)Connection termination (Releasing resource)Data transfer over connection (socket)Addressing: domain name, virtual port number

Simple request/response – asyncRequestAddressing: URLasyncRequest(“http://a.com”) => XMLHTTPRequestasyncRequest(“mhttp://b.com”) => mashlet-mashletasyncRequest(“http://b.com”) => cross-domain

A lightweight simple remote procedure call protocolAddressing: Method name and parameters

Abstracts away the details of communication Flexible APIs for providing and consuming services

AC

L

AC

L

Black-listing certain domainso (m.com, vport 1231)o (m.com, mhttp, vport 80, /documents)

34

Managing Identities

Lack of unified provisions for IDM Ad-hoc solutions, new identity for each

provider, isolated, corss-reference in mashups

URL is tangible, clickable, user-friendly OpenID supports this model

DynamoDB

S3

EC2

Alice@SFDCAlice@Google

Alice@Zoho

Alice@Amazon

Alice@MicrosoftAlice@Heroku

Alice

Alice.me

35

Alice.meAlice.me

Alice

Web2ID Authentication

HTTP ServerAlice.me

Service ProviderSP.com

SP.comSP.com

Alice

Alice.meWeb2ID:

Log in

Web2ID:

Log in

Browser

I=Alice.me( ,SP.com)SID

SP.com

OpenID Originally designed for bloggers Redirection-based approach not

suitable for Ajax-based Web-2.0 apps Requires trusted third party (the IdP) Privacy concerns: IdP will learn surfing

habits of the user Stateful: both SP and IdP to maintain

state

Our Web2ID Authentication Uses client-side asymmetric crypto,

eliminates the need for IdP Uses client-side communications, avoid

http redirections State is maintained in the client-side

(Stateless)

Web2ID-Other Services

Attribute Exchange Anonymize the attribute consumer Mashlet relay framework

Authorization Delegationo Mode 1: User’s identity known to the

consumer (Delegation Certificate)o Mode 2: Protecting user’s identity

from the consumer (Opaque Token)

36

MediatorMediator

SP.comSP.comAttProvider.comAttProvider.com

SP.com AttProvider.com

Alice

41

Performance EvaluationRSA Key Generation

0

10000

20000

30000

40000

50000

60000

70000

512 1024

Key Length

ms

IE

Firefox

Chrome

Safari

Opera

RSA Encryption/Decryption

0

500

1000

1500

2000

2500

Encryption Decryption

ms

IE

Firefox

Chrome

Safari

Opera

Summary Developed a scalable cryptographic access control framework

(K2C) for un-trusted cloud storage. "K2C: Cryptographic Cloud Storage With Lazy Revocation and Anonymous Access'', Saman Zarandioon, Danfeng Yao, and Vinod Ganapathy SecureComm, 2011. London, UK

Introduced OMOS framework for secure service integration in the client-side."OMOS: A Framework for Secure Communication in Mashup Applications'', Saman Zarandioon, Danfeng Yao, and Vinod Ganapathy,

ACSAC,  December 8-12, 2008, Anaheim, California, USA, Pages 355-364 

Presented Web2ID for identity management in mashup environments.Privacy-aware identity management for client-side mashup applications'', Saman Zarandioon, Danfeng Yao, and Vinod Ganapathy

In Proceedings of the Fifth ACM Workshop on Digital Identity Management (DIM). Collocated with ACM Conference on Computer and Communications Security (CCS). Chicago, IL. Nov. 2009., Pages 21-30

42

Conclusions User-centric security models Shifting certain parts of communication

and computation to the client-side Cloud Consumers:

More visibility and control Alleviates some security and privacy

concerns and fears

Cloud Providers: Reduces the burden of managing end-users'

identities and fine-granular access control Concentrate on their core services

43

Resources

Control

Future Work

Extension/improvement opportunities:Off-loading K2C key distribution to cloudUsing cloud for client-side cryptographyBackend authentication in presence of untrusted

client

44

45

Thank You!

56

JSON-RPC

A lightweight simple remote procedure call protocol

Addressing: Procedure Name, Arguments

57

c.comb.com

a.com

a.com b.com c.com

asyncRequest(“http://b.com”)

asyncRequest(“mhttp://a.com”)asyncRequest(“http://c.com”)

59

60

61