Serious Security: Linux Full Disk Encryption Bug Fixed – Patch Now!

A lot of people “run Linux” without really knowing or caring – many home routers, navigation devices, webcams, and other IoT devices are based on it; most phones in the world run a Linux-derived variant, says for Android; many, if not most, off-the-shelf cloud services rely on Linux to host your content.

But many users and system administrators don’t just “use Linux,” they’re also responsible for everyone else’s hundreds, thousands, or even millions of desktops, laptops, and servers running Linux.

These system administrators are often responsible not only for ensuring that the systems under their jurisdiction operate reliably, but also for ensuring that they are as secure as possible.

In today’s world, this almost certainly means knowing, understanding, deploying and managing some kind of Full Disk Encryption System, on Linux this may mean using a system called LUKS (Linux unified key setup) and a named cryptsetup take care of it.

FDE wins

Full Disk Encryption, often abbreviated as FDE, is a simple but effective idea: encrypt each sector before writing it to disk, no matter which software, user, file or directory it belongs to; decrypt each sector after reading it back.

FDE by itself is not enough, because basically everything has a password, so you usually end up layering further file-specific, application-specific, or user-specific password protection on top of it.

But now FDE can be considered mandatory, especially for laptops, for the exact same reason: there is at least one password, so nothing is not encrypted.

With FDE, you don’t have to worry about files you might forget to encrypt; or a temporary copy you make from an encrypted folder to an unencrypted folder when you’re ready to hand over; or when you use a menu option such as Export, Compile or Print.

With FDE, everything is encrypted, including unused parts of the disk, deleted sectors, filenames, swap file data, applications you’re using, operating system files you’ve installed, and even ones you’ve purposely zeroed out Disk space forcibly overwrites previous content.

After all, if you don’t leave anything unencrypted and your laptop is stolen, the data on the disk isn’t much use to thieves or the cyber crooks they sell it to.

If you can prove that you did have FDE installed on the now-missing laptop, then you can put your hands on your heart and swear by your auditors, regulators, customers, and even curious journalists! – If that stolen laptop shows up on the dark web, they have little or nothing to worry about.

FDE is considered green

Even better, if you want to retire old equipment—especially if it doesn’t work reliably—the FDE generally reduces the controversy over sending old equipment for general reuse or recycling.

FDE means that if someone with ulterior motives buys an old kit from your recycling company, extracts the old disk drive and somehow brings it back to life, they won’t be able to easily dump your old data for fun and profit.

Without FDE, old storage devices become a bit like nuclear waste: few people dare to trust them to be “repurposed”, so you usually end up stuffing old safes with “we’re not sure what to do with these yet” disk drives , or use laborious equipment destruction protocols, which are far from being as environmentally friendly as they should be.

(old-fashioned materials Getting into blast furnaces is quick and efficient — law enforcement teams are known to do it, live on TV, after a weapons amnesty aimed at reducing endemic violence — but blindly evaporating computer kits and their many heterogeneous metals and polymers is no longer Acceptable Faces “Secure Erase”. )

But what if there is an error?

The problem with FDE — and just as importantly, the software tools that help you manage it reliably — is that it’s easy to do bad things.

Are you using the correct encryption algorithm? Did you generate the encryption key reliably? Are you handling data integrity issues correctly? Can you change your password safely and quickly? How easy is it to lock yourself out by mistake? What if you want to adjust encryption parameters as company policy evolves?

Unfortunately, cryptsetup The program, widely used to manage Linux FDE in a way that solves the above problem, turned out to have a nasty bug called CVE-2021-4122, which provides a useful function called re-encrypt.

A well-designed FDE solution will not use your password directly as the original low-level encryption key for the following reasons:

• Changing the low-level key means decrypting and re-encrypting the entire disk. This may take several hours.
• Multiple users need to share a key. Therefore, you cannot revoke access from one user without also locking everyone else out.
• Users often choose weak passwords, or suffer password compromises. If you realize this just happened, the sooner you can change your password, the better.

Therefore, most FDE systems choose a master password for the device – for LUKS, it is usually 512 bits long and comes from the kernel’s high-quality random generator.

Each password holder (up to 8 by default) chooses a personal password that is used to create a personal encrypted version of the master key stored in LUKS keyway, so the master key itself doesn’t actually need to be stored anywhere outside of memory while the device is in use.

In short: you cannot derive a device’s master key unless you provide a valid user key; no user key is stored anywhere on the device; by default, neither the user key nor the master key will start with displayed or stored in clear text.

You can dump the master key of a LUKS device, but it’s hard to go wrong, you need to enter a valid user key to generate master key data:

# cryptsetup luksDump /dev/sdb --dump-master-key

WARNING!
========
The header dump with volume key is sensitive information
that allows access to encrypted partition without a passphrase.
This dump should be stored encrypted in a safe place.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb: ****************
LUKS header information for /dev/sdb
Cipher name:      aes
Cipher mode:      xts-plain64
Payload offset:   32768
UUID:             72f6e201-cbdc-496b-98bd-707ece662c9a
MK bits:          512       <-- MK is short for "master key"
MK dump:          7a 31 05 ba f3 68 b6 be e5 6c 6f 16 92 44 ea 35 
                  0b 66 fe ce ae ec a9 ec 22 db ea c9 9e 15 4d 60 
                  f8 d0 b9 cb b5 1f ab f4 8f d3 e9 c1 1f 05 37 73 
                  7d 64 df 8b be 38 e4 49 29 d1 5d 95 cd a4 9b 04
#

Re-encryption options

As mentioned above, you will sometimes need to change the master encryption settings on your device, especially if you need to adjust some parameters used to keep up with changing encryption recommendations, such as switching to a larger key size.

For this purpose, cryptsetup provides a convenient but complex implementation option called reencrypt, which is actually responsible for three different processes: decrypt, encryption, and re-encrypt your data, even when the device is in use.

Of course, re-encryption can be achieved by calling options --decrypt and --encrypt, but re-encrypting the device while using it requires you to decrypt the entire device before encrypting it again from plaintext

This leaves you exposed for much longer than absolutely necessary: ​​if the device takes 12 hours to decrypt and another 12 hours to encrypt from scratch, then at least some of the data on disk will be intact in plaintext Data days, more than 50% of the data will be kept in clear text for at least 12 hours.

Simplified re-encryption

so, cryptsetup Allows you to simplify the re-encryption process by encrypting some disks with the old key and the rest with the new key, while carefully tracking its distance in case the process is interrupted or the computer needs to be shut down before the process is complete.

When you boot again, the duly authorized user enters the password to mount the device (the user’s password temporarily decrypts the old master key and the new master key, so the double-pipe decrypt-re-encryption process can continue), the re-encryption process starts from Continue where you left off…

…finally, the old master key is cleared, and the new master key acts as the only encryption key for the underlying data.

Unfortunately, code crafted to handle re-encryption is reused to implement a less useful but sometimes necessary option “Fully decrypted to plaintext” (equivalent to re-encrypting with an empty password during the encryption phase), and “Full encryption from plaintext” (essentially re-encrypt with empty password in decrypt part).

When repurposed in this way, reencrypt mode to ensure that no one has tampered with the temporary data used to track how far the process has reached, preventing someone with root access to the disk but not knowing the password from abusing the re-encryption process…

…not applied.

Assess security impact

as a description Related bugfixes Say:

The problem arises from reusing mechanisms designed for the actual re-encryption operation without re-evaluating the security implications of new encryption and decryption operations. While re-encryption requires computation and verification of two key digests, if the target is plaintext (no encryption key), no digest is required to initiate decryption recovery.

In short: someone who has physical access to the disk but doesn’t have the password to decrypt it themselves can trick the re-encryption tool into thinking it’s only part of the decryption process, and thus trick the FDE software into decrypting part of the disk and leaving it unencrypted state.

As the bugfix explains, the LUKS system itself cannot “Prevent intentional modification [because someone with phsycal access to the disk could write to it without going through the LUKS code], provided that such modifications shall not violate data confidentiality. “

That’s the risk here: you might end up with a disk that appears to be encrypted; still requires a valid password to mount; behaves as if it’s encrypted; which might satisfy your auditor that it’s encrypted…

…but it still contains (probably large and many) blocks that are not only stored in cleartext, but also not re-encrypted later.

To make matters worse, perhaps observe:

The attack can also be reversed later (simulating a broken encryption from the plaintext) by possibly modifying the displayed plaintext.

This means that a malicious user can silently decrypt parts of the disk without a password, such as on a server, and silently modify the decrypted data, while it is in plaintext – due to the lack of integrity protection in plaintext mode – — and then seamlessly and secretly re-encrypt and “re-integrate” the data at a later date.

Roughly speaking, they could – at least in theory – by inserting false “evidence” and then Re-encrypt with your password, even if they don’t actually know your password.

what to do?

• upgrade to cryptsetup 2.4.3 or later. If you run a Linux distribution that provides regular updates, you probably already have this version. (use cryptsetup --version find out the answer. )
• Learn how to detect when the re-encryption option is used. you can use it luksDump function to see if partial decryption/encryption is in progress. (see below.)
• Restrict physical access as carefully as possible. Sometimes, for example, if you use a cloud service or a hosted server, you don’t have full control over who gets what. But even in a world of trusted computing modules and tamper-resistant cryptographic chips, it’s not necessary to make it accessible to everyone, if it can be avoided.

CRYPTSETUP command to track re-encryption

--> First command tells cryptsetup to boost the master key length to 512 bits

# cryptsetup reencrypt /dev/sdb --key-size 512
Enter passphrase for key slot 1:

[. . .]

--> While re-encrypting, you will see two extra keylots in use, one to access
--> the new master key (slot 0 here) and the other to keep track of how far
--> the decrypt-and-recrypt process has got (slot 2 here)

# cryptsetup luksDump /dev/sdb
[. . .]
Keyslots:
  0: luks2 (unbound)
        Key:        512 bits
   [. . .]
   Salt:       f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 
   [. . .]
  1: luks2
        Key:        256 bits
   [. . .]
   Salt:       75 33 81 96 ba f3 ec 8a dc ef 28 dc 68 a9 a7 44 
   [. . .]
  2: reencrypt (unbound)
        Key:        8 bits
        Priority:   ignored
        Mode:       reencrypt
        Direction:  forward
   [. . .]

--> After the re-encryption is complete, keyslot 1 (for access to the
--> old master key) is removed, keyslot 2 (denoting the progress of the
--> procedure) is removed, and keyslot 0 takes over for access to the device

# cryptsetup luksDump /dev/sdb
[. . .]
Keyslots:
  0: luks2
        Key:        512 bits
   [. . .]
        Salt:       f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 
   [. . .]

Read More..