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.