From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [195.159.176.226] ([195.159.176.226]:58066 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751075AbcIOExz (ORCPT ); Thu, 15 Sep 2016 00:53:55 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bkOgD-0000wB-DZ for linux-btrfs@vger.kernel.org; Thu, 15 Sep 2016 06:53:45 +0200 To: linux-btrfs@vger.kernel.org From: Alex Elsayed Subject: Re: [RFC] Preliminary BTRFS Encryption Date: Thu, 15 Sep 2016 04:53:34 +0000 (UTC) Message-ID: References: <1473773990-3071-1-git-send-email-anand.jain@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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