Efficient methodology for implementation of Encrypted File System in User Space

(IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 Dr. Shishir Kumar Departme nt of CSE, Jaypee Institute of Engg. & Technolog y Guna (M.P.), Indi a dr.shishir @yahoo.com U.S. Rawat Departme nt of CSE, Jaypee Institute of Engg. & Technolog y Guna (M.P.), Indi a umasrawat@gmail.com Sameer Kumar Jasra Departme nt of CSE, Jaypee Institute of Engg. & Technolog y Guna (M.P.), Indi a Akshay Kumar Jain Departme nt of CSE, Jaypee Institute of Engg. & Technolog y Guna (M.P.), Indi a Efficient methodology for implementation of Encrypted File System in User Space Abstract — The Encrypted File System (EFS) pushes encryption services into th e file system itself. E FS supports secure storage at the syste m level through a standard UNIX file system in terface to encrypted files. User can associate a cryptogr aphic key with the directories they wish to prot ect. Files in these directories (as well as their pathn ame components) are transparently encrypted and decrypted with the speci fi ed key without further us er intervention; clear text is never store d on a disk or sent to a remote fi le server. EFS can use any available fi le syste m for its underlying storage without modifications, including remote file servers such as NFS. System m anagement functions, such as fil e back up, work in a normal m anner and without knowledge of the key. Performance i s an important factor to users s i nce encryption can be time consuming. This paper describes the design and implementation of EFS in user space usin g fast er cryptographi c algorithms on UNIX Operating system . Implementing EFS in user space makes it portable & flex ible; Kernel size will also not increase resulting in more reliable & efficient Operating System. Encryption t echniques for file system level encryption are described, and general issues of cryptographic system interfa ces to support ro utine secure computing are discussed. Keywords- Advance Encryp tion st anderd, Electronic code bo ok mode, EFS daemon, Intialization vector, Ne twork File system. I. INTRODUCTION Encrypted File System is an interface that ensures the user that the data stored on the hard disk is secure and cannot be hacked by any ot her user without t he permissi on of the owner. It ensures t hat the original data doesn’t reside on the hard disk in th e normal or th e plaintext form , but it shoul d always been stored in encr ypted fo rm which cannot be understood by the intru der. As in our current file syste m, it is normally stored in plaintext o n the hard disk. So, if s omeone hacks the data stored in hard di sk then that person can easily access the data. But if the file is stored in an encrypted form on the hard disk, the hacking in such ca ses won’t be so effective. User should not be aware about the locati on where the encryption and decryption take s place. By using encryption and decryption methodolo gies, user can secure his data and store it on the hard disk in an unreadable format. Several recent incidents accentuate the n eed for a cohesive solution to the problem of st orage security that pro tects data using strong cryptograp hic methods in both perso nal and organizational scenarios. This paper investigat es the implications of cryptographic protection as a basic feature of the file system interface. II. RELATED WORK There are many architectures and procedures avai lable in these areas that have already b een implemented. Ve ry few of them are implemented in user space and m ost of them are in kernel space. Each one of them is having ce rtain advantages and limitation s. The crucial issu es of both, systems level and user level cryptogra phy are as mentioned bel ow. A. ISSUES WITH USER LEVEL CRYP TOGRAPHY The simplest approach for file encryption is available through a tool, such as the UNIX crypt program, that enciphers (or deciphers) a file or data stream with a specified key. Depending o n the particular softwa re, the program may or may not be automatically delete the clear text while encrypting and such progr ams can usually be used as cryptographic "filters" in a co mmand pipeline. Another approach i s integrat ed encryption in application software, where each program which has to manipulate sensitive data h as built in crypto graphic facilities. F or example, a text editor could as k for a key when a file is (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 opened and autom atically encrypt and decrypt the file’s data as they are written and read. All those ap plications that will be operated on the same data must, include the same encryption engine. An encryption filter, such as crypt, might also be provided to al low data to be im ported into and exported out of ot her software. Unfortunately, neither approach is entirely satisfactor y in terms of security, generality or convenience. The former approach, which allows great flex ibility in its ap plication, invites mistakes; th e user could inad vertently fail to en crypt a file, leaving it in the clear, or cou ld forget to delete the cle ar text version after encry ption. The manual nat ure of the encryption and th e need to supply the key several ti mes whenever a file is used ma kes encryption too cumbersom e. More seriously, even when us ed properly, manual encry ption programs open a window of vuln erability while the file is in clear form. It is alm ost im possible to avoid occasionally storing clear text on the disk and, in the case of remote file servers, sending it over the networ k. Some appli cations simply expect to be able to read and write ordinary files. In the application based approach, each program m ust have built in encryption functionality . Although encryption takes place automatically, the user stil l must supply a key to each application, t ypically when it is invoked or when a fil e is first opened. Software without encryption cap ability cannot operate on secure data witho ut the use of a separate encryption pro gram, maki ng it hard to avoi d all the pro blems outlined in the p revious text. Furth ermore, rather than being confined to a single progra m, encryption is spread among multiple applications, each of which must be trusted to interoperate securely and co rrectly with the others. A single poorly designe d component c an introduce a significant an d difficult to detect window of vulne rability. Changing the encryption algorithm entails m odification of every pr ogram that uses it, creating many opportunities of implementation errors. Finally, multiple copies o f user level cryptographic code can introduce a signifi cant performance penal ty. [1] B. ISSUES WITH SYS TEM LEVEL CRYPTOGRAPHY One way to avoid m any of the pitfalls of user level encryption is to m ake cryptographic servic es a basic part of the underlying sy stem. In designing s uch a system , it is important to identify ex actly what is to be trusted with clear text and what requi res cryptographic protecti on i.e. we must understand what components of t he system are vul nerable to co mpr omi se . For files, we are usually interested in protecting the ph ysical media on which sen sitive data are stored. This in cludes online disks as well as backup copies, which ma y persist long after the onli ne versions have been del eted. In distributed file server based system s, it is often also desirabl e to protect the net work connection between client and server since these links may be very eas y for interception attack [1]. Physical media can be protect ed by specialized hardware. Disk controllers are commercially available with embedded encryption hardware that can be used to encipher entire disks or individual file blocks with a specified key. Once the key will be provided to the con troller hardware, encryp tion will be completely transp arent. Th is approach has a number of limitations for general uses. The granulari ty of encryption keys must be compatib le with the hard ware; often, the en tire disk must be thoug ht of as a single prote cted entity. It i s difficult to share resources among users who are not willing to trust one another with the same key. Ob viously, this approach is only applicable wh en the required hardware is available. Network connecti ons between client machines and file servers can be protected wit h end-to-end encryption. Specialized hardware m ay be employ ed for this purpos e, depending on the parti cular network invol ved, or it may be implem ented in software. Howeve r, all networks does not support encrypti on and among t hose that do, al l system vendors does not su pply worki ng implem entations of encryption as a standard product.[8] Even when the various pro blems wi th media and network level encryptio n are ignored, the combination of the two approaches may not be ade quate for the prot ection of data in modern distri buted systems. In particular, even though clear text may never be stored on a disk or sent "over the wire", sensitive data can b e leaked if the file server itself is compromised. At some point file server must maintain, the keys used to encipher both the disk and the net work. Even if the server can be completely tr usted, direct media encryption on top of network e ncryption has a num ber of shortcom ings from the point of view o f efficient distributed syst em design [2]. Further, the alternative approach taken by the Encrypt ed File System (EFS) has been mentioned. E FS pushes file encryption entirely into the client file system interface, and therefore does not suffer from many of the di fficulties inherent in user l evel and disk and network based syst em level encryption. III. CRYPTOGRAPHIC SERVICES IN THE FILE SYSTEM The main focus of EFS is to identify the lo cation in a system, where file encryption will be p erformed. If it is at too low level, then trust s in components are rem oved from t he user’s control. If it is t oo close to the user, frequent human interaction may lead to erro r. A. DESIGN GOALS EFS occupy som ething of a m iddle ground between low level and user level cryptography. It aims to protect exactly those aspects of file storage that are vulnerable to attack in a way that is convenient enough to use routinely. In particul ar, we will be guided by the fo llowing specific go als: Key management sche me: The sensitive in formation of the file in encrypted file system is access by the key which is taken as the input from the user as a passphrase. This key is used to encrypt the conten t of the file and also help in returning the orig inal content of the file. There must be a way to get this key fro m the user. It is taken in the form of (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 passphrase. It is the m ost crucial input to th e encrypted file system on whi ch the whole secu rity of the system relies. Transparent access semantics: Encrypted files should support the same access methods availabl e on the underlying storage system. All system call s should work n ormally, and i t should be possible to compile and execu te in a completely encrypted environment . Transparent performance: Encryption algorithms are computationall y intensive, bu t the overhead shou ld not be too high so as to discourage the use of encrypted fi le system in the real scenario. Security of file contents: Th e f ile contents shou ld be secure effectively so that no other perso n gets to know about t he data without the kn owledge of key, t he structural data shoul d also be protected e.g. Informa tion in the header & footer of the file should not generate same ci pher text. Natural key granulari ty: It should be easy t o protect related files under the sam e key, and it should be easy to create new keys for other fi les. The UNIX directory struct ure is a flexible, natural way to gr oup files. Compatibilit y with underly ing system services: The fi les and directory generat ed by the encrypted fi le system should behave normall y and should be ma nageable as the normal file in the file system. Portability: Th e encrypted file system shou ld use the available functionali ty and features. The files and directory should be seen no rmally whe never the key i s supplied to t he file system. Scalability: The en cryption engine should not place an unusual load on any shared component of the system. Fi le servers in parti cular should not be required to perform any special additional processi ng for clients who requi re cryptographic protecti on. Compatibilit y with future technologie s: Several emerging technologies ha ve potential appl icability for prot ecting data. In particular, key s could be contained i n or managed by "smart cards" that would rem ain in the physical possession of authorized users. A n encryption syst em should supp ort, but not require, novel hardware of this sort. B. EFS FUNCTIONALITY AND USER INTERFACE Encrypted File System interacts with stan dard UNIX file system through system calls and treats all the files in same manner, irrespecti ve of file being encrypted or normal file of standard file system . It prevents user fr om entering t he same key several times. The EFS att aches a key to a directory and all the files within th at direct ory are automatical ly encrypted. When this directory is at tached to the En crypted File System directory, then all the operati ons on the file can be executed. The files are automatically decr yp ted when they are read and are encrypted when write operation is performed. No modifications are required on the fil e system on whi ch encrypted files are stored. EFS provides “Virtual File System” on cl ient’s machine typically mounted on /crypt, th rough which user access their encrypted files. All the files a re stored in the encryp ted form and with the encryp ted path na me in associated director y. These files are not visible to th e user until th ey attach the associated directory to the /cry pt of the EFS. The underlying encrypted directories can re side on any accessible file system, including remote file servers such as Sun NFS [6]. No space is required to be pre- allocated for EFS directories and user controls EFS throug h commands like create, attach, detach etc. To use Encrypted File System user has to create a directory and EFS by issuing comm and em kdir, with this key associate a passphrase i.e. key which is us ed by EFS to encrypt all the files within that director y. The passphrase should be at least 16 characters long. For instance, it can be “This is Encrypted File System”. The emkdir works sam e as mkdir of D OS, but here we have to give passp hras e in order to make it secure. Eg $ emkdir/user/jas/efs (name of the encrypted directory) (user enters passphrase, which does n ot echo) (same phrase entered again to prevent errors) In order to use the files in the directory in the n ormal form, we have to supply key to the EFS. This is ach ieved by attach command. It takes three para meters. 1. Passphrase 2. Name of directory created 3. New name of direct ory $ attach /user/jas/efs aks Key: (sam e key used in the cm kdir command) If the key is supplied correctl y, th e user "sees" /crypt/aks as a normal direct ory; all standard operat ions (creati ng, reading, writing, compiling, executing, cd, mkdir, etc.) works as expected. The actual files are stored under /user/jas/efs, which would not ordinarily be used di rectly. Access to attached directories is controlled by restri cting the virtual directories created under /crypt using the standard UNIX file protection m echanism. Onl y the user who issued the attach command is permit ted to see or u se the clear text files. This is based on the uid of the user; an attacker who can obtain access to a client machine and compromise a user account can use any of that user’s curre ntly attached director ies. If this is a concern, the attached name can be marked obscure, which prevents it from appearin g in a listing of /crypt. When an attach is made obscure, th e attacker must guess its current name, which ca n be randomly chosen by the real user. Of course, attackers who can become the "super user" on the client machine can thwart an y protection scheme , including this; such an intruder has access to the entire address space of the kernel and can read (or modi fy) any data anywhere in the system. In order to rem ove the directory as files from /crypt we will use the command detach which removes the entry from the /crypt of EFS. Fil e names ar e encrypted and encoded in an ASCII representa tion of their binary encry pted value padded out to the cipher block of size eight byt es. (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 $ detach aks Some data are not protected. File sizes, access times, and the structure of the directory hierar chy are all kept in the clear text. (Symbol ic link pointers are, however, encrypted.) This makes EFS vulnerable to traff ic analysis from both real t ime observation and snaps hots of the underly ing files; whether this is acceptable must be evaluated for each application. IV. FILE ENCRYPTION METHODOLOGY EFS use Advance Enc ryption Standard (AE S) [4] to encrypt the file data. There are various modes of AES; one of it is Electronic Code Book (ECB) m ode. [5] In which each eight byte block is encry pted indivi dually. The main short coming of ECB is that it will produ ce same cipher text for the identical plain tex t block. It will help the cryptanalyst to find structural similarity o f the data and help to decrypt the tex t easily. Other modes of AES are various chainin g ciphers. These modes help in reduci ng the shortcom ing of ECB m ode. It helps in overcoming t he problem of structural anal ysis. But the problem with this mode is that, the random access of file becomes difficult due to reason that all the blocks are dependent on the cipher preceding block. Since 56 bit key is vulnerable to exha ustive search of the ke y space. To remove this problem we will use m ultiple AES to provide more security to d ata. To remove both the shortcomings of ra ndom access and struct ural analysis, we had used both the modes of AES. The 128 bit supplied key is crunched into two halv es of 56 bit key. Now the first 56 bit is used to calculate the long initial bl ock with AES OFB mode. Now whenever a file is to b e written, it is XOR’ed with the initial block a nd then encrypte d by the second key usi ng AES with ECB mode. When reading, the cipher is rever sed in the obvious m anner, first decrypt in ECB m ode then XOR it with initial b lock. This method helps us to overcom e both the problems of random access and structural anal ysis. It is clear that the protection against at tack is at least as strong as a singl e AES pass in ECB mode and m ay be as strong as two passes with AES stream mode cipher. It is likely that the scheme is weakened, in such situation th e attacker might be able to search for the two AES s ub keys independe ntly. If there a re several known pl aintext file encry pted with sam e key. In the chaining mode, as far as the Initialization Vecto r (IV) is different, the cipher text of identical blo ck will be different. For this purpose we can at tach IV to the beginning of file fo r maintaining atomicity. Encryption of path nam e components uses a simi lar scheme with the additio n that the higher ord er bit of clear text name are set to a simple checksum computed over the entire name string. It is import ant to emphasize that EFS protects data only in the context of the file s ystem. It is not, in itself, a co mplete, general purpose cry ptographic security sy stem. Once bits have been returned to a user program , they are beyond the reach of EFS’s protection. This means that ev en with EFS, sensitive data mig ht be written to a p aging device when a program is swapped out or revealed in a trace of a program ’s address space. Systems where the paging device is on a remote file system are especially vulnerable to th is sort of attack. (It is theoretical ly possi ble to use EFS as a paging file system, alt hough the current im plementation does not readi ly support this in practice.) .It shou ld also be taken into consideration that EFS does not protect the links between users and the client machines on which EFS runs; users connected via networked t erminals rem ain vulnerable if these links are not otherwi se secured. A. PROPOSED ARCHITECTURE The EFS prototy pe has been im plemented entirely at user level, communicating with the Unix kernel via the NFS interface. Each client machin e runs a special NFS server, efsd (EFS Daem on), on its localhos t interface, that interprets EFS file system requests. At boot tim e, the system invokes efsd and issues an NFS mount of its localhost interface on the EFS directory (/crypt) to start EFS. (To allow the client to also work as a regular NFS server, EFS runs on a different port number from standard NFS.) The NFS prot ocol is designed for remote file servers, and so assumes that the file system is very loosely coupled to the client (even though, i n EFS’s case, they are actually the same machine)[6]. The client kernel communicat es with the file system thro ugh remote procedure cal ls (RPCs) that im plement various fi le system related primitives (read , write, etc.). The server is stateless, in that, it is n ot required to maintain any state dat a between individual clien t calls. All communication is initiated by the client, and the server can simply process each RPC as it is received and then wait for the next. Most of the complexity of an NFS implementation is in the g eneric client side of the interface, and it is therefore often possible to implement new file system services ent irely by adding a simple NFS server. efsd is implemented as an RPC server for an extended version of the NFS protocol. Additional RPC s attach, detach, and otherwise control encrypted d irectories. Initially, the root of the EFS file system appear s as an empty directory. The attach command sends an RPC to efsd with arguments containing the full path name of a directory , the name of the "attach point", and the key. If the key is correct, cfsd computes the crypt ographic ma sk (described in the previous section) and creat es an entry in its root di rectory under t he specified attach poin t name. Th e attach point entry appears as a directory owned by the user who issued the attach request, with a prot ection mode t o prevent others from seeing its contents. Encryption of pathnam e components uses a simi lar scheme, with the additio n that the high ord er bits of the clear text name (which are norm ally zero) are set to a simple checksum computed ove r the entire name st ring. This frustrates structural analysis of long names that differ onl y in the last few characters. The same method is used to encrypt symbolic link pointers. For each encrypted file accesse d through an attach point, efsd generates a uniq ue file handle that is us ed by the client NFS interface to refer to the file. For each attach point, the (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 User Leve l Application Any Program System Call Interface FS Client File system (remote) F S SV R In te rf ace Stora g e System call File system interface cleartext UNIX Kernel EFS daemon m aintains a table of handl es and their corresponding underl ying encrypted nam es. When a read or write operation occu rs, the handle is used as an index into this table to find t he underlying fil e name. efsd uses regul ar Unix system calls to read and write the file con tents, which are encrypted before writi ng and decrypted after reading, as appropriate. To avoid repeat ed open and close calls, efsd also maintains a small cache of file descriptors for files on which there have been recent operati ons. Directory and sym bolic link operations, such as read dir, readlink, and loo kup are similarly translated into a ppropriate system calls an d encrypted and decrypted as n eeded. To prevent intruders from issuing RPC calls to EFS d irectly (and thereby thwarting the protection mech anism), efsd only accepts RPCs that originate fro m a privileged port on the local machine. Responses to the R PCs are also returned only to the localhost port, and fil e handles include a cryptographi c component selected at attach t ime to prevent an attacker on a different machine from spoofing one side of a t ransaction with the server. It is instructive to compare the flow of data under EFS with that taken under the standard, u nencrypted file sy stem interface. Figure 1 shows the architecture of the interfaces between an application pr ogram and the ord inary Sun "vnode based" Unix file sys tem [3 ]. Each arrow between boxes represents data crossing a kernel, hardw are, or network boundary; the diagram sh ows that data written from an application are first copied to th e kernel and then to the (local or remote) file system. Figure 2 shows the architecture of the user level EFS prot otype. Data are copied several ext ra times; from the app lication, to the kernel, to the EFS daemon, back to t he kernel, and finally to the underlying fi le system. Since EFS uses user level syst em calls to communicate with the underlying file system, each file is cached twice, once by EFS in clear form and once by the underlying syst em in encrypted form . This effectively reduces the available file buf fer cache space by a factor of two. The architecture described above helps in analyzing the efficiency of the algorithm . To analyze an algorithm is to determine t he amount of reso urces (such as tim e and storage) necessary to e xecut e it. Most algorithm s are designed to work with inputs of arbitrary length. Usually the efficiency or complexity of an algorithm is stated as a function rel ating the i nput lengt h to the number of steps (time complexity) or storage locations (space complexity). Figure 1: The Architecture of norma l V-node file system in Unix Figure 2: The Architecture of the user level EFS prototype Therefore this algorith m has complexity O (n 2 ). Its an important issue that while considering algorithms, one often measures complexity via the number of comparisons that occur, ignoring things such as assignments, etc. It will be suitable to keep track of any factors, in particular those which proceed with the domina ting su b term. In the DES, the factor applied to the dominatin g sub term, namely n 2 was 3/2, and by coincide nce, this was also the fact or that User Level Application Any Program Unix Kernel System Call Interface FS Client(NFS) EFS Daemon N FS server interface System call File system interface clear text Encryption/decryption Engine Unix Kernel System Call Interface FS Client ( NFS ) System call FS Client ( NFS ) File system(remote) File system interface encrypted Storage (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 came with the second term, namely n. It is obvious that an algorithm which is linear will perform better than a quadratic one, provi ded the size of t he problem is large enough, but if it is known th at the problem has a size of, say, at most 100 then a c omplexity of ( 1/10) n 2 might be preferable to on e of 1000000n. V. RESULTS & PERFORMANCE EVALUATI ON After implementing encrypted file system, it has been tried to find out the change in the sp ace of file i.e. the variation of space of the encry pted file form the original file. For that some file of s pecific size has bee n taken and enc rypted it using the encrypted file system. The Table-1 sh ows the variation of siz e of the origi nal file whe n encrypted by EFS. The variation in size of encrypted file is approximately 2.5 times the size of the original file. As the encryption algorithm is computationally intens ive, the computational time has been computed for t he file of sam e size with EFS. The time taken by EFS to encrypt file of specific size is shown in Table-2. The final result is that both the time and space of the encrypted gra ph in crease with the increase in the size of input file. For the purpose of comparison stand ard utility of UNIX has been used i.e. crypt , which is used to encrypt and decr ypt the file in the UNIX [7]. The same size of input files have been taken and the size of output file have been analyzed to get the variation in time and space and com pared it with the time and spa ce variation of enc rypted fil e system. The variation i n size is s hown in Table-3 and the variation in the time is shown in the Table-4. Table-1: Difference in size of original and encrypted file by EFS Size Of Original file Size Of Encrypted File 909 bytes 2.3 KB 3.6 KB 9.3 KB 9.5 KB 24.5 KB 10.7 KB 27.5 KB 15.6 KB 39.9 KB Table- 2: Time taken by EFS to encrypt a file Figure 3 : Variation in size of original file Figure 4: Variation in time according to size Table -3: Difference in size of original and encrypted fi le by crypt Size of Origi nal File Time Taken By Encrypted File System 909 Bytes 278 ms 3.6 KB 304 ms 9.5 KB 358 ms 10.7 KB 381 ms 15.6 KB 410 ms Size Of original file Size Of Encrypted File By crypt 909 Bytes 1.6 KB 3.6 KB 4.5 KB 9.5 KB 14.5 KB 10.7 KB 16.3 KB 15.6 KB 22.5 KB (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 Figure 5: Variation of size of original file by Crypt Table-4: Time taken by Cryp t to encrypt a file Size Of Original File Time Taken By crypt To Encrypt 909 Bytes ≈ 0 ns 3.6 KB ≈ 0 ns 9.5 KB 10000 ns 10.7 KB 10000 ns 15.6 KB 20000 ns VI. CONCLUSIONS & FUTURE WORK The proposed model of EFS provid es a simple mechanism to protect data written to disks an d sent to networked file servers. Alth ough experi ence with pr oposed model of EFS is still limited to the research env ironment, rather performance on m odern workst ations appears t o be within a range that allows its routine use. Obvio usly, it has shortcomi ngs of a us er-level NFS ser ver based implementation. The client file system interface appears to be the right place to protect fil e data. If we consi der the other alternative s, encrypting at the application layer is inconven ient. Application based encrypt ion leaves wi ndows of vulnerability while files are in the clear or requ ires the exclusive use of special pu rpose appli cations on al l encrypted files. At the disk level, the granu larity of encryption may not match the us er’s security requirements, especially if different file s are to be encrypt ed under different keys. Encrypt ing the netw ork in distri buted fi le systems, whi le useful i n general agai nst network based attack, does not protect the act ual media and the refore still requires trust in the server not to d isclose file data. The main focus of EFS is t o reduce the barri ers that stand in the way of the effective and ubiquitous utilizatio n of file encryption. This is especially releva nt as physical media remains exposed to t heft and unauthorize d access. Whenever sensitive d ata is being handled, it should be the modus operandi th at the data be encrypted at all times when it is not directl y being access ed in an authori zed manner by the applications. It can be im plemented on modern operating systems without having to chan ge the rest of the system. Better perform ance and stronger sec urity may be achi eved by running the file system in the kernel. Proposed m odel of EFS is more porta ble than other kernel based fi le systems because it interacts with a st a ndard vnode interface, as the quick ports to Li nux. R EFERENCES [ 1 ] M . B l a z e , “ A C r y p t o g r a p h i c F i l e S y s t e m f o r U N I X , ” in Proceedings of t he ACM Conference on Computer and Comm unications sec urity, Fair fax, VA, U SA, Nov. 1993, pp. 9–16. [2] Howard, J.H., Kazar, M.L., Me nees, S.G., Nichols, D.A., Satyanaryanan, M. & Sidebotham, R.N. " Scale and Performance in Distribut ed File Systems." ACM Trans. Computing Systems, Vol. 6, No. 1, (February ), 1988. [3] Kleiman, S.R., "Vnodes: An Architecture for Multiple File System Types in Sun UNIX." Proc. USENIX, Summer, 1986. [4] Nati onal Bureau of Standards, "A dvance Encrypti on Standard" FIP S Publication #19 7, NTIS, 26 N ov 2001. [5] National Bureau of Standa rds, "Data Encrypti on Standard M odes of Operat ion." FIPS Publicat ion #81, NTIS, Dec. 1980. [6] Sandberg, R., Goldberg, D., Kleima n, S., Walsh, D., & Lyon, B. " Design and Im plementati on of the Sun (IJCSIS) International Journal of Comput er Science and Info rmation Security, Vol. 3, No. 1, 2009 Network File System." Proc. USENIX, Summer, 1985. [7] dm-crypt: a de vice-mapper c rypto target for Linu x. [Online] Available:http://www.sa out.de/misc/dm-crypt/ [8] Encfs -Virtual Enc rypted Filesystem for Linux. [Online]. Available: http://en cfs.sourceforge.net/ AUTHORS PROFILE Dr. Shishir Kumar Dr. Shishir Kumar is currently working as Associate Professor and Head in Dept. of Computer Science & Engineering, Jaypee Institute of Engineer ing & Technolog y, Raghogarh Guna, India. He has completed his PhD in the area of Compute r Science in 2005.He is having around 12 year teaching experience. He has publis hed several papers in international/nat ional referred journals and conferences. His area of Interest is Network Security & Image Processing. Mr. U.S. Rawa t U.S. Rawat is currently working as Sr. Lecturer in Depart ment of CSE, Jaypee Institute of Engineering & Technology, Raghogarh Guna, India. He received his B.E. in 1999 from Amravati University, Amravati ,India. He received his M.E. in 2003 from S.G.S.I.T.S, I ndore, India. H e is working t owards his PhD f rom JUIT Waknagat, India. He is hav ing eight years of teaching experience. His areas of interest are Information System s & Network Security.