Encrypted File System

Standard

This post is a kinda report on my progress with my OS (name revised to BabyOS, suggest names please). Right now, I’ve implemented an Encrypted File System (EFS), which is quite similar to existing file-systems with just one twist. As the name suggests, the information inside the file system is encrypted. Yes, this does cause an overhead while data transfers but its a tradeoff between over head and security (I believe in “better secure than late and better late than never”). This post explains how I implemented the Encrypted File System and the complexities involved. All the code (wherever necessary) will be linked to paste site (codepad.org) where you can check out what the actual code looks like.

When I first started to code my own OS, I had difficulty in finding a perfect route map that tells me where to begin and where to end (though I’ve coded a boot loader, but thats just it). One day, during a Systems and Network prgramming lab here at college, the guy who was the incharge told me that he uploaded some stuffs on EFS on the server. I had decided by then that I’d modify Minix just to reduce the work load and better understandability of the underlying concepts (you cannot code an OS by applying “learning while coding” theory). I looked it up, it was simple. I just had to modify some tid-bits and it was made (well, all in my mind only). So, I took this as my first step towards salvation.

Lets see what defines a file system first. Wiki (my love) says “A file system (often also written as filesystem) is a method of storing and organizing computer files and their data. Essentially, it organizes these files into a database for the storage, organization, manipulation, and retrieval by the computer’s operating system.”. If you add “it also provides data security and integrity by applying certain encryption methods” then the file system is said to be an EFS, simple aint it?! *sarcastic smile*.

Enough of theory, I will assume that you know the basic concepts of file systems like the i-node table and the super block and LRU and MRU and the list goes on. The Minix file system consists of two pre-coded i-node structures in src/servers/fs/type.h. These are the disk core i-node table. The structures are given in the following paste:

http://codepad.org/4h3GV9Ss

the first two structures were pre-coded, the entries are self documented and easy to understand if you know the basic concepts of file systems (drona89@live.com is always open for doubts if you have any). The last structure was the one I made on my own. Its similar to the second structure (d2_inode) and has one extra entry, the last entry holds the key the AES encryption algorithm uses (AES is beyond the scope of this discussion/walk through, in short, it is a block cipher).

The reason why I made this structure is because making a new i-node actually creates a whole new file system. So it is easy to port it to somewhere else and also if I have to make any future mods, it wont effect the existing file system. In simple words, I can now remove a whole file system and replace it without doing much changes to the original source code.

Now, lets jump to the in-core i-node table. This i-node table exists in the memory (a distinction made here is, when I say memory, I do not mean the hard drive). this structure looks like this:

http://codepad.org/b2MVJhXY

Again, the fields are self explanatory, look at the “char d4_key[64]” entry. This holds the key to the EFS in memory. The i-node table contains complete information a file requires when it is manipulated. Again, I’m diving into the theory as this is just a walk through, comment or rather mail me on my email id and I’ll reply back (I promise!!).

The next step was quite mind boggling. I had to take help from the guys of Syracuse University (no I didn’t actually talk to anyone of them, my faculty did and got me something the guys over there call a SEED document). The MINIX 3.0 maintains a LRU of disk blocks. It is stoic to the emotions of the different file systems. Since we are programmers and not quite as adamant, we can define the data portion of the buffer as the union of all possible i-node formats. Here is the code, I’ll point out my mods I did:

http://codepad.org/DTmw1FbC

jump to line 19. This is the data format of my EFS.

The next post will take you through the rest of the complexities like defining prototypes and the actual do_login() procedure to log into the file system and also some other stuffs. Concisely put, we will see some more C codes (both header files and program files) that I had to modify to get it working.

May the force be with you

Code_ninja

PS: A few updates. The name of the OS is now NyxOS and not BlackOS. Nyx is the Greek Goddess of darkness and night. The OS is no longer being coded taking MINIX as the base system, in fact, it was getting a bit too tough using MINIX as the base system. Everything is now coded from scratch including the boot code, interrupts, file system etc. Any one interested in joining me in development may please mail me at drona89@live.com.

PPS: The EFS as a project has been discontinued. I heard that one of my friends in final year is making an EFS too. Bleh! I should not have started this in my second year… sigh. :\

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s