Department of Electrical Engineering and Computer Science
Syracuse University

Encrypted File System (EFS) Lab

Overview    Expectations    Preparation    Submission    Demonstration    Documents/Resources

Overview 

In a traditional file system, files are usually stored on disks in plaintext. When the disks are stolen by someone, contents of those files can be easily recovered by the malicious people. To protect files even when the disks are stolen, we can use encryption tools to encrypt files. For example, we can use "pgp" command to encrypt files. However, this is quite invenient; users need to decrypt a file before editing the file, and then remember to encrypt it afterward. It will be better if the encryption and decryption are transparant to users. Namely, when users edit a file (using any editor software) that is encrypted and stored on a disk, the file is automatically encrypted and decrypted; users are not aware of  the encryption/decryption process. To achieve this goal, we need the support from the file system. Encrypted File System (EFS) is developed for  such a purpose.

In an EFS, files are always encrypted. However, legitimate users can access those files using the normal programs without realizing that the files are encrypted. For example, if users use "cat" to look at the contents of a file, they see the decrypted contents; the decryption is transparantly conducted by the EFS. If users use "vi" to edit a file, every time they issue a "save" command, the contents of the file should be encrypted and then saved to the disk; the encryption is also transparantly conducted by the EFS.

In this lab, students need to study how EFS works, identify its functionality, and then design and implement an EFS for the Minix operating system. This is a comprehensive lab that covers a number of security concepts and principles.

Education Outcome

Upon finishing this lab, students should be able to achieve the following: (1) describe and explain how EFS works; (2)  apply a variety of security concepts and principles, including encryption algorithms, key management, authentication, access control, and security in OS kernels and file systems; (3) integrate various security concepts/principles to design and implement a security system.


Expectations & Guidelines

This is the final project for the computer security course, and we expect you to make use of all the knowledge that is covered in the course to implement this one. 

By now, you should be quite familiar with SMX, so we expect you to design and implement a working encrypted file system for SMX. You can work individually or in a group of 2-3 people. You have the freedom of choosing your own design strategy about this Encrypted File System, but we expect you to show us a working demo of a system that can protect the contents of a file system. We will award bonus points to those students who are providing creative and useful features.

Guidelines

  • How do you plan to implement the files encryption/decryption schemes?

  • How to manage the keys in the system? How effectively have you done the key management?

  • How can you achieve user-transparency for your encrypted file system?

  • How are you planning to mount the file system. What are the key decisions you have taken with regard to this point?

  • How you are going to manage the keys? Should you associate the encryption key with each user, or with each file/directory/etc?

  • Where do you plan to make the file encryption/decryption? User level? Kernel level?

  • Can you mask your encryption/decryption key while you input it from the keyboard?

  • Can your system deal with the change of file ownership or revocation?

  • Can you authenticate user from login the system?


Preparation & Challenges

Preparation

  1. Have a basic understanding of what you mean by an encrypted file system (Note: we are not asking you to build an entire new file system and not to demonstrate an encryption utility, but add security features to the existing file system and devise ways to encrypt / decrypt files using the encryption algorithms)
  2. Go through how the encryption algorithm works (AES) in Minix Operating System.
  3. Go through the presentation about the various File System implementations.
  4. Knowledge about encryption, key management, authentication, access control, security in the OS kernel, and file systems.

Steps For Running AES algorithm on Minix

The Rijndael AES algorithm can be found here  [C source Code]

  1. Copy the files rijndael-alg-fst.h and rijndael-api-fst.h into smx/include directory.
  2. Both the encrypt and decrypt would be called from the smx/src/lib/encrypt directory, which is the library for the encrypt and decrypt functions aes_demo.tar
  3. Write an application level program which reads the file and calls the encrypt and decrypt functions, I have created a sample file demo.c
  4. Sunread the demo application program in minix and creates a test.txt file and run demo.

    A step-by-step document can be downloaded here

Mounting a file system   

  1. Copy file efs into /smx/disks directory.
  2. In /smx/src/tools/.minix file, add "hdx3 ../../disks/efs" below "hdx2 ../../disks/man" line
  3. Start smx, in /usr directory, run mkdir efs
  4. Run command "mount /dev/hdx3  /usr/efs"
  5. Run command "df" to check out the file systems mounted in smx
  6. If you want to un-mount the file system, run "umount /dev/hdx3"

Sample design strategies on implementing the project

  1. Implement file encryption/decryption functions using AES algorithm. I've already provided an example here
  2. My demo does not provide file written to the disk, so you need to implement the function of file save to / load from disk. It should be straightforward.
  3. After individual files could be save/loaded, you should work on directories. To traverse a directory, you can use breadth-first traverse or depth-first traverse
  4. Now that directory encryption/decryption is done, you could consider how you would deal with a file system. You could implement the encryption/decryption in existing file system, or you could create new file system.

Challenges in the project

  1. Reading and writing data on the way to/from user processes - This can't be too difficult, but would still take some time to figure out and get to work. This is not that difficult, but the user should know which files he needs to change and where to insert the proper lines of code.
  2. Encrypting/decrypting the intercepted data blocks - Please use the AES algorithm for the Encryption and Decryption (Source: Rijndael Webpage, algorithm is at AES Algorithm). Accounting for size and file position changes are an important part while doing the encryption and decryption. The encrypting part should be very easy, almost trivial. Calculating block sizes, splitting/combining blocks and calculating file offsets would take work. But the user doesn¡¯t need to figure out how this happens since it happens automatically. The encryption algorithm works right off the bat.
  3. Mounting a file system. The mounting procedure basically is used to mount the encrypted file system. Here the user is given the flexibility to mount the file system on to any directory. This forms the major part for the Encrypted File system. I have provided an example on how you do that.
  4. System Policy ¨C Think about how you are going to define the system security policy for the whole system.

¡¡


Submission

You are required to submit a post lab report, which will contain your design strategy and your implementation details: how you plan to implement the system, what components will be affected, what is the most difficult part of your implementation, and all the relevant details that you would think would be needed. 

  • Please submit a softcopy of your report to TA.
  • Please bring a hardcopy of your report together with you during your demonstration.

Demonstration

You need to demonstrate your implementation to us.
  • The total time of the demo will be 15 minutes, no more additional time would be given. So prepare your demonstration so you can cover the important features.  
  • Students are entirely responsible for showing the demo, in the way they feel is in accordance to the project. We will NOT even touch the keyboard during the demonstration; so don¡¯t depend on us to test  your system. If you fail to demo the important features of your system, we will assume that your system does not have those features 
  • Before you went to the demonstration, please run it by yourself. If the system crashes or anything wrong happens, it is your own fault. We won't debug your problems, nor give you extra time for it. Excuses like "This is not my fault" "I know how to do that" will not be accepted.   
  • During the demo, you should consider yourself as salesmen, and you want to sell your system to us. You are given 15 minutes to show us how good your system is. So think about your sales strategies. If you have implemented a great system, but fail to show us how good it is, you won't get good grade. 

Helpful Documents & Resources

AES Algorithm [C source Code]
DES Algorithm [C Source Code]
Triple DES Algorithm(3DES) [C Source Code]
MD5 (Message Digest) Hashing Algorithm [C Source Code]

Step-by-step demonstration on using AES algorithm to encrypt/decrypt a file [PDF]
Encrypted File System [PPT] or [PDF]
Good webpage on encrypting disks [HTML]
Yet another good webpage on encrypted file system [HTML]
Steganographic File System (StegFS) for Linux [PDF]
Encrypted File System Project [PPT]
File System with integrated user management [HTML] (link to pdf file here)
Cryptographic File System [PDF]
Windows2000 Encrypted File System [ASP]
CryptFS: A stackable Vnode encryption file system [HTML] (link to PDF file here)

Updated on 12/20/2005