DIY Cryptography System

Introduction

This is a short case study for an informal, do-it-yourself cryptography system. The goal is to be able to secure variable amounts of information without much effort or cost.

Background

I decided to use TrueCrypt because it was free, open source, and popular. I found myself leaning towards the argument that open source software is more likely to be defect-free, and thus in this case, more secure.

TrueCrypt is relatively flexible in terms of applying a password when encrypting files. In addition to having a password, you can also apply one or more "keyfiles". A keyfile can be any file on your computer. TrueCrypt can also generate these keyfiles and place extremely random data inside them.

Keyfiles mitigate the risk of an adversary obtaining your password through malware, social engineering, or brute force.

Code

To make the keyfile system more viable, I got a USB drive with a readonly hardware switch. This protects against a scenario where malware is on a machine of interest, and it's programmed to delete data, particularly on a USB drive. It's relatively important that the drive not be infected and that the keys not ever be deleted. Even with this protection, I would recommend making additional local backups of the keys.

I considered getting a USB drive that was engineered to be extremely durable. These devices can withstand heavy environmental shock (e.g. water submersion or physical impact to the device). In the end, I decided the biggest risk was not that, but rather malware.

TrueCrypt has a built-in tool which allows you to generate keyfiles, and it's very easy to use. Unfortunately, there doesn't currently appear to be a TrueCrypt tool for bulk keyfile creation; you have to make them one at a time. This was a slight problem for me because I had decided to increase the level of security for this keyfile system. Specifically, I wanted to mitigate against the risk the USB drive (or its contents) would be obtained by an adversary. The solution, in my eyes, was simply inverting the classic needle-in-the-haystack problem so that it was in my favor. Instead of having, say, one keyfile, or even 100 keyfiles, why not have one billion or more keyfiles, where you are the only one who knows which keyfile sequence works? (A TrueCrypt-generated keyfile, or one made to look like it, is only 64 bytes, so you can certainly make a lot of them.)

The following code generates keyfiles that are similar to what TrueCrypt will make. The disadvantage is the keyfile content is surely not as random, and I also didn't hire a cryptologist to consult me while writing this code in LINQPad. (If you were concerned and motivated enough, TrueCrypt is open source, so you could simply port all or some of their keyfile generation code.) The advantage is that it generates a lot of them real fast. You will probably want to add some "salt" to this code to make it more unique and harder to reverse engineer. A very simple modification you could start with is changing the random seed to something else.

const int NumKeys = 10;
const int NumBytesPerKey = 64;
const string KeysFolder = @"C:\Users\Alexander\Keys\";
const string KeyExtension = @".key";
int RandomSeed = DateTime.Now.Millisecond;

Directory.CreateDirectory(KeysFolder);

var random = new Random(RandomSeed);
for(int keyIdx = 0; keyIdx < NumKeys; ++keyIdx)
{
    const int NumInts = NumBytesPerKey / sizeof(int);
    
    ICollection<byte> byteSequence = new List<byte>();
    for(int intIdx = 0; intIdx < NumInts; ++intIdx)
    {
        int val = random.Next(int.MinValue, int.MaxValue);
        byte[] bytes = BitConverter.GetBytes(val);
        foreach(byte b in bytes)
        {
            byteSequence.Add(b);
        }
    }
    
    File.WriteAllBytes(
        KeysFolder + "key " + keyIdx.ToString() + KeyExtension,
        byteSequence.ToArray());
} 

While I was at it, I decided to slap on a few finishing touches to the generated keyfiles. I wanted them all to look the same; to all look like hay, if you will.

const string DirectoryToProcess = @"C:\Users\Alexander\Keys\";

DateTime timestamp = DateTime.Now;

foreach(string directory in Directory.GetDirectories(DirectoryToProcess))
{
    var directoryInfo = new DirectoryInfo(directory);
    
    directoryInfo.Attributes &= ~FileAttributes.ReadOnly;
    
    Directory.SetCreationTime(directory, timestamp);
    Directory.SetLastWriteTime(directory, timestamp);
    Directory.SetLastAccessTime(directory, timestamp);
    
    directoryInfo.Attributes |= FileAttributes.ReadOnly;
};

foreach(string filePath in 
    Directory.GetFiles(DirectoryToProcess, "*.*", System.IO.SearchOption.AllDirectories))
{
    File.SetAttributes(filePath, File.GetAttributes(filePath) & ~FileAttributes.ReadOnly);
    
    File.SetCreationTime(filePath, timestamp);
    File.SetLastWriteTime(filePath, timestamp);
    File.SetLastAccessTime(filePath, timestamp);
    
    File.SetAttributes(filePath, File.GetAttributes(filePath) | FileAttributes.ReadOnly);
}  

Finally, to permanently delete copies of the keyfiles that are, for instance, on your local hard drive, delete all of them, empty the recycle bin, and then run the following command from the command line, where YourDrive should be replaced with the drive of interest. (Note that this is for a Windows environment; there are similar utilities in other operating systems.)

cipher /w:YourDrive

For example, if you wanted to apply this to your C drive, the command would be:

cipher /w:C

Points of Interest

Can a highly skilled adversary still determine which keyfiles are being used, perhaps with some cutting-edge equipment that can tell which 1s and 0s on the USB drive have been read most recently? I have no idea, but I'm guessing the answer could be yes. However, addressing that is definitely beyond the scope of this post.

So what are some possible weaknesses for this system? I'm interested in hearing what they might be and how one might go about addressing them.