I have an Asus UX32V notebook which has both an onboard SSD (24GB, I think) and a replaceable HDD. Years ago I replaced the HDD with a 250GB SSD (Samsung). Now I am going to replace the 250GB SSD with a 500GB SSD (Crucial MX300).
With the 250GB SSD I had Linux Mint with LUKS software-level encryption.
I decided that with the new 500GB SSD I want to use hardware-level disk encrpytion which is supported by the Crucial MX300.
The BIOS of the UX32V has 4 configurable passwords:
- (BIOS) Administrator Password
- (BIOS) User Password
- HDD Master password
- HDD User Password
At the time (few hours ago), I was under the assumption that the HDD password(s) would activate hardware-level disk encryption. More research leads me to believe that this assumption was wrong. Possibly the machine does not even support hardware-level disk encryption.
I also assumed at the time that the password would refer to the newly installed 500GB SSD.
I then removed the 500GB SSD (without replacing it) and was surprised that there was still a password prompt on startup. Duh!
Only when inserting the older 250GB SSD, the BIOS password prompt on startup is gone.
My conclusion is that the HDD password also applies to the on-board HDD. Or maybe only to that one?
Unfortunately, I seem to have misspelled (2 times?) the "HDD user password" when creating it, so now I kinda have a problem.
But I do know the "HDD master password". On startup this is ok, because I can hit escape and enter the master password instead of the user password. This allows me to proceed and e.g. boot from a bootable usb stick.
But in the BIOS, the "HDD master password" does not authorize me to change the "HDD user password". Sad!
As said, if I insert the older 250GB SSD, it won't ask for any hardware-level HDD password, and I can boot Linux normally. I can then use GParted to look at the disks.
If I start GParted, I first get "Error fsyncing/closing /dev/sdb: Input/output error" (Retry/Ignore) and "Input/output error during read on /dev/sdb" (Retry/Cancel/Ignore), both of these showing up 2 times. After clicking "Ignore" 4 times, GParted opens correctly. The 250GB SSD shows up as /dev/sda with its different partitions. The on-board SSD shows up as /dev/sdb, all "unallocated".
I do not remember if the on-board SSD had any data on it before I enabled the BIOS HDD password. Maybe it just shows as "unallocated" because the data cannot be read?
Questions
The essence of the questions is "I am confused". There are many assumptions, but not much certainty.
One password, multiple HDDs:
How can I know which hard disk is affected by the BIOS-level HDD password, if the system contains multiple hard drives? Does it always apply to all drives currently in the system? How would existing passwords affect new/other drives that are inserted?
Where are these BIOS HDD passwords stored? On the drive or on the BIOS?
If the password affects the on-board SSD, then why am I not asked for the password when I boot, if the 250GB SSD is installed? And if I am not asked for the HDD password, but one of the drives is password-protected, then how can I access the files, if any?
Assuming that the password affects all drives that were inserted at the time the password was created – what then happens if I change the password while only one of these drives is still inserted, and the other drive has been removed?
user password vs master password:
What is the difference between "HDD user password" and "HDD master password"?
I delete the "HDD master password", will I still be able to bypass the HDD user password on startup?
Can I somehow reset the "HDD user password" using the "HDD master password"?
This can be answered in this separate question, Reset HDD user password, if I know the HDD master password?
OS-level tools:
Can I use GParted, or Linux commandline tools, to find out which disks are protected with HDD encryption?
Can I use any of those tools to reset/remove the HDD password?
How will formatting a HDD affect the HDD password?
real disk encryption:
How can I know if my BIOS supports hardware-level disk encryption?
I assume this is separate from the "HDD password"?
System information
Asus UX32V
"Aptio Setup Utility – Copyright (C) 2011 American Megatrends, Inc"
BIOS Vendor: American Megatrends
Version: 206
VBIOS Version: 2137.I14UX3.006
EC Version: B14U120001
BIOS tabs: Main, Advanced, Boot, Security, Save & Exit
In the "Advanced" tab there is an option "Intel AES-NI", which is currently "[Enabled]". The description is "Enable/Disable Intel Advance Encryption Standard New Instructions (AES-NI).
Best Answer
Here is how I personally solved this, without any claim of deep knowledge or understanding.
First disable the lock / HDD password protection, as described here, Reset HDD user password, if I know the HDD master password?, which I have from https://serverfault.com/questions/712849/how-to-unlock-a-ssd-disk-with-hdparm/733784#733784
This solution requires that you know at least the master password for the drive, and that you have a running Linux OS with the disk connected.
I think the main conclusion is: BIOS vendors do what they want.
One password, multiple HDDs
My observations indicate that when I did specify a HDD password in BIOS (with the BIOS version that I am using), it did affects all HDDs that were connected at the time: Both the onboard SSD, and the 2.5'' SSD.
A friend told me that his BIOS has separate settings per HDD. Which makes a lot more sense.
My personal conclusion from this is that I won't use the hardware disk lock (or hardware disk encryption), if the BIOS is unable to have separate settings per disk.
E.g. if one drive is password-locked, and the other is not. Or both are, but with different password?
I imagine that my particular BIOS will simply not handle this very well. This is why I will not use this feature.
User password vs master password
As said in Reset HDD user password, if I know the HDD master password?: I was able to unset the user password using only the master password, with hdparm. All data became accessible.
However, in my BIOS this seems not possible.
The following article, https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/, suggests that there is actually a setting, "MASTER PASSWORED CAPABILITY BIT", which defines whether the master password can be used for unlock and for disabling security.
The article also mentions that BIOS is an unreliable tool.
OS-level tools:
lsblkgives a good overview of disks currently in the system.hdparm -I /dev/sdxtells us whether a drive is locked, frozen, and other things.hdparmcan be used to unlock a drive and disable the security.In https://www.zeitgeist.se/2014/09/07/enabling-ata-security-on-a-self-encrypting-ssd/, it is suggested one should use
hdparmfor everything, and not trust the BIOS. I am still reading up on this.real disk encryption:
("self-encrypting disk")
I am still not sure whether the password I defined in BIOS actually did enable the hardware-level disk encryption.
Well technically it is always enabled. But will the password be used to decrypt the disk, or is this something separate? I might find out more.