Please create an account to participate in the Slashdot moderation system


Forgot your password?
Security Hardware

Self-Encrypting Hard Drives and the New Security 205

In a recent blog post, CNet's Jon Oitsik has called for a policy shift with respect to data encryption. A new standard by the Trusted Computing Group promises the availability of self-encrypting hard drives soon, leading some to call for immediate adoption. Will this create even more security problems due to lazy custodians, or should someone responsible for keeping your information safe be required to move to the new hardware? Hopefully the new hardware comes with a warning to continue to use other data protection measures as well.
This discussion has been archived. No new comments can be posted.

Self-Encrypting Hard Drives and the New Security

Comments Filter:
  • by MaxwellEdison ( 1368785 ) on Monday March 09, 2009 @02:06PM (#27124115)
    Oh there's a warning, it's just been encrypted for its own protection.
  • by sheddd ( 592499 ) <jmeadlock@pCOBOL ... com minus langua> on Monday March 09, 2009 @02:06PM (#27124119)
    Never has a backdoor!
    • by Shakrai ( 717556 ) on Monday March 09, 2009 @02:15PM (#27124251) Journal

      You got a funny mod but it should be insightful. That was my first thought......

      Don't worry though, it's for your protection. Think of the children/terrorists!

    • by dgatwood ( 11270 ) on Monday March 09, 2009 @02:19PM (#27124311) Homepage Journal

      I wouldn't worry about back doors. Given the history of "secure" hardware devices, I'd be more worried about them turning the password trivially into a 64-bit key, using XOR with the key, and storing the key in unencrypted flash for verification....

      • All of my sensitive data is double-ROT-13 encrypted!
        • Re: (Score:2, Informative)

          by Aphoxema ( 1088507 )

          I use Quadruple-rot-13, far more effective IMHO.

          • Re: (Score:2, Funny)

            by UnderDark ( 869922 )
            4096 cycle rot-13 is much much more effective drain on cpu cycles
          • Re: (Score:2, Insightful)

            by sheddd ( 592499 )
            And you get modded informative. Nice!
          • Re: (Score:3, Funny)

            by Anonymous Coward

            I use Quadruple-rot-13, far more effective IMHO.

            ROT-13 should be the new trigger for Godwin's law in Slashdot discussions.

          • I use Quadruple-rot-13, far more effective IMHO.

            This is what comes of applying cryptography naively.

            You really need to learn about the "meet in the middle attack []". Read the link for full details, but what it boils down to is that when applying any cipher multiple times, the attacker can work both ends towards the middle, trading space against time.

            See, THIS is why even the most competent engineers should defer cryptographic design to the real experts.

            Quadruple-ROT-13... Bah.

          • I use Quadruple-rot-13, far more effective IMHO.

            Can anyone make sense of this? I think it's encrypted with double-rot-13, or possibly even quadruple. Any help cracking this secret message would be appreciated.

        • I'm sorry, I couldn't read your post. Could you post the algorithm and key to unencrypt it?

      • FIPS 140-2 (Score:3, Interesting)

        In theory, if these drives are being used by a US government agency for encryption, then the drives need to be FIPS 140-2 [] certified.

        In order be certified, there is a stringent list of algorithms that may be used, for both encryption and random number generation, and these algorithms need to be tested and certified themselves.

        We'll have to see if the hard drive companies want to go through the headaches involved to get FIPS certification, or whether this is meant as a gimmick for consumers.

    • by hweimer ( 709734 ) on Monday March 09, 2009 @02:42PM (#27124633) Homepage

      Actually, this is about a new specification created by the Trusted Computing Group, so it's fairly open stuff. However, I fail to see how this actually solves any of the problems related to recent data breaches. If you lose your notebook with all your data the attacker also gets access to the Trusted Platform Module and can decrypt the disk. If you want to securely transport your data, this is horribly inconvenient as the whole point is to be able to access the data on different machines (which this tries to prevent).

      • by Lumpy ( 12016 ) on Monday March 09, 2009 @03:00PM (#27124915) Homepage

        Some people say no but I have seen this in action.

        We had secure laptops here with encryption and smartcard security. Bought all Dell 620's with built in smartcard slot.. all was peachy.

        We tested our security. 9 out of 10 laptops had the smartcard in them in the bag. AND their pin access number was on the laptop somewhere. os the encryption and any login security was overridden by user failure.

        • Re: (Score:3, Interesting)

          by PitaBred ( 632671 )
          Fire a few of them, and let people know why they were let go. Users learn pretty well when they have proper incentives. You're not asking for a lot, and if they can't perform the duties of their job, they need a new job.
      • by PCM2 ( 4486 )

        If you lose your notebook with all your data the attacker also gets access to the Trusted Platform Module and can decrypt the disk.

        Yes, but on the other hand, this seems like it could help prevent cases where employees steal the hard drives out of servers. (It's a lot easier to walk out the front door with a couple of hard drives in a duffel bag than it is to make off with two or three complete rack-mount servers.)

      • Re: (Score:3, Interesting)

        by mlts ( 1038732 ) *

        Even though the TPM is specced to not be armored against attack, it would take someone with access to a chip fab to try to get the key off the silicon itself.

        With a TPM and a hard disk that can use this the way BitLocker does (where it boots to the OS without needing any passwords, but attempts to boot to other media to access the drive require access to the volume's recovery key), this is good protection for a laptop, making the main attack front the username/password of users or administrators. One can a

    • by eean ( 177028 )

      Is anyone talking about propriety encryption though? I mean the NSA has standards for encryption that obviously the Federal government would follow, but so does most of the industry.

    • Oh good, so now I need a special driver with which to decrypt my hard drive, so it won't work with the Linux or BSD kernels.

      I would buy such a product (encrypted HDD or encrypted SATA/SAS [RAID] controller) if it were completely open (as in GPL-compatible) firmware, open specs, and solid assurances of fair play with respect to patents, etc. Especially if the encryption/decryption is performed on a dedicated chip so as to keep resource costs from growing.

      ... and battery back-up (like other hw RAID contr

      • by mrsteveman1 ( 1010381 ) on Monday March 09, 2009 @02:57PM (#27124861)

        Self encrypting would be in the drive no?

        So to an operating system, once the drive has been unlocked by a firmware command it should appear as a cleartext ATA device.

        • by Khopesh ( 112447 )

          And what do you do when the drive is stuck in the middle of a write when something crashes? Without the proper ~journal/cache and a battery to ensure it has time to complete, you risk losing your data. When it comes to encrypted data, some malformed data can mean EVERYTHING is lost. This is not acceptable.

          Also, I fully expect them to skimp on the implementation. Fully driver-transparent encryption would require the device itself (or the controller, if that's where it is implemented) to handle the encr

    • Just to annoy them i'd use PGP encrypted files in a trucrypt container on the encrypted hard drive...
  • Decryption (Score:3, Funny)

    by MrEricSir ( 398214 ) on Monday March 09, 2009 @02:08PM (#27124147) Homepage

    Hopefully they're also self-decrypting. Although it would certainly be more secure without this feature.

  • by leromarinvit ( 1462031 ) on Monday March 09, 2009 @02:09PM (#27124161)

    An additional layer of encryption can't be bad. If it's a good implementation with no critical bugs and backdoors, great, you've just made it harder for someone to get your data. If it isn't, it's still no worse than storing plain text.

    Just don't rely on this as your only security measure.

    • by GMFTatsujin ( 239569 ) on Monday March 09, 2009 @02:21PM (#27124339) Homepage

      Unless it does something unexpected, such as, say, making it a nightmare to recover files off the drive for legitimate reasons.

      I foresee a lot of IT departments pulling their collective hair out on this one: some Executive Director with a penchant for buying the Shiny New Thing stores mission critical data on a self-encrypting drive, some motherboard component on the computer blows up, and now the hard drive -- while fine -- is inaccessible.


      • by Todd Knarr ( 15451 ) on Monday March 09, 2009 @02:39PM (#27124581) Homepage

        Or worse, said Executive Director stores information on that drive that's relevant to a lawsuit. And when you have to tell the court that you've lost evidence because of this, you end up facing the possibility of losing some points in the case (or even the entire case) as sanction for spoliation of evidence. Even if the evidence would have exonerated your company. We won't even discuss the fun if it's tax- or SEC-related.

      • Re: (Score:3, Insightful)

        That's why you do separate encrypted offsite backups. Encrypted transport over some cable or network to another encrypted container like a LUKS volume or something.

        You should never rely entirely on one copy of data anyway, this seems to be just a way to protect drive data from theft.

        • Execs tend to take the same approach to rules as Congress does: they make 'em but are for the most part exempt from their effects. They take, shall we say, "liberties." I have always worked for businesses where the execs determined "as I say, not as I do" IT policies.

          They are dumb that way. Yes. But that's who I end up working for. Maybe it's just me.

          I suspect it's not just me, though. I can't believe Scott Adams wrote the PHB just for my benefit.

          Your point about backups is well-taken, but applying th

      • I have one of the seagate encrypted drives. There is nothing about them that is tied to a specific motherboard or TPM chip. The encryption keys are protected by a password, and there are a couple of ways to provide the password to the drive. The computer manufacturer can implement this functionality in the BIOS, and have it prompt for the password on boot (this is what Lenevo does). Alternately the MBR is not encrypted, so you can install a boot loader that prompts for the password, passes it onto the drive

        • Sounds nice. How does it work in external enclosures?

          • by pavon ( 30274 )

            I haven't tried yet. I actually have one on order as we speak to try it out. From what I understand, the software from Wave Systems allows you to unlock and lock internal non-boot drives in Windows. I don't see any reason why an eSATA enclosure would be any different, but I don't expect USB enclosures to work.

            AFAIK, no one has written Linux client software for doing this or any other password administration yet.

    • by Jamu ( 852752 )

      An additional layer of encryption can't be bad.

      Probably not with different encryption schemes. If it's the same encryption scheme applied twice though, couldn't the encryption be easier to break? This is obviously the case for a trivial scheme like ROT13, but what about more practical schemes like AES?

      • Depends on the scheme. ROT13 is obviously a toy example; but DES isn't(outmoded, yes) and, while you'll see DES and 3DES, you'll never see 2DES, for that reason.
        • by afidel ( 530433 )
          And even 3DES needs modification from the base algorithm, just applying straight DES three times does leave you less secure. This was one of those interesting things that the general public didn't find out until decades later but the NSA actually suggested a modification to the S-box in DES for use with triple DES. Turns out that modification prevented a particular class of EC analysis against 3DES, a technique that wasn't available in academic circles until almost two decades after the NSA change.
          • Where did you get this information? 3DES uses the same algorithm as 1DES, just applied three times. In fact, one of the design goals of 3DES was that in EDE (encrypt-decrypt-encrypt) mode, using the same key for all three stages, it was functionally equivalent to 1DES, thus allowing you to use the same hardware for both 1DES and 3DES. 3DES has also be implemented in EEE models, which are no less or more secure than the EDE model.

            The only thing 3DES leaves you "less secure" than is perhaps a naive assumption
        • Re: (Score:3, Funny)

          by mustafap ( 452510 )
          >you'll never see 2DES

          Pity really, 'cause 2DES is very secure when hackers think it's triple DES :o)
        • Actually you'll never see 2DES because it only adds a trivial amount of security -- with a meet-in-the-middle attack it only provide about 57 bits effective key length, a mere one bit more than 1DES. Even 3DES only provides 112 effective key bits due to the same attack.

          But 2DES is not less secure the 1DES, it's just not enough better to bother. 3DES also has the advantage of a encrypt-decrypt-encrypt mode with a single key, which allows you to use the same hardware to do both 1DES and 3DES.
      • by icebike ( 68054 )

        An additional layer of encryption can't be bad.

        Probably not with different encryption schemes.

        My understanding is that dual (or any multiple) encryption provides no additional
        protection because brute forcing the product is no more difficult than brute forcing
        the first encryption.

    • Except for the first clause of your second sentence. It's pretty much guaranteed that there'll be critical bugs or back doors. And more likely than not it'll be cracked soon after release leading to other problems.

    • by Lord Ender ( 156273 ) on Monday March 09, 2009 @02:45PM (#27124689) Homepage

      No. Worthless security measures are bad for security because they provide a false sense of security. This influences behavior. So bad "encryption" really can be worse than plain text.

  • by petes_PoV ( 912422 ) on Monday March 09, 2009 @02:10PM (#27124167)
    And the very first thing the users will do is write down the encryption key, so they don't forget it.

    After all, what's the point of having all your data on a disk that you can't access? It's far more likely that the user(s) will forget the key, than for the drive to fail. However, the result will be the same in both cases: inaccessible data and if past experience is anything to go by, no backups (which would also have to be encrypted, again with the isssue over keys).

    Until the average PC user radically rethinks their attitude towards their computers - whether at work or play, this seems just one step too far.

    • > And the very first thing the users will do is write down the encryption key, so they
      > don't forget it.

      That's exactly what they should do, unless it's a corporate machine subject to central key management. They also should, of course, put the key somewhere secure and seperate from the computer.

    • by icebike ( 68054 )

      I don't see it that way. Its no worse than a password protected account on a machine.

      Do you write down a password you use every day?

      If this implemented on a wide scale, you wouldn't need any other passwords on a single user machine such as a laptop.

      Clearly, on a corporate or multi-user machine, its a problem (additional password), because you end up having to give it to every user.

    • You say that like it's a bad thing. If it was a matter of losing everything I owned, I'd write the key down somewhere. I currently keep all my passwords on a hand written piece of paper in a safety deposit box at my house in case I die so someone can access my shell / accounts.

      It's more than likely that someone is going to grab my laptop at the airport than when I'm sitting at it writing the password down.

    • Re: (Score:3, Informative)

      And the very first thing the users will do is write down the encryption key, so they don't forget it.

      Well, Bruce Schneier recommends writing down your passwords. []


      . We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

  • hmm (Score:5, Interesting)

    by n3tcat ( 664243 ) on Monday March 09, 2009 @02:11PM (#27124203)
    if encrypted hard drives become the norm, will authorities be more apt to treat it as a protected right rather than as a method of hiding shit?
  • by davidwr ( 791652 ) on Monday March 09, 2009 @02:15PM (#27124257) Homepage Journal

    It's hard to do with fixed drives, but I want USB drives and memory sticks that come with their own dongle-key that plugs into the storage device, so they key can be separated from the drive. Even better if it has its own keypad or fingerprint reader for authentication. "Something you have, plus something you know."

  • by Chas ( 5144 ) on Monday March 09, 2009 @02:17PM (#27124279) Homepage Journal

    Spoken (or typed in this case) like someone who's completely misunderstood the security process and thinks that [Insert Buzzword] = Security

  • by uberdilligaff ( 988232 ) on Monday March 09, 2009 @02:17PM (#27124283)
    While the focus will be on preventing data from being accessed when the PC is stolen, this will come with the rather severe side effect that a significant number of users will irreversibly lock themselves out of all their data by losing/forgetting their pass phrase. Too bad you can't reduce the first problem without increasing the second.
    • by TubeSteak ( 669689 ) on Monday March 09, 2009 @02:39PM (#27124593) Journal

      While the focus will be on preventing data from being accessed when the PC is stolen, this will come with the rather severe side effect that a significant number of users will irreversibly lock themselves out of all their data by losing/forgetting their pass phrase. Too bad you can't reduce the first problem without increasing the second.

      Are the contents of your wallet at least as valuable, to you, as the content of that encrypted hard drive?
      Good, then write down the passphrase and put it in your wallet.

      I bet most people take a lot more care with their wallet than they do with their work passwords.

    • For the average user what would be nice is if somehow this encryption talked wireless to a device I had tethered to my key chain.

      Perhaps when I boot, I have to click on a button to unlock the encryption, just like I do to open my car.

      While that is not governmental level security, it is something a user can understand. It means I don't have to remember anything other than my keys, which I already am use to. It also lets IT make backup devices (car lots can make you another key fob) in case the user looses

    • Key escrow (Score:3, Interesting)

      by davidwr ( 791652 )

      If there were multiple keys, each one of which could unlock the drive this would be fine. The owner, i.e. the IT dept., gets the main key and the user and others get backup keys.

      One way to implement it:

      The drive will accept either its on-board key or a key from a dongle. The on-board key of course will be encrypted with a passphrase that can be changed without changing the underlying key. If EITHER the passphrase is entered OR another copy of the key with ITS passphrase is present, the drive is unlocked.

      • by pavon ( 30274 )

        What you described is very similar to how the current seagate drives work, minus the external keyfob.

        Out of the box the drives store a single copy of the non-encrypted key. When you set an administrator password, that key becomes encrypted using that password. You can create up to 4 additional user accounts. Doing so creates an copy of the key (still on the drive) this time encrypted with their password. The commands to change settings on the drive require the administrator password (don't know how the secu

  • by elrous0 ( 869638 ) * on Monday March 09, 2009 @02:20PM (#27124321)
    If it's a proprietary system where some insecure company or insecure government agency has the keys, why even bother? If anything, it's only providing you with a dangerously false sense of "security."
  • Really? (Score:5, Insightful)

    by fuzzyfuzzyfungus ( 1223518 ) on Monday March 09, 2009 @02:20PM (#27124323) Journal
    I want some of what this guy is smoking. He seems to be under the impression that, because the encryption is handled in hardware, there will be no software to deal with. And what, pray tell, will configure the hardware, and set crypto keys, and hold them in escrow in case of the inevitable forgetting, and change them if needed, and so on and so forth?

    Hardware encryption certainly has its advantages; but if you can't handle deploying software encryption now, I'm deeply skeptical of your ability to handle deploying hardware encryption.
  • by Eric Smith ( 4379 ) on Monday March 09, 2009 @02:21PM (#27124331) Homepage Journal
    The big risk with FDE 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.

    • by icebike ( 68054 )

      > if you were an agend of some government...

      You wouldn't have to "tamper" with drives after manufacture.
      You would already have your built in back door.

    • by Zerth ( 26112 )

      If it is anything like the various encrypted USB sticks, it'll be trivially cracked with a logic probe and maybe soldering on another controller/copying the firmware from another drive for which the key is known.

  • Some of the online stores are already selling "encrypted hard disk drives". The firmware stores an encryption key that is used to process all data as it goes on and comes off the disk drive platters, so the data is encrypted at all times. When you want to erase the drive, you just change/erase the encryption key.

    It sounds like a good idea, but can the encryption key be recovered. Is it really erased, or just shuffled to an alternative backup array encryption keys? Or does the manufacturer keep a list of ser

  • by steve_bryan ( 2671 ) on Monday March 09, 2009 @02:28PM (#27124429)

    I hope this proposal is considered with more than the usual amount of skeptical reserve. The name was changed more than once but I'm fairly certain that the "Trusted Computing" group was previously acting as a lackey of the entertainment cartel. They managed to introduce new points of possible breakage making computer based media more prone to failure (e.g. HDCP and the forced failure of expensive monitors purchased by early adopters).

    If this is the same group then you can almost guarantee that they will include backdoors and other nastiness intended to inhibit unapproved behavior by the owner of the drive.

    • by afidel ( 530433 ) on Monday March 09, 2009 @03:11PM (#27125077)
      No, the trusted computer group grew out of an effort at Microsoft to allow secure network booting of clients. Without hardware encryption and bidirectional authentication it was a feature that customers asked for but which they would never have been able to accomplish. There has been talk of using such technology to implement better DRM, but so far it has come to naught even with Vista/Win7. In fact the TPM keystore is available for anyone to use via a fully documented interface and I believe there is a Linux module that allows you to use it. The biggest problem I have is that many TPM 1.2 implementations allow the key out of the keystore along an unencrypted bus which means there is a non-trivial but attainable attack vector against them. Personally I wish Dell wasn't the only vendor supporting TPM in server class systems because I would love to use bitlocker for remote office servers but I can't stand Dell's equipment or support.
  • My work hard drive is encrypted with Safeboot and it's slow as hell. If hardware encryption can improve the performance it'd be worth it for me.
  • Power Outage Hickups (Score:2, Interesting)

    by MBHkewl ( 807459 )

    So while the disk is self-encrypting itself, what if the power went out?

    Complete data corruption/loss?

    Or are you gonna mandate that everyone uses a UPS?

    • I'm pretty sure the drive just encrypts and decrypts on the fly at the block level as it writes and reads the data. If the hardware is designed correctly, you would be at no more risk of data loss due to power loss than you are with a regular drive. Did you think it runs through and encrypts the whole drive at shutdown and runs a decrypt at startup?

  • Three problems (Score:5, Insightful)

    by Todd Knarr ( 15451 ) on Monday March 09, 2009 @02:32PM (#27124483) Homepage

    Three problems with the idea:

    1. Transferring media to new systems. I've already seen a case at work where an encrypted laptop drive was fully intact and working, but the laptop it was in was dead and had to be replaced. The drive was a complete loss, because it couldn't be used as the boot drive in the new laptop (different manufacturer) and there wasn't any software that could be used to supply the boot password to the drive when connected by any other method.
    2. Suspend/hibernate. We've found that a lot of the laptop models where I work don't correctly handle returning from a suspend and/or hibernate state. The most common case is that the laptop simply returns to normal operation from the suspend state without requiring re-entry of passwords. Most users simply put their laptop into suspend state rather than powering it down, which means anyone stealing the laptop can completely ignore the drive encryption. Standard Windows screen locking doesn't help much, once the laptop's unsuspended it's network interface is active and it can be remotely compromised and the screen lock disabled.
    3. Law enforcement. If the drive encryption is truely secure, LEOs will insist on having a back-door to let them decrypt a suspect's drive to search for evidence even if the suspect won't give them the passwords. If such a back-door exists, it'll quickly be broken and software produced to gain access to an encrypted drive through that channel rendering the encryption useless.

    #2 can be dealt with going forward in the hardware and OS. #1 can be dealt with going forward with standardized encryption and hardware protocols. #3... is intractable.

    • Re:Three problems (Score:4, Insightful)

      by Creepy Crawler ( 680178 ) on Monday March 09, 2009 @02:50PM (#27124753)

      Then DM_CRYPT solves all three.

      1. There's a /boot partition which provides basic bootup services, like entering pass phrases. Any machine that can read standard HD's can read the dm_crypt system.

      2. Hibernate is inherently unsafe, unless the hibernation itself is encrypted. And once there, why not just fresh-boot? And about standby, require as a system policy to log out before standby. Then they must hack the standard system to get even a user account. Also, you did not specify memory holes like firewire. They're equally dangerous, if not moreso.

      3. Linux is open source, so we would see any attempted exploits in dm_crypt. There might be, but we'll find it eventually.

    • This standard they're working on would help with 1 and 2.

      Going with OSS would fix #3.

    • by blueg3 ( 192743 )

      #3 is pure paranoia. There are plenty of commercial and open-source encryption products out there, including full-disk hardware and software encryption. They don't have law enforcement backdoors.

      Sometimes hardware encryption implementations are absurdly broken (e.g., encrypting using single-key XOR), but if this is an intentional law enforcement backdoor, LE agencies are being awfully inefficient by reverse-engineering the devices to find ways to bypass the encryption (or paying commercial researchers to).

  • worthless. Proprietary, chip-based solutions are the opposite direction we should be going. An open source solution...and there are several great ones already what I use and recommend/setup for all my clients.
    Any and all of today's processors can handle the exertion necessary for on-the-fly encryption; most users (including, generally, myself) don't notice the difference.
    As per usual, I question SM's logic.
    • Re: (Score:3, Interesting)

      by afidel ( 530433 )
      How do you deal with the key in memory problem? That's right you can't without a hardware keystore, hardware is the only way to get true unbreakable encryption.
      • by Skapare ( 16644 )

        How do you deal with the key in memory problem? That's right you can't without a hardware keystore, hardware is the only way to get true unbreakable encryption.

        However, the hardware could encrypt the key with the public half of a PKC pair, store it in flash, making all your data available without needing to do any breaking at all, to whoever (agencies that don't exist) generated that pair and kept the private half.

        You don't even know that your CPU isn't doing that today. It could have some circuitry, or parallel acting firmware, that detects certain common instruction patterns that indicate software encryption is happening, and grab the key just like described ab

  • Bill of Rights (Score:3, Interesting)

    by OldFish ( 1229566 ) on Monday March 09, 2009 @02:38PM (#27124567)
    Just as important as the technology will be the legal framework that applies. Myself, I like the Bill of Rights and I want to see data storage be treated as an extension of my memory with all rights that apply to my testimony extended to the digital media that is protected by a key that is in my memory. I know, naive idealism is dumb.
    • by blueg3 ( 192743 )

      It's a much more reasonable analogy to treat information on digital media in the same way you would treat information written on paper, recorded on video- or audiotape, etc. Your memory (with current technology) is not objective physical evidence, wheras these others most certainly are.

  • by noidentity ( 188756 ) on Monday March 09, 2009 @02:48PM (#27124727)
    How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?
    • Re: (Score:3, Informative)

      by Skapare ( 16644 )

      How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?

      This can be done by making the actual encryption completely open, with open source reference implementations in software. The disk drive would have two operating modes. Without a set key, it would write and read the data bits in the raw. With the key set (and stored in the drive controller only in SRAM that's designed to instantly lose the key upon power loss), the drive encrypts writes and decrypts reads. The verification is to set the drive key, write some data, then erase the key, read it back, and d

    • If it is not securely implemented then people will break it and eventually one of these people will be a white-hat, and will let the community know. If the manufacturer had advertised that the drives were encrypted, and they were in fact not, they will be hit with some pretty damn big lawsuits. Even if the exploit was just a mistake they will likely lose a good number of sales over it.

      I don't think this is a risk that any of the major drive makers would be willing to take of for a quick buck. El-cheapo flas

  • My experience with hardware encrypted media makes me doubt anything good will come of this technology.

    We had a large number of encrypted thumb drives, at one point, and all of them died and needed to be reformatted in short order... they were simply more vulnerable to data loss when (for example) you pulled them "too soon". One vendor wouldn't even allow us to reformat them without sending them a signed letter from the CEO (on corporate letterhead) asking for the formatting utility, and then when we provided it we got no further response from them.

    We turfed all the "secure" thumb drives no matter what manufacturer and went back to application layer encryption.

    • Who's "them"? I want to know who to avoid.

      • by argent ( 18001 )

        I can't tell you who "them" is, this was back before I left $VBC, three jobs ago. But even the "best" (least worst?) hardware encryption was terribly fragile.

  • Flaws? So what. (Score:4, Interesting)

    by manif3st ( 699952 ) on Monday March 09, 2009 @03:06PM (#27124999)
    Personally, I can't wait for these to become commonplace. I use whole disk encryption not because I don't want my partner/friends accessing my data (my computer's on all the time anyway in an unencrypted state any business documents and porn are tucked away using TrueCrypt), not because I'm scared of LEOs or G-men (they're welcome to my files), but because I don't want some prick burgling my house, plugging in my hard drive to their computer, and posting my photographs and poking around looking for passwords to sell. So bring on the back doors, I can remember my passwords, and anyone with the knowledge to hack the hard drive to get at the data is doing it for more than my photos and old university papers. I can change my passwords faster than they can sell them.
  • If the key or passphrase is coded into the system configuration, the perp can see the data, anyway. So surely they would set up these systems so it is required for the assigned user to enter a passphrase for access, perhaps even periodically instead of just when booting or waking up. Then we are back to the weakness of people. Just flip the laptop over and get the key written on the bottom, or just find out the person's spouse's mother's dog's name.

  • by Ungrounded Lightning ( 62228 ) on Monday March 09, 2009 @05:26PM (#27127007) Journal

    Having the disk drive processor or special-purpose logic on the drive do the encryption/decryption is a fine division of effort.

    But until the firmware is open (and there's a way to check that it's what's really running) I won't use such a thing. (Except maybe in transparent mode with the REAL crypto being in software on the machine.)

    There are too many opportunities for data compromise with built-in, proprietary and closed, firmware encryption: Faulty design, government back doors, and bad-guy back doors to name just three.

"How many teamsters does it take to screw in a light bulb?" "FIFTEEN!! YOU GOT A PROBLEM WITH THAT?"