sokey: new security architecture for zero-possibility

SoKey: New Security Architecture for Zero-PossibilityPrivate 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 ScienceSouthern Illinois University Edwardsville

CQR2011/001

SoKey – Socially Keyed Zero-Leak Design

CQR2011/002

Background

• 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 includetheir 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 wereviewable 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/003

• In the client-server model, users are required to upload their private information to a server.

• Once users upload their private information to a server, it is out of their control.

• Information leaks can happen in many different ways, making prevention of information leaks from servers almost impossible.

• Private information stored at a server sometimes needs to be shared by legitimate users, who have diverse access rights.

Problems

- Due to system bugs- Unpredictable intrusion techniques used by attackers

- Due to “attacks” by insiders, including the security administrators


Client Host

Client Host

Client Host

Server Host

CQR2011/004

Problems

LegitimateUsers

Unauthorized Users(Intruders)

InternalAttackers

(Betrayers)

Upload

Upload

Upload

- client’s private information

Intrudeas a root

Intrudeas a root

Intrudeas a root


- Unauthorized access from outside- Unauthorized access from inside

CQR2011/005

Hierarchical Nested Multi-Level Access Control

Information the lowestlevel users have access

Information a mediumlevel users have access

Information the highestlevel users have access

- A model for an application w/ complex access control to shared data

Author

Author

Intruders

Administrator


CQR2011/006

Design Requirements

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

The contents ofauthors’ informationis never released tounauthorized users

Contradictingrequirements


CQR2011/007

Project Objectives

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

After all, for the benefits of both service providers and consumers

• We designed and built a new security architecture for SNS applications, SoKey for the above objectives.

(SoKey = “Socially Keyed” )


CQR2011/008

SoKey Zero-Leak Security Architecture

• Controlled Security Level (CSL)

• Master Key

• User Information (UI)

• Root Security Level (RSL)

• 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)

The security category only the owner (author) of the information can access

The level of information accesses for audiences to an authorCSL has a hierarchical nested multi-level access control layers

The information only for an author

SoKey encrypts any security-sensitive information stored in anSNS server. The master key encrypts the private keys.


CQR2011/009

MASTER

SNS Client-SideProcess

UI

CSL1

CSL2

CSL3

Create

User’sLocal Computer

Author

Create CSL1

CSL2

RS

L

CSL3

Transmitted

UCSL3RCSL3

+

+

+UCSL2

RCSL2

UCSL1RCSL1

RPM

Encrypt

RCSL3

Encrypt

RCSL2

MASTER

Encrypt

Encrypt

RCSL1

UCSL2UCSL2

UCSL2UCSL2

UCSL3UCSL3

UCSL3UCSL3

• R-Asymmetric Private Key• U-Asymmetric Public Key• Master-Symmetric Key

UIUI

UCSL1

A CSL1Audience

Decrypt

UCSL2

Decrypt

Plain Information(open to anyone)

Author

RCSL1Encrypted

RCSL2 Encrypted

RCSL3Encrypted CSL3

CSL1

CSL2

CQR2011/010

UCSL2

UCSL3

Information published(stored) at an SNS server

UCSL3

Decrypt

CSL1 Audiences

UCSL2

A CSL2Audience

UCSL3

Decrypt


Author

RCSL1Encrypted

RCSL2 Encrypted

RCSL3Encrypted CSL3

CSL1

CSL2

CQR2011/011

UCSL2

UCSL3


Decrypt

CSL2 Audiences

UCSL3

A CSL3Audience

Decrypt


Author

RCSL1Encrypted

RCSL2 Encrypted

RCSL3Encrypted CSL3

CSL1

CSL2

CQR2011/012

UCSL2

UCSL3


CSL3 Audiences

CQR2011/013

• 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

Write down the master key in a memo

When intruders successfully obtain the root access at a user’s localhost, 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.

If the memo is lost, the author will lose his SNS account and can neverget back his information in the account.

Master Key Server


CQR2011/014

Author

First NameLast Name

Phone NumberName of the SNS

One-wayHashing

Master Hash Value

MasterKey Server

Master KeyTable

Hash Master Key

Hash Value

Master Key Server


CQR2011/015

Author

MasterKey Server

Master KeyTable

Hash Master Key

Hash Value

The MKS does not:

Authenticate who this author is.

Know whose master key it is.

Know for which SNS server the key is for.

• MKS scans the MKT, looking for the matching hash

• Sends back the master key for matching hash.

Master Key Request

Recovered master key

First NameLast Name

Phone NumberName of the SNS

One-wayHashing

Hash Value

Master Key Server


CQR2011/016

SoKey Prototype

• Prototype that implemented the zero-leak SNS design

• The prototype was used as the demonstration for user survey


CQR2011/017

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

Possible Stumbling Blocks

(This problem is solved if each author has a certificate)

We believe that some solutions can be used to prevent DoS attacks to a MKS

• Client hosts are hijacked beforehand.(intruders can copy the master key as soon as it is created)

(except for “flooding attacks to deplete local link bandwidth to a MKS)


CQR2011/018

Another “Zero-Leak” Design

OnlineWeb Shop

Server

ShippingCarrier

Credit CardCompany

Customer

Shipping information

Product information

Payment information

ProductOrder

Request forApproval

Approval

ShippingRequest

ProductDelivery

ShippingConfirmation

Intruder


CQR2011/018

Another “Zero-Leak” Design

OnlineWeb Shop

Server

ShippingCarrier

Credit CardCompany

Customer

ProductOrder

Request forApproval

ShippingRequest

Intruder

Intruder


CQR2011/018

013: Are you interested in participating to a SNS?

002 (001): Do you participate in asocial networking site?

003 (003): How often do you use thesocial networking site(s)?

004 (004): Why do you use socialnetworking site(s)?

001: Are you familiar with “SocialNetworking Sites (“SNS”)”?

005 (005): Which of these types of information would you provide tothe SNS you are using?

006 (006): Do you have concernstowards SNS you are using, if any,and why do concern you? Check allthat apply and fill in comments.

009 (010): What reason(s) preventyou from participating in a SNS?

010 (011): What security issuesprevent you from using a SNS?Check all that apply.

If “security”is a reason

YES

YES

YES

NO

NO

NO

If “security”is not a reason

END

014: Are you aware of a fact thatif someone successfully gains illegalaccess to SNS’s database, yourpersonal information can be stolenfrom the SNS database (if you wereusing a SNS)?

Hint: SNS’s are network sites where manypeople can meet “on line” and exchangeinformation, including your personalinformation (if you like), through the siteswhile your identity is not disclosed (youcan be identified only by your “nickname”).















009 (010): What reason(s) preventyou from participating in a SNS?009 (010): What reason(s) preventyou from participating in a SNS?





YES

YES

YES

NO

NO

NO

If “security”is not a reasonIf “security”

is not a reason

END






CQR2011/019

Survey Results

0%

20%

40%

60%

80%

100%

1 2 3 4 5 6 7 8 9

1. Information Research 2. Business 3. Social Networking 4. School

5. News 6. Shopping 7. Gaming 8. e-mail 9. Others

Per

cen

tage

to

the

Tot

al R

esp

onse

s(i

.e.,

240

resp

onse

s)

Usage Categories

0%

20%

40%

60%

80%

100%

1 2 3 4 5 6 7 8 9





Per

cen

tage

to

the

Tot

al R

esp

onse

s(i

.e.,

240

resp

onse

s)

Usage Categories


CQR2011/020

YES (89.4%)

No (10.6%)

No Answer = 0%(for (a) and (b))

(a) Those participating to a SNS

YES (92.3%)

(b) Those no participating to a SNS

No (7.7%)

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

Survey Results


CQR2011/021

YES (33.9%)

No (66.1%)

No Answer = 0%

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

Survey Results


CQR2011/022

YES (29.1%)

No (39.7%)

Uncertain (31.3%)

No Answer = 0%

Result of the question if a responder is willing to provide his/her personal information to a social networking site

Survey Results


CQR2011/024

Conclusions

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

Server Host

CQR2011/005

LegitimateUsers

External Unauthorized Users(Intruders)

Client Host

Client Host

Client Host

Problems


UCSL1

A CSL1Audience

Decrypt

UCSL2

A CSL2Audience

UCSL2

Decrypt

Decrypt

UCSL3

Decrypt

UCSL3

A CSL3Audience

Decrypt


Author

RCSL1Encrypted

RCSL2 Encrypted

RCSL3Encrypted CSL3

CSL1

CSL2

CQR2011/025

UCSL2

UCSL3


UCSL3

CQR2011/016

1024

-byt

e no

nce1024-byte nonce

32-byte hash + master key

Calculate 32-bytehash

Retrieved master key

User’sHost

Master KeyServer

SNS Server(SNS Site B)

SNS Server(SNS Site A)

SNS Server(SNS Site X)

256-bit Hash Master Key

Master Key Table


sokey: new security architecture for zero-possibility

Documents