01-26-2017 01:46 PM
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)?
01-31-2017 07:32 PM
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.
01-31-2017 08:28 PM
This is an interesting topic, so here are the questions I'd like to raise:
01-31-2017 08:59 PM - edited 01-31-2017 09:03 PM
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.
01-31-2017 11:35 PM
02-01-2017 02:53 AM - edited 02-01-2017 03:26 AM
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.
02-01-2017 05:57 AM
Thanks for posting all this Godhand. I've never used encryption myself and know little about it. This is really interesting stuff!
02-01-2017 03:13 PM