TCFS: Transparent Cryptographic File System
Current network technology makes it cheap and convenient to share resources over a network. Typically, a computer network consists of one server with direct access to a resource (file system, printers, CPU time). The server then allows several clients to access the resource. A file system is a typical resource which can be shared over a network, and Sun's NFS is the most widespread protocol for file system sharing. An important feature of NFS is its complete transparency to the application using it. The application has no need to know whether it is accessing a file on a local file system or from a file system shared over a network.
NFS, designed by Sun several years ago, does not address the security issues arising in this context. NFS is simple in structure and assumes a strong trust model: that is, the user trusts the remote file system server and the network with his data. This poses several risks. The data on the server are available to the server superuser; also, users on the network may assume other identities by changing their IP numbers or their user IDs, allowing data to be read while it travels on the network. Because of this, it is necessary to address the security issues by protecting the data while stored on a remote server and during network transfers.
TCFS (Transparent Cryptographic File System) has been developed at the Dipartimento di Informatica ed Applicazione of the Universita' di Salerno (Italy) and is currently available for Linux. You can look at TCFS as an extended NFS. It acts just like NFS, but allows a user to protect his/her files using encryption.
TCFS requires an NFS server running Linux with the EXT2 file system. It must be used with 2.0.x kernels, since it is based on Olaf Kirch's NFS module. TCFS can be used as a kernel module (and inserted using the insmod utility) or can be compiled into the kernel. When you start the TCFS module or when you boot (if TCFS is statically linked), you will find four copies of the tcfsiod daemon running.
TCFS works as a layer under the VFS (Virtual File system Switch) layer, making it completely transparent to the applications. The security is guaranteed by means of the DES (data encryption standard) algorithm. Keys are kept in a special database (/etc/tcfspasswd) which stores keys encrypted with the user's login password. To maximize the level of security, it is best to keep to a minimum number of trusted entities. A TCFS user needs to trust only the kernel and the superuser of the client machine accessing the data. We stress that this minimal level of trust is necessary, since you cannot protect your data from the kernel and the superuser. Both can access memory any time that they want. Our trust model fits perfectly the typical scenario in which TCFS is used: a network of workstations with limited disk space, each used almost exclusively by a limited number of users (you can even think of each user as the superuser of his/her own workstation) and a remote file server sharing files with all the workstations.
In designing TCFS we were interested in providing a robust security mechanism at the lowest possible cost to the user. The security mechanism must guarantee that secure files are not readable:
by any user other than the legitimate owner,
by tapping the communication lines between the user and the remote file system server,
by the superuser of the file system server.
We also protect sensitive meta data—for each file; not only the content but also the filename is encrypted. We hide internal file data dependencies using a DES in the chaining block cipher.
In TCFS, security acts in a transparent way. Secure files can be accessed in the same way as local files—the user has only to authenticate himself to TCFS before starting to work. A special flag, which looks like an EXT2 extended attribute, marks encrypted files to make them distinguishable from unencrypted ones. Thus, TCFS is able to store both secure and unsecure files on the same file system depending on whether or not this flag is set.
We give special attention to making TCFS completely transparent to the file server. Transparency allows the superuser on a server to perform all administration duties in that we don't change the data structures of the file system itself. Special work is needed for a directory with the secure flag enabled. Files in a secure directory are stored with encrypted filenames, and new files inherit the secure flag, so that they too are secure. Since TCFS acts like a file system in a VFS (virtual file system) layer, standard system calls can be used to access files on the TCFS. No special flags are needed by the open() or create() system calls. For this reason, all applications can use the new features without being recompiled.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- Not So Dynamic Updates
- New Products
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Non-Linux FOSS: MenuMeters
- Solving ODEs on Linux
- Android Candy: Bluetooth Auto Connect