Group: GNU Social P2P/Keys

From LibrePlanet
Jump to: navigation, search

Keys and Identity in GNU Social


User Keys

The fundamental unit of user identity in GNU Social will be a standard OpenPGP public key (hereafter Kpu). Identity will be proved by correctly signing challenges with the key, and privacy can be guaranteed by using these keys for end-to-end encryption.

Specifically, any user wishing to use GNU Social must configure their UI with the public key ID from their user keyring they would like to use as their personal key. If they do not have a key, the UI should generate one for them.

To set a privacy constraint on a given user object, that object should be encrypted to the user keys of all users to whom the *owner* of that object wishes to share the data. This ensures that only those users have access to those objects, presuming that the owner's trust in those users is well-placed.

Data Keys

These are symmetric keys with which objects in the GNU Social datastore are encrypted. These keys are encrypted with user keys to add users to access lists for private data objects.

Data Keys and Key Packets

Every object in the data store is encrypted to a object specific symmetric key, the "data key" (abbreviated hereafter as Kd). That key is then encrypted to all keys in the set of user keys who are allowed access to the object (hereafter target users). The encrypted keys are stored in key packets. It is to our good fortune that such interactions are already implemented in the OpenPGP protocol. The relevant concepts from the OpenPGP standard are Symmetric-Key Encrypted Session Key Packet and Public-Key Encrypted Session Key Packet.

To reduce the computational effort and to increase flexibility, intermediate symmetric keys are introduced. Kd is encrypted with a symmetric key generated once per target user - Ksu. Ksu is further encrypted with the target user's public key Kpu. When the user attempts to retrieve the data, they are presented with the chain E(Kd, d), E(Ksu, Kd), E(Kpu, Ksu). They are then able to decrypt the chain using their private key. On the originating node, E(Kd, d) is the encrypted data and is only stored once. E(Ksu, Kd) is stored with the data in a collection, one per target user. E(Kpu, Ksu) is stored with the friend record - as part of the structure that keeps track of the social graph.


Core keys

Core keys are public keys used to identify a core in the long term. Since cores do not have access to unencrypted data, they do not need to be trusted for the purpose of basic privacy. However, cores provide additional services that enhance privacy (such as routing). Therefore, we would still like to determine if cores are trustworthy. This may be verified through the Web of Trust.

In a GNU Social packet, inter-core routing information is encrypted to the Core key.

Transport Keys

Some transports may use their own keys. These must be rotated regularly, and presented to each connection signed with the Core key. The key type and method of presentation is left entirely to the transport.

Friending

The friending process (creating a link between two users) is performed as follows:

Request Phase

  • The origin user initiates a friend request
  • The origin UI obtains the target UI public key through various means (from another friend, from a directory or as a last resort by contacting the target UI at a manually entered URL)
  • The origin UI creates a friend request packet, which includes: a generated friend token for the source, the origin public key, routing information from target to source. The packet is encrypted with the target UI public key.
  • The origin UI asks the origin Core to route the packet to the target UI

Response Phase

  • The target UI decrypts the friend request and presents the request to the target user
  • The target user approves the request
  • The target UI stores the friend information in the Core, including: the origin user public key, the target friend token (both items encrypted to the target user public key). It also stores the source friend token in plaintext.
  • The target UI creates and sends a friend request reply packet, including: a generated friend token for the target, the target public key, routing information from origin to target. The packet is encrypted with the origin user public key.
  • The origin UI stores the friend information

Further Communication

Further communication is routed using the exchanged routing information. The friend tokens are used by the cores to identify the social graph endpoints without directly referring to public keys. Routing information can be updated as needed.

Resources