On Tue Jan 2, 2024 at 7:04 PM EET, James Bottomley wrote:
> Add session based HMAC authentication plus parameter decryption and
> response encryption using AES. The basic design is to segregate all
> the nasty crypto, hash and hmac code into tpm2-sessions.c and export a
> usable API. The API first of all starts off by gaining a session with
> tpm2_start_auth_session() which initiates a session with the TPM and
> allocates an opaque tpm2_auth structure to handle the session
> parameters. The design is that session use will be single threaded
> from start to finish under the ops lock, so the tpm2_auth structure is
> stored in struct tpm2_chip to simpify the externally visible API.
>
> The session can be ended with tpm2_end_auth_session() which is
> designed only to be used in error legs. Ordinarily the further
> session API (future patches) will end or continue the session
> appropriately without having to call this.
>
> Signed-off-by: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> # crypto API parts
>
> ---
>
> v6: split into new patch, update config variable
> ---
> drivers/char/tpm/Kconfig | 3 +
> drivers/char/tpm/tpm-buf.c | 1 +
> drivers/char/tpm/tpm-chip.c | 3 +
> drivers/char/tpm/tpm2-sessions.c | 383 +++++++++++++++++++++++++++++++
> include/linux/tpm.h | 34 +++
> 5 files changed, 424 insertions(+)
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index e3c39a83171b..086cb8588493 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -30,6 +30,9 @@ if TCG_TPM
> config TCG_TPM2_HMAC
> bool "Use encrypted and HMACd transactions on the TPM bus"
> default y
> + select CRYPTO_ECDH
> + select CRYPTO_LIB_AESCFB
> + select CRYPTO_LIB_SHA256
> help
> Setting this causes us to deploy a scheme which uses request
> and response HMACs in addition to encryption for
> diff --git a/drivers/char/tpm/tpm-buf.c b/drivers/char/tpm/tpm-buf.c
> index bb81180495d1..274130398569 100644
> --- a/drivers/char/tpm/tpm-buf.c
> +++ b/drivers/char/tpm/tpm-buf.c
> @@ -44,6 +44,7 @@ void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)
> head->tag = cpu_to_be16(tag);
> head->length = cpu_to_be32(sizeof(*head));
> head->ordinal = cpu_to_be32(ordinal);
> + buf->handles = 0;
> }
> EXPORT_SYMBOL_GPL(tpm_buf_reset);
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 42b1062e33cd..d93937326b2e 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -275,6 +275,9 @@ static void tpm_dev_release(struct device *dev)
> kfree(chip->work_space.context_buf);
> kfree(chip->work_space.session_buf);
> kfree(chip->allocated_banks);
> +#ifdef CONFIG_TCG_TPM2_HMAC
> + kfree(chip->auth);
> +#endif
> kfree(chip);
> }
>
> diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> index ef66c28bb332..bca6fe3ebb10 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -3,18 +3,397 @@
> /*
> * Copyright (C) 2018 James.Bottomley@xxxxxxxxxxxxxxxxxxxxx
> *
> + * Cryptographic helper routines for handling TPM2 sessions for
> + * authorization HMAC and request response encryption.
> + *
> + * The idea is to ensure that every TPM command is HMAC protected by a
> + * session, meaning in-flight tampering would be detected and in
> + * addition all sensitive inputs and responses should be encrypted.
> + *
> + * The basic way this works is to use a TPM feature called salted
> + * sessions where a random secret used in session construction is
> + * encrypted to the public part of a known TPM key. The problem is we
> + * have no known keys, so initially a primary Elliptic Curve key is
> + * derived from the NULL seed (we use EC because most TPMs generate
> + * these keys much faster than RSA ones). The curve used is NIST_P256
> + * because that's now mandated to be present in 'TCG TPM v2.0
> + * Provisioning Guidance'
> + *
> + * Threat problems: the initial TPM2_CreatePrimary is not (and cannot
> + * be) session protected, so a clever Man in the Middle could return a
> + * public key they control to this command and from there intercept
> + * and decode all subsequent session based transactions. The kernel
> + * cannot mitigate this threat but, after boot, userspace can get
> + * proof this has not happened by asking the TPM to certify the NULL
> + * key. This certification would chain back to the TPM Endorsement
> + * Certificate and prove the NULL seed primary had not been tampered
> + * with and thus all sessions must have been cryptographically secure.
> + * To assist with this, the initial NULL seed public key name is made
> + * available in a sysfs file.
> + *
> + * Use of these functions:
> + *
> + * The design is all the crypto, hash and hmac gunk is confined in this
> + * file and never needs to be seen even by the kernel internal user. To
> + * the user there's an init function tpm2_sessions_init() that needs to
> + * be called once per TPM which generates the NULL seed primary key.
> + *
> + * These are the usage functions:
> + *
> + * tpm2_start_auth_session() which allocates the opaque auth structure
> + * and gets a session from the TPM. This must be called before
> + * any of the following functions. The session is protected by a
> + * session_key which is derived from a random salt value
> + * encrypted to the NULL seed.
> + * tpm2_end_auth_session() kills the session and frees the resources.
> + * Under normal operation this function is done by
> + * tpm_buf_check_hmac_response(), so this is only to be used on
> + * error legs where the latter is not executed.
> */
>
> #include "tpm.h"
>
> +#include <linux/random.h>
> +#include <linux/scatterlist.h>
> +
> #include <asm/unaligned.h>
>
> #include <crypto/aes.h>
> +#include <crypto/kpp.h>
> +#include <crypto/ecdh.h>
> +#include <crypto/hash.h>
> +#include <crypto/hmac.h>
>
> /* if you change to AES256, you only need change this */
> #define AES_KEYBYTES AES_KEYSIZE_128
>
> #define AES_KEYBITS (AES_KEYBYTES*8)
> +#define AUTH_MAX_NAMES 3
> +
> +/*
> + * This is the structure that carries all the auth information (like
> + * session handle, nonces, session key and auth) from use to use it is
> + * designed to be opaque to anything outside.
> + */
> +struct tpm2_auth {
> + u32 handle;
> + /*
> + * This has two meanings: before tpm_buf_fill_hmac_session()
> + * it marks the offset in the buffer of the start of the
> + * sessions (i.e. after all the handles). Once the buffer has
> + * been filled it markes the session number of our auth
> + * session so we can find it again in the response buffer.
> + *
> + * The two cases are distinguished because the first offset
> + * must always be greater than TPM_HEADER_SIZE and the second
> + * must be less than or equal to 5.
> + */
> + u32 session;
> + /*
> + * the size here is variable and set by the size of our_nonce
> + * which must be between 16 and the name hash length. we set
> + * the maximum sha256 size for the greatest protection
> + */
> + u8 our_nonce[SHA256_DIGEST_SIZE];
> + u8 tpm_nonce[SHA256_DIGEST_SIZE];
> + /*
> + * the salt is only used across the session command/response
> + * after that it can be used as a scratch area
> + */
> + union {
> + u8 salt[EC_PT_SZ];
> + /* scratch for key + IV */
> + u8 scratch[AES_KEYBYTES + AES_BLOCK_SIZE];
> + };
> + u8 session_key[SHA256_DIGEST_SIZE];
> +};
Could this contain also the fields added in the previous patch?
Then obviously this data would be allocated together with chip
but is there hard reason why this needs separate kzalloc and cannot
be always allocated with chip blob?
BR, Jarkko
