Saturday, April 4, 2009

Pen Drive Security System

Recently I with my team-mates made a solution to a problem statement released for an Intra Collegiate Event. The problem( in brief ) goes as follows:

1. You have to design a Pen Drive security system that resides on a Pen Drive, does no installation of software on a Operating Client and provides on the go run facility, as in plug and shoot.

2. The security should be two leveled where the Files are encrypted with a Key and a suitable algorithm( the key will generally be random ). The key has to be stored in a way so that it is secured via the main password that the user shall hold or the private key.

3. The software should preferably have a nice looking GUI, extra points for Native look.

Our Approach:

1. As the system has to be supported fully on a Operating System we definitely cannot assume packages like Java to be installed which can easily be the best choice for a platform-independent choice. Packing a whole JVM was a waste of effort as it'll take huge amount of space.

2. We used GTK+-2.0 for the same reason. Being a small and a protable library and having a cross platform support in Windows/Linux we'll have enough to say in terms of portability. Also the look and feel of GTK is far-far-far better than say Java-MOTIF or else!

3. The software installed will have two layers of security

(a) The master password which will be held by the master user.( there will be user accounts just
as in unix etc )

(b) A random key will be used to encrypt a file sored under the device. The random key will be encrypted via the master password and stored as the first bytes of the file. The Encryption algorithm used shall be of highest quality, namely, AES!

Have a look at the snapshots and u'll have a good feel of the software :)














5 comments:

  1. Interestingly my approach was almost identical (was there another better way?). I had sessions (equivalent to a 'user account'); though my GUI was not as polished (I did it hastily in Java; it communicated with the main C++ program through a socket, the main C++ program being a console program; the essential functionality was almost the same though) and I had not automated adding directories in one go.

    ReplyDelete
  2. Btw i didnt get the whole point of using C++ along with Java. How is it going to help you, and using both of them seems to be a very confusing and unobvious option... C++ and JAVA.... you could always that!

    Regarding the Algorithm that was always very obvious.. we had plans to increase the User security... we can always discuss that sometime :).

    Regarding the interface... thats all that was there in terms of mark content... but i wud still like to see your baby :)

    ReplyDelete
  3. The whole point was creating a socket based interface ... I did this so that any XYZ program could communicate with my program through an open socket. I mean it could tell my program to, say, encrypt abc.xcf and put it in the session SessionOne. This would have helped other programs easily take advantage of the functionality my engine provides.

    Now once the basic headless engine was done to create a GUI I used Java since it allows for very intuitive GUI coding and a really nice socket library. I could have used any language (even Python if I knew enough of it) to create the GUI - the GUI code never directly interfaces with engine code; it simply sends commands and receives messages through an open socket ...

    ReplyDelete
  4. ok... I am not really a very good Software Designer but what I feel is that the amount of work you did was not necessarily needed for the given problem statement... it's a 2 piece, one engine and one listener you had made. Was this much( if at all :P ) thinking required for the lame thing??

    ReplyDelete
  5. Me too not a good software designer ...

    The problem was lame ... true ... I kind of got carried away. Such complexity was definitely not required.

    ReplyDelete