[PATCH v0 0/8] Hardware Bound key added to Trusted Key-Ring

[Pankaj Gupta <pankaj.gupta@nxp.com>]

Hardware Bound key(HBK), is never available as a plain key buffer outside of the hardware boundary.
Thus, it is un-usable, even if somehow fetched from kernel memory.
It ensures run-time security.

This patchset establishes a generic bridge between HBK & the kernel's trusted-keyring.
This patchset adds generic support for identifying if the key is HBK.

Note: Copy-paste this text-based block diagram to notepad, for better
clarity.
                      +---------------+
                      |               |
                      |    keyctl     |
                      |               |
                      +-------+-------+
                              |
                              |
      +-----------------------+-------------------------+
      |                trusted keyring                  |
      |                               +---------------+ |
      |   +-----------------+         |trusted-key    | |
      |   |                 |-------->|payload (plain)| |
      |   |                 |         +---------------+ |
      |-->| trusted key     |         +---------------+ |
      |   | source as CAAM  |-------->|  trusted-key  | |
      |   +-----------------+         |  payload (HBK)| |
      |                               +-------^-------+ |
      +---------------------------------------|---------+
                                              |
                                              |
                                              |
 +----------------+  crypt_alloc_tfms +-------|------------------+
 | Kernel         |<------------------|        DM-Crypt          |
 | Crypto-API     |                   | +---------------------+  |
 |                |------------------>| |struct crypto_tfm:   |  |
 +----------------+  crypto_tfm(HBK)  | |- flag-is_hbk        |  |
                                      | |- struct-hbk_info,   |  |
                                      | |is copied from the   |  |
                                      | |tkp structure        |  |
                                      | +---------------------+  |
                                      +------------|-------------+
                                                   |
                                                   |
                                                   |crypto_tfm(HBK)
                                                   |
                                   +---------------|--------------+
                                   | Hardware crypto driver       |
                                   |                              |
                                   | Processing the incoming      |
                                   | key based on the flag        |
                                   | - as plain key, if is_hbk = 0|
                                   | - as HBK, if is_hbk = 1      |
                                   +------------------------------+

Major additions done: (in brief)

- Newly added:
  -- flag-'is_hbk', and
  -- struct hw_bound_key_info hbk_info,
  added to the structures - tfm & trusted key payload.

- Enhanced the 'keyctl' command to generate the hardware bound key
  as trusted key.
  -- at the time of generating the HBK, the values: 'flag - is_hbk'
     & structure 'hbk_info', in the trusted key payload, is set by
     the hw driver, generating or loading the key in the trusted
     key-ring.

- Applications like dm-crypt,
  -- first fetch the key from trusted key-ring. As part of doing this,
     application retains the values of: 'flag - is_hbk' & structure 'hbk_info'.

  -- to use kernel crypto api, after allocating the transformation,
     application sets the 'flag - is_hbk' & structure 'hbk_info', 
     to the tfm allocated from crypto_alloc_tfm().

- Newly added information to tfm, helps to influence the core processing logic
  for the encapsulated algorithm.

First implementation is based on CAAM.

NXP built CAAM IP is the Cryptographic Acceleration and Assurance Module.
This is contain by the i.MX and QorIQ SoCs by NXP.

CAAM is a suitable backend (source) for kernel trusted keys.
This backend source can be used for run-time security as well by generating the hardware bound key.

Along with plain key, the CAAM generates black key. A black key is an encrypted key, which can only be decrypted inside CAAM.
Hence, CAAM's black key can only be used by CAAM. Thus it is declared as a hardware bound key.

Pankaj Gupta (8):
  hw-bound-key: introducing the generic structure
  keys-trusted: new cmd line option added
  crypto: hbk flags & info added to the tfm
  sk_cipher: checking for hw bound operation
  keys-trusted: re-factored caam based trusted key
  KEYS: trusted: caam based black key
  caam alg: symmetric key ciphers are updated
  dm-crypt: consumer-app setting the flag-is_hbk

 crypto/skcipher.c                         |   3 +-
 drivers/crypto/caam/blob_gen.c            | 221 ++++++++++++++++++++--
 drivers/crypto/caam/caamalg.c             |  43 ++++-
 drivers/crypto/caam/caamalg_desc.c        |   8 +-
 drivers/crypto/caam/desc.h                |   8 +-
 drivers/crypto/caam/desc_constr.h         |   6 +-
 drivers/md/dm-crypt.c                     |  12 +-
 include/keys/trusted-type.h               |   4 +
 include/linux/crypto.h                    |   5 +
 include/linux/hw_bound_key.h              |  27 +++
 include/soc/fsl/caam-blob.h               |  38 ++--
 security/keys/trusted-keys/trusted_caam.c |   8 +
 security/keys/trusted-keys/trusted_core.c |  16 ++
 13 files changed, 356 insertions(+), 43 deletions(-)
 create mode 100644 include/linux/hw_bound_key.h

-- 
2.17.1