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

This is a changeset adding encryption to btrfs. It is not complete; it
does not support inline data or verity or authenticated encryption. It
is primarily intended as a proof that the fscrypt extent encryption
changeset it builds on work. 

As per the design doc refined in the fall of last year [1], btrfs
encryption has several steps: first, adding extent encryption to fscrypt
and then btrfs; second, adding authenticated encryption support to the
block layer, fscrypt, and then btrfs; and later adding potentially the
ability to change the key used by a directory (either for all data or
just newly written data) and/or allowing use of inline extents and
verity items in combination with encryption and/or enabling send/receive
of encrypted volumes. As such, this change is only the first step and is
unsafe.

This change does not pass a couple of encryption xfstests, because of
different properties of extent encryption. It hasn't been tested with
direct IO or RAID. Because currently extent encryption always uses inline
encryption (i.e. IO-block-only) for data encryption, it does not support
encryption of inline extents; similarly, since btrfs stores verity items
in the tree instead of in inline encryptable blocks on disk as other
filesystems do, btrfs cannot currently encrypt verity items. Finally,
this is insecure; the checksums are calculated on the unencrypted data
and stored unencrypted, which is a potential information leak. (This
will be addressed by authenticated encryption).

This changeset is built on two prior changesets to fscrypt: [2] and [3]
and should have no effect on unencrypted usage.

[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988246.git.sweettea-kernel@dorminy.me
  • Atemu@lemmy.mlOPEnglish
    1·
    1 year ago

    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.