System Requirements for Hardware Encryption on Crucial SEDs

Question

 
The majority of current Crucial SSDs are Self-Encrypting Drives (SEDs) which means all data is always encrypted by the controller when written to the NAND and decrypted when read. Windows 8 BitLocker can work with this built-in hardware encryption ability when you apply a password in Windows, provided the following requirements are met:
•    BitLocker only supports TPM version 1.2 and 2.0 (or newer). In addition, you must use a Microsoft-provided TPM driver (Please note, BitLocker can also work without a TPM, but it will need a USB flash drive to set the password instead)
•    The system needs to support UEFI 2.3.1
•    Make sure UEFI boot is enabled and you have a UEFI enabled Windows 8 installed
•    The computer must boot natively from UEFI.
•    The boot order must be set to start first from the SSD (not the USB or CD drives)
•    Dynamic discs are not supported by BitLocker
•    The SSD must have two partitions (drives with Windows installed generally do anyway) and the main partition to be encrypted must be NTFS
•    Ensure ATA Security features, for example Secure Boot, are disabled in the BIOS. The M500 supports either ATA Security or TCG Opal (which is needed for SED) but not both.
•    The system needs to support Opal 2.0 The Opal 2.0 standard is not backwards compatible; Crucial SEDs are not compatible with Opal 1.0
•    The computer must have the Compatibility Support Module (CSM) disabled in UEFI.
Looking for more information on Crucial SSDs?  Learn more here!
Looking for Customer Service? Contact Crucial Support for your region.

Answer 1

i'm very glad to read, from the article you referenced, that there's no performance hit.  but that's only 1 of 2½ issues.  i have some follow-up questions.  perhaps we should take this to a forum instead of the knowledge base?
-what about prior issue #2 (securely wiping the drive)?  is this easily and instantly doable?  we'll ignore #3 (relying on microsoft gets ½ a point). 
-with the encryption keys stored on the controller, doesn't using third-party encryption software mean the keys themselves aren't encrypted by a user pw, making it that much easier for someone with physical access to the drive to extract them from the firmware?
-if the controller is doing the encryption, why bother with bitlocker?  is it so slightly-more-savvy-than-average joe can easily enable it, or so you don't have to write it into the firmware?  (i'm being serious, not snarky--i'm a software developer myself.)  personally, i'm dual-booting win7* and ubuntu 14, which means i need 2 separate encryption methods instead of just supplying my credentials at boot to decrypt the hd and then choosing which os to load.
-also, if i upgrade the windows os, ms requires the os volume to be decrypted first.  this would obviously not be the case if windows was unaware that it was encrypted.
*last, what about those poor silly saps who are running win7 (or earlier)?  i just read that win7 bitlocker doesn't support self-encrypting drives--it was an update as of win8.  we're just out of luck?  i realize you can't support everything, but win7 is still a ms-supported os, and it seems like a better service to (more of) your customers to enable full-disk encryption all the time.
thank you!