LifeSocial – A P2P-based Online Social Network

Transcription

LifeSocial – A P2P-based Online Social Network
Project Group
A Distributed Framework for Social Networks
www.p2pframework.com
Dr.-Ing. Kalman Graffi
Email: graffi@mail.upb.de
Fachgruppe Theorie verteilter Systeme
Fakultät für Elektrotechnik, Informatik und Mathematik
Universität Paderborn
Fürstenallee 11, D-33102 Paderborn, Deutschland
Tel.+49 5251 606730, Fax. +49 5251 606697
http://www.cs.uni-paderborn.de/fachgebiete/fg-ti.html
UPB__SS2011__PG-Framework__Lecture-05___LifeSocial-a-P2P-based-OSN.ppt
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
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
Plugin
architecture
Games
Friends
Social
interaction
3
Goals and Motivations
Users want
System providers want
Storing and searching for content
High profit
Profiles, friend lists, …
Pictures, shared “Wall” editing, …
User to user interaction
Chatting, VoIP, …
Games
Security
Access control on their data
Secure, confidential communication
Fun!
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
Money!
Can the requirements be implemented decentrally?
4
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
5
2
Motivation for a Peer-to-Peer Approach
Online social networks are very popular
Need for decentralization
Host your own community
and more security
Consumer PC Capacity
(PCs sold since 2008)
Keep control of your data
and cooler applications
Supporting real-time interaction
Server
Capacity
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?
6
Peer-to-Peer Applications
Many legitimate peer-to-peer applications
1999
2000
2001
2002
≠ illegal
file sharing
2003
2004
2005
2006
2007
2008
…
Source: Above logos copied from the respective web page
7
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, 200.000$ for a
promise
Buggy and bad code
8
2.2 Safebook
Developed at Eurecom & TU-Darmstadt
Main idea:
Use only friends in overlay
Results in some security
Main issue:
See upcoming
seminar talk
Performance
Requires large friend base per user
9
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
Dr.-Ing.
FGP2P’10,
– Theorie
verteilter
See: K. Graffi et al., “A Distributed Platform for Multimedia Online Communities”, In:
IEEE Kalman
ISM’08, Graffi,
LCN’09,
CCNC
‘11 Systeme
10
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
Dr.-Ing.
KalmanIn:
Graffi,
– Theorie
See: K. Graffi et al., “LifeSocial.KOM: A P2P-based Platform for Secure Online Social
Networks”,
IEEEFG
P2P’10,
2010verteilter Systeme
11
Provider View: Monitoring and Management
Monitoring and managing global system statistics
Dr.-Ing.
Kalman
Graffi,
FG – Theorie verteilter Systeme
See: K. Graffi et al., “Monitoring and Management of Structured Peer-to-Peer Systems”
In: IEEE
P2P’09,
2009.
12
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
13
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
14
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
15
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
16
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
OSGi
See upcoming
seminar talk
17
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
Peer ID
PluginID
Peer ID
18
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
Email
Calendar
PluginID
PluginID
Peer ID
Peer ID
DHT
19
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
1008
709
Use shortcuts/fingers…
1622
Responsible for
1008 + 1024
2011
1009-1622
1623-2011
2207
710-1008
660-709
2012-2207
1
659
612-659
2682
2
3
Responsible peer found
2208-2682
2906
2683-2906
611
3486-…
0-611
Principle of ID-based routing
3485
2907-3485
Responsible
for 3000
Responsible
for 2207 + 512
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
20
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(email address + pluginID)
21
Distributed Linked List Example
Photo Plugin:
1. Albums
2. Images
Albums contain a collection of images.
Distributed Linked List:
1.
2.
3.
Every single image is stored
separately
Album objects hold a list of
storage keys of the images
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
22
Positioning in the Network
23
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
24
Deletion of Documents
Originally not supported by PAST
Approach in LifeSocial
Overwrite with tombstone object
Tombstone object is replicated
25
3.6 Security
Root of Trust
Requirements for access control
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
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
26
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
27
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
28
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
29
3.7 Practical Distributed Access Control
Step 2:
Attach
enc. keys
to
data object
SharedItem
objectID
1
3
Header
Privileged users
Payload
extract
Step 1:
PeerID
= UserID
= PublicKey
= f(username,
passphrase)
[userID A] =
Pub
User A
userIDs
[userID B] =
Pub
are public
User B
keys
wrap symmetric key
with public key
2
Symmetric Key
Serialized and encrypted with
symmetic key
Signed CryptedItem
5
objectID
Byte array
containing
encrypted
SharedItem
4
Encrpyted
with
Pub
User A
Key list
userID A – key A
userID B – key B
userID C – key C
…
Signature
Symmetric Key
Encrpyted
with
Pub
User B
Dr.-Ing.
Kalman
Graffi, FGIn:
– Theorie
verteilter Systeme
See: K. Graffi et al. (Norwegian Information Security Lab) “Practical Security in P2P-based
Social
Networks”,
IEEE LCN’09
30
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
31
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
32
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
33
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 …
34
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
35
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
36
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”
37
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
“Username”
“Friend-Plugin”
“FriendsItemToken”
38
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)
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
“Groups-Plugins”
“Group-Name”
Groups-List ID
Hash: “Username”+”Groups-Plugin”
+”GroupsItemToken”
39
Messaging and Chat- Plugin
Email functionality (messaging)
Data items: Inbox and Outbox
Send message to UserID
Append message in User’s inbox
Get Inbox Item, get Outbox Item
Delete message entries
List of messages
message 1
message 2
Message 3
…
Offline messaging
Approach for undelivered messages
Destined to Plugins
Put them in Message Queue
Retrieve when online again
PluginID
Peer ID
PluginID
Peer ID
PluginID
PluginID
Peer ID
Peer ID
DHT
Chat Plugin
Functions
Send message to UserID:PluginID
Specific PluginID to be used
40
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 …
41
Screenshots
42
Screenshots
43
Screenshots
44
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
45
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
46
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?
47
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
48
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
49
Questions?
?
50

LifeSocial – A P2P-based Online Social Network

Transcription

Similar documents

Jens Ellenberg

Online Social Networks and Network Layers

Transparencies Encryption