Sei sulla pagina 1di 6

PROJECT TITLE: XML-BASED ENCRYPTING FILESYSTEM

COLLEGE:
TEAM MEMBERS:

SPONSORED BY:
PROJECT GUIDE:

PROBLEM DEFINITION
A large portion of sensitive information is stored in the form of files, especially on
personal computers and laptops. Enforcing physical security, which was always a key
component in the protection mechanism of the past, has always been cumbersome and is
becoming less achievable. As a traditional way of compensating the loss of physical
security, encryption is being slowly integrated in the schemes of file protection.
Existing solutions provide the basic functionality, that is, they make it possible to protect
files by encrypting them. The solutions are however, not very well integrated into their
respective operating systems and underlying filesystems. In order to effectively deploy
the solutions, users must be aware of the functionality and know their limits.
With the aim of improving both user experience and security, we have proposed and
implemented an XML-based filesystem that performs not just encryption/decryption on
behalf of the filesystem, but also access control.
TECHNOLOGY USED : PYTHON AND XML

PLATFORM: LINUX
SOFTWARE REQUIREMENT:

FUSE-2.4.0

FUSE-PYTHON

PyXML-0.8.4

Xmlsec1-1.2.9

Pyxmlsec-0[1].3.0

ezPyCrypto-0.1.1

HARDWARE REQUIREMENT:

PENTIUM 1.9GHz

128MB RAM

PROJECT DESCRIPTION:
Introduction
The invention of personal computers and their subsequent proliferation brought sensitive
data, which had always been stored and protected in the safe havensenvironment of
datacenters, to an unsafe and insecure real world. The operating systems designed with
security in mind always relied on the premise that physical security is the keystone of
security. As the new technologies enable computer systems to spread into locations with
less-than-perfect physical security, like a laptop computer in a managers briefcase, Tthe
premise is no longer valid, of course, as technology takes computers to unsafe locations,
in the shape of laptops, for instance.

An example might be a typical Unix operating systems filesystem. While files are very
well protected by the operating system while it is running, it only protects the file when
they are accessed through its interface. The actual bytes on the disk are not Pphysically ,
they are not protected at all. One good example of a solution is the EFS (Encrypted
FileSyste m) which provides the option of enforcing encryption on a sub-tree of the
filesystem on modern Windows servers.
The question is whether we can protect our files when or if they happen to be out of our
physical protection.
Problem
Some partial solutions and coping mechanisms do exist, but none adequately solves the
problem. With the advent of multi-user systems and remote terminals, the physical
security was somewhat less enforceable. Files were tagged with permissions, so that the
operating system would protect files of one user from the actions of another; a logical
separation is applied.

Refering to Figure 1, the physical security can be defeated by simply breaking the facility
which stores the information, or the security features of the operating environment must
be found faulty and exploited. Attacker can simply sit at a physically unprotected
terminal and guess a superuser password.The attacker simply needs access to the physical
storage where data is stored, even if it means stealing the disk, for instance.
Solution

To solve this problem, we have proposed and implemented an solution using XML-based
filesystem (XEFS) wherein the filesystem properties are represented within an XML
document and filesystem calls are translated to create, read, and delete XML elements. In
addition, Along with this all the sensitive information is encrypted beforeand then storing
to disked. Encryption renders important data, even if accessed by an unauthorized person,
unintelligible and unusable.
Figure 2 gives an overview of our solution wherein the attacker must break the
cryptographic protection to get hold ofn the sensitive information. Hence gaining
physical access is not a solution for the attacker.
The attacker who chooses the operating environment path will have to bypass two layers
of security:
1. Enforcement of access control lists is provided by the use of XML and
cryptography. If a user has not beens given the read access right to someone, it
can be ensured that they will not be ablecan be sure that only that person can to
read the file. It can similarly be ensured that They can also be sure that only those
with proper write privileges tampered with the protected files
2. The files are protected by encrypting the content prior to storage of the file on the
physical device.

The file system has been implemented in user space. The sSystem runs with help fromof
FUSE (File System in User Space). The XML files themselves are encrypted using W3C
recommendations for encrypting and storing XML Encryption Elements.

Salient Features:
Access Control Lists : We have implemented access control lists to fine-tune access to a
file down to every user/group. A non-root user has no permissions by default and needs to
be given explicit read/write/execute permissions.
Multi-programming support : We support basic multi-program access to the filesystem
using a simple filetable implementation in our Filesystem Access component.Our
implementation maintains access control list in XML document which are used in the
authentication module. After being authenticated, the encryption/decryption module is
used to write/read the file. The filesystem access implementation is used to keep track of
the file in use, similar to the underlying filesystem.
Advantages of XML :

Using XML makes our filesystem implementation hierarchical, extensible and portable
to various filesystems/Linux implementations.