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."
Disk vendors are free to choose (Score:5, Insightful)
Why should this be trustable?
Re:Disk vendors are free to choose (Score:5, Insightful)
that is true, Defective by Design. (Score:3, Insightful)
I thought this kind of talk was over the top, then I read the article.
No reset so that you can repartion the thing? Users are supposed to trust the hardware won't betray them? No way. It's
Re: (Score:3, Insightful)
Re: (Score:2)
Warmer... warmer... warmer...
Who would find this an appealing alternative to the status quo?
Re:that is true, Defective by Design. (Score:5, Insightful)
Re: (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: (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
Re: (Score:3, Informative)
It is my understanding that modern OSes which are follow the ATA standards will issue the security freeze during hardware probe. At least, my *BSD systems do, and I've seen indications that even Windows does.
This doesn't matter. I've seen my share of odd virii living inside of the boot sector.
A particularly clever virus or trojan could even go forth and re-write the BIOS to disable the "security freeze" function you speak of. It sounds far-fetched, until you realize that BIOS code is generally written in
Comment removed (Score:5, Insightful)
OTOH, a reason to trust (Score:4, Insightful)
I'm not as worried about that as some. Here's how I look at it - if there's a back door, it doesn't matter as long as it doesn't get used. If it gets used even a few times, word will get out. When some ring of baby-rapers gets caught and prosecuted with evidence that was obtained through said back door, word *will* get out.
So what happens then? A million drive purchasers demand their money back. A million businesses that bought the drives because they were guaranteed unbreakable encryption join in class-action lawsuits against the drive manufacturers and resellers, blasting them into legal oblivion.
If I were a drive manufacturer, I wouldn't risk it. The secret would eventually leak and my company would be toast, overnight.
Re: (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: (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:5, Informative)
If you read further down, it says you can do a global reset, which loses the key and unlocks the disk as full of encrypted garbage, "with a few keystrokes".
Re: (Score:3, Insightful)
I think they're basically modernizing the old ATA security lockout, as made popular by the original Xbox. I do agree it's rather domineering to not include a "clear password" option. Sure, you'll lose the encryption key and the data is lost, but I'd much rather have a blank drive than a bricked one. This sort of draconian "security" is a sysadmin's nightmare, as now you can't just reimage a drive any old way, you have to reimage it in the target PC. If that board dies (as Dell/HP machines just love to d
Re: (Score:2)
Re:Disk vendors are free to choose (Score:5, Insightful)
Why not just use TrueCrypt? (Score:5, Informative)
Re:Why not just use TrueCrypt? (Score:5, Insightful)
Re:Why not just use TrueCrypt? (Score:5, Insightful)
Specialized hardware will always be faster and use less power to do a specific job than general-purpose hardware like your CPU.
Not "always", and not "and".
Specialized hardware will usually be faster than the CPU, and will usually yield an overall faster system by virtue of the fact that the CPU is free from those tasks.
However (and purely as an example), Linux's software RAID is faster than many hardware RAID controllers, and a system lacking a dedicated hardware RAID controller very well may use less power than an equivalent system with one.
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: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.
Bullshit. RAID5 is fine in read only file systems. (Score:3, Insightful)
Read about where the bottlenecks are before suggesting nonsense.
Re: (Score:2)
I thought it was a fact that dedicated hardware (properly designed) is ALWAYS faster than software.
I plead ignorance here as I don't know much about RAID but I wonder if the reason software raid (can) be faster is because they have poorly implemented drivers? Or conflicting design with how Linux operators?
If this is in fact not the case would you perhaps point me to further evidence of such cases as I think I would find it very interesting.
Re:Why not just use TrueCrypt? (Score:4, Insightful)
The best RAID coprocessors are made by companies like Intel and AMD. You can find them under names like "Xeon" or "Opteron".
Shamelessly stolen from Alan Cox.
Re: (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 hund
Re: (Score:3, Funny)
The vast and growing chasm between CPU power and the crunching needs of personal computing have rendered this argument obsolete. Please upgrade to MS Arguments 2009, or the open source alternative, OpenMouth v0.9b3
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]
True Crypt Source (Score:5, Informative)
http://www.truecrypt.org/downloads2.php [truecrypt.org]
Source Code ?
I have not compiled it, nor gone through it in detail, but it looks like source code to me.
D
Re:True Crypt Source (Score:4, Informative)
Re: (Score:2, Informative)
What' is this then ?
http://www.truecrypt.org/downloads2.php [truecrypt.org]
Source Code ?
I have not compiled it [...]
I have. It works.
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: (Score:2)
Re: (Score:2)
does it false-positive on simple compressed files, too?
Re: (Score:2)
Pffht, just means you haven't uncovered the keys I used when I altered the /dev/urandom generation source to output my TC volume. What better way to protect your data than to mirror it in every *nix computer on the planet?
Re: (Score:2)
Because pre-boot system partition encryption only works on x86/x86_64 and only for Windows [truecrypt.org].
They've thought about that. (Score:2)
CPU cache turned off when entering password.
Re: (Score:3, Insightful)
A standard is a good thing. Assuming you can get at the encrypted blocks, this makes it possible to *test* that a certain implementation is conforming to the standard. This gives better guarantees than simply to trust the undocumented, untested encryption invented by some manufacturer.
There can be bugs in the standard, offcourse, but it's going to get heavy scrutiny by very competent crypto-heads, so any obvious mistakes should be discovered quickly.
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: (Score:2)
I see you've used HTTPS for Subversion, where the canonical implementation stores your passwords in clear-text in your home directory, and raising a concern about this gets you told "if your client isn't secure, you shouldn't be doing source control from it".
This makes explaining to people why you will not allow them to use the same passwords for Subversion on HTTPS as they use for their email and X logins a bit of a problem.
Re: (Score:3, Funny)
The SS?
1955 called. They want their bad guys back.
itsatrap? (Score:3, Insightful)
trust (Score:2)
You can't (Score:2)
You can't ever trust what you don't have access to. So you will need to do the encryption yourself, regardless of what else the device does. That's "user trusted encryption" which these devices simply cannot ever offer (unless you build it yourself).
Oh, and BTW, you can't really trust your CPU, either.
It's not an encryption spec... (Score:5, Informative)
... it's TPM glue for hard drives. The spec says almost nothing about encryption and authentication, it's just a bunch of TPM command and control mechanisms for hard drives. The IEEE P1696 working group is the one working on secure hard-drive encryption. Unfortunately the TPM people have better PR people than the CS and EE types doing the IEEE work do.
Re:It's not an encryption spec... (Score:5, Informative)
Re: (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?
Re: (Score:2)
Anybody out there know if this will automatically use the aes engine in my geode lx if I turn this on? It would be a neat feature for a webpad, for sure. Especially one with no swap to mess things up.
Re: (Score:2)
So you mean that the CPU should send the data to the drive for storage, the drive should then encrypt it by sending it back to the CPU, and the CPU should then send it back to the drive a second time, but now encrypted? Sounds like some part here is unnecessary...
Seagate's stragegy.. (Score:5, Funny)
Re: (Score:2)
Hah! Why did you have to go and post anon?
http://support.apple.com/kb/TA37301 [apple.com]
They key words (Score:5, Funny)
here are "on the PLANET". Looks like they've got a bit more work to do before EVERYONE agrees to do this.
Dumb Question (Score:3, Interesting)
Re: (Score:2)
But if the encryption is in hardware, then it better be interoperable! Otherwise, imagine if you had to substitute an odd brand in order to rebuild an encrypted RAID array, even if just for emergency purposes. If the encryption were in hardware, and the implementations were not de facto identical, then it wouldn't work.
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.
Re:Pardon my ignorance (Score:5, Insightful)
The risk is that the drive may, unbeknownst to the owner, cache and store the encryption keys somewhere inside the drive, either on the media or in nonvolatile memory, making it available to those that know where to find it.
Even if the standard drive firmware doesn't do that, how would you know that the firmware of the drive wasn't modified sometime after manufacture and before purchase to install such a back door?
If you were an agent of some government that wanted to be able to access data on disk drives whose owners believe them to be encrypted, what better way to do that than to either convince the drive vendors to install a back door for you, or to let you tamper with the drives at some point in the process? That would eliminate a whole lot of hassle for you, and there are only a few drive vendors you'd have to subvert.
I think I'll stick to LUKS and dm-crypt. It's not a perfect solution, and it's still possible that someone could subvert my encryption, but doing it in the software I have some measure of control over clearly makes it harder for them than doing it in hardware that I have no choice but to trust blindly.
Am I paranoid? Sure. Probably no one is trying to steal my keys or my data. But the likelyhood of the existence of a back door has NOTHING to do with whether the bad guys (or maybe the good guys?) are interested in my data. Even if no one intends to steal my data today, once a back door exists it can be used against me in the future.
Re: (Score:2)
I don't know LUKS but TrueCrypt has been as solid as anything, and I really don't need full-partition encryption anyway which seems to be a weak point in this field. At least with TrueCrypt, they generally have to guess even what algorithm(s) you used.
Re: (Score:2)
Yes this is all true (Score:2)
Obviously (though some companies still don't get this), "security through obscurity" is a waste of everybody's time. TrueCrypt, while not "open sou
Re: (Score:2, Informative)
Re: (Score:2)
It's almost a certainty that HDDs keys are being sent to deh gubbmint, allowing them to read data that nobody else can. Making whole-disk encryption easily available, however, still provides a security benefit since in most cases, companies want to prevent the stupid breaches that you hear about incessantly: >9000 credit card numbers were found to be compromized today when l33t megacorp exec's laptop was lost...
In these cases, the use of encryption prevents them from having to say: "Aw shucks, geez, we'r
Re: (Score:3, Insightful)
Yes. But even more important to bear in mind is Bruce Schneier's admonition that security is a process, not a product. Far too many people will buy these FDE disk drives, and then blindly assume that since they have bought "security", don't have to do anything else, and that their problem is solved.
That's not a criticism of FDE; it happens with every kind of security-related hardware and software. Howe
Tomorrow's headline... (Score:4, Funny)
Universal Disk Encryption Spec Cracked. Available on 0dayz haxx0r b0ardz!!!
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: (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
Re: (Score:2)
Re:Do STD's make it easier to 'see' encrypted disk (Score:5, Insightful)
This use-case is more or less dying out though. Because transporting bits across a border by having someone hand-carry them is just too large a risk, assuming it's the kind of bits the government of either country would rather not have crossing the border.
Much better to transmit the bits out, in encrypted form, over some kind of network. Even if there's no internet, you can always do it over satelite-phone or something. Yeah, I know that's like $3/minute, but how many minutes do you need to transmit the ascii-text of an interview or something ?
It's sligthly more of a problem if it's something largish, particularily if it's HD-video though, but even this problem is going away. Even if you're in Iran, it's not very hard to find an access-point with a megabit or more of capacity.
There's no question; the safest way to store "dangerous" bits on your laptop while crossing a border, is to NOT store them on there at all. They can't find what is genuinely not there.
Re: (Score:2)
They can't find what is genuinely not there.
If they're properly motivated to find something on you, I'm sure they'll find something on you even if it's not there.
Re: (Score:2)
Not information. If they are trying to find out, for example, which government official revealed secrets to you, if the name isn't on your computer they won't find it. They can make up charges against you, sure, and even plant whatever they want on your hard drive. But it won't get them any closer to finding the leak. In that sense, they truly can't find what isn't there.
Re: (Score:2)
Truecrypt is awesome for this. Full disk encryption plus a hidden encrypted partition.
You put in one password you get a dummy install you use to trick them. Just a bare bones windows xp with some files on it. You put in the second password and you get your real OS with all your important data.
Passwords for harddrives (Score:2)
There was (still is) a possibility to set a password for hdds. It was in the news, because it was not possible to get to the data if you couldn't remember the pw. So it was advised to set it or disable it. Because if a malware got to it first they could set some random password and you would have no access anymore.
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: (Score:2)
As I understand it, at least with the recent Seagate 7200.11 fiasco exchanging the board no longer works on newer hard drives.
Re: (Score:2)
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: (Score:3, Informative)
That was called 'Trusted Computing', and formerly it was called 'Palladium'. It's a toolkit built into some modern motherboards to do robust encryption, and authentication, and most especially DRM. And Microsoft planned to be the root authority for signing and issuing keys, and storing the private keys "for recovery and law enforcement purposes".
Be very, very frightened of any such approach of storing centralized keys.
Re: (Score:3, Interesting)
Re: (Score:2)
That's one reason.
Re: (Score:2)
We have people with password protected documents. These people leave and their replacements need the password.
We have several brute force tools at our disposal to unlock these documents. We throw this on our VMWare cluster and let it run until it finds the password.
The government has at it's disposal some of the worlds fastest computers. Leaps and bounds quicker than anything consumers have.
If they can get your files, they can brute force the encryption open. The weakest link is your password. They c
Furthur "Edition" Separation (Score:2, Informative)
It looks like they're using the "Opal" standard as a way of selling essentially the same hard drive slightly crippled since if you don't have the key for the thing you "can't even sell it on eBay", whereas admins can "cryptographically erase" their data with ease. Does this mean that the well priced one has a one-key no-reselling system, and the artificially inflated "server" class one can be rotated? I'm going to ere on the side of "companies get together in order to hurt us all" and fear the worst.
Put your own encryption on top of the drive's... (Score:3, Insightful)
Nothing says you can't use Truecrypt or what have you on top of the hardware-based encryption built into the hard drive.
This way you'll have AT LEAST as much protection as you would've with just your software-based encryption.
How long... (Score:2)
This sounds like one of those things that have a few potential nice features, but can also turn into a big can of worms. Good luck explaining to grandma why there's no way she can get any of her files back, even though technically they're still there.
Re: (Score:2)
How long until the first trojan comes along that password-protects your drive for you with a random password, irrevocably locking you out? 'Universal' interfaces can have drawbacks as well.
Great, now that you gave them the idea it will only be about 10 minutes. That knock you just heard on your door is from the Department of Homeland Security. :)
They even agreed on the standard key (Score:2)
And the encryption key is standard also, it's:
f81ce859f77fa8a773d66d538ba7ad3daa1185d8
Short-sighted. (Score:3, Insightful)
How short-sighted is it to tie into one encryption standard? Idiots.
You need to *at least* make various encryptions pluggable and software-upgradeable because I guarantee that Murphy's Law says that once EVERYONE has one of these hard drive, AES will be cracked sufficiently and we'll be back to square one but tied into millions of devices incorporating a useless and obsolete security "standard. It'll be WEP all over again, even down to 99% of people being "assured" that their hard drive is safe, and then finding out the reality.
Plus, the DRM potential is obvious. I thought the ATA standard had the facility to implement disk encryption anyway - isn't that one of the features used on the XBox or something to lock the hard drives to a particular machine? - you have to send a password across the bus as an ATA packet before the drive will permit any access at all.
I'm sure it's been taking care of... (Score:2)
...but you can never be to careful so: Remember to include the CIA backdoor guys! Thanks!
PS: Tinfoil won't protect you from it!
128-bit -vs- 256-bit (Score:3, Insightful)
"Disk vendors are free to choose to use AES 128-bit or AES 256-bit keys depending on the level of security they want"
More likely, they will choose based on the power of the controller. Nobody would want less security.
Who is asking for this? (Score:2)
Disk firmware is a lame place to put this functionality, compared to the OS. When a bunch of vendors are working on a solution to a problem that no user has, beware. They aren't offering a feature; they are offering us a trojan.
Re:ok (Score:5, Funny)
Re: (Score:2)
Just phone in a threat to an elected official, and the NSA will unlock the drive remotely for you. A handy service, and so responsive...
Great tip. This will solve all my current problems.
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re:A few questions... (Score:5, Insightful)
Re: (Score:3, Interesting)
Re:A few questions... (Score:5, Insightful)
And yet, somehow I don't believe you.
To be more specific, I find it illogical to assume that the NSA would require you to provide them with the keys and at the same time let you talk about it.
Given this, I am suspicious of your claim in the extreme.
Re:A few questions... (Score:5, Funny)
clampolo?
Re: (Score:2)
If the keys are burned in, are they then supplied to the various law enforcement agencies to make things easier on them?
No need. A list of all possible encryption keys can be generated easily, and they've been told how to do this. They just need to try them sequentially...
Re: (Score:2)
encryption key management applications...
I'm supposed to trust my crypto keys to a third party?
Man, it's all about you, isn't it.
This sort of shit is _really_ useful in a business, where the business security people have a master key that they can use to recover your data when you forget your password (yet again).
You might even have a friend or family member that you trust enough to keep a separate key that can read your data if you screw up your passwords or, y'know - DIE. So that your descendants don't l
Re: (Score:2, Offtopic)