I just finished up an extremely challenging, albeit frustrating, task for my employer and just wanted to get some opions on how everyone may of done this differently.
Task:Design a Secure system by which employees can upload electronic documentation and provide a digital signature along with the document to validate that they are, in fact, the person that completed the document.
Deliverables
-The digital certificate must reside on a portable medium such as a USB Stick and NOT installed into the machines local store.
-If the device is lost or otherwise compromised, a would be thief can not have ready access to the certificate.
-A USB Stick must be tied to a user.
-The system must work on machines that have a host operating system of Windows 2000 and later.
-The system must work on thin clients that connect to a terminal server via RDP5
Limitations
-SSO (Single Sign On), or any other variance of 2 factor authentication, through Active Directory is not a possiblity.
Deadline
-4 Weeks
Resources
-1 Developer
This is what I came up with:
First the web application where users upload files to; this was the easy part. It accepts a file to upload, a .PFX (Certificate) file, and a text box to supply the password associated with the .PFX File.
The file upload is rudimentary, to validate that the password supplied for the .PFX file is valid, I simply created an instance of an X509Certificate and passed in a reference to the uploaded .PFX file and the password, if the password was invalid I simply handle the error that is generated and tell the user that the password is invalid, otherwise the data is sent to the database. (For the sake of simplicity and time, everything on the backend works, and there are additional checks that are proprietary to my employer)
Second, the portable medium.
My first thought was to use a USB Token but, given my time constraint coupled with the fact that I have no experience with USB Token's (or CSP's for that matter) I abandoned this idea very quickly.
I ultimately decided on a plan USB Flash Drive which presented all sorts of problems. Without some sort of 3rd party software, you can not partition a flash drive in windows, you can not set the entire drive to read only at all, and all data stored on a thumbdrive is readily accessible to anyone that has the drive (unless there is some sort of third party software involved).
My solution to all of the above problems were solved when I stumbled upon an open source project known as TrueCrypt. I am not going to give you an entire rundown of what the app does, to check it out go here:
http://www.truecrypt.org/ .
The end result of using TrueCrypt was very simple: the root of the USB drive contained 7 Files (2 TrueCrypt files 5 files of my own design). What TrueCrypt does is it creates a file on your thumbdrive of whatever size you wish (lets say 500mb) and that file represents an encrypted volume that can then be mounted to the file system using the TrueCrypt application. You can add files to this "Drive" and any other action that can be preformed on a logical drive, the thing is, the files that you place in this mounted drive can not be seen unless you mount the encrypted space from the USB Drive!
So, if someone were to simply delete this encrypted file, all of the data contained within it would subsequentally be lost as well. So, I solved the problem of a thief getting the drive and potentially stealing the certificate since the certificate is placed in the encrypted volume.
Tying a USB Drive to a user ended up expanding on the security that is built into the drive. The encrypted volume requires a password to be supplied to it before it will mount and, obviously, if you don't know the password you can't mount the volume. Well, to tie a User to a USB drive I would need to access some sort of data that would either confirm or deny the relationship between User and USB Stick and my solution for this became an all encompassing solution to the drive.
**I simply wrote an Autorun.inf file that asks the user to launch X application that does 2 things:
1)It grabs the logged in windows identity and the serial number of the USB Drive that is plugged into the system. (I us Application.StartupPath to get the drive the app is executed from as to not get a serial number of another device plugged in via USB) This data is sent to our SQL Server for verification. If machine the drive is being accessed from is not connected to our network the application simply exits if, however, the SQL Server verifies that the user/usb relationship matches:
2)Since the encrypted volume requires a password before it will mount and since I can run TrueCrypt with command line arguments from the USB Stick itself, I decided to create a "Master Key" for the volume which is also stored in our SQL Server. The key is retrieved from Sql and way of a System.Windows.Diagnostic.Process() i spawn a command line window that executes the TrueCrypt application on the USB Drive which successfully mounts the encrypted volume to the users local file system.
Simply put: without access to out network and the user account that the USB Drive is mapped to, there is no way to get at the certificate on the encrypted volume. (Zealots: yes, anything can be cracked given enough time) On top of that, a thief would also need to know the Password associated with the .PFX file contained within the encrypted volume.
The above points work on systems with Host Operating systems of Windows 2000 and WindowsXP.
The thin client deliverable was somewhat of a problem for me. Since i was coming over an RDP connection my code would not run with Full Trust on the server and after countless attempts trying to demand the permissions from the .NET Framework, I realized that since the thin clients physical name would never change and that a USB Drive attached to the thin client ALWAYS maps the same way, I could provide full trust permissions through the .NET Configuration to provide full trust perms to the UNC Path of the applicaiton. This worked like a charm but there was another pitfall here.
TrueCrypt requires a .sys file to run (which is contained on the usb drive) however, over an RDP connection truecrypt simply wont run. What i had to do was alter my program that mounts the volumes so that it could handle the different environments. What I ended up doing was playing the TrueCrypt software on the server and, if the client is coming in over an RDP connection, I mount the encrypted volume by making a call to the EXE that resides on the server, not the USB Stick, and this worked wonderfully.
This is kind of long winded, but this was a definate challenge for me, so if any of you have actually made it this far would you of done this implementation differently?
**In the event the user did not approve the autorun they are unable to do anything with the thumbdrive. If they double click on it through windows explorer they are prompted by TrueCrypt to enter the password for the encrypted volume. If they choose to explore the volume all they can see are the 7 previous mentioned files and can not really do anything.
================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
================================================== =========
Technical Editor for:
Professional Search Engine Optimization with ASP.NET
http://www.wiley.com/WileyCDA/WileyT...470131470.html
================================================== =========
Why can't Programmers, program??
http://www.codinghorror.com/blog/archives/000781.html
================================================== =========
Opinion - How would you of done this differently?
on their post!
