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?
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??
I'm not sure but it seems that Intel approach is no differ then SandForce 12xx one. It means: this is ONLY internal encryption with random generated passwords and without user defined passphrese. This solution does NOT increase security against thieves. It speeds secure erasing and add minor layer of security against controller switching (for ATA-pass overriding) and flash memory dumping. Highly rare and uncommon situations these days.
The controller switching is rather outdated hack method (mainly for platter drives) based on swapping hdd's electronic board (containing drive's controller and internal bios) to bypass some security methods. It does not concern motherboard controller, the drive's electronics only.
There are IMO much better solutions for securing mass storage these days. Much more flexible then bios-based passwords (with its 8 characters limitation - too small against brute force attacks). All of them are based on preboot authentication (and to be honest they have theirs own issues) but I highly dubt Intel implemented that. We are talking about budget drives.
AFAIK there in no technical reason for 8 chars limitation. And you are absolutely right. ATA security specification defines 32-bytes for pasphrase. Well... it seems that unofficial bios modding for adding security ATA extensions will be more common these days. This is the only way I can think of... I've lost any hope that my desktop mobo's manufacturer get rid of the essential flaws in its BIOS anytime soon. Adding security module sounds like sci-fi for me and it is unreal for most of us, unfortunately.
tristpost asked excellent question about passwords linking. This is the clue.
Intel's documentation suggests that AES keys are generated during Secure Erase procedure. And this is understandable. But the thing is: ATA password seems to be unrelated to AES encryption engine which to be honest reverse the proper implementations upside down. In truecrypt (and many soft-based solutions) for instance password is the first and based on it and random or pseudo-random generator (mouse based in truecrypt) final AES keys are obtained.
Intel's paper suggests that in 320 case AES encryption and SATA pass are separated. You can use AES (well you are forced to, but not complaining) and NOT use ATA-pass at the same time. ATA pass is optional.
These two security mechanisms are not nested. They are not nested!
When you crack ATA password AES becomes obsolete and vice-versa. They are not in logical conjunction.
Impications? Well look at the market. Dozens of manufacturers and theirs ATA pass implementations. And you can crack almost any of them. There are specialized commertial firms witch offer ATA pass removal. And all these security implementation are hardware!! ATA pass is stored in drives firmware or data firmware areas!
The only solution to secure such encryption mechanism I can think of is to encrypt (strong encrypt) generated AES keys with ata pass internally.
Otherwise sooner or later some skilled hacker will find "authorization bit" and this whole sophisticated AES will be absolutely useless.
In my opinion this is not looking like enterprice class security. If I'm wrong, feel free to prove otherwise.