Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer

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.

share|improve this answer

You must log in to answer this question.

protected by JakeGould Oct 18 '15 at 6:24

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged .