There’s a new hard drive encryption standard, which will make it easier for manufacturers to build encryption into drives.
Honestly, I don’t think this is really needed. I use PGP Disk, and I haven’t noticed any slowdown due to having encryption done in software. And I worry about yet another standard with its inevitable flaws and security vulnerabilities.
EDITED TO ADD (2/13): Perceptive comment about how the real benefit is regulatory compliance.
Tim • February 5, 2009 8:23 AM
I wonder what effect this will have on drive reliability. If the key is destroyed, your pretty much screwed, unless you have a good back up.
Peter • February 5, 2009 8:26 AM
FDE without a performance degradation? Very unlikely, the encryption needs to be done or there is no encryption … 😉
Tim • February 5, 2009 8:27 AM
I have to admit I only skimmed the specification at https://www.trustedcomputinggroup.org/specs/Storage/Opal_SSC_1.0_rev1.0-Final.pdf , but the revert method would destroy the key and it appears it can be called from software. If I read it right, their will be some really nasty possibilities for viruses, not profit oriented, but the old school ‘I just wanna break other peoples stuff’ kind.
Paul • February 5, 2009 8:38 AM
when I read about this my only thought was there will end up being a backdoor key that can be used for data recovery which will ultimately defeat the purpose of an encrypted drive.
I’m with Bruce, use PGP disk, or something similar.
Emmanuel Pirsch • February 5, 2009 8:39 AM
You must not notice any slowdown because PGP Disk is probably the first thing you install on a brand new computer.
The company I work for just made is a corporate policy that every PC should have PGP Disk installed and encrypt the entire disk. PC now take at least twice the time to boot and everybody is complaining about the slowdown.
Sure, once the PC is all booted up and if you just doing some Word or Excel stuff, you’ll hardly notice the slowdown. But it is very noticeable when you do things that are a bit more intensive on the harddisk. Also, when you PC runs low on memory and that swapping occurs, you feel like it’s almost grinding to halt.
So software disk encryption does slow down you PC a lot for disk access.
Just for the fun of it… Decrypt you disk and use your PC like that for a day or two (taking every precaution not to loose it during this period) and then re-encrypt it… Then you’ll notice the slowdown.
Jason • February 5, 2009 8:53 AM
Actually, I think there is a good reason to have it in the drive – it becomes less dependent on the OS, or multiple OS on a dual boot system. If someone knows of a software based encryption package that can handle whole disk encryption on a PC that’s dual booted Windows/Linux, please post the name because I haven’t found it. The software solutions don’t seem to be able to handle anything outside of a vanilla OS install.
Swashbuckler • February 5, 2009 8:57 AM
The individual user probably does not need this. However, think about large enterprises, backups and key management…
A nonny bunny • February 5, 2009 9:03 AM
@Jason:
‘If someone knows of a software based encryption package that can handle whole disk encryption on a PC that’s dual booted Windows/Linux, please post the name because I haven’t found it.”
People seem to have managed it with truecrypt. http://tinyurl.com/cudl8w
SteveJ • February 5, 2009 9:06 AM
@Emmanuel Pirsch:
Perhaps Bruce has a faster machine than your office PCs. Assuming a fast PC with an otherwise-idle core, disk encryption shouldn’t be that big of a deal. And I’d be willing to wager a small sum that Bruce can afford PCs which very rarely need to hit swap…
sbr • February 5, 2009 9:22 AM
The last time I looked at FDE (admittedly a few years ago), the key used for the encryption is generated by the drive manufacturer and never leaves the disk drive. The other keys are used for en- and decrypting this master key.
You therefore have to assume that the key is known to the secret service of the state the drive manufacturer resides in.
So, to be secure, you’ll need something like TrueCrypt anyway, so why bother with FDE? It doesn’t add anything.
bob • February 5, 2009 9:39 AM
I read the article looking for some addressing of the subject of key escrow or backdoors and didnt see any mention of the subject at all therefore I assume that there is a backdoor. So to be secure for real you’ll need to PGP anyway. And yeah I am afraid their goal is DRM not security or anything else that might benefit the person purchasing the drive.
When I was in military comm, there was a tendency to (symmetric key) encrypt a signal (usually telephone), then bulk encrypt it again after multiplexing, and I had this recurring nightmare that we would have (i realize this is a probability of about infinity minus 14.7) a bulk key which was the inverse of the primary key and be sending in the clear.
Evolution • February 5, 2009 9:47 AM
I for one look forward to disk encryption becoming a “commodity”. Right now, the cost of 3rd party disk encryption can hinder its deployment. I know of companies that have opted for only encrypting laptops, and not all desktop computers, due to the cost of the 3rd party software. I would expect that disk encryption built into the disk drive would cost much less than a 3rd party software add on.
Also, once the encrypted disk drives become standardized and commonplace (i.e. can’t buy a drive without built-in encryption), OS vendors like Microsoft will build the necessary key management into the OS and enterprise management tools like Active Directory.
Full disk encryption is no different from any other technology which is needed by all and must become a “mainstream” commodity (e.g. TCP/IP software and ethernet cards), which is initially purchased as 3rd party add-ons, but eventually evolves into something that is just “free” and included as part of the OS or baseline computer hardware.
This evolution has started with Bitlocker in Windows Vista, but Vista is not ubiquitous and Bitlocker still has limitations. Bringing the encryption into disk drive will provide a better baseline for moving forward.
In my experience, software-based FDE does not work well at all on systems with solid state drives. To the SSD firmware, a drive that has been encrypted appears to be full, even though most of the encrypted space is empty. SSD write performance gets very slow when the firmware thinks the drive is full. If the SSD handles the encryption in hardware, there is no such problem.
Paeniteo • February 5, 2009 9:54 AM
@bob: “When I was in military comm, there was a tendency to (symmetric key) encrypt a signal (usually telephone), then bulk encrypt it again after multiplexing,”
Isn’t it so that double encryption is only marginally stronger than single encryption?
(This is why we have Triple-DES and not Double-DES.)
Mike • February 5, 2009 10:24 AM
I believe triple DES was for compatibility with single DES implementation. If the same key is used in 3DES, it looks just like DES.
Jason • February 5, 2009 10:29 AM
@A nonny bunny:
Check that link again – the Linux portion is only being partially encrypted. It’s probably good enough for most purposes, but it’s not true whole disk encryption for a dual booted system. This is where the hardware encryption is going to make the difference.
Tbob • February 5, 2009 11:05 AM
@jason:
You can encrypt the Linux portion too, except for the /boot partition (Grub must be able to bootstrap there) but they chose not to do it since Linux is better at not writing random stuff around the drive (I would encrypt swap, /etc, /var and /tmp in addition to /home, but I’m more paranoid).
True FDE it’s not, but it’s partition encryption for anything you should need to keep secret, and it’s compatible with both OS.
JRR • February 5, 2009 11:10 AM
I just had TrueCrypt fully encrypt my boot drive on my little MSI Wind netbook. I haven’t noticed any performance difference, and boot time seems the same though I’ve never taken a stopwatch to it.
It claims to support multiboot systems, though I haven’t tested it. It was a darn smooth (impressively smooth, IMHO) operation, and I think it’s really likely that it’s actually been tested with multiboot systems.
derf • February 5, 2009 11:16 AM
This will only be used to lock you out of your computer. Wanna run Linux? Too bad, you have to buy a linux computer. Wanna run Windows on your Mac? Too bad – you have to buy a Windows machine for Windows. Wanna run VMware and use different operating systems? Hahahahahahahahahahahaha.
Wanna write a new OS? Sorry, that’s not supported.
Paul Crowley • February 5, 2009 11:19 AM
The entire crypto content of this “standard” is something like “It will use AES”. No mention of eg XTS mode or any other details of how the cryptography might work. I don’t think this deserves the name “hard disk encryption specification”.
John Ripley • February 5, 2009 11:25 AM
You are all missing the point!
I am not saying that this shouldn’t be done in hardware. It just does not belong in the hard disk! This could instead have been a standardized way of laying out the disk so that a key can be stored and retrieved in a cross-platform way.
You could then stick encryption in the hard disk controller chipset/card. There – no software overhead! On the bonus side, there would be absolutely no reason to buy a new hard disk, change the specs for hard disks, or manufacture new disks. Even better – you only have the hardware encryption in the controller rather than duplicated in every hard disk.
This strikes me as a cynical “value-add” at best, and I’m still convinced that the real market they’re trying to sell this into is for DRM, e.g using it in time shifting set-top boxes and consoles.
Software encryption is “fast enough” if not done badly, and if that’s not fast enough for you, then it’s definitely good enough if done in the disk controller. NOT the hard disk.
Rich Rumble • February 5, 2009 11:33 AM
Hardware FDE is the only thing I can really see getting around the “cold-boot” attack, where they froze the ram with compressed air, when the system was suspended or sleeping. You can in fact manage the keys of the Seagate drives, and McAfee has integration for them as well. Performance will be affected, even on modern hardware when using software encryption, but I do love TrueCrypt and use it where ever I can. I only wish it’d get properly vetted and or Mr Schneier’s cryptography sound approval. I know it’s not in the “doghouse” but it’d be nice to see it on a pedestal 😉 I wonder if anyone is willing to pay to have it FIPS certified… I’m sure it cost’s a bunch…
-rich
Rich Rumble • February 5, 2009 11:39 AM
And don’t forget PGP’s WDE backdoor!
Starts here:
http://securology.blogspot.com/2007/10/pgp-whole-disk-encryption-barely.html
Ends here:
http://securology.blogspot.com/2007/10/sorry-for-delay-jon.html
-rich
Patrick Henry • February 5, 2009 12:56 PM
This is all pointless because the spooks will have a key.
It needs to be done in open source software.
Anonymous • February 5, 2009 1:09 PM
As usual, custom equipment is needed and open source procedures.
The real question is: is it legal to build your own hardware encryption cards? Software crypto was given a pass, but not hardware crypto. I’m unsure about these laws now. ITAR laws are not to be taken lightly.
Bad and tainted crypto is a dangerous tool for an out of control police state.
Sure would be nice to have a serious wipe equipment in the hard drives, and be able to plug the hard drive into an external unit that encrypts the drive. Nope, not allowed, too simple, too easy to use, too honest.
Sure would be nice to be able to remove the platters easily, and install fresh wiped ones, and purge the hd with clean air. A small clean room box with robotic arms to do the work could be cheap. Nope, not allowed!
Would be nice to have public domain patent and systems given to the people. Nope, too late!
DennyBob • February 5, 2009 1:18 PM
I like the idea of a standard based on hardware mechanisms. As others have stated, its no big deal for regular home users to have software based FDE, but jump that up into the Enterpise and it is a different story. We are now on our second FDE product, why? all these products are a beast to manage, management of the clients is not even secondary it is way down the list for the vendors. Encryption is easy, but managing encrypted clients is difficult. Maybe this will take the vendors focus off of client software and attention will go towards a manageable infrastructure. Right now what we have in the Enterprise is very secure and completely unmanageable.
Skorj • February 5, 2009 2:24 PM
I worked on the standard for hardware encryption for tape drives. Most of the argument in this thread misses the point.
The point of hardware encryption in disk drives is procurment for regulatory compliance. If a hard drive is certified as compliant with some FIPS, a government entity or bank or whatever can just buy it as hardware, connect it to a key management system biught as hardware, and greatly simplify their procurement process.
The drive manufacturers love this because they can charge extra. The pruchasin agents love this becuase it simplifies their life (they don’t care whether the data is safe, they care that they can purchase compliant equipment).
kangaroo • February 5, 2009 3:14 PM
A single key to bind them…
This is just ridiculous. If you are going to actually secure something — it takes work. Hard thinking.
What we’re going to get here is bureaucratic ass-covering. I’ve already seen it at a university that “requires” full-disk, hardware encryption of laptop disks, without any thought about whether the data/domain requires it (who’s going to steal your rat survival numbers? Who cares?).
At the same time they leave a backdoor, since to keep the users from disabling this nonsense, they then lock the root account, leaving a universal backdoor to what actually matters when your protecting data that is sitting on the internet — the data while the disks is mounted.
So, they’ve actually massively reduced the security of their data!
Yup, that’s IT “thinking” for you.
Garrett G • February 5, 2009 3:35 PM
Hardware crypto – good idea, in my very humble opinion. It pushes FDE to the mainstream as others have mentioned. Also, PINs or tokens can be used in lieu of complex, hard-to-remember passphrases. And, as someone mentioned, h/w crypto (like Seagate Momentus) is immune to the “cold boot” attack (or any attack that involves reading the key out of RAM… I believe many OSes allow for direct memory access via the firewire port, for eg).
Clive Robinson • February 5, 2009 3:37 PM
A few of points,
1, What is the threat model?
2, How is Key Managment to be performed.
3, Hibernation modes.
4, Hot snatch prevention.
For most people the threat model is “stolen hardware” / “regulatory requirment” so for this the drive is just fine and dandy (provided it does not bootup without autherisation).
The only fly in the ointment for this threat model is hardware failure but everybody keeps transferable backups don’t they?
However what about the “privaleged information” threat model where you have information that for some perfactly legal reason should be kept from the state. Then FDE is not a solution to be relied on you need to take aditiona steps such as Software Disk Encryption. However this is not a reason not to use a FDE drive if it’s built in (call it belt and braces for theft of hardware).
There is an aditional fly in the ointment here which is ensuring that not only do you use the software disk encryption correctly, but also that you can delete encrypted information fully.
Closed platform threat model, this is the DRM issue, in that you are locked out from the content of the hard drive by the system it works within. This is actually not so much of a threat as first it appears. Because the data is encrypted on the drive and not in the system you can snoop the unencrypted data off of the interface. And it would not be to difficult to make a small hardware device to put between the drive and the system such that you could let the system start the drive up and then take it over to do an unencrypted dd to another drive.
There are other threat models but they are mainly variations on the above (except for 3&4 on the list).
Key managment is only an issue if you don’t have plaintext or known ciphertext backups. Or you implement some system where timley backups to a non encrypted device are not practicle (yes there are such systems) or is of no importance (back to DRM systems again).
Apart from DRM FDE is realy a non issue from the autherised access point of view providing users follow sensible precautions such as backing up their data.
But from the “regulatory” point of view they are a god send as they can be used in a way that is transparent for autherised users but “dead in the water” for unautherised users providing the system is not in hibernation or hot snatched…
Hibernation modes are the killer of FDE and actually wreck the whole thing. Unless there are specific provisions within the drive and the operating system such that on entering hiebernation the decryption is turned off then it’s game over as somebody with modest technical skills could get at some or all data.
The same applys to a “hot snatch” where the machine is taken from the autherised user in the autherised state by a non autherised person (let’s hear it for the TSA et al).
keithr • February 5, 2009 3:57 PM
@Rich Rumble:
Hardware FDE is the only thing I can really see getting around the “cold-boot” attack, where they
froze the ram with compressed air, when the system was suspended or sleeping.
I’ve been toying with the idea of using the performance monitor registers on CPUs that have them to help protect against this attack. The basic idea:
The goal is to make the time window during which the hard disk encryption key material is stored unencrypted in RAM as small as possible (it will need to be decrypted every time a disk block is accessed, but the decrypted copy can then be immediately overwritten), and to ensure that none of the key material or cipher state that was used to encrypt that key in RAM is ever itself stored in RAM.
Fitting the cipher state in machine registers is a challenge, especially on x86-32. The algorithm will necessarily be much weaker than something like AES. But I think the security requirements are also weaker: an attacker will only get one ciphertext to work with. They won’t know the entire plaintext (if they did there’d be no point attacking the simpler cipher), but they might know something about the plaintext (the authors of the cold boot paper were able to develop a heuristic to find AES key schedules in memory based on redundancy in the schedule).
Most x86 processors can store 80 bits in the PMC registers; more recent ones can store more. If I’m right that the security requirements are much reduced, 80 bits might be good enough.
I have no idea what a good candidate for the simpler cipher would be. Perhaps some variant of Helix? As I understand it, Helix was designed so that its state, but not its round keys, fits in the available registers on an x86-32 CPU. For this we want everything to fit in the registers. And of course it needs to be as fast as possible (but no faster 🙂 ).
SumDumGuy • February 5, 2009 5:57 PM
@keithr
Read this guy’s blog from the bottom up:
http://frozencache.blogspot.com/
Dmitry Obukhov • February 5, 2009 8:28 PM
I’m working with this technology and can answer some of the questions raised here.
Backdoor. There is no backdoor in the product I’m working on, I can guarantee it with my personal reputation. FIPS certification will be better proof, but it will come later and only if customers will be ready to pay.
Manufacturer is not generating the keys either. There is a non-deterministic random number generator that generates the keys. There are multiple levels of isolation in code and organization to protect keys even from the security firmware. The keys are never leaving the drive, so there is no problem of key management.
Linux. We are not going to lock out Linux users. Please notice that the specifications were released last week and we (now I’m wearing TCG Contributor hat) hadn’t too much time to contact open source community. Most of companies are positive on open source support. I even know about some plans to release some code to the public. Linux developers interested in support of TCG Opal, please contact me.
Please feel free to mail questions about this technology to “Dmitry.Obukhov” at Gmail. I can not promise to answer all of them due to the trade secrets, NDA’s, and other limitations, but I’ll do my best to help.
Michael Hampton • February 6, 2009 12:10 AM
Encryption in software is indeed slow. I notice it frequently. And this on a Core i7 workstation using LUKS, aes-cbc-essiv:sha256 on a hardware RAID 5 (megaraid_sas) with 4x 15000 RPM SAS drives. The speed at which the kernel can encrypt and decrypt my data has become the bottleneck. I’m going to have to overclock the CPU just to get the performance I was expecting out of my RAID array.
(Part of the problem here is that the kernel seems to run encryption in only one thread.)
Tom T. • February 6, 2009 1:31 AM
@stevej:
“Perhaps Bruce has a faster machine than your office PCs. Assuming a fast PC with an otherwise-idle core, disk encryption shouldn’t be that big of a deal. And I’d be willing to wager a small sum that Bruce can afford PCs which very rarely need to hit swap…”
Anyone who can afford a computer can afford one that doesn’t need swap. I have an older, low-end laptop. For $25 I bought a RAM upgrade and disabled paging completely, including deleting pagefile.sys. Don’t let anyone tell you that Windows (XP) can’t run without a pagefile. It can and it does, just fine. And besides the security implications, the machine is super fast. I’ve read that it takes 40,000 times as long to retrieve data from pagefile as from RAM. I believe it. Try it. It works.
Nik • February 6, 2009 2:14 AM
On the subject of performance, I recently did some extensive benchmarking of a number of FDE products prior to a corporate rollout. The performance hit across a range of operations was 10-20% for AES256. The free TrueCrypt had the best performance.
I agree with Bruce that in normal use this isn’t really an issue, but it is noticeable on disk intensive operations such as database startup.
It would be interesting to compare performance of hardware FDE modules with software equivalents.
Nik
Clive Robinson • February 6, 2009 4:22 AM
@ Tom T.
“a RAM upgrade and disabled paging completely, including deleting pagefile.sys. Don’t let anyone tell you that Windows (XP) can’t run without a pagefile. It can and it does, just fine.”
Actualy often you don’t need a RAM upgrade either (it depends more on what apps you use).
However if you get it wrong XP tends not to fail gracefully and you may lose data etc (Your mileage etc etc).
When you set up XP to run on an “embeded system” such as a test instrument pageing is just one of the things you disable or remove (and do you need “windows” or anything other than FAT32 etc etc).
As a hint for those wanting to strip XP down install a fresh copy then clean out all the startups in the registry etc you know you don’t need.
Then reboot in safe mode and keep an eye on what gets loaded up.
Then selectivly remove known / suspected “not needed” stuff to somewhere safe out of the path etc and reboot.
By “remove” I do not mean “deleate” I do mean put it somewhere safe… This way you can reboot with a recover CD and put it back with minimal problems. GRUB can also be your friend if you know how to use it.
How do you know what’s “not needed”, if you have a scan around the internet there are tutorials etc on what each bit of XP does and how you can trim the “bloat” including getting IE out of window 8)
For those that are a bit lazy buy a netbook with XP on it and have a look around the recovery partition…
XP will never be blisteringly fast compared to other OS’s but the advantages of well known tool chains and off the shelf software etc are not to be overlooked when running small projects.
Oh and for embeded stuff Tk/TCL can be another friend as can embeded Perl but watch the bloat on that.
ATN • February 6, 2009 5:55 AM
Well, all the hard drive sold during the last 5 years have such a feature – see:
http://linux.die.net/man/8/hdparm and search “ATA Security Feature Set”.
Also been reported on your blog few years ago (July 28, 2005).
Just by chance, none of the virus writer wants users to loose the content of their hard disk within the next few seconds – until now.
One of the problem is that IDE disks in USB enclosure were most of the time not able to set the password or authenticate, it seems that this spec would enable it.
ACK • February 6, 2009 8:50 AM
“Honestly, I don’t think this is really needed”
Ack Bruce. I use TrueCrypt 6.1a :-p The best for privat use on windows market :-p
Dont trust HD-Firmwares (!!!)
Bruce Schneier • February 6, 2009 11:59 AM
“Hot snatch prevention.”
My solution — amittedly imperfect — is to have most of my data encrypted with a separate key on a virtual drive, a drive that remains encrypted most of the time. So if someone snatches my computer, they only get some data.
Paeniteo • February 6, 2009 12:21 PM
@ATN: “Well, all the hard drive sold during the last 5 years have such a feature – see:
http://linux.die.net/man/8/hdparm and search “ATA Security Feature Set”.”
AFAIK this is not data encryption, but merely a password protection for the HDD controller.
larry • February 6, 2009 2:09 PM
arguably one good reason for a standard is to pave the way for that encryption to be supported in the drive at the hardware level.
Skorj • February 6, 2009 2:55 PM
“have most of my data encrypted with a separate key on a virtual drive, a drive that remains encrypted most of the time”
This seems the best option with existing products. What’s lacking is some sort of automated timeout, which would give really good protection against robbery, excepting robbery by a government looking specifically for your data (and, really, if a government has physical access to you and wants your data, they have so many options that worrying about this one seems silly).
I’d like to see a product that would run a virtual machine from an encrypted volume, and after some timeout automatically shut down the VM and dismount the encrypted volume.
Dmitry Obukhov • February 6, 2009 4:20 PM
“have most of my data encrypted with a separate key on a virtual drive, a drive that remains encrypted most of the time”
This is not enough. If you have documents, the software may store some portions in the page file, hibernation file, etc. You need
a) encrypted virtual drive
b) virtual machine within the space of the virtual drive
oh man... • February 7, 2009 9:35 AM
Permament product placement of PGP Corp. bloatware in this blog NERVES.
moo • February 7, 2009 12:50 PM
I use software FDE. The only scenario I worry about is my PC or laptop being stolen by a common criminal (or lost at an airport or something). The laptop I turn off when I’m not using it, and the PC is often powered up but I hope that a criminal who stole it would have to unplug it from power in order to cart it away.
@Dmitry: I always disable hibernation, and encrypt the pagefile with a random key that is generated on OS startup (so after the contents of RAM are lost, the contents of the pagefile are no longer easily retrievable).
It wouldn’t necessarily stop a really determined adversary, but as far as I know I don’t have any of those.
Tom T. • February 7, 2009 4:00 PM
@ Clive Robinson: “Actually often you don’t need a RAM upgrade either (it depends more on what apps you use).”
Definitely. Note I said I had a low-end model with minimum RAM (512MB). If you have a higher-end with more OOB RAM, sure, you’re good to go.
And yes, I’ve cut a lot of the garbage out too. For stopping unneeded, RAM-eating “services”, blackviper.com is useful. For trimming 80% off Windows itself, the guide by “Bold Fortune” is useful: 3w dot graphixanstuff.com/Forum/index.php?showforum=68. Caution: he apparently has a totally bare-bones system (not even a printer), so your mileage definitely will differ — think and try before making any of his suggestions permanent.
And yes, I did a complete disk backup before starting any of this, and backup both the whole disk and the important data regularly. But shouldn’t we all be doing this anyway?
Thanks for the comment.
Tom T. • February 7, 2009 4:03 PM
@Dmitry Obukhov:
Disable hibernation and paging, as per my first post.
greg • February 9, 2009 7:30 AM
One issue that hasn’t been raised that Bruce kinda brought up is the quality of the standard.
Engineers have been pretty bad at both designing a secure standard and implementing them securely. The wireless debacle comes to mind. But there are other examples (GSM is another example).
So do you trust the FDE?
As for raid setups. I would have thought that raid controllers would be capable of encryption these days no?
ATN • February 9, 2009 11:02 AM
After reading the standard, this extract:
This specification addresses a limited set of use cases. They are:
• Deploy Storage Device & Take Ownership: the Storage Device is integrated into its target system and
ownership transferred by setting or changing the Storage Device’s owner credential.
It seems that we are talking of a “multi owner” hard disk where some parts can be accessed if you get (i.e. pay for) the key to unlock it.
I am not sure of the use case, but this spec is not done for full encryption of HD.
MustbeANON • February 9, 2009 12:07 PM
So do you trust those who are F O R C E D to fork the truth?
So do you trust those who are F O R C E D to fork the security?
… the security.
… the reasons behind all of the above.
FDE, HDE, is a sign, a mark of the beast if you want to put it simply.
steven sprague • February 10, 2009 7:40 AM
dmitry’s Post brings some clear facts to this conversation. I am the CEO of Wave Systems we are one of the software vendors building to support this standard and an active participant to the storage working group at TCG. I have also personally carried an FDE drive for almost 2 years.
A few other key points that are typically not discussed. The FDE drives do the crypto execution and key managment in the hardware of the drive. Basically the managment of these drives is all about access control and not key managment.
Access control happens before the main OS is present. This Pre boot Code is also secured by the drive. The code that is PRE OS is Read only from the drive and protected by the drive controller.
There are a broad group of risks that can be part of the preboot code by haveing the drive assist in the integrity of this code many of those risks are reduced
There are no back doors in these drives If you do not have access to a drive there is no magic disk to bypass the security. Central managment by the enterprise is easily achieved by a number of vendors ourselves included that provide simple recovery tools to the enterprise. These recovery tools are set up at the Enterprise’s option when a drive is initialized. this takes 10 – 15 sec per drive not the few hours that PGG or any software tool takes.
For any IT department this is a very simple Real enhancment to security. Today all power modes are supported so there is no risk of powering down your machine wrong. Any time we can eliminate the consumer from making a mistake and leaving their computer insecure it is a good thing. I would ask Bruce if he can configure his PGP wrong and as a result leave a machine vunerable? This is very hard to do with an FDE Drive once configured by IT or a Consumer user it is hard to screw up. For example re imaging a machine will not effect the security.
I have seen a couple of top corporations who have deployed software encryption that has not been configured correctly and therefore offered no protection. In both cases no FDE password was required to wake the machine from sleep and sleep had not been disabled. Security that requires the users to be involved in the method of powering down their PC is no security at all.
Everyone should have FDE in the machine. I have Single sign-on up through Windows both XP and Vista and I only have one password to open my PC. The FDE Password is requested within 7 sec of pushing the power button and then my PC logs me into windows. I can leave my PC in a hotel room and feel safe I can lose it at the airport and know I only lost a computer.
Finally as Bruce has always said the devil is in the details. Loose the asset tag!!!!. FDE has a back door it is the help desk that can help you recover your password. Every enterprise that deploys FDE should loose the asset tag with the toll free nuber for the help desk written on it and the name of the corporation written on it and some even have the users name written on it.
Everyone who is considering this technology should buy at least one laptop with and FDE drive and get a hands on test drive. It is Easier to deploy, Easier to manage, Fewer configuration risks, and better security.
Steven Sprague
CEO
Wave Systems Corp.
PackageBlue • February 10, 2009 10:37 AM
Security is simple, incentives. Wave or somebody should pay out 10 million to whoever for a full break on system.
Why not power off HD, and have OS retry the access?
Removing the HD and putting it back in computer worked under earlier OpenBSD, not 4.4, 4.3, 4.2? perhaps 4.1.
The difference between a back door and a full exploit or break is spelling.
Crypto cards by IBM even have had issues. Sure Wave might be a great step up, but the details take a long time to figure out.
Andreas Kuhn • February 11, 2009 9:47 AM
Of course Bruce is touting PGP…
After all, he is a member of PGP’s Technical Advisory Board
razorblade • February 11, 2009 11:54 AM
andreas kuhn is what is known as a Wavoid.
Google Andreas Kuhn & Wave Systems and you will discover what a supposedly “unpaid hack” is all about.
For over a decade Mr. Kuhn under his own name and the name awkuhn has been spamming the internet with literally hundreds and hundreds of posts concerning, what else, Wave Systems.
For Andreas Kuhn to reference Bruce’s membership on the PGP technical board demonstrates the mindset of Mr. Kuhn.
For a man who apparently does nothing other than propagandize for Wave Systems, Mr. Kuhn is a poor excuse for a critic.
Bruce’s credentials, and his focus on data security is well known and respected by this industry.
Let’s not have the Andreas Kuhn stock tout types criticize a man we all respect.
Moderator • February 11, 2009 3:02 PM
Note that if you click the link in the phrase “I use PGP Disk,” you’ll find an article in which Bruce writes “(Disclosure: I’m also on PGP Corp.’s Technical Advisory Board.)”
I get the distinct sense that grudges from some other forum are being carried on here. Please don’t do that. The financial status of Wave Systems is completely off-topic here–and, I might add, a really boring subject. I’ll continue to delete messages about it.
Real_User • February 11, 2009 3:18 PM
It is interesting that Mr. Kuhn does an implicit attack on Bruce based on his credentials and association with PGP. Of course, Mr. Kuhn would advocate use of a product by a company whose CEO doesn’t know the difference between “lose” and “loose.”
But Mr. Kuhn, thank you for you opinion anyway. It reflects on you.
Moderator4Real? • February 11, 2009 4:49 PM
I didn’t notice the link at first. I thank Mr. Kuhn for bringing to my attention the fact that Mr. Schneier’s “opinions” are influenced by PGP, the product he touts.
I visited the TCG site. It is interesting Bruce Schneier claims to fear a new standard that just about every “who’s who” is involved with in technology (including all the hard drive companies), when the products he touts are known to have many flaws much worse than the new standard and can never be fixed by software running dependent on the o/s.
To anyone claiming armageddon due to a lost key, I don’t recall encryption ever being a solution for backing up data. Data should be backed up (on another encrypted drive).
I agree with much of what Steven Sprague says, simply saying to give HDD encryption a try. I actually have a Seagate encrypted drive since Oct 2008 and it works great. It was a very simple setup (less than a couple minutes), but I am one user, not a department of 100 users to manage. The fingerprint reader required more time to set up due to the repeated swipings.
I also agree with Emmanuel. At work we use software encryption and the delay is very frustrating.
From my own standpoint, the hardware secure drive is easier to set up, easier to manage, and easier to procure.
JGTIS • February 12, 2009 9:42 AM
Hello Mr. Sprague:
Just what do you mean by “Loose the asset tag”?
If you meant to lose it, that seems rather odd unless your are actually suggesting that companies used the TPM instead?
Why would anyone suggest that?
We all know that the TPM is DOA anyway.
JG Truth In Security
Loose Bits • February 15, 2009 8:51 AM
As others have noted, one main advantage of on-firmware encryption is that key material no longer resides in main memory. But the risk isn’t just of the “cold-boot” variety. There are other mechanisms to obtain enough memory to perform key extraction.
See this research for a point-and-click solution to decrypt PGP WDE if supplied with a memory image.
http://www.contrib.andrew.cmu.edu/~bfkaplan/
Dmitry Obukhov • February 16, 2009 5:22 PM
Lose Bits:
The encryption is hardware-based. There is no way firmware on relatively weak controller can handle the full bandwidth of HDD data I/O.
It is very theoretical statement: “There are other mechanisms to obtain enough memory to perform key extraction”. Of course, they are there, because the Universe is infinite. However, for the practical reasons some of them should be named and described. Can you?
Jon • February 17, 2009 10:14 AM
I have tested TrueCrypt 6 FDE and noticed one problem that keep me from using it on laptops:
Unless I’m mistaken that impacts performance in two places.
I found #2 to the the biggest issue. My one test laptop, an older Dell Latitude 530, ran the processor at 100% any time there was drive access. This caused the fans to run full speed, but it was still hot enough that it could not be put in your lap. My battery life was also reduced by over an hour.
I like the idea of hardware encryption because it solves these two problems. I know security is hard, and doing it right is even harder, and I’m hoping Seagate got it right with the Momentus FDE series, because that’s what I’m trying next.
I guess my dream solution would be hardware implementing something open-source like Truecrypt, but I doubt that will come any time soon.
VGM • February 17, 2009 12:09 PM
A prior comment about regulatory compliance hits the nail right on the head!
It’s a lot easier to state: there is no problem because the drive is encrypted
than it is to try and convince someone that no “critical information” was on the drive.
Dmitry Obukhov • February 18, 2009 12:03 PM
VGM:
Opal is targeting regulatory compliance. This is one of the reasons to have Admin and User roles separated. Admin (corporate IT) can state and provide proof that the lost drive was encrypted, because User can not disable encryption once it was turned on by Admin.
Outside the corporate environment the owner is equal to Admin. There is no need to create additional Users, unless owner want/have to play the role of family IT (what is the case for many of us 😉
PackagedBlue • February 24, 2009 3:58 PM
While I enjoyed this article/comments, sure would be nice to read more opinions about FreeBSD with Geli.
Jason • March 4, 2009 10:40 AM
The application I work on reads and writes large files to disk, and I’ve seen in the range of a 20%-30% decrease in throughput of our app since they forced us all to use disk encryption (All because some stupid executive couldn’t keep Soc Sec numbers off of their laptop).
This was almost exactly cancelled out by the speed increase of my new machine, but I’d rather have had the speed bump.
Niels • March 5, 2009 1:58 PM
Does this hard drive encryption method use key escrow encryption, or any other method which will ensure that forensic research will remain possible, for example in criminal investigations ?
I’ve been reading through the TCG Opal Storage Encryption Specification, but I couldn’t find any information regarding these issues.
Randy • March 8, 2009 6:00 AM
Niels:
To understand the Opal specification, one must follow its references into the SWG Core Specification.
In these first generation drives, key management is performed in the stack above the HDD. One vendor, Seagate, has claimed that it is unable to recover keys to unlock a drive. Another, Fujitsu, claims encryption keys are “cryptographically regenerated only when the correct password is received at power-on, and is unattainable when the system is powered off.” See representatives from both companies in the ‘Smart and Secure Storage’ clip:
http://www.tvworldwide.com/events/storagevisions/090106/
The HDD vendors probably wish to claim they could have no responsibility for data breaches, including those by law enforcement. This position is also aligned with TCG’s privacy policies.
In an apple to apple comparison, I have seen a vendor claiming 2X data throughput superiority over software encryption. Given the claim that encryption keys never leave the HDD, this aspect of security is stronger than software encryption, where the encryption key must be exposed to encrypt/decrypt data.
Clive Robinson • March 8, 2009 2:28 PM
@ Randy,
“In an apple to apple comparison, I have seen a vendor claiming 2X data throughput superiority over software encryption. Given the claim that encryption keys never leave the HDD, this aspect of security is stronger than software encryption”
I’m not sure if you actually mean that or not.
First off what are the threat models?
1, System powered off.
2, System powered up.
In the first case as the keys are on the drive the security depends only on how well they are defended. And this will in almost all cases be a physical access issue which on a comodity product is going to be very low.
For the software encryption as the keys (in theory) are not on the drive then it comes down to the security of the encryption method used.
In the second case if the drive is powered up and functioning when it is taken (Hot Snatch / hibernation) then it’s game over as (unless there is a specific driver) the data on the bus is in plain text and can be seen.
This is not as true of software encryption. For hot snatch a simple “inactive time” based key removal system could be implemented. Likewise when going into hibernation the last thing the software need do is remove the keys, and ask for them again on startup.
The use of transparent on drive encryption is somewhat limited at the best of times.
Even if I had it and “know” it is properly implemented I would still use software encryption on top of it.
Not due to belts and braces aproach simply due to the extra flexability software gives you to improve the security to cover other threat models that HD encryption cannot cover.
Randy • March 8, 2009 11:58 PM
@Clive:
On Feb 5, Dmitry Obukhov stated the single threat – data-at-rest mitigation, i.e., a stolen, powered off laptop. If you are mitigating additional threats, then I agree that SW encryption is appropriate and encrypting HDD is not a final solution.
For the data-at-rest threat, encrypting HDD has potential to be superior. Guessing from vendor claims, authentication data is input to a Key Derivation Function, which outputs encryption keys that could be held in write only registers. Implemented properly, an adversary would need $3-5M of specialized equipment for invasive attacks, and the population of adversaries would be significantly reduced.
Of course, should and could above depend upon vendor implementation. Perhaps HDD vendors will publish so that the community will be able to judge that these devices are not snake oil. An open specification is a good start, but it alone does not guarantee security. I agree with Bruce, Shannon and Kerckhoff: except for keys, a cryptosystem should be public knowledge.
Clive Robinson • March 9, 2009 6:21 AM
@ Randy,
I would contend that the main threat model against “current data” these days is not “data-at-rest”.
The two main threats are,
1, Hot Snatch
2, OS hibernation.
The first covers two types of people petty criminals who are more interested in the resale value of the hardware. And proffesional data takers such as US customs and industrial spy types, neither of whom will usually take the hardware (as that will trigger a security response).
The second problem is becoming a very very real issue. Due to the length of time laptops etc take to boot up more and more people are not turning them of and are relying on hibernation between power out lets.
Effectivly business execs etc have moved to the “always on” mode where “data-at-rest” does not happen very offten.
As I have said I have no problems with HD encryption it has it’s uses and at effectivly zero extra cost (ignoring key managment issues) I am happy to use it.
But due to “ease of use” or “efficiency” it is already to little to late.
And this is the big issue, security and efficiency almost always appear at oposit ends of the scales in that “the more you have of one the less you have of the other”.
Which brings me onto my other concern, to be “efficient” memory devices often have a random access model, not on data blocks but “data bits” this almost invariably means they use “stream encryption” which with most applications is going to be a bit of a disaster (stream reuse etc).
This mandates a conservative and carefull design which is not as likley to happen in consumer grade devices where the majority of people purchase on performance and marketing tick boxes.
Then there is the issue of key handeling, few people ever get this right there are so many gotchers in it that even “crypto experts” (if such an animal exists 😉 get it wrong.
Then there is the issue of “uniquness” and “true randomness” defficiencies in these areas are usually the “easy route” into real systems. Again people keep getting it wrong even though there is a well publisised track record of these issues.
But ultamatly because of the nature of these devices you cannot subject them to a full security audit due to “commercial confidentiality” and that will be their Achilies heel as long as real as oposed to faux security is required.
Anonymous • March 9, 2009 3:58 PM
Tempest issues? Many devices on a computer could compromise system, only need to transfer a snapshot to whoever over the net.
What is most disturbing about FDE, is the perception of solving the last mile problem of forensics, and empowering the police state. Lawyers are sure looking to profit on large number/data/copyright/patent/etc rackets.
TPM/FDE in the news again getting ready to release, see Slashdot/cnet on 03092009
Dave • November 4, 2009 5:50 AM
As one user already mentioned in vista it is possible to encrypt the pagefile (with a random key generated at boot time) out of the box.
All you need to do is to run secpol, public key policies, encrypting file system, right click, enable pagefile encryption.
Unfortunately this feature has been removed in windows 7. Does anybod have an idea why?
bit • March 2, 2010 11:40 AM
BitLocker is not safe, it’s easy to get the access to all encrypted partitions. See the following web page for more details: http://publicintelligence.net/microsoft-windows-7vista-advanced-forensics-guides-for-law-enforcement/ or http://cryptome.org/isp-spy/win7-bit-spy.pdf
David • March 5, 2010 9:39 PM
There is problem with Opal drives’ behavior coming out of sleep or hibernate. The problem is described at http://sharpesecurity.blogspot.com/2010/03/serious-usability-bug-in-tcgs-opal-hard.html
Foo • June 13, 2010 1:12 PM
Both GPG and built in FDE have pros and cons (I do prefer GPG) but there is a new class of device where FDE has a distinctive edge: SSDs that do compression, like ones with a Sandforce controller.
Doing any kind of OS side encryption for compressible data will impact device performance (in SF’s case decreasing it to up to about half the original throughput bandwidth) and write amplification, which has consequences for expected device lifetime.
These are currently enthousiast/enterprise products but will slowly become mainstream as the technology gains ground over classic HDDs.
Clive Robinson. • June 13, 2010 10:55 PM
@ Foo,
With regard to Sandforce (SF1222 SSD). based controlers apparently there are problems…
Superficialy they all appear the same but each drive manufacture can have their own “firmware” and some drives are failing under stress testing due to possible bugs…
Have a look at benchmarkreviws.com for more details on their testing of SF1200 based drives they have tried to get to the bottom of it unlike other review articles that just mention it in passing.
http://benchmarkreviews.com/index.php?option=com_content&task=view&id=531&Itemid=60
It does not bode well for Sandforce products.
Foo • June 28, 2010 8:32 PM
@Clive R.:
I own one and am familiar with the various firmware strategies/shenanigans (OCZ exclusivity for highest IOps, Corsair skirting this with a frozen RC version with power savings bug workaround; SMART bugginess, incompatibility with various laptop chipsets, bricking issues in combination with sleep states, lazy trim, no active GC etc.), but this is not the forum for that. As usual it will take a while to improve/stabilize.
The pertinent issue here is how new devices (SF only being an example) doing compression (and/or encryption of their own) change the question of using software FDE. From a performance/endurance point of view it matters greatly, even if CPU isn’t the bottleneck (or you can offload the encryption), simply because the encrypted data cannot be compressed like the original would be (and then encrypted by the device, possibly using the exact same AES algo as your FDE software).
As far as security is concerned I would vote for OSS ‘free as in speech’ transparency of software like Truecrypt/GPG, as far as common sense performance and corporate 80-20 usability vs. security is concerned not so much.
Clive Robinson • June 29, 2010 10:49 AM
@ Foo,
“I own one and am familiar with the various firmware strategies/shenanigans (…), but this is not the forum for that. As usual it will take a while to improve/stabilize”
Hopefully soon before the industry says “we can’t trust FDE on FLASH”
As you say,
“The pertinent issue here is how new devices doing compression (and/ or encryption of their own) change the question of using software FDE.”
Yes it boils down to being a question of layers in a stack, something that a lot of people don’t always pick up on.
Especialy when they don’t know enough about the various encryption modes. Or for that matter how the viewpoint of the data storage changes from just an infinatly expandable random access bit bucket “file” with hidden metadata in a “file handle” down to just sequentialy accessed fixed sized blocks of data “segments” that may or may not be independent of each other, and the attendant complex OS & file system dependant meta data structures (FAT, Inode, etc) required for their proper and efficient use.
Even fewer people actually look at how the random access nature of a HD storage medium can be best reconciled with the stream access assumptions with the traditional use of encryption, without making side channels or other “cracks” into which the tip of an attack wedge can be driven.
Further very few have actually talked about how encryption should be spread across each individual layer of the “bit bucket” to “segment” conversion of data and the attendant meta data generated by the process.
Which is important as it is the issues in this process that most effective attacks can be mounted. The usuall cop out seen is “single user” not “multiuser” secure access. Then the next being “recovery modes” that render the encryption almost worthless. And usually the almost total absence of prevention of files being writen under the same key etc. All of which might be fine on a single user laptop but is not very much use for secure multiuser systems.
For instance the NSA solution to FDE effectivly works only at the segment level and ignores all the layers above it. The actual reason for this is unknown publicaly but as you say,
“From a performance/ endurance point of view it matters greatly, … simply because the encrypted data cannot be compressed like the original would be”
Thus the “closer to the platter” the encryption is the more general purpose it is as it is not tied to any particula files system or it’s meta data.
However it also tells us a little about the threat model the NSA assumed and worked to. Which boils down to “single loss of HD at rest” with no crypto key.
That is there is a major assumption of proper crypto handling of the HD, not the more usuall business model insider threat where an attacker could get access to the “HD at rest” on a daily basis thus have a number of images from which to draw deltas from which a number of attacks could be mounted.
Then there is the issue of “performance”, usually the fastest encryption and that which can maintain the highest throughput is “stream encryption” with “pre computed keys”. Obviously this has a serious issue if two time seperated disk images are known to an attacker. As the simple dfference between them is two XORED data streams which often are not to diffcult to disentangle (especially when the file formats from the likes of MicroSoft contain huge lumps of known plaintext…
As always there will be a difference of opinion about Open -v- Closed software not just at the code level but throughout the entire design process.
My personal choice would be for a fully open design, preferably based around a “plugable module framework” with very clearly defind API’s all of which had gone through an open standards process with input from both the closed proffesional world and the open academic and business world.
FOSS has shown it is possible to earn a respectable income from Open development and implementation processes so there is little real advantage in Closed development for the ordinary / business end user.
mart • September 13, 2010 3:41 PM
Sandforce claims AES encryption.
But how can the user set the password?
Some speculate it can be done via ATA Pwd:
http://www.semiaccurate.com/2010/05/03/sandforce-ssds-break-tpc-c-records/
but i doubt that..
OCZ says you need their toolbox:
http://www.ocztechnologyforum.com/forum/showthread.php?71788-Sandforce-encryption-info
which does not exist ’til now..
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
John Ripley • February 5, 2009 7:46 AM
I think that sadly this has more to do with DRM than user protection.
It doesn’t add any value to the user, and if anything takes value away (as Bruce touches on). You can already cheaply, easily, and without any performance degradation perform whole-disk encryption.
If it doesn’t add value to the user, and involves encryption in the wrong place, then it’s a good bet it’s main market is for DRM. Actually, that pretty much defines DRM.