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
<Service tag removed>
) and we have about 60 more machines to set BIOS/HDD passwords, any help is much appreciated.
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.
Let's agree that SATA password protection is a standard and can be used on any recent SATA-compliant device, that can even be done with SATA-USB adapters, but we don't have software for that as it's such a niche market that you end up being obligated to use it on your own SATA HBA, ok?
NMVe are much different, they differ from one another just like software modems differed from hardware modems in terms of standardization, manufacturer can do almost anything they feel like. We just don't see any BIOS manufacturer going thru all the steps to make their BIOSes compatible with each and every way NVMe-SSD-manufacturers decide to go for.
jphughan, I'm not picking on you, you were wrong, but hey, we all make mistakes, tech changes all the time as well. Many people think that password-protecting hard drives is a proprietary extension of a hard-drive/bios combination bundled by a manufacturer because used to happen in the past.
Now, in no way a simple ATA command would be able to "disable" the password, that would be ridiculous, if you think I intended to say that I must say that either you read that wrong or I said it wrong, it doesn't matter afterall.
The data wasn't encrypted because for that to happen we would have to see the drive auto-encrypting itself right after setting a password, kinda like a RAID rebuild, but instead the drive kept itself idle after setting the password.
Also, if you use "0000000000000000000000000" as key to an AES encryption key you will not get paintext data coming out as encrypted, that would only happen if you use a XOR encryption, which is next to no encryption at all. But I get what you're suggesting: The drive could use that password to encrypt itself, yes, but either you would have to completely repartition and reformat it after setting the password or you would have to wait the drive to read-then-rewrite-encrypted itself from alfa to omega, right?
Last but not least I have a self-encrypting Crucial M300 SSD on other computer, I work with digital currencies and I know a whole bunch about crypto ;-)
Intel several years ago introduced hardware-level acceleration for AES encryption/decryption operations into their CPUs, so the CPU does not create a bottleneck or cause meaningful CPU utilization even when writing to the latest NVMe drives. That concern is several years outdated. With respect to impossibility of recovering data, if you're already managing passwords manually, encryption is no WORSE in that regard, and once again, with BitLocker especially if you have an AD environment, the Recovery Key is automatically backed up when encryption is enabled (you can have it refuse to enable if it can't talk to a domain controller). That seems a lot safer to me than having to worry about knowing the HDD or admin password for a particular system, but what do I know? And as I said earlier, ATA passwords present their own complications recovering data. What if you want to recover the drive from an external enclosure for convenience or because you don't have a suitable laptop nearby where you can install it internally?
Yes, I suppose setting up encryption is a bit more work if you're already going to muck around in the BIOS to set an admin password anyway, but I would still argue it's worth it.
If you set an HDD password, you're using a SATA-based HDD. Here is Dell's official KB article saying that HDD passwords are not supported on NVMe SSDs: www.dell.com/.../no-bios-option-to-set-a-hard-drive-password-on-m2-ssd
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).
In my defense, I said "I don't believe" there was an ATA command to clear out an HDD password without knowing it. So yes I suppose I can still be wrong, but it's not as if I claimed it as fact. However, I don't see any proof from you to the contrary. You simply claimed that the command exists as part of the industry-wide ATA standard and has for years. That is a highly dubious claim since again, that would mean any drive's password could be bypassed from any system simply by running a small utility that issued that standardized command -- does it really sound plausible to you that the standard would have been implemented that way? I can imagine there being a variety of proprietary tools for different vendors for this purpose that aren't publicly available, but a standard ATA command? I doubt it. But if you have documentation to the contrary, as I'd hope you would when saying something as emphatic as, "You're wrong in many ways," I would be keen to read it. In terms of a logic board swap, even if you COULD do that, that's not the same thing as claiming there's a simple command to disable an HDD password.
But where YOU'RE wrong is in categorically saying that the drive itself "is not really encrypted at all". While not ALL drives that support HDD passwords encrypt their data, it is becoming increasingly common for drives, both spinning and SSDs, to always encrypt their actual data sectors. Initially, the sectors are encrypted but the KEY is stored in the clear, so it works as an unencrypted drive, but if the drive supports "ATA Class 0 encryption" then when an HDD password is specified, that key is encrypted using a derivation of the supplied password. Other encryption standards that take advantage of automatic drive encryption are TCG, OPAL, and Microsoft's eDrive standard.
Before you call out others for being wrong, you might want to be correct yourself:
"You're wrong in many ways, the ATA specification do have a specific command for that since ages ago. The HDD password is kept on disk, but unaccessible for ordinary users, if the password was kept on the HDD controller (the disk-side part of it) a simple HDD controller switcheroo would solve the problem. The HDD is really not encrypted at all, we just want to make it a bit safer, not NSA-proof. (We're considering whether or not to employ truecrypt or bitlocker over the machines or not, 'til then we're using HDD's passwords.)"
It's been years since you could swap out a hard drive logic board and end up with a working drive. Try it with anything made in the last couple of decades -- and you'll wind up with a clicking drive that won't even boot.
By the way, with respect to TrueCrypt vs. BitLocker, be aware that TrueCrypt was abandoned quite a while ago, before they even got around to fixing Windows 8-related issues. Version 7.1a is still solid at least if you're on Windows 7, but you should look at VeraCrypt instead, which rose up to build on what TrueCrypt started. But be aware that just like TrueCrypt, VeraCrypt does not support OS volume encryption on GPT disks, which are used for systems that boot in UEFI mode; BitLocker has no such limitation. Also, as with any third-party software that operates at a low level like this, there's always a risk that updating to a new version of Windows will break something, which in the case of a disk encryption solution is inconvenient at best and catastrophic at worst -- and with Windows 10, Microsoft is committing to new releases every March and September. At least with BitLocker, you can reasonably expect that in-place upgrades to a new version of Windows will run properly even when BitLocker is being used. Additionally, if you have an Active Directory environment, BitLocker allows Recovery Keys to be backed up to the domain controller, which simplifies things quite a bit. With TrueCrypt/VeraCrypt, if you don't know the password and don't have a rescue disc for that system that was made when a password you DO know was in place, you're stuck.
But again, if you're still disinclined from BitLocker because you don't always have the Pro version of Windows that's required to use it and/or would prefer open source software, I would look at VeraCrypt over TrueCrypt.
Glad you got it sorted. And that's interesting, I didn't realize Dell systems cached a copy of the HDD password in some form in order to enable that functionality.
In terms of a little safer rather than NSA-proof, if you're going to have your users typing in passwords anyway, I don't see why you wouldn't want to use proper disk encryption. It's much more security for the same amount of effort, and actually BitLocker is designed to allow you to have encryption without a user-supplied password at all because the TPM stores the key (although you still need to retain the Recovery Key for certain atypical scenarios, and you can optionally still require a user-supplied PIN as well). Additionally, using encryption would simplify data recovery efforts through tools like SATA to USB adapters/enclosures/docks, which wouldn't know how to prompt for an ATA password but which you would be able to decrypt if they were using BitLocker or similar. Finally, as of this writing, Dell does not support HDD passwords on NVMe-based SSDs, just in case you were planning on getting any laptops that will have them.
You're wrong in many ways, the ATA specification do have a specific command for that since ages ago. The HDD password is kept on disk, but unaccessible for ordinary users, if the password was kept on the HDD controller (the disk-side part of it) a simple HDD controller switcheroo would solve the problem. The HDD is really not encrypted at all, we just want to make it a bit safer, not NSA-proof. (We're considering whether or not to employ truecrypt or bitlocker over the machines or not, 'til then we're using HDD's passwords.)
What you don't get it is that the BIOS itself keeps a copy of HDD password on it, but even if you reverse engineer it you won't be able to extract it because that copy of the (HDD) password was scrambled/encrypted by the admin's (BIOS) password, so as long as you know admin's password you can extract the plaintext of the HDD's password as long as the HDD was kept on the same machine that used to set its password all along.
The text on that admin's password page goes: <snip>"Also, the admin password can be used to delete the HDD password."<snip>, it just doesn't tell you how: It's just a matter of typing the admin's password where you should type HDD's password.
Thanks to your post I took the time to try using the admin's password right in place of the HDD's password, even though they're clearly different, and it worked like a charm, who would have thought?