09-29-2018 05:58 AM - edited 09-29-2018 06:05 AM
sudo hdparm -I /dev/sda
should return, among other things, some Security info, like this:
Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
My CT128MX100SSD1 does return the other things, but not the Security info.
I want to secure erase this SSD. But...
sudo hdparm --security-set-pass PASS /dev/sda
/dev/sda: Issuing SECURITY_SET_PASS command, password="PASS", user=user, mode=high SG_IO: bad/missing sense data, sb: 70 00 05 00 00 00 00 0a 04 51 60 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Updating to firmware MU03 didn't fix the problem. I am running a live version of Ubuntu 16.04.5. The SSD cannot be frozen, because i connected the SSD to the SATA port after booting. I was able to secure erase another MX100 from a friend just fine.
Solved! Go to Solution.
09-29-2018 06:42 AM - edited 09-29-2018 06:42 AM
I realise you;re using Linux atm, but if it's ever had Windows 8 or later on it, ATA Security will have been disabled in favour of Microsoft eDrive security. The solution is to do a PSID Revert from Crucial Storage Executive.
09-29-2018 07:28 AM
The SSD had W10 installed on it, but i doubt it is BitLocker encrypted, because i could attach the SSD to another PC (via a SATA-to-USB adapter) and copy files from the SSD to that PC.
09-29-2018 07:44 AM - edited 09-29-2018 07:47 AM
It's not to do with whether bitlocker is enabled or not. During install of W8 or later, Windows will disable ATA Security (of which Secure Erase is part) in favour of their own eDrive (which is based on the newer TCG Opal standard). This will happen on any Opal compatible drive that isn't already ATA Secured (ie with a password set).
The only course of action to restore the older ATA Security standard once this has happened is to do a PSID Revert on the drive.
09-29-2018 07:49 AM - edited 09-29-2018 01:13 PM
You were right! A PSID revert fixed the problem. After that, i used CSE to sanitize the SSD. By the way, i noticed that the CSE sanitizing process takes much longer than hdparm secure erasing. But it should be the same operation, right? Just erasing every physical block.
09-29-2018 01:55 PM
I've never actually done a secure erase or a PSID revert myself but I believe a PSID revert also does an erase anyway as part of that process.
09-29-2018 03:14 PM
I've never performed a PSID reset or Sanitize before either and the details are not clearly documented on anything I've read. I don't know if a PSID revert reset the NAND or whether it just changes the crypto keys when it resets the drive features.
From my reading, everyone recommends the Sanitize option over a Secure Erase most likely since there is a chance to lock or even brick your drive. The Sanitize option when reviewing the Linux commands seem to separate out the block erase and the changing of the encryption keys. I believe the Sanitize option is available using hdparm now, but it is not well known or documented. I only discovered it the other day. Perhaps you can compare it with CSE.
I'll be doing my first PSID revert next week, but I don't know if I will have any time to investigate as I"m extremely busy at the moment.
FYI, if you do a diskpart clean on the SSD it disables ATA Security, but still leaves the drive open for access. The encryption keys are locked later with Bitlocker. When I did a fresh install of Win10 on an MX500 it did not prep the drive or enable encryption by default. Even when I prepared the drive using diskpart clean it did not enable encryption. I had to manually enable Bitlocker after the install. I was using an installer downloaded from Microsoft and not an OEM installer.
09-30-2018 01:53 AM - edited 09-30-2018 10:16 AM
"Some of Micron’s older SSDs that support only the SATA 3.0 specification do not support SANITIZE, so Security Erase is the preferred method. On newer Micron SSDs that support SATA 3.1 and later, the SSD supports both Security Erase and Sanitize commands."
IIRC, MX100 = SATA 3.0.
"Whether the sanitize operation is executed using SANITIZE BLOCK ERASE or the legacy SECURITY ERASE UNIT command, the drive-level operation is the same. Micron’s proprietary firmware instructs the SSD controller to send a BLOCK ERASE command to all NAND devices on the drive—including the NAND space reserved for overprovisioning and retired blocks."
So, the CSE sanitizing process should not take much longer than hdparm secure erasing, right?
09-30-2018 11:00 AM
@Br1ck3dSSD Thanks for finding that link it is a great find!
Based on your earlier post it would seem CSE's Sanitize function is most likely performing the Crypto Scramble & Secure Block Erase which is good. The hdparm secure-erase-enhanced option appears to do the same thing acording to the Micron blog. The PSID revert appears to just restore the SED to normal operations and creates a new encryption key.
FYI, hdparm v.9.5.1 does include the Sanitize options, but it is not properly documented in the Debian Stretch man pages for it. It seems it is only somewhat documented with a summary by "sudo hdparm -h". To get a summary of the ATA Security commands use "sudo hdparm --security-help" since they are not summarized with the general help listing. When I get time I need to report these as a bugs to the Debian maintainer.
12-10-2018 01:44 PM - edited 12-11-2018 01:48 AM
@HWTech Not saying you're wrong, maybe i'm wrong, but my understanding from the mentioned blogpost is the following.
$ sudo hdparm --security-erase-enhanced PASSWORD /dev/sdX
--security-erase-enhanced issues the ENHANCED SECURITY ERASE UNIT command, which should result in a Cryptographic Erase, which AFAIK basically means that the MEK (Media Encryption Key) will be reset.
$ sudo hdparm --security-erase PASSWORD /dev/sdX
--security-erase issues the SECURITY ERASE UNIT command, which should result in a BLOCK ERASE of all NAND blocks.
"Whether the sanitize operation is executed using SANITIZE BLOCK ERASE or the legacy SECURITY ERASE UNIT command, the drive-level operation is the same."
Maybe this statement is true for Micron SSDs, but I know (almost) for sure this does not apply to Crucial SSDs.
I tried both Crucial Storage Executive on Windows and Micron Storage Executive on Linux to sanitize a Crucial SSD. Both utilities need more than a minute to sanitize, whereas hdparm does it in a few seconds. I disbelieve that if a Crucial SSD receives the SECURITY ERASE UNIT command, then this will result in a BLOCK ERASE of all NAND blocks.
Little side-note: if you're trying to sanitize a Crucial SSD, which is your Windows 10 startup drive, then CSE will not be of any use. You should:
- first do a PSID revert
- then boot into a Linux live-CD and install/run msecli