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.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Tech Tip: Really Simple HTTP Server with Python
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Not free anymore
3 hours 32 min ago
7 hours 19 min ago
- Reply to comment | Linux Journal
7 hours 27 min ago
- Understanding the Linux Kernel
9 hours 42 min ago
12 hours 11 min ago
- Kernel Problem
22 hours 14 min ago
- BASH script to log IPs on public web server
1 day 2 hours ago
1 day 6 hours ago
- Reply to comment | Linux Journal
1 day 6 hours ago
- All the articles you talked
1 day 9 hours ago