LifeSocial A P2P-based Online Social Network

Transcription

1 LifeSocial A P2P-based Online Social Network Project Group A Distributed Framework for Social Networks UPB SS2011 PG-Framework Lecture-05 LifeSocial-a-P2P-based-OSN.ppt Dr.-Ing. Kalman Graffi graffi@mail.upb.de Fachgruppe Theorie verteilter Systeme Fakultät für Elektrotechnik, Informatik und Mathematik Universität Paderborn Fürstenallee 11, D Paderborn, Deutschland Tel , Fax

2 Overview 1 Online Social Networks 2 Motivation for a Peer-to-Peer Approach 2.1 Decentral OSNs 2.2 Safebook 3 LifeSocial 3.1 Requirements for a DHT-based OSN 3.2 Architecture Details of LifeSocial 3.3 LifeSocial Plugin Overview 3.4 Peer and Plugin Communcation Principles 3.5 FreePastry and PAST 3.6 Security 3.7 Practical Distributed Access Control 3.8 Deletion of Data 3.9 Architecture Component: Dispatcher 3.10 Architecture Component: Cache 3.11 Plugin Examples 4 Further Research Challenges Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 2

3 1 Online Social Networks What are Online Social Networks technically? Web-based applications (StudiVZ, Facebook, MySpace, Xing) Provide different services for community members Personal information and photos Events Games Plugin architecture Friends Social interaction Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 3

4 Goals and Motivations Users want System providers want Storing and searching for content Profiles, friend lists, Pictures, shared Wall editing, User to user interaction Chatting, VoIP, Games Security Access control on their data Secure, confidential communication High profit Many users Personalized advertisements Low operational costs For servers, electricity, cooling For personnel, legal issues Controlled Quality of Service To attract and keep users Providing reliable, high quality services Fun! Money! Can the requirements be implemented decentrally? Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 4

5 Centrally hosted OSNs Web-based solution Centrally hosted data Benefits for the provider Data used for marketing Issues Costs / scalability Trust in provider You cannot delete your account, only deactivate (Facebook) Limited application scope No real user-to-user interaction Wide community focus Must share information with the world Although only meant for family Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 5

6 2 Motivation for a Peer-to-Peer Approach Online social networks are very popular Need for decentralization Host your own community and more security Keep control of your data and cooler applications Supporting real-time interaction Server Capacity Consumer PC Capacity (PCs sold since 2008) Resources are available and powerful Can we build a P2P-based online social network? P2P ~ paradigm using only the user devices to create infrastructures Are the public research results useable? Are they combinable? Is the quality still good? Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 6

7 Peer-to-Peer Applications Many legitimate peer-to-peer applications illegal file sharing Source: Above logos copied from the respective web page Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 7

8 2.1 Decentral OSNs Trends Freedom from providers - decentralization Put privacy first - security Distributed OSNs Federation of private webservers Store your data on trusted friends BUT: do you have a webserver? Functionality Friend-of-a-friend Data-centric, similar to yellow pages HelloWorld Not existent anymore Diaspora Great marketing, $ for a promise Buggy and bad code Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 8

9 2.2 Safebook Developed at Eurecom & TU-Darmstadt Main idea: Use only friends in overlay Results in some security Main issue: Performance Requires large friend base per user See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 9

10 3 LifeSocial History Aiming at applicable results in p2p research Some lessons learned Build a running version first Improve later Goal Facebook-like user experience Basis functionality extendible through plugins Data-centric (profiles) and user-to-user (chat,video) interaction BUT: security guarantees Operator view Completely p2p-based BUT: with quality of service control and guarantees Research New application leads to new requirements New requirements to new results See: K. Graffi et al., A Distributed Platform for Multimedia Online Communities, In: Dr.-Ing. IEEE Kalman ISM 08, Graffi, LCN 09, FG P2P 10, Theorie CCNC verteilter 11 Systeme 10

11 User View: Rich Functionality Wide set of functionality Plugin-based application: Profile, Login, Friends, Groups, Mails, Photos, Chat, Whiteboard, Calendar Flexible GUI GUI-Framework like in Eclipse Fast and user-friendly performance See: K. Graffi et al., LifeSocial.KOM: A P2P-based Platform for Secure Online Social Dr.-Ing. Networks, KalmanIn: Graffi, IEEE FG P2P 10, Theorie 2010verteilter Systeme 11

12 Provider View: Monitoring and Management Monitoring and managing global system statistics See: K. Graffi et al., Monitoring and Management of Structured Peer-to-Peer Systems Dr.-Ing. In: IEEE Kalman P2P 09, Graffi, FG Theorie verteilter Systeme 12

13 3.1 Requirements for a DHT-based OSN Functionality Like Facebook Extendible through plugins Different to typical p2p applications Platform to host a wide set of applications General platform Core functionality as a basis Communication patterns? Extendible out of the box App-functionality, app-market? Data access patterns Read: Independent whether friends are online Write: create new content Update: update previous data Consistently for all copies of the data Delete: securely remove data Community-enforced deletion of illegal content See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 13

14 Requirements for a DHT-based OSN Suitable distributed data structures Supporting a wide range of apps Heterogeneous peer capacities and data access patterns Security Root of trust, user authentication Confidential, integer, auth. communication Access control: read/write/delete rights How to address attackers Controlled Quality of Service Guarantees on system behavior? Response time, availability Self-adaptive behavior Several hands-on challenges How to implement Various search mechanisms Bootstrapping, NAT-handling An extendible graphical user interface See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 14

15 3.2 Architecture Details of LifeSocial GUI Framework: Extendable and flexible Provides an interface to the Plugins Plugins: Functionality of online social networks (and more) Easy Plugin-to-Plugin communication Over shared storage Over Plugin ID based messaging Information Cache: Enables the Plugins to reuse the data Hides the asynchronous effects of distributed data storage Monitoring and Management: Provides statistics on system behavior Enables the provider to control the service quality Secure Message Dispatcher: Provides secure, low-delay Plugin-to-Plugin communication Integrate offline messaging feature Secure Storage Dispatcher + access control: Storage and retrieval of data objects (PAST) Replicates data and guarantees their availability Structured Peer-to-Peer Overlay Connects the nodes and enables inter-peer communication Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 15

16 3.3 LifeSocial Plugin Overview Everything is a Plugin Stand-alone applications (apps) Implement OSN functionality (and more) Mandatory or optional Building blocks combinable Communicate over storage messages Traditional OSN functionality Login, Profile, Friends, Groups, Search, Photos, Messages, Chat Extended OSN functionality Multi-chat, Whiteboard, Calendar, Tweets Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 16

17 Plugins Extendability Plugins are OSGI-based See seminar paper Can be loaded on runtime on demand Version updates over the Internet possible Idea: Plugin-Store hosting new Plugins Rapid application development Plugin interfaces are open and combinable Allows for Unix-style reuse of components Core functions and GUI separated Interfaces See upcoming seminar talk OSGi Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 17

18 3.4 Peer and Plugin Communcation Principles Two plugins communicate via messaging Addressing: Peer-ID Routing in DHT Plugin-ID in the Peer Analogous to IP / Port Applications Chatting Playing Streaming Audio Video PluginID PluginID Peer ID Peer ID Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 18

19 Peer and Plugin Communcation Principles Two plugins communicate via storage Common storage in DHT Store under ObjectID Retrieve from ObjectID Applications Profile Personal wall Modifiable friend list Photo album Calendar Peer ID PluginID PluginID Peer ID DHT Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 19

20 3.5 FreePastry and PAST FreePastry based on Pastry, DHT Documents are mapped to peers Every ObjectID has a responsible peer Contacted by document owners and requesters FreePastry routes to responsible peer Add-on PAST manages the data replication Node 1008 queries item 3000 Responsible peer found Principle of ID-based routing Use shortcuts/fingers Responsible for Responsible for Responsible for Plugin-to-Plugin communication PluginID based messaging Send message to PeerID Header information: PluginID Shared storage Distributed storage Additional fine-grained access control Example data object Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 20

21 Building Storage Keys: Two Rules To be able to store/lookup data Associated with a user Use user identifier (user name) To build the storage key To be able to store/lookup data Associated with certain known criteria Use criteria value to build the storage key To avoid key collisions Use Plugin identifiers or/and known keywords to build storage keys Storage key = hash( address + pluginid) Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 21

22 Distributed Linked List Example Photo Plugin: 1. Albums 2. Images Albums contain a collection of images. Distributed Linked List: 1. Every single image is stored separately 2. Album objects hold a list of storage keys of the images 3. An object holds a list of storage keys of the albums High granularity of stored objects Better load balancing of the resources. See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 22

23 Positioning in the Network Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 23

24 PAST - Replication Provides a read / write access Write Object under a specific ObjectID Read Object und ObjectID Replication Automatic replication of data on 5 closest peers in leaf set Observes peer joins/leaves see Key-based Routing (KBR) Interface Adaptation in LifeSocial Modify data (before: write-once) Retrieve data Modify Write under same ObjectID Still some drawbacks! See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 24

25 Deletion of Documents Originally not supported by PAST Approach in LifeSocial Overwrite with tombstone object Tombstone object is replicated Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 25

26 3.6 Security Root of Trust Username and passphrase private key Deduce private/public key at any PC NodeID = UserID = public key Buddy List List of friends s UserIDs Checked if online during login Secure communication Confidential, integer, authenticated Encrypt every message with NodeID (=PubKey) of addressed peer Requirements for access control No unauthorized user can read content Author is authenticated Content integrity can be checked False authorship can be rejected Data objects should be signed Data object must be replicable Replication Multiple storage of the same content Find copy to read Find all copies to write consistently Replication independent of security Efficient mechanisms usable See upcoming seminar talk Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 26

27 Used Keys Asymmetric Key pair for signing and encryption 2048 bit RSA-Key serves the purpose Symmetric Needed for item encryption 128 bit AES-Key Storage Local storage for later reusage Java KeyStore secures keys with password Quick access to keys The Public Key Infrastructure User-/NodeId String representation of users public key Enlarge Id-range of FreePastry Public key available for everyone Trust must be obtained individually Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 27

28 Evaluation - Data Overhead Message Increasing message size does not affect overhead Constant overhead because of wrapping class Less than 2 kb acceptable, especially for large messages Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 28

29 Evaluation - Time Overhead Message Encryption and decryption time are independent from message size Most time must be needed for administrative processes Obtaining keys, building CryptedItem Initially obtaining public key from network 300ms! Therefore local storage of public keys unavoidable Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 29

30 1extract 3.7 Practical Distributed Access Control Step 1: PeerID = UserID = PublicKey SharedItem objectid Header 3 [userid A] = Pub User A = f(username, passphrase) Privileged users Payload userids are public keys [userid B] = Pub User B Step 2: wrap symmetric key with public key 4 Attach enc. keys to data object Serialized and encrypted with symmetic key 2 Signed CryptedItem objectid Key list 5 Symmetric Key Encrpyted with Pub User A Byte array containing encrypted SharedItem userid A key A userid B key B userid C key C Signature Symmetric Key Encrpyted with Pub User B See: K. Graffi et al. (Norwegian Information Security Lab) Practical Security in P2P-based Dr.-Ing. Social Kalman Networks, Graffi, FG In: Theorie IEEE LCN 09 verteilter Systeme 30

31 Evaluation - Data Overhead Shared Item Overhead depends on number of privileged users Each additional privileged user causes data overhead of about 413 bytes Comes from added userids and wrapped keys to the key list Much more overhead than in message encryption but acceptable Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 31

32 Evaluation - Time Overhead SharedItem Encryption time rises linear with number of privileged users Key wrapping time per user = 0.36 ms Decryption time constant because only one key has to be unwrapped Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 32

33 3.8 Deletion of Data Deletion is essential To control own data Delete unwanted private data Several approaches feasible Good: Independent of replication Replication can be improved Bindings are to be avoided Idea: Tombstone objects Empty data elements With timestamp Overwrite old data Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 33

34 Deletion of Illegal Content Note: Not implemented in LifeSocial Idea: Community-based decision For a quorum of read-enabled peers Quorum may decide on validity of content (picture) Secured decision: If to delete: Take somehow influence on replication Danger of misuse by attackers Quorum: multicast group SCRIBE: Extension of FreePastry To create and manage multicast groups Allows to send messages to all group members Multicast is also useful for other purposes Group chat Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 34

35 3.9 Architecture Component: Dispatcher Message Dispatcher Sort incoming messages by PluginID Attach appropriate headers to sent messages Storage Dispatcher Handles storage access Decouples from overlay events Asynchronous storage access Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 35

36 3.10 Architecture Component: Cache Information Cache stores Incoming messages (under PluginID) Requested ObjectIDs (under ObjectID) Also for outgoing data/messages Help for Plugins Plugins pick the required objects Anytime as often as needed Like: Cache.get(ObjectID) Instant results Possible states: Available: Object is returned Pending: Object will come soon Lookup process still ongoing Fail: Object not available Timeout occured Plugins may react instantly Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 36

37 3.11 Plugin Examples Profile-Plugin Functions Register (create new profile data) Change a profile field Get profile item Write current profile item Profile Item Created while registration One specific data item Personal information Picture ID of Profile Item Hash of concatenation of Username Profile-Plugin ProfileItemToken Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 37

38 Friends Plugin Friends-Plugin Functions: Send and receive friend requests Based on UserID Queued in open requests list Accept or decline friend request Check for undelivered messages Get friends list item to UserID Friends-List Item ID Hash of concatenation of Username Friend-Plugin FriendsItemToken Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 38

39 Groups Plugin Functions: Create group Join and leave group Send (and receive) messages to all group members They are stored in a specific message queue (for the Groups-Plugin) Check for undelivered messages Show all groups of a user Get Groups-list Item to UserID Show all users of a group Get Groups-Item to Group-ID Group ID Hash of concatenation of Groups-Plugins Group-Name Groups-List ID Hash: Username + Groups-Plugin + GroupsItemToken Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 39

40 Messaging and Chat- Plugin functionality (messaging) Data items: Inbox and Outbox Send message to UserID List of messages Append message in User s inbox Get Inbox Item, get Outbox Item message 1 message 2 Message 3 Check for undelivered messages Delete message entries Offline messaging Approach for undelivered messages Destined to Plugins Put them in Message Queue Peer ID PluginID PluginID Peer ID Peer ID PluginID DHT PluginID Peer ID Retrieve when online again Chat Plugin Functions Send message to UserID:PluginID Specific PluginID to be used Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 40

41 Essential Distributed List Operations Useful, but not implemented in Lifesocial Append list entry Add new entry to a List-Item ListItem identified by ObjectID Add Entry write permission without ability to modify previous entries Useful for messaging, friend lists, group lists Delete list entry Delete previously set entry Previous authorship required Useful for group lists, multicast groups Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 41

42 Screenshots Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 42

43 Screenshots Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 43

44 Screenshots Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 44

45 4 Further Research Challenges No p2p framework as such Limited functionality Untested and incomplete Like in real software projects No clear interfaces But in OSGi: interfaces defined Interfaces unclear Clear separation of functionality Allows to improve individual solutions Allows to build more advanced solutions A good starting point Many components already available It runs and can be tested (in small) Some bugs, but well documented Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 45

46 Challenges: Testing and Monitoring Monitoring and Management Integrated monitoring solution Implement a distributed control loop Self-learning and calibrating How to secure control signals? Integrated testing facility How to test large scale networks What kind of workload to induce? Which metrics to measure? Support for heterogeneity Data access patterns are heterogeneous Peer capacities are heterogeneous Most solutions assume homogeneity Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 46

47 Challenges: Security Storage and replication attacks (Joining) attackers may be responsible for crucial data in DHT Attacks on: read/write/delete Routing challenges Malicious nodes may attack routing Colluding malicious nodes? Compatible with current Routing? Accounting in DHT Introduce accounting and billing for premium services Get money for clicking ads Pay money for using specific apps How to setup a secure distributed approach? Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 47

48 Challenges: Usability and new Plugins Finalization of the framework Which functionality to provide? Functionality to be tested Dummy programs and good documentation New / improved Plugins Showing the power of the framework Best if several basic-functions are combined Example: Wiki? Video-Chat? Game? Graphical user interface General toolset of visualizations How to manage internal information flows? Pull-based, Push-based? Impressive visualization of Plugins Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 48

49 Challenges: Marketing and Licenses Out of the box Usability Easy to install Pre-created set of bundles Licensing issue GUI and Website to follow Corporate Identity Look and feel of the social network Target group-specific: logos, flyers, advertisment Launching of press releases Licensing Which libraries are used? Which one to take for the P2P Framework? Maintenance Proper documentation Website representation / group pictures Community building Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 49

50 Questions?? Dr.-Ing. Kalman Graffi, FG Theorie verteilter Systeme 50