En este artículo se muestra lo fácil que es eludir las frases de contraseña ATA del BIOS, y termina con eso usando la API de disco de autocifrado de discos (SED) desde el sistema operativo no daría un impacto en el rendimiento. En Windows, esta API se llama Microsoft eDrive. Mira aquí y aquí .
¿Alguien sabe si Linux puede comunicarse directamente con la capa SED, por lo que Linux maneja la frase de contraseña?
Encontré GPL'd sedutil que permite administrar SED en la "capa SED":
msed - Administrar unidades de autocifrado
Este programa y su imagen de autorización previa al arranque le permiten habilitar el bloqueo en SED que cumplen con el estándar TCG OPAL 2.00 en máquinas con BIOS.
El autor de msed se asoció con Drive Trust Alliance para crear una solución empresarial GPL:
Estoy uniendo fuerzas con Drive Trust Alliance (Drive-Trust-Alliance en GitHub) para traer las mejores herramientas SED de código abierto posibles a la comunidad.
No sé si esto realmente responde la pregunta que querías. Sin embargo, he usado información en esta página: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Tuve un SSD auto cifrado. Utilicé el comando hdparm para establecer una contraseña de usuario, una contraseña maestra, y establecer la capacidad de contraseña maestra en "máximo" para que una contraseña maestra no se pueda desbloquear o deshabilitar, solo borrar. (Mi BIOS no me permitió establecer una contraseña maestra o el modo maestro. Esto es realmente inseguro ya que el fabricante (Dell) tiene la contraseña maestra y probablemente cualquier representante de servicio pueda obtenerla).
Un buen BIOS / UEFI debe desbloquear el controlador y congelarlo para que el sistema operativo no pueda deshabilitar la contraseña. Si el firmware deja la unidad sin congelar, podría ver cómo se puede deshabilitar la contraseña.
Sin embargo, todo esto supone que confía en que el firmware de las unidades no tenga una puerta trasera o un agujero de seguridad. El artículo que cita parece implicar que esto es común. Cuestiono cuán "fácil" es derrotar el nivel de BIOS ya que el artículo establece que la unidad ya debe estar desbloqueada. El artículo no decía si la seguridad de la unidad estaba congelada o no.
Si no confía en el firmware de las unidades, entonces no veo cómo ninguna de las funciones de contraseña de ATA puede ayudarlo. Para seguir beneficiándose de la unidad HW, necesitaría acceso al motor AES y poder programar la llave AES usted mismo.
fue: {No conozco una API de nivel HW de este tipo. Me interesaría si alguien tiene una referencia.}
Lo siento, debería haber leído todas sus referencias antes de responder. Los estándares en cuestión son TCG Opal 2.0 e IEEE-1667. Parece que 1667 pasa a un protocolo de respuesta de desafío sobre el intercambio de contraseña de texto claro de ATA. Sin embargo, me parece que las contraseñas todavía están almacenadas en la unidad y que aún debería confiar en el firmware de la unidad.