fscrypt: add an HKDF-SHA512 implementation
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
"hmac(sha512)" transform allocated from the crypto API.
We'll be using this to replace the AES-ECB based KDF currently used to
derive the per-file encryption keys. While the AES-ECB based KDF is
believed to meet the original security requirements, it is nonstandard
and has problems that don't exist in modern KDFs such as HKDF:
1. It's reversible. Given a derived key and nonce, an attacker can
easily compute the master key. This is okay if the master key and
derived keys are equally hard to compromise, but now we'd like to be
more robust against threats such as a derived key being compromised
through a timing attack, or a derived key for an in-use file being
compromised after the master key has already been removed.
2. It doesn't evenly distribute the entropy from the master key; each 16
input bytes only affects the corresponding 16 output bytes.
3. It isn't easily extensible to deriving other values or keys, such as
a public hash for securely identifying the key, or per-mode keys.
Per-mode keys will be immediately useful for Adiantum encryption, for
which fscrypt currently uses the master key directly, introducing
unnecessary usage constraints. Per-mode keys will also be useful for
hardware inline encryption, which is currently being worked on.
HKDF solves all the above problems.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 05:35:47 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Implementation of HKDF ("HMAC-based Extract-and-Expand Key Derivation
|
|
|
|
* Function"), aka RFC 5869. See also the original paper (Krawczyk 2010):
|
|
|
|
* "Cryptographic Extraction and Key Derivation: The HKDF Scheme".
|
|
|
|
*
|
|
|
|
* This is used to derive keys from the fscrypt master keys.
|
|
|
|
*
|
|
|
|
* Copyright 2019 Google LLC
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <crypto/hash.h>
|
2020-11-13 08:20:21 +03:00
|
|
|
#include <crypto/sha2.h>
|
fscrypt: add an HKDF-SHA512 implementation
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
"hmac(sha512)" transform allocated from the crypto API.
We'll be using this to replace the AES-ECB based KDF currently used to
derive the per-file encryption keys. While the AES-ECB based KDF is
believed to meet the original security requirements, it is nonstandard
and has problems that don't exist in modern KDFs such as HKDF:
1. It's reversible. Given a derived key and nonce, an attacker can
easily compute the master key. This is okay if the master key and
derived keys are equally hard to compromise, but now we'd like to be
more robust against threats such as a derived key being compromised
through a timing attack, or a derived key for an in-use file being
compromised after the master key has already been removed.
2. It doesn't evenly distribute the entropy from the master key; each 16
input bytes only affects the corresponding 16 output bytes.
3. It isn't easily extensible to deriving other values or keys, such as
a public hash for securely identifying the key, or per-mode keys.
Per-mode keys will be immediately useful for Adiantum encryption, for
which fscrypt currently uses the master key directly, introducing
unnecessary usage constraints. Per-mode keys will also be useful for
hardware inline encryption, which is currently being worked on.
HKDF solves all the above problems.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 05:35:47 +03:00
|
|
|
|
|
|
|
#include "fscrypt_private.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HKDF supports any unkeyed cryptographic hash algorithm, but fscrypt uses
|
fscrypt: allow 256-bit master keys with AES-256-XTS
[ Upstream commit 7f595d6a6cdc336834552069a2e0a4f6d4756ddf ]
fscrypt currently requires a 512-bit master key when AES-256-XTS is
used, since AES-256-XTS keys are 512-bit and fscrypt requires that the
master key be at least as long any key that will be derived from it.
However, this is overly strict because AES-256-XTS doesn't actually have
a 512-bit security strength, but rather 256-bit. The fact that XTS
takes twice the expected key size is a quirk of the XTS mode. It is
sufficient to use 256 bits of entropy for AES-256-XTS, provided that it
is first properly expanded into a 512-bit key, which HKDF-SHA512 does.
Therefore, relax the check of the master key size to use the security
strength of the derived key rather than the size of the derived key
(except for v1 encryption policies, which don't use HKDF).
Besides making things more flexible for userspace, this is needed in
order for the use of a KDF which only takes a 256-bit key to be
introduced into the fscrypt key hierarchy. This will happen with
hardware-wrapped keys support, as all known hardware which supports that
feature uses an SP800-108 KDF using AES-256-CMAC, so the wrapped keys
are wrapped 256-bit AES keys. Moreover, there is interest in fscrypt
supporting the same type of AES-256-CMAC based KDF in software as an
alternative to HKDF-SHA512. There is no security problem with such
features, so fix the key length check to work properly with them.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Link: https://lore.kernel.org/r/20210921030303.5598-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-21 06:03:03 +03:00
|
|
|
* SHA-512 because it is well-established, secure, and reasonably efficient.
|
|
|
|
*
|
|
|
|
* HKDF-SHA256 was also considered, as its 256-bit security strength would be
|
|
|
|
* sufficient here. A 512-bit security strength is "nice to have", though.
|
|
|
|
* Also, on 64-bit CPUs, SHA-512 is usually just as fast as SHA-256. In the
|
|
|
|
* common case of deriving an AES-256-XTS key (512 bits), that can result in
|
|
|
|
* HKDF-SHA512 being much faster than HKDF-SHA256, as the longer digest size of
|
|
|
|
* SHA-512 causes HKDF-Expand to only need to do one iteration rather than two.
|
fscrypt: add an HKDF-SHA512 implementation
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
"hmac(sha512)" transform allocated from the crypto API.
We'll be using this to replace the AES-ECB based KDF currently used to
derive the per-file encryption keys. While the AES-ECB based KDF is
believed to meet the original security requirements, it is nonstandard
and has problems that don't exist in modern KDFs such as HKDF:
1. It's reversible. Given a derived key and nonce, an attacker can
easily compute the master key. This is okay if the master key and
derived keys are equally hard to compromise, but now we'd like to be
more robust against threats such as a derived key being compromised
through a timing attack, or a derived key for an in-use file being
compromised after the master key has already been removed.
2. It doesn't evenly distribute the entropy from the master key; each 16
input bytes only affects the corresponding 16 output bytes.
3. It isn't easily extensible to deriving other values or keys, such as
a public hash for securely identifying the key, or per-mode keys.
Per-mode keys will be immediately useful for Adiantum encryption, for
which fscrypt currently uses the master key directly, introducing
unnecessary usage constraints. Per-mode keys will also be useful for
hardware inline encryption, which is currently being worked on.
HKDF solves all the above problems.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 05:35:47 +03:00
|
|
|
*/
|
|
|
|
#define HKDF_HMAC_ALG "hmac(sha512)"
|
|
|
|
#define HKDF_HASHLEN SHA512_DIGEST_SIZE
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HKDF consists of two steps:
|
|
|
|
*
|
|
|
|
* 1. HKDF-Extract: extract a pseudorandom key of length HKDF_HASHLEN bytes from
|
|
|
|
* the input keying material and optional salt.
|
|
|
|
* 2. HKDF-Expand: expand the pseudorandom key into output keying material of
|
|
|
|
* any length, parameterized by an application-specific info string.
|
|
|
|
*
|
|
|
|
* HKDF-Extract can be skipped if the input is already a pseudorandom key of
|
|
|
|
* length HKDF_HASHLEN bytes. However, cipher modes other than AES-256-XTS take
|
|
|
|
* shorter keys, and we don't want to force users of those modes to provide
|
|
|
|
* unnecessarily long master keys. Thus fscrypt still does HKDF-Extract. No
|
|
|
|
* salt is used, since fscrypt master keys should already be pseudorandom and
|
|
|
|
* there's no way to persist a random salt per master key from kernel mode.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* HKDF-Extract (RFC 5869 section 2.2), unsalted */
|
|
|
|
static int hkdf_extract(struct crypto_shash *hmac_tfm, const u8 *ikm,
|
|
|
|
unsigned int ikmlen, u8 prk[HKDF_HASHLEN])
|
|
|
|
{
|
|
|
|
static const u8 default_salt[HKDF_HASHLEN];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = crypto_shash_setkey(hmac_tfm, default_salt, HKDF_HASHLEN);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2020-05-02 08:31:15 +03:00
|
|
|
return crypto_shash_tfm_digest(hmac_tfm, ikm, ikmlen, prk);
|
fscrypt: add an HKDF-SHA512 implementation
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
"hmac(sha512)" transform allocated from the crypto API.
We'll be using this to replace the AES-ECB based KDF currently used to
derive the per-file encryption keys. While the AES-ECB based KDF is
believed to meet the original security requirements, it is nonstandard
and has problems that don't exist in modern KDFs such as HKDF:
1. It's reversible. Given a derived key and nonce, an attacker can
easily compute the master key. This is okay if the master key and
derived keys are equally hard to compromise, but now we'd like to be
more robust against threats such as a derived key being compromised
through a timing attack, or a derived key for an in-use file being
compromised after the master key has already been removed.
2. It doesn't evenly distribute the entropy from the master key; each 16
input bytes only affects the corresponding 16 output bytes.
3. It isn't easily extensible to deriving other values or keys, such as
a public hash for securely identifying the key, or per-mode keys.
Per-mode keys will be immediately useful for Adiantum encryption, for
which fscrypt currently uses the master key directly, introducing
unnecessary usage constraints. Per-mode keys will also be useful for
hardware inline encryption, which is currently being worked on.
HKDF solves all the above problems.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 05:35:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute HKDF-Extract using the given master key as the input keying material,
|
|
|
|
* and prepare an HMAC transform object keyed by the resulting pseudorandom key.
|
|
|
|
*
|
|
|
|
* Afterwards, the keyed HMAC transform object can be used for HKDF-Expand many
|
|
|
|
* times without having to recompute HKDF-Extract each time.
|
|
|
|
*/
|
|
|
|
int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
|
|
|
|
unsigned int master_key_size)
|
|
|
|
{
|
|
|
|
struct crypto_shash *hmac_tfm;
|
|
|
|
u8 prk[HKDF_HASHLEN];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
hmac_tfm = crypto_alloc_shash(HKDF_HMAC_ALG, 0, 0);
|
|
|
|
if (IS_ERR(hmac_tfm)) {
|
|
|
|
fscrypt_err(NULL, "Error allocating " HKDF_HMAC_ALG ": %ld",
|
|
|
|
PTR_ERR(hmac_tfm));
|
|
|
|
return PTR_ERR(hmac_tfm);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (WARN_ON(crypto_shash_digestsize(hmac_tfm) != sizeof(prk))) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_free_tfm;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = hkdf_extract(hmac_tfm, master_key, master_key_size, prk);
|
|
|
|
if (err)
|
|
|
|
goto err_free_tfm;
|
|
|
|
|
|
|
|
err = crypto_shash_setkey(hmac_tfm, prk, sizeof(prk));
|
|
|
|
if (err)
|
|
|
|
goto err_free_tfm;
|
|
|
|
|
|
|
|
hkdf->hmac_tfm = hmac_tfm;
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
err_free_tfm:
|
|
|
|
crypto_free_shash(hmac_tfm);
|
|
|
|
out:
|
|
|
|
memzero_explicit(prk, sizeof(prk));
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HKDF-Expand (RFC 5869 section 2.3). This expands the pseudorandom key, which
|
|
|
|
* was already keyed into 'hkdf->hmac_tfm' by fscrypt_init_hkdf(), into 'okmlen'
|
|
|
|
* bytes of output keying material parameterized by the application-specific
|
|
|
|
* 'info' of length 'infolen' bytes, prefixed by "fscrypt\0" and the 'context'
|
|
|
|
* byte. This is thread-safe and may be called by multiple threads in parallel.
|
|
|
|
*
|
|
|
|
* ('context' isn't part of the HKDF specification; it's just a prefix fscrypt
|
|
|
|
* adds to its application-specific info strings to guarantee that it doesn't
|
|
|
|
* accidentally repeat an info string when using HKDF for different purposes.)
|
|
|
|
*/
|
2019-12-09 23:40:54 +03:00
|
|
|
int fscrypt_hkdf_expand(const struct fscrypt_hkdf *hkdf, u8 context,
|
fscrypt: add an HKDF-SHA512 implementation
Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
deriving additional key material from the fscrypt master keys for v2
encryption policies. HKDF is a key derivation function built on top of
HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
"hmac(sha512)" transform allocated from the crypto API.
We'll be using this to replace the AES-ECB based KDF currently used to
derive the per-file encryption keys. While the AES-ECB based KDF is
believed to meet the original security requirements, it is nonstandard
and has problems that don't exist in modern KDFs such as HKDF:
1. It's reversible. Given a derived key and nonce, an attacker can
easily compute the master key. This is okay if the master key and
derived keys are equally hard to compromise, but now we'd like to be
more robust against threats such as a derived key being compromised
through a timing attack, or a derived key for an in-use file being
compromised after the master key has already been removed.
2. It doesn't evenly distribute the entropy from the master key; each 16
input bytes only affects the corresponding 16 output bytes.
3. It isn't easily extensible to deriving other values or keys, such as
a public hash for securely identifying the key, or per-mode keys.
Per-mode keys will be immediately useful for Adiantum encryption, for
which fscrypt currently uses the master key directly, introducing
unnecessary usage constraints. Per-mode keys will also be useful for
hardware inline encryption, which is currently being worked on.
HKDF solves all the above problems.
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
2019-08-05 05:35:47 +03:00
|
|
|
const u8 *info, unsigned int infolen,
|
|
|
|
u8 *okm, unsigned int okmlen)
|
|
|
|
{
|
|
|
|
SHASH_DESC_ON_STACK(desc, hkdf->hmac_tfm);
|
|
|
|
u8 prefix[9];
|
|
|
|
unsigned int i;
|
|
|
|
int err;
|
|
|
|
const u8 *prev = NULL;
|
|
|
|
u8 counter = 1;
|
|
|
|
u8 tmp[HKDF_HASHLEN];
|
|
|
|
|
|
|
|
if (WARN_ON(okmlen > 255 * HKDF_HASHLEN))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
desc->tfm = hkdf->hmac_tfm;
|
|
|
|
|
|
|
|
memcpy(prefix, "fscrypt\0", 8);
|
|
|
|
prefix[8] = context;
|
|
|
|
|
|
|
|
for (i = 0; i < okmlen; i += HKDF_HASHLEN) {
|
|
|
|
|
|
|
|
err = crypto_shash_init(desc);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (prev) {
|
|
|
|
err = crypto_shash_update(desc, prev, HKDF_HASHLEN);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = crypto_shash_update(desc, prefix, sizeof(prefix));
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
err = crypto_shash_update(desc, info, infolen);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(counter) != 1);
|
|
|
|
if (okmlen - i < HKDF_HASHLEN) {
|
|
|
|
err = crypto_shash_finup(desc, &counter, 1, tmp);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
memcpy(&okm[i], tmp, okmlen - i);
|
|
|
|
memzero_explicit(tmp, sizeof(tmp));
|
|
|
|
} else {
|
|
|
|
err = crypto_shash_finup(desc, &counter, 1, &okm[i]);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
counter++;
|
|
|
|
prev = &okm[i];
|
|
|
|
}
|
|
|
|
err = 0;
|
|
|
|
out:
|
|
|
|
if (unlikely(err))
|
|
|
|
memzero_explicit(okm, okmlen); /* so caller doesn't need to */
|
|
|
|
shash_desc_zero(desc);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
void fscrypt_destroy_hkdf(struct fscrypt_hkdf *hkdf)
|
|
|
|
{
|
|
|
|
crypto_free_shash(hkdf->hmac_tfm);
|
|
|
|
}
|