Dans cet article, il est montré à quel point il est facile de contourner les phrases de passe BIOS ATA, et cela se termine par le fait que l'utilisation de l'API SED (self-Encryption Disk) des disques à partir du système d'exploitation ne donnerait pas de résultats. Sous Windows, cette API est appelée Microsoft eDrive. Voir ici et ici .
Est-ce que quelqu'un sait si Linux peut communiquer directement avec la couche SED, donc Linux gère la phrase secrète?
Réponses:
J'ai trouvé sedutil sous GPL qui permet de gérer les SED au niveau de la "couche SED":
msed - Gérer les disques à chiffrement automatique
Ce programme et son image d'autorisation de pré-démarrage qui l'accompagne vous permettent d'activer le verrouillage des SED qui sont conformes à la norme TCG OPAL 2.00 sur les machines bios.
L' auteur de msed s'est associé à Drive Trust Alliance pour créer une solution d'entreprise GPL:
Je me joins à Drive Trust Alliance (Drive-Trust-Alliance sur GitHub) pour apporter les meilleurs outils SED open source possibles à la communauté.
Je ne sais pas si cela répond vraiment à la question que vous vouliez. Cependant, j'ai utilisé des informations sur cette page: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
J'avais un SSD à chiffrement automatique. J'ai utilisé la commande hdparm pour définir un mot de passe utilisateur, un mot de passe maître et pour définir la capacité du mot de passe maître sur "maximum" afin qu'un mot de passe maître ne puisse pas être déverrouillé ou désactivé, il suffit de l'effacer. (Mon BIOS ne m'a pas permis de définir un mot de passe maître ou le mode maître. Ceci est en effet peu sûr car le fabricant (Dell) a le mot de passe maître et probablement n'importe quel représentant du service peut l'obtenir.)
Un bon BIOS / UEFI devrait déverrouiller le pilote et le geler afin que le mot de passe ne puisse pas être désactivé par le système d'exploitation. Si le micrologiciel laisse le lecteur non gelé, je pouvais voir comment le mot de passe pouvait être désactivé.
Cependant, tout cela suppose que vous fassiez confiance au micrologiciel des disques pour ne pas avoir de porte dérobée ou de trou de sécurité. L'article que vous citez semble impliquer que cela est courant. Je me demande à quel point le niveau de bios est «facile» à vaincre car l'article indique que le lecteur doit déjà être déverrouillé. L'article ne dit pas si la sécurité du lecteur a été gelée ou non.
Si vous ne faites pas confiance au micrologiciel des lecteurs, je ne vois pas comment la fonctionnalité de mot de passe ATA peut vous aider. Pour continuer à bénéficier du disque dur, vous devez avoir accès au moteur AES lui-même et pouvoir programmer vous-même la clé AES.
était: {Je ne connais pas une telle API de niveau HW. Je serais intéressé si quelqu'un avait une référence.}
Désolé, j'aurais dû lire toutes vos références avant de répondre. Les normes en question sont TCG Opal 2.0 et IEEE-1667. Il semble que 1667 passe à un protocole de réponse challange sur l'échange de mot de passe en texte clair d'ATA. Cependant, il me semble que les mots de passe sont toujours stockés dans le lecteur et vous devrez toujours faire confiance au firmware du lecteur.