On the security of the Linux disk encryption LUKS

2023-05-03

In the past few days, there have been uncertainties and concerns about the LUKS (“Linux Unified Key Setup”) disk encryption, which is widely used on Linux. We publish our assessment of this here.

Table of contents

• Background
• Discussion on Reddit
• Key derivation functions
• Attacks on encrypted data (media)
• Recommendations
  • Upgrading encrypted drives
  • Key derivation functions of Linux distributions
  • Reinstall instead of upgrade
  • Precautionary measures against access to unlocked devices
  • Precautionary measures against attacks on passwords and passphrases
• Conclusion
• More discussions and texts

Background

On April 17, 2023 Matthew “mjg59” Garrett published an appeal to change the key derivation function (KDF) of LUKS-encrypted volumes: PSA: upgrade your LUKS key derivation function. He refers to the article “Une lettre d’Ivan, enfermé à la prison de Villepinte : perquisitions et disques durs déchiffrés” (crosspost from paris-luttes.info).

According to the source, two encrypted computers belonging to an accused person had been decrypted – a Windows computer encrypted with BitLocker and a LUKS-encrypted computer running Ubuntu 18. (It is not clear from the text whether it is Ubuntu 18.04 or 18.10, but this is not relevant).

The Windows computer had been booted from a bootable USB stick, then a copy of the (encrypted) hard disk had been made with the software “AccessData FTK imager 3.3.05” (in the meantime “FTK® Imager by Exterro”, which bought AccessData in 2020). Making a copy in order to work with it is normal in IT forensics and says nothing about the security of encryption methods. We do not want to deal with BitLocker any further at this point. However, we would like to refer to pitfalls such as vulnerabilities in implementations of the Trusted Platform Module (TPM), which enable TPM-Sniffing-Angriffe, for example, or headlines such as Windows 10: Microsoft kriegt Bitlocker-Nachschlüssel frei Cloud (2015) (“Microsoft gets Bitlocker recovery key via the cloud”). A good overview of publicly known attacks on BitLocker can be found here.

The second computer, with Ubuntu 18, had been encrypted with LUKS1 using a password of more than twenty characters, consisting of letters, numbers and special characters. Garrett believes it is possible that there is no “opsec failure” and that the reason for the successful access to the Ubuntu disk is therefore the disk encryption LUKS1 and its key derivation function PBKDF2. We will go into this further below.

There could also be other causes for the decryption. For example, it is not clear from the text in which state the Ubuntu computer was seized. A seizure in a powered-on state with the screen locked or in suspend-to-RAM (“standby”) allows the keys to be read from memory using a cold boot attack. Since the decryption probably came as a surprise to the affected person, we would at least rule out that the password was handwritten somewhere – one of many possibilities that we will name later.

Discussion on Reddit

A brief discussion arised on Reddit between LUKS developer Clemens Fruhwirth and Matthew “mjg59” Garrett (in the Web Archive: Fruhwirth, Garrett, Fruhwirth).

Clemens Fruhwirth does not suspect LUKS1 as the cause, but other reasons. Even with LUKS1 with PBKDF2 and a password consisting of 13 random upper and lower case letters and digits, an attack with the current computing power of the entire Bitcoin network (assuming that it remains at this level and there is no further technical progress) would take 77 years. Assuming that the available computing power doubles every 24 months, it would be 10-12 years. Garrett argues that passwords are rarely truly random and thus are weaker than theoretically possible. He also notes that the computing power of graphics cards and of customized hardware (ASICs) is increasing faster than predicted.

It should be noted that Fruhwirth assumes a PBKDF2 difficulty level of 3,000,000 iterations in his calculation example. For drives that were encrypted many years ago, the difficulty level may well be lower by a factor of 20 to 30. More on this in the next section.

Key derivation function

Symmetric encryption methods are used to encrypt data media, for example AES (“Advanced Encryption Standard”). Symmetric encryption methods use the same cryptographic key for encryption and decryption. This key must have a certain length, for example 256 bits.

In practice, a passphrase is not used directly as a cryptographic key. Instead, a key derivation function is chosen that generates a cryptographic key from the passphrase. This has several advantages:

• The passphrase does not have to be 256 bits long, but can have a different length.
• The passphrase can be changed without having to re-encrypt the whole disk.
• We can specify the amount of time needed to generate the cryptographic key.

The last point is relevant here. To try a passphrase, the key derivation function must be executed. Accordingly, the more complex the function used, the more time-consuming it is to try a large number of possible passphrases. Modern graphics cards can execute thousands of computing operations in parallel. For this reason, key derivation functions such as Argon2id are now preferred, which are resistant to attacks with special hardware (graphics cards or ASICs) in that they not only require a lot of computing time, but also a lot of memory, and cannot be executed well in parallel.

When creating an encrypted volume, the difficulty level is usually chosen so that we have to wait for about one second. A volume that was encrypted many years ago on slow hardware will therefore use an older key derivation function and a lower difficulty level than a volume we encrypt today on a modern computer. Therefore, it may be wise to occasionally increase the difficulty level of the function or switch to a more modern function. This is exactly what Matthew Garrett recommends in his appeal.

The older LUKS1 only supports the key derivation function PBKDF2, which has an adjustable computing time but requires almost no RAM. PBKDF2 is simply an adjustable number of iterations of the SHA256 or SHA512 hash algorithm. The newer LUKS2 uses Argon2 by default, with adjustable computation time and memory requirements. Both Garrett and, for example, the OWASP and KeePassXC recommend the Argon2id variant. The forensics company elcomsoft also notes that LUKS2 makes brute-force attacks with graphics cards considerably more difficult.

Even with LUKS1 and its key derivation function PBKDF2, there is currently no need to worry if the passphrase used is sufficiently complex.

Attacks on encrypted data (media)

An impression of the methods and ways to obtain or circumvent passwords and passphrases is provided, for example, in the chapter “Analyzing Filesystem Encryption” of the book “Practical Linux Forensics: A Guide for Digital Investigators”:

Decrypting protected data requires a password/passphrase or a copy of the cryptographic key (a string or key file). The forensic challenge is to find the decryption key. Some known methods for password/key recovery include:

• Bruteforce with dictionarybased attacks to find simple passwords
• Bruteforce with GPU clusters for fast exhaustive password search
• Cryptanalysis (mathematical weakness, reduce keyspace)
• Finding passwords saved, written, or transferred previously
• Password reuse across multiple accounts or devices
• Legal requirement to produce passwords in court
• Cooperative system owner or accomplice with the password
• Key backup/escrow in enterprise environments
• Device exploit, vulnerability, or backdoor
• Keyloggers or keyboard visibility (video cameras or telescope)
• Rainbow tables: Precomputed table of cryptographic hashes
• Extract keys from memory: PCIbus DMA attacks, hibernation
• Maninthemiddle attacks on network traffic
• Social engineering
• Forced biometrics
• Torture, blackmail, or coercion

What do others say on this topic? Mikko Hyppönen wrote in “If It’s Smart, It’s Vulnerable”, in the chapter “Cracking Passwords”:

Authorities have pretty impressive decryption systems for this purpose. An office building in The Hague, for example, has decryption hardware the size of a supercomputer, which needs its own power station. Hardware like this allows millions of password options to be tested per second. Nevertheless, a single encrypted file can take months to open.

Automated decryption systems use a clever tactic for speeding up this operation. If a password-protected file is found on a suspect’s hard drive, all files on the drive are indexed, and all individual words are collected from each file for testing as passwords. If none work, all discovered words are tested in reverse, and if this does not work, the drive is scanned for any unused areas and deleted files, and words inside them are tried. On surprisingly many occasions, this will decrypt the files.

However, another method offers even better chances of success:

The best tactic is to distract a criminal, preventing them from destroying or locking their devices upon arrest. In an arrest coordinated by EUROPOL, the suspect was sitting in a café with a laptop when a female undercover officer sat at the same table, spilling her coffee a few moments later. The suspect stood up, at which point a male officer waiting behind stepped forward and whisked away the unlocked computer for forensic analysis.

The laptop of Ross Ulbricht, the operator of the darknet platform “Silk Road,” was also seized in an unlocked state. In another case, the operator of the neo-Nazi forum “Thiazi” was persuaded by a phone call to boot up his computer and unlock it shortly before he was raided.

Despite all that, the conclusion of the OWASP Password Storage Cheat Sheets (which is aimed at online services, but can be applied to the encryption of stored data) holds true:

Strong passwords stored with modern hashing algorithms and using hashing best practices should be effectively impossible for an attacker to crack.

Recommendations

For encrypted disks in your possession, we share mjg59’s recommendation to upgrade to LUKS2 and change the key derivation function to Argon2id:

What makes this worse is that distributions generally don’t update this (the key derivation function) in any way. If you installed your system and it gave you pbkdf2 as your KDF, you’re probably still using pbkdf2 even if you’ve upgraded to a system that would use argon2id on a fresh install. Thankfully, this can all be fixed-up in place. But note that if anything goes wrong here you could lose access to all your encrypted data, so before doing anything make sure it’s all backed up (and figure out how to keep said backup secure so you don’t just have your data seized that way).

For data media that are out of your reach, we’ve put together an overview of common Linux distributions and the key derivation features they use.

Upgrading encrypted drives

mjg59 wrote:

First, make sure you’re running as up-to-date a version of your distribution as possible. Having tools that support the LUKS2 format doesn’t mean that your distribution has all of that integrated, and old distribution versions may allow you to update your LUKS setup without actually supporting booting from it. Also, if you’re using an encrypted /boot, stop now - very recent versions of grub2 support LUKS2, but they don’t support argon2id, and this will render your system unbootable.

Next, figure out which device under /dev corresponds to your encrypted partition. Run

lsblk

and look for entries that have a type of “crypt”. The device above that in the tree is the actual encrypted device. Record that name, and run

sudo cryptsetup luksHeaderBackup /dev/whatever --header-backup-file /tmp/luksheader

and copy that to a USB stick or something. If something goes wrong here you’ll be able to boot a live image and run

sudo cryptsetup luksHeaderRestore /dev/whatever --header-backup-file luksheader

to restore it.

(Edit to add: Once everything is working, delete this backup! It contains the old weak key, and someone with it can potentially use that to brute force your disk encryption key using the old KDF even if you’ve updated the on-disk KDF.)

Next, run

sudo cryptsetup luksDump /dev/whatever

and look for the Version: line. If it’s version 1, you need to update the header to LUKS2. Run

sudo cryptsetup convert /dev/whatever --type luks2

and follow the prompts. Make sure your system still boots, and if not go back and restore the backup of your header. Assuming everything is ok at this point, run

sudo cryptsetup luksDump /dev/whatever

again and look for the PBKDF: line in each keyslot (pay attention only to the keyslots, ignore any references to pbkdf2 that come after the Digests: line). If the PBKDF is either “pbkdf2” or “argon2i” you should convert to argon2id. Run the following:

sudo cryptsetup luksConvertKey /dev/whatever --pbkdf argon2id

and follow the prompts. If you have multiple passwords associated with your drive you’ll have multiple keyslots, and you’ll need to repeat this for each password.

Upgrading persistent storage in Tails requires administrator privileges, which you obtain by assigning an administration password at the login screen. Also, when upgrading from LUKS1 to LUKS2, persistent storage must not be mounted.

Key derivation functions of Linux distributions

The cryptsetup system tool introduced support for the LUKS2 format in version 2.0.0 (released 2017-12-10), using Argon2i with 128 MB memory and 800 ms computation time (on the computer used) by default. In version 2.0.1 (released 2018-01-21) the memory requirement was increased to 1 GiB. However, the LUKS2 format itself has only been default since version 2.1.0 (2019-02-08). Since version 2.4.0 (released 2021-08-18) cryptsetup uses Argon2id by default. However, Linux distributions often do not include the latest software versions and do not necessarily use the default options.

The relevant factor is the time of encryption, or the version of the operating system used for encryption. For example, if you encrypted a disk as part of the installation of Ubuntu 18.04 and later upgraded your operating system to Ubuntu 22.04, it will probably be encrypted with the older LUKS1. The following table shows which encryption methods are used by the installation programs or installation guides of the Linux distributions we analysed.

Reinstall instead of upgrade

As Garrett also points out, it is possible that Linux installations will not support an upgrade to LUKS2 or switching to Argon2id, or will not be able to boot afterwards. To eliminate this risk, you can also backup your data on encrypted media and then reinstall your OS. (See the table above to see if this is worth doing. If you are using Tails, wait until the next release). If you upgrade encrypted disks which do not contain an operating system, you should still make a backup before upgrading them. You can also use this occasion to delete data that is no longer needed – because data that does not exist cannot be decrypted.

For those who do not want to rely on one method alone, we recommend: Encrypt your drive with LUKS2 first and store particularly vulnerable content in additional VeraCrypt containers with a different secure password and cipher. This way, your data is still protected even if vulnerabilities are discovered in one method. However, VeraCrypt currently also uses PBKDF2 as its key derivation function.

Precautionary measures against access to unlocked devices

By encrypting content that requires special protection separately and decrypting it only when necessary, such two-level encryption can also help against access to unlocked devices.

It can also be useful to switch off a computer, for example, by using the toggle switch of a power strip or by pulling the power plug and thus interrupting the power supply. In the case of laptops, the battery should be removed beforehand. Another way to quickly turn off or even wipe a computer is offered by devices such as BusKill.

Precautionary measures against attacks on passwords and passphrases

There are a number of countermeasures against the above-mentioned attacks on encrypted data (media). The algorithms and software used should be as up-to-date as possible (e.g. LUKS2 with Argon2id). In addition, there are mistakes that can be avoided, especially in the choice and handling of passwords and passphrases.

Choose a password or passphrase with high [entropy](https://en.wikipedia.org/wiki/Entropy_(information_theory) – in other words: so that enough possible passwords or passphrases come into question.

Methods such as Diceware are ideal for this. The dice provide the necessary randomness, while the words are easy to remember using mnemonic devices. In Creating Strong Passwords Using Dice, the Electronic Frontier Foundation (EFF) recommends using at least six randomly selected words from a list of 7776 words. The EFF provides an English word list for this purpose. We have compiled a German-language diceware word list “de-7776”, which will be updated again soon.

It is best to perform the procedure offline with dice. An example (with the EFF wordlist) for six words with five dice each:

1. 36433 maggot
2. 64355 unpiloted
3. 36541 manhole
4. 63656 unfunded
5. 23654 doorframe
6. 34466 implicate

The passphrase generated in the example is therefore: “maggot unpiloted manhole unfunded doorframe implicate”.

The word lists are 7776 words long because there are 6^5 = 7776 different possible outcomes when rolling five six-sided dice. Each word has an entropy of log2(7776) ≈ 13 bits. Consequently, a passphrase of six words rolled is 5 × 13 ≈ 78 bits strong. There are 2^78 ≈ 3 × 10^23 different possible passphrases from six words. A password consisting of thirteen randomly selected uppercase and lowercase letters and digits also has an entropy of 78 bits: one of 62 possible characters yields log2(62) ≈ 6 bits of entropy, thus thirteen random characters yield 78 bits.

Since the PBKDF2 key derivation function and the Bitcoin network use the same or a similar hash algorithm, their performances can be compared well. The Bitcoin network, which was used as a reference in the discussion on Reddit, currently calculates 3 × 10^20 hashes per second. For a PBKDF2 key derivation with 100,000 iterations, the network could thus try 3 × 10^15 passwords or passphrases per second. To try all possible passphrases from six words, it would take (3 × 10^23) / (3 × 10^15) = 10^8 seconds, or about three years at constant computing power. On average, half of all possibilities must be tried, which would take about one and a half years. With a passphrase of five words instead of six, the average would be just under two hours. However, we assume that most attackers do not have such high computing power – certainly not for a long period of time. With Argon2 instead of PBKDF, both attacks should be several orders of magnitude more difficult.

Keep in mind that passwords like IgtBa11peN!, which are composed of the first letters of a sentence (“I go to Bed at 11pm every Night!”) for example, are not random.

The online service 1Password has brought examples of passwords and the effort required to crack them in 2021: How strong should your account password be? Here’s what we learned. However, the assumed costs may already be outdated. Further texts on how to choose passwords can be found at The Diceware Passphrase Home Page. The FAQ from cryptsetup also offers information and recommendations.

For the handling of passwords or passphrases we recommend:

• Do not use a password or passphrase and variations of it for anything else, but only for one device and use case.
• Do not write down a password or passphrase and variations of it anywhere.
• Do not share a password or passphrase and variations of it with anyone.
• Make sure that no one can secretly observe or film you when you enter it.
• Do not use biometric information.

You may also encounter “plausible deniability” methods in this context to disguise the presence of encrypted data. VeraCrypt offers the Hidden Volume and Hidden Operating System functions for this purpose. Concerns and disadvantages on this are mentioned here, among other places:

• Bruce Schneier: Defeating Encrypted and Deniable File Systems: TrueCrypt v5.1a and the Case of the Tattling OS and Applications
• Cryptsetup: 5.18 What about Plausible Deniability?
• Kedziora, Chow, Susilo: Defeating Plausible Deniability of VeraCrypt Hidden Operating Systems (2017)

Conclusion

In our estimation, based on the available information, PBKDF2 and LUKS1 cannot be held exclusively responsible for decryption. It is important to use a strong password or passphrase and to follow the described recommendations when using them. Using up-to-date software and algorithms increases security and reduces possible attack surfaces.

Upgrading the key derivation function is not a one-time task. You should check every few years whether the function you are using is still considered secure, and adjust the level of difficulty. This applies not only to LUKS, but to all password-based encryption tools such as VeraCrypt or KeePassXC.

More discussions and texts

• Systemli: Is Linux hard disk encryption hacked?
• Discussion on Hacker News
• Discussion on lobste.rs
• Discussion on lwn.net