Re: [RFC] Preliminary BTRFS Encryption

On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote:

> This patchset adds btrfs encryption support.
> 
> The main objective of this series is to have bugs fixed and stability.
> I have verified with fstests to confirm that there is no regression.
> 
> A design write-up is coming next, however here below is the quick
> example on the cli usage. Please try out, let me know if I have missed
> something.
> 
> Also would like to mention that a review from the security experts is
> due,
> which is important and I believe those review comments can be
> accommodated without major changes from here.
> 
> Also yes, thanks for the emails, I hear, per file encryption and inline
> with vfs layer is also important, which is wip among other things in the
> list.
> 
> As of now these patch set supports encryption on per subvolume, as
> managing properties on per subvolume is a kind of core to btrfs, which
> is easier for data center solution-ing, seamlessly persistent and easy
> to manage.
> 
> 
> Steps:
> -----
> 
> Make sure following kernel TFMs are compiled in.
> # cat /proc/crypto | egrep 'cbc\(aes\)|ctr\(aes\)'
> name         : ctr(aes)
> name         : cbc(aes)

First problem: These are purely encryption algorithms, rather than AE 
(Authenticated Encryption) or AEAD (Authenticated Encryption with 
Associated Data). As a result, they are necessarily vulnerable to 
adaptive chosen-ciphertext attacks, and CBC has historically had other 
issues. I highly recommend using a well-reviewed AE or AEAD mode, such as 
AES-GCM (as ecryptfs does), as long as the code can handle the ciphertext 
being longer than the plaintext.

If it _cannot_ handle the ciphertext being longer than the plaintext, 
please consider that a very serious red flag: It means that you cannot 
provide better security than block-level encryption, which greatly 
reduces the benefit of filesystem-integrated encryption. Being at the 
extent level _should_ permit using AEAD - if it does not, something is 
wrong.

If at all possible, I'd suggest _only_ permitting AEAD cipher modes to be 
used.

Anyway, even for block-level encryption, CTR and CBC have been considered 
obsolete and potentially dangerous to use in disk encryption for quite a 
while - current recommendations for block-level encryption are to use 
either a narrow-block tweakable cipher mode (such as XTS), or a wide-
block one (such as EME or CMC), with the latter providing slightly better 
security, but worse performance.

> Create encrypted subvolume.
> # btrfs su create -e 'ctr(aes)' /btrfs/e1 Create subvolume '/btrfs/e1'
> Passphrase:
> Again passphrase:

I presume the command first creates a key, then creates a subvolume 
referencing that key? If so, that seems sensible.

> A key is created and its hash is updated into the subvolume item,
> and then added to the system keyctl.
> # btrfs su show /btrfs/e1 | egrep -i encrypt
> 	Encryption: 		ctr(aes)@btrfs:75197c8e (594790215)
> 
> # keyctl show 594790215 Keyring
>  594790215 --alsw-v      0     0  logon: btrfs:75197c8e

That's entirely reasonable, though you may want to support "trusted and 
encrypted keys" (Documentation/security/keys-trusted-encrypted.txt)

> Now any file data extents under the subvol /btrfs/e1 will be encrypted.
> 
> You may revoke key using keyctl or btrfs(8) as below.
> # btrfs su encrypt -k out /btrfs/e1
> 
> # btrfs su show /btrfs/e1 | egrep -i encrypt
> 	Encryption: 		ctr(aes)@btrfs:75197c8e (Required key not 
available)
> 
> # keyctl show 594790215 Keyring Unable to dump key: Key has been revoked
> 
> As the key hash is updated, If you provide wrong passphrase in the next
> key in, it won't add key to the system. So we have key verification from
> the day1.

This is good.

> # btrfs su encrypt -k in /btrfs/e1 Passphrase:
> Again passphrase:
> ERROR: failed to set attribute 'btrfs.encrypt' to
> 'ctr(aes)@btrfs:75197c8e' : Key was rejected by service
> 
> ERROR: key set failed: Key was rejected by service
> 
> # btrfs su encrypt -k in /btrfs/e1 Passphrase:
> Again passphrase:
> key for '/btrfs/e1' has  logged in with keytag 'btrfs:75197c8e'
> 
> Now if you revoke the key the read / write fails with key error.
> 
> # md5sum /btrfs/e1/2k-test-file 8c9fbc69125ebe84569a5c1ca088cb14 
> /btrfs/e1/2k-test-file
> 
> # btrfs su encrypt -k out /btrfs/e1
> 
> # md5sum /btrfs/e1/2k-test-file md5sum: /btrfs/e1/2k-test-file: Key has
> been revoked
> 
> # cp /tfs/1k-test-file /btrfs/e1/
> cp: cannot create regular file ‘/btrfs/e1/1k-test-file’: Key has been
> revoked
> 
> Plain text memory scratches for security reason is pending. As there are
> some key revoke notification challenges to coincide with encryption
> context switch,
> which I do believe should be fixed in the due course, but is not a
> roadblock at this stage.
> 
> Thanks, Anand

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html