OK, you all know I am paranoid about backups. But I have a security/cryptography background and that got me thinking about the use of encryption of MSS (WHS) systems.

I grabbed a copy of TrueCrypt (http://www.truecrypt.org/) and installed it on my MSS/WHS. Swapped my non-pool drives around to have 1TB as the external, deleted everything on it and have encrypted the entire volume. TRIED to mount that volume and backup the shares to it as well as my backup database. I chose levels of protection that should be more than adequate -- the defaults are OK for US Government "Top Secret" information-- and would not be comfortable leaving my backup disk almost anywhere (rather than only in a Safe Deposit box. All this, so far, from an RDP session. Next will be to get it to run using Advanced Admin Console, but I do not expect that to be a problem.

EDITED above to reflect that I tried to mount the volume and then do the backups through the MSS/WHS Console. It seems that the console will not recognize volumes that are not physical disks. (The encrypted volume is either a file on an existing disk or the entire disk or partition that is mapped to another logical drive.) I can mount the volume fine but cannot see it in the Connector Console. There are instructions over on http://www.homeautomation-direct.com/blog/?p=59 that can be followed to set up scripts to do this. I will be grabbing the scripts and modifying them appropriately for my next attempt.

By the way, I also installed it on my Vista Client and have encrypted a couple 8GB "sticks" that I use for financial data. Now I am comfortable leaving one in the car and another in the camera bag. (No problem with the "mounts" on clients!

So, why the thread? I am thinking of taking this another step and seeing if we can encrypt the entire MSS pool... Anyone tried anything like this yet? (And why have I not thought to suggest this as a feature for the next generation of WHS before now?) EDIT: Obviously this is not looking quite as feasible given the mount problems. I had hoped to somehow dismount "D:" and replace that with an encrypted version. (I have NOT given up hope yet!)

Anyone tried this yet? Any thoughts on the subject?

OK, looks like I am finally on the right path here, at least for a side-track from my original intent to encrypt the WHS "pool" disks. (Will work on that next year!)

WHS will not let me see volumes (disks) "mounted" by TrueCrypt when I am in the Console, but I really do want to encrypt my WHS backup disks. I had to revert to the CMD file approach that was taken in the article linked above to do this.

To run this you need to install RoboCopy and TrueCrypt (see referenced article). Using TrueCrypt I encrypted an entire 1TB external disk to use as the target for the backups. (Empty the disk before setting it up.) It took about 2 1/2 hours to set up but the performance when I played with it after doing that was fine on my system. The CMD file will shut off some WHS services, mount the encrypted volume, synchronize the backup database to a copy on the volume, turn the services back on, synchronize the shared folders with a copy on the volume and then exit. First time will take a LOOOONG time to run. Subsequent ones should be quick depending on your activity since the last use. I have tested the first part and it is actually creating that first copy of the backup database as I type (and will be for a while). The very last command (to copy the shared folders) has not yet been tested so if you try that before I post again be sure to test it.

Here is the current version of the CMD file. It is similar to the ones in the article except it combines them and does first the backups and them the shares. It also mounts an entire volume, not just an encrypted file.



The rather obvious next step is to schedule this CMD file using the Task Scheduler and automate the entire process.

Note that this resolves TWO problems: (1) encrypting the backups and (2) scheduling them. And the steps to mount an encrypted volume can be eliminated (TrueCrypt would not be needed) and the process used with only RoboCopy to make an unsecure (unencrypted) backup - automatically.

Comments anyone?

OK, that CMD file has been tested all the way through now and can, I believe, be safely used. I ran a series of comparisons on the results (MD5SUM) just to check as much as possible and they appear to be properly identical.

It takes HOURS to run the first time if you have a lot to back up, but not a huge difference compared to the non-encryption alternatives with the PP1 shares function and the BDBB Add-In. (This is with 2GB RAM and LE-1640 CPU.) When run a second time it is MUCH faster, especially for backing up the backups (which are all in a single folder). For the shares it needs to navigate its way through all your sub-folder tree structures; that takes a while even if nothing has changed. But even that is a heck of a lot faster than when it needs to store new files!

After the holidays it is my intention to write this up a bit more formally, specifically separating the backup portions from the encryption parts. In the meantime if anyone wants to try it out I would appreciate any feedback you might have.

This is great stuff. Everybody should be doing just what you do, so please keep us posted.

I want to let it run through a couple more scheduled updates and then intend to post a revised set of CMD files. For anyone playing with it at this point I will state that the "meat" of the CMD files has NOT changed at all, only some comments, organization and "glue".

Some questions and comments that are more security-related than MSS-related, but...

• You focused a lot of time and attention on your backups, yet as far as I can tell, the MSS itself still has unencrypted disks? Are you storing the backups offsite, etc. so they have a higher threat profile?
• The fact that the password is stored in cleartext on an unencrypted disk makes me nervous. Have you considered leveraging Truecrypt's ability to use keyfiles for authentication, either as single-factor or two-factor when combined with a password? I haven't tested it, but it seems like a USB key plugged into the back of your MSS with a keyfile would give you an easier way of protecting the means of accessing the truecrypt volume -- just yank the key and you're safe(r).
• I'll admit up front that I'm too chicken to try this on my MSS, but if you were really brave and had one of them fancy MSS VGA/PS2 cables so you could use a keyboard and monitor, you could also leverage Truecrypt's system encryption capabilities to protect the MSS itself. That would allow you to protect your live data as well as your backup data. And, I believe you could even use the same keyfile authentication mechanism so you didn't have to enter a password every time the MSS re-booted.

Anyway, not trying to poke holes -- I just think it's cool what you've done with truecrypt already and it got me thinking about where else it could be taken in the event of extreme paranoia.

--kurt

* You focused a lot of time and attention on your backups, yet as far as I can tell, the MSS itself still has unencrypted disks? Are you storing the backups offsite, etc. so they have a higher threat profile?

Yes. At the moment in a Safe deposit box (which is probably safer than the house) but that is a lot of space and a PITA to visit regularly. When encrypted I can just swap with a neighbor or keep in the car!

* The fact that the password is stored in cleartext on an unencrypted disk makes me nervous. Have you considered leveraging Truecrypt's ability to use keyfiles for authentication, either as single-factor or two-factor when combined with a password? I haven't tested it, but it seems like a USB key plugged into the back of your MSS with a keyfile would give you an easier way of protecting the means of accessing the truecrypt volume -- just yank the key and you're safe(r).

For an off-site backup disk this is really not necessary as the key is never off-site with the backup. Remember, if anyone can get the key they can get to the server and get to the data in the clear anyway. IF I can get this to encrypt the entire storage pool the equation will change radically and the key will have to be separate. A flash key is one alternative. A fingerprint reader may be another! I actually programmed this at one point to prompt for the password, which was great when I ran it manually but, obviously, did not work so well when the process was scheduled/automated!

* I'll admit up front that I'm too chicken to try this on my MSS, but if you were really brave and had one of them fancy MSS VGA/PS2 cables so you could use a keyboard and monitor, you could also leverage Truecrypt's system encryption capabilities to protect the MSS itself. That would allow you to protect your live data as well as your backup data. And, I believe you could even use the same keyfile authentication mechanism so you didn't have to enter a password every time the MSS re-booted.

Unfortunately the full-pool encryption attempts have NOT (yet) proven to be very feasible. Part of the problem is that the entire pool needs to be prepared in advance. Cumbersome but doable in a single disk system but it falls apart when you want/need to add a drive. The entire pool needs to be emptied, recreated and reloaded. I am not willing to loose the inherent WHS flexibility to accomplish that so this is very much on a back burner until I think of something else. And if a single drive fails in that scenario the replacement methodology becomes extremely non-trivial. To date I have not attempted anything that would require the KVM capabilities and, frankly, I am not sure I would want to make any bios changes at this level or have to use KVM at each startup. I am avoiding that.

For the moment I think I will concentrate on automating those MSS/WHS backups and the encryption for off-site storage. Unless someone triggers a thought that will get us around some of those problems...!

-----

I do appreciate the discussion though!

Question for the experts: is an encrypted volume more prone to data error/failure than a non-encrypted one? I remember back in the days when I was using PGP disk that I sometime had data failures which meant doom for all my data in the disk. Even a small error in the file would mean total destruction for the whole disk.

I know that there is a repair feature in Truecrypt but have never used it. Have you guys ever had to apply that?

Also, do you format your encrypted volumes using FAT or NTFS? I prefer NTFS for obvious reasons but Truecrypt discourages that for an outer volume of a dual (outer/hidden) volume. Isn't FAT more prone to data corruption?

I would hate to lose my MSS data because it is encrypted. By definition it's encrypted because it's important. Thanks,

Is an encrypted volume more prone to data error/failure than a non-encrypted one?

Good question! I do not have an answer and, so far, there do not seem to be a lot of folks around here experimenting with this so we need to ask somewhere else! I think the risk is minor, and the risk of that happening when I REALLY need an off-site disk to recover is even more remote. I am OK with the odds. But...

Do you format your encrypted volumes using FAT or NTFS?

I have been using NTFS. Been a few weeks since I read about it but as I recall it was because with NTFS it is possible to determine a disk contains data and the documentation (subtly) implies better to not know if the disk has data or has just been wipped so as to have "deniability" in the event you are coerced to reveal the password. If it is THAT important to a thif I would give up the password! (Had enough of that spook crap in a prior life!) If there was some other reason I have forgotten it at this point.

I would hate to lose my MSS data because it is encrypted. By definition it's encrypted because it's important.

Remember, you can always skip the encryption steps! Or you can do one of each! To me it is a trade-off between storing that backup disk in a bank vault or at a less secure location with encryption. Heck, I may rotate an unencrypted copy to the bank vault every few months and the other weekly.

In my experience, no. It's a lot more complicated to recover the data since you have to have a solid key management and recovery process in place, but I don't think the data are any more error/failure prone.


I think you're referring to their recovery feature, which is only necessary if you forget your passphrase and/or keyfile. It's there to protect you.


I always use NTFS, though it's more because FAT volumes don't support file permissions than anything to do with encryption. I wasn't aware that Truecrypt discouraged NTFS, but the hidden volume feature of Truecrypt isn't something I've spent a lot of time exploring. I don't care if people know I have an encrypted volume as long as it's encrypted.

Some more info on data corruption from TrueCrypt FAQs:

Q: What will happen when a part of a TrueCrypt volume becomes corrupted?

A: In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?


Q: What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?

A: File system within a TrueCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. TrueCrypt provides an easy way to use this tool on a TrueCrypt volume: First, make a backup copy of the TrueCrypt volume (because the 'chkdsk' tool might damage the filesystem even more) and then mount it. Right-click the mounted volume in the main TrueCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.

Hello,

So please let me add my contribution to this tremendously intersting topic.
First of all, thank you for you idea and you firsts tests. As a Homeserver user (who said addict ?), and concerned in security, I'm looking as well for a way to encrypt those drives, easily, seamlessly and if possible beeing able to keep all those fine features we have in WHS.
I think this would be nice to have a solution around this. Maybe just based on windows user rights. I tried just a few days ago with EFS, but it seems to be disabled by the shadow copy feature from WHS.
As well, I'm not sure it can help, but I implemented Bitlocker on my pro Lenovo laptop with onboard TPM, and it's pretty fast and well designed. Basically it encrypts the drives, and that's a good point, for an encryption solution, but the good thing is that you have the choice between one, two or three authentications schemes (TPM, PIN, USB stick with some signature file on it), that provide you the ability to adapt I think all the needs you could require.

For WHS, I think that it would be nice to have solution for bypassig the problem of the boot without vga screen (I have an Acer H340), so maybe something based on an usb stick you put in it at boot time, like a car key, but that you can remove and hide somewhere when it's running. would be great.

Anyway, I will try to make a few tests with using you truecrypt solution and give you my feedback ASAP. Maybe I will try as well with other solutions since I have a few of my friends working for McAfee / Safeboot.

Regards,
Mmz06

First, mmz06, welcome to the world of WHS/MSS and, especially, to any discussions of encryption! Great to have you aboard!

The TrueCrypt solution can work for a normal client. There are (at least) two problems with a headless WHS server:

(1) the need to enter the password on power-on or restart -- without a keyboard!!!

(2) the handling on MULTIPLE drives by DE where each one is in a common pool. But each physical drive has a password. And you cannot format the entire pool at once.

I have been unable to find ways around either of those problems.

------

TrueCrypt works EXTREMELY well for un-managed (non-data, non-backup) drives that are a target for backups. Easily automated and very little impact on WHS performance.

John,
Many thanks for your work on this. I'm setting up a WHS and testing it. Two questions. On a small WHS system I have a total of 140Gigs of storage, 70 of which is free, When I run the robocopy backup script, the databases alone have exploded out to more than 100Gigs. Am I missing something here? Also for restores in the event of disaster recovery. Is the robocopy process just reversed for destinations?

I'm presuming the process would be:

Reinstall server
Recreate shares (or would that be necessary)
Recreate the users
Edit a copy of the automatic.bat file and run it.

Here is what I came up with for a server restore file

REM Stop the Drive Letter Service
NET STOP PDL

REM Stop the Backup Service
NET STOP WHSBackup

REM Select one copy method OR the other below.

REM ROBOCopy the "backup" folder in Mirror Mode, Restartable, All attributes, No progress, 4 retries, 5 second wait between retries, Log to file, Console output
Robocopy e:\backups\{00008086-058D-4C89-AB57-A7F909A47AB4} D:\folders\{00008086-058D-4C89-AB57-A7F909A47AB4} /MIR /Z /COPYALL /NP /R:4 /W:5 /LOG:"D:\shares\Software\LogFiles\External-Backups.log" /TEE

REM Start the Backup Service
NET START WHSBackup

REM Start the Drive Letter Service
NET START PDL

REM Copy the “shares” folder in Mirror Mode, Restartable, All attributes, No progress, 4 retries, 5 second wait between retries, Log to file, Console output
Robocopy e:\backups D:\Shares /MIR /Z /COPYALL /NP /R:4 /W:5 /LOG:"D:\shares\Software\LogFiles\External-Shares.log" /TEE

Let me know what you think.

thank much
Michael

I dont know how difficult it would be for someone who does not work for the government to get a CAC card with valid certificates and a reader.
Me being in the military had the chance to get a CAC card reader with the program for free.
I have installed the software on all my computers and set them up so the only way to login is with a CAC card.
I have not try it in the server but i am thinking it should work. All my computer are encrypted so the back up are as well.
This make me fell safer than having a safety deposit box.
For those of you with privacy concerns might want to look into it. You might have to buy the hardware and software but its an small price to pay compared to having someone looking into your files. Just a thought.