Le mot de passe du disque dur dans le BIOS affecte-t-il de façon égale plusieurs disques?

J'ai un ordinateur portable Asus UX32V qui dispose à la fois d'un SSD intégré (24 Go, je pense) et d'un disque dur remplaçable. Il y a des années, j'ai remplacé le disque dur par un SSD de 250 Go (Samsung). Maintenant, je vais remplacer le SSD de 250 Go par un SSD de 500 Go (Crucial MX300).

Avec le SSD de 250 Go, j'ai installé Linux Mint avec un chiffrement au niveau logiciel LUKS. J'ai décidé que, avec le nouveau SSD de 500 Go, je veux utiliser l'encodage de disque au niveau du matériel qui est pris en charge par Crucial MX300.

Le BIOS de l'UX32V dispose de 4 mots de passe configurables:

  • (BIOS) Mot de passe de l'administrateur
  • (BIOS) Mot de passe de l'utilisateur
  • Mot de passe principal du disque dur
  • Mot de passe de l'utilisateur du disque dur

À l'époque (il y a quelques heures), je pensais que le (s) mot (s) de disque dur (HDD) activerait le cryptage du disque au niveau matériel. Plus de recherches me permettent de croire que cette hypothèse était erronée. Peut-être que la machine ne supporte même pas le cryptage du disque au niveau matériel.

J'ai également supposé au moment où le mot de passe se référerait au SSD nouvellement installé de 500 Go.

J'ai ensuite retiré le SSD de 500 Go (sans le remplacer) et j'ai été surpris qu'il y ait encore une invite de mot de passe lors du démarrage. Duh!

Seulement lors de l'insertion de l'ancien SSD de 250 Go, l'invite du mot de passe du BIOS lors du démarrage est terminée.

Ma conclusion est que le mot de passe du disque dur s'applique également au disque dur intégré. Ou peut-être seulement à celui-là?

Malheureusement, je semble avoir mal orthographié (2 fois?) Le "mot de passe de l'utilisateur HDD" lors de sa création, alors j'ai un problème.

Mais je connais le "mot de passe principal du disque dur". Au démarrage, cela est correct, car je peux échapper à l'échappement et entrer le mot de passe principal au lieu du mot de passe de l'utilisateur. Cela me permet de procéder et, par exemple, démarrer à partir d'un stick USB amorçable.

Mais dans le BIOS, le "mot de passe principal HDD" ne m'autorise pas à changer le "mot de passe utilisateur HDD". Triste!

Comme je l'ai dit, si j'insère le vieux SSD de 250 Go, il ne demandera aucun mot de passe de disque dur au niveau matériel et je pourrai démarrer Linux normalement. Je peux ensuite utiliser GParted pour regarder les disques.

Si je commence GParted, j'obtiens d'abord "Error fsyncing / closing / dev / sdb: Erreur d'entrée / sortie" (Réessayer / Ignorer) et "Erreur d'entrée / sortie pendant la lecture / dev / sdb" (Réessayer / Annuler / Ignorer) Les deux apparaissent 2 fois. Après avoir cliqué sur "Ignorer" 4 fois, GParted s'ouvre correctement. Le SSD de 250 Go apparaît comme / dev / sda avec ses différentes partitions. Le SSD embarqué apparaît comme / dev / sdb, tous "non alloués".

Je ne me souviens pas si le SSD embarqué avait des données à ce sujet avant d'avoir activé le mot de passe du disque dur du BIOS. Peut-être que cela montre simplement que "non alloué" parce que les données ne peuvent pas être lues?

Des questions

L'essentiel des questions est "Je suis confus". Il existe de nombreuses hypothèses, mais pas beaucoup de certitude.

Un mot de passe, plusieurs disques durs :

Comment puis-je savoir quel disque dur est affecté par le mot de passe du disque dur du niveau BIOS, si le système contient plusieurs disques durs? Est-ce que cela s'applique toujours à tous les lecteurs actuellement dans le système? Comment les mots de passe existants affectent-ils les nouveaux / autres lecteurs qui sont insérés?

Où sont stockés ces mots de passe du disque dur du BIOS? Sur le lecteur ou sur le BIOS?

Si le mot de passe affecte le SSD embarqué, pourquoi ne me demande-t-on pas le mot de passe lorsque je démarre si le SSD de 250 Go est installé? Et si l'on ne me demande pas le mot de passe du disque dur, mais l'un des lecteurs est protégé par mot de passe, alors, comment puis-je accéder aux fichiers, le cas échéant?

En supposant que le mot de passe affecte tous les lecteurs qui ont été insérés au moment où le mot de passe a été créé – que se passe-t-il si je change le mot de passe alors qu'un seul de ces lecteurs est toujours inséré et que l'autre disque a été supprimé?

Mot de passe utilisateur par mot de passe principal :

Quelle est la différence entre «mot de passe utilisateur HDD» et «mot de passe principal HDD»?
Je supprime le "mot de passe principal du disque dur", puis-je pouvoir contourner le mot de passe de l'utilisateur du disque dur lors du démarrage?

Puis-je réinitialiser le "mot de passe de l'utilisateur HDD" à l'aide du "mot de passe principal HDD"?

On peut répondre à cette question séparée, Réinitialiser le mot de passe de l'utilisateur HDD, si je connais le mot de passe principal du disque dur?

Outils de niveau OS :

Puis-je utiliser des outils de ligne de commandes GParted ou Linux pour savoir quels disques sont protégés par un chiffrement HDD?
Puis-je utiliser l'un de ces outils pour réinitialiser / supprimer le mot de passe du disque dur?
Comment le formatage d'un disque dur affecte-t-il le mot de passe du disque dur?

Cryptage réel du disque :

Comment puis-je savoir si mon BIOS prend en charge le cryptage du disque au niveau du matériel? Je suppose que cela est distinct du "mot de passe du disque dur"?

Informations sur le système

Asus UX32V

"Aptio Setup Utility – Copyright (C) 2011 American Megatrends, Inc"

BIOS Vendor: American Megatrends Version: 206 VBIOS Version: 2137.I14UX3.006 Version CE: B14U120001

Onglets BIOS: Main, Advanced, Boot, Security, Save & Exit

Dans l'onglet «Avancé», il existe une option «Intel AES-NI», qui est actuellement «[Activé]». La description est "Activer / Désactiver les nouvelles instructions standard de cryptage avancé d'Intel (AES-NI).

One Solution collect form web for “Le mot de passe du disque dur dans le BIOS affecte-t-il de façon égale plusieurs disques?”

Voici comment j'ai personnellement résolu cela, sans aucune revendication de connaissance approfondie ou de compréhension.

Désactivez d'abord la protection par mot de passe du verrou / HDD, comme décrit ici, réinitialisez le mot de passe de l'utilisateur HDD si je connais le mot de passe principal du disque dur? , Que j'ai de https://serverfault.com/questions/712849/how-to-unlock-a-ssd-disk-with-hdparm/733784#733784

Cette solution requiert que vous connaissiez au moins le mot de passe principal du lecteur et que vous disposiez d'un système d'exploitation Linux en cours d'exécution avec le disque connecté.

Je pense que la conclusion principale est: les fournisseurs de BIOS font ce qu'ils veulent.

Un mot de passe, plusieurs disques durs

Mes observations indiquent que lorsque j'ai spécifié un mot de passe du disque dur dans le BIOS (avec la version du BIOS que j'utilise), cela affecte tous les disques durs qui étaient connectés au moment: le SSD à bord et le SSD de 2,5 ''.

Un ami m'a dit que son BIOS avait des paramètres distincts par HDD. Ce qui a beaucoup de sens.

Ma conclusion personnelle en est que je n'utiliserais pas le verrou de disque matériel (ou le cryptage du disque matériel), si le BIOS ne peut pas avoir de paramètres distincts par disque.

Qu'est-ce qui se passe alors si je change le mot de passe alors qu'un seul de ces lecteurs est toujours inséré et que l'autre disque a été supprimé?

Par exemple, si un lecteur est verrouillé par mot de passe et l'autre n'est pas. Ou les deux, mais avec un mot de passe différent?

J'imagine que mon BIOS particulier ne fonctionnera pas très bien. C'est pourquoi je n'utiliserai pas cette fonctionnalité.

Mot de passe de l'utilisateur par mot de passe principal

Comme indiqué dans le mot de passe de l'utilisateur Reset HDD, si je connais le mot de passe principal du disque dur? : J'ai pu désactiver le mot de passe de l'utilisateur en utilisant uniquement le mot de passe principal, avec hdparm. Toutes les données sont devenues accessibles.

Cependant, dans mon BIOS, cela ne semble pas possible.

L'article suivant, https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/ , suggère qu'il existe en fait un paramètre, "MASTER PASSWORED CAPABILITY BIT ", Qui définit si le mot de passe principal peut être utilisé pour déverrouiller et pour désactiver la sécurité.

L'article mentionne également que le BIOS est un outil peu fiable.

Outils de niveau OS:

lsblk donne un bon aperçu des disques actuellement dans le système.

hdparm -I /dev/sdx nous indique si un lecteur est verrouillé, gelé et d'autres choses.

hdparm peut être utilisé pour déverrouiller un lecteur et désactiver la sécurité.

Dans https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/ , il est suggéré qu'il faut utiliser hdparm pour tout et ne pas faire confiance au BIOS. Je lis toujours ceci.

Cryptage réel du disque:

("Disque auto-crypteur")

Je ne suis toujours pas sûr de savoir si le mot de passe que j'ai défini dans le BIOS a effectivement permis le cryptage du disque au niveau du matériel.

Bien techniquement, il est toujours activé. Mais le mot de passe sera-t-il utilisé pour décrypter le disque, ou est-ce que cela est séparé? Je pourrais en savoir plus.

  • Le disque SATA disparaît chaque heure, en mode redémarrage dur
  • Emplacements Dell Latitude E5550 M.2 - que puis-je utiliser?
  • SSD en tant que lecteur de système d'exploitation ou lecteur de programme critique
  • Faire en sorte que SSD et HDD fonctionnent ensemble comme un hybride
  • Devrais-je mettre les répertoires d'accueil sur un SSD?
  • Pourquoi les lecteurs flash USB sont-ils beaucoup plus lents que les lecteurs à semi-conducteurs?
  • Pourquoi les transferts de fichiers entre les lecteurs utilisent-ils la RAM?
  • SSD "healthcheck"?
  • Installé un nouveau SSD, Windows démarre encore de l'ancien
  • Utilisez SSD pour OS et HDD comme stockage principal
  • Mon Intel 320 SSD - est-ce que le cryptage est automatique?
  • Soyons le génie de l'ordinateur et du réseau.