Slashdot Mirror
What's Missing From File / Disk Encryption?
lockDrive asks: "Every month, we read a news about personal information leak. Most of the time, either a laptop or a hard disk that contains sensitive information is stolen from a government or corporate office, and the data are not encrypted. Recently, Department of Veterans Affairs had lost a laptop which contained confidential information for 26.5 million veterans. The data were not encrypted. There are many products that provide a solution to such a problem. Microsoft Encrypting File System (EFS), which comes with Windows 2000 and later, encrypts data in a file system and seems to have a decent key recovery system in Windows 2003 Server CA. Products like SecureDoc and DriveCrypt encrypt an entire disk. I have tried some of them and they are not that difficult to use. What is holding people who handle sensitive information (government, health-care, insurance ...) back from encrypting their data? Are the products still too hard to use? Are they concerned about performance loss? Are they not convinced with the security gain? Are they just not adopting the technology quickly? Is there anything missing in the technology?"
Time is what is needed. :-D
it will slow people down. maybe long enough to recover the data or somehow make it less useful (change ids, passwords, etc). even good encryption will eventually fail. the best you can do is to make it difficult.
on a positive note, someone suddenly looking for breaking tools might catch some attention. on a negative note, something encrypted tends to be a big red flag that says 'look at me, i was important enough to protect'.
and one final thought: it you look at the care and attention that people pay to to security, it would not surprise me if most encrypted systems would be compromised by user stupidity (social engineering).
eric
I've been looking for an encrypted hard drive controller- something that looks to the OS like a normal disk but every single byte written to the disk is encrypted. The moment the power is pulled the key is lost and needs to re-entered when the system reboots. It would look like a disk error but when the "Non-system or disk error" message comes up you enter the key and the system boots normally.
I would prefer there not be any chance of the OS leaving around un-encrypted information on the swap partition or hacing a back door or any other stupidity. I've seen encrypted controllers but only with 40 bit keys. I'd love to see something with an AES 256 bit key. If nothing is out there I may just have to put together something using an FPGA.
-sirket
Can you stick the drive in any PC running the same OS, supply your password, and get the data? If not, there's one less step before you get stuck trying to read crufty old backup tapes/CDs/etc.
I think you missed the real cause -- the IWNHTM Syndrome.
It Will NeverHappen To Me
The Overrated mod is for reversing inappropriate, positive mods, not for voicing disagreement with a post.
It's not a technological problem -- everyone in Windows & Linux land should be using Truecrypt or something similar and being smart about how they handle data. Rather it's a social problem.
Without written security policies, nobody knows what they should/can/must not do, and even if they do, they follow the rules inconsistently.
Take a look at Cisco's SAFE, for example. It explicitly says
If you don't know what you have, who gets to access it, and when, what good is a bunch of hardware and software? You might as well hand all your workers CDs of your databases and cross your fingers. Which, possibly, actually happens in some of these cases. Sadly, this sort of stuff is Day 1 material for CCNA and MCSE and other certifications these days, so it pretty much looks like whoever is running the show in these places can't follow or doesn't know standard industry practices. That's gross negligence, IMO, and nothing to do with any sort of technical failings.
Education is missing. The software is fine, and cryptographically signing and encrypting can be set up so users don't need to enter their passwords when sending every email, etc.
When I explain to people that sending an email over the internet is akin to sending a postcard to someone, only less secure, they're horrified and don't know what they can do about it.
Educate the users, explain that their information is WORTH something, regardless of what it is, and that people WILL collect that information if it's available.
For example, Department A installs an encrypted file-system for a CRM database; Department B, who work with a portion of that data, allow for offline backups onto their users unprotected laptops, inevitably, one of the laptops is lost or stolen, and someone finds unencrypted data all over it.
The only possible solution to this is a really pervasive security policy that extends to all employees, contractors, users, clients etc., and that is what's really missing from this puzzle.
How about corrupted data recovery? Say I have a document, and 15 bytes are damaged and unrecoverable. No problem, I still want it because it's important. If it's unencrypted, that is unproblematic. Whatever those 15 bytes were is damaged and I'll have to fix, the rest of it is there. What about the encryption? Can it handle decrypting partially damaged files, or will it fail?
We need an act to mandate a functional backdoor so that authorized government agencies can access classified data to fight terrorism more effectively.
Powered by caffeine and sugar; BSD
what they don't realise, until it hits them is that their systems are hooked to the net, can go for service/repair or otherwise be exposed to external agents.
how many /.er's encrypt *all* their data on their HDDs? not many i presume. heck, even secrecy scared corporates and intelligence agencies don't do that.
* lon3st4r *
I would love to a see a distro, like ubunto, that would ask me if I wanted to create a small boot parition, and a larger *encrypted* primary parition, which would then install to the encrypted partiton, and finally give me the chance to burn a CD from which to boot (or USB stick if my system supported that, etc.). Then, on boot (either from the HD small boot part, or a read-only CD), I'd enter my password to access the root partition. As it stands, getting this done requires some expertise, too much time for most of us, and lot manipulating of files, partitions, etc.. Make it easy!
Common sense and rigour.
I don't care if your algorithm never exposes a weakness for ten thousand years and your messages are supposedly secret for ten billion. If you keep throwing your scratchpad in the wastebasket and leaving it there, for example, then I'll probably figure out your plaintext.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
Defaults are missing. Why would you -not- make it a standard system feature and turn it on by default? If you do that, then you need much less in the way of education... basically just educate the user to use a strong password, and you're done.
... the damn thing is still off by default.
IMO the combination of two Mac OS X features, FileVault + Secure VM, comes closest to doing things absolutely right. It's trivial to enable. There can be a global rescue password set up by an IT department. You can use long passwords that are harder to crack. Only the user's data is encrypted, not the OS files (which generally don't need to be). VM swap is automatically encrypted with no password needed. Heck, there's even a password checker dialog that shows the strength of your password every time you create a new one.
And yet
It's almost like someone paid a lot of attention to building the most secure house in the world with shatterproof glass, burglar alarms everywhere, bulletproof walls that can stop an armor-piercing shell, and so on. But when you buy it the front door doesn't come with a lock.
The first answer to the "why not?" question is, of course, benchmarking. Many evils have been committed in the name of better benchmarks. Nobody wants to be the OS vendor or hardware vendor whose machines run 10% slower by default (or whatever) because they are more secure by default.
The second answer to the "why not?" question is probably "risk". I bet Apple has seriously considered turning on FV by default. And I bet the execs were afraid that it might be too immature. Given that I've seen some bugs in Secure VM on my x86 Mac, they might be correct in that assessment for now.
There's still the problem with bad employees copying things off on CDs, floppies, emailing sensitive stuff out, but as far as theft of PCs/laptops, we're covered.
For many years, offsite backups have been all about preservation of data integrity, not data privacy. After all, backups are not what's important... restores are what's important. If your offsite backup is encrypted and no one has the key after a disaster, your tape may as well be blank. Now we need to make sure offsite backups preserve privacy as well as integrity, and those are somewhat contradictory goals.
:-)
So encrypting offsite backups is a big step, and unless it's done right it can be seriously counterproductive. That said, it's also not that hard to do right... but it needs to be built into the company's disaster plan.
I recommend writing the disaster plan document to durable media, like a CD or a keychain drive. That media should include the keys to the backup media. (Possibly in an encrypted container like Password Safe, but of course then you need to make sure you distribute that key in a different way...) Make several copies of the disater plan media, and distribute them widely among trusted employees/officers/partners/board members. Then encrypt the backup tapes, and send them to a safe-deposit box or home with an employee who does not have a disaster plan key.
With this method, in the event of a theft you've either lost a key or a backup tape, but not both at once. Yet in the event of a disaster, if your backup tape and one key survive, you can get back in business. (Even better, but slightly dodgy legally, is to make the disaster plan media a portable hard drive containing images of all software install disks needed to get the backup restored onto a system.)
Of course, this is just one way to do it. But in order to encrypt those offsite tapes, something like this will need to be in place. If it's not, there's not much point in running backups.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
I'd just like to be able to store 'personal' or 'private' information on a 1GB encrypted flash drive.
One of the major reasons that has stopped me from using encryption, however, is the lack of compadibility for diffrent operating systems.
If I encrypt the drive using AES-256 on linux, I'm unable to read it on Windows. If I encrypt it with one of the Windows tools, I'm unable to read it on linux.
So I'm stuck between only being able to read my information at home on my linux machine, or only on public/windows computers.
Any organization handling truly sensitive data doesn't have the luxury of using third party key management. As soon as you have to manage keys, the difficulty of encrypting data goes way up. For these applications, a six letter password isn't going to cut it. Security has little to nothing to do with encrypting data. You can just as easily lock the data in a safe. If you encrypt the data and lock the key in a safe, what's the difference? There is none. People often equate encrypted with secure and this is rarely, rarely the case.
the hard part is keeping the key safe but easy to use. I don't want to have to type in a password every time I boot up, but I obviously don't want the key anywhere on the hard drive.
What I really want is the encryption keys to live on a USB device that I boot from, something just small enough to bootstrap the system and start decoding from the hard drive. Ideally, it'd be some sort of smart card, like the U3 jump drives. I'd like to put all of the private keys for my system on the jump drive, and have sshd get the session key from the smart U3 device, so my ssh private host key never leaves the USB device. It's applying the principle of least privilege to my PC - I'd just as soon never trust Windows with my private keys.
When I'm done with the computer in a few years, I just pull out the USB key and I know that the data on the drive is completely useless to anyone else.
I used to work for a therapist practice where all the therapists would do their notes on their laptop. Unfortunately, that mean HIPAA-regulated client data was floating all around on their laptops. Should one of them get stolen, there goes privacy information. The problem is, therapists, and barely computer-literate people in general, do not have the patience nor the technical inclination to encrypt their personal laptops. These are usually their personal computers as well, so we say that it's up to them to delete their files, just to put up a small barrier of protection, and that they shoulder the loss should anything get out.
Eventually we switched to storing notes on a central server so the only thing stored on their computer is in the browser cache, which we tell them to clear when they can. There's just no cost-effective, user-friendly way yet to do full-disk encryption.
Did you ever notice that *nix doesn't even cover Linux?
After reading some of the other comments in this thread, I'd add something that OSX does not have but other implementations do:
Open Format. The format that any persistent encrypted data is stored in needs to be open and documented, so that an authorized user can recover it readily from a different operating system. This becomes particularly important once it becomes obsolete tech. AFAIK the file format for FileVault is entirely undocumented, and that's bad news in the long run. (It's probably not super hard to reverse-engineer, but it should actually be documented for real and specifically unencumbered so that other people can use the same format.)
it will slow people down. maybe long enough to recover the data or somehow make it less useful (change ids, passwords, etc). even good encryption will eventually fail. the best you can do is to make it difficult.
, 000,000,000,000,000,000,000 years.
"slow people down- _MAYBE_ long enough?" If 2^191 years isn't long enough to change your passwords then the only possible reason is that you are dead.
Just the act of counting from 1 to 2^256 at a rate of 1 trillion keys per second would take approximately 2^191 years (3 x 10^57).
That's 3,000,000,000,000,000,000,000,000,000,000,000,000
Assuming you find the key about half way through the search (on average) that's still 2^190 years.
This is WAY longer than the universe has been in existence and probably longer than it will continue to exist in the future. That's just counting the keys. Actually testing them would probably slow your key rate down significantly.
The math as I see it:
1 trillion keys per second = 2^40
2^40 * 86,400 * 365 = 3.4 x 10^19 keys per year
- or 2^65 keys per year
2^256 keys / 2^65 keys per year = 2^191 years (256 - 65 = 191)
- or 3 x 10^57 years
I remember fooling around with encrypted partitions at some point, and I remember having a Windows glitch cause all my data to be lost - unlike when a few bad sectors could be manually worked around with various disk tools, if an encrypted file is "damaged", the whole thing is smoke - or at least it was back in 1998.
So, I think just the paranoia of having files being much more "destructible" has kept me from encrypting my hard drive on my laptop.
On the other hand, now I use OS X and Linux, and have multiple backups in multiple locations, so there is really no good reason why I don't use FileVault. Maybe I will..... but old habits born of bad experiences die hard.
I know I'm far from the norm here, but I don't use full disk encryption -- despite being a security-industry paranoid -- because it's simply unavailable to me.
Because I use a Mac. As do at least half of my laptop-wielding coworkers.
Once a stable solution exists, I will be all over it, but at this rate I'll likely have to write it myself.
We had someone at work talk about this...
http://www.truecrypt.org/
Its not a HW controler, but a mount the file system encrypted. It seems like a well thought idea anyway. And available for Linux.
The "problem" with encryption is not that it takes a few extra clicks, a little extra training and a more effort to work with third parties. Though, those are issues. To me, the real problem is that we're lazy and there is no benefit... at least until something bad happens.
I've recently been part of a outsourced payroll provider transition. As the IT guy for the customer end, I've been telling our folks to put a password on sensitive Excel* files (full of SIN's and other stuff like that) that get emailed to the payroll company. I initiated that, not the "professional" payroll firm... why don't they insist on it? Who knows? I would guess that it just causes too many questions and minor problems. As long as people don't screw up, there is no "need" for encryption. Simple as that.
* Yes, I know, default Excel encryption isn't that secure, but it's good enough to guard against mistyped email addresses, and it's hard to beat the simplicity and ubiquity. Good luck sending a TrueCrypt file to someone outside the company!
motherboard from abit
It is not as easy for a large organisation. But it is possible:
* It has to be seamless, because some people will always take short-cuts
* It has to be full-disk capable. Preferably flexible partitioning.
* Big organisations need to be able to centrally and remotely administer (in case you lose your password)
* It should be flexible, e.g multiple partitions, able to automatically change behaviour if you log into an unsecure hot-spot
* Finally, it should be hardware based, not software based. Software can always be compromised. If your information is that valuable, then someone will hack it.
Secure Systems has had a product for two years (www.securesystems.com.au). Also there is a company in the UK - cant remember their name.
Integrity of the inner volume seems quite fragile, due to the possibility of it being overwritten through the outer volume, but aside from that it seems like a good plan.
This could be a plus. If you were ever foricbly made release your key to the outer volume then you could keep "secretfiles.tar" sitting around so that a less skilled attacker would untar it and in the process destroy the inner volume.
Maybe step 1 could be not having all this information on a laptop.
This too, will end.
Windows Vista Bitlocker encryption uses DRM to ensure that data stays encrypted, even on swap. You can recover the data using a backup USB key, but if you forcibly change the password from an admin account, all the bitlocker data will be deleted.
EFS is VERY buggy and limited, according to Microsoft technical support representatives.
Slashdot thread about EFS failures: EFS is very poorly documented. EFS failures.
The date on that article about the ABit motherboard: July 31, 2003. What happened? Apparently that idea was not successful.
FYI.
:-/
TrueCrypt was recently covered & promoted by Steve Gibson,
author of SpinRite, in his Security-Now! podcast (no. 41).
'looks good & fast; is it?
TIA
Finally, it should be hardware based, not software based. Software can always be compromised. If your information is that valuable, then someone will hack it.
This is a real misunderstanding of security and encryption. The point of an encryption algorithm is that you can know the implementation thoroughly, but without the key you cannot decrypt the data.
So for an encrypted hard drive, software is fine. The key is encrypted with a hashed password (or for some schemes the key is a hashed password) - so the encryption is as strong (or as weak) as the password. Whether the encryption is done by software or hardware is irrelevant.
There are a few provisos to this:
Incidentally, the strength of encryption being determined by the strength of the password could be a key reason for lack of uptake. Security people don't trust users to use and remember strong passwords. Though the casual thief of a laptop would be defeated by almost anything.
What holds me back is concern that it will malfunction.
A malfunctioning encyrption engine == a permenant deletion engine.
If something goes wrong in encyrption, storage, decryption or some other sub-system, everything is lost. You probably can't recover it -- if you could, the encryption engine isn't doing it's job.
Yeah, if you wanted to brute force the actual key.
A better way would be to brute force the password/passphrase. Try all combinations of letters on the keyboard for increasing lengths, run through the appropriate hashing function for the encryption scheme and try that.
The real encryption key is hard to brute force, the user remembered passphrase to the key is less so.
M
From what I've seen in a corporate environment, like 14,000-ish employees, is that to change things that involve other people is like changing the momentum of a large object: you have to push and push and push. The change will happen, but it just takes longer.
Aside from that, I believe there are somethings that can just get in the way:
The first two are interchangable according to the context of the change and I just put portability in there to keep some sort of technical focus.
My organization has been looking for a solution for this recently, and is leaning towards PGP Whole Disk Encryption http://www.pgp.com/products/desktop/professional/p gpwholedisk.html. One feature we like is the ability to do whole disk or simply folder encryption, when that is all that is necessary.
Anyone have experience, positive or negative, with this? Our testing has gone well on Win2K and XP so far...
There's the ability in all modern drives to set a hardware password. It's virtually unbreakable, has little to no speed impact, but don't forget it. There's no known backdoor.
The cesspool just got a check and balance.
1) Encrypt your swap. Not hard especially on Linux. If you must run an OS that can't encrypt its swap, virtualise it. Windows on VMWare on Linux, or whatever.
2) Don't trust hardware crypto. You didn't write it, can't read it. The NSA probably pwns the keys. Do crypto in software with peer-reviewed open source.
Take a simple linux install disk that uses initrd of your choice and comes with cryptoloop.
Modify the initrd so it asks for a password before setting up the "real" root device on your harddrive.
Burn the install CD with the modified initrd. Install linux using this disk (so it installs onto the now-encrypted hard drive)
In order to use the system, you'll have to insert the install CD and use it as a boot CD everytime. But in this fashion no un-encrypted data is on any of your hard drives. To remove evidence that you can even access it, remove the CD when you're done using the computer, and store it in an inconspicous place.
If you prefer using windows, deal with linux to the point you can install QEMU or VMWare. Install Windows normally in the virtual environment and it is encrypted as well (including the swap file!).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
It is possible I have a "real misunderstanding" of secrity and encryption. There are probably many posters with a better understanding than I.
But it is not just about the technology, it is about practical application of the technology. The majority of the posts on this thread home in on the issue of practicality not technology. In the real world people are not doing the things we expect or want them to. It is hard enough to get them to use the security tools.
In the response you say "software is fine" with a "few provisos".
But the "few provisos" can be real, practical cases where the system could be compromised.
DaMish said: " . . . you can no longer trust the onboard software to not be modified to save/transmit your password/key. "
And it is not just the case where a laptop is lost and recovered. How often do you find your users have downloaded all kinds of spyware and junk code onto their systems just to get a smiley cursor?
Do your execs stick their laptop in the bottom drawer overnight when they head out early to play golf?
Maybe software basd encryption is fine if you have an extremely disciplined user base. But then, it is only a few days since Symantec had to patch a major flaw in their anti-virus.
My belief is that the encryption implementation must be isolated from the system using a hardware based approach.
For me, software based encryption is not "fine" enough in the real world. Give me a hardware based solution (at the right price please).
Can anyone point me at some good hardware solutions?
The problem with disk encryption as it is implemented today is twofold:
1. it doesn't scale - all the various products today can be used for small deployments and still be useable. However, try to scale it to a large enterprise with thousands of machines and you have an administration headache. Microsoft EFS has various flaws in it like this. For instance, if somehow a user's _local_ profile on the machine with the encrypted data is erased, all his data is gone or has to be recovered by the backup operator (assuming the user went through proper procedure to allow this). Because of EFSs reliance on local profiles (if I recall correctly roaming profiles don't cut it), even NAS machines have to maintain a profile for every user accessing encrypted files on that machine. That's ok for 10 to 15 people and utterly ridiculous when you have 20,000+ users. Also, if I remember correctly, EFS adds an additional layer of certificate based ACLs which are devilishly difficult to use and are also contingent on local profiles being present for the users you want to grant access to.
2. it is a subset of the scaling issue but is a category of its own because it is central to a successful encryption scheme. Disk encryption is easy, managing the keys used for encryption is the real problem and is where your security ultimately lies. Again, the problem here is that for a small organization where you can store the keys on a notepad, if you like, is easy. For a large organisation with thousands of machines and hundreds of locations that need to share data, securely managing thousands and even millions of keys is not trivial. Key management considerations are Informaton Lifetime Management (ILM), Backup & Data Recovery (after a disaster, for instance), Synchronization across multiple sites, various key levels to control data sharing within an organization and without with its partners.
In summary, encrypting a disk is easy. Making it useful and manageable is very difficult.
You're forgetting one thing: The solution needs to be robust. If one bad bit can wipe out all your data, that's a non-viable solution, even if you're keeping regular backups. That, to me, is the biggest problem with encrypted file systems.
Probably the best solution would be to minimize the amount of sensitive information kept on laptops in the first place, by transferring just a tiny portion of the result set over encrypted network links in response to centrally-processed queries. There's really no need for someone to be toting around 30 million personal records, just because it makes their job easier.
Ok, I know you've seen movies and read books. But the fact is, crypto today mostly isn't about compsci/math geniuses who, given enough caffeine and a week without sleep, will stumble on some inspiration that'll crack the code wide open.
Crypto today is about brute force. And it's about how you CANNOT brute force a crypto key with current hardware. And this isn't about Moore's law, we need fundamentally different hardware to be able to crack current crypto techinques.
This is why the only reliable way to break it is to go around the crypto. If you build a fortress out of solid steel, but your front door is glass, an attacker would have to be a moron to try and get through the steel. Only, no real-world analogy quite conveys the impossibility of getting through the steel -- there is no blowtorch, you just have to look for glass doors. If the doors are steel, you try to break the padlock. If the lock's embedded in the door, you look for the key. If you can't find the key, you're fucked -- there is simply no way in.
Don't thank God, thank a doctor!
If you can't trust hardware, you can't trust anything.
Think of it this way -- do you regularly dissemble your keyboard and check for keyloggers embedded in it by the manufacturer? Could you tell the difference if one was part of its controller anyway? What about your motherboard?
And, even then, who built the chip fab? How do you know there isn't someone there changing your design before it actually gets to the silicon? And changing the visual on whatever microscope you're using?
For that matter, how do you know the govm't hasn't already built successful quantum computers, capable of breaking whatever crypto you use in split-seconds anyway? All they'd need is a plaintext word to check against, so they know when they've got the right key... hey! Your swapfile does have a swap signature, right?
Unless you're going to create everything yourself, untrustworthy hardware will always beat trustworthy software. And even then, you never know what tech might be out there to break your crypto.
At a certain point, you just have to trust something.
Don't thank God, thank a doctor!
Anyway, I beat them all bloody over price but when all was said and done, the price tag to protect 7,500 laptops still came to somewhere between $500k and $600k the first year plus 20ish% maintenance thereafter. The big boss nearly *&!@ a brick. Needless to say, we don't have an enterprise encryption solution in place.
Feel free to call Seagate presales support and ask about drive availability for Momentus drives with Full Disk Encryption. Despite the kludged setup shown at CeBit, there is no current BIOS that can talk to this drive. The hardware is unavailable and will only become available with laptops from big manufacturers at some point in the future. The guy I just talked to said "2 months, 6 months, who knows?"
.mil domain and see what sort of stuff the military is buying. Fascinating stuff.
Note also that this thing has already been announced for a solid year. Even if you had one, you wouldn't be able to slap it into an existing machine and make it work.
Luckily, there are alternatives. Not so luckily, they are ridiculously expensive - on the order of USD$600 for a 60 gig drive. There are also inline encryption modules that may or may not be secure, but good luck getting your hands on one to test.
I've been trying to source product in this sector for months. When I finally have some success, maybe I'll submit an article. Until then, I'll just leave it at this: "Full disk encryption in hardware is impractical and hard for an individual. Governments and the military are another story."
If you're really interested, poke around in the "request for proposal" sites in the
I have been using an encrypted RAID5 drive in my machine for months. I have had a few disc failures and recovery is easy enough - I just remove the disc from the raid, and the new one back, and it fixes itself. Encrypting everything is easier than encrypting only parts, because there's no granularity at present to ensure you don't accidentally copy or move "safe" data to "tainted" areas - ewncrypting everything ensures there's little chance for accidents.
Making the disks encrypted is even easier than making the RAID5 using mdadm. I've also had failures in my home partition (which is not on the RAID) and the standard reiserfs recovery tools had no problem fixing the corruption - just mount the encrypted partition and use the tools as normal.
The THERMITE method (to be used only if loosing the data is better than having it comprimised) the way it works is you stack a thermite blanket on top of the drive and then you rig a switch.....
Any person using FTFY or editing my postings agrees to a US$50.00 charge
JTDL Just too damn lazy.
Toda rabbah
Obviously secrecy isn't as important to your company.
600k for 7500 laptops isn't that bad assuming USD. 80/laptop, 16/year after that.
How much do you spend on crappy AV software for those 7500 laptops?
...works like a charm - enterprise-grade stuff with remote management, single-sign on and 256 it AES encryption across the whole disk (i.e. boot partition too). slows machines down a little, but it definitely does the job. i'd imagine it's expensive, but it does seem to scale up to enterprise size pretty well.
The really great thing about TrueCrypt, as I see it, is plausible deniability. This means that you can "nest" volumes and only have to account for the outer "envelope" when you are tortured by Homeland Security because you are using cryptography. The short of this: it is impossible to distinguish the "signal" of a nested hidden volume from the "noise" of random bits and such on the device.
An Industry Standard
Exercise caution when modding this message up: the author acts like a jerk when his karma is excellent.