eFS: encrypted File system

1. eFS: encrypted File system Project by: Andrew Grossman Gaurav Gupta CMSC 691X-Summer 2002 University of Maryland Baltimore County

2. Introduction: • Objective • Motivation • Related work • 3DES • Design and Implementation • Bash Shell

3. Objective The project had two main objectives: • Provide functionality to store a file in an encrypted format which can only be accessed by providing the correct password. • Modify the system to make the directories password protected.

4. Motivation • Security • Secures data from being accessed by any malicious user • Privacy • Ensure that private data is not accessed by other users( may not be malicious) • Reliability • Only responsible people are provided access to important data. • Resource sharing • Many users can use the same system and still can work independently

5. Related work • StegFS: A Steganographic File System for Linux, University of Cambridge. • CFS: Cryptographic File System , Temple University. • SFS: Secure File system, University of Minnesota and StorageTek. • TCFS :Transparent Cryptographic File System) University of Salerno (Italy).

6. 3DES Algorithm: • Triple-DES is just DES with two 56-bit keys applied. • First key is used to DES- encrypt the plaintext message. • The second key is used to DES-decrypt the encrypted message. • The twice-scrambled message is then encrypted again with the first key to yield the final ciphertext.

7. Design and Implementation • Used two methods performing 3DES encryption and decryption. • Created two functions: • efopen(const char* path, const char* mode, const char *password) • efclose(FILE *stream) • Provide password when creating or opening a file. • A temporary file is opened using: char * tmpnam(char L_tmpnam)

8. Continue… which generates a file name different of an existing file. • The processing is done on the temporary file transparent to the user. • If the file already exists the encrypted data is read in a buffer and the “decrypt” function is called by passing the pointer to the buffer and the password. • If the password is correct the decrypted data is loaded in the temporary file.

9. After modifying the file on efclose() call the “encrypt” function is called with the password and the file is encrypted and stored with the given filename. • The temporary file is destroyed after efclose() call is over.

10. Function Placement • Initially, we intended to implement efopen() and efclose() as calls to the kernel. • Our original design did not lend itself to placement in the kernel. • Considering how the functions work, there is no need to add them to the core of the OS. • Instead, we added them to the stdio library in glibc.

11. Testing of File Encryption Functions • To test the function calls, we used them to write two general-purpose encryption/decryption utilities, which we placed in /usr/bin. • encrypt <password> • Takes in input from stdin, encrypts it using the given password, and outputs the encoded data to stdout • decrypt <password> • Takes in input from stdin, decodes it using the given password, and outputs the decoded data to stdout

12. Directory Password Protection • Unlike file encryption, directory password protection requires changing the kernel, otherwise user-level programs could bypass the security measures. • Two steps were necessary: • Adding fundamental changes to the kernel • Changing user level programs that interact with the kernel, so that they can use the new security measures

13. Kernel Modifications • First, a place for the password, and a flag for whether or not the directory is password-protected, was added to the struct used for defining directories, located in include/dcache1.h • Then, additional functions, echdir(), efchdir(), and emkdir() were added, as secure complements to chdir(), fchdir(), and mkdir().

14. Kernel Modifications • The new functions were then added to the system call table. • Finally, the new kernel was compiled and moved into place.

15. User-Level Usage of Kernel Calls • Now that the basic functions, echdir(), efchdir(), and emkdir() were available, it was necessary to implement them in a shell, so that password-protected directories could be created and accessed. • Both bash and tcsh were changed to accept the ‘cd’ command with an extra optional argument, a password field. • `cd` calls given a password called echdir() with the password instead of the standard chdir().

16. User-Level Usage of Kernel Calls • While the logic for changing into directories was located in the shells themselves, any mkdir calls were instead passed to /bin/mkdir. • Therefore, it was necessary to change /bin/mkdir. • The code for mkdir.c is located in the fileutils package that comes with redhat.

17. User-Level Usage of Kernel Calls • mkdir was changed to take a password argument • mkdir <directory> [password] • Both mkdir.c and a library file, pathname.c needed to be changed. • After compiling mkdir, it was moved to /bin, replacing the old mkdir.

18. User-Level Usage of Kernel Calls • Using the bash shell, password protected directories can now be created and maneuvered within using these changes.

19. Summary • During the course of this project, we: • Added encrypted file functions efopen() and efclose() • Added those encrypted file functions into glibc • Added two general purpose encryption/decryption utilities based on the encrypted file functions • Modified the kernel as a basis for providing password-protected directories • Modified the bash and tcsh shells to use password-protected directories • Modified /bin/mkdir to create password protected directories