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."
320GB is alot of child pornography.
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.
However disk encryption on the whole can and will slow computers down, not significantly on modern computers but it does.
By transferring the overhead from the CPU to the processor built into the hard drive there is no slow down to the overall performance of the computer
I don't know if any of you linux fans out there have performance/overhead stats on using the device-mapper tool, but for someone who is trying to get the best out of their processor, moving this process from software to hardware is the ideal solution.
your friends at the NSA ask Fujitsu for the back door.
I'm going to stick with kernel-mode volume encryption.
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.
This is totally necessary. Keep in mind that this is not geared towards the home enthusiast. In that case, you are right. Those who play around with Linux on their home machines can use the Linux software based encryption.
But in the enterprise, the ease of management of a built-in hardware-based encryption scheme can't be beat. And let's not forget that Window's dominates the enterprise market. Besides a few folk in the engineering department, nobody runs linux on their laptops. It's all Windows.
Having a laptop stolen is a huge concern today. This will help ease that concern.
They don't want to tell you, but here's what information they made available: http://www.fujitsu.com/global/news/pr/archives/month/2008/20080421-01.html
"The conventional response to this problem has been the use of BIOS passwords(4) and software-based encryption. Seeking a more robust form of data security, Fujitsu has now developed 2.5" hard disk drives with hardware-based AES encryption using industry-leading 256-bit key.
The built-in AES automatically encrypts all data when storing it on the hard disk drive and decrypts the data when read. Unlike software-based encryption, the key does not reside in the computer's memory. This makes it more resistant to attack and imposes no processing overhead on the CPU, optimizing system performance. "
Let the guesswork begin?
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Could using these in a RAID-5 configuration lead to a weakness due to the XOR stripes? Since the parity stripes are a combination of the XOR of all other stripes, and is generated from the plaintext data before the crypto chip, a smart cracker might be able to use it to find a pattern.
Apparently, so is zero.
Personally, I just implement my own encryption. An XOR cypher is very fast, but not very secure. That's why I run mine twice for added security.
Seagate has been most active in this space and the most disappointing. Seagate announced their encrypted drives a couple of years ago. Complete vaporware and required a custom BIOS, to boot. Seagate re-announced their encrypted drives about 7-8 months ago. A few of the Momentus FDE drives showed up in retail channels only to go out-of-stock/back-ordered in a matter of weeks. A month or so ago, Seagate showed their encrypted portable drives. Anybody seen one for sale? Seagate announced their encrypted SAS-connected and FC-connected server drives a couple of days ago. Availbility? Only to OEMs. I don't think even OEMs have access to the 1TB desktop disks that Seagate announced months ago and that's the model that home users and hobbyists would scarf up by the truckload if it were only available.
n-Crypt has never answered my emails.
Digisafe has a nice web site but I can't find any place to actually buy the drives.
Lots of other manufacturers, including some of the big ones, have made announcements but nothing has shown up in the retail channels. Even if you're willing to buy a new laptop to get the encrypted drives that are apparently going preferentially to OEMs, actually finding encrypted machines for sale on the web sites of the major players will have you clicking fruitlessly until your fingers cramp. Even the much simpler "bump in the wire" encryptors (e.g. from Digisafe) that are supposed to work with any IDE drive are simply non-existent in the marketplace. The whole range of products from Enova is tantalizing until you realize that you can't actually lay hands on any of it.
For years, I've used Flagstone. They're expensive and insufficiently large. But at least I can pick up the phone and order one of them and, lo and behold, actually receive it in the mail. Given the way the dollar is tanking and the size of the available drives, I'd love to have another choice. Realistically, I don't.
Call me back when I can drop an encrypted drive into my shopping cart at NewEgg. Until then, this is so much supremely frustrating vapor.
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!