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

37 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. Re:Disk vendors are free to choose by Kamokazi · · Score: 4, Insightful

      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.

      --
      As our way of thanking you for your positive contributions to Slashdot, you are eligible to disable Slashdot 2.0.
    3. Re:Disk vendors are free to choose by MrNaz · · Score: 3, Funny

      The SS?

      1955 called. They want their bad guys back.

      --
      I hate printers.
    4. Re:Disk vendors are free to choose by noidentity · · Score: 3, Interesting

      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.

  2. itsatrap? by Anonymous Coward · · Score: 3, Insightful

    How can we trust their implementation?

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

    1. Re:It's not an encryption spec... by this+great+guy · · Score: 4, Informative

      The parent poster made a typo in the IEEE project name. It's P1619. 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.

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

    brick your hardrive. Now it's secure.

  5. They key words by dmomo · · Score: 4, Funny

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

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

  7. Re:A few questions... by jamstar7 · · Score: 4, Insightful

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

    --
    Understanding the scope of the problem is the first step on the path to true panic.
  8. Dumb Question by sstpm · · Score: 3, Interesting

    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?

  9. 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 MrNaz · · Score: 3, Funny

      The vast and growing chasm between CPU power and the crunching needs of personal computing have rendered this argument obsolete. Please upgrade to MS Arguments 2009, or the open source alternative, OpenMouth v0.9b3

      --
      I hate printers.
    4. Re:Why not just use TrueCrypt? by Eighty7 · · Score: 3, Interesting

      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

      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/

    5. 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:Why not just use TrueCrypt? by amorsen · · Score: 3, Interesting

      True dedicated hardware RAID controllers, such as the HP Smartarray, IBM ServeRAID, and the RAID controllers you see on fiberchannel SANs, are actually quite rare except in enterprise setups, and they are in general much faster than the Linux software RAID implementation.

      Smartarray is dead slow for RAID5, and RAID1 in software doesn't tax the CPU. RAID controllers are only worth it because it can be hard to get Linux booting reliably from a software RAID 1 with a failed disk. As for RAID levels other than RAID1 and RAID10, don't.

      --
      Finally! A year of moderation! Ready for 2019?
    7. Re:Why not just use TrueCrypt? by amorsen · · Score: 3, Insightful

      The best RAID coprocessors are made by companies like Intel and AMD. You can find them under names like "Xeon" or "Opteron".

      Shamelessly stolen from Alan Cox.

      --
      Finally! A year of moderation! Ready for 2019?
    8. Re:Why not just use TrueCrypt? by Dr_Barnowl · · Score: 3, Interesting

      All TCHunt does is look for random data. If you append 100MB of /dev/urandom to a file and run TCHunt, it will "recognise" it as a TrueCrypt volume.

      This is not a secret. This is how encryption works. Obfuscating your data inside a apparently plaintext structured format is called stenanography and is another subject entirely.

      The changelog is here

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

  10. that is true, Defective by Design. by twitter · · Score: 3, Insightful

    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.

    --

    Friends don't help friends install M$ junk.

    1. Re:that is true, Defective by Design. by palegray.net · · Score: 3, Insightful

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

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

    3. 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.
    4. 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.
  11. Tomorrow's headline... by syousef · · Score: 3, Funny

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

    --
    These posts express my own personal views, not those of my employer
  12. 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.

  13. Problems abound... by Vertana · · Score: 3, Interesting

    If someone has Truecrypt on their hard drive and the police raid your house for some server and they take that encrypted drive, there is nothing stopping you from saying, "I forgot my password... oops." But if you trust the hardware, then what stops the police from going after that hard drive manufacturer and putting the legal pressure on them to provide a back entrance and/or technical help? The idea that the government won't put a legal squeeze on the hard drive manufacturer the second they think they've come upon a child pornography/warez/other horrible illegal things seems absurd to me. I understand that manufacturers of things like flash drives and such have had hardware encryption before, but it hasn't been widespread and mainstream. When you throw in the "average citizen" factor, I think we'll see all kinds of challenges and laws spring up.

    -- And as always IANAL, but I do read Slashdot!!

    --
    "The best way to accelerate a Macintosh is at 9.8m/sec^2" -Marcus Dolengo
  14. Re:A few questions... by clampolo · · Score: 3, Interesting

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

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

  16. 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/
    1. Re:True Crypt Source by AusIV · · Score: 3, Informative

      When TrueCrypt released version 5.0, they lacked a 64 bit version. Myself and a couple of others on the Ubuntu forums hacked at the source until we got a 64 bit version to compile and run smoothly. It may not be an OSI approved license, but the source is definitely there for those who want to pick at it.

  17. Re:A few questions... by Atlantis-Rising · · Score: 4, Insightful

    And yet, somehow I don't believe you.

    To be more specific, I find it illogical to assume that the NSA would require you to provide them with the keys and at the same time let you talk about it.

    Given this, I am suspicious of your claim in the extreme.

    --
    "It is possible to commit no errors and still lose. That is not a weakness. That is life." -Peak Performance
  18. Re:A few questions... by L4t3r4lu5 · · Score: 4, Funny

    Good point. clampolo, care to comment?

    clampolo?

    --
    Finally had enough. Come see us over at https://soylentnews.org/
  19. OTOH, a reason to trust by BenEnglishAtHome · · Score: 3, Insightful

    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.