Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Data Storage Encryption Security Upgrades Hardware

Fujitsu HDD with AES 256-bit Encryption 220

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."
This discussion has been archived. No new comments can be posted.

Fujitsu HDD with AES 256-bit Encryption

Comments Filter:
  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Tuesday April 22, 2008 @11:37AM (#23159068)
    Comment removed based on user account deletion
    • by thegermanpolice ( 1194811 ) on Tuesday April 22, 2008 @11:43AM (#23159148)

      Why have encryption at the hardware level when you can use e.g. Linux's crypto device-mapper tool? That also allows you to keep certain partition encrypted for privacy and other partitions unencrypted for performance.
      There is certain ring of truth to what you say...
      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.
      • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Tuesday April 22, 2008 @12:26PM (#23159778) Journal

        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.

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

          I've been thinking about such compression lately, since TuxOnIce [tuxonice.net] (Linux's alternative hibernation system) uses LZF for faster saving and restoring of memory contents. LZO is even faster than that, probably unnoticeable in normal use.

          However, having used such compression schemes back in my DOS days (SuperStor et al), I recall one inherent problem. The compression ratios aren't easily predicted, so the effective free space is unknown, and depends on the kind of data. This is exaggerated now that a lot

        • by bytesex ( 112972 )
          Oh yes there is latency for software-encrypted hard-drives. My company won't allow any computer to run without an encrypted disk, and apart from the fact that it's a bitch to set up under Fedora, it /does/ slow down your access to the drive. Again, no benchmarks here, but the kcryptd process makes overtime on my machine.
        • by hemp ( 36945 )
          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.


          Why bother with actual data, it always just gets in the way of what you want to say.
        • by Kjella ( 173770 )

          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.

          Neither have I, but playing HD media from encrypted disks I know you're wrong. The overhead of decrypting a 40Mbit stream plus thst you can't use DMA directly to get data means it is significantly slower. However, for anything less intensive I doubt you'll notice much difference, and things only get faster. H.264 hardware acceleration on Linux would probably solve that one anyway...

      • Re: (Score:3, Interesting)

        You could also just use a hardware encryption accelerator, couldn't you? And that has the advantage of enhancing *all* your crypto, not just the disk-based stuff.
      • by dgatwood ( 11270 ) on Tuesday April 22, 2008 @05:57PM (#23164326) Homepage Journal

        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

        ...and significantly increase the odds of the crypto chip becoming a throughput bottleneck all while providing limited expandability.

        The reason to do encryption in software is that the encryption can be replaced as existing crypto techniques become thoroughly broken. If you have a chip that does it in hardware, you're permanently limited to a given crypto scheme and probably limited in how long the key can be. Thus, if we conclude in a year that 256 bits really isn't enough, you get to either buy a new drive that does AES512 or switch to software crypto. At that point, you've paid the added expense of the outboard crypto chip, but have gotten little from it.

        If you want to design something like this, start by creating a standard for communicating with crypto processors and creating a standard programming language for configuring these dedicated processors to handle various types of crypto. Put the control over the encryption in the hands of the OS where it should be, rather than in the hands of hardware manufacturers many of whom have repeatedly cut corners in their crypto implementations in the past. Do I trust crypto hardware? Not as far as I can throw it. How do you generate a good random number in such limited hardware, for one? How do we know they didn't incorporate a back door master key---two copies of the key that is actually used for encrypting the data, one encrypted with your AES key, one encrypted using a public key for the NSA or the Chinese government or even an organized crime syndicate---if we can't see the source code? How do we know that the AES key is even used to encrypt the data on disk at all and isn't just used as an authentication mechanism like those crappy "secure flash" devices? I mean, this entire concept just has disaster written all over it....

        Hardware crypto just doesn't make sense. I trust hardware to do one thing: execute programs. Anything that requires a greater degree of trust should be done in software so that it can be readily audited and subject to verification if desired.

    • Re: (Score:3, Insightful)

      by blueg3 ( 192743 )
      What does that get you? Good device-level encryption already has the performance level of an unencrypted drive.

      The danger to having encrypted data and unencrypted other partitions is that generally the "other partition" is your OS and such. (If your unencrypted partition is just storage for video editing, no problem.) You tend to leak information all over the place in this space.
      • Only if you use poorly designed software.

        I use an encrypted Disk Image(OS X) I have one app which i use regularly with that Disk Image. OS X let's you move all settings, preferences, and files to another location easily. So In order to even load the app, OSX tries to mount the Disk Image, which then asks for a password. The Disk Mounts and the app continues to load normally. Then using the app i can decrypt the files in question.

        I order for anyone else to access that, they not only need the app which is
        • Re: (Score:3, Insightful)

          by blueg3 ( 192743 )
          Software designed for this kind of operation certainly helps, though substantial information can still leak to disk. Core dumps, hibernation files, virtual memory pages help.

          Presumably, though, people who are considering whole-disk encryption are ones interested in running software that hasn't been well-designed and still having that data encrypted.

          Personally, I'd probably trust a virtual machine running off of an encrypted image more than hardware disk encryption, and it allows you to run applications that
      • Re: (Score:2, Insightful)

        by sshir ( 623215 )

        What does that get you? Good device-level encryption already has the performance level of an unencrypted drive.

        The main thing - security. Software is open to everybody for extensive audit. Hardware on another hand, while potentially faster, not easily accessible and as such presumed insecure by default (one of the axioms of cryptography).

        So if you need real security - you do in-software full disk encryption, if you need performance and deniability - go hardware.

        • by blueg3 ( 192743 )
          That really depends on the auditing process for the hardware. Closed-source software has no benefit compared to hardware.

          Software full-disk encryption is good, but true full-disk encryption that is secure is hard to come by. It also carries a performance penalty. In performance-critical applications, people are going to either choose hardware encryption or none. (Another axiom of security -- people will make the choices necessary to do their job efficiently. If security gets in the way, they will circumvent
    • by Anonymous Coward on Tuesday April 22, 2008 @11:53AM (#23159294)
      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.

      • Having a laptop stolen is a huge concern today. This will help ease that concern.

        Many companies are already implementing solutions for that. The company that markets PGP has a drive encryption solution for laptops that even requires entering a passphrase at boot time in order to decrypt and initialize the system.

        This might have the advantage of being faster though, which would certainly be attractive. Still, I use a PGP-encrypted laptop and I've never really noticed any performance degradation.

    • Re: (Score:3, Interesting)

      by mr_death ( 106532 )
      Why have encryption at the hardware level when you can use e.g. Linux's crypto device-mapper tool?

      For the crypto in software case, a motivated bad guy can sniff memory to determine the key and method of encryption. To sniff the crypto in hardware takes a bit more effort, but I'm guessing your friendly neighborhood NSA can do it -- if they don't already have a back door.
      • by afidel ( 530433 )
        Yeah for example they can use firewire DMA mode to read the crypto password from RAM. Since this is a hardware fault with the design of the Firewire spec there is no way to guard against it other than to turn off all firewire ports or remove them.
    • Re: (Score:2, Insightful)

      by Argilo ( 602972 )
      Encrypting in hardware rather than software has some security advantages. Keys can be kept out of main memory, preventing cold boot attacks [princeton.edu] which have been used to break Linux's software encryption. Also, software encryption can be more vulnerable to side channel attacks such as cache timing attacks [mit.edu] which have also been successful against dm-crypt.
  • by Anonymous Coward on Tuesday April 22, 2008 @11:37AM (#23159076)
    320GB is alot of child pornography.
    • No thanks (Score:3, Funny)

      by Anonymous Coward
      640k ought to be enough for anybody...

      Way more than enough.
      • 640k of child pornography is certainly enough to get you thrown in the FBI van.
        • Re:No thanks (Score:5, Interesting)

          by Dachannien ( 617929 ) on Tuesday April 22, 2008 @12:16PM (#23159624)
          Apparently, so is zero. [arstechnica.com]
          • Re:No thanks (Score:4, Insightful)

            by querist ( 97166 ) on Tuesday April 22, 2008 @01:18PM (#23160524) Homepage
            Unfortunately, it was not zero if the Ars Technica article is accurate. It was very close to zero, two cached thumbnail pictures, but apparently it was enough.

            It's frightening. According to the AT article, numerous computer experts offered their opinions that boiled down to "It's not his fault. The browser put them there and he didn't know they were there or how to remove them."

            I would be very afraid of a court that would throw out (supposedly) expert opinions just to gain a conviction with regard to a truly evil (imho) crime.
  • An encrypted raid volume on these.
    • Weakness? (Score:5, Interesting)

      by maz2331 ( 1104901 ) on Tuesday April 22, 2008 @12:14PM (#23159600)
      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.
      • The smart way to do it would be to generate the XOR stripes are generated from the cyphertext, creating no weakness.

        If you're cyphering after the xor stripes are created, well, it could create a weakness, but if the encryption is strong it shouldn't.
  • Key Storage? (Score:2, Insightful)

    by Anonymous Coward
    I fail to see how this is useful. The key is stored on the drive... and there are no authentication measures.

    Aside from the data bits on the physical platter being encrypted, how is this secure?
    • It's better than that other one that was on Slashdot a couple of months ago which completely lied about its encryption (it had none) probably
    • Re:Key Storage? (Score:5, Informative)

      by jandrese ( 485 ) <kensama@vt.edu> on Tuesday April 22, 2008 @11:49AM (#23159232) Homepage Journal
      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.
    • You can view the official press release [prnewswire.com] for more information.

      They claim that the drive generates its crypto key from a password supplied externally. However, they don't explain how it gets this password. I presume from the BIOS, but there's no solid info.

      It could be from the OS if the drive isn't intended to be a boot drive, but that would be very strange and limit its usefulness.
      • This is better then Hitachi's BDE technology then - they store the key on the harddrive itself, where it can be theoretically recovered.

        Hello proudfoot
        I will try to answer this to the best of my knowledge on the Bulk Data Encryption drives.

        The drive uses the password as a key to open the drive to the user of the password. The drive is always encrypted, the password simply is the final key to allow access to the drive. If the password is changed then that key will follow the new password. If there is no password the drives believes the password is still there, but it is enter automatically.

        The encryption key is set when the drive has a password set for the first time. The key can be changed by a HDDErase (version 3.2) (http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml) This will change the encryption key when the program is run. There is no physical way to access the encryption key and view it to find out what the sequence is. I am unable to provide you with the algorithm of the encryption. The encryption is set to 128-bit encryption.

        We have sent our hard drives with bulk data encryption to Data recovery companies with a password we set on it and did not provide it to them. They all tried an none of them were able to retrieve the information off the drive.

        You can visit: http://www.hitachigst.com/hdd/support/bulk_faqs.htm [hitachigst.com] if you have anymore questions.

        Regards,
        Kyle B.

    • No. It isn't. The particular article linked in the summary doesn't make that clear, but it's calculated over again every boot time. This article [news.com] has at least a bit more info.

      Don't leave it in standby mode...
  • Private key (Score:3, Funny)

    by Dishwasha ( 125561 ) on Tuesday April 22, 2008 @11:40AM (#23159116)
    Let's hope Fujitsu doesn't take after Microsoft "security" and embedd the private key in a dll of their driver or within the firmware of the drive.
  • Data Recovery? (Score:4, Informative)

    by b.thompson ( 542104 ) on Tuesday April 22, 2008 @11:43AM (#23159144)
    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.
    • Re:Data Recovery? (Score:5, Informative)

      by TheThiefMaster ( 992038 ) on Tuesday April 22, 2008 @11:49AM (#23159224)
      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.
      • If you don't have to enter the password every time you boot up, there might as well not be a password.
      • If you're expecting the average credit bureau or government agency employee to remember a 32-character password, you have either wonderful security because nobody will ever get the data or terrible security because there will be a sticky note.

        If you're generating a 256-bit AES key from less than 32 bytes of user input, then you're not really getting the full benefit of 256 bits.
    • Re:Data Recovery? (Score:4, Insightful)

      by Zonk (troll) ( 1026140 ) on Tuesday April 22, 2008 @11:53AM (#23159296)

      My question/concern that I've always had with encryption is how can I recover from a crash?
      Backups.
  • by neonman ( 544 ) on Tuesday April 22, 2008 @11:48AM (#23159214)
    your friends at the NSA ask Fujitsu for the back door.

    I'm going to stick with kernel-mode volume encryption.
  • Maybe this is a sensible design, and there is a software front end to the driver which passes a key you specify to the processor to encrypt data (with all the trimmings; keyfiles, salt, entropy etc), but all the enc/dec overhead is handled on-chip, not in main memory.

    Kind of like accessing a TrueCrypt volume on a networked machine, if you catch my drift.

    Then again, none of these devices seem to have been thought out properly... I'll stick to TrueCrypt volumes and cheap external drives (which, by the way,
  • by Phoenixhunter ( 588958 ) on Tuesday April 22, 2008 @11:58AM (#23159366)
    We encrypt our torrents, mount our flash drives with TrueCrypt, we use TOR /w SSL to browse anonymously...all in pursuit of maintaining privacy in an increasingly interconnected world.

    10 Years from now will we all be content with the promise delivered with quantum cryptography, traveling the globe with all of our data instantly available with 'unbeatable' security?

    Or will it continuously escalate to the point that we start seeing more and more networks running 'off' the grid? Transporting data in person as on-the-fly decryption becomes increasingly prevalent. (Here we come Johnny Mnemonic)

    • Can you point out the vulnerabilities in the techniques you cited? The problem is that existing techniques are not used or used incorrectly, not that SSH, AES etc are broken.
  • by Tridus ( 79566 ) on Tuesday April 22, 2008 @11:58AM (#23159372) Homepage
    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 [fujitsu.com]

    "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?
    • 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 [fujitsu.com]
      My first guess is that there is an ATA specification for the key management, either published or in the works. Someone should go and check because I won't get around to it today.
    • by Tsar ( 536185 )
      According to Fujitsu [prnewswire.com], the password is entered at power-up. I would wager that the drive incorporates a bootable utility in flash which presents the password screen, then logically switches the flash boot drive with the newly-accessible hard drive and boots normally.

      I'd hope that the drive stores the password data in auto-erasing SRAM to thwart anything like cold-reboot attacks [slashdot.org] at the drive level.
  • by Manip ( 656104 ) on Tuesday April 22, 2008 @11:58AM (#23159380)
    Please excuse my ignorance but I fail to understand how this could be faster.

    In a modern day computer the bottleneck is the long term storage (HDD, DVD Rom etc). Memory and CPUs are extremely fast by comparison.

    So I don't entirely understand how shifting encryption down the IO bus is really helpful.

    Plus by doing so you lose tons of functionality and if the implementation gets "broken" (AES gets cracked) then you are kind of stuck unless Fujitsu are going to release an update back-ported to all of their old drives (and a lot of hardware vendors can't even support stuff from a year ago, let alone several).

    Plus aren't laptops designed entirely around keeping the hard drive in almost a zero power state as long as it can?

    • by evanbd ( 210358 )
      Not all applications are IO bound. Some people are actually using their CPUs, and would like to offload the encryption.
    • Please excuse my ignorance but I fail to understand how this could be faster.
      Performing encryption in software takes multiple CPU cycles per byte.

      Performing encryption in hardware encrypts multiple bytes per cycle and takes none of the CPU's time since it is done on the disk's chips.
    • The IO bus being slow gives the processor on the drive plenty of time to get its work done before the results are actually needed.

      It'd be much harder for the drive electronics to decrypt the data fast enough if the interface was faster.

      When you're decrypting and encrypting on the CPU, not only are you using CPU cycles that could be doing other things, but you're also still waiting on the IO bus to move the data once it's encrypted. You're on the wrong side of the link.
    • by KZigurs ( 638781 )
      custom aes encryption functionality will definetely provide much better watt performance than leaving it on your cpu. Also CPU is not involved anymore (ie DMA writes) directly with data in/out of hdd.
      Even more importantly - provided you set up key init phase properly, keys are handled around in the hdd (where there is a chance of some specific protection) vs close to cpu/main memory where it is far easier to pull them in the plain.

      Someone obviously find those valuable, quite surely there is also more to tha
  • Hardware based? (Score:3, Interesting)

    by Thelasko ( 1196535 ) on Tuesday April 22, 2008 @12:01PM (#23159420) Journal
    Hardware based doesn't seem to mean much anymore. It seems to me that hardware based used to mean purpose built hardware to do only one task. Now it means "we put a tiny computer in the hardware." It's only slightly more secure than doing things like encryption on the OS because your just moving the work from one generic processor to another. If some malicious programmer knows what you are doing he/she could just as easily take over that "tiny computer in the hardware" as the CPU.

    It's simply security through obscurity.
    • You're right in certain situations, but I don't think this is to keep your computer safe from trojans placed in the drive firmware that report on the data while the computer runs later. It's designed to protect the data on a drive or computer that's stolen while it's turned off. You wouldn't use the computer again if it was recovered for fear of a trojan.
    • It's simply security through obscurity.

      The security gained from doing the crypto on the disk is only gained through obscurity. The security baseline in the crypto is security through crypto, not through obscurity.

      Hardware based doesn't seem to mean much anymore. [...] [You're] just moving the work from one generic processor to another.

      There are reasons to do this besides security. A big one is speed: crypto eats a substantial amount of resources (in particular for breakfast). By moving this to dedicated hardware, you free up your CPU to render the movie, compile the code, or whatever.

      Also, since the motivation is likely speed (they mention that explicitly in the

  • If the encryption is transparent to the OS, means that if i, dont know, open the disk, extract the plates and read it in some way (dont know how people recover data from phisically broken hard disks), will have all scrambled. But if i take the disk as a whole, and put it in another computer, or under another OS (even booting from USB or another OS, in the same PC) the data should be shown unencripted.

    If that is right, well, dont see where this is useful. If the hard disk is stolen, could be used directly, a
    • by Oscaro ( 153645 )
      One scenario where this would be VERY useful is (tah dah!) DRM.

      It all depends on WHO has the keys...
    • It is controlled in the BIOS like you say. You need a password to even access the boot sectors (I think it presents a "false" boot sector to the BIOS or something to ask for the password). That's how it works on my T61 here. I don't have the model they advertise here, but hard-drive hardware encryption has been around for a while. The passwords are also sensitive to a dictionary attack, so if you get the wrong one too many times, it'll disable access to the drive.

      Overall, it's really a pretty secure des
  • by BenEnglishAtHome ( 449670 ) on Tuesday April 22, 2008 @12:25PM (#23159762)

    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 [n-crypt.co.uk] has never answered my emails.

    Digisafe [digisafe.com] 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 [digisafe.com]) that are supposed to work with any IDE drive are simply non-existent in the marketplace. The whole range of products from Enova [enovatech.com] is tantalizing until you realize that you can't actually lay hands on any of it.

    For years, I've used Flagstone [stonewood.co.uk]. 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.

    • Which is why it's just better to go with TrueCrypt at the moment. While hardware crypto would ideally be better, the lack of good products you can actually buy means that right now, software is a much better solution. Buy whichever drive you want, and just use software crypto.
  • by pclminion ( 145572 ) on Tuesday April 22, 2008 @12:28PM (#23159806)
    I am intrigued. Perhaps somebody should write a boot sector virus which configures an AES password. That way the drive will become a brick with no possibility of recovery.
    • oh that's easy to fix.
      just set yourself up a program that tries all the possible passwords.

      then throw yourself into a cryostasis tube, wait 1 billion years, and hope that the hard drive is still working when the program's finished!
  • It is always good to hear of storage device manufacturers embedding
    encryption into their products. However, after reading this article,
    there are at least three concerns I am left with regarding Fujitsu's
    offering, along with every other offering of this sort.

    Firstly, AES-256 smacks of a marketing gimmick. AES-128 is perfectly
    sufficient for anything that anyone wishes to protect; nobody has ever
    discovered a weakness in AES-128 that would be cause for
    concern. Using AES-256 bloats the key size while providing a
    • My gut feeling is that the drive data are encrypted until the host computer sends the drive key to drive. All data on the drive are encrypted using drive key. The host computer might send the drive key either from BIOS or from an operating system that was booted from a non-encrypted drive. Hopefully, it does so in a method that isn't unattended.

      Attack vectors might include allowing the host BIOS to send the password, then boot using a thumbdrive; using a connector extension cable, power-up the drive and

    • by querist ( 97166 )
      I agree with your second and third points, so I will not comment further on those.

      However, I must take exception to your first point, if only from a technical standpoint.

      Doubling the key size dramatically increases the security in the one way that can be a standard for such things: the time it would take to perform a brute-force attack.

      2^128 is approximately 3E38. 2^256 is approximately 1.15E77.

      Since there have been no published successful attacks against AES in its full form (no reduced-round versions) wit
      • by Sancho ( 17056 ) *
        A 128-bit key will still fall before a 256-bit key when dealing with quantum computers trying to crack it. The speedup in cracking is not exponential, as it is with asymmetric encryption, though it is still significant enough to become a concern.
    • ...is really just ECB.
    • Re: (Score:3, Informative)

      Firstly, AES-256 smacks of a marketing gimmick. AES-128 is perfectly sufficient for anything that anyone wishes to protect; nobody has ever discovered a weakness in AES-128 that would be cause for concern.

      Two possibilities: We've seen dramatic weaknesses in md5 and sha1, and it's not impossible that something similar could be found for AES. A reduction from 128 bit security to ~96 or even ~64 bits of security would be a relative disaster; 64-bit ciphers are simply not secure anymore.

      Additionally, quant
    • Re: (Score:3, Informative)

      by Detritus ( 11846 )

      Firstly, AES-256 smacks of a marketing gimmick. AES-128 is perfectly sufficient for anything that anyone wishes to protect; nobody has ever discovered a weakness in AES-128 that would be cause for concern. Using AES-256 bloats the key size while providing absolutely no additional protection above and beyond what we already get from AES-128. Whenever I hear of a crypto product advertising AES-256, I am suspicious that the company is more concerned with marketing than it is with actually providing good level-

  • From what I read here this device does not add any more security than "software" based encryption (it's still software based, if you think about it). The only advantage is that it relieves the CPU of the tiny amount of clock cycles that it would normally use to do encryption.
    • by Sancho ( 17056 ) *
      There is at least one other advantage--the entire disk can be encrypted. In theory, this is OS independent, which is another advantage.

      Saving a few cycles can be significant. Even more significant may be the power savings. Since encryption on hard drives is probably most useful on portable devices (things which run on batteries), if you can save power by using a dedicated chip (which should consume less power than the equivalent CPU cycles required to decrypt), then there's another advantage.

      Assuming the
  • by Bender0x7D1 ( 536254 ) on Tuesday April 22, 2008 @01:05PM (#23160364)

    I'm guessing that most of the drives will be vulnerable to a dictionary attack. Every user will have to know the password, (and be able to enter it correctly), to boot up their machine, and if you forget the password, your hard drive becomes a brick. Enough people will be paranoid about forgetting their password that they will pick something short, simple, easy to remember and easy to type. In other words, they will likely choose a dictionary word of some sort.

    If an organization has their IT staff assign passwords to the drive, so they are hard to crack, users will just keep the Post-it note with the password glued to their machine. Either way, a great idea that someone will screw up.

    Users - making products insecure since the dawn of time.

  • If it's anything like the other 'hardware acceleration' that I've seen lately, like the Ethernet chip that has on-chip checksum verification, but is only single-buffered, so everything comes to a screeching halt while the checksum is calculated. Of course, with fast processors, caches, and multiple cores, it's much faster to calculate the checksum in software.
    • Or they completely screw up the checksum ala NForce4, and all your downloads end up becoming corrupted. The only way to remedy this is to completely disable the integrated checksum checking, which was your whole reason for buying said hardware in the first place.
  • If you take them literally:

    According to Fujitsu, "the key used to encrypt and decrypt data is cryptographically regenerated at power-on, and is not known even to the HDD when the system is powered off."

    Ah, so they generate a new key on power-on, and any data written last time, is essentially lost. This drive isn't worth anything for most conventional uses, but would make a great swap, /tmp, squid cache, etc. My laptop's swap works sort of like that (random key each boot), except in software.

    Of course,

  • to effectively secure data against theft or loss.

    I can understand how this protects you against data theft - as long as you don't keep the password scribbled on a PostIt stuck to your notebook.

    But how are you protected against loss? If you data is gone due to a head-crash or theft, it's gone. You've lost it, that that's often a huge problem.

  • The problem with Fujitsu has always been getting them to warrant their product. Most drives today come with a 3-5 year warranty while Fujitsu and Toshiba have been a stick in the mud selling mostly to OEMs and forcing you to get warranty replacements through the OEM. This means that after a year (in most cases) you don't get a replacement drive if it fails.

    I'd rather put my money in Seagate or Western Digital.

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...