1

Encrypted Network File System

Robin Thomas, Student, University of Hyderabad
AbstractDesign and implement an encrypted Network File System (NFS) [2] for the Linux operating system, which allows one to
view, store and update files on a remote server as though they were on the users own local computer. The file system should support
most of the common file system commands, and at the same time provide security that is fundamentally lacking in most NFS file
systems.
Index TermsNetwork File System, NFS, FUSE.

I NTRODUCTION

VER the past few years, several vulnerabilities had

been reported for cloud based file storage services like
Google Drive [3], Dropbox [4], Facebook [5] and Amazon
[6]. Though they had taken steps to prevent the vulnerabilities from getting exploited on their discovery and patched
up the bugs within weeks, no one can dispute the claim that
bugs keep appearing and private data keeps getting leaked
online.
Millions of people fall prey to numerous data breaches
every year. For the majority of them, the results are bad. The
attackers shall sell users data on underground websites [7],
companies pay a huge sum of money to their clients, and
consumers lose money. Recent breaches like Sony pictures
[8] and Apple iCloud [9] brings light to one indisputable
truth - your data is not secure online.
The first step in making your data secure is by encrypting your data. Encryption softwares are dime a dozen. You
can use one to encrypt all your files and store it online. When
the need arises, you just have the download the file and
decrypt it. But when you have hundreds of files, it doesnt
make sense to keep them all within the same directory. A
better idea would be to store the files in different hierarchy
within your remote server. When the need arises, you just
need to navigate through your server, download the file,
decrypt the data, access it, edit it, encrypt it again, and
upload the file back to the server. What if you need to do
the same for hundred of files? What if you need to do it
regularly?

R ELATED W ORK

In conventional network file systems, when a NFS Client

requests a file, the NFS Server checks whether the NFS
Client have access to the NFS Server by checking for an
entry in /etc/export file [13]. If such an entry doesnt exist,
connection is refused. If such an entry exists, the file is sent
to the client, assuming that user can access the file in the
file system. This approach is not secure, as anyone can use a
packet sniffer to rebuild your files or spoof their IP address
to a valid IP address in the /etc/export file and then access
the NFS Server.
Sshfs [14] file system is the file system that most users
use for accessing remote data securely. But sshfs encrypts

the data only on transmission and the load of encrypting

the data falls heavily on the NFS server, which can cripple
it, in case of many NFS clients. Meanwhile, anyone with
access to the NFS server or an attacker who gains access to
the server, can access your data. Since the data is stored in
plain-text form in the server, your private data is now in the
hands of your attackers.
EncFS [12] file system can store your files with encryption. The disadvantage here is that encFS is used to encrypt
a local file system. To be able to use it within a network, we
need to build sshfs over it. So when the local user request a
file, the request shall be sent to sshfs, which shall delegate
it to encFS, which shall retrieve the file and send it to sshfs,
which shall send it to the client. Though this approach does
look feasible, most users would find it quite difficult to setup
two file systems, and at the same time, make them interact
with each other.

3
3.1

I MPLEMENTATION
Modules Developed

3.1.1 Security
This module deals with encrypting and decrypting files,
creating private keys and public certificates and communicating securely between the client and the server. When
either the server or the client is first booted up, the system
shall create a private key and a public certificate. Since the
private key is encrypted with a password, even if someone
gets access to your private key file, its still in encrypted
form.
The private key and the public certificate is generated
from 2048-bit RSA keys. When the client and the server
communicate, only the public certificate is exchanged. For
every communication between the client and server, the
system uses TLSv1.2 encryption. So every data exchanged
between the client and the server is in encrypted format.
Since the data stored in the server is in encrypted format,
this module shall encrypt the data when writing to a file and
decrypt the data from reading from a file.
3.1.2 Authentication
Since the file system uses TLSv1.2, the security handshake
present in the TLS protocol is handled internally by the

security module. In this module, the server and client shall

authenticate each other.
When the client is contacting the server for the first
time, the client shall send a special request to the server,
stating that the client is new and would like to create
an account in the server. Server shall discard requests it
doesnt understand. It shall perform necessary operations
and create a unique code and send it to the client. This code
uniquely identifies the client, and should be sent with every
subsequent request to the server.
When the client is contacting the server not for the first
time, the server shall check the existence of the code send
by the client in its system. If the code is present, the client
is authenticated. The server shall send back the code to the
client so that the client can trust the server too.
Fig. 1. Data flow diagram of Authentication module

3.1.4

ENFS

This module deals with the actual encrypted network file

system, and is built using FUSE (File System in Userspace)
library. It comprises of an ENFS client and an ENFS server.
When the user performs a local file system call, it shall
be detected by the FUSE process, which shall pass it to
the ENFS client process. It shall determine the type of file
system call, construct the correct file system request and
send it to the server.
The ENFS server shall detect the incoming request, and
shall determine that its a file system call, and determines the
type of file system call. It shall perform the operation locally
and construct a response and send it back to the client.
The client receives the response from the server, parse
it, and perform the necessary operations on them. The user
is transparent to all the exchanges happening between the
client and server.
Fig. 3. Data flow diagram of ENFS module

3.1.3

Multithreading

This module deals with the multithreading aspect of the

server. When the server process is launched, its initialized
with a set of threads or workers (default value is 100) and
placed into a worker pool.
When a client request comes, the server shall pick one
available worker from the pool and allocate it to the client.
Once the client request is finished processing, the worker is
returned back to the worker pool.
When a client request comes, and no workers are available, the client request is placed into a queue of pending
requests. When a worker becomes free, pending client requests shall be processed in a first-in-first- out manner. If
the queue is full, and a client request arrives, the request is
dropped.

3.2

Work Flow

Fig. 4. Data flow diagram of ENFS file system

Fig. 2. Data flow diagram of Multithreading system

3.3
3.3.1

Design Choices
Storing No File Data In Client

All the data that the client displays to the user is either
read from its cache or from the server. No file data is
actually stored in the client. So when the ENFS file system
is unmounted, even if the client is compromised, your files
in the server are still secure. Even if someone tries to mount
the file system, they still need your password to proceed
with the client.

3.3.2 Client Unique Code

When a client connects to the server for the first time, and
send a special client initialization request to the server, the
server shall generate a special code and send it back to
the client. The client shall send the code along with all
subsequent requests to the server. The server shall use this
code to uniquely identify the client.
3.3.3 Worker Pool
If the server doesnt support multi-threading, only one client
can connect to it at a time. All other clients need to wait till
server finish processing the pending clients request. This is
not an efficient method.
Another method is to allocate a thread for every new
client request. But in this case, when the server receives too
many client requests or the server is attacked, it can run
out of threads and resources, like in a DDOS attack. So the
efficient approach is to use a worker pool.

R ESULTS

ENFS comes with a support for,

Support for creating files [touch, echo, vi]

Support for creating directories [mkdir]
Support for deleting files [rm]
Support for deleting directories [rmdir, rm -r]
Support for copying files [cp]
Support for moving files/directories [mv]
Support for renaming files/directories [mv]
Support for listing files/directories [ls]
Support for moving into directories [cd]
Support for reading files [cat, head, tail, more, less]
Support for writing files [echo]
Support for changing file/directory permissions
[chmod]
Support for GUI file system

C ONCLUSION

The conclusion goes here.

R EFERENCES
[1] H. Kopka and P. W. Daly, A Guide to LATEX, 3rd ed. Harlow, England:
Addison-Wesley, 1999.
[2] Network File SYstem, http://www.tldp.org/LDP/nag/node140.html
[3] Google Drive vulnerability leaks users private data,
http://thehackernews.com/2014/07/google-drivevulnerability-leaksusers 9.html
[4] IBM
exposes
critical
Dropbox
vulnerability,
http://www.esecurityplanet.com/mobile-security/ibmexposes-criticaldropbox-vulnerability.html
[5] Facebook
vulnerability
leaks
users
private
photos,
http://thehackernews.com/2015/03/facebook-photo- sync-hacking.html
[6] Amazon
S3
leaks
private
data,
https://nakedsecurity.sophos.com/2013/03/29/amazon-s3-cloud-storagedata-leak/
[7] Underground black market thrives on private data,
http://www.symantec.com/connect/blogs/undergroundblack-marketthriving-trade-stolen-data-malware-and-attack-services
[8] Sony Pictures Entertainment hack, http://en.wikipedia.org/wiki/Sony
Pictures Entertainment hack
[9] Apple iCloud Hack, http://www.ibtimes.com/apple-icloud-hack-obvioussecurity-flaw-patched-after-new-years-day-disclosure-1773648

FUSE, http://fuse.sourceforge.net/doxygen/
OpenSSL, https://www.openssl.org/
Valient Gough, http://www.arg0.net/#!encfs/c1awt, EncFS file system
Security
and
NFS,
http://www.tldp.org/HOWTO/NFSHOWTO/security.html
[14] Miklos Szeredi, http://fuse.sourceforge.net/sshfs.html, sshfs

[10]
[11]
[12]
[13]