Secure Co-Editing

For consistency reasons, even after opening a text file inside an editor, the member cannot edit the file (i.e., key strokes would have no effect) until he (or she) locks a region.

A region in this context is a continuous section of a file that contains zero or more characters. Locking is done by using the mouse to highlight a region of the file and then clicking the lock region button (or choosing from the menu bar). The lock request is sent to the server, which determines if it conflicts with existing locks, because two locked regions must not overlap. If there is no conflict, the server registers the lock and acknowledges it to the requesting member.

At this point, the locked region changes in color (say to blue) to visually signify that the lock has been granted. (We are considering non-color-based indicators for color-blind users.) Now the lock holder can edit within this region. Another member who also has the same file opened will see that this new region turns into red, signaling that it is locked by another group member, and will also see changes made by the other member reflected immediately in the local editor. When a member opens a file, all existing locks are reflected by color coding.

If a lock request is denied, the requestor is informed as to whose current locked region overlaps with the requested region. It is possible to assign priorities to users such that one with a higher priority can ``grab'' a locked region from one whose priority is lower. (Whether this is a desired group behavior is a separate question.) A lock can be explicitly released by clicking on the unlock region button. When a member exits from the editor, or leaves the group, his locks are automatically released.

To facilitate system-independent file editing, we have devised a simple language for file manipulation. We will not give all the details here, except for an example. In this language, inserting a character A is represented by a tuple of the form (file_name, insert, A, cursor_index, region_name). Here, the index is the relative distance from the start of the locked region.

This relative indexing has a few significant benefits. First, because the member has exclusively locked the region for writing, to maintain consistency, it is sufficient if the communication regarding this file between this member and the group member responsible for coordinating the file (in our case, the group leader) maintains a FIFO order. In other words, serialization is done via the group leader, so the regions can ``float'' as a result of simultaneous editing, and yet there is still no need for a global causal or total ordering among file operations. Another advantage is that local batching becomes possible. For example, if a member is typing rapidly, the changes can be saved and then sent to other members in one batch. Of course batching can be done at lower levels, such as at the multicast level, although low-level batching is best directed by higher-level applications to obtain the best desirable effect.

One way to further improve efficiency is to design the object manipulation language to be as compact as possible. For example, a series of insertions can be replaced by a single insert command. Also, there is a lot of redundancy in commands such as the following, where the operation to delete a character from a shared file translates into a long command of the form (file_name, delete, start_index, end_index, region_name). If the redundancy in these commands is squeezed out, the amount of encryption is also reduced.

Based on this system-independent language, different group members can in theory use their own favorite editors (which of course must have been enhanced with this language capability).

Note that because a user has ultimate control over his own enclave, he can use methods outside of Enclaves to violate a lock and to update a shared file. However, any effect of such editing is strictly local because the group leader would not accept or propagate such an editing command.

So far we have focused on how a region within a single file can be locked and shared among group members. It is not difficult to generalize such a basic facility to sharing or locking entire files or even parts of the directory structure.

Finally, files can be saved to local disks and can also be signed with digital signatures. In fact, it is easy to implement ``notary'' services. A traditional object notary, as in a paper-based environment, receives submissions in the form of objects or files and returns (and maintain a record of) signed certificates. A session notary, on the other hand, can be implemented as a group member who takes notes of every change made to the shared files and commits these transaction records to a non-volatile storage with the proper digital signatures.

Need help? Use our Contacts page.

Conference Index USENIX home