Slashdot Mirror


Universal Disk Encryption Spec Finalized

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

15 of 237 comments (clear)

  1. Disk vendors are free to choose by SpaceLifeForm · · Score: 5, Insightful
    What about the owner?

    Why should this be trustable?

    --
    You are being MICROattacked, from various angles, in a SOFT manner.
    1. Re:Disk vendors are free to choose by fuzzyfuzzyfungus · · Score: 5, Insightful

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

  2. It's not an encryption spec... by (Score.5,+Interestin · · Score: 5, Informative

    ... it's TPM glue for hard drives. The spec says almost nothing about encryption and authentication, it's just a bunch of TPM command and control mechanisms for hard drives. The IEEE P1696 working group is the one working on secure hard-drive encryption. Unfortunately the TPM people have better PR people than the CS and EE types doing the IEEE work do.

  3. Seagate's stragegy.. by Anonymous Coward · · Score: 5, Funny

    brick your hardrive. Now it's secure.

  4. Re:ok by fuzzyfuzzyfungus · · Score: 5, Funny

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

  5. Why not just use TrueCrypt? by Futurepower(R) · · Score: 5, Informative

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

    1. Re:Why not just use TrueCrypt? by PitaBred · · Score: 5, Insightful

      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.

    2. Re:Why not just use TrueCrypt? by MSG · · Score: 5, Insightful

      Specialized hardware will always be faster and use less power to do a specific job than general-purpose hardware like your CPU.

      Not "always", and not "and".

      Specialized hardware will usually be faster than the CPU, and will usually yield an overall faster system by virtue of the fact that the CPU is free from those tasks.

      However (and purely as an example), Linux's software RAID is faster than many hardware RAID controllers, and a system lacking a dedicated hardware RAID controller very well may use less power than an equivalent system with one.

    3. Re:Why not just use TrueCrypt? by dido · · Score: 5, Interesting

      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.

      --
      Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
  6. Re:Pardon my ignorance by Eric+Smith · · Score: 5, Insightful
    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.

  7. Re:Do STD's make it easier to 'see' encrypted disk by Eivind · · Score: 5, Insightful

    This use-case is more or less dying out though. Because transporting bits across a border by having someone hand-carry them is just too large a risk, assuming it's the kind of bits the government of either country would rather not have crossing the border.

    Much better to transmit the bits out, in encrypted form, over some kind of network. Even if there's no internet, you can always do it over satelite-phone or something. Yeah, I know that's like $3/minute, but how many minutes do you need to transmit the ascii-text of an interview or something ?

    It's sligthly more of a problem if it's something largish, particularily if it's HD-video though, but even this problem is going away. Even if you're in Iran, it's not very hard to find an access-point with a megabit or more of capacity.

    There's no question; the safest way to store "dangerous" bits on your laptop while crossing a border, is to NOT store them on there at all. They can't find what is genuinely not there.

  8. True Crypt Source by RationalRoot · · Score: 5, Informative

    What' is this then ?

    http://www.truecrypt.org/downloads2.php

    Source Code ?

    I have not compiled it, nor gone through it in detail, but it looks like source code to me.

    D

    --
    http://davesboat.blogspot.com/
  9. Re:that is true, Defective by Design. by Lucky_Norseman · · Score: 5, Insightful

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

  10. Re:that is true, Defective by Design. by hairyfeet · · Score: 5, Insightful

    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.

    --
    ACs don't waste your time replying, your posts are never seen by me.
  11. Re:that is true, Defective by Design. by AlecC · · Score: 5, Informative

    If you read further down, it says you can do a global reset, which loses the key and unlocks the disk as full of encrypted garbage, "with a few keystrokes".

    --
    Consciousness is an illusion caused by an excess of self consciousness.