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]

I have recently bought the 80GB 320 and I am still trying to get a simple answer to the FDE passwrd question and think it would be very helpful if the answer were included in the HD manual and the FAQ.

If, as is the case, my pc has a bios and an HD password and I set both of these when installing the SSD, have I in fact set up the bespoke password FDE, or do I need to , as the pdf intel guidance suggests, use the toolbox to then do a new secure erase on the same PC. It's just that the tablet PC in question only has one sata connection meaning that any secure erase would have to happen on a desktop PC with no HD password option.

Basically a simple step by step answer to how to set it up would be apprciated.

I have assumed up until now that by setting an HD password in the Bios on first using the drive that the FDE is encrypted with reference to the HD password that was set but am increasing believing it isn't. I am of the thinking that in order for the HD password to be relevant to the encryption of the drive a password has to be in place.

Everyone just seems to be discussing the security levels provided rather than trusting that a described method does achieve a reasonably robust level of data security.

TIA

G

[idata]

I have checked this entire thread and the situation still isn't clear. It sounds like the Intel SSD encryption is totally insecure, despite what SSDelightful says.

The password is stored as a hash. That strongly suggests that it is not being used for encryption. If it was then hashing it would be pointless and a security risk. Despite what SSDelightful said hashes can be cracked, particularly by dictionary attacks. Normally when used for encryption you don't store the password, you just use it to decrypt the key used for the actual on-disk encryption and see if it works or not. That takes considerably longer to do that a mere hash. So either Intel's implementation is very poor or the ATA password is not used as part of the encryption scheme in which cause it is worthless.

To be fair to Intel they are not alone. Sandforce's implementaton is similarly flawed and pretty much worthless. It might go some way to preventing forensic analysis of the flash memory directly but if the user's password is not used as part of the encryption then it is highly vulnerable to having said password recovered via dictionary attack or even rainbow tables if it isn't salted. It may even be possible to remove the password via software, e.g. Sandforce controllers can be firmware updated to remove the password in some cases and all data becomes accessible.

Can anyone actually confirm that Intel is doing it right? It seems like Intel needs to get their products independently audited to confirm their security because until then we can't rely on it.

[idata]

@mojo

1. The use of a password hash doesn't mean the protection is insecure. In Microsoft's BitLocker encryption, SHA-256 is used to generate a hash from the user's PIN, and the first 160 bits of this hash (plus the TPM protector) are used to "seal" (encrypt) the volume master key (VMK), which in turn encrypts the full volume encryption key (FVEK). The ATA password hash in the Intel 320 series SSDs is probably used to protect the volume encryption keys in a similar way.

2. The length of the password and the strength of the hash algorithm are probably sufficient to prevent reconstruction of the password from the hash.

3. The ATA password hash is probably stored in a "host-protected area" on the SSD. According to AIDA64 Extreme Edition, my Intel 320 SSDs have a host-protected area and it is enabled. This should interfere with an attacker's efforts to find and read the hash.

4. If it is possible to create a firmware update that removes password protection without the user's authorization, and it may not be, Intel has every reason not to create or release it.

5. I would not say it seems that Intel's SSD encryption is "totally insecure", as you suggest, but it is important to know how Intel protects the ATA password from attacks. My points 1-4 above are only speculations. And if a long and/or complex password is needed to protect against attacks with rainbow tables, we should be told that, too.

6. I am responsible for protecting confidential information under HIPAA regulations. As I gradually move our desktops and laptops from BitLocker to Intel 320 series SSDs I would like to know that Intel's implementation of a self-encrypting drive is as secure as it should be.

[idata]

@ ChemicalX, I don't think you appreciate the implications of what you are saying. If the password hash is stored anywhere then it is insecure, in that it can be cracked with some (perhaps considerable) effort. Take all look at the Truecrypt docs, particularly the section "http://www.truecrypt.org/docs/header-key-derivation Header Key Derivation".

That being the case then the encryption scheme is broken. There is a severe security flaw that allows an attacker to break it with consdiderably less effort than should be required, an amont of effort that an ordinary person with a high end graphics card can muster in a few weeks or months maximum. If they didn't properly salt it then it might even be crackable in seconds via rainbow tables, but I'll give Intel the benefit of the doubt there.

Of course it depends who your attacker is. The average computer theif might not bother, but if you keep corporate secrets on your laptop or are at risk from oppressive regeims you had better not rely on it. I think SSD manufacturers have rushed to add secure sounding AES encryption because Sandforce did it, but it isn't actually anything like as secure or useful as it sounds.

[AZapa1]

mojo wrote:

@ ChemicalX, I don't think you appreciate the implications of what you are saying. If the password hash is stored anywhere then it is insecure, in that it can be cracked with some (perhaps considerable) effort. Take all look at the Truecrypt docs, particularly the section "http://www.truecrypt.org/docs/header-key-derivation Header Key Derivation".

That being the case then the encryption scheme is broken. There is a severe security flaw that allows an attacker to break it with consdiderably less effort than should be required, an amont of effort that an ordinary person with a high end graphics card can muster in a few weeks or months maximum. If they didn't properly salt it then it might even be crackable in seconds via rainbow tables, but I'll give Intel the benefit of the doubt there.

Of course it depends who your attacker is. The average computer theif might not bother, but if you keep corporate secrets on your laptop or are at risk from oppressive regeims you had better not rely on it. I think SSD manufacturers have rushed to add secure sounding AES encryption because Sandforce did it, but it isn't actually anything like as secure or useful as it sounds.

It is possible to design a EEPROM chip that couldn't be read on modern level of science and technology. Take a look on FIPS 140-2 standard. But the question is WHY Intel stores the hash of ATA password in drive controller? Why not just to encrypt the main volume key with this password as TrueCrypt does? Or it least store it in plain text if they made a controller with level 4 security FIPS140 standard. Storing the hash of ATA password is completely pointless in every case!