Universal Disk Encryption Spec Finalized 237
Lucas123 writes "Six of the largest disk manufacturers, along with encryption management software vendors, are backing three specifications finalized [Tuesday] that will eventually standardize the way encryption is used in firmware within hard disk drives and solid state disk drive controllers ensuring interoperability. Disk vendors are free to choose to use AES 128-bit or AES 256-bit keys depending on the level of security they want. 'This represents interoperability commitments from every disk drive maker on the planet,' said Robert Thibadeau, chief technologist at Seagate Technology."
Dumb Question (Score:3, Interesting)
Re:It's not an encryption spec... (Score:3, Interesting)
You're right, sorry, typo while trying to get first post :-). Their home page is here [siswg.net], and they've had their specs out for nearly two years. How can any group that has an official Wine Tasting Standing Subcommittee be a bad thing?
Pardon my ignorance (Score:3, Interesting)
What good would hardware encryption be unless we were pretty well assured that even the NSA would be stymied?
It is not a matter of doing anything illegal, of course, but encryption is encryption. If there are reasonable methods available to break it, then it ain't.
Do STD's make it easier to 'see' encrypted disks? (Score:3, Interesting)
So, do[es any of] these standards make it easier for a gov't or other organization to notice that someone (eg, a journalist) has got his/her data (eg, article, photo's, interview audio, important video clips, etc.) encrypted on a device, ie, as they try to sneak from, say, within a war zone (closed to journalists) back to friendly soil?
If so, which encryption software (eg, Trucrypt, etc.) - that DOESN'T adhere to standards - will save this journo's life and/or media, in the above situation?
Re:Do STD's make it easier to 'see' encrypted disk (Score:3, Interesting)
You're kind of missing the point. If our hypothetical journalist is caught crossing a border, the guards won't pull the hard drive and check the make, and then hook it up to their own gear to see if it's encrypted or not. They'll point their AKs at the journo and make him turn his laptop on. If he refuses, they shoot him. If it prompts for a password and he refuses to enter it, they shoot him. If he claims he forgot the password, they'll toss him and his laptop into the back of the truck to send him to the capital to receive 'enhanced interrogation'. No encryption software will save his life. The guards probably won't know or care about encryption.
If I were that journo, I'd encrypt the files themselves and rename them crash.dump and put them in the Windows directory so I can turn it on, let them scan for jpegs and avis and find nothing, and be sent on my way.
Well if data isn't encrypted ... (Score:3, Interesting)
If the password protection is only blocking the drive's firmware, but the data is not encrypted on disk, it's a very weak protection. Someone stealing your disk only has to find a disk of the same model, and exchange the platters.
Re:Why not just use TrueCrypt? (Score:4, Interesting)
from: http://www.reddit.com/r/programming/comments/7otuy/who_wrote_this_software_an_excia_agent/ [reddit.com]
Problems abound... (Score:4, Interesting)
If someone has Truecrypt on their hard drive and the police raid your house for some server and they take that encrypted drive, there is nothing stopping you from saying, "I forgot my password... oops." But if you trust the hardware, then what stops the police from going after that hard drive manufacturer and putting the legal pressure on them to provide a back entrance and/or technical help? The idea that the government won't put a legal squeeze on the hard drive manufacturer the second they think they've come upon a child pornography/warez/other horrible illegal things seems absurd to me. I understand that manufacturers of things like flash drives and such have had hardware encryption before, but it hasn't been widespread and mainstream. When you throw in the "average citizen" factor, I think we'll see all kinds of challenges and laws spring up.
-- And as always IANAL, but I do read Slashdot!!
Re:A few questions... (Score:3, Interesting)
Re:Why not just use TrueCrypt? (Score:5, Interesting)
Speaking from experience, this seems to be true only of the 'fakeraid' setups that you see on cheap RAID controllers, which aren't really hardware RAID at all. They cheat and instead use firmware that executes on the main CPU to do the RAID, making them no better in principle and more often than not worse in performance than the Linux kernel's heavily optimized high-performance software RAID implementation. True dedicated hardware RAID controllers, such as the HP Smartarray, IBM ServeRAID, and the RAID controllers you see on fiberchannel SANs, are actually quite rare except in enterprise setups, and they are in general much faster than the Linux software RAID implementation.
But of course, nothing stops a manufacturer from doing bad engineering and making a product that has a dedicated piece of hardware that actually does the job slower than the main CPU would. And performance is not the only reason to make a dedicated hardware implementation of some bit of functionality. It could be done for "trusted computing" purposes for instance, in which case, it doesn't matter that it's slow, just that it keeps control out of the hands of the main CPU.
Re:Disk vendors are free to choose (Score:4, Interesting)
I think we can fully trust manufacturers to take a shortcut and implement this as dual ROT-13 encryption, perhaps with a delay thrown in to make it seem like it's doing something. How would the average user determine whether the magnetic patterns on the disk are encrypted anyway? This seems very similar to the issue with electronic voting machines, only worse. Encryption on the host machine seems far superior, since the data is never traveling over the I/O bus unencrypted, and it's much easier to verify that the data is actually being encrypted.
Re:Why not just use TrueCrypt? (Score:4, Interesting)
True dedicated hardware RAID controllers, such as the HP Smartarray, IBM ServeRAID, and the RAID controllers you see on fiberchannel SANs, are actually quite rare except in enterprise setups, and they are in general much faster than the Linux software RAID implementation.
Smartarray is dead slow for RAID5, and RAID1 in software doesn't tax the CPU. RAID controllers are only worth it because it can be hard to get Linux booting reliably from a software RAID 1 with a failed disk. As for RAID levels other than RAID1 and RAID10, don't.
Re:Why not just use TrueCrypt? (Score:2, Interesting)
Hardware raid is not always faster than software. Often the opposite is the case. However, speed is only one factor, the other is CPU offloading.
If you are running a CPU-heavy computation, I/O speed is not so much the important thing, as making sure that every CPU cycle is available for the computation.
However, if your main bottleneck is I/O, the main CPU can do a lot more "raid-stuff" than the much slower CPU on a raid card. While the main CPU may be 3 GHz, 8 core, the RAID one may only be a couple of hundred MHz with a passive heat sink. You don't see a lot of raid cards with a 3 GHz multicore CPU where the heat sink and fan will block the five adjacent slots.
Comment removed (Score:3, Interesting)
Re:OTOH, a reason to trust (Score:3, Interesting)
Nah, the company would probably just make sure that the word doesn't get out. And if it does it would be seen as some whack job on Slashdot who thinks only F/OSS can be trusted. Just so there is no confusion here, I'm one of those whackjobs. Proprietary disk encryption is just a universally dumb idea.
Re:Why not just use TrueCrypt? (Score:4, Interesting)
All TCHunt does is look for random data. If you append 100MB of /dev/urandom to a file and run TCHunt, it will "recognise" it as a TrueCrypt volume.
This is not a secret. This is how encryption works. Obfuscating your data inside a apparently plaintext structured format is called stenanography and is another subject entirely.
The changelog is here [truecrypt.org]
Discussions on using CVS and other version control are scattered throughout the forums without apparent quoshing by the admins. Yes, old versions of the source are not available - unless you already downloaded them, of course.
The MD5 hashes changing for the installer was just that - they rebuilt the installers with some of the new setup (like offering the option to disable the pagefile) from the version 6 installers, but the binaries inside remained identical. Doing this is rather poor practice because it raises this sort of question, but hey, you trusted the first file signed with their PGP key, why not the second? The TCHunt guys have an archive [16systems.com] of old TrueCrypt versions, but they won't let you download them now for bandwidth reasons ; it might be illuminating to pick through the various MD5 versions and compare the actual binaries installed.
If someone is concerned about back doors, they can audit the code, and build it themselves. (don't respond to this with the Ken Thompson compiler back door proposition). Undoubtedly there are people that do this, although they are not equipped to sign their builds with the TC foundation PGP key.
As a popular encryption soft, I have no doubt it comes under scrutiny. I might trust it a mite more if it was signed by Bruce Schneier's key though :-)
Re:OTOH, a reason to trust (Score:3, Interesting)
That's a nice idea, but about as accurate as the idea that "Banks will self regulate because it's in their best interest". It's already well known that the NSA had a backdoor into Windows encryption, and that doesn't seem to bother anyone.
Re:that is true, Defective by Design. (Score:3, Interesting)
That's a meaningless question. A trojan can encrypt using software or hardware. This technology doesn't make any difference to trojans whatsoever. Your data is just as encrypted.
This is why the word "owned" is used when a trojan takes over. It can do anything it wants with your data.
Re:that is true, Defective by Design. (Score:3, Interesting)
There is a bit of a difference.
In the standard current case you would need to read-encrypt-rewrite all several hundred gigs of the drive. I would guesstimate that would probably take over an hour to complete. If you realize something is wrong you could simply hit the power button and nearly all of your data will still be retrievable.
With this system all of the data is encrypted. If I'm understanding the system correctly the owner is forbidden to know his encryption key. The system maintains a list of access profiles, you enter your password linked to your access profile, and then the drive internally generates or accesses the actual encryption key. Malware could potentially create do something like creating new access profile locked to some new password, and then delete or reset your access profile. That would involve only a few dozen bytes of data, and it would be completed almost instantaneously. All of your data is effectively destroyed instantaneously, unless you can get the unlock code from the attacker.
-