Forgot your password?
typodupeerror
Your Rights Online Data Storage Encryption Privacy Security Upgrades Hardware

Universal Disk Encryption Spec Finalized 237

Posted by timothy
from the surely-will-foil-the-nsa dept.
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."
This discussion has been archived. No new comments can be posted.

Universal Disk Encryption Spec Finalized

Comments Filter:
  • by SpaceLifeForm (228190) on Thursday January 29, 2009 @01:30AM (#26649743)
    What about the owner?

    Why should this be trustable?

    • by fuzzyfuzzyfungus (1223518) on Thursday January 29, 2009 @01:37AM (#26649783) Journal
      The drive is "trusted" because the "owner" isn't.
      • 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

        • Re: (Score:3, Insightful)

          by palegray.net (1195047)
          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 th
          • 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."

            Warmer... warmer... warmer...

            Who would find this an appealing alternative to the status quo?
        • by Lucky_Norseman (682487) on Thursday January 29, 2009 @06:28AM (#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: (Score:3, Interesting)

            by Lord Ender (156273)

            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)

              by Alsee (515537)

              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

        • by hairyfeet (841228) <bassbeast1968@@@gmail...com> on Thursday January 29, 2009 @07:40AM (#26651549) Journal

          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.

          • by BenEnglishAtHome (449670) on Thursday January 29, 2009 @10:58AM (#26653273)

            Why would you trust them not to have a back door installed,...

            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)

              by Directrix1 (157787)

              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)

              by Hatta (162192)

              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.

        • by AlecC (512609) <aleccawley@gmail.com> on Thursday January 29, 2009 @08:00AM (#26651645)

          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)

          by billcopc (196330)

          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

    • by Kamokazi (1080091) on Thursday January 29, 2009 @01:48AM (#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.
      • by Futurepower(R) (558542) <MJennings.USA@NOT_any_of_THISgmail.com> on Thursday January 29, 2009 @01:58AM (#26649913) Homepage
        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.
        • by PitaBred (632671) <slashdot@pitabre ... rg minus painter> on Thursday January 29, 2009 @02:11AM (#26649991) Homepage
          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.
          • by MSG (12810) on Thursday January 29, 2009 @02:22AM (#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.

            • by dido (9125) <dido@i[ ]rium.ph ['mpe' in gap]> on Thursday January 29, 2009 @04:04AM (#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.

            • by Wescotte (732385)

              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.

              • by amorsen (7485) <benny+slashdot@amorsen.dk> on Thursday January 29, 2009 @05:24AM (#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: (Score:2, Interesting)

                by Anonymous Coward

                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)

            by MrNaz (730548) *

            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

        • by Eighty7 (1130057) on Thursday January 29, 2009 @03:08AM (#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 (Score:5, Informative)

            by RationalRoot (746945) on Thursday January 29, 2009 @04:20AM (#26650567) Homepage
            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
          • by Dr_Barnowl (709838) on Thursday January 29, 2009 @02:15PM (#26656145)

            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 :-)

        • Because pre-boot system partition encryption only works on x86/x86_64 and only for Windows [truecrypt.org].

    • Re: (Score:3, Insightful)

      by Eivind (15695)

      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.

    • by noidentity (188756) on Thursday January 29, 2009 @04:39AM (#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.

      • 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? (Score:3, Insightful)

    by Anonymous Coward on Thursday January 29, 2009 @01:30AM (#26649747)
    How can we trust their implementation?
    • 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 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.

  • by (Score.5, Interestin (865513) on Thursday January 29, 2009 @01:32AM (#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.

    • by this great guy (922511) on Thursday January 29, 2009 @01:43AM (#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: (Score:3, Interesting)

        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?

      • by drinkypoo (153816)

        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.

        • by pipatron (966506)

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

  • by Anonymous Coward on Thursday January 29, 2009 @01:38AM (#26649789)
    brick your hardrive. Now it's secure.
  • by dmomo (256005) on Thursday January 29, 2009 @01:40AM (#26649801) Homepage

    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)

    by sstpm (1463079) on Thursday January 29, 2009 @01:46AM (#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?
    • 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 (Score:3, Interesting)

    by Jane Q. Public (1010737) on Thursday January 29, 2009 @02:29AM (#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.
    • by Eric Smith (4379) <eric@broDEBIANuhaha.com minus distro> on Thursday January 29, 2009 @02:49AM (#26650153) Homepage Journal
      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.

      • 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.
        • by dfn_deux (535506)
          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
          • 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 sou
            • Re: (Score:2, Informative)

              by hairyfeet (841228)
              Uuuhhh.....Maybe I missed something here, but how exactly is TrueCrypt Not "open source"? When I pick downloads at the bottom of the page it has a nice link that says source code, which you click and it take you to this page [truecrypt.org] which says, and I quote "The complete source code (in C, C++ and assembly) of the latest stable version of TrueCrypt.". So how exactly are they NOT open source? And as many folks out there that use TrueCrypt and as many security experts that recommend it I am sure that the source code h
      • by mcrbids (148650)

        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)

          by Eric Smith (4379)

          Remember, if security were a data field, it wouldn't be a boolean value, it would be a real number.

          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

  • by syousef (465911) on Thursday January 29, 2009 @02:44AM (#26650139) Journal

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

  • by ivi (126837) on Thursday January 29, 2009 @02:50AM (#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: (Score:3, Interesting)

      by jjohnson (62583)

      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

      • You'd be better off using pagefile.sys than some name you made up. How many cursory glances will pick up you're running your pagefile on a different partition? Or which pagefile is in use?
    • by Eivind (15695) <eivindorama@gmail.com> on Thursday January 29, 2009 @03:48AM (#26650445) Homepage

      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.

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

        • by brusk (135896)

          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.

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

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

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

      • by calc (1463)

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

      • by makomk (752139)
        That doesn't work - the password is almost certainly stored on the platters too. (Of course, pretty much all drives seem to offer a way of removing the password without knowing it, given the correct software. Also, all modern drives have a nice serial connection for manufacturer testing and diagnostic purposes, and I think generally this can be used to disable the password too.)
  • Problems abound... (Score:4, Interesting)

    by Vertana (1094987) on Thursday January 29, 2009 @03:13AM (#26650263) Homepage

    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)

      by hairyfeet (841228)

      You want to know how the child pr0n guys get away with it? I know that I will probably get flamed for bringing this up, but out of curiosity I asked a buddy I was going to school with that worked in the state crime lab how come all we ever see on the news is these morons in their basements looking at child pr0n instead of the rings that are actually making the crap. According to him it is because the actual producers don't make this garbage and then post it to forums where they can be traced. By the time i

    • In the UK, "Oops, I forgot the password" means two years in jail (five for terrorist or paedophilia related investigations).

      That's one reason.
    • 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

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

  • by thorndt (814642) on Thursday January 29, 2009 @03:31AM (#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.

  • 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.
    • by Ada_Rules (260218)

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

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

    f81ce859f77fa8a773d66d538ba7ad3daa1185d8

  • Short-sighted. (Score:3, Insightful)

    by ledow (319597) on Thursday January 29, 2009 @08:17AM (#26651757) Homepage

    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.

  • ...but you can never be to careful so: Remember to include the CIA backdoor guys! Thanks!

    PS: Tinfoil won't protect you from it!

  • by MobyDisk (75490) on Thursday January 29, 2009 @11:04AM (#26653347) Homepage

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

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

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Working...