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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
