Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Universal Disk Encryption Spec Finalized

timothy posted more than 5 years ago | from the surely-will-foil-the-nsa dept.

Your Rights Online 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."

cancel ×

237 comments

Sorry! There are no comments related to the filter you selected.

Disk vendors are free to choose (5, Insightful)

SpaceLifeForm (228190) | more than 5 years ago | (#26649743)

What about the owner?

Why should this be trustable?

Re:Disk vendors are free to choose (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26649783)

The drive is "trusted" because the "owner" isn't.

that is true, Defective by Design. (3, Insightful)

twitter (104583) | more than 5 years ago | (#26650125)

I thought this kind of talk was over the top, then I read the article.

The specifications enable support for strong access control and, once set at the management level, the encryption cannot be turned off by end-users. ... it can't be brought back up and read without first giving a cryptographically-strong password. If you don't have that, it's a brick. You can't even sell it on eBay."

No reset so that you can repartion the thing? Users are supposed to trust the hardware won't betray them? No way. It's like they are trying to clog landfills with these things.

The whole article reeks of "trusted path" and other defective by design tech beyond the obvious "oops, I forgot the password" inevitability. To be trusted by sane users, the controller boards must come with easy to change free software doing the dirty work. If not, all sorts of malicious features can be hidden that negate all benefits of hardware encryption. These things could turn themselves if "premium" content is ever placed on the drive and then accessed with a "non trusted" OS, for example. Your data is never secure when you use non free software, it is always at the mercy of the software's owner. This kind of "firmware" is something that should be rejected.

Whoosh (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26650343)

Ladies and gentlemen, get your tinfoil hats here! BYO paranoia and total lack of knowledge about the topic!

Re:Whoosh (1)

pipatron (966506) | more than 5 years ago | (#26650955)

In this case, you seem to be the one without any knowledge. Ask any security expert about something called "security by obscurity" and see if that's a good thing.

Re:that is true, Defective by Design. (3, Insightful)

palegray.net (1195047) | more than 5 years ago | (#26650437)

I sincerely hope this post isn't being modded "-1" simply because is belongs to Twitter. In this case, he's absolutely right. Why the hell would you trust a third party to provide trusted firmware code that manages crypto keys for your organization without access to the source that makes up said firmware? You would be an absolute idiot to take this path, and probably accused of criminal negligence should improper data disclosure ever reach the point where a federal prosecutor got involved in a case where the data in question "Really Mattered."

Re:that is true, Defective by Design. (5, Insightful)

Lucky_Norseman (682487) | more than 5 years ago | (#26651203)

What prevents a trojan from turning on encryption "at management level" thus holding all your data hostage until you pay up for the key?

Re:that is true, Defective by Design. (5, Insightful)

hairyfeet (841228) | more than 5 years ago | (#26651549)

As much as I hate to say this, don't mod him down simply because he is twitter, because in this case he has a point. Why would you trust some large corporation not to hand the keys over to any government upon request? Why would you trust them not to have a back door installed, if for no other reason than to save on support costs when the "dee dee dees" lose their keys and call tech support? And if there is one place I would WANT the source code available it would be crypto. There are plenty of FOSS encryption programs out there where crypto experts have gone over the code with a fine tooth comb looking for weaknesses, simply for no other reason than they themselves use it. But I am supposed to ignore all that work for this stuff cooked up by three mega corps and with no source code and just a "trust us" that there isn't a back door?

So while you may not like twitter and his "M$" rants(please use MSFT twitter, the M$ thing is annoying) I'm afraid he has a very good point here. We have seen absolutely NO reason why we should trust this, and we have every reason not to. And when it comes to keeping important data secure from prying eyes I want to see the code. While I myself won't be able to make heads or tails of it I'm sure that there are plenty of crypto guys than can and will. So for me no source equals use Truecrypt. At least I know it doesn't have built in back doors.

Illin with the Panicillin? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26649813)

Is she illin in the panicillin?
Is she chillin in the panicillin?
Is she stealin in the panicillin?
Is she feelin in the panicillin?

Panka panka

Is she liable no suitifiable pliable style is so suitifiable
Is she liable no suitifiable im not on trial but its suitifiable
Is she reliable no suitifiable not just viable but real suitifiable
Is she try-able no suitifiable lying in the aisle im real suitifiable

Is she spillin in the panicillin?
Is she squealin in the panicillin?
Is she feelin in the panicillin?
Is she trillin in the panicillin?

Panka panka

Is it libel? no suitifiable pliable style is so suitifiable
Is it a style? no suitifiable im not on trial but its suitifiable
Is it a mile? no suitifiable not just viable but real suitifiable
Is it wild? no suitifiable lying in the aisle im real suitifiable

Re:Illin with the Panicillin? (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#26649829)

Go and learn to spell then come back and try again.

Re:Disk vendors are free to choose (4, Insightful)

Kamokazi (1080091) | more than 5 years ago | (#26649851)

It's a standard for hardware encryption so you don't have to worry about interoperability. If you're that concerned, load up Truecrypt and pick what you want.

Why not just use TrueCrypt? (5, Informative)

Futurepower(R) (558542) | more than 5 years ago | (#26649913)

Why not just use TrueCrypt [truecrypt.org] pre-boot system partition encryption [truecrypt.org] ? The benefit of a hardware standard is not immediately clear to me.

Re:Why not just use TrueCrypt? (5, Insightful)

PitaBred (632671) | more than 5 years ago | (#26649991)

Because the hardware standard doesn't use your CPU for the encryption and decryption? Specialized hardware will always be faster and use less power to do a specific job than general-purpose hardware like your CPU.

Re:Why not just use TrueCrypt? (5, Insightful)

MSG (12810) | more than 5 years ago | (#26650039)

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? (0, Offtopic)

dfn_deux (535506) | more than 5 years ago | (#26650377)

I wish I had a mod point for this, but mine expired yesterday. This is true and insightful and exactly the sort of comment that slashdot needs to see more of.

Re:Why not just use TrueCrypt? (5, Interesting)

dido (9125) | more than 5 years ago | (#26650509)

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.

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? (3, Interesting)

amorsen (7485) | more than 5 years ago | (#26650889)

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? (1)

Wescotte (732385) | more than 5 years ago | (#26650513)

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? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26650615)

It's not that hardware raid is faster on $$ controllers, it's that its battery backed and makes it possible for the storage system to commit the transactions they have in the caches.

Re:Why not just use TrueCrypt? (3, Insightful)

amorsen (7485) | more than 5 years ago | (#26650901)

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:Why not just use TrueCrypt? (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26651157)

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.

Re:Why not just use TrueCrypt? (3, Funny)

MrNaz (730548) | more than 5 years ago | (#26650089)

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? (1)

troll8901 (1397145) | more than 5 years ago | (#26650599)

Also recommended are Lotus Humor for Humans 3.1 and IBM Common Sense for Humans 1.4 as well. Both closed-source unfortunately.

Re:Why not just use TrueCrypt? (3, Interesting)

Eighty7 (1130057) | more than 5 years ago | (#26650227)

No one knows who wrote TrueCrypt. No one knows who maintains TC. Moderators on the TC forum ban users who ask questions. TC claims to be based on Encryption for the Masses (E4M). They also claim to be open source, but do not maintain public CVS/SVN repositories and do not issue change logs. They ban folks from the forums who ask for change logs or old source code. They also silently change binaries (md5 hashes change) with no explanation... zero. The Trademark is held by a man in the Czech Republic ((REGISTRANT) Tesarik, David INDIVIDUAL CZECH REPUBLIC Taussigova 1170/5 Praha CZECH REPUBLIC 18200.) Domains are registered private by proxy. Some folks claim it has a backdoor. Who Knows? These guys say they can find TC volumes:

http://16systems.com/TCHunt/index.html [16systems.com]

For these reasons, I won't use it. Encryption is important and TC looks great and makes great claims, but TC should be more transparent.

from: http://www.reddit.com/r/programming/comments/7otuy/who_wrote_this_software_an_excia_agent/ [reddit.com]

True Crypt Source (5, Informative)

RationalRoot (746945) | more than 5 years ago | (#26650567)

What' is this then ?

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:Why not just use TrueCrypt? (0)

Anonymous Coward | more than 5 years ago | (#26650625)

I tried this util. using tc6.0a to create a 1GB file volume with a 512k hidden both of which were serpent-twofish-aes wrapped, tchunt failed to find it.

Re:Why not just use TrueCrypt? (1)

sdiz (224607) | more than 5 years ago | (#26651011)

I tried this util. using tc6.0a to create a 1GB file volume with a 512k hidden both of which were serpent-twofish-aes wrapped, tchunt failed to find it.

I guess you are using the alpha version?
http://16systems.com/TCHunt/alpha.html [16systems.com]

Only locates TC volumes between 15MB and 100MB in size. The only purpose of this is to limit the usefulness of the alpha version. Unrestricted versions of TCHunt search for volumes between 19KB and 1TB.

Re:Why not just use TrueCrypt? (1)

BuckoA51 (1119431) | more than 5 years ago | (#26650783)

All TC hunt seems to be doing is finding files with the .tc extension. That is something I can do in windows by opening the start menu and searching for ".tc"

Re:Why not just use TrueCrypt? (1)

wdef (1050680) | more than 5 years ago | (#26651139)

Use loop-aes: http://sourceforge.net/projects/loop-aes/ [sourceforge.net]

Its author (Jari Ruusu) frequents the email list and answers questions. Loop-aes is actively in development and has a changelog. It is highly stable and in general well-regarded.

If you want a wrapper to simplify use, even with multiple encryption, you could try my script tripl, which is about to get an update: http://tripl.sourceforge.net/ [sourceforge.net]

Re:Why not just use TrueCrypt? (1)

Cruicky (1122359) | more than 5 years ago | (#26651303)

It's a simple entropy scanner, nothing more. You can prove this by doing the following like I have done. Generate a 75MB file from /dev/urandom using dd, copy it to a Windows machine, then run TCHunt. It will find the file you made, even though it isn't a TrueCrypt volume.

Re:Disk vendors are free to choose (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26649943)

Well just know that there is no way this would happen without the FBI, SS, or CIA having ready access to the keys.

Re:Disk vendors are free to choose (3, Funny)

MrNaz (730548) | more than 5 years ago | (#26650095)

The SS?

1955 called. They want their bad guys back.

Re:Disk vendors are free to choose (0, Funny)

Anonymous Coward | more than 5 years ago | (#26650721)

Really? There is no such thing as the Secret Service [ustreas.gov] ?

High school called, they want your social studies grade back.

Re:Disk vendors are free to choose (2, Insightful)

Eivind (15695) | more than 5 years ago | (#26650355)

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 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26650669)

It's called competition. I know that if I led one of the six, I would ask my research development to periodically test if all the others are doing what they should. If not, I would make sure that everyone would hear about it.

Re:Disk vendors are free to choose (3, Interesting)

noidentity (188756) | more than 5 years ago | (#26650689)

Why should this be trustable?

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:Disk vendors are free to choose (1)

Antique Geekmeister (740220) | more than 5 years ago | (#26650995)

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.

itsatrap? (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26649747)

How can we trust their implementation?

trust (1)

Iamthecheese (1264298) | more than 5 years ago | (#26649761)

That information is not available. The PDF linked to as "the spec" is merely a press release, and the other linked documents aren't any better. It seems like they haven't really agreed.

You can't (1)

Skapare (16644) | more than 5 years ago | (#26650871)

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.

Re:You can't (0)

Anonymous Coward | more than 5 years ago | (#26651031)

I don't buy this "you can't really trust your CPU, either" argument. It supposes some advance malevolence that is able to ferret away data that "looks interesting?" (that's paranoid) Or are you just saying that the CPU might be making mistakes? (this would get noticed pretty quickly).

On the other hand, a hard drive might store the key somehow, and provide for some capacity to produce the key when provided some master password. This is a very real concern, unlike this CPU paranoia that gets thrown about.

Re:itsatrap? (0)

Anonymous Coward | more than 5 years ago | (#26651341)

at least on linux they use the native dm-crypt layer

It's not an encryption spec... (5, Informative)

(Score.5, Interestin (865513) | more than 5 years ago | (#26649753)

... 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... (1, Informative)

Anonymous Coward | more than 5 years ago | (#26649795)

That should be P1619, not P1696.

Re:It's not an encryption spec... (4, Informative)

this great guy (922511) | more than 5 years ago | (#26649823)

The parent poster made a typo in the IEEE project name. It's P1619 [wikipedia.org] . Their main full disk encryption spec is XTS-AES, and is currently implemented by the Linux dm-crypt layer (cipher name aes-xts-plain), and by OpenBSD. I have been using it for almost a year on my laptop.

Re:It's not an encryption spec... (2, Interesting)

(Score.5, Interestin (865513) | more than 5 years ago | (#26649855)

The parent poster made a typo in the IEEE project name. It's P1619.

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:It's not an encryption spec... (1)

drinkypoo (153816) | more than 5 years ago | (#26650141)

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:It's not an encryption spec... (1)

pipatron (966506) | more than 5 years ago | (#26650989)

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...

Re:It's not an encryption spec... (0)

Anonymous Coward | more than 5 years ago | (#26650105)

If you actually took a look at the spec, you'd realize that this has nothing to do with the TPM. The specifications released by the TCG Storage Workgroup indeed describe a command architecture. However, its sole purpose is to allow the owner to control access to ranges of LBA that he himself defined - typically mapped to partitions -.
Each of those LBA ranges is encrypted with an independent key by the drive hardware. Upon power-up, the user authenticates to the drive and unlocks the ranges he/she is interested in accessing.
This is solely for the purpose of protecting against data leakage in case of laptop/drive theft. As a side benefit, it also provides the user a quick way of erasing the drive by erasing a single cryptographic key.

Also, the work done in IEEE1619 to standardize the XTS mode is completely orthogonal to this work. The TCG specification allows drive manufacturers to use the XTS mode if they so choose...

My disk drives are made on Uranus (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26649767)

You insensitive clod.

Re:My disk drives are made on Uranus (-1, Troll)

Vectronic (1221470) | more than 5 years ago | (#26649815)

Those are rings around Uranus... .. . not discs... oh nevermind.

ok (1)

larry bagina (561269) | more than 5 years ago | (#26649769)

everytime you turn on your computer, you need to enter a password to access the hard drive. That's not going to work so well if your computer is sitting in a data center on the other side of the country.

Re:ok (0)

Anonymous Coward | more than 5 years ago | (#26649803)

What if your computer sits on your desk in your house?

Re:ok (0)

Anonymous Coward | more than 5 years ago | (#26650415)

Or within the duffel bag of a laptop-thievin' ninja?

Re:ok (5, Funny)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26649807)

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...

Re:ok (2, Insightful)

jandrese (485) | more than 5 years ago | (#26649817)

Hard drive encryption doesn't really offer much to a machine sitting in a data center though. The real value is on laptop hard drives where there is a much greater chance of having your machine stolen at some point. Built-in full disk encryption will help prevent the crook from getting at all of your data.

Re:ok (0)

Anonymous Coward | more than 5 years ago | (#26650755)

I disagree. It simplifies end-of-life data protection.

When the hard drive dies, or you discard the machine, you no longer have to physically destroy the drive to protect your information.

Re:ok (1)

yahwotqa (817672) | more than 5 years ago | (#26651179)

Such computer should be equipped with a remote console interface.

Seagate's stragegy.. (5, Funny)

Anonymous Coward | more than 5 years ago | (#26649789)

brick your hardrive. Now it's secure.

Re:Seagate's stragegy.. (1)

MrEricSir (398214) | more than 5 years ago | (#26650617)

Can I cut to the chase and just put a brick inside my computer?

I hope they make 3.5" bricks...

A few questions... (1)

Rog-Mahal (1164607) | more than 5 years ago | (#26649797)

When are drives conforming to this standard going to be available? Also, the article mentions using this type of encryption to, say, lock up a laptop and keep a kid from using it. That seems to imply that there will be some kind of user interface. Wouldn't the encryption keys be unwieldy and hard to remember? If it's baked into the hardware, what about swapping drives between machines? If users are able to create their own passwords, wouldn't these drives be just as crackable as any other?

Re:A few questions... (4, Insightful)

jamstar7 (694492) | more than 5 years ago | (#26649841)

If the keys are burned in, are they then supplied to the various law enforcement agencies to make things easier on them?

Re:A few questions... (0)

Anonymous Coward | more than 5 years ago | (#26650093)

If the keys are burned in, are they then supplied to the various law enforcement agencies to make things easier on them?

First hack will be to diddle the key so no one else knows.
 

Re:A few questions... (3, Interesting)

clampolo (1159617) | more than 5 years ago | (#26650401)

I worked for a company that shipped encrypted firmware. We were required to send the keys to the NSA.

Re:A few questions... (4, Insightful)

Atlantis-Rising (857278) | more than 5 years ago | (#26650577)

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... (0)

Anonymous Coward | more than 5 years ago | (#26650857)

Maybe the ninja watching his house went for a quick coffee break?

Re:A few questions... (1)

AliasMarlowe (1042386) | more than 5 years ago | (#26650537)

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...

They key words (4, Funny)

dmomo (256005) | more than 5 years ago | (#26649801)

here are "on the PLANET". Looks like they've got a bit more work to do before EVERYONE agrees to do this.

Dumb Question (3, Interesting)

sstpm (1463079) | more than 5 years ago | (#26649843)

Can any storage gurus explain the real-world benefit to this? Is it currently impossible to encrypt a RAID volume built on two different manufacturers' disks?

Re:Dumb Question (1)

Jane Q. Public (1010737) | more than 5 years ago | (#26650037)

No, not if you are using software. The idea here is to build encryption into hardware, so the performance will be vastly better.

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 (2, Interesting)

Jane Q. Public (1010737) | more than 5 years ago | (#26650071)

but has it been pretty well established that there are no significant backdoors, or backdoor techniques, related to the existing AES algorithms? I.e., 128 and 256?

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 (5, Insightful)

Eric Smith (4379) | more than 5 years ago | (#26650153)

The main risk isn't with weaknesses or back doors in AES, even though it's possible that there is an as-yet-unrecognized weakness.

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:Pardon my ignorance (1)

Jane Q. Public (1010737) | more than 5 years ago | (#26650327)

Those are certainly risks that I had not considered in advance. Encryption is obviously worthless if it can effectively be bypassed. I have made that point myself in other contexts (DRM), but didn't think about it in this case.

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:Pardon my ignorance (1)

dfn_deux (535506) | more than 5 years ago | (#26650417)

TrueCrypt suffers from much of the same blackbox behavior as the parent post explains with regards to this hardware encryption scheme. Open, Free, software based encryption is more secure in that it is open to analysis every step along the way, however it suffers from a different set of potential pitfalls that go along with crowd sourced designed by committee software. I'd choose the more open solution personally, but just because you have the source code doesn't mean that you or any other interested party has properly validated it against potential flaws in the implementation of even the most mathematically sound encryption. You all remember the recent fiasco with ssh key generation on debian based distros I'm sure.

Yes this is all true (1)

Jane Q. Public (1010737) | more than 5 years ago | (#26650815)

but in the end what it amounts to is trust. In general today, I would trust a private supplier of free software (that has been thoroughly examined in broad daylight by experts in the field), even if it is "proprietary", over something supplied by my government. Simply because in the case of the government, there is strong motivation to "fudge" things a little.

Obviously (though some companies still don't get this), "security through obscurity" is a waste of everybody's time. TrueCrypt, while not "open source", has still been willing to put up with open examination, and in fact has challenged people to break its security. I believe its credibility is pretty high. Which does not prove anything, of course.

I bet they'll ALL have major backdoors built in! (0)

Anonymous Coward | more than 5 years ago | (#26650085)

I bet they'll ALL have major backdoors built in!

Question: what are the SPECIFICATIONS for this, anyway? I've heard enough about drive resident crypto to be worried about things like secret specifications / implementations geared toward industries like DRM providers to help them "hide" / access control content on your OWN hard drive at the hardware level, backdoors, et. al.
q.v.
http://www.theregister.co.uk/2001/01/10/everything_you_ever_wanted/ [theregister.co.uk]

Presumably this AES implementation is different than the CPRM related link above, but it is moot if AES is considered secure / auditable of the details of how the drive itself stores / uses the secret key are not well assured. If the drive encrypts / decrypts the data onboard, it must have an API to receive and control the secret key and encryption parameters. Nothing at all would prevent a malicious implementation from keeping a copy of the secret key in FLASH or on a hidden spot on the disc surface or whatever. Full disclosure of the data encryption algorithms / keying scheme and an independent host software means to read the *encrypted* disc blocks and (in host software) duplicate the crypto algorithms would permit the host to be (somewhat) assured that the "on disc" data blocks were even being stored encrypted with the expected algorithms / formats. Although malicious firmware could simply read actually unencrypted data on the disc and encrypt it "as expected" for an auditing readback if it wanted to fool the reader. As long as the data surfaces are "black boxes" accessible only via this "black box" storage controller we really have no idea WHAT it is doing in a proper and trustworthy fashion.

Why would anyone really trust encryption done by a such "black box" piece of commodity hardware?

The temptation on the part of manufacturers is too great to have sloppy / weak / backdoored implementations due to pressures from sources like oppressive / intrusive governments, data recovery concerns / options for industry, et. al.

All the GSM phones have been intentionally weakened in their "security through obscurity" crypto algorithms to permit snooping. Even if there are "somewhat potentially secure" algorithms available for GSM, IIRC it has been established that they intentionally misuse them via keying / option choices to weaken the result and permit easy disclosure of the traffic if the operator / government desires. Intentionally or unintentionally the security of a lot of DECT telecom gear has basically been rendered moot due to bad design according to recent /. articles. Companies that get their security systems hacked (e.g. that recent mass transit / crypto card situation) would rather sue to quiet the news about the insecurity rather than be humbled / shamed and make a properly secure system.

Weren't several prominent secure USB / "secure disc drive" vendors exposed and found out to be using basically no actually useful security even the ones that claimed to be using AES actually WEREN'T in any useful manner encrypting anything?

Look at seagate in the news.. they practically have to be having millions of drives turning into dead bricks in a very public scandal before they'll even ADMIT they have a firmware problem and issue a firmware update to fix the problem. Is this the sort of company you want to TRUST to proactively audit / update crypto algorithms and systems whenever there's the slightest vulnerability found (I assume key disclosure / loss / data corruption vulnerabilities are most likely rather than failure to implement AES itself properly)?

What "consumer level" hardware actually DOES have effective security through cryptography using openly available / auditable algorithms and specifications? Next to nothing? GSM SIM cards -- intentionally weak, non-public algorithms / implementation parameters. "Smart cards" -- very often secret algorithms and / or critical implementation details are used to prevent public auditing of the actual security of the system. "Secure Digital" SD cards -- another proprietary "security through obscurity" algorithm that is undisclosed, and, worse, the crypto FUNCTION isn't even exposed to the OWNER of the device for their OWN data protection, it is ALL about DRM content control.
DECT -- more of the same insecurity. TPM modules -- still not common in consumer gear, and AFAICT their usage is mostly intended to be a tool to keep users OUT of their own PCs (e.g. used by DRM restriction systems and to prevent the user from 'tampering' with their own OS rather than to help secure the system according to whatever policies the end user actually wants.

So, really, what is left in consumer level hardware assisted crypto that isn't intentionally crippled, deeply flawed, or effectively untrustworthy due to lack of disclosure / usability of the actual implementations?

Isn't it in many ways an even bigger vulnerability to have your secret keys stored on a black box hard disc than to at least have some control of them in a host software implementation since now one must trust BOTH the host software (not to reveal / compromise the secret key when it is entered) as well as the drive device since it is another place where an adversary can potentially access the plaintext of both your data and your secret key? Surely drive resident encryption / decryption is also worse for "TEMPEST" type concerns and concerns about vulnerable plaintext data transmission over the network / SAN / storage interface since the alternative host based implementation would encrypt all the data all the way from the CPU outward.

People worry about "cold boot" attacks to PC RAM; it wouldn't be a bad guess to think that such a thing might be even more easy / effective if it were done to a drive.

PCs are starting to have TPM units to secure the execution environment of the PC, but there is no standard (unless this recent work helps define such an architecture) TPM for on-drive storage controllers, so it might be even easier to tamper with the drive based crypto system than were it to be done by trusted host based software (though this is not necessarily so -- it could be EASIER to secure the drive based SOC controller implementation, but given that it is a black box with non-public design / source code, who could ever say it is really implemented securely?).

Now having the host software encrypt the data and then having a drive independently (and with a different key!) encrypt the data would potentially be a nice additional layer of security, though.

Security you cant verify is useless (0)

Anonymous Coward | more than 5 years ago | (#26650109)

This is useless and insecure.

Can I please get the sourceode to the firmware and verify it and then build a new set of firmware to use on the device?
I mean, I want to make sure there isnt any funny backdoors and stuff.

I cant? Well, No problem. Ill just continue to use the one I am already using then.

Security vithouth being able to verify it is useless. CryptoAG told us that.

Tomorrow's headline... (3, Funny)

syousef (465911) | more than 5 years ago | (#26650139)

Universal Disk Encryption Spec Cracked. Available on 0dayz haxx0r b0ardz!!!

Do STD's make it easier to 'see' encrypted disks? (2, Interesting)

ivi (126837) | more than 5 years ago | (#26650159)

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 (2, Interesting)

jjohnson (62583) | more than 5 years ago | (#26650211)

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.

Re:Do STD's make it easier to 'see' encrypted disk (5, Insightful)

Eivind (15695) | more than 5 years ago | (#26650445)

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.

Passwords for harddrives (1)

Britz (170620) | more than 5 years ago | (#26650179)

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 ... (2, Interesting)

Nicolas MONNET (4727) | more than 5 years ago | (#26650223)

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:Well if data isn't encrypted ... (1)

calc (1463) | more than 5 years ago | (#26650275)

As I understand it, at least with the recent Seagate 7200.11 fiasco exchanging the board no longer works on newer hard drives.

And use ROT 13 for good measure... (0)

Anonymous Coward | more than 5 years ago | (#26650569)

That will throw them... heck, do it once more to be doubly sure...

Re:Well if data isn't encrypted ... (0)

Anonymous Coward | more than 5 years ago | (#26651255)

You DO realize it would be a lot easier (i.e., not requiring a "clean room") to just switch the actual controller boards, right? ;)

Problems abound... (3, Interesting)

Vertana (1094987) | more than 5 years ago | (#26650263)

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:Problems abound... (2, Informative)

Antique Geekmeister (740220) | more than 5 years ago | (#26651025)

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.

No thank you. (1)

palegray.net (1195047) | more than 5 years ago | (#26650273)

From the article:

... can be used across all hard disk drives, solid state drives (SSD) and encryption key management applications ...

I'm supposed to trust my crypto keys to a third party? What particular dealer do they think is supposed to supply me with the kind of crack that would cause me to find this acceptable? I didn't write the code that runs their firmware, and I didn't compile anything from their shop either (reference On Trusting Trust [bell-labs.com] by Ken Thompson, circa 1984, for background).

Re:No thank you. (1)

Bronster (13157) | more than 5 years ago | (#26651291)

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 lose everything you've ever done because it's locked behind personal encryption. Some legacy that brick is going to be.

Furthur "Edition" Separation (2, Informative)

iSzabo (1392353) | more than 5 years ago | (#26650291)

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.

modo uP (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26650295)

Put your own encryption on top of the drive's... (2, Insightful)

thorndt (814642) | more than 5 years ago | (#26650367)

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.

Why is this a rights issue? (1)

scourfish (573542) | more than 5 years ago | (#26650379)

The idea isn't new. Hard drives already have the ability to lock users out if a code isn't entered correctly; the XBox used this. The paranoid seem to be coming at this from a "Oh no they're gonna lock me out of my own data" type of deal; but the benefits aren't intended to lock your upgrade hardware down to your brand, PC wise (Compaq tried that a long time ago, it didn't work.) An encryption standard could be good. There are plenty of perverts out there, afraid that their friends will discover all of their nasty bestiality fetishes, who would love to be able to encrypt their hard drives. If the standard is open, then it would be a lot easier for them to swap their drives filled with illegal horse and furry porn into a new computer.

last part they needed for completely secure DRM (0)

Anonymous Coward | more than 5 years ago | (#26650501)

They needed to own your hardware at the lowest level before they could implement a DRM based OS that completely controls access to every bit on the computer. And the DCMA guarantees jail time for breaking the encryption on your own hardware to get your own data out.

In other words... (1)

The Real Tachyon (1332153) | more than 5 years ago | (#26650743)

All this sounds like to me is that enough governments finally agreed on a standard that they want the HD manufacturers to use. I would say this is about the point where the tech industry is getting into bed with government like the telecom industry did back in it's day.
Trusted computing platform. Built in, black box hard drive encryption. And with the recent 'bogus Chinese Cisco routers that might have enemy sniffing capabilities' scare I'm sure routers and other core Internet architecture are in the process too.
In my mind this is the real reason to push open source. For protection from a police state as much as protection of free choice.
It gives good reason why things like Asterisk, Vayatta, Linux/BSD, etc. are important and why we need them to have significant market share in core communications areas to insure initiatives like those I mentioned don't become defacto standards.
IMO anyway....

A few comments... (0)

Anonymous Coward | more than 5 years ago | (#26650751)

Here are some comments that may not be obvious from the story.

(1) While all of the HDD vendors have been involved with the spec, not all HDD vendors have agreed to the TCG version yet. That is, the Opal spec was approved, but there is also an approved Enterprise spec that could be used (previously, Enterprise was targeted only at RAID servers, but the spec is applicable to laptops & desktops). In other words, there may still be some fracturing within the industry until the final standard is selected.

(2) Microsoft, who typically is very involved with drivers and application support for standardized HW, is notably absent from the article

(3) Microsoft is driving a related spec under the IEEE-1667 umbrella, which does not current include encryption, but does include the ability to handle access control (credentials).

(4) Pre-boot authentication is not currently supported by BIOSes or widely by ISVs (e.g. Wave). There's still a lot of work to do here.

(5) Compliance testing is still not completed by the TCG, and therefore, current implementations toward the existing spec likely vary.

Also, for those who are wondering if there are backdoors to these solutions. Note the following:

(a) The first HDD encryption solutions may or may not have back doors. It's obviously not in the TCG spec, but the TCG spec does not specifically prevent a HDD manufacturer from adding other firmware to create a backdoor for them or uncle sam (no such agencies).

(b) Once HDD encryption solutions hit the streets, hackers will likely attack the products and find weaknesses. The community will, in turn, reveal the relative strengths of these solutions.

(c) Mid to long term, the HDD encryption drives will likely be requested to be FIPS certified, which is under NIST. FIPS 140-2 or 140-3 requires a lab to review both the hardware and firmware designs in order to gain compliance (i.e. check for security holes and backdoors). FIPS testing will go a long way to confirm the quality of these FDE solutions.

Cheers

How long... (1)

xlsior (524145) | more than 5 years ago | (#26651349)

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.

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:How long... (1)

Ada_Rules (260218) | more than 5 years ago | (#26651479)

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 (1)

daem0n1x (748565) | more than 5 years ago | (#26651509)

And the encryption key is standard also, it's:

f81ce859f77fa8a773d66d538ba7ad3daa1185d8

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?