MX500 hardware encryption using BIOS password only.

Kilobyte Kid

MX500 hardware encryption using BIOS password only.

I set a password to my MX500 SSD only from BIOS(I enter the password when the laptop boot). Is the hardware encryption feature is used in this case? WHat happens if someone gets my computer, removes the SSD, unsolder flash chips and puts them to a eprom programmer device? Can he read may data? I use a linux OS. I do not want to use any additional encryption software .

1 Reply

Re: MX500 hardware encryption using BIOS password only.

If there are no security vulnerabilities allowing access to the ATA password or data encryption key, then the data on the SSD should be safe since it is always encrypted even when no security features are enabled.   Enabling the various security features (ATA Security, aka BIOS HD password, or OPAL security) restricts access to the data encryption key.   For most people it should be Ok.


Recently a university in the Netherlands published a report (easier to understand summary here) where they found vulnerabilities in the MX100/200/300 SEDs (plus some non-Crucial SEDs) which allowed them to decrypt the data through hacks like you described which also involved modifying the firmware (for both ATA Security & OPAL security).  Implementing security is very difficult and there are so many people that are amazingly good at finding vunerabilities.  I pretty much expect everything is vulnerable to some extent.


As for using the BIOS HD password, the only thing you might want to check is whether the BIOS modified the password  you entered when it stored it on the SSD.  You can check this by booting a Knoppix USB drive (or other Linux drive) and trying to unlock the SSD using hdparm.  If you can do this, then you know you can access your data if the laptop dies, otherwise you would need to fix the laptop or find another one to unlock your drive.   I forget if you can cancel entering the BIOS HD password so if you cannot, then you will  need to boot to Knoppix and connect the locked SSD with a USB adapter for testing.


The BIOS HD password or ATA Security feature you enabled basically keeps the drive from responding to most commands except for drive identification, SMART info & health, and  ATA Security commands until the drive is unlocked.   I would suggest setting the Master password so if for some reason you are unable to unlock the drive with the default "User" password, then you can either unlock it with the Master password or Secure Erase the SSD using the Master password to allow it to be reused (it depends on the security setting).   While Crucial has stated they have not enabled the Master password, it is always a good idea to use your own passwords to eliminate any possibility a password could exist.   Here is a very good article explaining how to use hdparm for managing ATA Security in case you ever need it.  I had to piece limited bits of information together before I stumbled across it.


Have you checked out OPAL security using sedutils?  It should be just about as easy as the BIOS password method once you install the PreBoot software onto the special hidden MBR area of the SED which prompts you for the password to decrypt the access keys which decrypt the data keys on the SED.  OPAL security should be more portable than the BIOS password.   AFAIK you don't actually need any software on your Linux system for normal use, but I may be mistaken since I haven't actually done this yet for a boot drive.  The one downside for me anyway is there is no native Debian package yet.  To better understand how to use & implement OPAL security, you will need to read the Wiki and all the links there, plus you might find some information on the Issues page.  The BIOS HD Password can be enabled/disabled without losing any data and I believe the same is true of OPAL security as well.  I was about to test Linux OPAL security for a boot drive for some laptops I'm getting ready to setup, but just haven't had the time yet.  I believe you can set more than one OPAL password and I would suggest you do so in case something corrupts the first one.