[PATCH v1 00/17] btrfs: add encryption feature

cross-posted from: lemmy.ml/post/1840134

<pre style="background-color:#ffffff;">
<span style="color:#323232;">This is a changeset adding encryption to btrfs. It is not complete; it
</span><span style="color:#323232;">does not support inline data or verity or authenticated encryption. It
</span><span style="color:#323232;">is primarily intended as a proof that the fscrypt extent encryption
</span><span style="color:#323232;">changeset it builds on work. 
</span><span style="color:#323232;">
</span><span style="color:#323232;">As per the design doc refined in the fall of last year [1], btrfs
</span><span style="color:#323232;">encryption has several steps: first, adding extent encryption to fscrypt
</span><span style="color:#323232;">and then btrfs; second, adding authenticated encryption support to the
</span><span style="color:#323232;">block layer, fscrypt, and then btrfs; and later adding potentially the
</span><span style="color:#323232;">ability to change the key used by a directory (either for all data or
</span><span style="color:#323232;">just newly written data) and/or allowing use of inline extents and
</span><span style="color:#323232;">verity items in combination with encryption and/or enabling send/receive
</span><span style="color:#323232;">of encrypted volumes. As such, this change is only the first step and is
</span><span style="color:#323232;">unsafe.
</span><span style="color:#323232;">
</span><span style="color:#323232;">This change does not pass a couple of encryption xfstests, because of
</span><span style="color:#323232;">different properties of extent encryption. It hasn't been tested with
</span><span style="color:#323232;">direct IO or RAID. Because currently extent encryption always uses inline
</span><span style="color:#323232;">encryption (i.e. IO-block-only) for data encryption, it does not support
</span><span style="color:#323232;">encryption of inline extents; similarly, since btrfs stores verity items
</span><span style="color:#323232;">in the tree instead of in inline encryptable blocks on disk as other
</span><span style="color:#323232;">filesystems do, btrfs cannot currently encrypt verity items. Finally,
</span><span style="color:#323232;">this is insecure; the checksums are calculated on the unencrypted data
</span><span style="color:#323232;">and stored unencrypted, which is a potential information leak. (This
</span><span style="color:#323232;">will be addressed by authenticated encryption).
</span><span style="color:#323232;">
</span><span style="color:#323232;">This changeset is built on two prior changesets to fscrypt: [2] and [3]
</span><span style="color:#323232;">and should have no effect on unencrypted usage.
</span><span style="color:#323232;">
</span><span style="color:#323232;">[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
</span><span style="color:#323232;">[2]
</span><span style="color:#323232;">https://lore.kernel.org/linux-fscrypt/[email protected]/
</span><span style="color:#323232;">[3]
</span><span style="color:#323232;">https://lore.kernel.org/linux-fscrypt/[email protected]
</span>
UnfortunateShort,

I honestly tought they had abandoned “native” encryption on btrfs itself, after seeing that it works perfectly fine with LUKS and dm-crypt. Glad to see this is actually being developed.

Can’t wait for the day where you can just create a key, use a TPM or U2F to store it and let btrfs handle the rest

ozymandias117,

Is there a major performance benefit to encryption using LUKS over this?

Or is this more useful for like, encrypting a single directory of a filesystem?

I’ve never quite understood the impetus for each filesystem handling encryption rather than doing it at the block layer

Atemu,
@Atemu@lemmy.ml avatar

Possibilities at the block layer are generally quite limited since it only has limited means to work with. It’s very low-level. For example, it is not possible to do authentication in LUKS. An attacker can’t read the data but they can modify it; undetected.
You need to stack another layer on top and I’m not sure that’s even a thing.

The patch mentions that authenticated hashes aren’t supported yet either but with effectively limitless metadata to work with, it’s at least possible to do.

Per-directory/subvolume encryption is also a useful feature. You could encrypt the root fs which generally does not contain sensitive information using a key in TPM but then require a password to unlock the user’s home. That’s basically how it works in Android and it builds on top of fscrypt.

ozymandias117, (edited )

An attacker can’t read the data, but they can modify it; undetected

Wouldn’t it then decrypt to gibberish data unless they already had the encryption keys?

If it decrypts incorrectly, shouldn’t BTRFS checksumming then return an I/O error to user space as well?

Atemu,
@Atemu@lemmy.ml avatar

Note that this is of course a very theoretical attack vector.

Wouldn’t it then decrypt to gibberish data unless they already had the encryption keys?

Depends. I don’t know the situation of LUKS and its commonly used ciphers in particulare but even some commonly used ciphers are vulnerable to things like bitflip attacks.

This is usually “fixed” by authenticating them but that’s not easily possible at the block layer.

If it decrypts incorrectly, shouldn’t BTRFS checksumming then return an I/O error to user space as well?

Note that btrfs usually uses CRCs, not cryptographic checksums. They’re designed to catch “naturally” occuring corruption, not crafted corruption. Naturally, it’d still be extremely hard to break them when working with encrypted data but it’s a “uh, sounds pretty hard” situtation, not a “we can prove you’d need billions of years to do it” one.

You can use cryptographic checksums but note again here that the attacker could be able to modify the checksum aswell.

I don’t know how feasible this really is a but a possible attack could be to tell btrfs that the extent you modified is a nochecksum extent (you can turn off checksums in btrfs) which would make btrfs simply not check the checksum.

Actual authentication fixes all of that.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • uselessserver093
  • Food
  • [email protected]
  • aaaaaaacccccccce
  • test
  • CafeMeta
  • testmag
  • MUD
  • RhythmGameZone
  • RSS
  • dabs
  • oklahoma
  • Socialism
  • KbinCafe
  • TheResearchGuardian
  • Ask_kbincafe
  • SuperSentai
  • feritale
  • KamenRider
  • All magazines
    •