Unlocking/Resetting Locked Self Encrypting Drives

[Jefferson Cowart]

Does anyone have an experience resetting locked self encrypting drives
(SEDs)? I have a number of Hitachi SSD SEDs (specifically
HUSMR1619ASS205) that are stuck in a locked state. They were removed
from a test environment with the assumption that we could simply
reset/re-key the drive and re-use it in another environment. We've
subsequently run into problems doing that. We don't want access to the
data; we simply want to be able to re-use the drives. Based on the
research I've done, there are generally two ways to unlock a drive:

* Provide the key it's expecting - The drives were previously installed
in a system that managed getting the keys from the external key manager
and using them to unlock the drives. There is a chance I could get the
keys exported from the key manager, but even if I were able to get them,
I'm not sure how I'd use them to unlock the drive.
* Issue a command to reset/revert/zeroize the drive - This instructs the
drive to replace it's internal encryption key and then unlock. Since the
key has been replaced the data isn't accessible, but the drive can be
re-used. Doing this typically requires using a PSID that is printed on
the drive label.

While our drives do have a PSID on the label, I can't figure out how to
use it to reset the drives. I've tried a few different PSID revert
tools, but I haven't had any success. (The primary one I've used is
https://github.com/Drive-Trust-Alliance/sedutil/wiki/PSID-Revert. I've
also tried tools from Seagate, Samsung, and Crucial. Unfortunately I
can't find a tool from Hitachi.) When I use the tool from GitHub above,
it doesn't detect the drives as OPAL compliant. Based on a comment
thread for that project
(https://github.com/Drive-Trust-Alliance/sedutil/issues/36) it sounds
like some enterprise SEDs don't completely follow OPAL, but that thread
also implies that the tool should at least give me some data about the
drives. Right now when I run that utility it gives me no data about the
drives. (Unfortunately I don't have the output in front of me, but it
gives me the same output for the locked SEDs that it does for a regular
drive.)

--
Thanks
Jefferson Cowart

[Edward Ned Harvey (lopser)]

> From: Jefferson Cowart [mailto:je...@cowart.net]

>
> Does anyone have an experience resetting locked self encrypting drives

I only have a little experience, and maybe what you're using is different, but my experience is this: A new self-encrypting drive, by default, has encryption turned off, but if you go into BIOS or EFI, you can enable encryption on that drive by entering a password. Subsequently, whenever the computer powers on, it prompts you to enter the password before the drive is accessible. If you want to blank the drive, you should be able to go into BIOS, and clear or reset the password.

[Jefferson Cowart]

Unfortunately these drives weren't locked with a password. They were
locked with an encryption key (I believe RSA or possibly DSA). I don't
currently have the keys, but I might be able to get them. However, I'm
not sure how to supply the key to the drive even if I got it.

If possible, my preference would be to simply tell the drive to replace
it's internal key and reset. Unfortunately I'm either using the tools
wrong, or these drives don't support the commands the reset tools I've
found use.

--
Thanks
Jefferson Cowart

[Tracy Reed]

I know this won't help and with apologies to Jefferson let this serve as
a cautionary tale to others: This is a good example of why SEDs are a
bad idea.

You cannot easily access your data in other systems even when you have
the key (Need a controller which supports SED or other keying mechanism)

You can't audit what's going on in the drive.

You don't get any real performance benefit on a modern CPU which
includes AES primitives.

You cannot change the algorithm should a flaw be discovered as it is
baked in.

You have logistical issues of having to source and maintain spares for
these special snowflake drives.

In the case of the Dell H700 controller the encryption key is stored in
the RAID controller and once entered is not prompted for again. Thieves
could yank the whole machine out of the rack, take it back to their evil
lair, plug it in, and boot it up and steal the data never having even
known it was encrypted on the SED. It is only useful for the case when
the drive is separated from the RAID controller such as when the machine
is decommissioned and parted out.

Yes, all of the encryption happens in the drive and the key is stored in
the drive hardware where a bad guy can't get at it but nobody is
interested in the key when they have raw read access to the data which
is exactly what they have when they are in the system such that they
could read the key out of the OS memory anyway.

There is really no good reason not to use LUKS (Linux) or BitLocker
(Microsoft) as these are built in, well supported, and don't have the
above issues.

On Fri, Feb 10, 2017 at 07:55:29PM PST, Jefferson Cowart spake thusly:

> --
> This list provided by the League of Professional System Administrators
> http://lopsa.org/
> --- You received this message because you are subscribed to the Google
> Groups "LOPSA Tech Discussion list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tech+uns...@lopsa.org.
> To post to this group, send email to te...@lopsa.org.
> To view this discussion on the web visit https://groups.google.com/a/lopsa.org/d/msgid/tech/ec59ffc2-a58a-734e-6968-e3f43427bfac%40cowart.net.

--
Tracy Reed, RHCE Digital signature attached for your protection.
Copilotco PCI/HIPAA/SOX Compliant Secure Managed Hosting
866-MY-COPILOT x101 http://copilotco.com

[Marcos Alano]

This is a silly question, but did you try to contact the support?
sup...@hgst.com Probably they have a tool to reset drive.