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

Comments

Is this really necessary?

[CRCulver]

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.

Re:Is this really necessary?

[thegermanpolice]

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.

Re:Is this really necessary?

[robizzle]

Because when you use hardware instead of software to do the heavy lifting, you don't see the performance hit and you benefit from encryption on all partitions. Or at least that is the idea, I can't find the read/write rates to make sure there isn't (much of) a performance hit.

Re:Is this really necessary?

[blueg3]

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.

Re:Is this really necessary?

[Anonymous Coward]

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.

Re:Is this really necessary?

[Anonymous Coward]

Is this really necessary?

Yes, but Linux's crypto device-mapper tool does not have state department mandated backdoors in it (well, they tried but due to the nature of open source the attempts were foiled). Hitachi likes trading in the United States (and other countries with both less and more authoritative regimes), so they pretty much have to make the crypto broken for government backdoor purposes.

So, it is necessary for the various hard drive manufacturers to come out with this over the next couple years. As the consumer realizes encrypting their data is the only way to maintain net neutrality and hopes to prevent government eavesdropping, simple solutions to the government's need to look at all your data are necessary. This is one of them.

Re:Is this really necessary?

[mr_death]

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.

Re:Is this really necessary?

[graphicsguy]

Yes, but Linux's crypto device-mapper tool does not have state department mandated backdoors in it (well, they tried but due to the nature of open source the attempts were foiled). Any evidence of either of these assertions? *That* would be informative.

Re:Is this really necessary?

[SanityInAnarchy]

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.

Re:Is this really necessary?

[willyhill]

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:Is this really necessary?

[peragrin]

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 kept separate, but to decrypt not one but two different 256 bit AES passwords.

Re:Is this really necessary?

[Argilo]

Encrypting in hardware rather than software has some security advantages. Keys can be kept out of main memory, preventing cold boot attacks 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 which have also been successful against dm-crypt.

Re:Is this really necessary?

[blueg3]

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 higher performance demands outside of your encryption sandbox.

Re:Is this really necessary?

[menace3society]

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.

Re:Is this really necessary?

[TeknoHog]

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 (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 of music/film data is already compressed, and we also have XML and similar types that compress easily.

Then again, this is not a problem for read-only filesystems. Also, decompression is usually much faster than compression. Linux's zisofs is a nice example I've used, though with modern tools like LZMA you could probably improve the compression ratio further.

Re:Is this really necessary?

[bytesex]

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.

Re:Is this really necessary?

[bytesex]

They also like to sell to many different regimes/nations, all of which are definitely not going to buy it when they other guy has access to their information. So it's in their own interest really, to be as backdoor-less as possible. Any /smell/ of favouritism toward an NSA-like entity anywhere, and their product is in the toilet.

Re:Is this really necessary?

[Anonymous Coward]

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

If crypto is so important, why isn't in the hardware? I know both Sun and Via have CPUs have have on-board AES and SHA hardware (among other algorithms).

You can now have wire-speed crypto (Sun's is benchmarked at 45 Gb/s), with commodity components in the rest of the system. You can disk and network encryption "for free".

Re:Is this really necessary?

[hemp]

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.

Re:Is this really necessary?

[William-Ely]

What's the point of this encryption if you can plug the drive in to another PC and read the data anyway? From TFA "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."

So what's stopping me from pulling this drive and reading the data on another computer if the act of reading data decrypts the information? How does the hard drive authenticate valid computers? Can someone explain please?

Re:Is this really necessary?

[Anonymous Coward]

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. Yes, but you're adding latency and eating I/O to get to and from the card. Better to have it on the CPU (like Sun has one or two of its Niagara-based chips). Hopefully more and more CPUs will do this and the software / libraries updated to use the new instructions (I think it's on the road map for Intel and / or AMD as well).

Re:Is this really necessary?

[sshir]

Any evidence of either of these assertions? *That* would be informative.

Google for Crypto AG fiasco.

The bottom line: if you really need cryptographic security - never trust solutions which are not subject to audit (i.e. not open source software/hardware)

Re:Is this really necessary?

[afidel]

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:Is this really necessary?

[sshir]

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

That's the thing - stolen laptop is a liability. In many cases corporations don't really care if the data (with private information like soc security numbers) got stolen - they don't want public embarrassment and legal consequences. So for them - these hardware things are of great interest (as a form of due diligence defense).

For real security - only open (audited) hardware/software solutions are acceptable.

Re:Is this really necessary?

[sshir]

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.

Re:Is this really necessary?

[Kjella]

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:Is this really necessary?

[blueg3]

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 it.)

Re:Is this really necessary?

[mr_death]

I wouldn't call it a hardware fault with the design of Firewire -- indeed, the DMA nature of Firewire (400Mb/sec) gives it a leg up on the transfer rate of USB (typical 280Mb/sec), which requires that the host cpu get involved.

That the DMA of Firewire can be pointed to host ram is an unintended consequence, and just reinforces the idea that only trusted devices should be connected to a system. I expect that Microsoft and others will get around to sandboxing the DMA target -- say, in a Virtual Machine distinct from the real machine.

Even if/when Firewire is sandboxed, you'll still be able to get the contents of ram via Ed Felten's "freeze the ram" exploit. Once again, if the bad guys have access to your system, you're screwed.

Re:Is this really necessary?

[SanityInAnarchy]

The compression ratios aren't easily predicted, so the effective free space is unknown, and depends on the kind of data.

Still, you should be able to get a reliable measure of the minimum free space. Just detect if compression ever made a chunk bigger than it was to begin with, and if so, store without compression.

The one disadvantage is that you can no longer be absolutely sure, once you've allocated some space, that it's available -- but you probably want to be using sparsefiles and such instead of pre-allocating anyway.

Re:Is this really necessary?

[SanityInAnarchy]

The overhead of decrypting a 40Mbit stream plus thst you can't use DMA directly to get data means it is significantly slower.

Meaning more latency, and more CPU usage -- but not, as far as I can tell, less throughput.

So, if it's a single-threaded h.264 movie, and you're using a significantly large cache in your player, you should be fine.

Re:Is this really necessary?

[CrazedWalrus]

There actually was some hullaballoo about this a while ago. Whatever became of it, I don't know, but the GP isn't exactly making baseless remarks, or rather, their baseless remarks are at least based on other baseless remarks from a while ago:

Network World

C|Net

From what I can find, it seems like it was mostly just unsubstantiated paranoia. I'm no expert, but I did see a Holiday Inn Express commercial once.

Re:Is this really necessary?

[dgatwood]

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:Is this really necessary?

[NuclearDog]

I don't think that's really as big of an issue as you think it is.

Anyone who's worried about protecting super-secret classified military secrets or something is worried about this.

Any company who just wants some way to help ensure that the thug that breaks into the company car and grabs the laptop onto which some idiot copied 220'000 SSNs wont be able to access them would be quite content with hardware encryption.

I don't know of it's an axiom of security, but it should be:

Most people don't give a half a shit about the data you're trying to secure.

Re:Is this really necessary?

[NuclearDog]

It's 2.5" form factor so it's probably meant for laptops which already have a means of locking drives, so I imagine it takes probably just takes advantage of this.

Re:Is this really necessary?

[AHuxley]

Sort of like Enigma, Crypto AG and Microsoft?

Re:Is this really necessary?

[dgatwood]

Enigma was a hardware cypher and was broken by stealing one, so yeah, that's a good example of hardware crypto being a bad idea. Crypto AG is a rather weak examples because there's no proof. I'd have probably said Microsoft, Clipper, and Dual_EC_DRBG, though only one of those is hardware. The fact that the problems in those software algorithms were identified, however, is a good example of why I trust software more.

Remember: Many eyes make all back doors locked. :-)

Re:Is this really necessary?

[AHuxley]

Reading your diplomatic cables in the press is not a great feeling :-)

Re:Is this really necessary?

[gr8dude]

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.

Unlike conventional methods, this one is immune to "cold reboot" attacks (when one extracts the keys directly from RAM), which were discussed earlier here on Slashdot.

Re:Is this really necessary?

[AmiMoJo]

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

Actually, a hardware AES implementation of the type used here can easily sustain 300MB/sec, the maximum SATA II allows.

The reason to do encryption in software is that the encryption can be replaced as existing crypto techniques become thoroughly broken.

AES is unlikely to be broken any time soon. By the time it is feasible to brute force crack it, the HDD will be have been long abandoned.

Keep in mind that even now 3DES is impossible to brute force for anyone not willing to spend millions on hardware. Having the encryption done in hardware also has the advantage of making brute force attacks much harder, because the drive only allows three attempts before needed a power cycle so you would have to dismantle or hack the physical drive to even attempt it.

Re:Is this really necessary?

[gabebear]

That's not really true in this case. If the drive allows access to the raw encrypted data and the key is known it is simple to audit the encryption hardware.

On the other hand auditing software is not nearly as easy. Anything less than full-disk encryption can be a nightmare to audit, it's very hard to tell where files are going to be stored, especially on a desktop machine. Software full-(disk/partition) encryption can be audited the same way as hardware encryption, but you have to deal with unencrypted kernels that are going to need to be upgraded at some point.

I see it as this:

• hardware
  • Limited access to audit encryption implementation, although AES is ridiculously simple to implement
• software
  • Requires unencrypted kernel to be stored on a disk

If I needed real security I'd use both.

Why do you think software is less deniable? If anything I'd say you have it backwards. If you store your kernel/bootloader on a usb drive and use something like TrueCrypt your computer has nothing but a drive with gibberish on it. It is much harder to deny you are using encryption when you have a hardware specifically designed to do just that.

Re:Is this really necessary?

[sshir]

That's not really true in this case. If the drive allows access to the raw encrypted data and the key is known it is simple to audit the encryption hardware.

That's very naive, to say the least.

First of all, nobody gives access to actual platter information - what they write there can only be recovered in a lab. So in worst case scenario an audit like you described can be fooled by on-the-fly encryption of written data.

But even if they correctly encrypt your data you don't know what else got written to the disk - i.e. the side channel information.

And just from the top of my head (simply to further disprove your point about effectiveness of such an audit)look here: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (p. 7)

So basically there are so many "holes" known and unknown, that without full disclosure of how they (Fujitsu) do that thing (including photolithography slides) such hardware encryption is unsuitable for "high stakes" situations.

Re:Is this really necessary?

[gabebear]

Are you suggesting that Fujitsu took the very simple AES encryption process and is for some reason storing extra data alongside it on the platter? I don't think my assumption was naive, I think you are either absurdly paranoid or trying for a straw man argument.

For a complete audit, yes, you would want to take the drive physically apart and make sure that it didn't store something stupid in eeprom or a cache as well as the platters, but you would also need to do the same for the keyboard, keyboard controller, motherboard, RAM, CPU, etc.

Handling of keys is always problematic, but hardware based systems potentially pass the key through much less hardware than software based systems. It is nearly inconceivable to create a software system where the key isn't at least stored in main memory and the CPU.

I guess you are right in a way, we won't have full security in Fujitsu's security until we break down their hardware and get the complete details for all the chips and the way that every part is manufactured...

Of course we won't get software encryption security until we break down our WHOLE COMPUTER and get the same data for every chip from every company. I'm sure glad you are sure every last component of your computer is fully secured.

Re:Is this really necessary?

[Alexpkeaton1010]

Besides what others have said about the advantages of offloading tasks to separate hardware, encryption is a task that is well suited to custom hardware. AES in particular can be implemented in a highly parallel manner, which allows relatively low-cost FPGAs or ASICs to perform the encryption at speeds that only a relatively fast CPU could achieve. From an efficiency standpoint, hardware-based encryption is simply better due to the nature of the algorithms.

Re:Is this really necessary?

[Anonymous Coward]

If 256-bit encryption can be implemented inexpensively enough to be added to hard drive chipsets, how come similar chips are not added to the network port. It would be nice to know my online postings, etc, are not being snooped on. I would prefer that to this, since I can reasonably control whether another person has physical access to my hard drive. It is a lot harder to control whether someone else is watching what I do or say on the internet.

Re:Is this really necessary?

[shmlco]

"... you should be fine."

Guessing again. However, Apple says otherwise, as their disk encryption system (FileVault) encrypts everything in a user's Home folder. Further, there's a tech note that says using FileVault with software like iMovie or Final Cut is contra-indicated due to the additional overhead.

Re:Is this really necessary?

[SanityInAnarchy]

Further, there's a tech note that says using FileVault with software like iMovie or Final Cut is contra-indicated due to the additional overhead. And that is video editing software, which I'd imagine is a good deal more intensive than movie playing software.

Re:Is this really necessary?

[aliquis]

ZFS supports compression (and on average I assume that they belive it will speed up the data fetching since compression/decompression are faster than the additional read/writes for most data.)

My mouth is wattering

[Anonymous Coward]

320GB is alot of child pornography.

Imagine...

[mulvane]

An encrypted raid volume on these.

How does it work?

[Xtense]

Sorry for being so ungoogley (no time at the moment, stuck working), but how does it work? Does it use a separate hardware decryption mechanism, or some form of driver/software combo?

Re:How does it work?

[calebt3]

From the summary:

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.

Re:How does it work?

[Xtense]

If this is indeed the only protection, it strikes me as totally unsafe - no external storage of keys/hashes/passes/whatever? The best it would do is protect you for the next couple of days before some creative hackers figure out how to extract the keys from the drive.

Re:How does it work?

[Major Blud]

Right, so if the drive is stolen and put in another machine, the AES key is included on the processor, which is part of the drive?

Re:How does it work?

[visible.frylock]

Looks it's fully in hardware.

My biggest worry is that things like this will be seen as a panacea and used irresponsibly. Sure, this type of setup is great for people who actually know what they're doing. But unfortunately, many could be lead into a false sense of security.

Dept. Health/Human Services: Look, we can let Tom carry around the database now, no problems.

Sure, until it gets stolen and the password sticky is found in the side pocket of the laptop bag. Of course, this is in no way the hardware's fault. But from the page above, Fujitsu is at least somewhat marketing this to larger organizations. Organizations which would do well to keep their organizational data on their own servers, only being remotely accessible through secure, non-persistent means.

Re:How does it work?

[Deanalator]

Presumably, they will just be using the standard ATA password extensions. Instead of just unlocking the device when the password is entered, it would also set the key in whatever hardware device is doing the crypto, and wipe it when the hard drive is powered down.

Note that I have not read the specs, that just seems to be the most logical way to design something like this.

Re:How does it work?

[gnick]

There were vendors showing off similar drives at a show here last year. (These may differ significantly - I dunno.) The drives at the show stored the keys on small devices similar to thumb drives. So, unless somebody also stole your key, everything was locked up. They actually had received approval for storing classified information (up to SRD I believe) on the drives without having to remove them and lock them up when not in use. So, if you're working and need to get up and grab some coffee/relieve yourself of your last cup of coffee/whatever, you could pull the key and take it with you rather than pull the hard drive and lock it up in the vault. Very convenient for folks working in that kind of environment.

Re:How does it work?

[mr_mischief]

The news.com story says the hard drive doesn't store the key at all. It's figured during the POST process within the hard drive's BIOS config and isn't known to the drive itself when the power is down.

What it sounds like is that if you keep the computer from booting, like a pre-boot password, the drive is utterly useless to a thief. If they can get it to boot instead of staring blankly at the password prompt, the thing will recalculate the key and go merrily on its way.

Hopefully it figures the key on stored CMOS config values so that if you reset the CMOS to get rid of the boot password it'll still not generate the right key.

Re:How does it work?

[mr_mischief]

I had this same question, but no. It figures the key at boot time.

Hopefully there's some way to keep the thing from figuring the key once it's stolen, as most people will try to, you know, use the PC as a whole before they resort to stripping the drives out of it.

Re:How does it work?

[tattood]

If that's the case, then all you need to do is put the drive in another computer without a boot password, and it boots. Pretty useless.

Even if the boot password is the way they do it, then you are still subject to people putting in weak passwords for the boot password, which again, defeats the purpose.

What they might do, is some sort of pairing with the laptop that it's installed in, and it will only be able to decrypt if it is in the original laptop. This would still require some sort of user-entered password to prevent a stolen laptop from being booted.

Re:How does it work?

[gmack]

What it sounds like is that the CNET author didn't know what he was talking about.

Fujitsu says it uses an ATA password so it's most likely using the password to generate the key.

Re:How does it work?

[Sancho]

Which is an interesting way of handling it. The press release also says that there is a key stored on the drive (they change this key to implement secure erase.) Here's how I envision this.

Each drive has a 128-bit key, and with a special command, can change the key to something random. This command is invoked when the Secure Erase function is requested.

The drive key is used as a salt to the ATA-password generated key. Normally, the ATA password just locks the drive, preventing it from being accessed. In this case, the drive probably has logic to create a 128-bit hash value from the ATA password. The 128-bit hash value would then be concatenated with the drive key to form the 256-bit AES key.

Now the ATA specification allows for 32-byte passwords, so realistically, they could allow for the user password to fully compose the 256-bit AES key (in other words, no hashing needed.) However this, in and of itself, does not allow for the extra key used in the secure-erase function. I'd be curious to know where that key is really coming from, and how it integrates into the encryption algorithm.

Re:How does it work?

[setagllib]

Now the ATA specification allows for 32-byte passwords, so realistically, they could allow for the user password to fully compose the 256-bit AES key (in other words, no hashing needed.) This is a terrible idea. The entropy of a user-memorable password is well below 256 bits, even if it fills the same space. Most bits in a byte aren't even printable, much less typable, in standard encodings, so even the theoretical maximum for a typed-in key is probably around 6 bits per byte. English averages out to around 1.1 bits per byte. Study entropy, it's very important for compression and encryption theory and even practice.

Even worse, if the key is recovered, you'd have the full password in plaintext. At least if you salt and hash it, even a collision on the resulting key does not guarantee you've found the passphrase.

Re:How does it work?

[Sancho]

I wasn't proposing it as a solution, just as how it might be implemented. I'm well aware of the implications on key space :)

Key Storage?

[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?

Re:Key Storage?

[Kamineko]

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?

[jandrese]

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.

Re:Key Storage?

[edelholz]

According to the press release, there's a password of sorts. I do not know how the drive receives it at boot time. I'd hope that there's a public key on the drive and one somehow supplies the private key, everything else is just senseless. Still, I fail to see how one could go about that.

From the release:

The key used to encrypt and decrypt data is cryptographically regenerated only when the correct password is received at power-on, and is unattainable when the system is powered off

The advanced secure erase feature immediately invalidates every piece of data just by changing the in-drive encryption key, making the stored data completely indecipherable.

Re:Key Storage?

[Anonymous Coward]

(I stand corrected)

Press release, with all the juicy details.
http://www.fujitsu.com/us/news/pr/fcpa_20080421-02.html

Re:Key Storage?

[keysersoze_sec]

It may be better than fake encryption, but it could be worse than nothing. Indeed, the word "encryption" creates an impression of security... but security against what? With a plaintext key stored on the hard drive, it doesnt really matter if the contents is encrypted or not.

Re:Key Storage?

[mr_mischief]

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 has at least a bit more info.

Don't leave it in standby mode...

Re:Key Storage?

[Anonymous Coward]

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.

Re:Key Storage?

[wkk2]

I wouldn't want to use this drive unless the encrypted data can be read in a raw mode so that the encryption can be verified so that an audit can be performed. I would also want the drive to cache the encryption key in some type of non-imprinting memory. It needs an external tamper input and environmental sensors that clear the key (hi/lo temperature, power out of spec. radiation/x-ray, etc.).

Re:Key Storage?

[jandrese]

While I'll agree with you on wanting a third party to verify that yes, it is actually encrypting your data (handing the drive off to a data recovery type place and see if they can get anything off of it should do the trick, since that's pretty much what an attacker would do), but all of the other stuff you mentioned are probably too paranoid for a consumer level device like this. I'm not sure what "non-imprinting" memory is either. I'm sure the key will be stored in volatile memory, but if you're worried about people deep freezing the drive while it's running so they can read the data out of the RAM chip later, well, that's a bit too paranoid for something that regular people might be able to afford. Maybe if Fujitsu encased all of the drive logic in epoxy? Ultimately any security measure could theoretically be defeated if the guy has physical access to your drive and the will (and budget!) to do it, Ultimately you have to choose which threats are most realistic and guard against them.

Re:Key Storage?

[Anonymous Coward]

Even among nerds, your humor needs some work. :-P

Re:Key Storage?

[Sancho]

I wouldn't use public key in places where it isn't necessary. They could effectively get the same results by using a salt, and changing that when secure-erase is chosen. If this is the case, then their wording was poor, but pretty close to accurate.

One concern I'd have in either scenario is what happens when you need to change the password?

Re:Key Storage?

[dimeglio]

The PinPad connector on the back of the disk is probably a clue on how it gets it's key.

Re:Key Storage?

[wkk2]

Some of my suggestions are relatively simple. Others might be over-kill depending on the application. A procedure to actively clear the key material is needed since non-volatile memory will retain much of its data for a long time. Removing a jumper could trigger this clearing so that the jumper could be replaced with a computer lid switch circuit if additional protection is required. I'm not suggesting that the product have resistive meshes and such but a little care to protect the key material is really needed. Non-imprinting memory can be as simple as relocating or complementing data derived from the key material every few seconds so it won't always be in the same place stressing the memory locations. There are also products that are designed to protect key material (Maxim DS3600, etc.) This part can help clear external SRAM, has tamper inputs, temperature and voltage monitoring. I believe it also non-imprinting key memory.

Re:Key Storage?

[setagllib]

I'm sorry, I couldn't read your post. Can you follow up by posting the key?

Re:Key Storage?

[kasperd]

I wouldn't want to use this drive unless the encrypted data can be read in a raw mode so that the encryption can be verified so that an audit can be performed.

Just my thought. I have seen so many storage encryptions with more or less severe flaws. I have yet to see one that was completely flawless. Even if they didn't intend to put in a back door they for sure have introduced some weakness. I am confident that given the complete specification of how it is implemented, I could point out at least one minor weakness. I'm not saying that storage encryption in hardware is bad, but you have to see it mainly as a performance optimization, and there should always exist an identical implementation in software. Doing it in the drive itself does have the advantage that you can tweak the logical and physical sector sizes, which allows using the few extra bytes needed for random IV and such. You can work around the limitation even in a software implementation of the encryption, but that comes at a cost in performance. Almost every storage encryption in existence was designed for performance and does not use that extra storage for additional security. The one encryption I have seen doing this right happens to have a few other flaws.

Re:Key Storage?

[Anonymous Coward]

How about storing the encryption key on a custom, manufacturer-provided USB flash drive -type device? For example, if you want to boot, you stick in the key, some code that runs on startup scans the USB for confirming devices, reads the key, and then starts decryption.

You store the USB stick on, say, your keychain. It goes with you. The harddrive goes elsewhere. Never the twain shall meet, until you want to perform decryption.

Re:Key Storage?

[lazyforker]

*Double* ROT 13. It's the only way to go.

Private key

[Dishwasha]

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.

Re:Private key

[Anonymous Coward]

Well the key has to come from somewhere if you ever want to read the contents. Unless you have a new encryption scheme that is both secure and allows you to decrypt without a key.

Re:Private key

[eln]

They have come up with a new scheme that allows decryption without a key, while still being secure. It builds on one of the earliest encyption techniques on the Internet, and is more than ten times more secure. The new technology is called "ROT-156".

Data Recovery?

[b.thompson]

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?

[TheThiefMaster]

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.

Re:Data Recovery?

[Zonk (troll)]

My question/concern that I've always had with encryption is how can I recover from a crash? Backups.

Re:Data Recovery?

[CastrTroy]

If you don't have to enter the password every time you boot up, there might as well not be a password.

Re:Data Recovery?

[loxosceles]

Those backups had better be encrypted (manually) as well. At least there you can use real crypto, not some ECB-mode AES garbage.

Re:Data Recovery?

[Anonymous Coward]

With chassis intrusion prevention you could require the key only after opening, but that won't prevent unauthorized boots.

Re:Data Recovery?

[phoenix321]

Your backups already are in a secure undisclosed location, are they?

Re:Data Recovery?

[mr_mischief]

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?

[Anonymous Coward]

I don't get why a 32 character key would be difficult to remember. If it was a random string of letters and numbers then yes, difficult to remember. Using a simple keyphrase however is just as memorable as a short password and provides the necessary length. Of course a keyphrase loses some effectiveness in the fact that much of it will be simple words, vulnerable to a dictionary attack, but combined with punctuation and maybe a few numbers and some proper nouns it should be sufficient.

Re:Data Recovery?

[blackjackshellac]

Imagine if you had 6 of them in a raid5 setup, boot time might be pretty tedious if one had to enter 6 (different, of course) passwords.

Re:Data Recovery?

[algaeman]

I would imagine that Fujitsu will use the same methodology as Seagate and Hitachi have used in their encrypted drives. When you set the HDD password, you generate the keys. You can have a user password and a master password. Since pretty much all modern BIOS' will recognize and prompt for a HDD password at boot, this works fine to secure it. You can even pull it and put in a new machine as long as you know the pass. There are utilities to reset a lost password, but since the keys will then be gone, the data will be gone. Because the HDD password only works on boot recognized drives, you cannot pull this drive and put it in an external enclosure (say to bulk move a user to a new machine).

Re:Data Recovery?

[m50d]

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

Using linux's software dm-crypt (LUKS), it's just a question of putting the disk in a machine with compatible software. If the header at the start of the drive is trashed you're in trouble, but the software makes it easy to back this up.

Re:Data Recovery?

[Anonymous Coward]

> Is it possible to do this with any full drive encryption (software or hardware)?

Yes, it is possible with the free and open-source TrueCrypt (at least with the Windows version).

Re:Data Recovery?

[Anonymous Coward]

However in that last case you have the annoyance of having to enter the key every boot. You mean you have the feature. Any scheme that doesn't require authentication on every boot is broken.

Incidentally, hard drives are already capable of doing this (there are standard ATA commands for it), they just don't do encryption, but rather rely on hard drives generally being something nobody takes apart. That's not going to stop a data recovery specialist, though.

Re:Data Recovery?

[Anonymous Coward]

However in that last case you have the annoyance of having to enter the key every boot.

Store it on a USB memory stick and just plug that in before you boot up.

Re:Data Recovery?

[mr_mischief]

If you're using dictionary words and punctuation, that's going to be easier to find automatically for the same number of characters. More characters does make the problem harder, though, so it's a tradeoff.

trust

[Anonymous Coward]

I wouldn't trust fujitsu to not turn over the keys to someone with black helicopters, sunglasses and guns.

More robust security unitl...

[neonman]

your friends at the NSA ask Fujitsu for the back door.

I'm going to stick with kernel-mode volume encryption.

Re:More robust security unitl...

[Anonymous Coward]

Yeah, this is a problem for me too. The NSA is always trying to get at my data. Bastards.

Re:More robust security unitl...

[netpixie]

I was about to ask how encrypting the data is going help secure against "loss".

Obviously, if the disk goes bad, the data is lost, irrespective of whether it's encrypted or not.

But if it is all "backed up" by the NSA then that explains their marketing claim.

Re:More robust security unitl...

[Anonymous Coward]

neonman, you are 100% correct. Reminds me of the clipper chip fiasco.

Honestly, how can you possibly trust Fujitsu not to put a backdoor into this device? It is too simple for them to use a custom ASIC with no documentation and it's virtually impossible to prove that the device is secure for the user.

Want true security instead of a false sense of security? Take noenman's advice. Stick to software solutions, preferrably kernel-mode encryption.

Re:More robust security unitl...

[Anonymous Coward]

What backdoor? This is particularly scant on details; however, let us look at this in two potential ways:
Scenario 1: Key is stored externally to a USB device to perform disk decryption (or the USB device contains the a key used to decrypt a key stored to the device). If this is the case, there is no key on the device for the NSA (or anyone else) to have direct access to without the USB device. In case you were not aware, AES is very secure and has no known "backdoor". In fact, if it had such a flaw, I doubt it would be part of the NSA's Suite B encryption algorithms.

Scenario 2: Key is stored locally to the drive without any encryption. This isn't technically a backdoor, so much as it is a bad design. Honestly, if the device does store the key is this manner, you are no more secure then if the drive is unencrypted since the secret value protecting your data is stored with your data and in plain view.

Re:More robust security unitl...

[grassy_knoll]

Damn... you must have a hell of a pr0n collection.

Re:More robust security unitl...

[Anonymous Coward]

Who needs the NSA? I'm sure the tech support guys who know the formula for converting a drive's serial number into it's "emergency" backup password are paid minimum wage, assuming they're even in the US.

No thanks

[Anonymous Coward]

640k ought to be enough for anybody...

Way more than enough.

Re:No thanks

[Malevolyn]

640k of child pornography is certainly enough to get you thrown in the FBI van.

Re:No thanks

[Dachannien]

Apparently, so is zero.

Re:No thanks

[querist]

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.

Maybe we're being too hasty...

[L4t3r4lu5]

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, are more than responsive enough to access DVD video and high quality OGG audio from).

DVD's I own, and OGG from Jamendo.com, obviously.

The keyhole....

[PiSkyHi]

Its just like a Hardened steel door with a deadlock that they have conveniently silver soldered the key into the keyhole so you won't lose it.

You won't even notice how well the door is securely locked down!!

- just don't look at the handle closely and ask your friends not to look at the handle closely too.

Encryption's End Game?

[Phoenixhunter]

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)

Re:Encryption's End Game?

[jsoderba]

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.

Re:Encryption's End Game?

[lymond01]

all in pursuit of maintaining privacy in an increasingly interconnected world.

Privacy from places that aren't law enforcement agencies...they can still poke into your laptop and ask you for the key at the borders.

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)

I wouldn't be surprised if the Internet becomes an unregulated wilderness where individual packets are in jeopardy. Private networks, virtual or not, will be the safe havens, and anyone running a public anything will always be taking a chance.

Hmm. Guess it's like that now. :-)

Re:Encryption's End Game?

[Anonymous Coward]

I agree, embedded easy to use strong encryption will change a lot of things, especially for ordinary Joe Sixpack.

Best thing is obviously the no need to worry about stolen, broken or otherwise lost drives.

But seriously, you will be asked those keys by the officials if there is a need and you will find it hard time deny the access knowing what the consequences might be for you.

NSA, GCHQ and other such agencies find the backdoor in a way or the other. They can't afford not to.

But issue that I'm currently thinking most is will this start and other period of dark ages from the point of historians?

ac

So where is that key anyway?

[Tridus]

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?

Re:So where is that key anyway?

[TechyImmigrant]

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

Re:So where is that key anyway?

[Tsar]

According to Fujitsu, 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 at the drive level.

Re:So where is that key anyway?

[Anonymous Coward]

If the key is "industry-leading", it shouldn't be too hard to find.

Re:So where is that key anyway?

[Anonymous Coward]

Is that so the CPU doesn't know whats on the drive?

Actually, there are authentication measures.

[Valdrax]

You can view the official press release 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.

Re:Actually, there are authentication measures.

[proudfoot]

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 if you have anymore questions.

Regards,
Kyle B.

Re:Actually, there are authentication measures.

[Anonymous Coward]

they store the key on the harddrive itself

It sounds like (based on the fact that the key is set when the password is set) they do something along the lines that cryptsetup/LUKS does for dm-crypt devices: a key is generated, then encrypted using the password given by the user, then stored in the device itself (this is similar to some modes of PGP, where your public key is actually used to encrypt a random "session key" that then encrypts the message and is bundled in with it. Also SSL.). You could read the encrypted key, but without the password, you wouldn't be able to decrypt the key. You could try brute forcing the password, but since the key is just random bits, any random password you attempt to decrypt it with would also result with random bits, so it's not like decrypting a JPEG or something where you can figure out whether you're right or not based on the header in the first few bytes. You'll have to take each potential decrypted key and decrypt enough of the filesystem to determine whether you're looking at a valid filesystem or not.

The search space for brute forcing such an arrangement is likely to be smaller than that of a 128 bit key, but it's far easier for the user than memorizing 32 hex characters (or a passphrase long enough to generate 128 bits of key material).

Other "benefits" include storing the same key encrypted multiple times with different passwords. This would allow several users revocable access to the same resource (if you don't trust them anymore, remove the key matching their password). Because of this arrangement, it IS possible that Hitachi has a "backdoor" key to the drive... If they do it this way.

Re:Actually, there are authentication measures.

[proudfoot]

Nope - in my initial email, I asked them if the key was encrypted by the password - and also what algorithm was used to generate the key. The key isn't encrypted - it's stored in a special section of the harddrive, and the chip only allows access to that section if the correct password is given.

How could this be faster?

[Manip]

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?

Re:How could this be faster?

[evanbd]

Not all applications are IO bound. Some people are actually using their CPUs, and would like to offload the encryption.

Re:How could this be faster?

[TechyImmigrant]

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.

Re:How could this be faster?

[Anonymous Coward]

Have you even worked with encrypted partitions etc. ?

Something like AES 256 bit encryption is quite a strain on the CPU, especially if it isn't the fastest in the world.

The bottleneck isn't only the storage.. why do you think they keep making new CPU's ?

Re:How could this be faster?

[mr_mischief]

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.

Re:How could this be faster?

[KZigurs]

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 that than I can imagine off the top of my head.

Re:How could this be faster?

[m50d]

Have you even worked with encrypted partitions etc. ?

Something like AES 256 bit encryption is quite a strain on the CPU, especially if it isn't the fastest in the world.

I've been using encrypted partitions for about a year and a half now, and sure it shows up in top, but I've never noticed a practical effect. I've tried moving videos I was having trouble playing (throw 1920x1080 H264 at my machine and it starts showing its age, alas) onto unencrypted partitions, and it never made a noticeable difference.

Re:How could this be faster?

[Anonymous Coward]

Because it is done by a specific chip which only knows AES. The bottleneck is still there but it is faster done by this chip than by your Pentium Core 2, which is a sage in comparison but, as sages are, slow...

Pedro.

Re:How could this be faster?

[devilspgd]

The chip is custom designed with one purpose in mind: AES.

As long as it can perform it's encryption/decryption tasks at least as fast as the drive's own read/write rates, it will not cause a performance problem at all.

Implementing anything in software will have the potential to impact any CPU-bound process which happens to be processing while IO is occurring.

Hardware based?

[Thelasko]

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.

Re:Hardware based?

[Anonymous Coward]

You seem to think that the security of an AES hardware-based encryption derives from being done by "purpose built hardware" instead of "a tiny computer in the hardware". It doesn't matter how it is performed at all, and it doesn't matter that the AES algorithm is publicly known. With a good encryption algorithm, knowing how it is done doesn't help you (very much) with cracking it.

A true "security through obscurity" mechanism that Fujitsu could have come up with is some proprietary mechanism where they just assumed nobody could figure out what they were doing and wasn't subjected to any third-party analysis (such as AES was subjected to).

Re:Hardware based?

[Thelasko]

If it doesn't matter where the encryption takes place, what is the purpose of this device?

Re:Hardware based?

[mr_mischief]

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.

Re:Hardware based?

[Anonymous Coward]

Performance mainly. Some value in having cross-OS compatibility

Re:Hardware based?

[PitaBred]

Rather than having the gateway on the CPU end of the drive accesses, we can still use DMA accesses to read and write to the drive and it's encrypted/decrypted by a special-purpose chip rather than the CPU? Really, it's putting the encryption so there's the least data remangling happening, and freeing the CPU to do more general purpose things rather than easily ASIC'able operations.

Re:Hardware based?

[jonaskoelker]

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 article), it would seem natural to put the crypto into a custom-built circuit; that way you can do stuff in parallel and be limited speed-wise only by the propagation time of the voltage across the wires. If you know that Fujitsu doesn't do this, please provide a quote (I'm merely curious, not accusing your of lying).

While you may be correct, it's like accusing a screwdriver of being lousy at playing soccer: that's not what they're meant to do.

Re:Hardware based?

[Alexpkeaton1010]

AES encryption using an FPGA was a grad school project for me, so hardware based without a soft-core CPU is fairly easy.

Scenario where this is useful?

[gmuslera]

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, and if not, you will lose your last chance to recover some info from it if broken.

Or you control the encryption from BIOS/1st boot, store some key in your BIOS or somewhat near, and if you put that disk in another machine wont be possible to read it (without a keyphrase?), but still, dont see it to be very useful (if you will steal the HD, well can steal the whole machine unless is somewhat a monster).

The 3rd alternative is that there is some existing protocol to deal with hardware encrypted media in windows/linux/whatever so is somewhat cooperative between both, at least if it supports having unencrypted partitions or you have to boot from somewhere else. But dont know it this exist.

Re:Scenario where this is useful?

[Oscaro]

One scenario where this would be VERY useful is (tah dah!) DRM.

It all depends on WHO has the keys...

Re:Scenario where this is useful?

[PitaBred]

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

Weakness?

[maz2331]

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.

Re:Weakness?

[Firethorn]

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.

Re:Weakness?

[Anonymous Coward]

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. no, presumably you would use a different key for each drive. The disk controller/OS (whatever is doing the RAIDing) would provide key for communication and then go on its merry way as if there was no encryption. The point is that it is transparent encryption.

Re:Weakness?

[Anonymous Coward]

No. Next question?

Re:Weakness?

[DogFacedJo]

If only one of the drives is encrypted, then remove it and recover it to a non-encrypted drive. Clearly this is not what you are talking about.
    With several drives, all encrypted, you should be good, bugs in the _implementation_ notwithstanding.
    Whether the drives have the same keys or not doesn't matter - a drive has to be block encrypted since it's random access and thus 5 drives with the same key aren't much different than 1 drive 5 times as large.
    Any info that can leak out of five drives striped could just as easily leak out of a single appropriately arranged file on one drive.
    If AES is implemented properly that would mean no significant info in both cases.
    Since the application is closed source, in 'hardware' (firmware/fpga? who knows) we'll just hope it's secure. For a corp, it means that they are less likely to be successfully sued for being security idiots, though - which is likely what would drive such purchases.

Re:Weakness?

[kasperd]

Could using these in a RAID-5 configuration lead to a weakness due to the XOR stripes?

Since the disks would be encrypted with independent keys, such a vulnurability is highly unlikely. Actually such a raid setup does have an advantage. Whenever you replace a disk with a new one, you get your old data reencrypted under a new key. So no problem in returning defective disks to the vendor. The problem is key management. The simple, but not most secure, way of doing it is to just encrypt the key of every disk using the same password. A much better way would be to secret share the keys across all the disks (and reshare them when a disk is replaced). If implemented that way somebody who got all the disks leaving your raid would be unable to decrypt it even if they knew your password, since they would only get one share of each version of the sharing. And once they get the first sharing, the previous one would be destroyed. The "problem" with that approach is, that it cannot be implemented directly on the drive, since something have to do the secret sharing computations. So that would have to be implemented either in the OS or a raid controller. And if encryption is done by the disk itself, it is not certain that it would give you access to read and write some areas without encryption, which is what you would need to do your own key management.

Prediction: Availability will suck

[BenEnglishAtHome]

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.

Re:Prediction: Availability will suck

[CastrTroy]

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.

Re:Prediction: Availability will suck

[Anonymous Coward]

Complete vaporware and required a custom BIOS, to boot. Nice pun.

Re:Prediction: Availability will suck

[Anonymous Coward]

I have owned one of the Seagate FDE drives since August. I got it in a Lenovo laptop. The encryption is done in hardware based on a key generated by the TPM chip on the system board.

Using a BIOS hard disk password will successfully lock/unlock the disk. The catch is: that BIOS password only works in combination with that TPM chip.

If your system board gets replaced, you had better hope you removed the BIOS password prior to the board getting fried or have good backups.

A FDE drive with an assigned BIOS password will only work with the original TPM chip unless you remove the assigned password using that TPM chip. You can assign/remove the BIOS password as often as you'd like.

Re:Prediction: Availability will suck

[Anonymous Coward]

I could have sworn I saw encrypted Seagates for sale while I was in Japan. Of course, my Japanese-reading-ability is virtually nil, but by what Engrish I could make out, there are tons of encrypted drives for sale over there. I've never SEEN so many types of encrypted drive. ...which makes me wonder, what it is that they are so afraid someone will see. Especially considering that I saw a guy on the train openly reading a lolicon comic (which is basically cartoon child pornography). If THAT is OK, what could they possibly be hiding??

Re:Prediction: Availability will suck

[Anonymous Coward]

Here's one. http://www.newegg.com/Product/Product.aspx?Item=N82E16822145159

As an evil genius this intrigues me.

[pclminion]

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.

Re:As an evil genius this intrigues me.

[Kingrames]

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!

Crypto requires good integration

[omnirealm]

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 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-headed security.

Secondly, how "hardware-based" is this product, really? More often
than not, crypto modules are implemented in firmware, and sometimes
they can be attacked, up to and including replacement of the
microcode. Is this an open implementation? How do we know we can trust
it? Is there any kind of key escrow going on? Is the chip using CBC
mode while using a predictable IV? If so, then the drive may be
susceptible to a chosen-plaintext attack. On Linux, we can directly
inspect the code for TrueCrypt, dm-crypt, eCryptfs, EncFS, and so
forth. The users, not the manufacturers, have complete control and
transparent knowledge of exactly what is going on under the
covers. How can we know we can trust the "hardware-based"
implementation shipping on these drives?

Thirdly, the fact that "the key does not reside in the computer's
memory" does not necessarily help you much. Perhaps the symmetric key
used for the bulk encryption and decryption of what goes out to the
disk sectors stays on the drive's processor chip, but what does that
buy you in terms of real security? The entire crypto system needs to
be evaluated around its weakest point, which is almost always key
management. If the BIOS has to send a passphrase to the drive to
"unlock" that on-chip key, then who really cares if it is using
AES-256 or if it keeps the 256-bit key on the drive? An attacker only
needs to attack the passphrase, which is typically significantly
weaker than the 256-bit key, and then simply ask the drive to hand
over its contents.

Some crypto protection is better than no protection at all, but we
also do not want people to buy these drives and then have a false
sense of security. Crypto, like any other form of security, is not
really something you can bundle up and sell as a stand-alone product
to customers. Security needs to be integrated into the entire system,
because any individual component (such as an encrypting storage
device) can be rendered completely ineffective if it can be
circumvented by some action elsewhere in the system.

Re:Crypto requires good integration

[Marillion]

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 host system, then switch cable to another system; connect a "dummy drive" to the host computer and wait for the host system to send the key.

The bottom line: Encryption is hard.

Re:Crypto requires good integration

[querist]

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) with a "normal" sized key (128 or 256), the "best" attack other than exploiting an implementation flaw would be a brute force attack. (Being better than brute-force is one of the benchmarks to determine if the "attack" "works".)

Granted, in either case we are looking at a very, very long time and massive amounts of computing power to brute force AES 128 or AES 256. However, we are also looking at nearly 39 orders of magnitude difference.

Given the current state of the available technology, going from 128 to 256 bits in the AES key makes no practical difference, but from a mathematical and cryptological standpoint, the difference is significant.

Also, as computers become faster and more powerful, the 128-bit key will fall long before the 256-bit key (barring quantum cryptography living up to the hype).

Re:Crypto requires good integration

[DamnStupidElf]

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, quantum computers can theoretically break symmetric ciphers in sqrt(n) time, which means that AES-128 could be broken this century. Assuming both a mild algorithmic reduction and quantum computing, AES-256 looks secure until the next century, if not longer.

Also, AES-256 really only takes 40% longer than AES-128 for practical purposes, since AES-128 has 10 rounds and AES-256 has 14 rounds.
Finally, AES-192 and AES-256 are authorized for TOP SECRET classification, while AES-128 is not. That's a pretty big market Fujitsu would be cutting out by only offering AES-128.

Re:Crypto requires good integration

[Sancho]

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.

Re:Crypto requires good integration

[Detritus]

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-headed security.

The NSA disagrees with you. They require AES-256 for the protection of TS (Top Secret) data. AES-128 is only authorized for the protection of data classified as Secret and below.

Re:Crypto requires good integration

[omnirealm]

> Two possibilities: We've seen dramatic weaknesses in md5 and sha1,
> and it's not impossible that something similar could be found for
> AES.

MD5 and SHA1 are one-way hashes. AES is a symmetric cipher. The
weaknesses found in MD5 and SHA1 have nothing to do with
AES. Weaknesses have been found in symmetric ciphers like Skipjack,
however, and that would have been an appropriate example.

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

A reduction from 256 bits to 96 bits would also be a disaster. So long
as we are spreading FUD about an imaginary attack against AES-128,
why not go all the way to AES-256?

We have discovered absolutely no cause to be concerned about a
possible reduction of the effective key length of AES, regardless of
whether it is 256 bits or 128 bits. Until we get some sort of
indication that perhaps this might be a possibility (we need this
thing scientists like to call ``evidence''), we can say with some
degree of confidence that AES-128 really provides 128-bit key
protection.

> Additionally, quantum computers can theoretically break symmetric
> ciphers in sqrt(n) time, which means that AES-128 could be broken
> this century. Assuming both a mild algorithmic reduction and quantum
> computing, AES-256 looks secure until the next century, if not
> longer.

You are referring to Grover's Algorithm. You have to make up
some nonexistent quantum computing device with log(n) storage
capacity. We are nowhere near actually constructing such a beast; to
date, we have only solved the most trivial problems relating to
quantum computers. Tell me about your plan to resolve quantum
decoherence (just for starters), and I will start taking your
boogeyman quantum computer attack seriously. Personally, I would
rather be holding my breath for cold fusion.

> Also, AES-256 really only takes 40% longer than AES-128 for
> practical purposes, since AES-128 has 10 rounds and AES-256 has 14
> rounds. Finally, AES-192 and AES-256 are authorized for TOP SECRET
> classification, while AES-128 is not. That's a pretty big market
> Fujitsu would be cutting out by only offering AES-128.

This is the only legitimate point you have brought up: marketing. Of
course, that is exactly the point I originally brought up too.

Re:Crypto requires good integration

[omnirealm]

> The NSA disagrees with you.

Due to the key management issues I brought up, I disagree with
using these storage devices as adequate means for protecting
anything near top secret. No use putting a titanium padlock on a
cardboard box.

Re:Crypto requires good integration

[DamnStupidElf]

We have discovered absolutely no cause to be concerned about a possible reduction of the effective key length of AES, regardless of whether it is 256 bits or 128 bits. Until we get some sort of indication that perhaps this might be a possibility (we need this thing scientists like to call ``evidence''), we can say with some degree of confidence that AES-128 really provides 128-bit key protection.

Once a break is found, hindsight is of no real use. Everyone said MD5 was secure up until the weakness was found. My point was simply that for a few strong cryptographic primitives, we have seen several orders of magnitude reduction in strength. Who knows what XSL and its derivatives will bring?

You are referring to Grover's Algorithm. You have to make up some nonexistent quantum computing device with log(n) storage capacity. We are nowhere near actually constructing such a beast; to date, we have only solved the most trivial problems relating to quantum computers. Tell me about your plan to resolve quantum decoherence (just for starters), and I will start taking your boogeyman quantum computer attack seriously. Personally, I would rather be holding my breath for cold fusion.

Yes, sometime within the next 50 to 100 years we have to design a quantum computer that doesn't exist yet. Personally, I'd bet almost any amount of money with you that a practical way to construct "reasonably" large quantum computers will exist within 50 to 100 years. For one thing, I'll probably be dead in 100 years, and for another inflation will have taken care of the value of any bet we make today. In practical terms, there are few secrets that need to be protected for 50 to 100 years, except perhaps nuclear secrets (which will most likely be just as dangerous in 50 years as they are now), but for the small trade off in speed between AES-128 and AES-256, is there even a reason to take a chance? Many people thought 10 rounds was too low during the initial NIST competition, given the higher number of rounds most other applicants used.

This is the only legitimate point you have brought up: marketing. Of course, that is exactly the point I originally brought up too.

Don't flatter yourself; you said it was a meaningless marketing ploy when it's actually a legitimate response to government requirements (whether the government's requirements are reasonable is a completely different story).

Useless

[Thelasko]

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.

Re:Useless

[Sancho]

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 hardware is done right, you have the advantage that it's idiot-proof. You can give people an encrypted partition, but that doesn't mean that they'll use it. Even if they do, temporary files may be store data outside of the encrypted partition.

So there are a few good things about this device, assuming it's implemented correctly. Unfortunately, due to companies being highly secretive, we'll probably never know for sure whether or not it's implemented correctly.

Secure, yeah right.

[Anonymous Coward]

I trust that chip to not have a backdoor in it about as much as I trust my cat to leave the steak on the counter alone. You would be foolish to assume that your data is safe from government or law enforcement eyes.

I'll stick with open solutions. Thanks.

It has a backdoor.

[Anonymous Coward]

Well, the FBI is concerned about compromised hardware of hostile foreign origin. "The threat is real".

It would be foolish to assume there wasn't a backdoor for someone. The question is who, and why should you trust them? The government? Intelligence agencies? Yours? Theirs?

it won't help

[JeanBaptiste]

when I tie you up and beat the crap out of you until you give up your password. I can do it, I'm a big guy and I'm good with knots.

Re:it won't help

[neonman]

Yours is a commonly-cited, but ultimately fallacious argument. The difference between getting the key through a back door and getting it through coercion is that when you force me to give it up I know about the breach of my privacy. It's also more likely to require a proper court subpoena under those circumstances. Even if I ultimately give in to the interrogation, at least I know what I've lost.

Furthermore, let's say the NSA captures my drive, but because of my line of work I'm in command of a nuclear submarine. Better that they have to get the key from me than get a backdoor from Fujitsu which retrieves it out of secret registers in the ASIC or exploit some intentional vulnerability in the implementation.

Also, I'm an escape artist, and a sailor, so I'm good at untying knots. :P

Re:it won't help

[magarity]

I'm in command of a nuclear submarine
 
We have to know: how long does it take to load /. over ULF? It's a wonder you're able to post in any topic newer than 3 days old!

Re:it won't help

[realthing02]

Yeah, but he probably won't be fired for being taken hostage and beaten. He might be fired for taking the unencrypted, company database and losing it.

Re:it won't help

[JeanBaptiste]

heh, I was going for an obscure simpsons reference actually. but wow you're really in command of a nuke sub? thats pretty damn cool. which sub?

Re:it won't help

[Sancho]

Are you kidding? If they did that, people might actually try to secure their computers more.

Nope, losing customer data is business as usual and just a risk of doing said business.

Re:it won't help

[NuclearDog]

Yes, some of my secret data may or may not be held in a volume hidden inside of the free space of a filesystem within a file hidden away and encrypted with Serpent-Twofish-AES. (TrueCrypt).

Of course, the only information I have held in there is the kind of stuff I wont even describe.

I keep all my porn in a file-backed device encrypted using geli (FreeBSD Handbook page on disk encryption) using a key located inside of an encrypted partition on a usb key so that the USB key must be present to mount the drive.

ND

Works for sales, but does not secure your data

[AngryDad]

There is a catch-22 -- you either have compatibility , but key management is handled by the HDD, or you have security, but you need external software and BIOS integration. I bet, Fujitsu decided to go with the compatibility. In this case, the encryption key could be recoverable. HexView published an advisory about it back in 2006.

Re:Works for sales, but does not secure your data

[proudfoot]

It doesn't work like that. It works similar to 7-zip - the crytographic key is generated from the provided password. It is regenerated at startup.

Thanks but no thanks

[Atrox666]

With the failure rates I've seen on Fujitsu drives over the years I'll be giving this a pass. I wonder how much fun these are going to be to recover. No Fujitsu, no Maxtor is what I tell people looking for hard drives.

Users and Passwords

[Bender0x7D1]

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.

Probably slower

[FranTaylor]

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.

Re:Probably slower

[CastrTroy]

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.

How will encrypting the data protect against loss?

[Anonymous Coward]

It's just as easy to lose encrypted data as it is to lose unencrypted data. This is ridiculous.

Re:No, Imagine...

[Namlak]

A orbjhys cluster of these...

One or the other?

[Valdrax]

I'm going to stick with kernel-mode volume encryption. Why wouldn't you use both?

Re:Zero... if you didnt RTFA

[TheDanglerofTheSouth]

Apparently, so is zero.
If you actually went deeper into the story you would see the original original article... explains a LOT more then this.

The first article that was linked makes it sound like this guy is innocent, but if you read the original article in cnet, you will see that the FBI left the link on a known child porn chat area online... advertising graphically child pornography acts that were expect to see.

If my drunk friend sent me a link to this site, then Id be the first to turn my drunk friend in the police.

So the guy who was made out to be the innocent good guy in the aforementioned article, smashed his flash drive and hard drive while FBI was outside his door.

He also had a windows thumbnail file (thumbs.db), on his machine that showed pictures of "pre-pubescent girls" exposing their genitalia.

Now the thumbs.db is created for browsing photos easily - AND ONLY CREATED WHEN YOU RIGHT CLICK AND SELECT "VIEW AS... THUMBNAILS"

This means the man in the article, had PURPOSELY viewed these images before... then deleted the images, but forgot the delete the thumbs.db which contained cached thumbnails of the child porn he was viewing.

This guy did have porn, he was convicted by a grand jury and he was sent to jail, JUSTLY.

Good for a swap drive, I guess

[Sloppy]

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, I don't really believe that's what they do ("whaddya mean I lose all my data every boot?!?"). I bet the key is stored somewhere, and how/where is the big question. If it's hashed at power-on from a passphrase stored in the user's brain, I'm impressed. If it's stored in flash RAM, I smell snake oil.

Re:Good for a swap drive, I guess

[JohnFluxx]

No, they mean that the user types in the password. This is then used to generate the key. If this decrypts the data, then you're good to go.
This key only needs to be stored until you poweroff.

There's and advantage

[mathimus1863]

There is an advantage using hardware-based encryption. That is, the key never resides in memory. Although this has been stated before, it has been understated. There's a million ways to get the key out of the RAM if it persists there (as it has to, for you to run software-based encryption [did you know your firewire ports allow OS-independent memory dumps?]) If this is implemented properly on hardware, there should be no way to get the key off the drive without a passphrase that decrypts the AES key.

In nearly all cases, the weakest point of the encryption will be passphrase, if one is used (instead of a keyfile). No matter how you look at it, if a passphrase is used, it is near-infinitely easier to guess that passphrase than it is to break the AES directly. This is why I use a 24-character passphrase generated by /dev/random for my harddrive encryption :)

The security is definitely improved (if implemented properly), but may be irrelevant: someone who has the ability to break the software-based solution, probably has the ability to break this one too (keyboard loggers, most likely).

Re:Zero... if you didnt RTFA

[n0dna]

Not to nit-pick, but depending on the number/type of files in a folder, Windows (XP at least) will sometimes set the initial view of the folder to thumbnails.

Like most things revolving around the folder view options, it's unpredictable, inexplicable, volatile and almost totally random, so I can't recommend a good way to demonstrate this. However, copying a handful of photos into a new folder which has never been opened yet, will set the default view to filmstrip., which I believe also creates a thumbs.db.

However, it's Folder View Options, YMMV. ;)

Against Both ???

[Nom du Keyboard]

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.

CBC with a predictable IV...

[Theatetus]

...is really just ECB.

Re:CBC with a predictable IV...

[statemachine]

CBC with a predictable IV... ...is really just ECB.

Not really. An IV is expected to be known. All it does is function as a salt, much the way password storage works: salt + hash function + password (BTW, all hash functions start with a built-in IV).

Your first block of CBC data may be somewhat more predictable if the same IV was used for every first block in the chains, and if you had a rainbow table (which would be huge!). But we know what is actually being used: ECB, due to the independence of blocks. However, this same convenience always produces the same cipher text with the same plain text -- which is very bad when your plain text has huge swaths of redundant data, such as zeros or file system formatting.

CBC is actually a good mode; it's just not very convenient for random access.

Fujitsu a No Go!

[HermMunster]

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.

found some "info"

[Stoian Ivanov]

here
http://www.coolest-gadgets.com/20080422/fujitsu-announces-mhz2-cj-series-hard-drive/
Is stated:

Heck, the key used to encrypt and decrypt data is cryptographically regenerated whenever the correct password is received at power-on, and won't be able to be attained whenever the system is turned off
But this suppose special IDE/SATA controller with special BIOS on it. And the human factor (note with password sticked on "smart" place) still remains...

Re:Zero... if you didnt RTFA

[CastrTroy]

Who's to say that if your friend sent you an MSN message that it was actually your friend sending you an MSN message, an not some virus on his computer sending you a the link. I've seen viruses before that do this. They send you an MSN message saying to go check out this picture of yourself online. When you go to open it, it's actually an exe, with a copy of the virus in it. So unsuspecting users will download, and allow it to run, and get themselves infected. Also, how do you really tell (beyond a resonable doubt) what the picture is in a 100x100 thumbnail image? It could be child porn, or it could be legal porn of a girl with not much of a figure, and shaved body hair. I'm not saying that this guy is innocent, but it seems to me like there's a lot of room for error.

Re:Zero... if you didnt RTFA

[TheDanglerofTheSouth]

If you read the article.... it was 4 year old girls. If you have a screen 800x600 (4800 sq pixels) then a 1000 sq pixel image would take up 1/5 of my screen. I would be able to recognize a 4 yr old vs a teen. Now go F yourself, one for being a scumbag and defending the guy, two for not reading the article.

Trusted components?!

[Wowsers]

Another attempt at the trusted computer environment, but... why should I trust the hardware/vendor/store?

At least using a regular hard drive with software encryption, if you're smart enough, you can read the code that does the encryption in Linux and and check that it doesn't do anything you don't want it to.

Just go with software?

[BenEnglishAtHome]

Organizationally, that's exactly what we did. We use SecureDoc from WinMagic almost universally.

turning over possession to another

[Anonymous Coward]

What I'm wondering:

Say your boss decides you no longer need the company laptop, and gives it to Joe to use instead. After wiping your personal data but leaving the OS files, can you simply change your HD's old encryption password to a new one so that Joe can use the laptop? Or are you forced to choose between a total wipe of the HD + OS reinstall or having to tell him your password if you're too lazy/unskilled to reinstall an OS?

Horrible site to link to

[xyankee]

1. Full of ads
2. Limited information
3. NO LINKS TO MORE PRODUCT INFORMATION
4. One link to ANOTHER story on that site

Gee, I wonder if "anonymous coward" is also the recipient of those Google adsense checks.

C'mon, Slashdot, don't let this stuff through.

Here is the official press release and here is the official product page. You're welcome.

Legality?

[SiriusStarr]

Anyone know where hardware-based encryption falls in regard to US laws? Doesn't the US have limitations (theoretical, not really enforced) on encryption stronger than 64-bit, or is that just software based?

Re:Legality?

[Anonymous Coward]

We have export restrictions on strong encryption as it is classified as munitions. The rules have relaxed over the years, however newer laptops that have a TPM chip in them are classified as munitions and are barred from export to certain countries.
http://en.wikipedia.org/wiki/Export_of_cryptography

Re:Legality?

[SiriusStarr]

Thanks.

I think they mean loss of the hard drive/laptop

[JSBiff]

I don't think they mean loss in the sense you are. Of course, the only way to prevent *data loss* is to use some sort of backup. I think they mean here that the privacy of your data is protected if the drive/laptop is stolen or lost.

Advantages. . .

[JSBiff]

I'm not entirely convinced that hardware-based security is necessarily more secure, but as you say, because of the necessity to cache the key *somewhere*, hardware based solutions should potentially be able to be more secure.

    I think the main benefit, really, is performance. Why bog down the cpu with decryption, when the drive can do it itself? Also, OS independence. I assume with this thing, during boot you provide the passphrase, and after that it looks like a normal drive to the OS? I might be wrong on that; it might actually be nice to have different partitions individually encrypted, and be able to provide the passphrase at mount time instead of boot time, but that would require OS support to implement.

Look like fog at the moment

[Anonymous Coward]

I thinnk it's slighlty condensed vaporware. Yes, the 'spec' are available, however they won't be 'shipping' for 5 weeks with a projected sales of 2 million units. Probably the only way you could get one would be to mug an OEM and use their account to order 10,000 units. 8-( OTOH we can hope that they do appear for individual sale on well e-tailers. No frickin' clue how they work though It would appear that you can change the key w/o re-encrypting all the data for a fast 'erase'.

Your technology is outdated...

[freaker_TuC]

Nowadays they got ROT-312 and ROT-624 encryption, most new cpu's can handle that load just fine!

I never knew /. had sex adverts!

[freaker_TuC]

Kinky!

I am still trying to figure out wether this is a dating advert (for some atleast) or a breach in security..

Re:Zero... if you didnt RTFA

[Anonymous Coward]

800x600 = 480,000 pixels - surely this would have occurred when you calculated that a 32x32 picture takes up 1/5 of the screen? Besides, how is it scummy to assume someone is innocent when you don't have all the information (which you've said he doesn't)? That seems like a perfectly normal thing to do to me.

Encryption accessible w/ boot-up password?

[Anonymous Coward]

If this is similar to such hard drives available with Lenovo laptops, the HD is indeed encrypted all the time and you do not have the key and cannot change it. However, all information is available at the interface of the HD (just not from taking it directly off the platters). So, just by guessing the boot-up password, you have access to all the data. That is why the Lenovo scheme did not make sense to me. Why bother? If I am wrong please correct me.

Trust the Source

[DeanFox]

The reason to do encryption in software is that the encryption can be replaced as existing crypto techniques become thoroughly broken. Not just that. Unless I am in complete control of the algorithm I can't trust it. I doubt the chip will be open source available for peer review. I would almost guarantee there's a back door in their chip. Even if there is no back door I can't trust that there isn't one.

With software device/partition/file encryption [TrueCrypt] I can trust the source and I control all aspects of the implementation.

Re:Zero... if you didnt RTFA

[TriezGamer]

Good lord, where did you learn math?

Or rather, why DIDN'T you learn math?

Thanks, but no

[BenEnglishAtHome]

That drive uses ATA security. ATA has been broken for at least 3 years. While it provides good protection against determined thieves, it's not proof against anyone who can write a check to a major data recovery firm. Successful file recovery from locked drives has been demonstrated for at least 3 years.

But I appreciate the effort.