Performance of AES-NI Full Disk Encryption +/- TrueCrypt for SSD Drive

1. If you are thinking about encrypting twice, then yes, you will have the overhead of the Encryption and Decryption process for every block written or read. Cannot suggest how much performance loss but there will be some that I am sure will be noticeable.

2. Encrypting data that is already encrypted seems very redundant and necessary. As for which is more secure, unknown... If you create the private key for both, then I would think they are going to be equivalent.

3. Anyone who tells you to do this without having a complete backup and the time to do a full restore if it doesn't also has a snow-cone shop for sale in Antarctica. You can encrypt things as many times as you want and theoretically it should work fine. Having not tried what you are proposing, I would just tell you to be cautious.

I would throw in some personal insight... Why in the world do you want to do such a thing anyway. Seems like a project that will cause more headache than solve. My $.02 YMMV

Thanks for the response.  My purpose wasn't to double encrypt (at least not initially).  I was hoping that TrueCrypt would be able to use the CPU's AES-NI feature to minimize the performance impact that TrueCrypt has on the SSD.  Unfortunately, the SSD performance has taken a hit with using TrueCrypt FDE.  I have considered just using the BIOS/SSD encryption instead, but I have heard that since Samsung doesn't disclose it's encryption methods, it's hard to say if it is better or worse then Truecrypt.  i.e. if the encryption key is just sitting on the SSD in plaintext, then the BIOS/SSD encryption security would be non-existent.

TrueCrypt is a software system that runs in memory and intercepts Disk I/O. It does not really affect the actual SSD performance, it is just not feeding the SSD as fast as it could without the encryption overhead, and encryption is big overhead, even for fast computers. Good luck...

SSD's are a bad cadidate for encryption because they use compression, the two are often mutually exclusive. Compression works by finding duplicates or patterns of matches and reducing them, encryption makes data look random and random is anything except repetitive. SSD's are totally different animals when you compare to platter HDD's. Wear-levling and Trim methods on SSD's make using TrueCrypt a big no no, and it does affect performance, reduce your drives life, and it might make you less secure :(
http://www.truecrypt.org/docs/trim-operation
http://www.truecrypt.org/docs/wear-leveling
http://www.ghacks.net/2011/02/23/solid-state-drives-and-encryption-a-no-go/

Use the native encryption that the SSD came with, that will have taken into consideration the flaws that TC has or points out, hopefully. Also note that FDE only protects you when the drive is stolen or removed from the computer. It does not protect you when the OS is running. You may want to have a look at my articles here:
https://www.experts-exchange.com/Security/Encryption/A_12134-Choosing-the-right-encryption-for-your-needs.html
-rich

Rich (or anyone else), how secure is the native SSD encryption (specifically for a Samsung 840 Evo)?  I have heard that for some SSD's the keys are stored in plain text on the drive itself, which defeats the purpose.

Also, in your article, you mention sleep and hibernation not being secure while using TC FDE.  Can you clarify that?  I understand that during sleep mode, the OS is still stored in RAM, but in hibernation, I thought that as long as the snapshot of memory and the hiberfil.sys are encrypted, the drive would be as secure as it would when it was shutdown.

TC states it cannot guarantee the FDE (hibernation file)encryption on some OS's (when hibernation file has already been created)
http://www.truecrypt.org/docs/hibernation-file

* Disclaimer: As Windows XP and Windows 2003 do not provide any API for encryption of hibernation files, TrueCrypt has to modify undocumented components of Windows XP/2003 in order to allow users to encrypt hibernation files. Therefore, TrueCrypt cannot guarantee that Windows XP/2003 hibernation files will always be encrypted. In response to our public complaint regarding the missing API, Microsoft began providing a public API for encryption of hibernation files on Windows Vista and later versions of Windows (for more information, see the Version History, section TrueCrypt 5.1a). Since version 7.0, TrueCrypt has used this API and therefore has been able to safely encrypt hibernation files under Windows Vista and later versions of Windows. Therefore, if you use Windows XP/2003 and want the hibernation file to be safely encrypted, we strongly recommend that you upgrade to Windows Vista or later and to TrueCrypt 7.0 or later.

The native encryption uses a secure algorithm, but the storage of that password can be dubious. I don't know of significant research in this side of things yet.
Also note about the hibernation or even just a locked screen, if the OS is running, or able to run again like taken out of sleep or hibernation, it's possible with Elcomsoft or Passware to get the decryotion key from memory if you can get physical access to a firewire port, or insert a PCMCIA to Firewire adapter. Using the decryption key an attacker could then turn off the computer, pop out the HDD and provide the key and mount the drive.
There is also a SATA password one can use in bios, these can be reset/removed and in some cases, you can swap the HDD's board for one that isn't pwd'd, and then access the drive. This would not work for hardware encrypted drives, but does against that bios feature.
-rich

Disk password is not encryption. It is access control. i.e it should erase drive if no good password is provided (but dont take it for granted)

Hi.

Let me challenge RichRumble's statement "Wear-levling and Trim methods on SSD's make using TrueCrypt a big no no" with this link to Symantec (PGP) support: http://www.symantec.com/business/support/index?page=content&id=TECH203315
Question: "Does Symantec Drive Encryption completely encrypt Solid State Drives (SSD)?"
Part of the answer: "Since Symantec Drive encryption works at the block level below the file system level,  it is immune to this [=wear-leveling-introduced] security weakness"

We also run other encryption products on SSDs, for example SINA virtual workstations. http://www.secunet.com/en/topics-solutions/high-security/sina/sina-workstation/ - I once asked the manufacturers if their certification for data security (military grade confidential) is also applicable if this product runs with SSDs  - and it is indeed.

I can't agree with Symantec's assertions 100%, from a PGP dev themselves:
http://paulstamatiou.com/pgp-disk-encryption-safe-for-solid-state-drives

We could also debate about whether or not the wear leveling would leave plaintext in some nook or cranny. My answer is probably not -- since the WDE process is doing a sweep across the drive, it has to hit every sector. But of course, there are extra sectors for bad block replacement as well. We quickly get into the area where there's no possible definitive statement. However, if one is really paranoid, it should be obvious that it is better to encrypt the disk *before* you put sensitive data on it, because that will always be protected.

This is what TC says as well (unlikely but the possibility exists), encrypt before any data that is sensitive is placed on the drive. But I do stand corrected on the reduces the life of the drive, once it's encrypted, it should be like any other drive in that way. I don't see TC saying anything that PGP now Symantec isn't, however I do have to question the tone of finality of the link/quote from symantec, and the gibberish that they work on some level that others don't. Most if not all FDE work below the FS layer, it's no secret Symantec :p
As my article says at the beginning, there are many steps and caveats to security and the products of security. We have to read, research and question/verify those claims all the time. If I were the OP I'd use the built-in encryption since it's done in the hardware and while there isn't much effect on performance I've been able to measure with software like PGP/TC/Bitlocker, there should be next to nothing for the hardware encryption.
I can't get behind any Gov't claims of security or certification of late, and there are many other instances, one or two in my article, that point this out too. I don't want to derail the Q any more.

1) [MAIN QUESTION] Will enabling the SSD's encryption functionality (by enabling the BIOS hard drive password)  have any effect on the performance of the SSD Drive that is already encrypted with TrueCrypt (Full Disk)?

Bios password is bypassable by plugging HD into an adapter or another bios, or resetting the bios etc... FDE of the drive won't have anything to do with the bios. ATA(sata) passwords are also bypassable.

2) Would this be redundant to have both the SSD AES encryption enabled and TrueCrypt enabled?  My understanding is that onboard SSD encryption (key storage method and location unknown) may not be as secure TrueCrypt.

I think it would be redundant, but I don't believe the passwords are kept in plain-text, but you never know.
-rich

PGP does not even mention the crucial point that you linked before with the TC wear levelling link: "For instance, when you change a volume password/keyfile(s), the volume header is, under normal conditions, overwritten with a re-encrypted version of the header. However, when the volume resides on a device that utilizes a wear-leveling mechanism, TrueCrypt cannot ensure that the older header is really overwritten. If an adversary found the old volume header (which was to be overwritten) on the device, he could use it to mount the volume using an old compromised password (and/or using compromised keyfiles that were necessary to mount the volume before the volume header was re-encrypted). "

Could not find any statement by Symantec concerning the headers.

It's all speculation, and SSD plus the added baggage will make for some interesting talks in the future: https://www1.informatik.uni-erlangen.de/filepool/projects/sed/seds-at-risks.pdf
I read over that briefly, and all I took away from it is that you can keep an SSD "alive" very easily because reboots don't turn off the drive all the way and the SED is still "unlocked" until they lose power.
-rich

While wear leveling ensures old block is not immediately re-written, if it is followed by full re-encryption and normal writes to "fully encrypted disk" sooner or later the old key will be rewriten. (say it keeps 1-5% of data aside to kill bad blocks... so it may take slightly more than full rewrite)

Bios password is bypassable by plugging HD into an adapter or another bios, or resetting the bios etc... FDE of the drive won't have anything to do with the bios. ATA(sata) passwords are also bypassable.

I am getting some conflicting information about the BIOS drive password and how it is linked with the SSD.  I do recall that the passwords could be bypassed for standard HDD and SSD (without encryption).   My understanding was that you had to set the BIOS drive password, and it would be linked with the encryption-enabled SSD Drive so that resetting the BIOS, etc. would not bypass the security.  Can someone clarify this?

Sorry, I feel like the original question has opened some side issues, but it all goes back to security and performance.  If I can ascertain that using the on-board hardware encryption of the SSD Drive (specifically the Samsung 840 Evo) is reasonably secure compared to TC FDE, I could regain the performance of the SSD drive by disabling TC and using the SSD encryption instead (also assuming that RSA's BSAFE key generation isn't used by TC or Samsung).

There is no independent confirmation it encrypts at all.
Even less that it encrypts right

Bios is independent of it's hardware, with the exception of TPM. If the SSD is using the TPM, then maybe you can't bypass it so easily. SED and FDE are different than one another, I can't find anything that says Samsung's SSD/SED uses or can use TPM.

The make it *sound* like they use it (TPM), but I can't confirm, maybe you're manual or documentation can?
http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/about/whitepaper06.html
That is all I can find on the site for tpm+840+ssd+site:samsung.com, the TPM/OPAL group list Samsung but again I don't know if it's default or if it works like it's claimed
http://www.trustedcomputinggroup.org/community/2010/03/selfencrypting_drives_take_off_for_strong_data_protection
-rich

OK, that seems reasonable that TPM can pass whole 256 bits (32char) ATA password as opposed to typical 8 char BIOS disk password box (90^8 = ~ 52bits)

Still nobody guarantees that drive encrypts at all....
Just that it says it erases data if you cannot profide password...

My computer doesn't have TPM, but the BIOS hard drive password allows for 32 chars.

In terms of security, here is another website that mentions that the key is stored encrypted on the drive itself:

On the 840 Evo all data is encrypted. The block cipher key is stored on flash. When the ATA password gets enabled the SSD erases that key and stores an encrypted key that can only be decrypted with the ATA password. That is how it is supposed to work, at least.

  from: http://www.tomshardware.com/answers/id-1876643/setting-password-samsung-evo-840-bios.html
I would hardly call this definitive evidence that it is as secure (or similar) as software based encryption, but at least it's more information than I had before.

Their text does not say about key derivation.
It might be fixed key for time of life of the drive, same for each data sector.
Since there is no performance loss(statement including greater power consumption) i doubt any encryption takes place at all...