TCFS project is a cryptographic network file system featuring group sharing of encrypted files. TCFS will encrypt your files before sending them to the file server and will decrypt them before they are read by the requesting application.
Because the encryption/decryption process takes place on the client host, no clean data will travel the network. This is particularly valid for the encryption key.
Recent advances in hardware and communication technologies have made possible and cost effective to share a file system among several machines over a local (but possibly also a wide) area network.
One of the most successful and widely used such applications is Sun's Network File System (NFS).
NFS is very simple in structure but assumes a very strong trust model: the user trusts the remote file system server (which might be running on a machine in different country) and a network with his/her data. It is easy to see that neither assumption is a very realistic one.
The server (or anybody with superuser privileges) might very well read the data on its local filesytem and it is well known that the Internet or any local area network (e.g, Ethernet) is very easy to tap (see for example, Berkeley's tcpdump application program).
Impersonification of users is also another security drawback of NFS.
In fact, most of the permission checking over NFS are performed in the kernel of the client. In such a context a pirate can temporarely assign to his own workstation the Internet address of victim. Without secure RPC no further authentication procedure is requested. From here on, the pirate can issue NFS requests presenting himself with any (false) uid and therefore accessing for reading and writing any private data on the server, even protected data.
Given the above, a user seeking a certain level of security should take some measures. We propose a new cryptographic file system, which we call TCFS, as a suitable solution to the problem of privacy for distributed file system.
Dynamic Encryption Modules in TCFS:
The dynamic encryption module feature of TCFS allows a user to specify the encryption engine of his/her choiche to be used by TCFS. So you are not forced anymore to use what us (the developer) consider the best (i.e., more secure and efficient) encryption algorithm. The encryption engine must be given in the form of a Linux module and must conform to (the very simple) TCFS API for encryption module. Essentially, it must specify four functions:
1. An initialization function that is called by TCFS when the user pushes her key into TCFS.
Typically the initialization function takes as input the key and returns a pointer to a struct containing a the result of a preprocessing of the key to be used for the encryption and the decryption.
For the specific case of DES the initialization function computes the 16 48-bit subkeys, one for each round of DES.
2. An encryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and encrypts the data.
3. A decryption function which takes a block of data, the length of the block in bytes and the result of the initialization function and decrypts the data.
The encryption and the decryption functions are called each time TCFS needs to read/write a block of data.
4. A cleanup function which performs whatever operation is needed before the key removed by TCFS.
Our work improves on Matt Blaze's CFS by providing deeper integration between the encryption service and the file system which results in a complete transparency of use to the user applications.
Release 2.2 of TCFS includes the possibility of threshold sharing files among users. Threshold sharing consists in specifying a minimum number of members (the threshold) that need to be ``active'' for the files owned by the group to become available.
TCFS enforces the threshold sharing by generating an encryption key for each group and giving each member of the group a share using a Threshold Secret Sharing Scheme. The group encryption key can be reconstructed by any set of at least threshold keys.
A member of the group that intends to become active does so by pushing her/his share of the group key into the kernel. The TCFS module checks if the number of shares available is above the threshold and, if it is so, it attempts to reconstruct the group encryption key. By the properties of the Threshold Secret Sharing Scheme, it is guaranteed that, if enough shares are available, the group encryption key is correctly reconstructed.
Once the group encryption key has been reconstructed, the files owned by the group become accessible. Each time a member decides to become inactive, her share of the group encryption key is removed. The TCFS module checks if the number of shares available has gone under the threshold. In this case, the group encryption key is removed from the TCFS module and files owned by the group become unaccessible.
The current TCFS implementation of the group sharing facility requires each memeber to trust the kernel of the machine that reconstructs the key to actually remove the key once the number of active users goes below the threshold. Future implementations will remove this requirement by performing the reconstruction of the key in a distributed manner.