Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

1 Answer 1

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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