Secure Access to Cloud-based Source-Code

I've had this idea for about a week now -- I want to store my working source-code tree in the cloud, securely, so that I can access it from my machine at work, or from home.  I use a laptop at work as my primary machine -- which is cool -- but I really hate lugging the damn thing back-and-forth from work to home. In my mind, it introduces risk - shoving a laptop into a backpack and trundling 70 or so miles (one-way) just doesn't seem, to me, to be the best way to treat delicate electronics, even if said device was designed to be portable.  There's also the additional liability of theft or loss of the device.

Like most geeks, my home machine makes a far better development environment because it has significantly more display real-estate, more memory, and faster everything else.  I don't have to hunt for a spare power receptacle to plug the laptop into, or work off the kitchen table because my desk is already at capacity.

So I came up with the idea (and I'm not claiming this to be original - but it does work) that if I could store my source code in the cloud, then all I'd need is a duplicate operating environment (apache, mysql and the db contents, etc.) while I ran my development source from the cloud, pushing it to the stage-server when necessary, thereby always maintaining the code in a consistent state across platforms.

I need the repository to be stored under subversion, and I want really decent encryption so that if the account gets hacked, my code isn't exposed.  (Protect corporate assets.)

Oh, and I want it to be free.   :-)

And to be large enough to store my entire project.  (I like CloudApp and DropBox, but I don't feel they offer either enough space for what I need to do, or the ability to access the remote "device" as a filesystem.)  Here we go...

I decided to use a service called ZumoDrive for my cloud storage simply because they offer 2Gb of mountable file storage.  Unlike others, this storage is visible as a mounted drive on your desktop.  It's also compatible with Mac OS X, Linux, Windows, and mobile devices (Android, iPhone and Palm Pre).

Go to their website - I've linked it above - and download the appropriate file -- they pretty much walk you though every process -- and install the file on your machine.  On my Mac, the install requires only 4.7Mb of disk space.  Sweet.  Once installed, you'll be asked to create an account or log in to an existing account.

I first installed this application on my desktop machine.  I created a login/password using my favorite account management tool, 1Password, and I chose a randomly-generated 16-bit password.  As an aside, the more I use 1Password, the more I rely on their password-generator.  I'm breaking the mold of the rotating-three passwords and using something that's both non-intuitive and random to protect my accounts.

Once I've created an account, and logged-in to the account, I'm now in the Zumo landing page, or what they term the "Dojo".  Initially, Zumo offers you 1Gb of free storage but if you take an extra couple of minutes to run through their tutorial and examples, they'll quickly bump you (promoting your account in "belts") to the maximum storage freely available of 2Gb.  Sweet.

What you now should have is a mounted drive on your desktop that looks like any of the other connected devices.  This virtual drive is accessed like any other drive which allows you full file-system management to the device.  (You can copy and delete files and stuff.)

Before we do anything, we want to prepare the device.  I was wondering if the data you stored on the cloud device was secure so I searched-for and found this blog post from Zumo which basically states:

The file being uploaded is transferred to the ZumoDrive server which is hosted by Amazon's EC2 (Elastic Compute Cloud).  It is done via 256-bit SSL encryption.  SSL is the same type of encryption used when you log into your bank's secure website.  The EC2 is the workhorse.  It's the liaison between the client on your computer and the ZumoDrive datacenter (which is hosted by Amazon S3; more on this below).  It also services the ZumoDrive website.

Ok, so the data you store on the device is already being encrypted.  Cool.  But what if you want it to be really, really encrypted?  Should you be this paranoid?  Consider the excerpts from this article:

"As set forth in our privacy policy, and in compliance with United States law, Dropbox cooperates with United States law enforcement when it receives valid legal process, which may require Dropbox to provide the contents of your private Dropbox ... It is also worth noting that all companies that store user data (Google, Amazon, etc.) are not above the law and must comply with court orders and have similar statements in their respective terms of service."

I am only storing source code.  But it's not my source-code -- it's the IP of my company.  Therefore, your encryption methods do not satisfy my requirements and I shall have to devise an alternative strategy.

It's called Truecrypt.

I've already extensively blogged about Truecrypt in a 3-part post so I'm not going to cover the basics here.  Go read or review the series if you need a refresher on using Truecrypt and creating secure files and volumes.

Start TrueCrypt and create an encrypted file on your Zumo device.  I'm going to create a 500Mb encrypted file container on the Zumo drive.  I'm going to use multi-pass encryption scheme with a strong hash algorithm.  I'm going to use my 1Password program to randomly generate a password to control access to this container.  I'm creating this as a FAT filesystem, fully formatted.  Total time to format was about 10 seconds.

Once I've created the file container, I have to mount it.  I do this by selecting the file from within the Zumo filesystem share, using the TrueCrypt manager/program, and clicking "Mount".  I supply my password and the encrypted file container is now mounted to my desktop.  I now have two devices mounted -- the original Zumo drive and the TrueCrypt file container within the Zumo drive.

Were someone to access my Zumo device, without the TrueCrypt module, all they will see is a 500Mb file with my container name.  Stored inside the container is what appears to be random bits.  Perfect.

I can still store files to the Zumo device, along side my container file -- they will not be encrypted using TrueCrypt however.

The next step is to install my source code repository.  I use the best PHP IDE in the whole multi-verse:  PHPStorm by JetBrains.  It's so good, that this checkout process will be amazingly simple and fast.  My code repository will be checked-out from, and completely maintained in, subversion by the IDE.  Sweet.

I realize you may not yet be enlightened yet to PHPStorm and that's ok.  Use your inferior product to valiantly struggle to get the source code out from repository into the TrueCrypt volume.  You may even be successful!

For the rest of us, we simply select: Checkout From Version Control -> Subversion, and select the repository (svn+ssh://...).  The tricky part, for us Mac users, is that we have to locate the filesytem destination for the source-code files under the directory Volumes beneath the root mount-point.  In the Volumes directory, you will see (at least) two Volumes -- one for your Zumo drive and one for your encrypted container within the Zumo Drive.

If you want your source code to be stored in the encrypted container, within the Zumo drive, you have to select the encrypted container.  In the screenie shown, my container is creatively named "NO NAME".  This is the device I will select to check-out my source code into.  I'll create additional paths within the container that are proprietary to the application.

Once that's done, I click "OK" and, in the next dialog, tell PHPStorm to check-out from the HEAD and include external locations.  The final dialog asks me for version compatibility and I select 1.6.  The check-out process within PHPStorm takes off.

For my code base, checkout the entire code library and storing it to the encrypted volume took less than four minutes for slightly more than 100Mb worth of files.  True, there is processing overhead in retrieving the encrypted file form storage and de-crypting the file on-the-fly (and the same holds true in reverse) but the files are secure and my company's IP is protected.

From this point, as long as I have both the Zumo drive, and the TrueCrypt, software installed on whatever platform, I can access my source code, securely, from the cloud while ensuring that the source code itself remains current.

With the exception of the JetBrains PHPStorm IDE, the Zumo drive and the TrueCrypt software programs are open-source and free to use.

As a final caveat, this system puts you at the mercy of your ISP -- if there's no internet access, then you'll be unable to access your files.  Also, you'll want to make sure that you stage your source code regularly.  My general rule-of-thumb is to commit only when I reach the point where I don't want to have to re-engineer and re-type in the new code, or modifications, that I would lose should something happen to my cloud repository.

Final Notes

Zumo drive maintains it's files locally on your machine so that you always have off-line access to your files.  Therefore, you're really not at the mercy of your ISP.  You are, however, at the mercy of your hard drive space and your connectivity upload speed.  It took me hours to upload my 500Mb encrypted file container to Zumo -- at 77K/sec, it was not only painful, but it also bogged down my network speeds so that other idle entertainments (WoW) were pretty much impossible.

The upload speed lag, which I blame both my ISP and Zumo (throttling) for, meant that earning "achievements" from Zumo wasn't instantaneous -- I had to wait for network processing to complete before I could earn my "belts".  Eventually I did get up to my 2Gb of free storage so it's all good.

Upcoming Project...

I've got a project I'm going to start over the weekend.  I'll try to document it as thoroughly as possible because I think it's (a) a cool project and (b) someone else may learn from it. Here's what's happening.  I currently have four desktop systems:

  1. 27" iMac i7 (main work machine)
  2. Windows Vista Box - fairly powerful - previous work machine - has been "off" for about 6 months.
  3. Windows Vista Box #2 - Sarah's machine.  Slower box.  HP Mini Desktop.
  4. Linux server custom built but incredibly old.

My plan is:

  1. to retire the Linux server, this being the second such linux box I've retired in the last 16 years -- so there's a ton of data on it that needs to be backed-up and migrated over to what will become the new linux server.
  2. Save Sarah's data on the HP mini-desktop over to my old Vista box via the network.
  3. Wipe Sarah's box and install centOS hardened.
  4. Transfer my data from the old custom box to the new CentOS box.
  5. Retire the old custom box by reformatting it with Ubuntu.
  6. Configure the Linux box with a dedicated IP.
  7. Get Sarah's box restored and running on the network.

Start plan 2 of the project:

  1. Install Asterisk on the Linux server and configure it as a VOIP switch.
  2. Install soft SIP clients.
  3. Install kfone over the SIP clients.
  4. Test for proof of concept.

That's the summary - commentary and encouragement welcomed!

Let's Talk TrueCrypt - Part 2

In our last session about TrueCrypt, we discussed what it was, as a product, and some of the features offered by the software. In today's topic, we're going to go a little more practical and do some work with encrypted files.

Our overall goal is to create a file container which has not one, but two encrypted volumes residing within it.  Remember last session, how we talked about "plausible deniability"?  Well, this article is where we'll put it into practice.

So, we want to create a file on a some sort of disk volume.  It doesn't matter what type of media we use.  This could be your local hard drive, a USB key drive, a drive on your local network, or a drive out on the cloud.  All that matters is that your operating system is capable of "seeing" the file itself.

The process is simple - we're going to create a container "file" for the encrypted volumes.  This file defines the size of the disk space available for storing encrypted files.  In other words, if you need to store a 200Mb file, creating a container volume of 100Mb will be insufficient.  (You can't put something that's larger than the object you're trying to put it into to.  Not yet, anyway....)

For my example, I've chosen a volume on my Dropbox account so that my data is available to me on any machine where I have both the Dropbox and TrueCrypt clients installed.  Accounts are free and they offer 2Gb of storage.  Getcha summadat.

While you're doing that we're going to talk about files and how TrueCrypt organizes files and how data is stored on physically on the platter.

At the physical layer on a traditional hard-disk drive platter, data is referred to as "magnetic media".  This is because, at the microscopic level, you have a slab of iron that's aligned a particular way.  If this slab of microscopic iron is aligned one way, you have a "1", the other way, a "0".  Read-in enough of these 1's and 0's and you have a data stream.  How the data is tracked on the physical partition is not in the scope of this article (and should already know something about this anyway), but suffice to say that if you organized your 1's and 0's into, say, header blocks and data blocks, then it'd be possible to associate the data stream into something meaningful.

However, data by itself, without organization just looks random.  Without knowing how data is organized physically, there's nothing to distinguish meaningful data from random-appearing data.  And this is the concept I want you to keep in-mind when we get to the part about plausible deniability, ok?

Using TrueCrypt, what we're going to do is create a file by reserving a certain amount of disk space assigned to the file.  You'll use TrueCrypt to mount the file, as if you were mounting a filesystem - a volume - where you can store files, images, etc.  Then, again using TrueCyrpt, you're going to contain a second filesystem within the first one.  Depending on which password you provide determines which filesystem gets mounted.

In other words, let's say you have a USB drive that you carry with you.  On it, you have source-code files for your latest project.  You do not want to lose your source code because it's worth millions (!) and you're nearly code-complete on the project you've been working on.

However, the Elbonians wants your source code and will stop at nothing to get it!  So, they kidnap you.  And they take your USB drive and plug it into their computer.  But, wait!  Your drive is encrypted with TrueCrypt!  The entire drive is meaningless without the password!  They ask politely for the password and you, of course, refuse.

It's not until you come under the extreme duress of having a loaded sling-shot placed against your knees that you relent.  You sob convincingly as you blurt the password to the outer filesystem.  The Elbonian hacker types in your password, and, success!  The filesystem mounts, and they see your source code files!  They quickly transfer them to their computer, chucking in a sinister fashion amid much elbow nudging.

However, the Elbonian spymaster is not so easily fooled!    He asks the hacker how large were your files and the hacker pockety-pocks out the answer of 100MB.  The spymaster looks at your USB drive and blinks.  A 2GB USB drive and you only have 100MB used?  Sure, you reply.  Blink.  Blink.

Scan the rest of his drive, he orders the hacker....whir...whir...whir... and.... nothing.  All meaningless random data, reports the hacker.  The spymaster chucks your stick back at you, laughs once, and forces out of the rolling minivan...

See, there really is no difference in appearance between random data, and encrypted data (given a proficient encryption schema).  If, for some reason, someone, against all odds, was able to crack the second (hidden) filesystem and actually access your files, you could always claim plausible deniability because you weren't aware of the presence of those files.  For all you know, some sophisticated worm on your Windows box (they won't believe you if you're using a Mac or a Linux machine) was writing out to the hidden filesystem.

Anyway, I hope you get the points made in that massive rathole we just traveled down.

Let's get back to the how-to...

Fire up TrueCrypt and let's create a volume - for demonstrative purposes, we're going to create a volume on our local hard drive, but you could use TrueCrypt to create a volume anywhere - a USB stick, a network device, even a cloud-mounted device like DropBox.

When you select "Create Volume" the first dialog box that opens asks if you'd like to create either an encrypted file container, or a volume within a partition or drive.  The first option is for inexperienced users, so we're going to select the that option and click the [Next] button.  (Unless you'd like to reformat one of your existing disk partitions which is the rocky road you'll head down should you choose that option.)

This dialog asks if you wish to create a standard TrueCrypt volume (eg.: a single volume) or a Hidden TrueCrypt volume - like what we talked about before.  Click on the Hidden TrueCrypt volume option and click the [Next] button.

The next dialog asks us to select a device -- this is where the volume will be located physically.  Again, for demonstrative purposes, I'm going to create my volume on my local drive.  Feel free to create yours where ever you like and click the [Next] button to continue.  (Note that you may be asked for your administrator's password.  Just because you're using the software doesn't mean can run amok on another system sucking down their available hard drive space for your nefarious schemes...)

Oh, and it's a good idea to leave the box "Never save history" checked....

Ok - here's where we select both the encryption and hashing algorithms.  TrueCrypt offers three types of encryption, in varying combinations.  AES, Serpent and Twofish.  I've thoughtfully provided links to the Wikipedia links explaining what each encryption algorithms entail.  What's interesting is that TrueCrypt allows you to use combinations of the three singly, in pairs, or in triplets.  So, for example, you choose AES-Twofish -- this means that this is two ciphers operate in a cascading faction: blocks are first encrypted with Twofish, and then with AES.  Each cipher uses it's own 256-bit key and all keys are mutually independent on one another.

The hashing algorithm you select at the bottom of the dialog box can be either RIPEMD-160, SHA-512, or Whirlpool.  The hashing algorithm is used by the TrueCrypt random-number-generator as a 'pseudorandom "mixing" function, and by the header key derivation function (HMAC based on a hash function, as specified in PKCS #5 v2.0) as a pseudorandom function.'

Select whichever hashing algorithm you prefer, along with any encryption algorithm and click the [Next] button.

In the next dialog box, choose the size of the outer partition keeping in-mind that the inner partition you're planning on installing cannot be larger than the outer partition.  Enter in the appropriate number, select the units from the drop-down dialog, and press the [Next] button.

The next dialog asks you for your outer-volume password.  This is the password that you will reveal if coerced into doing so.  You should choose a password that is significantly different from the inner-volume password.  Type the password in twice, leave both option boxes unchecked, and click the [Next] button.

The next dialog asks you to move your mouse randomly within the dialog box to generate a seed for your encryption keys.  When you get tired of watching numbers rip across the dialog, click [Format] to create the outer volume.

Once formatted, you will see an informational screen which (wisely) advises you to place files into the outer volume.  These should probably be files that you don't mind being discovered, but you would still want to encrypt.  Old tax records, emails, work financials, that sort of thing.  Click [Next] when you're done with all that.

In this section, we're going to deal with the Hidden volume.  In my test case, the size of the outer volume was predetermined so it's asking me to click [Next] to move on.

Doesn't this dialog look familiar?  This is the same encryption/hashing dialog that you saw to format the outer volume.  This time, we're going to do the same thing, except we're going to format the inner volume.  I'd strongly suggest that you choose different encryption and hashing algorithms for the outer volume than what you selected for the inner volume.  Make your selections and click [Next].

In this dialog, choose the size of the inner partition.  I'd recommend about 50% of the entire file size.  If you go larger, it may appear obvious that there's something else hidden within your file.  Click [Next].

Choose a very strong password.  I'd strongly recommend using 1Password to generate a hideously-long nonsensical string that you'd need 1Password to provide as there's no way in Hell that you're going to remember it.  (I'll talk about 1Password in a follow-up article.)  As before, leave the check boxes alone and click [Next].

Select the filesystem format.  This may vary from OS to OS.  I'm going with FAT.  Click [Next] and then do the mouse-move-random-number thing.  Click [Format] when that bit's over.

You should see a pop-up that says that the TrueCrypt volume has been successfully created and is now ready for use.  Yay!

In part-3, I'll wrap all this up and explain the bits and pieces I glazed over.  For now, you know enough to start banging away on your filesystem...