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]

@ryan29: Thanks for the information about your Gigabyte motherboard and booting the encrypted drive. I have a DS3 I'm going to try that on. I also have an ASUS P8Z68 I'm going to try, probably later this month.

@all:

The ATA password is probably stored as a hash to meet the standard. I believe Intel firmware has to verify it has the correct password and they use the hash to do that. As I said earlier in this or another thread the real question is what hash they're using for that. Conceivably we could choose 32 random characters for our ATA password and that random data is used to make the hash. If it's an sha256 hash, well that's ok with me. If you have only 32 characters of input on a one-way maybe there might be some attack for that specific situation? But if it's some xor magic with md5 that's not ok with me.

The bigger elephant in the room for me right now is this 8MB bad ctx crap it needs to be addressed yesterday. We need more "Intel" on the causes and solutions. Yeah, I'm corny.

[AZapa1]

@all:

The ATA password is probably stored as a hash to meet the standard. I believe Intel firmware has to verify it has the correct password and they use the hash to do that. As I said earlier in this or another thread the real question is what hash they're using for that. Conceivably we could choose 32 random characters for our ATA password and that random data is used to make the hash. If it's an sha256 hash, well that's ok with me. If you have only 32 characters of input on a one-way maybe there might be some attack for that specific situation? But if it's some xor magic with md5 that's not ok with me.

The disk volume is encrypted by master key. This key generated during secure erase command and do not change when you change ATA password. That's why you can set password in seconds it because the volume is already encrypted. And because of this you can proceed secure erase in one second its because you need only change master key and the volume became a random garbage without the knowledge of previous key. Ok? This scheme is in use by most full disk encryption software.

Now the question is how this encryption key is stored?

1) It could be stored on insecure chip but encrypted by ATA password. When you set ATA password, controller encrypt master key with this password and store it in insecure EEPROM chip. Then you need to provide ATA password to read the volume because master key is encrypted and couldn't be used to decrypt the volume. But in this case ATA password is not stored anywhere.

2) It could be stored on secured EEPROM chip satisfying the level 4 of FIPS 140-2 standard. In this case controller can be used as an oracle. Nobody can gather information from this secured controller. You can only plug it on and provide correct ATA password to read encrypted volume. In this case controller store master key as a plain text. And ATA password could be stored as plain text as well.

Is it clear? When you need to use hash??? In what case?

[idata]

Dwarf:

In your case 1 you would actually need to have a hash of the password, how else would the drive know it's correct? Encryption doesn't fail if you try to use the wrong key (if you decrypt the master key with a wrong ata password), it just gives you different data.

[AZapa1]

DesktopMan wrote:

In your case 1 you would actually need to have a hash of the password, how else would the drive know it's correct? Encryption doesn't fail if you try to use the wrong key (if you decrypt the master key with a wrong ata password), it just gives you different data.

Yep! Encryption software uses volume header checksum to verify decryption correctness. But really, full SSD encryption not need any header so your words make sense. But why Intel not to clarify and publish the actual scheme of encryption? I am also interested in internal encryption algorithm, are they use LRW/XTS/XEX algorithm or just simple CBC mode of operation? According to Kerckhoffs's principle Intel should publish all details of there encryption system/process.

Or else any speculation are allowed, and even mojo may be right. For now Intel just say: hey guys we use full disc encryption with AES algorithm and store passwords hashed! Be proud that we are concerned about your privacy, believe us we are professionals! Its just a marketing it is not an encryption system description.

[idata]

In addition to increasing the performance of the SSD 320 series over the G2, Intel has also incorporated a few new features to enhance reliability and security. Along with using the over-provisioned space to minimize write amplification and for wear-leveling and other drive maintenance, part of it is also used to store parity data to help prevent data loss in the event of a partial or full NAND device failure. The drive also has an array of capacitors that will supply a bit of power in the event of an outage so the drive can flush its cache and complete and pending write operations. The Intel SSD 320 series drive also offers AES encryption to help protect user data.While discussing the features of the SSD 320 series, Intel was also keen to talk about the reliability of their drives and the work that was done to ensure the SSD 320 series was their most reliable drive yet. One of the slides above shows the miniscule failure rate of Intel's solid state drive offerings in a variety of deployment scenarios. Intel hopes the SSD 320 series drives, despite the fact that they use 25nm NAND flash which is more prone to failures than 34nm NAND (as process geometries go down, NAND is more prone to errors), will be their most reliable yet. Of course, we won't know until the drives have been shipping in volume for some time, if this turns out to be the case, but reliability was clearly a strong focus for Intel with this series of drives.