How To, When You Have To Encrypt Absolutely Everything? 468
Dark Neuron writes "My institution has thousands of computers, and is looking at starting an IT policy to encrypt everything, all hard drives, including desktops, laptops, external hard drives, USB flash drives, etc. I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives, but I am concerned about overhead and speed penalties. Does anyone have experience and/or advice with encrypting every single device in a similar situation?"
TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...
I think you're going to find most people advising you to choose TrueCrypt [truecrypt.org] which boasts:
I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking [truecrypt.org] the various encryption algorithms it offers.
... but i am concerned about overhead and speed penalties.
Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option [slashdot.org] which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.
... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.
I wouldn't recommend waiting that long, however.
Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.
I do not know for certain but I do not believe there is a painless push-across-the-network way to do this
Pointsec (Score:2, Informative)
don't encrypt system files (Score:2, Informative)
TrueCrypt and Mac (Score:4, Informative)
TrueCrypt does not support Pre-boot full disk encryption on the Mac. Only product I know of that does that right now is PGP Whole disk (latest version).
Re:Yeah... (Score:5, Informative)
They probably have to (Score:3, Informative)
Truecrypt, your our only hope (Score:2, Informative)
I was screaming PGP until I got to the Open source part, removing funding from the equation Truecrypt is the only thing that will really do what your asking for. Its not bad & I like it, but its not PGP. And if you have been using something since the BBS days, your really not likely to change now so I am bias towards it. But from my limited (3 month) run with Truecrypt I had no problems and it was very stable, and little to no real performance difference from PGP's.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
Yes, and as the OP was asking for "real-life" benchmarks, here they are. Tom's Hardware benchmarked TrueCrypt thoroughly and found practically no overhead.
http://www.tomshardware.com/reviews/truecrypt-security-hdd,2125.html [tomshardware.com]
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
You can encrypt your key with a password (I'm sure truecrypt supports this) but then you might as well just have used a password in the first place instead of encryption.
WTF? If someone steals a computer and puts a drive in another computer the windows/BIOS password won't do shit, encryption will.
What you do is store sensitive material on secure servers and have people check out copies of material that they have access to. I'm sure keeping sensitive data off local hard drives would be easier than actually protecting all those hard drives.
No it won't. If they need to use the data then it will be cached on their computer whether it is stored centrally or not. And if they weren't using the data then it wouldn't have been on the computer to begin with. Centralization will only help if you move from thick-client to a thin-client-like processing of data. That will limit the amount of distribution of sensitive manner - "checking data out" won't.
Fedora (Score:1, Informative)
I've been using Fedora since v8. Fedora 9 introduced the ability to encrypt the entire hard drive. I have a least three servers (Apache, Tomcat, and MySQL) running on my encrypted hard drive and the speed in incredible. Absolutely no issues with speed or problems with start-up or shut-down. Setup is as easy as checking a check box during the install. And logging in just requires a password during the Grub boot cycle to unlock the encrypted hard drive.
Description from Fedora: /boot using cryptsetup and LUKS. This includes install time creation/configuration, as well as integrated support in mkinitrd and initscripts (others?). Currently we are only pursuing support for encrypted devices using cryptsetup/LUKS."
"Support the use of encrypted filesystems for anything other than
Further Reading:
http://magazine.redhat.com/2007/01/18/disk-encryption-in-fedora-past-present-and-future/
http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems
by Anonymous Coward
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
I'm not so sure about that. The deal with whole disk encryption is that it's fail-safe; it doesn't matter if something bad happens, the data is stored in a secure state by default. A check-out model doesn't give you that.
Also, speaking from experience, it's incredibly difficult to get end users to even understand what sensitive data is, much less train them how to work with it in a secure manner. Any security model that relies upon educated (and diligent) users is probably going to fail sooner rather than later.
Re:Yeah... (Score:5, Informative)
I can't tell, are you joking? With all the sarcasm around Slashdot it's sometimes difficult to tell if someone is being snarky.
The scenario you mention wouldn't happen unless a half-baked encryption scheme was used. HP, RSA, IBM, and even Truecrypt all have recovery options ranging in levels of difficulty to implement. RSA's key management tools are quite handy but you definitely pay a premium for them. HP's are clunky like all HP software, IBM has been doing it for years but again you pay and arm and a leg.
With Truecrypt you create two to three thumbdrives when you do the initial encryption, two of them store the master encryption key and the third has whatever key is needed for authentication depending on how you want to deploy it. The only fault I have with Truecrypt is that there are a dozen ways to deploy it so you have to read and plan very carefully before deploying it on any level.
Once you have your flash disk you copy its contents to an encrypted folder on your SAN somewhere and keep the flash drive in a properly fire-proof safe. One flash drive has the keys for over a hundred machines with room for plenty more, keeping two copies ensures that a flash drive dying won't leave your data inaccessible during transport to the server and should the SAN experience some sort of data loss you can go back to the flash drive to recover keys.
Encryption is pretty scary as your keys are extremely important as you mention, once the key is lost then so is the data. So you take a few precautions ahead of time and then you don't need to worry.
Re:User Error (Score:3, Informative)
Any sufficiently enterprisey encryption system would have a site-wide "master key" entrusted to whatever IT staff is responsible for rescuing people from forgetting their key.
TrueCrypt is very fast (Score:4, Informative)
Re:TrueCrypt or Wait for On Drive Upgrades (Score:4, Informative)
We use truecrypt for full drive encryption. So far we have encrypted well over 100 notebooks without issue. The full drive encryption has very little overhead and besides a password at start up most users don't even notice.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
If the pagefile is located on the encrypted volume, not much harm, might make cryptanalysis easier if someone can get two images of your drive at different times.
If the pagefile is not on the encrypted volume, then it is leaving chunks of no-longer-secure data for anyone to see.
You're still missing the point. (Score:5, Informative)
Hard drive encryption isn't meant to protect against social engineering attacks. It's meant to protect against attacks that don't require social engineering, like stealing or cloning a database server's drives for the information. More than anything, it's meant to provide reasonable assurance that if one of your employees' computers gets stolen by a common thief who just wants to sell it for the cash value, somebody else down the line won't be able to read the data in the drive and take advantage of it.
no choice in Calif for gov funded agencies (Score:2, Informative)
Encryption and a whole host of other requirements are now the law in California for any non-profit, local gov or other agency using state funds and that has any personal data anywhere on their systems. This could be something as innocent as the address block in a letter you typed to one person, does not have to mean the "database."
http://www.documents.dgs.ca.gov/osp/sam/mmemos/MM08_11.pdf [ca.gov]
Re:TrueCrypt or Wait for On Drive Upgrades (Score:3, Informative)
TrueCrypt can't do full-drive encryption on OS X.
You have to go commercial for that.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
A simple perusal of their website reveals:
Q: We use TrueCrypt in a corporate/enterprise environment. Is there a way for an administrator to reset a volume password or pre-boot authentication password when a user forgets it (or loses a keyfile)?
A: Yes. Note that there is no "back door" implemented in TrueCrypt. However, there is a way to "reset" volume passwords/keyfiles and pre-boot authentication passwords. After you create a volume, back up its header to a file (select Tools -> Backup Volume Header) before you allow a non-admin user to use the volume. Note that the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. Then ask the user to choose a password, and set it for him/her (Volumes -> Change Volume Password); or generate a user keyfile for him/her. Then you can allow the user to use the volume and to change the password/keyfiles without your assistance/permission. In case he/she forgets his/her password or loses his/her keyfile, you can "reset" the volume password/keyfiles to your original admin password/keyfiles by restoring the volume header from the backup file (Tools -> Restore Volume Header).
Similarly, you can reset a pre-boot authentication password. To create a backup of the master key data (that will be stored on a TrueCrypt Rescue Disk and encrypted with your administrator password), select 'System' > 'Create Rescue Disk'. To set a user pre-boot authentication password, select 'System' > 'Change Password'. To restore your administrator password, boot the TrueCrypt Rescue Disk, select 'Repair Options' > 'Restore key data' and enter your administrator password. /noisocheck).
Note: It is not required to burn each TrueCrypt Rescue Disk ISO image to a CD/DVD. You can maintain a central repository of ISO images for all workstations (rather than a repository of CDs/DVDs). For more information see the section Command Line Usage (option
Seriously, a little research isn't hard.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:3, Informative)
We wrote our own tool for storing passwords and the recovery isos. Our users are not administrators so they can't change the passwords on their own.
It made it all very easy to deal with.
Re:Theory vs. Reality - Seriously (Score:3, Informative)
The point of the comic is that there's no *practical* difference between, say, 128-bit encryption and 4096-bit encryption because it is, and always will be, easier to just obtain the password somehow than to crack the encryption.
Meanwhile, crypto-nerds go around scoffing at your primitive WPA wifi encryption and go on to introduce 47 new layers of encryption, all bigger and better than the last, wasting tons of time and money in the process.
That message still applies, despite everything in your post.
Re:Theory vs. Reality - Seriously (Score:5, Informative)
There's a huge difference. When you see numbers like "128-bit," you're dealing with a symmetric encryption algorithm (e.g., AES). When you see numbers like "4096-bit," you're dealing with an asymmetric algorithm (e.g., RSA).
See the NIST Recommendation for Key Management (PDF) [nist.gov], page 63. For example, to get RSA that is "equivalently" secure (for some predicted meaning of equivalent) to AES-128, you need a 3072-bit key. The table is explained on page 62.
As an aside, the comparably small key sizes that asymmetric elliptic curve cryptograph (ECC) can use, illustrated on page 63, are one of the reasons that ECC is so valuable.
Re:TrueCrypt (Score:5, Informative)
Nobody deals with that, for the moment. I don't think the hardware solutions deal with that for every case, either.
I've heard of some possible solutions being thrown out there - including a CPU "disabled cache"-type software solutions - but there's nothing being sold yet.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:1, Informative)
Did you try disabling AHCI in your BIOS first? This would require a reinstall of windows regardless but it will allow truecrypt to function properly.
(Sadly) TrueCrypt is not what you want (Score:2, Informative)
As much as I like TrueCrypt, it is not what you want to be using when you have thousands of computers.
TrueCrypt has no way to remotely install or manage its self. It means taking a trip to each and every computer you own and installing it by hand.
Sadly one of the commercial solutions in this case will save many a headache.
Something like Checkpoints Pointsec (or what ever they are calling it this month) or PGP WDE for your computers and give everyone IronKeys which can be centrally managed (Pointsec will also encrypt USB keys as well as allow you to control what USB devices are plugged in).
And no I'm not a Checkpoint shill...
Re:Yeah... (Score:3, Informative)
There is still a password to use the flash key. You would never expect an end-user to end a 1024bit key themselves after-all. It's not near as bad as you make it out to be especially since there are multiple authentication techniques which you can perform.
You are correct in that there are a lot of logistics that have to get worked out before such a system can be deployed. Probably why I've spent a year testing different scenarios and how to handle recovery. I'm finally looking at deploying it company wide even though I'm moving towards virtual desktops anyways which are more about strong authentication beside strong encryption.
Go with Full disk encryption on the computers only (Score:1, Informative)
Personally, I would recommend going with a full disk encryption methodology utilizing something similar to Utimaco. This provides a challenge/response feature that will enable you (the IT support staff) to decrypt the drive in a situation that would require you to do so (e.g. an employee departs the company, file system corruption, etc).
As for the external drives, my personal stance on this is that you establish a policy surrounding such devices that would not allow them to store any sensitive data on them. If necessary, you can of course create encrypted volumes with TrueCrypt, Utimaco or something similar; but doing so (as has been stated) is risky if they forget the password to it.
Fingerprints are even easier that removing fingers (Score:3, Informative)
eyeballs and fingers aren't that hard to remove
Fingerprints are even easier:
- Get a print on something.
- "Develop" it to get a computer image of the print.
- Fabricate a fake finger from the image any of several ways.
One example:
- Etch it into a printed circuit board (using a printer and a Radio Shack grade PC board etching kit.)
- Cast a fake fingertip on the printed circuit. (Gelatin works for a few-shot prosthetic fingerpint. I think silicon caulk works too if you first lightly oil the PC board to keep it from sticking. Etc.)
Should be similarly easy to make a fake for a retinal scanner from a retinal scan, which is strictly an optic device. (I'd start with a disposable camera for the holder.) Ditto iris scan.
SafeGaurd Easy (Score:1, Informative)
This is the encryption system we settled on for our corporation. It has a network deployment, network configuration, it also encrypts the disk while the user is using it, so it takes a day or two as it encrypts in the background and the user can shut off their computer and then it will pick up where they left off.
Looked at Truecrypt yeah but like several others have mentioned really we find a lot of the open sourced really not very well supported. And what I mean by that is you got a system down you can either go to a forum or send an email and someone may get back with you, then again may not. Safeguard easy has fully staffed help desk and support center. All of our installations except 1 went smooth and that one just wouldn't run the encryption utility from the network. Instead it had to manually be started. I would suspect some user interference from that like blocking ports or something.
Now I will say we used this for all laptops and desktops and removable drives but not servers. No real need when servers are in data center, if someone were to steal the hard drives from there we got bigger issues. Be forewarned though doing this on a removable drive like a USB drive for example basically renders that drive useless for any computer but the one it was encryption on and others on your network. You can't for example take it home plug it into your home computer and expect it to work. And Why because when you manage encryption centrally you typically have a central key for your corporation so you do not wan to give that key out to everyone so they can take it home.
Also there is no noticeable performance decrease, even from me as a developer running 2 virtual machines off my hard drive at the same time. I use a standard laptop we give to everyone else which is a Dell Latitude with 2 gigs ram and intel core 2 duo, running XP though not Vista.
There was slight performance decrease when the drive was encrypting because it was going like mad however that was only for a day, would have been 2 but I took my laptop home turned it on and let it just churn overnight.
Anyway my 2 cents
"Concerned about overhead and speed penalties" (Score:3, Informative)
We don't use an open source product except TruCrypt on some of my own portable HDD's. I am pushing that more so we don't have to buy licenses for every piece of hardware. Automation (see below) is a step in that direction. My experiences may still help.
First where I do use TruCrypt I set up a batch file that opens a simple prompt so the user just enters a password and the drive becomes accessible. The batch file and the TrueCrypt executable both reside on a small unencrypted partition on the drive in question with an autorun.inf file pointing to the batch file. To automatically mount any encrypted volume it sees on the disk you just inserted it goes something like this:
TrueCrypt\TrueCrypt
Second we use Encryption Plus Hard Disk for our laptops. PC's are not encrypted we invested in a controlled access security system instead of purchasing licenses for all PC's although unlike other
Like TrueCrypt our software loads a driver that encrypts and decrypts everything written to the HDD. As you probably know computers aren't always writing to the HDD. So the idea that you'll take a huge performance hit is kind of a misnomer. We have laptops that range from Pentium III's to the latest cpu's. If the laptop is excruciatingly slow to begin with then encrypting the HDD will only make it slightly more excruciating. If the cpu is more current then the user will not notice the difference.
Yes people loose passwords and forget the challenge questions. Unfortunately here we don't have a good procedure in place to reset them remotely. We have them bring them in and we enter the admin password. Even if the HDD crashes we can pop in the decryption CD and get their data about 50% of the time. Which is not all that far off from the recovery achieved from our unencrypted PC's after HDD crashes.
In conclusion having imaged and encrypted hundreds of PC's I would say unless you choose the wrong algorithm don't worry to much about performance issues. The most basic algorithms will stop 99% of common thief's from getting at your data. Of course if your worried about the uncommon ones you may have to weigh protection verses performance.
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
The post you reply to is written by a numbskull. Compiling software doesn't even begin to ensure that all possible memory locations accessed and bit values are written. The vast majority of what is going on during a compile and/or md5 sum is going to happen in the processor's L1 & L2 caches.
On the other hand memtest86(+) has a methodology that includes disabling cache and ensures that all possible locations are written to and read from. Additionally there is a mixture of patterns used, from random patterns for general testing to specific patterns (both bit value & access ordering) for exercising known failure modes of DRAM.
Finally the idea that you can "stress" you RAM is nuts. Outside of running the device out of spec (e.g. overclocking), the only "stress" possible is heat and just being on will get it into the normal operating temperatures. Anything else is what it's designed to do, there is no ubermagic access pattern driven by that "well known" gcc that causes DRAM to fall over dead.
Disk encryption, is easy and well worth it. (Score:3, Informative)
Re:TrueCrypt or Wait for On Drive Upgrades (Score:3, Informative)
Believe or not that method has a name.
Its called "rubber hose cryptanalysis": http://en.wikipedia.org/wiki/Rubber_hose_cryptanalysis [wikipedia.org]
Re:Not truecrypt, compusec (Score:3, Informative)
I've used both truecrypt and compusec, and for a corporate environment only compusec is acceptable. Truecrypt does not provide a master password you can use to quickly reset a password when the user forgets.
That's not true. Restoring access to a container or partition with a forgotten password is quite easy if you do one extra step when creating the container. From their FAQ:
Q: We use TrueCrypt in a corporate/enterprise environment. Is there a way for an administrator to reset a volume password or pre-boot authentication password when a user forgets it (or loses a keyfile)?
A: Yes. Note that there is no "back door" implemented in TrueCrypt. However, there is a way to "reset" volume passwords/keyfiles and pre-boot authentication passwords. After you create a volume, back up its header to a file (select Tools -> Backup Volume Header) before you allow a non-admin user to use the volume. Note that the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. Then ask the user to choose a password, and set it for him/her (Volumes -> Change Volume Password); or generate a user keyfile for him/her. Then you can allow the user to use the volume and to change the password/keyfiles without your assistance/permission. In case he/she forgets his/her password or loses his/her keyfile, you can "reset" the volume password/keyfiles to your original admin password/keyfiles by restoring the volume header from the backup file (Tools -> Restore Volume Header).
Similarly, you can reset a pre-boot authentication password. To create a backup of the master key data (that will be stored on a TrueCrypt Rescue Disk and encrypted with your administrator password), select 'System' > 'Create Rescue Disk'. To set a user pre-boot authentication password, select 'System' > 'Change Password'. To restore your administrator password, boot the TrueCrypt Rescue Disk, select 'Repair Options' > 'Restore key data' and enter your administrator password. /noisocheck).
Note: It is not required to burn each TrueCrypt Rescue Disk ISO image to a CD/DVD. You can maintain a central repository of ISO images for all workstations (rather than a repository of CDs/DVDs). For more information see the section Command Line Usage (option
The actual FAQ has many of those terms linked to other help files for more info: http://www.truecrypt.org/faq.php [truecrypt.org]
They don't mention it explicitly, but this process does not require any computation/decryption on the actual data. It will be very fast to execute no matter how large the container is.
Re:TrueCrypt (Score:5, Informative)
TrueCrypt has several options. The way I have it configured, the TC volume is automatically unmounted when I suspend, and I need to re-mount it when the notebook wakes back.
I understand the password is not in RAM anymore after a suspend. These are the options I use:
"SaveVolumeHistory" = 0
"CachePasswords" = 0
"WipePasswordCacheOnExit" = 1
"WipeCacheOnAutoDismount" = 1
"StartOnLogon" = 0
"MountDevicesOnLogon" = 0
"MountFavoritesOnLogon" = 0
"DismountOnLogOff" = 1
"DismountOnPowerSaving" = 1
"DismountOnScreenSaver" = 0
"ForceAutoDismount" = 1
Re:TrueCrypt (Score:2, Informative)
A Crypto nerd's imagination
Person1: His laptop's encrypted. Let's build a million dollar cluster to crack it
Person2: No Good! Its 4096 bit RSA!
Person1: Blast! Our evil plan is foiled!
What would actually happen:
Person1: His Laptop's encrypted. Drug him and hit him with this $5 wrench until he tells us the password
Person2: Got it
Source: http://xkcd.com/538/ [xkcd.com]
Re:TrueCrypt (Score:4, Informative)
You are misunderstanding the problem. Defending data in a datacenter is a completely different problem that data-at-rest encryption really doesn't help you with.
In most states, whenever a client computer could contain personally-identifying data, data breaches must be exposed to any potential victim and the general public.
In some cases, that includes things like browser caches, and other temporary files. So most financial institutions and government agencies opt to encrypt all mobile devices. Some law enforcement agencies encrypt desktop computers as well.
Encryption is very easy to do. Key management is hard. Truecrypt is great for an individual user, but falls down when you have to manage a non-trivial number of clients.
Re:TrueCrypt (Score:3, Informative)
He means overwrite the keys in memory, not trash the hard drive. So that a reboot will be necessary, which will then prompt for the password. It really should be done.
Truecrypt can dismount regular drives on screensaver launch. I don't think it can dismount the system drive though.