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]

Thank you for the response Piy! I have been doing a lot of research to try and figure out what my options are since I have no obvious ATA/HDD password settings on my bios. Pretty much everything I have looked at has gotten me to a dead end, but I did find some interesting info on this blog

http://dfarq.homeip.net/2011/03/ssds-and-built-in-encryption-and-how-to-enable-it/ http://dfarq.homeip.net/2011/03/ssds-and-built-in-encryption-and-how-to-enable-it/

According to the writer, in the main article and comments section, he hints about how BIOS nowadays in PC's actually do the ATA/HDD password in conjunction with the regular BIOS password.

To quote:

"It's been a long time since I've bothered with BIOS passwords, since they're trivially easy to defeat. So I never noticed that modern PCs also use the BIOS password as the ATA password."

In the comments section:

"If you want your drive to remain for your eyes only you'll need to set an ATA password, which on PCs is forced by setting a BIOS password."

So I am not sure what to think, I have checked my BIOS over and over and there is some hope after looking at one of the features I have. See below:

HDD Security Freeze Lock (Disabled)

If this item is enabled, it prevents any external application from locking hard driveexcept for BIOS.

And also:

Security Option (Setup)

If you have installed password protection, this item defines if the password isrequired at system start up, or if it is only required when a user tries to enter theSetup Utility.

This to me hints that my BIOS might be capable of PW locking my drive, and there is even an option to force the PW upon boot.. But I really do not know what to think, I am still trying to make heads or tails of this. Seems pretty lame Intel would restrict using the encryption only for computers that have the ATA/HDD password in BIOS.

[idata]

That is easy to confirm.

Set your bios password. Boot to linux. In root type:

hdparm -I /dev/ (I - capital "i")

When ssd is connected to sata1 port the the path most probably will look like: /dev/sda

hdparm returns drive info. Look at the security section and verify if the security is: enabled or disabled

But do not hold your hope as in all cases I came across bios password is unrelated to hdd passwords (note theat bios password can be reset by bios reset, just think a second about it) and Hdd Security Freeze Lock is used only to freeze all the drives against some malware attacks.

[idata]

I hope it is allowed to revive this discussion as I have only found it yesterday.

I'm not going to shoot off 20 questions immediately but I do have some that I may ask later.

Firstly, can anyone explain how FDE authentication works? There is software like Winmagic and others that nest themselves in a special PBA (pre-boot authentication) partition. Essentially, it is a mini-linux OS that is (or should be) very secure. It is comparable to the TC bootloader but I'm sure the PBA for FDE drives has many more options. I have not seen anyone mention this type of software so you guys may or may not have missed it.

[idata]

ATA password (so called HDD password) is the only authentication channel intel implemented. No pre-boot authentication as the whole drive area is encrypted. The BIOS/EFI should support HDD password. Other options beside BIOS also available (as stated above) but not so convenient and with limitations.

[idata]

Yes, I understand. Seagate has both drives only implementing ATA-password and drives which have a special area capable of holding a pre-boot authentication OS. The OS is also capable of supporting a wide area of other authentication devices like a smart card reader.

I did read the entire thread but I'll have to re-read it to know what "other" options you are talking about. The PBA software suites (if anyone wants to know I've researched a list) are TCG Opal compliant.

At any rate, from reading different threads, I understood that ATA-password and SED encryption password/phrase are two different things entirely and that ATA-password (as said in this thread) is often easily defeated. It is safe to say I did not fully grasp the connection between ATA-password and the AES encryption key on the drive. Moreover, I'm still a bit confused as to how this AES encryption key is stored and how a new one (nobody wants to use the factory installed key, right?) is generated.

What good is encryption anyway if the authentication is bypassed easily...