A few questions regarding encryption on MX300 drive

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

1)  Yes, with the exception of some older OEM devices and boards which store the password on the HDD platter itself.  That's fairly uncommon now, though.

 

User turns on PC > BIOS firmware acknowledges the "ATA/HD0 Password" flag as "ON" > Prompts for password entry > User enters a password that the BIOS firmware will authenticate based on the password being correct as well as other values set when that password was created > ATA Trust Send signal is sent and received as trusted by the SED > Key Encryption Key (KEK) decrypts Data Encryption Key (DEK) > Data Encryption Key (DEK) then decrypts user data thus unlocking the drive.

 

Also note that some ATA password entry proceedures on boards ARE encrypted and thus the encrypted ATA password is verified by the KEK itself when it receives it, though only so long as the Trust Send signal accompanies the password.  Most, if not all, business/corporate/enterprise boards do this with Enhanced Security storage devices, as do many modern boards that are more security oriented.  Many boards with a fTPM (firmware TPM) or even a daughter-board TPM (the kind you can just plug in) will automatically use the TPM to encrypt and store the password.

 

Also of importance is ATA security is NOT the same as Opal security.  Using Opal security affords more security than ATA Enhanced Security and is completely different in how it works in comparison.  To use Opal security you must use Opal-specific software for SED control.  This requires IEEE 1667 compliance as well as Opal compliance.  IEEE 1667 has been standard since Windows 7 and is a way storage devices are authenticated.  It can also be modified using Group Policy (gpedit.msc).  

 

For those who run Opal-complient software with their SED, or servers with enterprise SED management with endpoint SED control, Opal-compliant SEDs use the BIOS to request the MBR of the SED and then returns a pre-boot record back to the user which contains the software's specific PBA (pre-boot activation).  The MBR and PBA are set up by the Opal-complient software.  This is why when you use such software, before PBA, the SED shows as a very small "shadow" drive.  That is the MBR that is set up via the software.

 

2) Yes, some SEDs store the ATA password on the drive's platter.  Though this is not very common since security requirements have been increasing substantially over the past 10 years as well as the increasing call for SED rescue procedures in the event the ATA password is forgotten, lost or corrupted.  The password itself being lost or corrupted can occur due to simple age of the drive or the rotten chance a sector is flagged as bad where the key is stored, and a bad sector (or more) does not in itself render a drive a paperweight; however, if the ATA security password is affected then the drive is a paperweight.  You cannot revive it as it has become "self-identifiable" and cannot identify with a device.  Even the drive's manufacturer can't help in this case.

 

This is pretty much obsolete with SEDs, since it will not adhere to TCG specifications, and also prevented entirely by mainboard manufacturers by mostly removing that option from their BIOS entirely, or by automatically setting the password to firmware.  When this problem occurs, it's almost always on cheaper large capacity home user drives since purpose drives (SSD/SSHD/Enterprise/NAS) will flat out reject the setting of an ATA password if it requires drive storage.  You will return an error code in the BIOS, or it will appear as set but if you go back into the BIOS, it will show the drive as unlocked.



gradinaruvasile wrote:
If 1 is true, someone takes a SED out of an ATA password protected laptop, puts it in another with a known password set, that should unlock the drive if the drive stores nothing about the password...

The drive requires authentication via its ATA Enhanced Security feature using the Trust Send command, which is provided by the BIOS, and that authentication is created at the original initialization of a password.  Ways it would be universal is with the storage of the ATA password on the drive's platter.  With it stored on the platter, that drive can be put into another laptop or PC and unlocked so long as the password is known.


Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

Thanks for the detailed info and patience.

Can you tell me this specific SED, the MX300 (CT275MX300SSD4), does it store the password anywhere or t is reliant only on BIOS/UEFI trust signals?

I would try it but 1. i have to open my laptop and another one and 2. i really don't want to unentionally erase the drive (i remember the first time i activated the password there was a question about secure erase - my data was already on the drive before setting the password).

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

gradinaruvasile wrote:

Thanks for the detailed info and patience.

Can you tell me this specific SED, the MX300 (CT275MX300SSD4), does it store the password anywhere or t is reliant only on BIOS/UEFI trust signals?

I would try it but 1. i have to open my laptop and another one and 2. i really don't want to unentionally erase the drive (i remember the first time i activated the password there was a question about secure erase - my data was already on the drive before setting the password).


If you use ATA passwords via the BIOS for locking the drive while at rest, they are usually stored in the actual drive's firmware and not on the platter.  I could not tell you for certain without knowing your BIOS manufacturer (AMI/Award/Intel) because they could possibly prevent that by sending the password directly to the board's firmware as another safety mechanism, where they're usually stored in EEPROM.  Some boards store them in SMRAM.

 

Why you generally can't just take the disk out and put it in another computer, enter the known BIOS password and have it work is because ATA Enhanced Security, when used via the BIOS, converts it to keyboard scan codes, which are scrambled if you were to find the password (I should have clerified this a few posts back).  That does not mean you can't switch keyboards and unlock the drive.  It just means it scrambles using your keyboard to do it but does not require the same keyboard to unscramble them.  It's hard to explain without showing you with a hard drive workbench terminal but the keyboard plays zero part in decryption or ATA security access granting other than when a password is first set or changed.

 

Now when you use ATA Enhanced Security using actual software (for example Wave Security Suite), it will encode the password in ASCII.  Same when you use hdparm (I personally prefer command-line despite it being unforgiving if you **bleep** up).  Wave EMBASSY Security Suite is fairly cheap and allows you to set pre-boot ATA security passwords right from Windows.  Wave EMBASSY Security Suite was nice back in the day - when SEDs were first coming out - but has dwindle in comparison to other programs.  Still, it's like $40 or something so not unreasonable if you want SED and TPM control for cheap.

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

So I did some testing the past few days with various SSDs/SEDs and their security features; particularly ATA security.

 

1) Only enterprise/business laptops, ServerWerks (and some others') motherboards, and security-oriented and business related desktop motherboards offer proper ATA security.  For example, Lenovo's Thinkpad and Dell's Latitude series are two laptops I worked around with, since I own 2 older ones and 2 new ones and they are business laptops.

 

Both the Thinkpad and Latitude offer legitimate and quite concrete ATA security for hard drive locking.  Unlike a brand like Acer, for example, you cannot get past the ATA password to do anything if you do not enter the proper password.  Many laptops - Acer, Compaq, ASUS, ect. - will let you simply exit out of the HD0 ATA password screen, using either a combination of key presses or simply hitting Escape, and allow you to go right into a manual boot of another device, like a USB drive.

 

Though the drive itself remained locked, even after booting into a custom WinPE SE USB I have, I was able to bypass the ATA security quite easily by doing some fairly routine techniques.  Simiarly, live Linux boot disks also allowed me to bypass ATA security using some simple techniques (won't divulve details publicly).

 

A few of them actually give you an actual "temporary" password after you enter the ATA HD0 password incorrectly too many times (Acer).  Acer's ATA HD0 security is the worst I've ever seen.

 

The business/enterprise laptops like Dell's Latitude series and Lenovo's Thinkpad series will NOT let you proceed past the ATA HD0 password input screen.  If you attempt to do anything other than enter the password, the device shuts down.

 

2) Next I tested 2 enterprise SSDs: Seagate Secure 1,200 GB SAS SSD (FIPS 140-2 validated mainstream endurance model) a Seagate Secure 400 GB SAS SSD regular SED high endurance model), as well as 4 regular Seagate Secure SEDs (1 is FIPS 140-2 validated, 2nd is not FIPS 140-2 validated by identical in design as the 1st, 3rd was a FDE.3 and 4th was a DriveTrust SED).  My SAS SSD SEDs were tested in a 2013 Dell Optiplex running Windows Server 2012 R2 and my 2016 Optiplex server running Windows Server 2016 Datacenter.  Both use ServerWerks motherboards.

 

To make a long story short, even using some of the hardware I have that have very little problems "tricking" regular SEDs into remaining in an active state, thus allowing me to bypass any form of security on them and use a special power/data clamp to divert the drives' data, I was unable to use any of that hardware successfully.  Though I expected as such, since SAS is generally much more difficult to bypass simply because of the difference in its interface.  Most tools to bypass either Opal or ATA security cannot get a good bypass connection on them due to their placement in server racks, their recessed interface connectors, as well as their designed sensitivity.

 

Seagate Secure SEDs (modern ones) require a change of master password in order to fully secure the drive.  That has to be done with something like hdparm.  Other SEDs (SSDs included) also require the same.

 

3) I was able to bypass ATA security on 8 regular SED SSDs I tried when placed in desktop computers.  I was unable to bypass ATA security on them when placed in certain laptops (the majority were not a problem to bypass, either).  Certain laptops (business/enterprise/workstation) are designed where the drive connects fairly deep inside the laptop itself after inserting it.  This is to prevent any attempt to divert data directly from the interface and the only way to access its interface is to remove the drive from the port (which locks it).  Conversely, most other laptops are designed to make swapping drives and placing them in the bay extremely easy by having their connection point visible and accessible simply by removing a few screws, if that.

 

4) Opal security with PBA management is significaly more secure than ATA security; however, ATA security is very viable and impressive on certain laptops since almost all business/enterprise/workstation laptops have additional security features built into them to prevent any sort of tampering or bypassing of ATA security.  Those laptops/desktops that do not, however, simply offer moderate ATA security that is sufficient for the regular person, but nowhere remotely sufficient  for anyone with state, federal or HIPPA sensitive data (though in all fairness, you must also use FIPS 140-2 validated drives for that as required by 99% of agencies to prevent any auditing).

 

tl;dr

 

- ATA security is quite good though depends entirely on the rest of the system.  Simply being able to set a HD ATA password means nothing, as it's easily cirvumvented.

- Opal security supercedes ATA security due to the fact it requires other management software to utilize, as well as offering various degrees of PBA which can often require a secure network connection to unlock via certificate based verification, biometrics, physical or virtual smart cards, TPMs, etc.

- ATA security is free while good Opal security software is not free.

- ATA security is only as secure as the design of the system you have, and what additional security features the motherboard and BIOS offer to mitigate attempts to circumvent the ATA security.

- 95% of ATA passwords are placed in a portion of a SSD/HDD called the management partition.  It's inacessible unless you have some very exclusive hardware and tools.  

- ATA passwords are often obfuscated by "hiding" them in hash strings which need to be deciphered in a certain order in to access the password.  Hash scripts can remidy this, though not all hash strings are alike and vary.

- Most laptops create a checksum for the password that is placed in the FlashROM.

- Some laptops encrypt the password itself and place it  in the FlashROM.

- Software like hdparm will encode the password in ASCII, while BIOS created passwords are encoded using keyboard scan codes.

- When setting ATA security on laptops/workstations that are not designed and built for business, e.g. having various additional features for password security and reducing chances of circumventing the password, it's best to use hdparm as opposed to the BIOS.  That said, hdparm will require you to have a small Linux distro on a USB stick where you will have to boot into in oder to remove the drive's password which can be tedious if Linux is not what you use as your OS.

 

I could go into much more detail but it would undoubtedly be frowned upon by Crucial staff and forum moderators.

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

Guys, I still can't understand whether I can enable that internal HW-based encryption during Linux setup or not. As I understood, the password that I can set in BIOS is not related to drive's AES encryption. I mean Crucial MX300 750Gb  2.5" SATA drive (CT750MX300SSD1) here.

From Siberia with love!
Highlighted
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

Rabinovitch wrote:

Guys, I still can't understand whether I can enable that internal HW-based encryption during Linux setup or not. As I understood, the password that I can set in BIOS is not related to drive's AES encryption. I mean Crucial MX300 750Gb  2.5" SATA drive (CT750MX300SSD1) here.


The hardware encryption on any self-encrypting drive is automatic and does not need turned on.  The password you can set in the BIOS is the ATA password (hard drive password), which locks the drive to secure it when the drive is off, but the ATA password itself plays no role in the hardware-based encryption and is entirely independent, safe some manufacturers - like Lenovo and Dell - who utilize vendor-unique extensions allowing the ATA protocol to also send and receive Trusted (COM2) commands.  This is also how they're able to do cryptographic sanitation of a SED without requiring the PSID.  The BIOS on these business laptops allow for the proper setting of ATA enhanced security roles adhering to FIPS Approved Mode (Master and User).  Setting both a Master and a User password sets the drive in "High" security mode, while setting only the User role sets the drive to "Maximum" security mode.  These passwords then directly correspond to the Read/Write data authentication for the drive.

 

In short, hardware encryption on your drive is already enabled and cannot be disabled.  Only can the security mode in which the drive operates be enabled or disabled.  One mode is the use of a hard drive password using ATA enhanced security.

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

I got it. But it seems that it's more secure to use 'sedutil' by Drive Trust Alliance, right?

From Siberia with love!
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive


Rabinovitch wrote:

I got it. But it seems that it's more secure to use 'sedutil' by Drive Trust Alliance, right?


Opal is far superior to ATA, and both are superior to eDrive (Microsoft's shady practices never cease to amaze); however, most people are simply looking for the ability to lock their SED and not utilize all of the other Opal functions available (multiple users, create and configure multiple LBA ranges, assign access control to various LBA ranges for Users, muti-factor PBA, etc.)  For that, the ATA security I detailed above - with proper Trust commands being utilized - is easier to set up and will do the job without having to do anything else via command-line.  Likewise, ATA security is farily unforgiving, particularly if you forget the ATA passphrase.  Opal, on the other hand, always has a way to revert the drive back to factory specs by doing a PSID revert.  Not to mention, Opal allows passphrases that allow for increased length and any character you wish to use.

 

Sedutil is the only free option one has to be able to lock Opal 1 and 2 drives on desktops and laptops that do not have ATA enhanced security BIOS features.  I would always recommend using Opal SSC as opposed to ATA if you have the 10-15 minutes to set it up.  I would never recommend eDrive.