Unsolved
This post is more than 5 years old
8 Posts
1
135336
Erasing HDD password via admin/bios password
Hi there,
I have a machine that was protected with a HDD password and, as any IT manager's nightmare, right after setting it the following first trial have failed to let us use the hard drive.
We also set the bios admin password (the one which is required to make changes in bios) and this one is working accordingly.
On the HDD password bios page you can read that you can use the admin/master password to remove the HDD password (supposedly without losing data), but I wasn't able to find how could that be done, can someone tell me how?
Best outcome: Use the admin password to disable HDD password.
Unacceptable but still possible solution: Erase the whole hard disk altogether with the password.
The system is a Dell Inspiron 7560 (S/Tag
) and we have about 60 more machines to set BIOS/HDD passwords, any help is much appreciated.
Lint256
8 Posts
0
December 1st, 2017 16:00
There are some reasons, cpu usage being one, impossibility of recovering any data if something bad happens (that is a BIG factor), time and effort required to go into each user's laptop and encrypting it are other factors. Placing a simple password on the hard drive gives some advantage, albeit undeniably flawed, at almost no cost.sword -- I'm already doing that right now, all bios/hdd/service tags are being kept on an encrypted file.
Also Dell also supports HDD password on (most likely SATA) SSDs, I'm typing right now on a machine that has both a HDD and a SSD which are password protected, and what was really lovely is that if you use the same password for both drives you don't need to type twice at boot! :D
I'm not sure if this laptop I'm using (not the one we were talking about, that other one only had a single HDD) is SATA or NVMe, I can assure you I can set a password to access it, but I'm not sure if is it ATA or NVMe, and that really doesn't bother me, all I need to know is whether the drive can lock itself with a password or not, and if it does how that data is kept (encrypted/plaintext).
jphughan
4 Operator
4 Operator
•
14K Posts
0
December 1st, 2017 16:00
You tell me I was wrong, then you say I wasn't wrong and that I simply misunderstood your claim? Ok....
With respect to self-encrypting drives, perhaps you're not understanding what I said. The drive does not use a bunch of zeroes as the AES key initially. Right out of the box, it generates a proper AES key and immediately uses that to encrypt all of its sectors, before the user has enabled encryption -- but the key that protects THAT key is stored in the clear -- consequently, the drive operates as if it's unencrypted, since the key is plainly visible. But when encryption is enabled either via HDD password (Class 0) or TCG/OPAL, or eDrive, the AES key is encrypted with a derivative of the password that the user supplies. Consequently, the drive does NOT have to immediately go back and encrypt everything at that point or repartition itself. It immediately becomes protected because all it had to do was encrypt the key. This design incidentally is how the Secure Erase feature for self-encrypting drives (and even some smartphones these days) can be performed in seconds. Rather than needing to wipe every individual sector, the drive/phone simply destroys the key, which renders all of the data inaccessible. This is all very well documented as part of the various self-encrypting drive standards, so you may want to look into it.
And no, XOR is not "next to no encryption at all". It's certainly doesn't have the protections of more exotic designs like CBC, but XOR remains the foundation of stream ciphers that are still popular and industry-standard today because stream ciphers still have their advantages over block ciphers in certain use cases. As long as the algorithm generating the stream with which the plaintext is XORed creates enough entropy, just XORing turns out to be a surprisingly robust protection mechanism. Granted, it's highly counterintuitive because it seems almost impossibly simple -- "You're just flipping some bits!!" True, but you have no idea WHICH bits were flipped, and absent threats like an algorithm that generated repetitive or predictable patterns, an attacker's knowledge of portions of the plaintext, etc, just knowing that bits were flipped in a completely unpredictable pattern doesn't make recovering the plaintext any easier. Again, XOR by itself certainly is not the best encryption there is today, but calling it practically no encryption at all is a gross underestimation.