Linux hard drive encryption hacked?

Ivan, an anarchist who has been in custody in France for some time, informed in his letter that the French police managed to gain access to the contents of his laptop (1). The laptop in question had an encrypted Ubuntu Linux operating system installed. Instead, they were unable to gain access to another device with Windows installed, but which was encrypted with Bitlocker. Ivan explained in his letter that he had used a 20-digit code for the (Ubuntu) system, consisting of letters, numbers and special characters.

No, Linux disk encryption is neither "broken" nor "insecure". Technological advances, as well as algorithms, have evolved, so data on cryptography must be re-checked and, if necessary, updated.

Since then, discussions have arisen online and in our circles about how this happened, whether an unupgraded encryption algorithm in Ivan's installed version of Ubuntu was to blame, and what this means for the security of other Linux systems. We have also heard claims that the encryption of the Tails operating system - which is another Linux system - was not secure, due to non-updated algorithms. The issue of device encryption is not easily understood by many, so we would like to lay some groundwork in this discussion with this post.

All Linux operating systems use the method Linux Unified Key Setup -or for short "LUKS"– to encrypt hard drives. The basis of the hypothesis that an unupgraded algorithm is responsible for Ivan's case is the fact that the version Ubuntu 18.04 (released in April 2018, as the abbreviation states) still uses the relatively outdated specifications "LUKS1" for hard disk encryption, while newer versions of Linux use specifications "LUKS2" for this purpose (2). To understand how these are related, it is necessary to get an idea of ​​the cryptographic method "LUKS", and to understand what role the so-called plays in this key generation function. Unfortunately, this issue is somewhat technical in nature, however we will try to make it as clear as possible.

The encryption system Linux Unified Key Setup (LUKS)


A hard drive that is encrypted using the method "LUKS", is a two-part field, with a unencrypted header, and one encrypted body. The body contains the actual encrypted data, while the header should be understood as an instruction manual: What encryption algorithm is used for the body, what size should the body be, where on the hard drive is the body placed, what is the identity of the partitioned device, etc. – It looks something like this:

LUKS header information

Version: 2

UUID: d077227a-eb02-4349-ab5b-fd9494ade3a6

Data segments:

0: crypt

offset: 16764544 [bytes]

length: (whole device)

cipher: aes-xts-plain64

sector: 512 [bytes] …

Something important to us: The header also contains the information about which key generation function is to be used during the encryption or decryption process. Η key derivation function is a cryptographic conversion of the password to the key with which the body was encrypted, and with which it can be decrypted again. Contrary to what one might think, the password itself is not the key with which the body was encrypted, but only the actual key is generated from it. We will explain in a moment why this intermediate step is necessary. First, it's important to just know that there are many different algorithms for key generation, and that the information stored in the header is necessary for key generation.

Let's look at an example, with code visualization “dPhdWnv1.3k4d4,szv!”:

Now the question arises, so why the intermediate step is needed, instead of just encrypting/decrypting the body of the hard drive directly with the password. First of all, we need to consider the attack scenario that encryption is supposed to protect against: No one would try to break the actual algorithm – in this case: AES-XTS-PLAIN64: This, from research, is considered safe. Usually, people try to guess the password by just trying all the possible combinations of characters. This method is called "brute force". Each attempt costs computing power, memory and time, so one will usually use a very powerful computer or a cluster of many computers. There is also dedicated software that works with lists of known passwords, or even personal data about the owner (languages, interests, passwords used for other services) to highlight more likely combinations.

This is where the key generation function: The idea is to extend decryption with the correct password by adding the intermediate step of key generation, which takes so few milliseconds that it is not even noticeable in everyday computer use, but greatly increases the effort for mass password guessing . The key generation function mainly protects short passwords and those consisting of a smaller set of possible characters: For a password consisting of only 6 digits, for example, the multitude of all possible combinations is calculated much faster than for an alphanumeric one 20 character password.

There are high demands on the key generation function: On the one hand, they must be able to cope with huge clusters of computers that have unimaginable computing power at their disposal, and at the same time, encryption and decryption on everyday portable and stationary computers should not require so much time that they become impractical. The solution to this problem is – to put it briefly – the development of mathematical algorithms designed in such a way that even as computing power multiplies, the time required to generate a key remains relatively the same.

The vulnerability of Ubuntu 18.04, Tails and other operating systems

Now that the concept of the key generation function is explained, we return to Ivan's laptop: According to his letter, it had Ubuntu version 18.04 installed on it. This version of Ubuntu still uses the outdated LUKS1 encryption model, which in turn uses an outdated key generation function (PBKDF2). This is known to be of little use against specialized machinery, and is therefore no longer considered safe. Hence the hypothesis that it was the obsolete key generation function that allowed access to Ivan's laptop. Other versions are also affected by this potential vulnerability if their first installation was a long time ago: Indeed, the algorithm is usually not improved on an existing installation when a full software upgrade is performed (eg from Ubuntu 18.04 to Ubuntu 22.04 ) (3). It has also been discussed that while the developer community behind the Tails operating system has for several years on its future work list the switch to the more secure LUKS2 encryption, however, has not yet implemented it. This again seems to have led others to claim that encryption on a Tails stick is insecure (4).

What should we conclude from this? Basically, it is worrying that many old Linux installations use an outdated algorithm for hard disk encryption. Users with older installations must now decide if they are tech-savvy enough to upgrade their encryption themselves – there's a guide to this on our wiki –, reinstall their OS, or accept using an outdated algorithm. However, whether this particular vulnerability played a role in Ivan's case is merely a hypothesis, not a fact. The possibility that he was being watched or videotaped entering his password, that he has reused the same password in different places, that the password was simply insecure, and even that traces of usage on the keyboard could be clue to the password, all of the above are possible explanations for accessing his data. Considering the vague information, statements like “Tails encryption is broken” they seem risky and dubious.

It is difficult to assess how serious an outdated algorithm actually is: A better one key generation function which makes the process more difficult brutal forcing, undoubtedly contributes greatly to the security levels of device encryption. On the contrary, however, this does not mean that all devices using an outdated key generation algorithm are necessarily fundamentally insecure. First and foremost, the security of LUKS encryption depends on the security of the password, and while this is improved by a good password, it is not made worse by an outdated key generation algorithm. A good password, i.e. a truly randomly generated password of sufficient length and consisting of a sufficiently large pool of letters, numbers and special characters, takes an unimaginable amount of time to crack, even with an outdated key generation function, even with unimaginable amounts resources. However, we cannot and should not rely on estimates of what kind of resources are available to a potential attacker. However, we consider it at least unlikely that such passwords – even with insufficient key generation – can be brute-forced without further delay.

Secure passwords

A little note about secure codes: When we talk about a random code, that means it's machine generated. A password created by you will never be as secure as a random password: Even the password dPhdWnv1;3k4d4;szv! it looks safe at first glance, with uppercase and lowercase letters, numbers and special characters. However, it's just short for the not-so-mysterious German phrase “Die Philosophen haben die Welt nur verschieden interpretiert? es kommt aber darauf an, sie zu veränder.”, with some vowels replaced by numbers and some special characters added. Such and similar tricks are extremely common, but can be easily predicted after good research and intuition, and do not form the basis of a truly secure code.

The Tails community recommends in their guidelines that we use "Diceware" codes (*randomly generated from a sequence of dice rolls).

(1) in the upcoming years, while / Onion link: http://7sk2kov2xwx6cbc32phynrifegg6pklmzs7luwcggtzrnlsolxxuyfyd.onion/en/2023/04/30/is-linux-hard-disk-encryption-hacked/index.html#fnref:1

(2) / Onion link: http://7sk2kov2xwx6cbc32phynrifegg6pklmzs7luwcggtzrnlsolxxuyfyd.onion/en/2023/04/30/is-linux-hard-disk-encryption-hacked/index.html#fnref:2

(3) This is understood as follows: In the worst case, fiddling with the encryption settings can lead to data loss, and you clearly want to avoid such risks when upgrading your operating system. / Onion link: http://7sk2kov2xwx6cbc32phynrifegg6pklmzs7luwcggtzrnlsolxxuyfyd.onion/en/2023/04/30/is-linux-hard-disk-encryption-hacked/index.html#fnref:3

(4) The Tails community is working on a fix for this, which is expected to be available in Tails 5.13, late May 2023: / Onion link: http://7sk2kov2xwx6cbc32phynrifegg6pklmzs7luwcggtzrnlsolxxuyfyd.onion/en/2023/04/30/is-linux-hard-disk-encryption-hacked/index.html#fnref:4


Source: Act for Freedom Now

Translation: Revolutionary Consciousness The Best Technology Site in Greecefgns

LUKS, Linux

Written by newsbot

Although the press releases will be from very select to rarely, I said to go ... because sometimes the authors are hiding.

Leave a reply

Your email address is not published. Required fields are mentioned with *

Your message will not be published if:
1. Contains insulting, defamatory, racist, offensive or inappropriate comments.
2. Causes harm to minors.
3. It interferes with the privacy and individual and social rights of other users.
4. Advertises products or services or websites.
5. Contains personal information (address, phone, etc.).