Enhancing Privacy: Zero-Leak Security Architecture for Social Networking Applications

1. SoKey: New Security Architecture for Zero-Possibility Private Information Leak in Social Networking Applications At IEEE CQR 2011, Naples FL J. W. Keister, H. Fujinoki, C. W. Bandy, and S. R. Clinton {jkeiste, hfujino}@siue.edu, {slickenbrock, bandyguy}@gmail.com Department of Computer Science Southern Illinois University Edwardsville CQR2011/001

2. Background SoKey – Socially Keyed Zero-Leak Design • Private information leaks in the Internet have been a serious problem • 77 millions customers’ accounts in Sony PlayStation Network have been intruded (April 2011). Sony admitted that stolen customer information may include their credit card information. • Personal information was leaked from Amazon’s server (March 2008) Due to a system bug (not by intruders), real names of their users were viewable by any other users • A server owned by an adult shop was intruded and the stolen customers’ information was posted in the Internet (March 2010). Real name of the customers Their real mailing and e-mail addresses The lists of the products ordered by the customers CQR2011/002

3. Problems SoKey – Socially Keyed Zero-Leak Design • In the client-server model, users are required to upload their private • information to a server. • Information leaks can happen in many different ways, making prevention • of information leaks from servers almost impossible. - Due to system bugs - Unpredictable intrusion techniques used by attackers - Due to “attacks” by insiders, including the security administrators • Once users upload their private information to a server, it is out of their • control. • Private information stored at a server sometimes needs to be shared by • legitimate users, who have diverse access rights. CQR2011/003

4. Problems Unauthorized Users (Intruders)    Client Host Client Host       Client Host Server Host - Unauthorized access from inside - Unauthorized access from outside Legitimate Users Intrude as a root Intrude as a root Intrude as a root Internal Attackers (Betrayers) - client’s private information SoKey – Socially Keyed Zero-Leak Design Upload Upload Upload CQR2011/004

5. Hierarchical Nested Multi-Level Access Control Information the lowest level users have access Author Author Information a medium level users have access Information the highest level users have access Administrator Intruders SoKey – Socially Keyed Zero-Leak Design - A model for an application w/ complex access control to shared data CQR2011/005

6. Design Requirements The contents of authors’ information is never released to unauthorized users Contradicting requirements SoKey – Socially Keyed Zero-Leak Design • Legitimate users (authors) share their personal information with other • users (audience), each of whom has a different access light. • Authors upload their personal information to a SNS server. • Personal information created by each author must be protected:  Even when intruders successfully obtain the root access at a server.  Even when internal administrators involve in information theft  Even when intruders successfully obtain the root access at a user’s client host. CQR2011/006

7. Project Objectives After all, for the benefits of both service providers and consumers SoKey – Socially Keyed Zero-Leak Design • To demonstrate that “zero-leak network design” is possible for SNS • applications, which require complex access controls. • To mitigate fear from novice network users in using security-sensitive • network applications • To encourage the industry to adopt more secure security design(s) that • eliminates possibility of their customers private information. • We designed and built a new security architecture for SNS applications, • SoKey for the above objectives. (SoKey = “Socially Keyed” ) CQR2011/007

8. SoKey Zero-Leak Security Architecture SoKey – Socially Keyed Zero-Leak Design • Authors: SNS users who post their personal information • Audiences: SNS users who view other authors’ information (Each author can be an audience for other authors) • Root Security Level (RSL) The security category only the owner (author) of the information can access • Controlled Security Level (CSL) The level of information accesses for audiences to an author CSL has a hierarchical nested multi-level access control layers • User Information (UI) The information only for an author • Master Key SoKey encrypts any security-sensitive information stored in an SNS server. The master key encrypts the private keys. CQR2011/008

9. UI RSL CSL1 User’s Local Computer MASTER MASTER CSL2 Author CSL2 CSL3 CSL1 CSL3  Encrypt  Encrypt  Encrypt  Encrypt  Create  Create • R-Asymmetric Private Key  Transmitted SNS Client-Side Process RCSL3 RCSL1 RCSL2 RCSL2 RCSL1 RCSL3 • U-Asymmetric Public Key RPM • Master-Symmetric Key UCSL2 UCSL1 UCSL3 + + + CQR2011/009

10. CSL1 Audiences Encrypted Encrypted Encrypted CSL2 CSL1 CSL3 RCSL2 RCSL3 RCSL1 UCSL2 A CSL1 Audience Author UCSL1 Decrypt Decrypt Decrypt UCSL2 UCSL3 UCSL3 Information published (stored) at an SNS server Plain Information (open to anyone) CQR2011/010

11. CSL2 Audiences Encrypted Encrypted Encrypted CSL2 CSL1 CSL3 RCSL2 RCSL3 RCSL1 UCSL2 A CSL2 Audience Author UCSL2 Decrypt Decrypt UCSL3 UCSL3 Information published (stored) at an SNS server Plain Information (open to anyone) CQR2011/011

12. CSL3 Audiences Encrypted Encrypted Encrypted CSL2 CSL1 CSL3 RCSL1 RCSL2 RCSL3 UCSL2 A CSL3 Audience Author UCSL3 Decrypt UCSL3 Information published (stored) at an SNS server Plain Information (open to anyone) CQR2011/012

13. Master Key Server SoKey – Socially Keyed Zero-Leak Design • Master Key protects the authors’ information in an SNS server from • intruders and internal betrayers, but where SNS authors should keep it?  Storing the master key in an author’s local client host computer When intruders successfully obtain the root access at a user’s local host, they obtain full access to the user’s information at an SNS server. E.g., intruders can obtain the master key and identify the user’s SNS account using a spyware and keylogger.  Write down the master key in a memo If the memo is lost, the author will lose his SNS account and can never get back his information in the account. CQR2011/013

14. Master Key Server Master Key Server Hash Master Key Master Author Hash Value Hash Value First Name Last Name One-way Hashing Phone Number Name of the SNS SoKey – Socially Keyed Zero-Leak Design Master Key Table CQR2011/014

15. Master Key Server Master Key Server Hash Master Key Master Key Request Author Hash Value Hash Value First Name Last Name One-way Hashing Phone Number Name of the SNS SoKey – Socially Keyed Zero-Leak Design Master Key Table The MKS does not:  Authenticate who this author is.  Know whose master key it is.  Know for which SNS server the key is for. Recovered master key • MKS scans the MKT, looking • for the matching hash • Sends back the master • key for matching hash. CQR2011/015

16. SoKey Prototype SoKey – Socially Keyed Zero-Leak Design • Prototype that implemented the • zero-leak SNS design • The prototype was used as the • demonstration for user survey CQR2011/016

17. Possible Stumbling Blocks SoKey – Socially Keyed Zero-Leak Design • The users’ accounts become black box, which security administrators and law • enforcement authorities can not access even with a court’s search warrant. • When a user with a certain access right is purged from that security class, • a new UCSL-X should be created and distributed to all other users in the class. • The public key for a CSL (UCSL-X) is manually transmitted to each audience. (This problem is solved if each author has a certificate) • Client hosts are hijacked beforehand. (intruders can copy the master key as soon as it is created) We believe that some solutions can be used to prevent DoS attacks to a MKS (except for “flooding attacks to deplete local link bandwidth to a MKS) CQR2011/017

18. Another “Zero-Leak” Design Shipping Request Approval Shipping Confirmation Request for Approval Intruder Product Delivery Product Order Product information Payment information Customer SoKey – Socially Keyed Zero-Leak Design Credit Card Company Shipping Carrier Online Web Shop Server Shipping information CQR2011/018

19. Another “Zero-Leak” Design Shipping Request Request for Approval Intruder Intruder Product Order Customer SoKey – Socially Keyed Zero-Leak Design Credit Card Company Shipping Carrier Online Web Shop Server CQR2011/018

20. SoKey – Socially Keyed Zero-Leak Design CQR2011/018

21. Survey Results SoKey – Socially Keyed Zero-Leak Design CQR2011/019

22. Survey Results No (10.6%) No (7.7%) YES (89.4%) YES (92.3%) No Answer = 0% (for (a) and (b)) (b) Those no participating to a SNS (a) Those participating to a SNS SoKey – Socially Keyed Zero-Leak Design Result of the question if a responder is aware that if someone gains access to a social networking database, his/her personal information can be stolen from that database CQR2011/020

23. Survey Results YES (33.9%) No Answer = 0% No (66.1%) SoKey – Socially Keyed Zero-Leak Design Results of the question if a responder would continue to use a SNS after someone had illegally gained access to the SNS’s database and could view any person’s account CQR2011/021

24. Survey Results YES (29.1%) Uncertain (31.3%) No Answer = 0% No (39.7%) SoKey – Socially Keyed Zero-Leak Design Result of the question if a responder is willing to provide his/her personal information to a social networking site CQR2011/022

25. Conclusions SoKey – Socially Keyed Zero-Leak Design • We proposes a new architecture that guarantees no privacy leak for SNS • applications. • We developed a prototype of SoKey SNS application to demonstrate the • feasibility of the design. • Our survey based on the demonstrations of SoKey SNS will contribute to • many Internet users • We identified possible stumbling blocks for SoKey SNS application. • They are worth solving, to realize the zero-leak SNS applications. CQR2011/024

26. Problems External Unauthorized Users (Intruders)          Server Host Legitimate Users SoKey – Socially Keyed Zero-Leak Design Client Host Client Host Client Host CQR2011/005

27. Encrypted Encrypted Encrypted CSL2 CSL1 CSL3 RCSL3 RCSL2 RCSL1 UCSL2 A CSL1 Audience A CSL2 Audience A CSL3 Audience Author UCSL2 UCSL1 UCSL3 Decrypt Decrypt Decrypt Decrypt Decrypt UCSL3 UCSL2 UCSL3 UCSL3 Information published (stored) at an SNS server Plain Information (open to anyone) CQR2011/025

28. SNS Server (SNS Site A) Master Key Table 1024-byte nonce  1024-byte nonce       32-byte hash + master key  Retrieved master key  Calculate 32-byte hash Master Key Server User’s Host SNS Server (SNS Site X) SNS Server (SNS Site B) SoKey – Socially Keyed Zero-Leak Design CQR2011/016