2

According to my reading there are 2 known methods for using Self-Encrypting Drives (SED):

  1. hdparm

https://www.pugetsystems.com/labs/articles/Introduction-to-Self-Encrypting-Drives-SED-557/

  1. sedutils

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive

Yet, after reading information about each method, I still not sure about the following:

  1. Is it that these methods are two alternatives for the same thing ? Can I used both together ? (for example use one to lock and second to unlock)

  2. Is it that the main difference between these two methods is that hdparm requires BIOS ATA password feature, while sedutils does not require it ?

  3. Does it mean that sedutils is preferred way to use with SED drives because it doesn't require a BIOS supported ATA password ?

1

in this context SED = self encrypting disk

sedutil is that software package that is supposed to make things work in linux as far as i can tell. So i would not use hdparm other than for verifying and diagnosing.

The Drive Trust Alliance software (sedutil) is an Open Source (GPLv3) effort to make Self Encrypting Drive technology freely available to everyone. It is a combination of the two known available Open Source code bases today: msed and OpalTool.

After having purchased more than a few self-encrypting SSD's from a well-known hard drive maker, emailing them, and emailing LSI/Avago/Broadcom about the sas raid controller being able to make a SED "encrypt", as well as a well known server motherboard maker of which has TPM, I am finding this self-encryption is more of an advertisement and marketing ploy, in my opinion worthy of a class action would not surprise me if people just plug these in and think because they are "self-encrypting" that it all just happens; it does not!

  • instructions on how to make it work are almost non-existent

per your pugetsystem link: Something we discovered when we decided to start offering SED encryption on our systems is that full support for SED is actually very poor. There are plenty of hard drive and SSD models that support SED encryption (although finding those models can be difficult), but full support for SED also requires a compatible motherboard.

  • after emailing motherboard, raid controller, and hard disk maker one would think I would have some reasonable solution. No.

  • As an end user I think one would need "complete support" from the motherboard to be able to interface with the sata/sas controller to enable or cause self-encryption to happen. this encryption is different than "drive locking" at the sata/sas controller level (because the data on or in the disk is not encrypted).

  • The best i found was from a seagate product document on their 1200.2 ssd referencing drive encryption, however I've yet to make "self-encryption" work on my ssd(s). From documentation i've gathered it boils down to 2 scsi commands happening: SECURITY PROTOCOL OUT and SECURITY PROTOCOL IN. How does that happen, I do not know yet.
  • Most likely solution seems to be the sedutil package in linux and somehow using the command line interface sedutil-cli. This would all be from within the linux operating system as root as far as i can tell so far.
  • My initial responses regarding SED were all Microsoft Windows based; it certainly seems SED is still in the development stages and not ready for prime time use (not easily, one should not have to cli or hdparm commands at the levels being described in what instructions exist). However I do not doubt that a SED is capable of actually doing encryption within itself, but by default it does not happen and that is the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.