An idea for distributed secure/reliable social network version 4 by Vasil Kolev, vasil(at)ludost(dot)net -1) Todo Appendix A and B, email and native transport methods 0) Disclaimer (all rights reserved, blah blah) This is heavily influenced by orkut, so I might be missing something important, you can correct me at vasil(at)ludost(dot)net Thanks to all the people in orkut, that came with a lot of suggestions, and special thanks to Bine. The latest version is available at http://vasil.ludost.net/pisaniq/sn_wot/sn_wot.txt, at http://vasil.ludost.net/pisaniq/sn_wot/ you can find previous versions and diffs. 1) Prerequisites This document assumes that you're familiar with social networks, like orkut (www.orkut.com), and with PGP/GnuPG and web-of-trust (http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-1.html). The ideas here are just that - ideas, there is no current implementation, although the author has the desire and about half the time he'll need to start the project. The term 'guarantee' is used in the standard cryptographic sense, "for x times the age of the universe, unless there is a major mathematical breakthrough, and you're careful" 2) Overview The idea is about a social network, that relies on PKC (public key cryptography), its derivatives like GnuPG, and peer-to-peer model, which will make it secure and resistant to the common attacks in existing such networks, as FOAF and orkut. These are the core elements of the system: Public/private key pair - a key pair in PKC sense. Every single entity in the system has a pair of it's own. Keys can be signed with other keys, to ensure their authenticity. Every private key has a pass phrase to protect it. This phrase is used to encrypt the key with some standard symmetric encryption algorithm, and the key is only usable to the person that knows the pass phrase. This prevents misuse of stolen keys(without their pass phrases, of course :) ). Key signatures - these are a part of the key, and are used to verify it's authenticity. It has the following parameters: 'level of trust' (LoT) - this parameter tells how trusted a key is. For example, a low level of trust means that this key is trusted, but every key, signed with it, is not. Trust can also be negative, in the sense that a person is SURE that the owner of the key isn't the person that he/she presents to be. 'friendship level' (FL) - this tells the relation of the signer with the key owner. This has a meaning that's similar to the level of trust, but it's from the other direction, e.g. LoT tells you how much can you trust keys signed with this one, and FL tells other people how much they can trust your signature. This makes possible to have a friend that other people can trust only when they agree with this implicitly. This can be negative, too, implying a enemy, hated person. It's important to be noted that if a signature has negative FL or LoT, then the other shouldn't be trusted/used. If you have negative LoT, there can be no positiveness that the person which uses the key is really known, and if you have negative FL, then you can't be trusted to provide right measurement for the trust level given to the signed key. Timestamp - it's the exact time when the signature was made. This can be used to distinguish which event is the latest, which signature should be used, etc. End user - A user in the system, that has his own profile, friends, and other attributes, that are visible to others on the user's will. (e.g. the user _controls_ what is visible to whom). Every user has a key pair, and is uniquely identified by his/her key fingerprint. (optionally, as in PGP, there can be a email linked with him, the so-called identities). Communities (called that because I can't think of a better term) - services running somewhere, where you can post, rate or whatever you want, something like a bulletin board. They can have various functions - from normal discussions, to karma/rating systems, like in orkut. Every such community has a key pair. Trackers are services, that provide information about the online status of a person, and ways for direct communication with him. They're optional, and are just an aid for the direct request transportation method. They also have public/private key pair. 3) Layering of the system The core part of the system is a client, that can do the following things: 1. Generate public/private keys 2. Sign other people's keys 3. Create and parse requests in common format 4. Encrypt, decrypt, sign, and check signatures of requests/documents 5. Use some mode of transportation to send out and receive requests 6. Provide interface to higher-layer applications to use it (audio conferencing comes to mind) This part takes care of most of the important things. It provides the security and the guarantees for every operation's origin. The transport system is a way to send and receive requests from and to other members or communities. I'll be using email as example, but you can use for example uploading to a web/ftp site and downloading from such, with no effect on the core part. This is separated from the core, because it gives a lot of ways to route around all kinds of firewalls and censors. The only requirement of such system is to have a way to deliver the requests reliably enough, the authenticity and confidentiality is guaranteed by the core system. 4) Principle of operation 4.0) Prerequisite Every request here, unless stated otherwise, is signed _and_ encrypted. Every received request is acknowledged by the receiver. 4.1) Joining the network To join the network, you first have to generate a key pair. Then, a member has to sign your key (after verifying that you are you, and you're using the key) (note: you two can create a network, no need for the other person to be in some such net). The signature you have on your key is the way for everyone else to check that you're really you, when they receive something from you, or get something that comes from you. Up to now, there isn't a secure electronic way to send your key to someone, and to make it impossible to be modified, before exchanging some other information, that can be used as a shared secret, so it's recommended to use the standard practices adopted by PGP users, like exchanging key fingerprints on paper, to be able to verify the authenticity of someone's key. 4.2) Making a friendship relation with someone To do this, you have to make a request, sign it with your key, encrypt it with her/his public key, and send it. The public key and it's identity can be verified through the chain that's created between you and person. After he/she receives the request, she/he can easily verify your identity, based on the key signatures and the trust levels, and then to approve or reject your request. The approval comes with a signature for your key. You can then send/receive requests with various information, like your network of friend, your profile, etc. The signatures and the encryption guarantee that the information is authentic and unreadable for anyone else. 4.3) Communicating with a community To be able to use any community, you'll have to get it's key, which has to be signed by it's creator, and probably by some of the members, so you can verify it's authenticity. Then you send a request to join, and depending on the policy you're automatically accepted, approved by moderator, or rejected. If you're accepted, then the community signs your key, and you're allowed to do whatever this community is for. Then everything that's done by member of the community _and_ allowed to be seen by the system, has a way to prove it's authenticity not only to the service, but to all the members, again by checking their signatures. In practice, it would be good for the community to sign every incoming and processed request, so there can't be any falsification. The testimonials and other public ratings have the same way of replicating, they're just sent to a person than to a community, and the person decides which such ratings will be publicly visible. 4.4) Normal login procedure When started, the client looks in it's list of friends, and then depending on the mode for communication with them, checks if there is any pending information. Then, depending on user's preference, it announces itself to a tracker, and starts to communicate with the user. Then the user can import received requests, generate requests, and in general use the system. She/he can also use the client to initiate secure connections to be used with other applications, using a standard procedure for key exchange. The client , again depending on user's preference, will support receiving requests on a TCP port, or other public method. 4.5) Key revocation and key expiration. There are two ways to revoke a key. One of them is to make a revocation request signed with the key itself, and propagate it through the transport layer (there are some problems with this, that will be discussed elsewhere). The other way (if the key itself was lost, or there is something that makes it unusable, like forgotten passphrase), is to have it's LoT changed to it's lowest value by everyone who has signed it, and have the new key of the person/entity signed by them. Changing soneone's key means that the new key has to be signed again. (note: the revocations request itself is a signature done with the private key, with the lowest LoT). Revocation requests are final and terminal, after one such request the key becomes invalid. Key expiration is done the following way: some time before the key expires, the owner generates a new key, signs it with the old one, and propagates it through the network as his new key, to have it signed by the people that have signed the old one. It's up to them then to sign it and start using it. (It can also be mandated, that if you have more that one key for an entity, to use the one with the later expiration date). 5) Some interesting questions 5.1) What can you do with a community? This deserves a part on it's own, because it's one of the pieces that makes the system really expandable. Through the interface for a community, you can run any service that has user participation, can authenticate it's users, and authenticate itself to them. One of the possibilities is to make a normal forum. It can have restrictions of all kinds, like who's able to view what, who can post, or who can join, based on trust from it's current users' keys, or some equivalent indication. It then can implement anonymity, by stripping users' signatures (if they desire, or if that's policy), and leave only it's signature. Of course, it should be noted that it's not _full_ anonymity - you can never be sure what the implementation of the community server will do, and all your requests are ultimately signed and traceable to you (or to be exact - to your key). One other possibility is anonymous ranting system, equivalent to that in orkut. It's anonymity again will depend on the service itself, but the difference here is that all your ratings have to be kept in their original form, so when you decide to modify any rating, the system can find your old, and replace it. 5.2) How exactly is it decentralized? This is easy to explain and understand - the system _can_ be centralized or decentralized, depending on the preference of the users and people that run it. It all depends on the communications method. The example given is with email, which makes it unnecessary to have anything central, you'll just need a working mail servers, to be able to send and receive the requests from other people (and that can fully be automated). You can also use something that has irc-like structure, of connected servers (hubs and leafs) to propagate information through the network (in fact, you can use irc for that :) ). The only exclusively central points (e.g. points that aren't (easily) distributable) are communities, and there is NO requirement for all the communities to be in a particular place - you can have them in different countries, on different machines, using another transportation method, or whatever you think. 5.3) Why not use full decentralized peer-to-peer infrastructure? Because in peer-to-peer you can't have a good reliability, if the information that you need isn't available at more than one node, and because there is a general problem with discovering nodes in such a network. And, you can always use email exclusively, which gives you the same benefits with enough reliability. 6) Why? Why should you use such a system, if there are a lot of ones that do almost the same job, as orkut, and FOAF? First, all centralized systems have too much information in their hands to be trusted enough by most of Internet's population. No matter how trusty you are, if you get enough information, you'll became untrusted by default. This system doesn't have any central place, and all the places that are somewhat central (like communities) don't hold personal information, or anything that can be considered too important (your posting in a community can be made visible _only_ to people in that community, for example, and the only way to get to them will be to break in the machine, for which there are methods to prevent reading of data, even if there is a break in). Second, with other such networks, there is NO guarantee that anyone can't sniff you password and use it to impersonate you, or get in some way your site (some sites, notably LinkedIn, use SSL by default, which helps a bit). This is different from this idea, where your authenticity is proved by all people that have signed your key, and it depends on your protection of your own key. This is a lot easier than protecting all the network route to the servers of the network, or from protecting your web site (most FOAF users use public web sites, a lot of which still use FTP to update, which is real easy to sniff). And of course, you have FULL control about what you give to whom. 7) Problems (that I've seen) 7.0) Misc social problems There is NO full anonymity in this system, because you can always be traced through the signatures of your friends. Also everything you send is provable to be sent by you, by the signature of the request, because as a rule, a request can't be accepted if it hasn't got a valid signature. Every normal participant in the system will be able to keep track of events, like new keys, changes of FL, changes in profiles (that he has access to), etc. This exists in current such networks, too, but here it's something by default, and some people may have objections about giving so much information so easily. 7.1) Update propagation This has always been a problem in WoT and peer-to-peer networks, and there aren't a lot of good solutions. One of them is to have a flood-type update (if you're using email or some equivalent off-line (e.g. not real-time) transport layer), and not to resend the update if you already have it applied (which will eliminate loops). This would create a storm of updates on every major key expiration or revocation, and will give a mediocre guarantee that everyone will get the update. The other way is to have a keyserver-like structure that will take care of the propagation of this. The problems there will be the size of the database, the synchronization of the servers (one server will be a single point of failure, and the database will have trouble being split, because you won't be able to verify all the signatures).