Date:   Wed, 26 Jul 2017 11:19:22 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     linux-fscrypt@...r.kernel.org
Cc:     linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, linux-crypto@...r.kernel.org,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Alex Cope <alexcope@...gle.com>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: [PATCH v2 0/7] fscrypt: key verification and KDF improvement

From: Eric Biggers <ebiggers@...gle.com>

This patch series solves two major problems which filesystem-level
encryption has currently.  First, the user-supplied master keys are not
verified, which means a malicious user can provide the wrong key for
another user's file and cause a DOS attack or worse.  This flaw has been
criticized in the past [1].  Second, the KDF (Key Derivation Function)
used to derive per-file keys is ad-hoc and nonstandard.  While it meets
the primary security requirement, it's inflexible and is missing some
useful properties such as non-reversibility, which is important under
some threat models.  This weakness was noted by Unterluggauer and
Mangard (2016) [2] who also demonstrated an EM attack against the
current AES-based KDF.

These problems are solved together by introducing a new encryption
policy version where the KDF is changed to HKDF-SHA512, i.e. RFC-5869
[3] with SHA-512 as the underlying hash function.  HKDF is used to
derive the per-file keys as well as to generate a "key hash" which is
stored on-disk to allow key verification.  The HMAC transform for each
master key is pre-keyed and cached, which in practice makes the new KDF
about as fast or even faster than the old one which did not use the
crypto API efficiently.

Please give special consideration to the choice and usage of crypto
algorithms and any other on-disk format and API changes, since we will
be locked into these once merged.

As a sanity check, I have verified the new on-disk format on ext4 by
dumping the encryption xattr and contents of an encrypted regular file
using debugfs, then reproducing the key_hash field and the encrypted
contents in userspace using the RFC-6234 example code and OpenSSL for
HKDF-SHA512 and AES-256-XTS respectively --- given the master key and
unencrypted file contents.

All these changes are independent of filesystem and encryption mode,
i.e. the "v2" encryption policies can be used on any fscrypt-capable
filesystem (ext4, f2fs, or ubifs currently) and with any of the
supported encryption modes.

Changes since v1:
    - Validate encryption modes and flags earlier in
      fscrypt_ioctl_set_policy(), since the modes are used in
      fscrypt_compute_key_hash().
    - Various cleanups
    - Base on v4.13-rc2

References:
  [1] https://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html

  [2] Unterluggauer and Mangard (2016).  "Exploiting the Physical
      Disparity: Side-Channel Attacks on Memory Encryption".
      https://eprint.iacr.org/2016/473.pdf

  [3] RFC 5869. "HMAC-based Extract-and-Expand Key Derivation Function
      (HKDF)".  https://tools.ietf.org/html/rfc5869

Eric Biggers (7):
  fscrypt: add v2 encryption context and policy
  fscrypt: rename ->ci_master_key to ->ci_master_key_descriptor
  fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys
  fscrypt: validate modes and flags earlier when setting policy
  fscrypt: verify that the correct master key was supplied
  fscrypt: cache the HMAC transform for each master key
  fscrypt: for v2 policies, support "fscrypt:" key prefix only

 fs/crypto/Kconfig              |   2 +
 fs/crypto/fscrypt_private.h    | 113 +++++--
 fs/crypto/keyinfo.c            | 668 ++++++++++++++++++++++++++++++++++-------
 fs/crypto/policy.c             | 138 ++++++---
 fs/super.c                     |   4 +
 include/linux/fs.h             |   5 +
 include/linux/fscrypt_common.h |   2 +-
 include/uapi/linux/fs.h        |   6 +
 8 files changed, 779 insertions(+), 159 deletions(-)

-- 
2.14.0.rc0.400.g1c36432dff-goog

Powered by blists - more mailing lists