Using MX500 hardware encryption on Linux

Kilobyte Kid

Using MX500 hardware encryption on Linux

Hi,

 

I've searched for an answer to this on the forum so my apologies if I missed it.

 

I have a MX500 drive installed as a data drive on a Linux system. Currently I use LUKS to provide full disk encryption and I type in the password when I mount the data drive. To be clear this isn't a boot drive, it is purely a data drive. Using LUKS works but there is a significant performance impact. I'd like to take advantage of the hardware encryption built into the drive.

 

I've been looking at the hdparm utility whose man page mentions some useful looking options such as --security-set-pass and others, but also says the switches are dangerous and might not work with some kernels. My kernel is v3.4 (Debian v8.11).

 

Does anyone have experience on using a data drive on Linux with hardware encryption?

If I do a '--security-set-pass' will that effectively wipe the current data from the drive, or does it sweep through encrypting the sectors (in the way that Truecrypt used to do)?

 

I'd be very grateful if someone could share their knowledge and experience with me.

 

Cheers,

Mark

8 Replies
Kilobyte Kid

Re: Using MX500 hardware encryption on Linux

Have a look at sedutil. It's basically a toolset for managing OPAL-compliant drives.

https://github.com/Drive-Trust-Alliance/sedutil

https://github.com/Drive-Trust-Alliance/sedutil/wiki (wiki with howtos)

 

I used it on a friend's computer in combination with a Samsung SSD (850 EVO), because Windows 8.1 Home doesn't support Bitlocker and Laptop should be encrypted.

 

Because you want to use it as a data drive, you won't need to flash the pre-boot image.

Just use sedutil inside your Linux installation for setting up and unlocking.

 

Just in case make a backup, but in theory no wiping is done.

Your drive is already pre-encrypted (from factory), but decrypts on powerup.

With sedutil you just add a user-defined passphrase and that locks it down

Best of all: in opposite to ATA-Security (through hdparm or BIOS), OPAL is able to factory-reset with your PSID-code - but your data is lost of course! so near-to-zero chance of bricking your SSD

 

Please be aware, that hardware encryption is not 100% safe. Just recently researchers found serious flaws in Crucial SSDs (only MX100, MX200 and MX300 got tested, so state of MX500 is unknown)

If you are in need of extreme encryption, just use both (hard- and software). Then you could opt for an software-algorithm with performance in mind.

JEDEC Jedi

Re: Using MX500 hardware encryption on Linux

Here is a very good article providing details about ATA Security & Opal Security.  It has very good information about how to use ATA Security.

 

Make sure to check out all of the links within the pages @BerndLauert linked as information is scattered throughout.     I would suggest performing a Sanitize or possibly a PSID revert before storing data so you change the data encryption key.  I believe both options will create a new encryption key.   hdparm has the Sanitize options in addition to the ATA Secure erase option, but it is not properly documented (at least on Debian).  Check ALL three places to get all the information about these features as pieces are scattered:

 

man  hdparm

sudo  hdparm  -h

sudo  hdparm  --security-help

 

Using hdparm to enable ATA Security should not be a problem.   The only issue would be if the drive is installed internally and the BIOS has the option for hard drive passwords, then perhaps the BIOS won't be able to unlock the drive.   Some BIOS implentations modify or store the password onto the drive differently so people ran into problems unlocking the drive if the system was dead.  Enabling it with Linux hdparm first is best so you know you can access the drive anywhere.  I've been using the ATA Secure Erase since Debian Wheezy and kernel 3.x series without issue.   If you use it to Secure Erase just make sure the drive is installed internally or you could have issues.   Locking & unlocking the drive for security can be done over USB too (just not the Secure Erase).   If you use ATA Security, make sure to enable the Master user so you can unlock the drive with a second user & password or have the ability to Secure Erase the drive and reset the User password so you don't end up with a brick.  ATA Security can be enabled & disabled without affecting the data on the drive.

 

ATA Security (BIOS HD password) never really took due to the various implementations of the BIOS making portability risky.  Also the password is stored on the drive in a manner that isn't too difficult to retrieve.   I haven't actually used sedutil for encryption yet, but I would suggest you go with that since it should be more secure even with the flaws @BerndLauert mentioned.   Unfortunately sedutil is not in the Debian repositories yet.  There was a bug report to include it, but it seems to have stalled.   I think everything is in place to include it as the kernel parameter necessary is supposed to be enabled by default in the Debian kernels now, so the maintainer probably needs a little reminder nudge to make it happen.

Kilobyte Kid

Re: Using MX500 hardware encryption on Linux

@BerndLauert

Thank you very much for your reply. I have spent some time reading around the git repository and some of the forks. My Debian machine is a Banana Pi which has a ARM Cortex A7 dual core cpu. None of the sedutil binaries in the repository have been built for ARM and so I will looking into building it myself.

 

Cheers,

Mark

Kilobyte Kid

Re: Using MX500 hardware encryption on Linux

@HWTech Thank you very much for your reply.

 

That is indeed a very good article. I would value some clarification on how the ATA security model works with a Self Encrypting Drive such as the MX500. I believe that in a SED there is a hidden encryption key. Does the ATA security password get used to encrypt that key or is it only used at a logic level to decide whether you are allowed access to the drive contents. My understanding of the Opal security platform is that it's along the lines of the later.

 

Today I decided to just try the hdparm security ATA commands on a spare MX100 SSD. It also was configured with LUKS and used as a data only drive connected via SATA to the Banana Pi. It was replaced by the MX500 when I needed more storage. I now appear to have done something to the MX100 drive which means I can't boot the Banana Pi when the drive is plugged in.

 

These are the steps I took.

1) I booted the Pi with the MX100 plugged into the SATA port.

2) I used hdparm -I /dev/sda to check and it reported "Master password revision code = 65534" "supported" "not enabled" "not locked" "not frozen" as I expected.

3) I did

hdparm --user-master m --security-set-pass 'SuperSecret!!'

and

hdparm --user-master u --security-set-pass 'Secret!'

 

4) At that point hdparm -I continued to reported 'not enabled'

5) I rebooted.

6) Now hdparm reported 'enabled' but still 'not locked'. I was still able to access the drive.

7) I powered off and booted. During boot the system crashes with a black screen. Briefly before that it's possible to see lots of messages that appear on screen for just a second or two. I'm able to stop the automatic boot in something called U-Boot 2016.01 which gives me a command line (=>) and lots of commands which presumably help diagnose issues at this level. It seems to serve the same sort of purpose as grub does, but I don't know if it can help at all with the MX100.

 

I'm still able to boot the Banana Pi with the MX500, but now the MX100 has this impact on it. I've even tried plugging the MX100 into the SATA port once the system is up, that leads to some messages in kern.log that indicate it's recognised the drive then the output to kern.log stops and the console fills with screens and screens of messages. I videod that to try and capture the problem.

 

ata1: hard resetting link

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

...

scsi 0:0:0:0: Direct-Access    ATA    Crucial_CT256MX1 ...

...

ata1: failed to read log page 10h (errno=-5)

ata1.00: exception Emask 0x1 SAct 0x2 SErr 0x0 action 0x0

ata1.00: irq_stat 0x40000000

ata1.00: failed command: READ FPDMA QUEUED

ata1.00: cmd ...

               res...

ata1.00: status: { DRDY ERR }

ata1.00: error: { ABRT }

ata1.00: supports DRM functions and may not be fully accessible

ata1.00: supports DRM functions and may not be fully accessible

ata1.00: configured for UDMA/133

ata1: EH complete

 

These repeat a lot, and later tend to be command: READ DMA instead of READ DMA QUEUED.

The last line on the console is

ata1.00: configured for UDMA/133

 

At which point the system is completed locked up. The console does react to the keyboard. the NIC doesn't respond to ping or ssh.

 

Any ideas what I can do to return the MX100 to normal and why this has happened?

The data on the drive is not needed. I have a Windows 7 machine that boots with the drive connected. When I open Disk Management it offers to initialize the disk. I've not taken that option at this time. I don't know if it would help.

 

Cheers,

Mark

[EDITED: To remove my mention of stack trace - I think that was wrong and misleading]

Kilobyte Kid

Re: Using MX500 hardware encryption on Linux

@HWTech Thank you very much for your reply. I did type a reply to you previously but today I don't see it so I fear I must have done something stupid and lost it.

 

In that reply I described the problems I encountered with using hdparm on my Banana Pi which lead to a broken situation. I will describe it all here in case it is useful to others in the future.

 

On my Banana Pi (ARM Cortex A7) machine I plugged in a spare Crucial MX100 so I could test out the hdparm security parameters without risking my main MX500 and it's data. I'm so glad I did. This is what happened.

 

Banana Pi is running Debian v8.11 with Kernel v3.4.113 and hdparm v9.43.

 

1) I booted off the SD card with the MX100 data drive attached via the SATA port

2) I checked the security status with hdparm -I /dev/sda

     "supported" "not enabled" "not locked"

3) # hdparm --user-master m --security-set-pass 'SuperSecret!!'

    # hdparm --user-master u --security-set-pass 'Secret!'

    hdparm still reported 'not enabled'

    # hdparm -I /dev/sda

     "supported" "not enabled" "not locked"

 4) I rebooted

    hdparm now reported 'enabled'

    # hdparm -I /dev/sda

     "supported" "enabled" "not locked"

 5) I powered off and tried to boot. The boot process hung part way through and I was unable to get to a unix command prompt. The machine didn't respond to ping or ssh. If I connected the drive after it had booted it also locked up the OS.

 

At this point I was having troubles working with the MX100 drive at all. If I booted with the MX500 all was fine.

 

I tried the 'Crucial Storage Executive' program on a Windows 7 machine which confirmed the drive was locked, but I was unable to find anyway to use the utility to provide the password to unlock it. It seems crazy to me that this functionality isn't available.

 

I solved my problem by booting my desktop machine from a Ubuntu Linux v16.04.1 Live CD (Kernel v4.4.0-31, hdparm v9.48). It was happy to boot with the MX100 connected. I was then able to issue the command

# hdparm --user-master u --security-disable 'Secret!' /dev/sdd

Which has successfully disabled ATA security and now the MX100 works as normal with the Banana Pi. Phew.

 

So I have learnt a few things. I believe that once I have a sufficiently modern version of the Linux kernel and hdparm on my Banana Pi then I will be able to use the hdparm commands to unlock and mount my drive. The difference in read speed is x10 using /dev/sda vs the LUKS /dev/mapper/data device. 10MB/s vs 110MB/s. So that will be welcome.

 

I would still like to get it clear what level of protection the ATA security provides me. If I understand it correctly a sufficiently technical adversary could use an custom firmware, or direct access to the SED controller to examination of the flash memory contents even though the bits on the flash chips are encrypted. Is that correct?

 

Cheers,

Mark

JEDEC Jedi

Re: Using MX500 hardware encryption on Linux

Thanks for the update.  That is very interesting.  If I can find a few spare moments I'll test it out with an old hard drive and a Wheezy install I have.  May even spin up a Jessie minimal install as well.  Glad you were able to recover.

 

As far as the security of ATA Security, I never looked too deep into the password issue.  I think it depends on the implementation which varies by drive.  I think it would be ok for many people.  With an SED the data is always encrypted unlike a standard SSD or hard drive.  If the sedutil doesn't have an ARM version, then at the moment you don't much choice if you want to increase performance.

  

Kilobyte Kid

Re: Using MX500 hardware encryption on Linux


@marky1124 wrote:

 

I tried the 'Crucial Storage Executive' program on a Windows 7 machine which confirmed the drive was locked, but I was unable to find anyway to use the utility to provide the password to unlock it. It seems crazy to me that this functionality isn't available.

I assume this piece of software is intended for the average PC user, and someone like that would just rely on the builtin OS tools like Bitlocker. ATA Security in most cases is handled by the BIOS in laptops. So no need for implementation. Some laptops are known for altering the typed passphrase in a weird way or just setting a default manufacturer-known default password (Dell, Lenovo, Asus come in mind did one or the other thing in the past). This would just lead to much to many bugreports on Crucial's side. 

 


On my Banana Pi (ARM Cortex A7) machine I plugged in a spare Crucial MX100 so I could test out the hdparm security parameters without risking my main MX500 and it's data. I'm so glad I did. This is what happened.

 

Banana Pi is running Debian v8.11 with Kernel v3.4.113 and hdparm v9.43.

 

1) I booted off the SD card with the MX100 data drive attached via the SATA port

2) I checked the security status with hdparm -I /dev/sda

     "supported" "not enabled" "not locked"

3) # hdparm --user-master m --security-set-pass 'SuperSecret!!'

    # hdparm --user-master u --security-set-pass 'Secret!'

    hdparm still reported 'not enabled'

    # hdparm -I /dev/sda

     "supported" "not enabled" "not locked"

 4) I rebooted

    hdparm now reported 'enabled'

    # hdparm -I /dev/sda

     "supported" "enabled" "not locked"

 5) I powered off and tried to boot. The boot process hung part way through and I was unable to get to a unix command prompt. The machine didn't respond to ping or ssh. If I connected the drive after it had booted it also locked up the OS.

 

 

One idea that came to my mind after you mentioning Banana Pi:

maybe the SATA port on your Banana Pi does not fully adhere to SATA standards

I know this problem is prevalent on USB-connected SATA interfaces, where some or none of the ATA commands are getting through

 

maybe you should ask this question again in a Banana Pi forum for the reason that the interface or drivers are the culprits

Kilobyte Kid

Re: Using MX500 hardware encryption on Linux

Thanks for the reply @BerndLauert

 

I think the problem is the kernel. I tried an Armbian kernel for my Banana Pi M1 obtained from https://www.armbian.com/bananapi/. At the time it was listed as mainline kernel v4.14.y. Using that I was able to set the ATA password on my MX100, power down and rebooted successfully. The drive showed as locked in hdparm -I and at that point fdisk -l reported input/output error as expected. I was then able to provide the password and see the drive unlock and then IO to the drive worked.

 

I feel like I now understand what ATA security provides and how I could use it. Now to see if I can get an ARM build of sedutils working. If anyone has experience of doing that successfully I'd be very grateful to hear the details.

 

Cheers,

Mark