Data leak concerns of LUKS and TRIM

icebit · 2024-03-27 21:01:39

Good evening,

I have my computer partitioned using the following layout:

- /dev/nvme0n1p1 /boot
- /dev/nvme0n1p2 LUKS
|-> /dev/mapper/luks /

That is, an unencrypted /boot partition and a single encrypted partition mounted at root. When I first installed my system, I added the "discard" kernel parameter to enable ATA TRIM command. Recently I’ve read that TRIM can leak sensitive information about the encrypted volume every time the systemd timer is being run.

Plausible deniability is not a concern for me(in fact the header of the encrypted partition contains details about LUKS afaik), so is there any other way such that the TRIM command could leak sensitive information when the encrypted device is unlocked?

As I said, the only thing that I care is to protect my work stuff in the event of the laptop being stolen, I don’t care about plausible deniability.

Last edited by icebit (2024-03-27 21:03:08)

frostschutz · 2024-03-27 21:18:11

Depends, how do you define sensitive information?

Is it sensitive information if someone knows you only have 500GB of data on your 2TB partition?

With TRIM you can guess how much free space there is, and where this free space is located, vs. where data is located.

For example trimcheck.sh makes such a guess (by checking compressed data size).

#!/bin/bash

#
# check how much encrypted data vs. trimmed areas
#

target="$1"

if [ -b "$target" ]
then
    size=$(blockdev --getsize64 "$target")
else
    size=$(stat -c "%s" "$target")
fi

pv -cN input < "$target" | lzop --fast | pv -cN output --size="$size" > /dev/null

However, data itself is still encrypted, so it's kind of useless to worry about it.

You can use free space patterns like a fingerprint and sometimes tell, that this is likely ext4 or xfs or something else inside. Since these filesystems arrange metadata in a certain way, so some sectors can't be free (if that's where you'd normally have backup superblocks or journals or whatever).

Some standard installers had the issue that offsets of specific files always turned out the same so you knew that file X was located at offset Y, encryption or no. This would allow an attacker to damage a file specifically. However this isn't really a TRIM specific issue, and it would not affect Arch since installation is less automated here.

On SSD it's quite normal to use TRIM (although it's a bit over-used in Linux).

On HDD it's different. You probably have to test the drive anyway, so you can just fill it with random data entirely and keep it that way. This does not affect the lifetime, performance or anything (well, maybe it does for SMR drives).

Another issue may be if it wasn't encrypted originally, so there's old data to get rid of. That's where you could leak data, if you think luksFormat did more than just write a header. It encrypts the entire device in the sense that all future read/write are encrypted, it doesn't change what was there before.

icebit · 2024-03-27 22:01:20

As long that data remains unreadable, I’m fine.

mpan · 2024-03-27 22:37:36

The data itself (files’ content) remains protected.

The risk introduced by TRIM only regards metainformation.⁽¹⁾ TRIM may reveal patterns in how data is allocated. From this, and in particular from how these patterns change over time, the attacker may infer something about the data. For a typical user this doesn’t pose a risk.
____
⁽¹⁾ And I use word “metainformation” instead of “metadata” to avoid confusion with filesystem structures describing files. These receive the same protection as data.

Thor-x86 · 2024-03-31 09:46:11

Unless you are using outdated Samsung Evo 840 firmware, you're safe from CVE-2018-12038.

icebit wrote:

The only thing that I care is to protect my work stuff in the event of the laptop being stolen, I don’t care about plausible deniability.

If it's password-protected LUKS, then the only option for theft to steal your data is by bruteforce, which is rarely happen as it takes a lot of time. But if you're using TPM to do the decryption, consider setup Secure Boot and UEFI-level password because the guide of tapping TPM is already shared publicly.

Arch Linux

#1 2024-03-27 21:01:39

Data leak concerns of LUKS and TRIM

#2 2024-03-27 21:18:11

Re: Data leak concerns of LUKS and TRIM

#3 2024-03-27 22:01:20

Re: Data leak concerns of LUKS and TRIM

#4 2024-03-27 22:37:36

Re: Data leak concerns of LUKS and TRIM

#5 2024-03-31 09:46:11

Re: Data leak concerns of LUKS and TRIM

Board footer