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]

and is the ATA password stored on the 320 SSD?

[idata]

I think a few additional words are needed. If someone is reading this topic (at least I hope there are a few of us) he will be able to get an idea what is all about and why we are asking all over again about such "irrelevant" things like ATA and AES keys linking.

The manufacturers are to blame. When Security Extensions to ATA specification was born the manufacturers (like Seagate, Western Digital, Hitachi etc) started a very strange thing. They started to implement unofficial undocumented ways to talk to his drives - so called Vendor Specific Commands which allow to run disk diagnostics and other firmware and S.M.A.R.T related tasks even if ATA passwords was being set so even when device is locked! Why? I don't know but If you ever wondered what actually all those ATA Password Recovery firms want your 50 bucks for, this is it. The hackers quickly started to explore the possibilities and here you have it: you can recover ATA pass from the most of todays drives, you can dump service blocks, inject your modified firmware, you can even dump the locked drive sector by sector from top to bottom. This a pathetic disaster security wise!

I'm fresh to this things but it is beyond me why the manufacturers did not implement some public kill switch passwords which when executed resets ATA security systems and at same time triggers unavoidable Secure Erasing all data on the drive? No more is required! Data still safe and you-manufacturers have your unlocked / servicable drive again, and no more whining that the drive is locked so we cannot service it for you.

Instead they started to build bridges above their own security systems and explaining that they are for service porposes. Don't get it. Locked means locked, doesn't it?

And here is the thing: Even if intel implemented ATA password system in a traditional way (full of holes and service backdoors), even if it is fundamentally flawed there is still hope that the whole thing is secure.

When ATA password is cryptographically linked to AES keys and when it's presented only in a hashed form internally for authorisation purposes, then even if hackers reverse-engineer the controller down to VHDL level and run it in virtual machine 1000 times faster, even if they dump all the registers, they still do not get the final AES key so cannot decrypt the drive.

But if these two conditions are not met (protecting ATA pass with certified hash alghoritm and binding it with AES)... I'm giving you, intel 3 months until this system is defeated. Knowing how leaky the ATA password system is.

[idata]

I am also watching for the response to the questions. Everything I have read thus far has providied conflicting information as to the actual security provided by the FDE encryption found in these drives.

It basically comes down to this.

Either

The ATA password (master or user) is cryptographicaly linked to the AES encryption key

or

The ATA password is stored as a non-reversible hashed value in the SSD for authentication purposes

or

The ATA password is the same as previous platter drives, and is trivial to bypass

I'm looking for a drive, capable of true user-unique FDE, that is non-trivial to bypass. I see in the intel specs reference to "user-unique" encryption available if the ATA password is set, however I do not find confirmation of this anywhere.

I do not want a drive that pretends to implement AES encryption, or implements AES encryption, but leaves the keys hanging from the lock.

I need answers to these questions before I make a purchase decision.

[idata]

Patiently waiting for a response to this too.

[idata]

Also, I wish to know if the situation is the same on Intel 510 series...