No presente artigo é mostrado como é fácil para ignorar BIOS ATA frases-chave, e termina com que o uso de auto-Disk Encryption API (SED) discos de dentro do OS não daria um acerto de desempenho. No Windows, essa API é chamada Microsoft eDrive. Veja aqui e aqui .
Alguém sabe se o Linux pode se comunicar diretamente com a camada SED, então o Linux lida com a frase secreta?
Encontrei um sedutil GPL que permite gerenciar SEDs na "camada SED":
msed - Gerenciar unidades de criptografia automática
Este programa e a imagem que acompanha a Autorização de pré-inicialização permitem ativar o bloqueio de SEDs que estejam em conformidade com o padrão TCG OPAL 2.00 em máquinas de BIOS.
O autor da msed se uniu à Drive Trust Alliance para criar uma solução corporativa da GPL:
Estou unindo forças com a Drive Trust Alliance (Drive-Trust-Alliance no GitHub) para trazer as melhores ferramentas SED de código aberto possíveis para a comunidade.
Não sei se isso realmente está respondendo à pergunta que você queria. No entanto, usei as informações desta página: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Eu tinha um SSD auto-criptografado. Usei o comando hdparm para definir uma senha de usuário, uma senha mestra e definir o recurso de senha mestra para "máximo" para que uma senha mestra não possa ser desbloqueada ou desativada, basta apagar. (Meu BIOS não me permitiu definir uma senha mestra ou o modo mestre. Isso é realmente inseguro, pois o fabricante (Dell) possui a senha mestra e provavelmente qualquer representante de serviço pode obtê-la.)
Um bom BIOS / UEFI deve desbloquear o driver e congelá-lo para que a senha não possa ser desativada pelo sistema operacional. Se o firmware deixar a unidade descongelada, pude ver como a senha pode ser desativada.
No entanto, tudo isso pressupõe que você confia no firmware da unidade para não ter uma porta dos fundos ou uma falha de segurança. O artigo que você cita parece sugerir que isso é comum. Eu questiono o quão "fácil" é o nível de bios para derrotar, pois o artigo afirma que a unidade já deve estar desbloqueada. O artigo não dizia se a segurança da unidade estava congelada ou não.
Se você não confia no firmware das unidades, não vejo como alguma funcionalidade da senha do ATA pode ajudá-lo. Para se beneficiar ainda da unidade HW, você precisaria acessar o próprio mecanismo AES e poder programar a chave AES.
foi: {não conheço uma API no nível de HW. Eu ficaria interessado se alguém tiver uma referência.}
Desculpe, eu deveria ter lido todas as suas referências antes de responder. Os padrões em questão são TCG Opal 2.0 e IEEE-1667. Parece que 1667 mudou-se para um protocolo de resposta a desafios através da troca de senha de texto não criptografado da ATA. No entanto, parece-me que as senhas ainda estão armazenadas na unidade e você ainda precisa confiar no firmware da unidade.