From patchwork Fri Dec 8 01:38:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 10101455 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B3EF860325 for ; Fri, 8 Dec 2017 01:40:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A19D52899A for ; Fri, 8 Dec 2017 01:40:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 95FB4289B0; Fri, 8 Dec 2017 01:40:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AFC7F28997 for ; Fri, 8 Dec 2017 01:40:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752095AbdLHBkU (ORCPT ); Thu, 7 Dec 2017 20:40:20 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:41086 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751020AbdLHBkS (ORCPT ); Thu, 7 Dec 2017 20:40:18 -0500 Received: by mail-it0-f68.google.com with SMTP id x28so1668541ita.0; Thu, 07 Dec 2017 17:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=lFMPFn5iJj53A9e9Fr05gNOzIHVqAwPT9IzqXi9CtgI=; b=snx+tSjtV8sp+1gxXEfVR0NgS3L2Geg2B4mIj0iYuAzzU75Mqbuzg1uHQmXOqVOl5h cFZ2vgt6tlab6NzeFDUKxXl/wrfJLF+7gOetKsPA0KUe+Bq1BYCVJaU32v7Gfypgjx8U zBltXXWVfQu4mCKO1n/PtViEAORwcT7IJZttzwxZO6PEn9JKqgGPlWQRhWU/EvICID0P jQzPurCqmIWx/8eUtqccW61Jb5sLHxuwlAOGtnCzfIoBiiMFbPM9MgsWGxv8xNGMAau9 lCFk5thAeuwDjhfgH9oy/A6wx0gb2kt7aAxlLoetMvRmqtNwLhDmN3uY4njhJD9gGL6v MmQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=lFMPFn5iJj53A9e9Fr05gNOzIHVqAwPT9IzqXi9CtgI=; b=Y7sm6f6CJGFrQ5CvpB3tFrmC3HQnq45oUWdbUepvMhYQ9EFwCwhBMuo/HzkQz317dq guiXHk0HWvUwRLa9F8dDNRIqjCGRslqrNFJaMKLYUIOFiIod38t0UIRyAi7YL4zk3yyd OQu9W2d57ri4CZWL9xceqWnxEVeHD/g42tSqN0/0/V0Mb6m7t1E19ii6DgXjAguRUwHQ TIB+bGHe2KP6ChhCOOoZtRoZisz1W91j3Qr43GZ8c+rCOnKdk5prv5ke5biCoHgYcTBr g7QH7nKpCcuTaht4CckchvjcF7Hb593pqO+9PM+LCYz8TSvKTNmdJy0xyDRk4nuFAWyl 3AOg== X-Gm-Message-State: AJaThX6xcFNNIMWeYf1O1TBgzYL6DrVRFadHB1p4EJJiyOpaqt+dq8VG Zi1t5NvMU7uBLjoo8O7Z5Ac6jelC X-Google-Smtp-Source: AGs4zMafA8MqG9pyBjvjdPdo1dtJrvMC1vtkTottKTlZgcgRNAvpmvYZoV0FjSuE+ynWnCrkZMO0oA== X-Received: by 10.107.33.71 with SMTP id h68mr38489376ioh.167.1512697217274; Thu, 07 Dec 2017 17:40:17 -0800 (PST) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.175.88]) by smtp.gmail.com with ESMTPSA id b195sm3167491ioa.43.2017.12.07.17.40.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Dec 2017 17:40:16 -0800 (PST) From: Eric Biggers To: linux-fscrypt@vger.kernel.org, Theodore Ts'o Cc: linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-crypto@vger.kernel.org, Jaegeuk Kim , Michael Halcrow , Paul Crowley , Martin Willi , Ard Biesheuvel , David Gstir , "Jason A . Donenfeld" , Eric Biggers Subject: [PATCH] fscrypt: add support for ChaCha20 contents encryption Date: Thu, 7 Dec 2017 17:38:38 -0800 Message-Id: <20171208013838.105034-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.15.1.424.g9478a66081-goog Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers fscrypt currently only supports AES encryption. However, many low-end mobile devices still use older CPUs such as ARMv7, which do not support the AES instructions (the ARMv8 Cryptography Extensions). This results in very poor AES performance, even if the NEON bit-sliced implementation is used. Roughly 20-40 MB/s is a typical number, in comparison to 300-800 MB/s on CPUs that support the AES instructions. Switching from AES-256 to AES-128 only helps by about 30%. The result is that vendors don't enable encryption on these devices, leaving users unprotected. A performance difference of similar magnitude can also be observed on x86, between CPUs with and without the AES-NI instruction set. This patch provides an alternative to AES by updating fscrypt to support the ChaCha20 stream cipher (RFC7539) for contents encryption. ChaCha20 was designed to have a large security margin, to be efficient on general-purpose CPUs without dedicated instructions, and to be vectorizable. It is already supported by the Linux crypto API, including a vectorized implementation for ARM using NEON instructions, and vectorized implementations for x86 using SSSE3 or AVX2 instructions. On 32-bit ARM processors with NEON support, ChaCha20 is about 3.2 times faster than AES-128-XTS (chacha20-neon vs. xts-aes-neonbs). Without NEON support, ChaCha20 is about 1.5 times as fast (chacha20-generic vs. xts(aes-asm)). The improvement over AES-256-XTS is even greater. Note that stream ciphers are not an ideal choice for disk encryption, since each data block has to be encrypted with the same IV each time it is overwritten. Consequently, an adversary who observes the ciphertext both before and after a write can trivially recover the keystream if they can guess one of the plaintexts. Moreover, an adversary who can write to the ciphertext can flip arbitrary bits in the plaintext, merely by flipping the corresponding bits in the ciphertext. A block cipher operating in the XTS or CBC-ESSIV mode provides some protection against these types of attacks -- albeit not full protection, which would at minimum require the use an authenticated encryption mode with nonces. Unfortunately, we are unaware of any block cipher which performs as well as ChaCha20, has a similar or greater security margin, and has been subject to as much public security analysis. We do not consider Speck to be a viable alternative at this time. Still, a stream cipher is sufficient to protect data confidentiality in the event of a single point-in-time permanent offline compromise of the disk, which currently is the primary threat model for fscrypt. Thus, when the alternative is quite literally *no encryption*, we might as well use a stream cipher. We offer ChaCha20 rather than the reduced-round variants ChaCha8 or ChaCha12 because ChaCha20 has a much higher security margin, and we are primarily targeting CPUs where ChaCha20 is fast enough, in particular CPUs that have vector instructions such as NEON or SSSE3. Also, the crypto API currently only supports ChaCha20. Still, if ChaCha8 and/or ChaCha12 support were to be added to the crypto API, it would be straightforward to support them in fscrypt too. Currently, stream ciphers cannot be used for filenames encryption with fscrypt because all filenames in a directory have to be encrypted with the same IV. Therefore, we offer ChaCha20 for contents encryption only. Filenames encryption still must use AES-256-CTS-CBC. This is acceptable because filenames encryption is not as performance-critical as contents encryption. Reviewed-by: Michael Halcrow Signed-off-by: Eric Biggers --- Documentation/filesystems/fscrypt.rst | 43 +++++++++++++++++++--- fs/crypto/Kconfig | 1 + fs/crypto/crypto.c | 69 ++++++++++++++++++++++++++++------- fs/crypto/keyinfo.c | 2 + include/linux/fscrypt.h | 6 ++- include/uapi/linux/fs.h | 1 + 6 files changed, 102 insertions(+), 20 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 776ddc655f79..927d3c88816b 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -184,6 +184,9 @@ replaced with HKDF or another more standard KDF in the future. Encryption modes and usage ========================== +Available modes +--------------- + fscrypt allows one encryption mode to be specified for file contents and one encryption mode to be specified for filenames. Different directory trees are permitted to use different encryption modes. @@ -191,24 +194,52 @@ Currently, the following pairs of encryption modes are supported: - AES-256-XTS for contents and AES-256-CTS-CBC for filenames - AES-128-CBC for contents and AES-128-CTS-CBC for filenames +- ChaCha20 for contents and AES-256-CTS-CBC for filenames It is strongly recommended to use AES-256-XTS for contents encryption. AES-128-CBC was added only for low-powered embedded devices with crypto accelerators such as CAAM or CESA that do not support XTS. +Similarly, ChaCha20 was only added for low-end devices that have +neither a CPU with AES instructions, nor a hardware crypto +accelerator. Note that since ChaCha20 is a stream cipher, it is +easily broken if an attacker can view encrypted data both before and +after it is overwritten. Thus, even moreso than the other modes, +ChaCha20 can protect data confidentiality *only* in the event of a +single point-in-time, permanent offline compromise of the storage. +Also, ChaCha20 is supported only for contents encryption, not +filenames encryption, because all filenames in a directory have to be +encrypted with the same IV, which would be especially inappropriate +for a stream cipher. + New encryption modes can be added relatively easily, without changes to individual filesystems. However, authenticated encryption (AE) modes are not currently supported because of the difficulty of dealing with ciphertext expansion. +Contents encryption +------------------- + For file contents, each filesystem block is encrypted independently. Currently, only the case where the filesystem block size is equal to -the system's page size (usually 4096 bytes) is supported. With the -XTS mode of operation (recommended), the logical block number within -the file is used as the IV. With the CBC mode of operation (not -recommended), ESSIV is used; specifically, the IV for CBC is the -logical block number encrypted with AES-256, where the AES-256 key is -the SHA-256 hash of the inode's data encryption key. +the system's page size (usually 4096 bytes) is supported. + +With the XTS mode of operation, the logical block number within the +file is used as the IV. + +With the CBC mode of operation, ESSIV is used. Specifically, the IV +is the file logical block number encrypted with AES-256, where the +AES-256 key is the SHA-256 hash of the inode's data encryption key. + +With ChaCha20, the file logical block number is also used as the IV, +but it is formatted differently to ensure that it is copied into the +"nonce" portion of the ChaCha20 initial state (words 14-15) rather +than the "block counter" portion (words 12-13). This detail is +critical, since otherwise different portions of the file would be +encrypted with the same keystream. + +Filenames encryption +-------------------- For filenames, the full filename is encrypted at once. Because of the requirements to retain support for efficient directory lookups and diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig index 02b7d91c9231..44f052e9d842 100644 --- a/fs/crypto/Kconfig +++ b/fs/crypto/Kconfig @@ -3,6 +3,7 @@ config FS_ENCRYPTION select CRYPTO select CRYPTO_AES select CRYPTO_CBC + select CRYPTO_CHACHA20 select CRYPTO_ECB select CRYPTO_XTS select CRYPTO_CTS diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 732a786cce9d..d5c95a18db59 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -126,15 +126,66 @@ struct fscrypt_ctx *fscrypt_get_ctx(const struct inode *inode, gfp_t gfp_flags) } EXPORT_SYMBOL(fscrypt_get_ctx); +struct fscrypt_iv { + __le64 first_half; + __le64 second_half; +}; + +/* + * Generate the IV for encrypting/decrypting the block at the given logical + * block number within a file. + */ +static void fscrypt_generate_iv(struct fscrypt_iv *iv, u64 lblk_num, + const struct fscrypt_info *ci) +{ + BUILD_BUG_ON(sizeof(*iv) != FS_IV_SIZE); + + if (ci->ci_data_mode == FS_ENCRYPTION_MODE_CHACHA20) { + /* + * ChaCha20 interprets its IV as a block counter followed by a + * nonce. We *MUST NOT* use the file logical block number as + * the Chacha block counter because the ChaCha block counter + * counts 64-byte ChaCha blocks, which are much smaller than + * file blocks. If we did, then portions of the keystream would + * be repeated, which would be catastrophic. + * + * We could initialize the block counter with the offset in the + * file in ChaCha blocks. But RFC7539 defines the ChaCha20 + * block counter to be 32-bit, which is only enough for a 256GiB + * keystream. Confusingly, this differs from the original + * ChaCha paper which defines the block counter to be 64-bit. + * + * To be compatible with either convention, just put the file + * logical block number in the second half of the IV, so that it + * goes into the "nonce" portion of the ChaCha initial state + * (words 14-15). The ChaCha block counter then starts at 0 for + * each file block. In other words, we use one keystream per + * file block instead of one keystream per file. + */ + iv->first_half = 0; + iv->second_half = cpu_to_le64(lblk_num); + + BUG_ON(ci->ci_essiv_tfm != NULL); + } else { + /* XTS or CBC */ + iv->first_half = cpu_to_le64(lblk_num); + iv->second_half = 0; + + if (ci->ci_essiv_tfm != NULL) { + /* CBC */ + BUILD_BUG_ON(AES_BLOCK_SIZE != FS_IV_SIZE); + crypto_cipher_encrypt_one(ci->ci_essiv_tfm, + (u8 *)iv, (u8 *)iv); + } + } +} + int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw, u64 lblk_num, struct page *src_page, struct page *dest_page, unsigned int len, unsigned int offs, gfp_t gfp_flags) { - struct { - __le64 index; - u8 padding[FS_IV_SIZE - sizeof(__le64)]; - } iv; + struct fscrypt_iv iv; struct skcipher_request *req = NULL; DECLARE_CRYPTO_WAIT(wait); struct scatterlist dst, src; @@ -144,15 +195,7 @@ int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw, BUG_ON(len == 0); - BUILD_BUG_ON(sizeof(iv) != FS_IV_SIZE); - BUILD_BUG_ON(AES_BLOCK_SIZE != FS_IV_SIZE); - iv.index = cpu_to_le64(lblk_num); - memset(iv.padding, 0, sizeof(iv.padding)); - - if (ci->ci_essiv_tfm != NULL) { - crypto_cipher_encrypt_one(ci->ci_essiv_tfm, (u8 *)&iv, - (u8 *)&iv); - } + fscrypt_generate_iv(&iv, lblk_num, ci); req = skcipher_request_alloc(tfm, gfp_flags); if (!req) { diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c index 5e6e846f5a24..bae4cce2389a 100644 --- a/fs/crypto/keyinfo.c +++ b/fs/crypto/keyinfo.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include "fscrypt_private.h" @@ -134,6 +135,7 @@ static const struct { FS_AES_128_CBC_KEY_SIZE }, [FS_ENCRYPTION_MODE_AES_128_CTS] = { "cts(cbc(aes))", FS_AES_128_CTS_KEY_SIZE }, + [FS_ENCRYPTION_MODE_CHACHA20] = { "chacha20", CHACHA20_KEY_SIZE }, }; static int determine_cipher_type(struct fscrypt_info *ci, struct inode *inode, diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index 08b4b40c5aa8..1cfb7950f915 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -100,11 +100,15 @@ static inline bool fscrypt_dummy_context_enabled(struct inode *inode) static inline bool fscrypt_valid_enc_modes(u32 contents_mode, u32 filenames_mode) { + if (contents_mode == FS_ENCRYPTION_MODE_AES_256_XTS && + filenames_mode == FS_ENCRYPTION_MODE_AES_256_CTS) + return true; + if (contents_mode == FS_ENCRYPTION_MODE_AES_128_CBC && filenames_mode == FS_ENCRYPTION_MODE_AES_128_CTS) return true; - if (contents_mode == FS_ENCRYPTION_MODE_AES_256_XTS && + if (contents_mode == FS_ENCRYPTION_MODE_CHACHA20 && filenames_mode == FS_ENCRYPTION_MODE_AES_256_CTS) return true; diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index 4199f8acbce5..5a25eb2994b1 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -275,6 +275,7 @@ struct fsxattr { #define FS_ENCRYPTION_MODE_AES_256_CTS 4 #define FS_ENCRYPTION_MODE_AES_128_CBC 5 #define FS_ENCRYPTION_MODE_AES_128_CTS 6 +#define FS_ENCRYPTION_MODE_CHACHA20 7 struct fscrypt_policy { __u8 version;