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]

Quick question - are the 320 series SSD's FDE.2 or FDE.3 compliant?

And, where can I find that in Intel's printed documentation?

Thanks!

[idata]

1). NEVER run software FDE on SSD. You may however encrypt specific folder/file(s) bu tnot whole SSD, in other words don't use BitLocker, TrueCrypt os similar. Unless you're willing to settle for a) enormous speed drop like 4-6 times especially writing b) wear out SSD sooner (more writing). Although I said "never" just as a side thought: FDE using BitLocker is faster on SSD drives than TrueCrypt, but again don't use any.

Software FDE is meant for regular harddrives, not SSD.

2) . As Uncle Joe pointed out, gthere's no need for FDE anyway - because Intel320 series is already encrypting in hardware. Unlike software FDE, hardware encryption (e.g. AES or another type) does NOt result in any measurable performance drop, it's "built-in" already.

3) However a big problem:

While many laptops' BIOS's allow to add "ATA password" (aka "harddrive password, lock, do not confuse with BIOS password which is a joke kids can crack in 15 minutes, I am talking about ATA password), most desktops don't. My highend HP "EliteBook" 8540w/8740w allow all kinds of password, even locking up I/O ports (USB3, audio, eSATA, etc.), and that's fine, but too many laptops and almost all desktops except professional/server type desktops don't have this ATA password extension/feature in BIOS.

Which renders any hardware encryption useless. Thieves simple remove your SSD and plug into another computer and your data is theirs.

Because SSD's were first meant for laptops.

Now SSD manufacturers are waking up and trying to bypass BIOS to add some kind of password to work in conjunction with hardware encryption, fo rpeople whose BIOS doesn't offer one. Intel or not, doesn't matter. OCZ & Crucial are trying same, but I strongly prefer Intel's reliability/stability (speed is nice, but losing data makes Crucials or OCZ speed meaningless, they fail more often and even reported to occasionally corrupt data).

So nothing you can do until Intel releases a new Toolbox with added password feature, until then hardware encryption means only one thing:

if someone was to remove SSD chips from circuit board, desolder & probe or solder onto another board, their contents is encrypted/protected, BUT if someone steals whole SSD which is obviously the simplest, straightforward thing todo (why would thieves disassemble SSD & remove chips?!? when they can steal whole SSD?), your data is theirs.

As of harddrives - yes, FDE is theonly solution if there's no way to enter ATA password on some lkaptops and almost all desktops. My HP EliteBook forunately ha sno such problem, it's got many ways to enter a password, but my MSI-motherboard based desktop doesn't, same is my HP DM1Z-2nd generation famour ultraportable that came out in March this year. Cheaper computers don't have it, highend/professional like HP EliteBooks & lenovo Thinkpads and my old Asus have it, HP EliteBooks has even numerous ways to add passwords.

So to summarize:

1) if your BIOS has ATA/harddisk password ability, if you configure it you're totally protected with Intel320 SSD's, same with harddrives if you also add FDE (do not setup software FDE on Intel320 as it would kill it, it already has FDE built into hardware)

2) If your BIOS doesn't allow ATApassword, there's no easy way to protect yourself until Intel releases new Toolbox

3) if you're like me who is a professional EEengineer, you wouldn't care for BIOS.

I hack/modify my SSD's & harddrives to ADD ATA PASSWORD WITHOUT ANY BIOS! I use heavy-duty lowlevel disk firmware hacktools which I won't be disclosing here b/c if you use them improperly & "brick" your drive you may blam eme or even Intel's Discussion Forum. I am ding some defense/govenment work so I aboslutely must be protected.

Too bad most desktops BIOS's & many laptps manufacturers assume we're dumb and cannot use ATA passwords properly. So it's not in many BIOS's despite being part of ATA Standard since 1997!! I had it even in mid 1990's on ancient IBM Thinkpad, I now have it in HP EliteBooks bu tnot everyone so lucky. If you buy a basic consumer laptop or 95% of desktops, they don't offer ATA password, though at least 3 Intel's motherboards do offer it - on SATA port0 Those with "Q67" chipset (business, not consumer).

[idata]

I'm not sure if you're a troll or just misinformed, but I'll bite.

1. This paragraph contains grand statements without any references to actual facts:

Speed: Some SSDs rely on compression to speed up writes, which will slow the SSD down if using encryption as encrypted data is random data which do not compress. This is not relevant on Intel SSDs as they do not compress data. Let's challenge your 4-6 times claim anyway with an SSD that *does* rely on compression:

http://www.anandtech.com/show/3667/oczs-agility-2-reviewed-the-first-sf1200-with-mp-firmware/6 http://www.anandtech.com/show/3667/oczs-agility-2-reviewed-the-first-sf1200-with-mp-firmware/6

As you can see the absolute worst case in this scenario is 57%. That's hardly 5-6 times, and it's not even applicable to Intel SSDs.

The actual software encryption speed also affects encrypting harddrives, so I don't think it's relevant to this discussion, but I'll mention it anyway for completeness sake: Most recent Intel CPUs have hardware AES encryption, removing this bottleneck. Even with software encryption my 2.4 ghz core 2 laptop (which is pretty old at this point) does 160MB/sec aes in TrueCrypt. This would slow down an SSD in certain workloads.

As for wearing out the SSD faster, this again only applies to SSDs that use data deduplication. I couldn't find hard info on Intel on this, but I believe they do not use it. Even if it did, wearing out an SSD is mostly a myth anyway for workstation workloads, which are mostly reads.

2. There is if you prefer using encryption that's well documented and well tested. There are many unanswered questions regarding Intel's implementation in this thread, and I'll likely not use it before those are put to rest.

3. Yes this is a problem on many motherboards, desktop and mobile alike. I think you're misunderstanding what you need on motherboards that do not support ATA passwords though. A new toolbox with "ata password features" wouldn't help at all, how would you boot the OS if you can't unlock the drive? What you need is a bootloader that asks for the ATA password and unlocks the SSD, then boots the OS, not unlike the TrueCrypt bootloader. MHDD might be able to do this: http://hddguru.com/software/2005.10.02-MHDD/ http://hddguru.com/software/2005.10.02-MHDD/

This will likely be my last post in this thread as there's really not constructive discussion going and for some reason it seems to attract a lot of trolls.

[idata]

Guest wrote:

1). NEVER run software FDE on SSD. You may however encrypt specific folder/file(s) bu tnot whole SSD, in other words don't use BitLocker, TrueCrypt os similar. Unless you're willing to settle for a) enormous speed drop like 4-6 times especially writing b) wear out SSD sooner (more writing). Although I said "never" just as a side thought: FDE using BitLocker is faster on SSD drives than TrueCrypt, but again don't use any. Software FDE is meant for regular harddrives, not SSD.

You may be a great "professional EEengineer", but I prefer to beleive Microsoft's SSD FAQ:

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

Is Bitlocker's encryption process optimized to work on SSDs?

Yes, on NTFS. When Bitlocker is first configured on a partition, the entire partition is read, encrypted and written back out. As this is done, the NTFS file system will issue Trim commands to help the SSD optimize its behavior.

We do encourage users concerned about their data privacy and protection to enable Bitlocker on their drives, including SSDs.

Yes, a some performance degradation will be, but no any problems with wear out.

ps: sorry if my English are not good.

[idata]

You can use hdparm utility in linux to unlock ATA-passsword protected drive (ssd included).

Just boot from a pendrive with one of those micro-small linux distributions (ttyLinux, tinycore, microcore, DSL) and issue:

hdparm --user-master u --security-unlock /dev/

inside your script which asks for password first...

and then, reboot. Security state of the disk is preserved during the warm reboot.

Not the most elegant solution as it requires additional restart but you can automate it mostly thanks to grub's fallback function.

And it could be fast. Small, good configured linux can boot in 5 seconds.

One can live with that.