Intel 320-series SSD and FDE (Full Disk Encryption) questions...

[idata]

I am considering to buy a couple of new solid state drives for my company. A requirement is FDE and according to some info I found the new 320 series should support this. I have a few questions:

1. As far as I know none of our computers have any support in BIOS for disk password. Is this required for FDE to work with the 320 series or how exactly does the encyption / password entry work?

2. If we would like to use a RAID configuration (RAID 0 striping) is it still possible to use FDE and if so do one have to enter a password for each disk?

3. What about using two disks in the samer computer (non-raid) that is used to dual boot two different operating systems (say Linux and Windows 7) installed one OS on each drive - does FDE work in this case and would one have to enter a password twice?

4. Is the FDE solution dependent on some support in the OS (in that case what OS does it work with) or is it independent?

5. Do you have some white paper about the FDE with for instance information about how much slower it is compared to a non FDE drive?

6. I have read that TRIM does not work with SSDs in RAID configuration. Is this still the case and how dependent is the 320-series of TRIM?

/Trist

CORRECTION : I just found that our Dell Precision M6500 computers do have a field in the BIOS for disk password so I am interested in the questions above (two disks in the machine with or without RAID) also for this configuration. How do I know if the 320-serias FDE is compatible with the disk password setting in the dell M6500 machines? Is there a standard for this that all BIOS manufacturers follows or??

[idata]

Guest wrote:

You can use hdparm utility in linux to unlock ATA-passsword protected drive (ssd included).

Just boot from a pendrive with one of those micro-small linux distributions (ttyLinux, tinycore, microcore, DSL) and issue:

hdparm --user-master u --security-unlock /dev/

inside your script which asks for password first...

and then, reboot. Security state of the disk is preserved during the warm reboot.

Not the most elegant solution as it requires additional restart but you can automate it mostly thanks to grub's fallback function.

And it could be fast. Small, good configured linux can boot in 5 seconds.

One can live with that.

I tried this with a Gigabyte P35-DS3R motherboard and have a few tips for anyone else that wants to try:

1) Try it with a live CD before putting any effort into it. The Ubuntu Live CDs have fairly new versions of hdparm.

2) Your BIOS may put the drive into 'frozen' mode even if it doesn't support ATA password. Use 'hdparm -I /dev/sd[your drive]' to check. If your BIOS does this you probably have to hotplug the drive get access to it in unfrozen mode (hotplug at your own risk).

3) The BIOS for your hard disk controller might have trouble querying the drive once it's locked. Mine did. Imagine this (http://www.youtube.com/watch?v=y7Qhu1mYdYI http://www.youtube.com/watch?v=y7Qhu1mYdYI), but with an extra 5-10 seconds while it has trouble detecting info for the locked drive. Edit: I just tested this again and it's closer to 30 seconds to timeout and, for some reason, won't let my machine fail over to the next boot device in the list. If you have the same board as me, don't waste your time. You can use the Gigabyte AHCI controller, but it benchmarks much slower for me.

[idata]

I had a bit more time to play around with my disks on the weekend and, regardless of how secure FDE implementation is, I don't know if I'm going to end up using it. I'm a bit disappointed because a lack of FDE was one of the main reasons I took so long to make the jump to SSDs and the promise of FDE was the main reason I bought Intel drives.

In terms of usability (security related below this):

First off, I can't use FDE on my desktop because my motherboard (Gigabyte P35-DS3R) doesn't support ATA password and none of the alternative methods for unlocking the drive work for me. Booting into linux with the drive locked, unlocking it and then rebooting adds about 80 seconds (POST + disk timeouts) to the boot process and using IDE mode incurs too much of a performance penalty, so the ATA Security eXtension BIOS isn't an option.

IMO, this is a big problem for the average user:

SSDelightful wrote:

4. In order to provide the absolute best security possible, there are no available password recovery solutions. If you lose or forget your ATA User Password and Master Password, your SSD will remain locked without access to read, write, or erase any data within the device. In this case, your SSD and your data are lost, and cannot be recovered by Intel.

Pit wrote:

3. Let's assume that User had set his own ATA User Password and Master Password and then he forgot both of them. Now he's returning the drive as broken. Does his warranty still valid? I can understand that ATA locked device is unreadible, unwritable and unerasable. But is it unservicable?

SSDelightful wrote:

Warranty is not valid since SSD works per specification. It is not serviceable by Intel.

Here's an example of someone that has a bricked drive because of a problem that shouldn't exist:

/message/131126 http://communities.intel.com/message/131126

I say the problem shouldn't exist, because the Intel SSD Toolbox should check the 'Master Password Revision Code' (Word 92) and offer to change it as an optimization if it's never been set. At least that way the (average) user has a BIOS independent way of recovering the disk if the need arises.

Like the poster in the linked thread, I also have a Dell laptop. I locked the drive, put it in my desktop (which doesn't support ATA password) and tried to unlock it using 'hdparm'. Dell must transform the password somehow before passing it to the disk since, AFAIK, the ATA password spec doesn't forbid doing so. That means the password could be padded, hashed, salted or transformed in pretty much any way before being passed to the disk. I couldn't figure out what it was and ended having to put the disk back into my laptop to unlock it.

Now, I have no problem losing all my data if I forget my password or my laptop sets it to something weird, but to make the drive unserviceable... The average user might still use the FDE since a bricked drive if their laptop dies is still better than their data being open to casual snooping if the forget their laptop somewhere.

However, if I were a corporate user, I'd be hesistent to buy these if I were tasked with buying drives that support FDE. Running software based FDE like TrueCrypt or BitLocker isn't a very good option and dealing with forgotten passwords is a huge pain. Setting a master password negates the issue, but there isn't a supported tool for setting the master password (that I can find) and, worse yet, there's no best practices documentation (that I can find) for dealing with forgotten user passwords. Do I need to boot into linux, hotplug my disk and use hdparm (this is how I did it)?

I'll likely use a bootable linux disc to set a master password and use the built in ATA password support of my laptop. At least that way I know I can recover the disk if my laptop dies. I had to give up on my desktop.

-----------------------

In terms of the FDE implementation, it definitely needs some clarification.

SSD Delightful wrote:

Yes, ATA password is used to encrypt the encryption keys stores on the SSD.

I'm extremely skeptical of this claim unless there are actually two copies of the AES encryption key stored on the disk. I booted up my machine with a Debian Live CD and did the following testing.

a) set the user and master password

b) power the disk off / onc) unlock the disk with the user passwordd) mount a partition, access data, unmount the partitione) power the disk off / onf) unlock the disk with the master passwordg) mount a partition, access data, unmount the partition

I was able to access my data using either password. So, if a key derivation function (http://en.wikipedia.org/wiki/Key_derivation_function http://en.wikipedia.org/wiki/Key_derivation_function) of some type is being used to encrypt the AES key, there has to be two copies of the AES key stored on the disk; one for each password, right? Hopefully someone can repeat my test and confirm it just to be sure I didn't screw something up.

The cut and paste from earlier reads a bit different.

SSDelightful wrote:

The encryption keys are securely held within the SSD device, hidden and encrypted using standard security techniques. These keys cannot be read by the user. All Intel SSD 320 Series drives do this. No user intervention is needed to enable data encryption on the NAND devices within the SSD.

What are 'standard security techniques'?

IMO it's far more likely the user / master password is being used to unlock the disk and the disk won't give up the encryption keys until the drive gets put into an 'unlocked' state. Then storing a hash on disk makes sense too since it gets used for password verification. Hopefully I'm wrong.

Maybe the intern that implemented the FDE scheme finished their internship and isn't available to explain how it works 😉

[idata]

I got more time to play with my disks over the weekend. In my opinion, implementing AES encryption on top of HDD (ATA) password was a mistake. There's no way to guarantee your disk is secure without testing the way your specific system implements ATA password. Others in this thread have already made the point, but I'll give a very specific example.

I have a Dell Studio 1537 laptop. The BIOS has an HDD password. As I mentioned in my previous post, I can't figure out what the user password actually gets set to, so I decided to boot off a linux live cd, set a master ata password and then rely on my laptop's built in HDD user password for day to day use. That way I figured I'd have a way to recover my SSD if my laptop dies and I can't figure out what the user password is set to.

However, while testing to make sure I could actually go back and unlock the SSD after the fact, I realized the master password I set no longer worked. After a decent amount of testing, I'm fairly sure when I set the HDD user password in the BIOS, the HDD master password is also changed. My theory is that Dell has things set up so that whenever I set a user password, the master password gets set to something Dell knows so they can service machines that get returned under warranty. Based on the claims of most HDD unlocking services, the master password is getting set to something that Dell can derive from the service tag.

And that's the problem with building on top of ATA password. For the vast majority of users, their disk is only as secure as the ATA password implementation in their BIOS. If the vendor of the BIOS is setting the HDD master password to something reversible, the whole thing becomes worthless. It doesn't matter what Intel does with the password once it gets to the disk; the system is already broken at a higher level that Intel has no control over.

I can use max security on the disk, but then I'm back to the original problem; I can't figure out how to unlock my SSD using the HDD user password with anything but my laptop. If my laptop dies, my SSD is bricked.

Besides the shortsighted FDE implementation, I'm actually very happy with my disks (as long as my rebates come thorugh ;-).

[idata]

SSDelightful wrote:

2. Support for ATA Passwords within BIOS or other means are system implementation specific. [...] Consult your system manufacturer's documentation, or contact your system manufacturer for support.

The Intel® Desktop Board DQ67SW, DQ67OW, and DQ67EP support the ATA Password functionality, called "HDD Password". On these boards, the HDD password support works in all SATA modes (IDE, RAID, or AHCI). The HDD password will only be applied to the drive on SATA port 0.

3. The ATA Password standards, and therefore Intel SSD 320 Series drives, allow for up to 32 byte passwords and contain no specific password "strength" requirements. 32 bytes enables users to create passwords with significant security "strength". It has been noted that some systems support ATA Passwords which are significantly shorter than 32 characters in length, and contain no password "strength" requirements. The utilization of the ATA Password security interface in system BIOS is system implementation specific. Consult your system manufacturer's documentation, or contact your system manufacturer for support.

@SSDelightful:

I bought an Intel 520 SSD Drive, among other things because of it's claimed strong AES encryption. I'm using an Intel DH67CL Mainboard which is very similiar to the DQ67 series you mentioned.

This board's BIOS however does not allow setting the HDD Password to more than 8 characters. With 8 characters one can support at most 64bit encryption, more realistically (because not all characters can be typed on a keyboard) it's more like 50-55bits of maximum password complexity.

a) Why does Intel offer a completely insecure HDD Password functionality in it's own mainboards for no apparent reason while promoting the encryption capabilities of it's SSD?

b) Does the DQ67 series you mentioned allow longer HDD Passwords than the DH67 Series? If so, why is Intel making the H67 based boards artificially insecure for no apparent reason?

c) When will this be fixed? You mention I should contact my system manufacturer for support. The manufacturer of my system (=Mainboard, BIOS) is Intel (=You)...

[idata]

Hi,

I have a HP Elitebook 8740W with an Intel series 520 SSD. Am I able to secure the drive with a password and what would be the best practice doing this?

From my Fujitsu laptop (S751) w/ a similar SSD this is done in BIOS's security-options (Hard disk security, drive0 password etc..) but I cant find any similar option from the HP BIOS.

Does the ATA security password have something to do with this?