Saman Zarandioon

1. Improving the Security and Usability of Cloud with User-centric Security Models Saman Zarandioon Defense Committee: Danfeng Yao (co-advisor), Vinod Ganapathy (co-advisor), Rebecca Wright, Uli Kremer, William Horne (HP Lab)

2. Introduction Distributed Computing Hardware Virtualization Utility Computing System Automation Web Services Computation/Resource as a Service What is Cloud? Attractive Features: Elasticity Pay-as-you-go Pricing Model Cost Effectiveness Global-scale Accessibility Easy Maintenance

3. Introduction DynamoDB S3 EC2 enterprise.com Integration Scenarios : Internal Integration Cloud-to-Cloud (C2C) Enterprise-to-Cloud (E2C) SaaS to SaaS/on-premises

4. Introduction Integration 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

5. 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

6. Public Cloud for Sensitive Data HIPAA • 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

7. Related Work • Shared/distributed/untrusted file systems Tradeoff between scalability and granularity (wrt. Key Management) • 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) • Grouping Files: file-groups, lockbox-key, key rotation Plutus: 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) • Our solution: Granular enough for hierarchies, scalable with respect to both key management and revocation

8. Key Management/Revocation Time A B a a C b c d D Alice Bob • Key-updating Schemes • Lazy Revocation, first introduced in Cepheus, postpones re-encryption until the next change • Reduces the overhead of revocation at the price of slightly lowered security • Adopted by all majors cryptographic file systems • Key Fragmentation, Key Regression • Traversing time backward • Key Updating Scheme • Formalized and Studied: Backeset al, “Secure Key-Updating for Lazy Revocation”. In Research Report RZ 3627, IBM Research, pages 327-346. Springer, 2005. • Flat

9. Key Management/Revocation / a b A B c e /B/D/f C E D h g f d Bob • Key-updating Schemes • Hierarchical Key Management Schemes • Access classes form a hierarchy • Access to a class assumes access to all of its descendants • Enables user to derive keys of descendants • Traversing space forward • 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. • Static with respect to time

10. Key Management/Revocation None of these schemes are capable of handling key regression and hierarchies simultaneously! • Key-updating Schemes • Hierarchical Key Management Schemes • Hierarchical Key Updating (HKU) Schemes

11. Key Management/Revocation Time / a b Space A B c e C E D Read /B/D/f h g f d Bob • Key-updating Schemes • Hierarchical Key Management Schemes • Hierarchical Key Updating (HKU) Schemes • Formal definition of HKU Schemes and their security • 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. Background: KP-ABE Encrypt Setup KeyGen Decrypt Delegate Very Expressible Decisional Bilinear Diffie-Hellman (BDH) assumption VipulGoyal, et al, CCS ’06 Ciphertexts labeled with sets of attributes Private keys associated with access structures Ciphertext’satts satisfy key's access structure => key can decrypt

13. Our AB-HKU Scheme Root user; Publishes the public parameters, outputs root key Root, reader, writer; derive a key to descendant node Writer; encrypt data with path and local time instances; Returns the ciphertext Reader; Decrypt cipher text using a recent key of its access class or one of its ascendants; return the object. Root, reader, writer; Lazily revokes users’ access

14. Our AB-SIGN Signature Scheme Sign Verify P(A)=True? • 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?

15. K2C Access Control Protocol Read /a/d/f /a/b/d /a/c/g /a /a/c • Participants • The Root User (System Admin) • Readers/Writers • Meta-data Directory: RAR, WAR • Data Store: Actual content • Keystore • Key Distribution • Client-side • Decentralized

16. Write(p,data) WriteKey(p) Get RAR Vector (p) RAR(p) Encrypt AB-HKU Sign AB-SIGN Put(p, [e,S]), RS Validate RS Done! Done!

17. Read(p) ReadKey(p) Get(p), RS Validate RS Value(p) = [e,S] Validate S Decrypt Data Data

18. Implementation 23 ms • 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

19. Performance Evaluation

20. Performance Evaluation

21. 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

22. Service Integration • Server-side 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-hocnon-secure techniques • Consumers need to fully trust service providers

23. OMOS Framework • 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

24. 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

25. High-level Architecture   c.com Service C Service B Service A Identity Management Protocol Phishing Attack Detector Container Secure Communication APIs ACL OMOS

26. Data Transfer -- Background • Optional: • Confidentiality: targetOrigin can be all-permissive ‘*’ literal • Authenticity: Manual sender’s origin validation • “Requires repetitive custom sanity check”. • “Tedious exercise which can be easily forgotten” • “In complex cross-domain interactions validating the origin becomes nontrivial” • Fragment Identifier/postMessage Channel: A. Barth, et. al., Stanford University, “Securing frame communication in browsers”, June 2009, Commun. ACM • 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 2010 • Studied two prominent users of the postMessage primitive, the “Facebook Connect” and the “Google Friend Connect” protocols • Discovered many security vulnerabilities • 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."

27. Remote Procedure Call Request/Response Socket API postMessage/Proxy iframe Communication Stack • Abstracts away the details of communication • Flexible APIs for providing and consuming services JSON-RPC JSON-RPC MHTTP MHTTP ACL ACL Mashup Datagram Protocol (MDP) Mashup Datagram Protocol (MDP) Datalink Datalink b.com 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 management • Connection establishment (3-way handshake) • Connection termination (Releasing resource) • Data transfer over connection (socket) • Addressing: domain name, virtual port number • Simple request/response – asyncRequest • Addressing: URL • asyncRequest(“http://a.com”) => XMLHTTPRequest • asyncRequest(“mhttp://b.com”) => mashlet-mashlet • asyncRequest(“http://b.com”) => cross-domain • Black-listing certain domains • (m.com, vport 1231) • (m.com, mhttp, vport 80, /documents) • A lightweight simple remote procedure call protocol • Addressing: Method name and parameters

28. Managing Identities DynamoDB S3 EC2 Alice@SFDC Alice@Google Alice@Zoho Alice@Amazon Alice@Microsoft Alice@Heroku Alice.me Alice 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

29. ( ,SP.com) Web2ID Authentication • 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 IdPto 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) SP.com I=Alice.me SID

30. Web2ID-Other Services • Attribute Exchange • Anonymize the attribute consumer • Mashlet relay framework • Authorization Delegation • Mode 1: User’s identity known to the consumer (Delegation Certificate) • Mode 2: Protecting user’s identity from the consumer (Opaque Token)

31. Performance Evaluation

32. 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

33. Conclusions Resources Control • 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

34. Future Work Extension/improvement opportunities: • Off-loading K2C key distribution to cloud • Using cloud for client-side cryptography • Backend authentication in presence of untrusted client

35. Thank You!

36. JSON-RPC • A lightweight simple remote procedure call protocol • Addressing: Procedure Name, Arguments

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