Solid State Drives
Support for Issues Related to Intel® Solid State Drives
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
4374 Discussions

Intel 320-series SSD and FDE (Full Disk Encryption) questions...

idata
Community Manager
13,160 Views

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??

123 Replies
idata
Community Manager
104 Views

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
Community Manager
112 Views

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
Community Manager
112 Views

@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
Community Manager
112 Views

@ 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
Beginner
112 Views

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!

idata
Community Manager
112 Views

@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
Beginner
112 Views

@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
Community Manager
112 Views

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
Beginner
112 Views

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
Community Manager
112 Views

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.

idata
Community Manager
112 Views

Exactly, the design makes no sense. I think either SSDelightful is wrong or the system is not designed to be secure at all. I think the most likely case is that the password is not actually used to encrypt the drive key at all and is merely an ordinary password that the drive requires before it will allow further access. Like most HDD ATA passwords it is probably totally insecure and easy to bypass, meaning there is basically zero protection against anyone who wants the data.

As I said, it's a tickbox feature, basically worthless. As far as I can tell the only company that makes known secure SSDs is Samsung, all the Sandforce ones are as useless as the Intel drives.

idata
Community Manager
112 Views

You can use a BIOS extension for desktops. It works well. http://www.fitzenreiter.de/ata/ata_eng.htm http://www.fitzenreiter.de/ata/ata_eng.htm

idata
Community Manager
112 Views

mojo wrote:

You can use a BIOS extension for desktops. It works well. http://www.fitzenreiter.de/ata/ata_eng.htm http://www.fitzenreiter.de/ata/ata_eng.htm

That is only IDE, not AHCI and I don't think he plans to update it. I take a fairly big performance hit when I switch to IDE:

http://imgur.com/a/9Beny http://imgur.com/a/9Beny

I don't understand BIOS stuff well enough, but I found myself wondering why Intel didn't include ATA password support in the ICHxx AHCI BIOS.

idata
Community Manager
112 Views

I fully agree with you ryan29. Intel needs to release BIOSs for their boards with ATA password support. I bought an Intel desktop board for this very reason, assuming they would surely have it because of their SSDs.

idata
Community Manager
112 Views

Hi

I've enabled the ATA Password on my PC and everything works fine.

I now want to move the SSD to another PC and remove the FDE.

What is the exact supported procedure to do that?

Are the steps below correct?

1. Reset the ATA password

 

2. Dissconnect the drive

 

3. Run secure erase on other PC

 

4. reinstall/restore OS, apps and so on.

Can I use an sata to usb adapter to perform step 3 above?

I just want to dubble check before doing anything drastic

Thanks in advance,

Michael

plee21
Valued Contributor I
112 Views

Hi

To move the drive to another PC remove the password in the original PC first.

You don't have to do a secure erase unless you are giving the drive away, just delete the partitions and start again, in theory running the Intel Optimise function permanently destroys old data. To do a secure erase requires you to hot plug the SSD into the computer after it has booted so that isn't locked to low level security commands. To do this connect the power cable to the drive but disconnect the SATA cable, then reboot, once the system has booted connect the SATA drive cable. I'm not sure if you can do this via USB.

Regards

Phil

JHick3
Beginner
112 Views

Can someone from Intel please respond to Ryan's comment above:

If Ryan is correct and the 320 doesn't use KDF for the second AES key, the information provided by Intel is wrong. If the AES key is not encrypted by the ATA password than the 320's FDE implementation is broken and the hashing argument is irrelevant. A comment from Intel would be appreciated.

Technical specifications for any device like this should be public and I encourage everyone to demand them. I've read every comment on this thread numerous times and only one conclusion can be drawn from it: Intel currently implements black box security in the 320 series SSD.

plee21
Valued Contributor I
128 Views

Hi

The whole encryption thing with Intel SSDs seems to be more marketing than anything. In their literature they fail to point out that for encryption to be any good, you need to set a password first, and not all systems will support that. Intel don't seem to engage in any discussions regarding how we can secure our data using their SSDs. It's an additional worry that the even adding a password might still mean we have weak security anyway.

Currently I'm waiting for an Intel response on the fact some of their own brand new motherboards have broken support for setting the password, so at best you can't set one, at worse your PC might not boot up again!

Here is hoping for some information.

Regards

Phil

idata
Community Manager
128 Views

Anyone know if the 330 series also supports AES? I'm getting mixed information from Intel Tech Support. They claim only the 320 series and 520 support AES? This post also has a broken link that I can't use to confirm:

Reply