A few questions regarding encryption on MX300 drive

Kilobyte Kid

A few questions regarding encryption on MX300 drive

Hello,

I recently got a MX300 SSD (CT275MX300SSD4/M.2) drive for my work laptop because it has hardware encryption.

I have some questions regarding the encryption without any OS support (there is much talk about Windows specific features) that i would like to know a definite answer to. In my specific case i use Linux but we might consider this type of drive for Windows users too, but we do not want to  need any specific OS-based setup for anyone so i would like to ask a few questions with this scenario in mind.

 

1. This drive encrypts data automatically on write regardless of OS based settings? 

2. I set a drive password in the UEFI (We use Dell laptops, in my case it is a Precision 3510), will it be actually used to encrypt the drive?

3. If i put the drive in another laptop that supports disk passwords, will it be able to use the drive?

4. If a custom password is set in the UEFI and it's lost (or the computer is stolen), is there any method of recovering data from it (such as tampering with firmware etc)?

 

Thank you.

17 Replies
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

1) All SEDs - from my Enterprise server's Seagate SAS drives to its primary SSDs - encrypt moving data from the time they're built until they're destroyed.  So yes, it's always encrypting.  You just can't tell since it's hardware and completely isolated from you, the user.

 

2) ATA passwords (HD passwords) are better than nothing, but are not a great PBA (pre-boot authentication) option.  However, if that's all you have to secure you drive while at rest, then using it is a good idea.  Unfortunately, Dell does not allow for solid 32 character passwords.

 

3) Yes, if you enter the correct password.  It's encryption only - it does not also marry itself to the system the password was set on.

 

5) There ware many ways to bypass ATA hard drive BIOS passwords, especially with Dell.  Dell even has an official tool that you can boot with that will set a temporary password that's an elevated administrator's password for the BIOS, and allow users to clear a hard drive password without even first entering the old one.

 

 

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

This is an interesting topic, so here are the questions I'd like to raise:

  1. if I use a Crucial MX300 SSD with the ATA password correctly set, does this mean that the drive can NOT be decrypted, even if you bypass the ATA password? or, will the ATA password bypass somehow also ensure that the drive decrypts all the contents?
  2. wasn't the password protection feature supposed to be a part of the controller of the SSD? That being said, the controller should not allow bypassing the ATA password to gain access to data.
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

1) The drive can not be decrypted unless you know the ATA password.  However, to use the ATA password feature on any Opal drive, you must enable it BEFORE installing a Windows OS.  Windows will activate it as an Opal drive during its setup (right before partitioning the drive, actually).  Even if you did install Windows without first setting an ATA password, you can wipe the drive, using either diskpart clean or the PSID option and it will remove the Opal status of the drive, thus allowing you to set an ATA password and then install Windows.

 

TCG compliant drives use two additional commands for ATA Enhanced Security, in addition to all other non-SED ATA commands: Trust Send and Trust Receive.  Those are direct trusted commands from the BIOS and pre-boot environment to the drive itself and are solely for Enhanced Security.  If one were to "bypass" the ATA password, they would not get anywhere since the drive did not receive the trusted command entering the correct ATA password sends.

 

I mean there are always ways to do something.  Nothing is completely secure, after all.  The best ways to do this is to use a TPM with another pre-boot authentication utility, though a simple ATA password will work absolutely fine for 99% of the people out there.

 

2) The Data Encryption Key (DEK) uses a 256-bit hash, making it completely useless to anyone, even those of us who use DEK and KEK keys for user encryption on server MYSQL databases.  The Key Encryption Key (KEK) decrypts and encrypts the DEK.  Both are hidden in hardware.

 

Bypassing the ATA password will not allow someone to gain access to the data because the SED never received the trusted send command that the ATA password sends.  The only way to gain access to the data is through circuitry manipulation (which is not something you can just learn since it's basically machine code) or guessing the ATA password.

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

@GodHand: thank you, much appreciated!

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

Not a problem, man.

Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

About point 5:
-In my case i have the MX300 in this Dell laptop.
-I copied the original drive's content to this new drive.
-After i rebooted i accessed UEFI and set an ATA password.
-Functionally everything is ok, i booted, resized my partitions etc. I did not use any tool from the OS to access or modify anything related to the SSD (i have Linux installed if it matters in this case).

1. Now if the laptop is stolen and the thief boots it with the mentioned Dell utility, removes the ATA password, can he access the data on the drive?

2. From the answers above it is not clear to me that the data encryption itself is in fact influenced by the ATA password or not :
The ATA password acts as an actual data encryption key or is separatlely stored only to authenticate incoming requests (in which case the DEK? key stored in hardware is the only factor)?

PS please bear with me, i don't have much background in this matter...
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

[ Edited ]

1) No.  Removal of the password does not send the ATA Enhanced Security Trust Response.  Only proper entry of the password will signal a Trust Response and thus, a Trust Receive is authenticated by the encryption key which then gives you access to the disk.  The hardware encryption keys REQUIRE a Trust Response via correct ATA password entry.  The key "no pun intended" is to make sure the password (PINs are preferrable, actually) is not something that can be guessed based on your person.  I know a lot of people also set a system password, or Administrator password, that must be entered first.  Though that does not affect the SED's access, some people like securing access to even the ATA password option.

 

2) The ATA password does only one thing: sends a response.  The password itself has nothing to do with anything regarding the encryption itself.  The password is not authenticated by the encryption key, the reponse signal is.

 

For example a code to your home alarm.  It's not the code that signals the alarm to deactivate, even though you use it to do so.  It's the proper sequence of electronic signals that code sends that does.  The code itself is irrelevant to the system - just like the ATA password is irrelevant to the SED.

 

Moreover, the ATA password is not stored anywhere except for the BIOS' firmware.  Conversely, that can be exploited by those with experience in cryptography and have knowledge of BIOS firmware designs because some boards store that password unencrypted.  You have to know what you're doing, where to look and often times use developer tools leaked from a BIOS manufacturer to exploit that, though.  With that exploited, one would just have to turn off the firmware flag for "ATA/HD0 password on" (the flag can have different names on different BIOS and firmware vendors).

 

Again, ATA passwords work for most people without them worrying and without any compromises of their data, but it was not designed to be an immensely strong barrier between an intruder and your data, nor to be used to secure extremely sensitive data or bulk data.  Someone who knows what they're doing will get into any SED that's using the most common methods for securing them like eDrive/BitLocker, ATA, regular PBA software, OPROM extension flashes, etc.

 

Our supplied laptops, with FIPS certified SEDs, are initialized and deployed using enterprise server software with PBC (preboot-connect) which authenticates us over an encrypted network by using a CA issued certificate on multiple servers which first verify the validity of our own personal client certificates within virtual smart cards secured and controlled by a TPM in our devices, and then are approved using biometric scanning (retina usually; sometimes fingerprint) to unlock the drives.  Unfortunately, good SED control software is not cheap.  Wave is absolute trash.  WinMagic standalone is very good, though. Unfortunately, 99% of others are enterprise designed and not just for a standalone user.  But how they initialize and deploy our SEDs is just an example of security, even in a pre-boot environment.

 

Not a problem at all, man.  I work in global security and Criminology so I've been working with cryptography for quite a while and fiddle with it in my spare time, too.  With how my regular desktop PC and laptop are set up, you'd think I'd have secrets about Area 51 on them.

JEDEC Jedi

Re: A few questions regarding encryption on MX300 drive

Thanks for posting all this Godhand.  I've never used encryption myself and know little about it.  This is really interesting stuff!

_______________________________________
How do I know what memory to buy?
Shop for your region: US | UK | EU | France | Global
I think my memory is bad. What do I do now?
FAQs and Top Forum Solutions
We want your feedback! Post in the Suggestion Box
Did a user help you? Say thanks by giving Kudos!
Still need help? Contact Customer Service
Want to be a Super User?
Kilobyte Kid

Re: A few questions regarding encryption on MX300 drive

"Moreover, the ATA password is not stored anywhere except for the BIOS' firmware."

1. So, everything related to the password authentication takes place in the computer's BIOS/UEFI then the drive is unlocked by a trust signal?
2. Doesn't the drive itself store the password or a hash of it in its firmware? I read somewhere that some SEDs encrypt the encryption keys with the password.

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...