An idea for distributed secure social network by Vasil Kolev, vasil(at)ludost(dot)net 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 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. There also can be levels of trust of the signatures, e.g. to approve a key, but not the keys signed with it. 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 :) ). 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. 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. 5) 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. 6) Problems (that I've seen) 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. There isn't a really clear and simple way to revoke signatures. There are a few ways, to have all the signatures and revocations have a time stamp, but the propagation of the revocation is still a problem, and may impose further restrictions on the transport layer. This, of course, is fixable with a central revocation authority (or some of them), but that doesn't feel right for such system.