Slashdot Mirror


Fujitsu HDD with AES 256-bit Encryption

An anonymous reader writes "Fujitsu today updated its 2.5" 320GB hard disk drive with automatic hardware-based encryption to effectively secure data against theft or loss. According to Fujitsu, the MHZ2 CJ series is the first hard disk drive in the world to support the 256-bit Advanced Encryption Standard (AES). The drive implements the AES hardware encryption directly into the processor chip of the hard disk drive, resulting in more robust security and faster system performance than software-based encryption."

4 of 220 comments (clear)

  1. Data Recovery? by b.thompson · · Score: 4, Informative

    My question/concern that I've always had with encryption is how can I recover from a crash? On a normal HD, if Windows won't boot (from a bad MBR or a failing drive), I could hook the drive up as a slave to another machine and start pulling data off of it. Is it possible to do this with any full drive encryption (software or hardware)?

    I realize that being able to pull data when hooked up as a slave defeats the purpose of encryption, but I would hope that there is some way (maybe with a key created prior to the failure?) to recover.

    1. Re:Data Recovery? by TheThiefMaster · · Score: 4, Informative

      It depends on where the encryption key is. If it's generated from the drive or stored on the drive, there's not really any security, you take the key with you to the new pc. If it's generated from the disk controller or motherboard serial number or similar, then you can't move it to another pc at all. If it has to be entered by a person then you have real security and the ability to move the drive to another machine if you want. However in that last case you have the annoyance of having to enter the key every boot.

  2. Re:Key Storage? by jandrese · · Score: 4, Informative

    Where do you see that? The article is so light on details that you can't have gotten that from it. I thought it would just install a bios module that asks you for the password when it boots, and use that password until it is power cycled or whatever. That should even be compatible with the hibernate mode of most laptops, which would make it useful against laptop theft.

    Storing the key on the drive with no authentication would be retarded, the only thing it would protect you from are those data recovery places that people who don't have proper backups use.

    --

    I read the internet for the articles.
  3. Re:Is this really necessary? by SanityInAnarchy · · Score: 4, Informative

    However disk encryption on the whole can and will slow computers down, not significantly on modern computers but it does.

    Really not significantly.

    I haven't done any benchmarks of the speed of the drive itself, though I suspect it adds some latency. But the actual CPU usage is insignificant, compared to just about anything else you might do on the machine.

    Seriously, ntfs-3g is going to be a MUCH bigger slowdown -- yet I've run ntfs-3g on top of dm-crypt, and it was still usable. Just did a quick "find /", and watched top, and while find itself occasionally climbed to 10% CPU (and on Linux, that means 10% of one core), the actual kernel crypt process never rose above 1%. It's now installing software updates, and the kernel crypto process just rose to 15%.

    Another statistic: After four days of using this computer since the last full reboot (hibernating every now and then), one crypt process has accumulated a little over an hour of CPU time. The other has a little over a second.

    Keep in mind, most software doesn't know how to take advantage of more than one core, so most people do actually have most of a core just sitting idle. That's why dual-core feels faster. If, under heavy load, the crypt process might -- maybe -- take 20% of that core, you're still not really going to feel it. And most truly CPU-intensive tasks, like games, video encoding, raytracing, etc, are not incredibly disk-intensive.

    All in all, I think that outside of embedded disks, the CPU time we spend on our storage isn't really relevant. At this point, doing some simple lzo compression may actually improve performance, as you're still going to be faster than the disk is, and reading less raw data from the disk takes less time.

    No, the real reason we're seeing this in hardware is because Windows will support it, and easily. I imagine there's a fair chance there's some BIOSes out there that do it in software, too.

    --
    Don't thank God, thank a doctor!