Drive decryption passwords / PINs

Following on from my post about BIOS passwords I'm going to talk about drive decryption passwords. Whereas I feel BIOS passwords have become optional (more in my previous post), drive decryption passwords are something I'm much more keen on - I'd say they were a must.

What's drive encryption / decryption?

According to Wikipedia:

In cryptography, encryption is the process of transforming (more specifically, encoding) information in a way that, ideally, only authorized parties can decode.
(https://en.wikipedia.org/wiki/Encryption)

So in this case, drive encryption is the process of making a drive's data unreadable to people unless they have the key to decrypt it. This is useful to ensure that confidential files cannot be accessed, for example if a device is stolen.

Use of drive encryption means that simply moving the storage device (SSD, hard disk drive, etc.) to another computer will prevent access to the files. This is a technique that we often used to recover data from a failed Windows installation - pop the drive out, move it to a Linux machine, and you could access all the files. With the drive encrypted, unless you have access to the decryption key that's not going to work.

Examples of drive encryption

A number of tools, paid and free, are on the market to provide full drive encryption. Linux users can benefit from Linux Unified Key Setup (LUKS) which has been around since 2004. LUKS allows for multiple keys[1], which isn't something I've ever used personally.

Windows professional (and above) editions since Windows 7 have access to BitLocker. When used in a business environment, recovery keys can be stored in Active Directory or Microsoft Entra, or alternatively printed on paper (I know, old school!). Recovery keys are used to provide access to a drive if the Trusted Platform Module (TPM) has an issue or the user forgets the PIN / password. Sadly, BitLocker isn't available to Windows Home edition users (although there does seem to be something available if you use a Microsoft account).

Apple MacOS users have FileVault, and a recovery key is presented to the user during setup or the user can opt to have the recovery key saved to their iCloud account. I really like the fact that FileVault is available to all MacOS users (not just those on a professional tier).

Back in the early 2000s I was using TrueCrypt to protect Windows XP installations, but Truecrypt vanished from the Internet in somewhat suspicious circumstances. VeraCrypt, compatible with Truecrypt [2], is a fork of the code, and is still being updated. In theory, VeraCrypt addressed a lot of the security issues present in TrueCrypt.

For encryption tools that use the computer's TPM, if the storage device is moved to a different computer there's the added advantage that the keys won't be in the TPM (because a different TPM is in use), so recovery keys will be needed.

Why have a decryption PIN / password?

Spoiler - code is not secure. Attacks against operating systems (OS) are common, and if the OS has booted then it can be attacked. By requiring a decryption PIN / password at startup the OS is prevented from booting unless the user enters the right PIN / password. That means that attacks against the OS aren't an option, because it's not running.

I'll admit, making a user type an additional PIN or password adds a step and could be seen as a barrier. Nonetheless, I think the benefits here outweigh the negative impact. Sometimes you only need a relatively short decryption PIN too. My advice would be to allow the user to set their own password / PIN and to not make it massively complex. You don't want them to simply write the decryption password on a sticky note and tape it to the laptop wrist rest!!

Ok, I'll attack the decryption PIN / password then...

While attacking the PIN / password is a valid option, there may be protections in place to help prevent this, dependent on the system used. I'm most familiar with Microsoft's BitLocker, when used in combination with a TPM, so I'll explain how that works.

If the decryption PIN / password is entered incorrectly too many times, BitLocker will report that the TPM is locked and that the BitLocker recovery key is needed. A quick search suggested it takes 32 attempts before the TPM locks, and then the "failure" count drops by one every two hours - i.e. if I type in 32 incorrect guesses I'll have to wait two hours before I can try guess number 33. This massively increases the amount of time taken to brute force the decryption PIN / password.

As I mentioned already, you could take the drive out and put it in another computer but then you'd need the BitLocker recovery key instead. Those are much longer, so would take even longer to brute force. An example BitLocker recovery key:

688842-434281-668218-147147-867307-288678-409047-600083

Brute forcing the recovery key requires guessing a 48 digit code, which is way beyond the scope of this post (and I'm not convinced I could accurately describe that).

Should you encrypt desktop computers?

For years the wisdom seemed to only be to encrypt portable devices - laptops, phones, and tablets - because these were more at risk of theft. Given the size of computers is reducing (there's some truly small devices now) I'd say that argument was now redundant. Plus, if you've got the option to encrypt the device why wouldn't you? I think Sophos said it very well when they produced these t-shirts a while back:

Conclusion

Given to small amount of extra hassle (say 10 seconds, at most, per boot) caused by typing in an extra password, possibly a relatively short one, I'd say the extra protection provided more than justified the nuisance. Obviously your risk model will be very relevant, but if you weren't worried about your data you wouldn't have encrypted it in the first place, would you?!

Banner image: BitLocker unlock screen, (c) Microsoft, image taken from Microsoft Learn.

[1] Including, if you're feeling brave or work with particularly sensitive data, a "nuke" key through an extension called LUKS Nuke. Entering the password for the nuke key at the usual prompt will destroy the keys, preventing brute force attacks against the drive. With the keys gone the data remains unavailable, unless you have a backup of the keys that you can restore. I couldn't quickly find the link, so maybe that project is discontinued, but it was an interesting idea some years back.

[2] Since version 1.26.7, VeraCrypt no longer supports TrueCrypt encrypted drives or file containers. The project offers VeraCrypt version 1.25.9 specifically to allow users to access their historical TrueCrypt data and copy it over to VeraCrypt - https://www.veracrypt.fr/en/Downloads_1.25.9.html .