In this article it is shown how easy it is to bypass BIOS ATA passphrases, and it ends with that using the disks self-Encryption Disk (SED) API from within the OS would not give a performance hit. On Windows this API is called Microsoft eDrive. See here and here.

Does anyone know if Linux can communicate directly with the SED layer, so Linux handles the passphrase?


I found GPL’d sedutil which allows managing SEDs at the "SED layer":

msed - Manage Self Encrypting Drives

This program and it's accompanying Pre-Boot Authorization image allow you to enable the locking in SED's that comply with the TCG OPAL 2.00 standard on bios machines.

The author of msed teamed up with Drive Trust Alliance to create a GPL’d enterprise solution:

I am joining forces with the Drive Trust Alliance (Drive-Trust-Alliance on GitHub) to bring the best possible open source SED tools to the community.


I don't know if this is really answering the question you wanted. However I have used information on this page: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I had a self encrypting SSD. I used the hdparm command to set a user password, a master password, and to set the master password capability to "maximum" so that a master password can not unlock or disable, just erase. (My BIOS did not let me set a master password or the master mode. This is indeed insecure as the manufacture (Dell) has the master password and probably any service rep can get it.)

A good BIOS/UEFI should unlock the driver and freeze it so that the password can not be disabled by the OS. If firmware leaves the drive unfrozen I could see how the password could be disabled.

However all this assumes you trust the drives firmware not to have a backdoor or security hole. The article you quote seems to imply this is common. I do question how "easy" the bios level is to defeat as the article states that the drive must already be unlocked. The article did not say if the drive security was frozen or not.

If you don't trust the drives firmware then I don't see how any of the ATA password functionality can help you. To still benefit from the drive HW you would need access to the AES engine itself and be able to program the AES key yourself.

was: {I don't know of such a HW level API. I would be interested if someone has a reference.}

Sorry I should have read all your references before I answered. The standards in question are TCG Opal 2.0 and IEEE-1667. It appears that 1667 moves to a challange response protocol over ATA's clear text password exchange. However it appears to me that the passwords are still stored in the drive and you would still need to trust the drive firmware.

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