I find the best way to understand and learn about something is for me, to try and use it. I’ve been trying to understand the RegisterCRDT and have had discussions on the community forum about its capabilities and how to use them, and made a couple of Pull Requests to revive and add to the sn_register examples as part of that process.
I also looked at how to implement a versionable filesystem, and considered implementing this as a FUSE mountable drive. A lot remains undefined and unclear to me, so I abandoned that and am currently looking to implement something using just the capabilities I think I understand.
The aim of this post is to share that idea and my thoughts about how to implement it to get feedback:
- on the app, to ask if people think it’s useful, and
- on the user experience around what I call key exchange, and the implementation using Registers
Below I describe the essentials of the app which I imagine would begin as person-to-person sharing but could be extended to support group sharing. Then I describe how it is set up in terms of what users are expected to do, and what the app does using the Safe Network API in response to user actions.
Please let me know what you think about any of this regarding the app and how I describe its implementation. I don’t know if I will build it but I’m tempted to at least create a command line version to test the underlying idea.
It may be that the functionality I’m describing is planned as part of the MaidSafe created apps, or even a partner sponsored app but without knowing about those it seems an important feature to explore and begin working on.
Safe Room Overview
A Safe Room is an idea for secure, private communication that handles multiple kinds of shared interaction, such as email, chat, file sharing and collaborative editing between two, or perhaps more parties. It is a space known only to and accessible only by members of the room, and acts like a shared inbox and outbox, shared drive etc., encrypted so that only the participants can access content or metadata.
The design aims to ensure that not only are the contents of communication secure, but that it is not possible for others to discover that there is a room, or even if they were told of its location, they cannot tell who is a member of it. So this is a way for people to establish a way to communicate that is entirely hidden, and is suitable for any kind of digital information sharing from chat, to email, documents, folders etc.
To avoid sabotage and spam, both reading and writing are restricted to ‘members’. To ensure privacy, the Safe Room is not discoverable unless its location is disclosed by a member of the group to someone outside, and to read the content would require access to the private key of at least one member.
For the initial use case only two members are permitted, and a mechanism is required to allow exchange of public keys that is easily understood and managed offline, and without immediate access to computers, phones. This requires a key exchange protocol (proposed below) that begins with two humans meeting, exchanging some easily remembered information and later entering that into their Safe Room App to establish secure, verified communication using a Safe Room located somewhere on the Safe Network.
Beyond One-to-One
I imagine a Safe Room could be one-to-one (like email or a chat room for two), one-to-many (like a blog post with member only comments), or many-to-many (like a chat room for many).
To go beyond one-to-one requires ways to add or remove members. Adding or removing a member could be implemented by creating a new room that contains the new set of members after the add or remove, and publicising the address to the old room, but encrypted to only be readable by members of the new room. This prevents a new member from reading old messages and a removed member from knowing about or reading the new room and its messages.
The remainder of this outline is limited to one-to-one Safe Room implementation. Later, feasibility of one-to-many and many-to-many can be explored, perhaps by using BLS encryption.
Safe Room Features
The following assumes a one-to-one implementation with metadata and content encrypted so that it can only be read by the two participants. The location of the room will not be public and not discover-able independently, so any leaking will require access to private information held by one of the participants.
Use as a Chat Room
- no spam - each room is only known to the participants (just two for now) and so is free of unsolicited messages from others (spam)
- privacy - messages from one to the other are encryped using the other’s public key, so only the participants can read content
- undiscoverable - the room is a location (Safe Register) on the network that is known only to the participants, so the fact they are communicating is not discoverable by anyone else
Safe Room Implementation
A Safe Room is a data structure stored on Safe Network at an address typically only known to members of the room.
In a one-to-one form, a room is implemented as a Safe Register that is writeable by both participants (or members). Each entry points to a chunk of data that is encrypted to ensure it is readable only by those participants.
Stage 1: in a trivial [cough] implementation, the Register is just a sequence of pointers to messages. To send a message, either participant creates a chunk, stores it on the network and updates the Register to point to it. To read messages either participant syncs the register to get a local copy and can interrogate it to see all messages posted so far.
Stage later: a much more useful implementation uses a Register as the root of a more complex structure, that contains chunks representing different types of data being shared, such as a directory of files which either can update, list of bookmarks or pet names for Safe Network hosted websites, documents, videos etc. It can include multiple types of entry, and a Safe Room App can display and provide interaction with the data through UIs tailored to the use cases and data types it holds.
The Register data structure of Safe Room is not discoverable by anyone else, but even it it was, encryption of the chunks means the content remains secret until decrypted locally by one of the participants.
Use cases and data types:
- shared drive
- collaborative document editing
- shared bookmarks
- shared contacts
I expect rooms can be designed so that one-of-many can read the content, rather than just one of two.
Safe Room Key Exchange Protocol
The implementation and features of Safe Room may vary, but whatever they look like, people will need a way to create them in a way that is private and secure to avoid eavesdropping and impersonation by others. This requires a procedure for secure exchange of each member’s public key and creation of the Safe Room Register at a location on the network that cannot be linked to either party.
The procedure is both human and computational and called the Safe Room Key Exchange Protocol.
Here’s a proposal (v2) for a protocol that allows two parties to set up a Safe Room that only they can access, which prevents anyone else knowing that the participants are connected to the same room, and ensures only they have access to the content (no leaking of metadata or content).
This Key Exchange Protocol (draft v2) has two stages:
1. Contact Initiation
Bob and Carol people meet and want to communicate using Safe Network. The first step, and the only one where both need to be in direct communication is that they agree on a set of four unconnected seemingly random Safe Words.
At some point, and at their own convenience, each person enters these “words” into the Safe Room App as part of adding a new contact.
What Kind of Words?
What matters is that the words are not obviously connected to each other, or to Bob or Carol (so not any of their email, relative’s name, nickname, home town etc.) and not easily guessable (so not “one two three four”). More something like: “jupiter tractor banana pacific”. Good luck guessing that or who came up with it based on the words themselves.
Why Four Unconnected Words?
The more words used the more secure, but I’m going to guess for now that four words will be enough provided they don’t choose just common words. If either of them has the Safe Room app available they might be able to ask it to generate the words and the second person can just write them down or type them into their app if that’s handy.
In practice these don’t have to be dictionary words but can be any pieces of textual and or numeric information so long as they can both enter exactly the same “words”, into their respective Safe Room app. This can be done right away, or later with reference to a copy on paper.
2. Public Key Exchange
After Contact Initiation each person has the same four pieces of information, or Safe Words agreed for use in establishing their Safe Room connection.
Each adds the other as a contact using their Safe Room App (or to start with, probably a command line program can perform the same function).
When connected to the Safe Network this information is used by each person’s app to look for a Staging Register created by the other, or if it doesn’t exist yet the creates it. The Staging Register is only used during Public Key Exchange and is not the Safe Room Register itself.
Suppose Bob does this first. His app calculates the address of the Staging Register using the hash of all four pieces of information, combined in a deterministic way so that Carol’s app can calculate the address independently using the same shared information.
Bob’s app tries to access the Staging Register but finds it doesn’t exist yet, and so creates it and writes the first entry in the register which will contain his public key.
When Carol’s app connects to the network it finds that Bob has already created the register. Carol’s app then writes an entry containing her public key, but encrypted using Bob’s public key so only he can read her key. At the same time, Carol’s app creates the Safe Room Register based on the two public keys and the Safe Words they have agreed.
Bob and Carol now have each other’s public keys, and the Safe Word App knows the address of the Safe Room Register who’s address is calculated using them. At this point, nobody else can calculate the address of the Safe Room because even if they were to find the Staging Register, they cannot see Carol’s public key.
Attacks by a Third Party
A Staging Register is only used during Key Exchange, but between Bob creating it and Carol adding her public key to it there is a window where an attacker could pre-empt Carol and impersonate her by writing a different public key. However, this is an unlikely attack, that is easily mitigated. One mitigation is that when Carol’s app is activated to write her key, the Staging Register will contain two respondent entries and the App can alert both Bob and Carol to the fact. They will both know independently that there appears to be an imposter, and Bob can communicate with both the imposter and Carol to establish what has happened, and if necessary Bob and Carol can abandon the process. They might also, if they need to be very careful agree an extra Safe Word for each of them to use when beginning to communicate using the Safe Room. However, is very unlikely that this attack will be worthwhile, because a) it cannot be targetted at an inividual without being able to intercept the Safe Words, and b) Bob and Carol witll both be aware of the problem before they can begin conversing.
Other Risks
Leak of a the public key associated with first identity and being used to identify that person - no risk if the app generates the key-pair just for this purpose.