Protecting Hard Disks and SSDs with a Password

One thing that still bugs me a bit about my Linux installation is that the system partition is not encrypted. In practice that should mostly be o.k. because I mapped ‘/tmp’ to memory and ‘/home’ is mounted to an encrypted partition during boot. But still, it bugs me a bit. And notebooks on the move do get stolen or are lost by accident. So when I recently thought a bit about the password protection offered by hard drives, I investigated a bit to see if this would help me out.

The Disk Password is Stored on the Disk

If you go into the BIOS of a PC that was built in the past 10 years, it is likely that you will find a number of password options. There is a BIOS password, for example, that restricts access to the BIOS setup. And then there are user and master passwords for the disk drive. These can be set in the BIOS but are actually stored inside the hard disk or SSD. Whenever the computer is switched on, this password has to be entered before the BIOS can be accessed or the computer is started. There is a user and master disk password serving different purposes and it’s good to set them both to overwrite a potential factory default for the master password.

Using the Disk in Another PC Works – Or it Doesn’t

As the disk password is stored in the drive itself, it persists even when the drive is moved to another PC/notebook and used as a startup device there. To make life a bit difficult at this point, different manufacturers have devised different ways to encode the password before it is written to the drive. Thus, moving the drive to a PC of a different manufacturer will likely render it unusable there. Lenovo, for example uses a number of hash functions and information retrieved from the disk to generate a 32 byte password. Dell uses a different approach from what I have seen on the web. In other words, it’s unlikely that unlocking a drive for which the password was set on a Lenovo PC will work on a Dell machine. However, I had no problem moving a password protected drive from my Lenovo X230 to a Lenovo X250.

How To Access A Password Protected Drive Over USB

Locking a drive with a password also means that accessing it over USB is not quite straight forward anymore. To unlock the drive, the USB to SATA adapter has to support the “USB attached SCSI protocol” (UAS), which many older adapters, even if they support USB-3, do not yet support. If supported, it’s possible to unlock the drive with ‘hdparm’. In case of Lenovo, the password has been converted to a 32 byte hash value, so using the original password with hdparm does not work. Fortunately, Jethro Beekman has reversed engineered a Lenovo BIOS a couple of years ago and found out how the conversion is done. He then wrote a short ruby script that does the same operations. So with a USB to SATA adapter that supports UAS, one can unlock the drive and then use it. A few things have changed in bash in the meantime so I needed to modify his procedure a bit to get it working for my password, which contained a NULL byte in the sequence. This seems to upset bash a bit these days. More about that in a follow up post.

Password Protection And Encryption

One important thing to understand is that password protection of the drive is not equivalent to drive encryption! In the case of spinning hard drives and also many SSDs, password protection just denies access to the drive while the data is still stored in the clear on the drive itself. Therefore, a reasonably strong password is likely to thwart off the ordinary notebook thief from accessing your data but it is probably not a good countermeasure against other attacks. In other words, that’s good enough for my purposes as I ‘only’ need to protect the system partition this way. All my user data is on a LUKS encrypted data partition and is thus well protected even without a disk password.

Some SSD manufacturers couple the disk password to their full drive encryption capability. Samsung, for example, seems to support that since their 840 (EVO?) model. Unfortunately, their encryption algorithm and the software are not publicly available so there is no independent way to verify how good that encryption really is. So as far as I’m concerned, I’m not relying on this layer of protection for anything than denying access to the ‘ordinary thief’.

So much for the general details. In a follow up post I will have a look at the practical details of how to unlock a password protected drive when connected to a PC over a USB to SATA adapter so I can access the drive without booting from it and update the partitions every now and then.