Hardware Bound key(HBK), is never acessible as plain key outside of the
hardware boundary. Thus, it is un-usable, even if somehow fetched
from kernel memory. It ensures run-time security.
This patchset adds generic support for classing the Hardware Bound Key,
based on:
- Newly added flag-'is_hbk', added to the tfm.
Consumer of the kernel crypto api, after allocating
the transformation, sets this flag based on the basis
of the type of key consumer has.
- This helps to influence the core processing logic
for the encapsulated algorithm.
- This flag is set by the consumer after allocating
the tfm and before calling the function crypto_xxx_setkey().
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):
keys-trusted: new cmd line option added
hw-bound-key: flag-is_hbk added to the tfm
sk_cipher: checking for hw bound operation
keys-trusted: re-factored caam based trusted key
caam blob-gen: moving blob_priv to caam_drv_private
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 | 242 ++++++++++++++++++++--
drivers/crypto/caam/caamalg.c | 37 +++-
drivers/crypto/caam/caamalg_desc.c | 8 +-
drivers/crypto/caam/desc.h | 8 +-
drivers/crypto/caam/desc_constr.h | 6 +-
drivers/crypto/caam/intern.h | 6 +-
drivers/md/dm-crypt.c | 6 +-
include/keys/trusted-type.h | 2 +
include/linux/crypto.h | 2 +
include/soc/fsl/caam-blob.h | 44 ++--
security/keys/trusted-keys/trusted_caam.c | 6 +
security/keys/trusted-keys/trusted_core.c | 14 ++
13 files changed, 333 insertions(+), 51 deletions(-)
--
2.17.1
Re-factored caam based trusted key code:
- Two separate definition for encap and decap having
separate code for creating CAAM job descriptor.
Signed-off-by: Pankaj Gupta <[email protected]>
---
drivers/crypto/caam/blob_gen.c | 122 +++++++++++++++++++++++++++++----
include/soc/fsl/caam-blob.h | 28 +++-----
2 files changed, 118 insertions(+), 32 deletions(-)
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
index 6345c7269eb0..c128a83cc8dd 100644
--- a/drivers/crypto/caam/blob_gen.c
+++ b/drivers/crypto/caam/blob_gen.c
@@ -2,6 +2,7 @@
/*
* Copyright (C) 2015 Pengutronix, Steffen Trumtrar <[email protected]>
* Copyright (C) 2021 Pengutronix, Ahmad Fatoum <[email protected]>
+ * Copyright 2022 NXP, Pankaj Gupta <[email protected]>
*/
#define pr_fmt(fmt) "caam blob_gen: " fmt
@@ -29,10 +30,6 @@
/* Command describing the operation to perform */ \
CAAM_CMD_SZ)
-struct caam_blob_priv {
- struct device jrdev;
-};
-
struct caam_blob_job_result {
int err;
struct completion completion;
@@ -58,8 +55,19 @@ static void caam_blob_job_done(struct device *dev, u32 *desc, u32 err, void *con
complete(&res->completion);
}
-int caam_process_blob(struct caam_blob_priv *priv,
- struct caam_blob_info *info, bool encap)
+
+
+/** caam_encap_blob - encapsulate blob
+ *
+ * @priv: instance returned by caam_blob_gen_init
+ * @info: pointer to blobbing info describing input key,
+ * output blob and key modifier buffers.
+ *
+ * returns 0 and sets info->output_len on success and returns
+ * a negative error code otherwise.
+ */
+int caam_encap_blob(struct caam_blob_priv *priv,
+ struct caam_blob_info *info)
{
struct caam_blob_job_result testres;
struct device *jrdev = &priv->jrdev;
@@ -72,14 +80,102 @@ int caam_process_blob(struct caam_blob_priv *priv,
if (info->key_mod_len > CAAM_BLOB_KEYMOD_LENGTH)
return -EINVAL;
- if (encap) {
- op |= OP_TYPE_ENCAP_PROTOCOL;
- output_len = info->input_len + CAAM_BLOB_OVERHEAD;
- } else {
- op |= OP_TYPE_DECAP_PROTOCOL;
- output_len = info->input_len - CAAM_BLOB_OVERHEAD;
+ op |= OP_TYPE_ENCAP_PROTOCOL;
+ output_len = info->input_len + CAAM_BLOB_OVERHEAD;
+
+ desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
+ if (!desc)
+ return -ENOMEM;
+
+ dma_in = dma_map_single(jrdev, info->input, info->input_len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(jrdev, dma_in)) {
+ dev_err(jrdev, "unable to map input DMA buffer\n");
+ ret = -ENOMEM;
+ goto out_free;
+ }
+
+ dma_out = dma_map_single(jrdev, info->output, output_len,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(jrdev, dma_out)) {
+ dev_err(jrdev, "unable to map output DMA buffer\n");
+ ret = -ENOMEM;
+ goto out_unmap_in;
+ }
+
+ /*
+ * A data blob is encrypted using a blob key (BK); a random number.
+ * The BK is used as an AES-CCM key. The initial block (B0) and the
+ * initial counter (Ctr0) are generated automatically and stored in
+ * Class 1 Context DWords 0+1+2+3. The random BK is stored in the
+ * Class 1 Key Register. Operation Mode is set to AES-CCM.
+ */
+
+ init_job_desc(desc, 0);
+ append_key_as_imm(desc, info->key_mod, info->key_mod_len,
+ info->key_mod_len, CLASS_2 | KEY_DEST_CLASS_REG);
+ append_seq_in_ptr_intlen(desc, dma_in, info->input_len, 0);
+ append_seq_out_ptr_intlen(desc, dma_out, output_len, 0);
+ append_operation(desc, op);
+
+ print_hex_dump_debug("data@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 1, info->input,
+ info->input_len, false);
+ print_hex_dump_debug("jobdesc@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 1, desc,
+ desc_bytes(desc), false);
+
+ testres.err = 0;
+ init_completion(&testres.completion);
+
+ ret = caam_jr_enqueue(jrdev, desc, caam_blob_job_done, &testres);
+ if (ret == -EINPROGRESS) {
+ wait_for_completion(&testres.completion);
+ ret = testres.err;
+ print_hex_dump_debug("output@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 1, info->output,
+ output_len, false);
}
+ if (ret == 0)
+ info->output_len = output_len;
+
+ dma_unmap_single(jrdev, dma_out, output_len, DMA_FROM_DEVICE);
+out_unmap_in:
+ dma_unmap_single(jrdev, dma_in, info->input_len, DMA_TO_DEVICE);
+out_free:
+ kfree(desc);
+
+ return ret;
+}
+EXPORT_SYMBOL(caam_encap_blob);
+
+/** caam_decap_blob - decapsulate blob
+ *
+ * @priv: instance returned by caam_blob_gen_init
+ * @info: pointer to blobbing info describing output key,
+ * input blob and key modifier buffers.
+ *
+ * returns 0 and sets info->output_len on success and returns
+ * a negative error code otherwise.
+ */
+int caam_decap_blob(struct caam_blob_priv *priv,
+ struct caam_blob_info *info)
+{
+ struct caam_blob_job_result testres;
+ struct device *jrdev = &priv->jrdev;
+ dma_addr_t dma_in, dma_out;
+ int op = OP_PCLID_BLOB;
+ size_t output_len;
+ u32 *desc;
+ int ret;
+
+ if (info->key_mod_len > CAAM_BLOB_KEYMOD_LENGTH)
+ return -EINVAL;
+
+ op |= OP_TYPE_DECAP_PROTOCOL;
+ output_len = info->input_len - CAAM_BLOB_OVERHEAD;
+
desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
if (!desc)
return -ENOMEM;
@@ -145,7 +241,7 @@ int caam_process_blob(struct caam_blob_priv *priv,
return ret;
}
-EXPORT_SYMBOL(caam_process_blob);
+EXPORT_SYMBOL(caam_decap_blob);
struct caam_blob_priv *caam_blob_gen_init(void)
{
diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
index 937cac52f36d..632944df29f7 100644
--- a/include/soc/fsl/caam-blob.h
+++ b/include/soc/fsl/caam-blob.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
* Copyright (C) 2020 Pengutronix, Ahmad Fatoum <[email protected]>
+ * Copyright 2022 NXP, Pankaj Gupta <[email protected]>
*/
#ifndef __CAAM_BLOB_GEN
@@ -13,7 +14,10 @@
#define CAAM_BLOB_OVERHEAD (32 + 16)
#define CAAM_BLOB_MAX_LEN 4096
-struct caam_blob_priv;
+struct caam_blob_priv {
+ struct device jrdev;
+};
+
/**
* struct caam_blob_info - information for CAAM blobbing
@@ -72,15 +76,8 @@ int caam_process_blob(struct caam_blob_priv *priv,
* Return: %0 and sets ``info->output_len`` on success and
* a negative error code otherwise.
*/
-static inline int caam_encap_blob(struct caam_blob_priv *priv,
- struct caam_blob_info *info)
-{
- if (info->output_len < info->input_len + CAAM_BLOB_OVERHEAD)
- return -EINVAL;
-
- return caam_process_blob(priv, info, true);
-}
-
+int caam_encap_blob(struct caam_blob_priv *priv,
+ struct caam_blob_info *info);
/**
* caam_decap_blob - decapsulate blob
* @priv: instance returned by caam_blob_gen_init()
@@ -90,14 +87,7 @@ static inline int caam_encap_blob(struct caam_blob_priv *priv,
* Return: %0 and sets ``info->output_len`` on success and
* a negative error code otherwise.
*/
-static inline int caam_decap_blob(struct caam_blob_priv *priv,
- struct caam_blob_info *info)
-{
- if (info->input_len < CAAM_BLOB_OVERHEAD ||
- info->output_len < info->input_len - CAAM_BLOB_OVERHEAD)
- return -EINVAL;
-
- return caam_process_blob(priv, info, false);
-}
+int caam_decap_blob(struct caam_blob_priv *priv,
+ struct caam_blob_info *info);
#endif
--
2.17.1
Consumer of the kernel crypto api, after allocating
the transformation, sets this flag based on the basis
of the type of key consumer has. This helps:
- This helps to influence the core processing logic
for the encapsulated algorithm.
- This flag is set by the consumer after allocating
the tfm and before calling the function crypto_xxx_setkey().
Signed-off-by: Pankaj Gupta <[email protected]>
---
include/linux/crypto.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 2324ab6f1846..b4fa83ca87bd 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -639,6 +639,8 @@ struct crypto_tfm {
u32 crt_flags;
+ unsigned int is_hbk;
+
int node;
void (*exit)(struct crypto_tfm *tfm);
--
2.17.1
caam blob-gen: moving structure blob_priv to structure caam_drv_private.
Signed-off-by: Pankaj Gupta <[email protected]>
---
drivers/crypto/caam/blob_gen.c | 8 ++++----
drivers/crypto/caam/intern.h | 6 +++++-
include/soc/fsl/caam-blob.h | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
index c128a83cc8dd..5164e62f9596 100644
--- a/drivers/crypto/caam/blob_gen.c
+++ b/drivers/crypto/caam/blob_gen.c
@@ -70,7 +70,7 @@ int caam_encap_blob(struct caam_blob_priv *priv,
struct caam_blob_info *info)
{
struct caam_blob_job_result testres;
- struct device *jrdev = &priv->jrdev;
+ struct device *jrdev = priv->jrdev;
dma_addr_t dma_in, dma_out;
int op = OP_PCLID_BLOB;
size_t output_len;
@@ -163,7 +163,7 @@ int caam_decap_blob(struct caam_blob_priv *priv,
struct caam_blob_info *info)
{
struct caam_blob_job_result testres;
- struct device *jrdev = &priv->jrdev;
+ struct device *jrdev = priv->jrdev;
dma_addr_t dma_in, dma_out;
int op = OP_PCLID_BLOB;
size_t output_len;
@@ -267,12 +267,12 @@ struct caam_blob_priv *caam_blob_gen_init(void)
return ERR_PTR(-ENODEV);
}
- return container_of(jrdev, struct caam_blob_priv, jrdev);
+ return &ctrlpriv->blob_priv;
}
EXPORT_SYMBOL(caam_blob_gen_init);
void caam_blob_gen_exit(struct caam_blob_priv *priv)
{
- caam_jr_free(&priv->jrdev);
+ caam_jr_free(priv->jrdev);
}
EXPORT_SYMBOL(caam_blob_gen_exit);
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 572cf66c887a..2fb7df3ffda5 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -4,7 +4,7 @@
* Private/internal definitions between modules
*
* Copyright 2008-2011 Freescale Semiconductor, Inc.
- * Copyright 2019 NXP
+ * Copyright 2019-2022 NXP
*/
#ifndef INTERN_H
@@ -12,6 +12,7 @@
#include "ctrl.h"
#include <crypto/engine.h>
+#include <soc/fsl/caam-blob.h>
/* Currently comes from Kconfig param as a ^2 (driver-required) */
#define JOBR_DEPTH (1 << CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE)
@@ -114,6 +115,9 @@ struct caam_drv_private {
struct dentry *ctl; /* controller dir */
struct debugfs_blob_wrapper ctl_kek_wrap, ctl_tkek_wrap, ctl_tdsk_wrap;
#endif
+#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+ struct caam_blob_priv blob_priv;
+#endif
};
#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API
diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
index 632944df29f7..380b0bcb79dc 100644
--- a/include/soc/fsl/caam-blob.h
+++ b/include/soc/fsl/caam-blob.h
@@ -15,7 +15,7 @@
#define CAAM_BLOB_MAX_LEN 4096
struct caam_blob_priv {
- struct device jrdev;
+ struct device *jrdev;
};
--
2.17.1
- CAAM supports two types of black keys:
-- Plain key encrypted with ECB
-- Plain key encrypted with CCM
Note: Due to robustness, default encytption used for black key is CCM.
- A black key blob is generated, and added to trusted key payload.
This is done as part of sealing operation, that was triggered as a result of:
-- new key generation
-- load key,
Signed-off-by: Pankaj Gupta <[email protected]>
---
drivers/crypto/caam/blob_gen.c | 132 +++++++++++++++++++++++++++++----
drivers/crypto/caam/desc.h | 8 +-
include/soc/fsl/caam-blob.h | 16 ++++
3 files changed, 140 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
index 5164e62f9596..2354e3c6fc61 100644
--- a/drivers/crypto/caam/blob_gen.c
+++ b/drivers/crypto/caam/blob_gen.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "caam blob_gen: " fmt
#include <linux/device.h>
+#include <keys/trusted-type.h>
#include <soc/fsl/caam-blob.h>
#include "compat.h"
@@ -74,8 +75,16 @@ int caam_encap_blob(struct caam_blob_priv *priv,
dma_addr_t dma_in, dma_out;
int op = OP_PCLID_BLOB;
size_t output_len;
+ dma_addr_t dma_blk;
+ u8 *input = info->input;
+ u8 *blk_out;
+ size_t input_len = info->input_len;
u32 *desc;
int ret;
+ int hwbk_caam_ovhd = 0;
+
+ if (info->output_len < info->input_len + CAAM_BLOB_OVERHEAD)
+ return -EINVAL;
if (info->key_mod_len > CAAM_BLOB_KEYMOD_LENGTH)
return -EINVAL;
@@ -83,11 +92,33 @@ int caam_encap_blob(struct caam_blob_priv *priv,
op |= OP_TYPE_ENCAP_PROTOCOL;
output_len = info->input_len + CAAM_BLOB_OVERHEAD;
+ if (info->is_hw_bound == 1) {
+ op |= OP_PCL_BLOB_BLACK;
+ if (priv->hbk_flags & HWBK_FLAGS_CAAM_CCM_ALGO_MASK) {
+ op |= OP_PCL_BLOB_EKT;
+ hwbk_caam_ovhd = CCM_OVERHEAD;
+ }
+
+ if ((input_len + hwbk_caam_ovhd) > MAX_KEY_SIZE)
+ return -EINVAL;
+
+ /* create copy of input buffer */
+ input = kzalloc(info->input_len, GFP_KERNEL | GFP_DMA);
+ if (!input)
+ return -ENOMEM;
+ memcpy(input, info->input, info->input_len);
+
+ /* create hw bound key on input buffer reference */
+ blk_out = info->input;
+
+ info->input_len = input_len + hwbk_caam_ovhd;
+ }
+
desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
if (!desc)
return -ENOMEM;
- dma_in = dma_map_single(jrdev, info->input, info->input_len,
+ dma_in = dma_map_single(jrdev, input, input_len,
DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, dma_in)) {
dev_err(jrdev, "unable to map input DMA buffer\n");
@@ -95,12 +126,26 @@ int caam_encap_blob(struct caam_blob_priv *priv,
goto out_free;
}
+ if (info->is_hw_bound == 1) {
+ dma_blk = dma_map_single(jrdev, blk_out,
+ input_len + hwbk_caam_ovhd,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(jrdev, dma_out)) {
+ dev_err(jrdev, "unable to map output DMA buffer\n");
+ ret = -ENOMEM;
+ goto out_unmap_in;
+ }
+ }
+
dma_out = dma_map_single(jrdev, info->output, output_len,
DMA_FROM_DEVICE);
if (dma_mapping_error(jrdev, dma_out)) {
dev_err(jrdev, "unable to map output DMA buffer\n");
ret = -ENOMEM;
- goto out_unmap_in;
+ if (info->is_hw_bound == 1)
+ goto out_unmap_blk;
+ else
+ goto out_unmap_in;
}
/*
@@ -112,15 +157,40 @@ int caam_encap_blob(struct caam_blob_priv *priv,
*/
init_job_desc(desc, 0);
+
+ if (info->is_hw_bound == 1) {
+ /*!1. key command used to load class 1 key register
+ * from input plain key.
+ */
+ append_key(desc, dma_in, input_len,
+ CLASS_1 | KEY_DEST_CLASS_REG);
+
+ /*!2. Fifostore to store black key from class 1 key register. */
+ append_fifo_store(desc, dma_blk, input_len,
+ LDST_CLASS_1_CCB | FIFOST_TYPE_KEY_CCM_JKEK);
+
+ append_jump(desc, JUMP_COND_NOP | 1);
+ }
+ /*!3. Load class 2 key with key modifier. */
append_key_as_imm(desc, info->key_mod, info->key_mod_len,
info->key_mod_len, CLASS_2 | KEY_DEST_CLASS_REG);
- append_seq_in_ptr_intlen(desc, dma_in, info->input_len, 0);
+
+ /*!4. SEQ IN PTR Command. */
+ if (info->is_hw_bound == 1) {
+ append_seq_in_ptr_intlen(desc, dma_blk, input_len, 0);
+ } else {
+ append_seq_in_ptr_intlen(desc, dma_in, input_len, 0);
+ }
+
+ /*!5. SEQ OUT PTR Command. */
append_seq_out_ptr_intlen(desc, dma_out, output_len, 0);
+
+ /*!6. BlackBlob encapsulation PROTOCOL Command. */
append_operation(desc, op);
print_hex_dump_debug("data@"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 1, info->input,
- info->input_len, false);
+ DUMP_PREFIX_ADDRESS, 16, 1, input,
+ input_len + hwbk_caam_ovhd, false);
print_hex_dump_debug("jobdesc@"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 1, desc,
desc_bytes(desc), false);
@@ -136,15 +206,19 @@ int caam_encap_blob(struct caam_blob_priv *priv,
DUMP_PREFIX_ADDRESS, 16, 1, info->output,
output_len, false);
}
-
- if (ret == 0)
+ if (ret == 0) {
info->output_len = output_len;
-
+ }
dma_unmap_single(jrdev, dma_out, output_len, DMA_FROM_DEVICE);
+out_unmap_blk:
+ if (info->is_hw_bound == 1) {
+ dma_unmap_single(jrdev, dma_blk, info->input_len, DMA_TO_DEVICE);
+ }
out_unmap_in:
dma_unmap_single(jrdev, dma_in, info->input_len, DMA_TO_DEVICE);
out_free:
kfree(desc);
+ kfree(input);
return ret;
}
@@ -168,13 +242,41 @@ int caam_decap_blob(struct caam_blob_priv *priv,
int op = OP_PCLID_BLOB;
size_t output_len;
u32 *desc;
+ u8 *output = info->output;
int ret;
+ int hwbk_caam_ovhd = 0;
+
+ if (info->input_len < CAAM_BLOB_OVERHEAD)
+ return -EINVAL;
if (info->key_mod_len > CAAM_BLOB_KEYMOD_LENGTH)
return -EINVAL;
op |= OP_TYPE_DECAP_PROTOCOL;
output_len = info->input_len - CAAM_BLOB_OVERHEAD;
+ info->output_len = output_len;
+
+ if (info->is_hw_bound == 1) {
+ op |= OP_PCL_BLOB_BLACK;
+ if (priv->hbk_flags & HWBK_FLAGS_CAAM_CCM_ALGO_MASK) {
+ op |= OP_PCL_BLOB_EKT;
+ hwbk_caam_ovhd = CCM_OVERHEAD;
+ }
+
+ if ((output_len + hwbk_caam_ovhd) > MAX_KEY_SIZE)
+ return -EINVAL;
+
+ /* In case of HW Bound Key, lengths have different purpose:
+ * - output_len = HW encrypted key length.
+ * - info->output_len = Length of HW Bound Key Payload
+ * (Payload = Header + outlen)
+ */
+ info->output_len = output_len + hwbk_caam_ovhd;
+
+ output_len += hwbk_caam_ovhd;
+
+ output = info->output;
+ }
desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
if (!desc)
@@ -188,7 +290,7 @@ int caam_decap_blob(struct caam_blob_priv *priv,
goto out_free;
}
- dma_out = dma_map_single(jrdev, info->output, output_len,
+ dma_out = dma_map_single(jrdev, output, output_len,
DMA_FROM_DEVICE);
if (dma_mapping_error(jrdev, dma_out)) {
dev_err(jrdev, "unable to map output DMA buffer\n");
@@ -207,8 +309,8 @@ int caam_decap_blob(struct caam_blob_priv *priv,
init_job_desc(desc, 0);
append_key_as_imm(desc, info->key_mod, info->key_mod_len,
info->key_mod_len, CLASS_2 | KEY_DEST_CLASS_REG);
- append_seq_in_ptr_intlen(desc, dma_in, info->input_len, 0);
- append_seq_out_ptr_intlen(desc, dma_out, output_len, 0);
+ append_seq_in_ptr(desc, dma_in, info->input_len, 0);
+ append_seq_out_ptr(desc, dma_out, output_len, 0);
append_operation(desc, op);
print_hex_dump_debug("data@"__stringify(__LINE__)": ",
@@ -226,13 +328,10 @@ int caam_decap_blob(struct caam_blob_priv *priv,
wait_for_completion(&testres.completion);
ret = testres.err;
print_hex_dump_debug("output@"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 1, info->output,
+ DUMP_PREFIX_ADDRESS, 16, 1, output,
output_len, false);
}
- if (ret == 0)
- info->output_len = output_len;
-
dma_unmap_single(jrdev, dma_out, output_len, DMA_FROM_DEVICE);
out_unmap_in:
dma_unmap_single(jrdev, dma_in, info->input_len, DMA_TO_DEVICE);
@@ -267,6 +366,9 @@ struct caam_blob_priv *caam_blob_gen_init(void)
return ERR_PTR(-ENODEV);
}
+ ctrlpriv->blob_priv.hbk_flags = HWBK_FLAGS_CAAM_CCM_ALGO_MASK;
+ ctrlpriv->blob_priv.jrdev = jrdev;
+
return &ctrlpriv->blob_priv;
}
EXPORT_SYMBOL(caam_blob_gen_init);
diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index e13470901586..41b2d0226bdf 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -4,7 +4,7 @@
* Definitions to support CAAM descriptor instruction generation
*
* Copyright 2008-2011 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018-2022 NXP
*/
#ifndef DESC_H
@@ -403,6 +403,7 @@
#define FIFOST_TYPE_PKHA_N (0x08 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_A (0x0c << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_B (0x0d << FIFOST_TYPE_SHIFT)
+#define FIFOST_TYPE_KEY_CCM_JKEK (0x14 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_AF_SBOX_JKEK (0x20 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_AF_SBOX_TKEK (0x21 << FIFOST_TYPE_SHIFT)
#define FIFOST_TYPE_PKHA_E_JKEK (0x22 << FIFOST_TYPE_SHIFT)
@@ -1001,6 +1002,11 @@
#define OP_PCL_TLS12_AES_256_CBC_SHA384 0xff63
#define OP_PCL_TLS12_AES_256_CBC_SHA512 0xff65
+/* Blob protocol protinfo bits */
+
+#define OP_PCL_BLOB_BLACK 0x0004
+#define OP_PCL_BLOB_EKT 0x0100
+
/* For DTLS - OP_PCLID_DTLS */
#define OP_PCL_DTLS_AES_128_CBC_SHA 0x002f
diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
index 380b0bcb79dc..ae2c2a6c8c23 100644
--- a/include/soc/fsl/caam-blob.h
+++ b/include/soc/fsl/caam-blob.h
@@ -10,12 +10,26 @@
#include <linux/types.h>
#include <linux/errno.h>
+#define HWBK_FLAGS_CAAM_CCM_ALGO_MASK 0x01
+
+/*
+ * CCM-Black Key will always be at least 12 bytes longer,
+ * since the encapsulation uses a 6-byte nonce and adds
+ * a 6-byte ICV. But first, the key is padded as necessary so
+ * that CCM-Black Key is a multiple of 8 bytes long.
+ */
+#define NONCE_SIZE 6
+#define ICV_SIZE 6
+#define CCM_OVERHEAD (NONCE_SIZE + ICV_SIZE)
#define CAAM_BLOB_KEYMOD_LENGTH 16
#define CAAM_BLOB_OVERHEAD (32 + 16)
#define CAAM_BLOB_MAX_LEN 4096
struct caam_blob_priv {
struct device *jrdev;
+ /* Flags: whether generated trusted key, is ECB or CCM encrypted.*/
+ uint8_t hbk_flags;
+ uint8_t rsv[3];
};
@@ -38,6 +52,8 @@ struct caam_blob_info {
const void *key_mod;
size_t key_mod_len;
+
+ const char is_hw_bound;
};
/**
--
2.17.1
Changes to enable:
- To work both with black key and plain key.
- It is supported in context of symmetric key ciphers only.
- Based on as crypto layer's flag: tfm->is_hbk, handling for
h/w bound key is done.
- Otherwise, work as previously.
Signed-off-by: Pankaj Gupta <[email protected]>
---
drivers/crypto/caam/caamalg.c | 37 ++++++++++++++++++++++++++++--
drivers/crypto/caam/caamalg_desc.c | 8 ++++---
drivers/crypto/caam/desc_constr.h | 6 ++++-
3 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index d3d8bb0a6990..2c96aecab627 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -3,7 +3,7 @@
* caam - Freescale FSL CAAM support for crypto API
*
* Copyright 2008-2011 Freescale Semiconductor, Inc.
- * Copyright 2016-2019 NXP
+ * Copyright 2016-2022 NXP
*
* Based on talitos crypto API driver.
*
@@ -59,6 +59,7 @@
#include <crypto/engine.h>
#include <crypto/xts.h>
#include <asm/unaligned.h>
+#include <soc/fsl/caam-blob.h>
/*
* crypto alg
@@ -734,6 +735,7 @@ static int skcipher_setkey(struct crypto_skcipher *skcipher, const u8 *key,
container_of(crypto_skcipher_alg(skcipher), typeof(*alg),
skcipher);
struct device *jrdev = ctx->jrdev;
+ struct caam_drv_private *ctrlpriv;
unsigned int ivsize = crypto_skcipher_ivsize(skcipher);
u32 *desc;
const bool is_rfc3686 = alg->caam.rfc3686;
@@ -741,9 +743,26 @@ static int skcipher_setkey(struct crypto_skcipher *skcipher, const u8 *key,
print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+ /* Here keylen is actual key length */
ctx->cdata.keylen = keylen;
ctx->cdata.key_virt = key;
ctx->cdata.key_inline = true;
+ /* Here real key len is plain key length */
+ ctx->cdata.key_real_len = keylen;
+ ctx->cdata.key_cmd_opt = 0;
+
+ /* check if the key is HBK */
+ if (skcipher->base.is_hbk) {
+ ctrlpriv = dev_get_drvdata(jrdev->parent);
+ ctx->cdata.key_cmd_opt |= KEY_ENC;
+
+ /* check if the HBK is CCM key */
+ if (ctrlpriv->blob_priv.hbk_flags
+ & HWBK_FLAGS_CAAM_CCM_ALGO_MASK) {
+ ctx->cdata.key_cmd_opt |= KEY_EKT;
+ ctx->cdata.key_real_len = keylen - CCM_OVERHEAD;
+ }
+ }
/* skcipher_encrypt shared descriptor */
desc = ctx->sh_desc_enc;
@@ -766,8 +785,22 @@ static int aes_skcipher_setkey(struct crypto_skcipher *skcipher,
const u8 *key, unsigned int keylen)
{
int err;
+ int overhead = 0;
+ struct caam_ctx *ctx;
+ struct device *jrdev;
+ struct caam_drv_private *ctrlpriv;
+
+ if (skcipher->base.is_hbk) {
+ ctx = crypto_skcipher_ctx(skcipher);
+ jrdev = ctx->jrdev;
+ ctrlpriv = dev_get_drvdata(jrdev->parent);
+ if (ctrlpriv->blob_priv.hbk_flags
+ & HWBK_FLAGS_CAAM_CCM_ALGO_MASK)
+ overhead += CCM_OVERHEAD;
+ }
+
+ err = aes_check_keylen((keylen - overhead));
- err = aes_check_keylen(keylen);
if (err)
return err;
diff --git a/drivers/crypto/caam/caamalg_desc.c b/drivers/crypto/caam/caamalg_desc.c
index 7571e1ac913b..784acae8c9b7 100644
--- a/drivers/crypto/caam/caamalg_desc.c
+++ b/drivers/crypto/caam/caamalg_desc.c
@@ -2,7 +2,7 @@
/*
* Shared descriptors for aead, skcipher algorithms
*
- * Copyright 2016-2019 NXP
+ * Copyright 2016-2022 NXP
*/
#include "compat.h"
@@ -1391,7 +1391,8 @@ void cnstr_shdsc_skcipher_encap(u32 * const desc, struct alginfo *cdata,
/* Load class1 key only */
append_key_as_imm(desc, cdata->key_virt, cdata->keylen,
- cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG);
+ cdata->key_real_len, CLASS_1 | KEY_DEST_CLASS_REG
+ | cdata->key_cmd_opt);
/* Load nonce into CONTEXT1 reg */
if (is_rfc3686) {
@@ -1466,7 +1467,8 @@ void cnstr_shdsc_skcipher_decap(u32 * const desc, struct alginfo *cdata,
/* Load class1 key only */
append_key_as_imm(desc, cdata->key_virt, cdata->keylen,
- cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG);
+ cdata->key_real_len, CLASS_1 | KEY_DEST_CLASS_REG
+ | cdata->key_cmd_opt);
/* Load nonce into CONTEXT1 reg */
if (is_rfc3686) {
diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h
index 62ce6421bb3f..d652bdbf3f91 100644
--- a/drivers/crypto/caam/desc_constr.h
+++ b/drivers/crypto/caam/desc_constr.h
@@ -3,7 +3,7 @@
* caam descriptor construction helper functions
*
* Copyright 2008-2012 Freescale Semiconductor, Inc.
- * Copyright 2019 NXP
+ * Copyright 2019-2022 NXP
*/
#ifndef DESC_CONSTR_H
@@ -500,6 +500,8 @@ do { \
* @key_virt: virtual address where algorithm key resides
* @key_inline: true - key can be inlined in the descriptor; false - key is
* referenced by the descriptor
+ * @key_real_len: size of the key to be loaded by the CAAM
+ * @key_cmd_opt: optional parameters for KEY command
*/
struct alginfo {
u32 algtype;
@@ -508,6 +510,8 @@ struct alginfo {
dma_addr_t key_dma;
const void *key_virt;
bool key_inline;
+ u32 key_real_len;
+ u32 key_cmd_opt;
};
/**
--
2.17.1
Consumer application:
- Adding a flag 'is_hbk', in its "struct crypto_config".
- After fetching the keys, it is setting the above
mentioned flag, based on the key fetched.
-- Note: Supported for trusted keys only.
- After allocating the tfm, and before calling
crypto_xxx_setkey(), setting the tfm flag 'is_hbk':
cc->cipher_tfm.tfms[i]->base.is_hbk = cc->is_hbk;
-- Note: Supported for symmetric-key ciphers only.
Signed-off-by: Pankaj Gupta <[email protected]>
---
drivers/md/dm-crypt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 159c6806c19b..12b400e06cbf 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -221,6 +221,7 @@ struct crypt_config {
struct mutex bio_alloc_lock;
u8 *authenc_key; /* space for keys in authenc() format (if used) */
+ unsigned int is_hbk;
u8 key[];
};
@@ -2397,10 +2398,12 @@ static int crypt_setkey(struct crypt_config *cc)
r = crypto_aead_setkey(cc->cipher_tfm.tfms_aead[i],
cc->key + (i * subkey_size),
subkey_size);
- else
+ else {
+ cc->cipher_tfm.tfms[i]->base.is_hbk = cc->is_hbk;
r = crypto_skcipher_setkey(cc->cipher_tfm.tfms[i],
cc->key + (i * subkey_size),
subkey_size);
+ }
if (r)
err = r;
}
@@ -2461,6 +2464,7 @@ static int set_key_trusted(struct crypt_config *cc, struct key *key)
if (!tkp)
return -EKEYREVOKED;
+ cc->is_hbk = tkp->is_hw_bound;
if (cc->key_size != tkp->key_len)
return -EINVAL;
--
2.17.1
On Tue, Sep 06, 2022 at 12:21:51PM +0530, Pankaj Gupta wrote:
> Consumer of the kernel crypto api, after allocating
> the transformation, sets this flag based on the basis
> of the type of key consumer has. This helps:
>
> - This helps to influence the core processing logic
> for the encapsulated algorithm.
> - This flag is set by the consumer after allocating
> the tfm and before calling the function crypto_xxx_setkey().
>
> Signed-off-by: Pankaj Gupta <[email protected]>
> ---
> include/linux/crypto.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 2324ab6f1846..b4fa83ca87bd 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -639,6 +639,8 @@ struct crypto_tfm {
>
> u32 crt_flags;
>
> + unsigned int is_hbk;
> +
We already have plenty of drivers with hardware keys in the tree.
Plesae explain why the current support is inadequate and you need
to do this.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi,
Am 2022-09-06 08:51, schrieb Pankaj Gupta:
> Hardware Bound key(HBK), is never acessible as plain key outside of the
> hardware boundary. Thus, it is un-usable, even if somehow fetched
> from kernel memory. It ensures run-time security.
>
> This patchset adds generic support for classing the Hardware Bound Key,
> based on:
>
> - Newly added flag-'is_hbk', added to the tfm.
>
> Consumer of the kernel crypto api, after allocating
> the transformation, sets this flag based on the basis
> of the type of key consumer has.
>
> - This helps to influence the core processing logic
> for the encapsulated algorithm.
>
> - This flag is set by the consumer after allocating
> the tfm and before calling the function crypto_xxx_setkey().
>
> 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.
What is the difference to the current trusted keys with CAAM?
When I tested the patch series back then, I wasn't able to import
a sealed key on another board with the same SoC.
-michael
On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> Hardware Bound key(HBK), is never acessible as plain key outside of the
~~~~~~~~~
accesible.
> hardware boundary. Thus, it is un-usable, even if somehow fetched
> from kernel memory. It ensures run-time security.
Why is it called "HBK" here and "hw" in the context of keyctl?
> This patchset adds generic support for classing the Hardware Bound Key,
> based on:
>
> - Newly added flag-'is_hbk', added to the tfm.
>
> Consumer of the kernel crypto api, after allocating
> the transformation, sets this flag based on the basis
> of the type of key consumer has.
>
> - This helps to influence the core processing logic
> for the encapsulated algorithm.
>
> - This flag is set by the consumer after allocating
> the tfm and before calling the function crypto_xxx_setkey().
>
> First implementation is based on CAAM.
CAAM is implementation of what exactly?
I'm sorry but I don't know your definition of unusable.
BR, Jarkko
On Tue, Sep 06, 2022 at 12:21:55 +0530, Pankaj Gupta wrote:
> - CAAM supports two types of black keys:
What is a "black key"?
> -- Plain key encrypted with ECB
> -- Plain key encrypted with CCM
> Note: Due to robustness, default encytption used for black key is CCM.
^^^^^^^^^^
"encryption"
> - A black key blob is generated, and added to trusted key payload.
Missing "the" before "trusted".
--Ben
> -----Original Message-----
> From: Michael Walle <[email protected]>
> Sent: Tuesday, September 6, 2022 12:43 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; Sahil Malhotra
> <[email protected]>; Kshitiz Varshney <[email protected]>;
> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>
> Caution: EXT Email
>
> Hi,
>
> Am 2022-09-06 08:51, schrieb Pankaj Gupta:
> > Hardware Bound key(HBK), is never acessible as plain key outside of
> > the hardware boundary. Thus, it is un-usable, even if somehow fetched
> > from kernel memory. It ensures run-time security.
> >
> > This patchset adds generic support for classing the Hardware Bound
> > Key, based on:
> >
> > - Newly added flag-'is_hbk', added to the tfm.
> >
> > Consumer of the kernel crypto api, after allocating
> > the transformation, sets this flag based on the basis
> > of the type of key consumer has.
> >
> > - This helps to influence the core processing logic
> > for the encapsulated algorithm.
> >
> > - This flag is set by the consumer after allocating
> > the tfm and before calling the function crypto_xxx_setkey().
> >
> > 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.
>
> What is the difference to the current trusted keys with CAAM?
> When I tested the patch series back then, I wasn't able to import a sealed
> key on another board with the same SoC.
>
Currently, keys that are part of trusted key-ring, contains plain key.
With this patch-set, these key will become Hw Bound Key, which is not a plain key anymore.
After this patch-set, if somehow the HB-key is retrieved from the keyring, the retrieved key would be un-usable without hw.
> -michael
> -----Original Message-----
> From: Herbert Xu <[email protected]>
> Sent: Tuesday, September 6, 2022 12:13 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; Sahil Malhotra
> <[email protected]>; Kshitiz Varshney <[email protected]>;
> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
> Subject: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added to
> the tfm
>
> Caution: EXT Email
>
> On Tue, Sep 06, 2022 at 12:21:51PM +0530, Pankaj Gupta wrote:
> > Consumer of the kernel crypto api, after allocating the
> > transformation, sets this flag based on the basis of the type of key
> > consumer has. This helps:
> >
> > - This helps to influence the core processing logic
> > for the encapsulated algorithm.
> > - This flag is set by the consumer after allocating
> > the tfm and before calling the function crypto_xxx_setkey().
> >
> > Signed-off-by: Pankaj Gupta <[email protected]>
> > ---
> > include/linux/crypto.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/crypto.h b/include/linux/crypto.h index
> > 2324ab6f1846..b4fa83ca87bd 100644
> > --- a/include/linux/crypto.h
> > +++ b/include/linux/crypto.h
> > @@ -639,6 +639,8 @@ struct crypto_tfm {
> >
> > u32 crt_flags;
> >
> > + unsigned int is_hbk;
> > +
>
> We already have plenty of drivers with hardware keys in the tree.
> Plesae explain why the current support is inadequate and you need to do
> this.
>
Current support, does not permit the hardware to support both types of keys: HBK & Plain Key, at the same time.
This change is generic and permit any driver that supports both- HBK and plain-key, to differentiate and use the keys accordingly.
> Thanks,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2F&data=05%7C01%7Cpankaj.gupta%40nx
> p.com%7Cffd6105be88e4b82546c08da8fd33b6e%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637980434686220485%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&sdata=AErrjpwh%2FRZSCNDDbtH%2FWW
> %2B39J%2FrxPJwak2X2Fk%2BWBg%3D&reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7Cpankaj.g
> upta%40nxp.com%7Cffd6105be88e4b82546c08da8fd33b6e%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C637980434686220485%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F7axxa8nrYDiItrwcZi
> AfRTVc%2F25Ln5IgUzr%2F1uK%2FNk%3D&reserved=0
> -----Original Message-----
> From: Jarkko Sakkinen <[email protected]>
> Sent: Tuesday, September 6, 2022 2:28 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; Sahil Malhotra
> <[email protected]>; Kshitiz Varshney <[email protected]>;
> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>
> Caution: EXT Email
>
> On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> > Hardware Bound key(HBK), is never acessible as plain key outside of
> > the
> ~~~~~~~~~
> accesible.
>
> > hardware boundary. Thus, it is un-usable, even if somehow fetched from
> > kernel memory. It ensures run-time security.
>
> Why is it called "HBK" here and "hw" in the context of keyctl?
It is HBK, because the key is bounded to the Hardware. As:
- Key is generated by hardware.
- Key can only be used by hardware.
- Stored as a blob by the hardware.
>
> > This patchset adds generic support for classing the Hardware Bound
> > Key, based on:
> >
> > - Newly added flag-'is_hbk', added to the tfm.
> >
> > Consumer of the kernel crypto api, after allocating
> > the transformation, sets this flag based on the basis
> > of the type of key consumer has.
> >
> > - This helps to influence the core processing logic
> > for the encapsulated algorithm.
> >
> > - This flag is set by the consumer after allocating
> > the tfm and before calling the function crypto_xxx_setkey().
> >
> > First implementation is based on CAAM.
>
> CAAM is implementation of what exactly?
CAAM is the chip's cryptographic acceleration and offloading hardware and combines cryptographic and other mathematical
functions to create a modular and scalable hardware acceleration and assurance engine. In context to this patchset, CAAM implements the following functions:
- Generates HBK
- Generates key-blob, from HBK, for security at rest.
- Perform crypto operations, using HBK.
>
> I'm sorry but I don't know your definition of unusable.
Even if somehow the key is retrieved from the keyring, the retrieved key would be an encrypted key.
This encrypted key can only be decrypted by Hardware, which generated it.
Hence, the retrieved key is unusable outside of the hardware.
>
> BR, Jarkko
> -----Original Message-----
> From: Ben Boeckel <[email protected]>
> Sent: Tuesday, September 6, 2022 6:34 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-security-
> [email protected]; Sahil Malhotra <[email protected]>; Kshitiz
> Varshney <[email protected]>; Horia Geanta
> <[email protected]>; Varun Sethi <[email protected]>
> Subject: [EXT] Re: [RFC PATCH HBK: 6/8] KEYS: trusted: caam based black key
>
> Caution: EXT Email
>
> On Tue, Sep 06, 2022 at 12:21:55 +0530, Pankaj Gupta wrote:
> > - CAAM supports two types of black keys:
>
> What is a "black key"?
This needs to be changed to Hardware Bound Key.
Black Key is NXP terminology for Hardware Bound Key.
>
> > -- Plain key encrypted with ECB
> > -- Plain key encrypted with CCM
> > Note: Due to robustness, default encytption used for black key is CCM.
> ^^^^^^^^^^
>
> "encryption"
Accepted
>
> > - A black key blob is generated, and added to trusted key payload.
>
> Missing "the" before "trusted".
>
Accepted
> --Ben
On Wed, Sep 07, 2022 at 07:22:42AM +0000, Pankaj Gupta wrote:
>
> Current support, does not permit the hardware to support both types of keys: HBK & Plain Key, at the same time.
>
> This change is generic and permit any driver that supports both- HBK and plain-key, to differentiate and use the keys accordingly.
Existing drivers simply register hardware keys under a different
algorithm name, there is no reason why they can't coexist with a
plain key.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>> -----Original Message-----
>> From: Michael Walle <[email protected]>
>> Sent: Tuesday, September 6, 2022 12:43 PM
>> To: Pankaj Gupta <[email protected]>
>> Cc: [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected];
>> [email protected]; [email protected]; linux-
>> [email protected]; Sahil Malhotra
>> <[email protected]>; Kshitiz Varshney <[email protected]>;
>> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
>> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>>
>> Caution: EXT Email
>>
>> Hi,
>>
>> Am 2022-09-06 08:51, schrieb Pankaj Gupta:
>> > Hardware Bound key(HBK), is never acessible as plain key outside of
>> > the hardware boundary. Thus, it is un-usable, even if somehow fetched
>> > from kernel memory. It ensures run-time security.
>> >
>> > This patchset adds generic support for classing the Hardware Bound
>> > Key, based on:
>> >
>> > - Newly added flag-'is_hbk', added to the tfm.
>> >
>> > Consumer of the kernel crypto api, after allocating
>> > the transformation, sets this flag based on the basis
>> > of the type of key consumer has.
>> >
>> > - This helps to influence the core processing logic
>> > for the encapsulated algorithm.
>> >
>> > - This flag is set by the consumer after allocating
>> > the tfm and before calling the function crypto_xxx_setkey().
>> >
>> > 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.
>>
>> What is the difference to the current trusted keys with CAAM?
>> When I tested the patch series back then, I wasn't able to import a
>> sealed
>> key on another board with the same SoC.
>>
>
> Currently, keys that are part of trusted key-ring, contains plain key.
>
> With this patch-set, these key will become Hw Bound Key, which is not
> a plain key anymore.
> After this patch-set, if somehow the HB-key is retrieved from the
> keyring, the retrieved key would be un-usable without hw.
This doesn't answer my question why I couldn't import one key on
another board with the same SoC.
Ahmad (as you were the author of the original series), is this supposed
to work or is the seal export already encrypted with the per SoC key?
-michael
Hi Michael,
> On 07.09.2022, at 09:29, Michael Walle <[email protected]> wrote:
>
> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>>> -----Original Message-----
>>> From: Michael Walle <[email protected]>
>>> Sent: Tuesday, September 6, 2022 12:43 PM
>>> To: Pankaj Gupta <[email protected]>
>>> Cc: [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]; linux-
>>> [email protected]; Sahil Malhotra
>>> <[email protected]>; Kshitiz Varshney <[email protected]>;
>>> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
>>> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>>> Caution: EXT Email
>>> Hi,
>>> Am 2022-09-06 08:51, schrieb Pankaj Gupta:
>>> > Hardware Bound key(HBK), is never acessible as plain key outside of
>>> > the hardware boundary. Thus, it is un-usable, even if somehow fetched
>>> > from kernel memory. It ensures run-time security.
>>> >
>>> > This patchset adds generic support for classing the Hardware Bound
>>> > Key, based on:
>>> >
>>> > - Newly added flag-'is_hbk', added to the tfm.
>>> >
>>> > Consumer of the kernel crypto api, after allocating
>>> > the transformation, sets this flag based on the basis
>>> > of the type of key consumer has.
>>> >
>>> > - This helps to influence the core processing logic
>>> > for the encapsulated algorithm.
>>> >
>>> > - This flag is set by the consumer after allocating
>>> > the tfm and before calling the function crypto_xxx_setkey().
>>> >
>>> > 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.
>>> What is the difference to the current trusted keys with CAAM?
>>> When I tested the patch series back then, I wasn't able to import a sealed
>>> key on another board with the same SoC.
>> Currently, keys that are part of trusted key-ring, contains plain key.
>> With this patch-set, these key will become Hw Bound Key, which is not
>> a plain key anymore.
>> After this patch-set, if somehow the HB-key is retrieved from the
>> keyring, the retrieved key would be un-usable without hw.
>
> This doesn't answer my question why I couldn't import one key on
> another board with the same SoC.
I don’t believe this is intended to work this way. Each key blob created by CAAM is bound
to a specific device. Being able to decrypt the same blob on another SoC would
open up some attack vectors: Think of a locked down device where I’m able to
extract this key blob. Simply buying a board with the same Soc would allow me to
decrypt this blob by copying it over to my board.
Roughly speaking, CAAM key blobs are secure using a key derived from the device’s master
key. This master key can be programmed via eFUSEs. So you’d have to burn the same master
key on both SoCs and it should work.
In any way, check the security reference manual for your SoC. It should explain this in more detail.
- David
On Wed, 2022-09-07 at 07:22 +0000, Pankaj Gupta wrote:
> Even if somehow the key is retrieved from the keyring, the retrieved key
> would be an encrypted key.
> This encrypted key can only be decrypted by Hardware, which generated it.
>
> Hence, the retrieved key is unusable outside of the hardware.
NXP's CAAM unit (i.e. on i.MX6) supports several modes of sealed/encrypted keys.
The (un)sealing process uses a key that is normally derived from a per-device
key in eFUSES. One aspect of these modes is whether the plaintext key material
is accessible to the kernel or not.
Ahmad's patch set added support for a mode where the CAAM is used to seal
plaintext known to the kernel to a "blob" (in CAAM terminology) on export to
userspace and the reverse on import. This mode allows the kernel to use the
plaintext for dm-crypt, to encrypt other keyrings and similar.
The CAAM has another sealing mode, where it will not allow writing of the
plaintext key to memory. Instead, it is kept in one of the CAAM-internal key
registers. There, it can be used for cryptographic operations (i.e. AES). This
way, the plaintext key is protected even from the kernel. The kernel could keep
a copy of in sealed form, so it can reload the CAAM's key register when needed.
Pankaj, is that the mode you intend to support with this series?
Could you describe the high-level use-cases this would be need for, compared to
the existing mode where plaintext keys are accessible to the kernel? In which
cases would you use each mode?
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi David,
Am 2022-09-07 09:46, schrieb David Gstir:
>> On 07.09.2022, at 09:29, Michael Walle <[email protected]> wrote:
>>
>> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
>>>> -----Original Message-----
>>>> From: Michael Walle <[email protected]>
>>>> Sent: Tuesday, September 6, 2022 12:43 PM
>>>> To: Pankaj Gupta <[email protected]>
>>>> Cc: [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected]; [email protected];
>>>> [email protected]; [email protected];
>>>> [email protected];
>>>> [email protected]; [email protected];
>>>> linux-
>>>> [email protected]; Sahil Malhotra
>>>> <[email protected]>; Kshitiz Varshney
>>>> <[email protected]>;
>>>> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
>>>> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>>>> Caution: EXT Email
>>>> Hi,
>>>> Am 2022-09-06 08:51, schrieb Pankaj Gupta:
>>>> > Hardware Bound key(HBK), is never acessible as plain key outside of
>>>> > the hardware boundary. Thus, it is un-usable, even if somehow fetched
>>>> > from kernel memory. It ensures run-time security.
>>>> >
>>>> > This patchset adds generic support for classing the Hardware Bound
>>>> > Key, based on:
>>>> >
>>>> > - Newly added flag-'is_hbk', added to the tfm.
>>>> >
>>>> > Consumer of the kernel crypto api, after allocating
>>>> > the transformation, sets this flag based on the basis
>>>> > of the type of key consumer has.
>>>> >
>>>> > - This helps to influence the core processing logic
>>>> > for the encapsulated algorithm.
>>>> >
>>>> > - This flag is set by the consumer after allocating
>>>> > the tfm and before calling the function crypto_xxx_setkey().
>>>> >
>>>> > 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.
>>>> What is the difference to the current trusted keys with CAAM?
>>>> When I tested the patch series back then, I wasn't able to import a
>>>> sealed
>>>> key on another board with the same SoC.
>>> Currently, keys that are part of trusted key-ring, contains plain
>>> key.
>>> With this patch-set, these key will become Hw Bound Key, which is not
>>> a plain key anymore.
>>> After this patch-set, if somehow the HB-key is retrieved from the
>>> keyring, the retrieved key would be un-usable without hw.
>>
>> This doesn't answer my question why I couldn't import one key on
>> another board with the same SoC.
>
> I don’t believe this is intended to work this way. Each key blob
> created by CAAM is bound
> to a specific device. Being able to decrypt the same blob on another
> SoC would
> open up some attack vectors: Think of a locked down device where I’m
> able to
> extract this key blob. Simply buying a board with the same Soc would
> allow me to
> decrypt this blob by copying it over to my board.
I agree, thus my first question here was, what this series is adding,
if the key is already "bound" to the hardware. That is what I don't
understand.
-michael
> Roughly speaking, CAAM key blobs are secure using a key derived from
> the device’s master
> key. This master key can be programmed via eFUSEs. So you’d have to
> burn the same master
> key on both SoCs and it should work.
>
> In any way, check the security reference manual for your SoC. It
> should explain this in more detail.
> -----Original Message-----
> From: Michael Walle <[email protected]>
> Sent: Wednesday, September 7, 2022 1:42 PM
> To: David Gstir <[email protected]>
> Cc: Pankaj Gupta <[email protected]>; Ahmad Fatoum
> <[email protected]>; Jarkko Sakkinen <[email protected]>;
> [email protected]; James Bottomley <[email protected]>; Mimi Zohar
> <[email protected]>; David Howells <[email protected]>; Sumit
> Garg <[email protected]>; [email protected]; James Morris
> <[email protected]>; Serge E. Hallyn <[email protected]>; Herbert Xu
> <[email protected]>; David S. Miller <[email protected]>;
> Jan Luebbe <[email protected]>; Eric Biggers <[email protected]>;
> Richard Weinberger <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; Sahil
> Malhotra <[email protected]>; Kshitiz Varshney
> <[email protected]>; Horia Geanta <[email protected]>;
> Varun Sethi <[email protected]>
> Subject: Re: [EXT] [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>
> Caution: EXT Email
>
> Hi David,
>
> Am 2022-09-07 09:46, schrieb David Gstir:
> >> On 07.09.2022, at 09:29, Michael Walle <[email protected]> wrote:
> >>
> >> Am 2022-09-07 09:22, schrieb Pankaj Gupta:
> >>>> -----Original Message-----
> >>>> From: Michael Walle <[email protected]>
> >>>> Sent: Tuesday, September 6, 2022 12:43 PM
> >>>> To: Pankaj Gupta <[email protected]>
> >>>> Cc: [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected]; [email protected];
> >>>> [email protected];
> >>>> linux-
> >>>> [email protected]; Sahil Malhotra
> >>>> <[email protected]>; Kshitiz Varshney
> >>>> <[email protected]>; Horia Geanta <[email protected]>;
> >>>> Varun Sethi <[email protected]>
> >>>> Subject: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED
> KEY
> >>>> Caution: EXT Email
> >>>> Hi,
> >>>> Am 2022-09-06 08:51, schrieb Pankaj Gupta:
> >>>> > Hardware Bound key(HBK), is never acessible as plain key outside
> >>>> > of the hardware boundary. Thus, it is un-usable, even if somehow
> >>>> > fetched from kernel memory. It ensures run-time security.
> >>>> >
> >>>> > This patchset adds generic support for classing the Hardware
> >>>> > Bound Key, based on:
> >>>> >
> >>>> > - Newly added flag-'is_hbk', added to the tfm.
> >>>> >
> >>>> > Consumer of the kernel crypto api, after allocating
> >>>> > the transformation, sets this flag based on the basis
> >>>> > of the type of key consumer has.
> >>>> >
> >>>> > - This helps to influence the core processing logic
> >>>> > for the encapsulated algorithm.
> >>>> >
> >>>> > - This flag is set by the consumer after allocating
> >>>> > the tfm and before calling the function crypto_xxx_setkey().
> >>>> >
> >>>> > 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.
> >>>> What is the difference to the current trusted keys with CAAM?
> >>>> When I tested the patch series back then, I wasn't able to import a
> >>>> sealed key on another board with the same SoC.
> >>> Currently, keys that are part of trusted key-ring, contains plain
> >>> key.
> >>> With this patch-set, these key will become Hw Bound Key, which is
> >>> not a plain key anymore.
> >>> After this patch-set, if somehow the HB-key is retrieved from the
> >>> keyring, the retrieved key would be un-usable without hw.
> >>
> >> This doesn't answer my question why I couldn't import one key on
> >> another board with the same SoC.
> >
> > I don’t believe this is intended to work this way. Each key blob
> > created by CAAM is bound to a specific device. Being able to decrypt
> > the same blob on another SoC would open up some attack vectors: Think
> > of a locked down device where I’m able to extract this key blob.
> > Simply buying a board with the same Soc would allow me to decrypt this
> > blob by copying it over to my board.
>
> I agree, thus my first question here was, what this series is adding, if the key
> is already "bound" to the hardware. That is what I don't understand.
>
> -michael
Just one correction in above statement.
"Key-Blob" is bound to the hardware, not the plain key that is added to the job-ring, after de-blobification.
Security at rest is ensured here. But not at the runtime.
This patch-set goes a step further and ensures runtime security as well.
>
> > Roughly speaking, CAAM key blobs are secure using a key derived from
> > the device’s master key. This master key can be programmed via eFUSEs.
> > So you’d have to burn the same master key on both SoCs and it should
> > work.
> >
> > In any way, check the security reference manual for your SoC. It
> > should explain this in more detail.
> -----Original Message-----
> From: Jan L?bbe <[email protected]>
> Sent: Wednesday, September 7, 2022 1:41 PM
> To: Pankaj Gupta <[email protected]>; Jarkko Sakkinen
> <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; Sahil Malhotra
> <[email protected]>; Kshitiz Varshney <[email protected]>;
> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY
>
> Caution: EXT Email
>
> On Wed, 2022-09-07 at 07:22 +0000, Pankaj Gupta wrote:
> > Even if somehow the key is retrieved from the keyring, the retrieved
> > key would be an encrypted key.
> > This encrypted key can only be decrypted by Hardware, which generated it.
> >
> > Hence, the retrieved key is unusable outside of the hardware.
>
> NXP's CAAM unit (i.e. on i.MX6) supports several modes of sealed/encrypted
> keys.
> The (un)sealing process uses a key that is normally derived from a per-device
> key in eFUSES. One aspect of these modes is whether the plaintext key
> material is accessible to the kernel or not.
>
> Ahmad's patch set added support for a mode where the CAAM is used to
> seal plaintext known to the kernel to a "blob" (in CAAM terminology) on
> export to userspace and the reverse on import. This mode allows the kernel
> to use the plaintext for dm-crypt, to encrypt other keyrings and similar.
>
> The CAAM has another sealing mode, where it will not allow writing of the
> plaintext key to memory. Instead, it is kept in one of the CAAM-internal key
> registers. There, it can be used for cryptographic operations (i.e. AES). This
> way, the plaintext key is protected even from the kernel. The kernel could
> keep a copy of in sealed form, so it can reload the CAAM's key register when
> needed.
>
>
> Pankaj, is that the mode you intend to support with this series?
Yes, this is what is called as "black key", in CAAM terminology.
Black key is nothing but a HBK key.
This is what I am trying to achieve with this patch-set.
>
> Could you describe the high-level use-cases this would be need for,
> compared to the existing mode where plaintext keys are accessible to the
> kernel? In which cases would you use each mode?
>
High-level Use-case is to ensure runtime security.
By runtime security, I mean, key that is added to keyring after blob-decapsulation,
- if get stolen, then being plain key, security can be compromised.
- After this patch-set, if key get stolen, then being HBK(encrypted by H/W), will not be of any use without HW. Security is not compromised.
> Regards,
> Jan
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&data=05%7C01%7Cpankaj.gupta%40nxp.com%7Cb
> 1335df185404e02df1108da90a8886c%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637981350763081319%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&sdata=aNxEETFYLc74F%2BOq9IK3p63tniVfczpgslG3LYe
> ZzAo%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> -----Original Message-----
> From: Herbert Xu <[email protected]>
> Sent: Wednesday, September 7, 2022 12:56 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; Sahil Malhotra
> <[email protected]>; Kshitiz Varshney <[email protected]>;
> Horia Geanta <[email protected]>; Varun Sethi <[email protected]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk
> added to the tfm
>
> Caution: EXT Email
>
> On Wed, Sep 07, 2022 at 07:22:42AM +0000, Pankaj Gupta wrote:
> >
> > Current support, does not permit the hardware to support both types of
> keys: HBK & Plain Key, at the same time.
> >
> > This change is generic and permit any driver that supports both- HBK and
> plain-key, to differentiate and use the keys accordingly.
>
> Existing drivers simply register hardware keys under a different algorithm
> name, there is no reason why they can't coexist with a plain key.
>
Thanks for the comments.
Intention is to only secure the key buffer, at run-time.
Not to change the working of the crypto algorithm. Algorithm would be working exactly same for plain and HBK.
There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
Modifying the algorithm name in these IP(s), is not always allowed or easy to maintain.
While, this patch-set allows to use the same algorithm name,
and hence prevents any changes required to the user(3rd Party IPs) of kernel crypto layer.
Regards,
> Cheers,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2F&data=05%7C01%7Cpankaj.gupta%40nx
> p.com%7C9bc412605fa243702f3a08da90a2602c%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637981324324251974%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&sdata=b1ImbcEMa9jticFU7yrpwHXuuQEog
> KLrjuiE%2FFpcYyA%3D&reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondo
> r.apana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7Cpankaj.g
> upta%40nxp.com%7C9bc412605fa243702f3a08da90a2602c%7C686ea1d3bc2b
> 4c6fa92cd99c5c301635%7C0%7C0%7C637981324324251974%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cP4js5Q0QPBJfvlrYDi0j6R
> IGFpqHtJOSa9C7YC2IXM%3D&reserved=0
On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
>
> There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> Modifying the algorithm name in these IP(s), is not always allowed or easy to maintain.
So the objective is to support out-of-tree modules?
There is no way I'm merging this then.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert
Please find response inline.
Regards
Varun
> -----Original Message-----
> From: Herbert Xu <[email protected]>
> Sent: Wednesday, September 7, 2022 3:40 PM
> To: Pankaj Gupta <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-security-
> [email protected]; Sahil Malhotra <[email protected]>; Kshitiz
> Varshney <[email protected]>; Horia Geanta <[email protected]>;
> Varun Sethi <[email protected]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
>
> Caution: EXT Email
>
> On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> >
> > There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> > Modifying the algorithm name in these IP(s), is not always allowed or easy to
> maintain.
>
> So the objective is to support out-of-tree modules?
[Varun] No, the intention is not to use out of tree modules but to allow seamless use of crytpo ciphers with keys backed by security co-processors (keys only visible to security co-processors), by Linux kernel and userspace components. Hardware backed keys are being introduced as a variant of existing Trusted keys, with the difference that these are not un-sealed and released in plain to the kernel memory. With the current patchset, the existing set of ciphers can be used along with newly introduced hardware backed flag. The security co-processor driver is able to interpret the flag and subsequently program the hardware, to interpret the supplied key as a hardware backed key.
>
> There is no way I'm merging this then.
>
> Thanks,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&data=05%7C01%7CV.Sethi%40nxp.com%7Cd
> ec165619848426b9c9008da90b946da%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637981422690327443%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=kKaGEvKOmUbV8hCh6T9Fswfo39jg%2BqbxYavPcfJS
> h3E%3D&reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7CV.Sethi%40nxp.
> com%7Cdec165619848426b9c9008da90b946da%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637981422690327443%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&sdata=vSNYijBOH5mCmOzZW02R0sNzNNrtTWkD
> vF8%2FpwlTUqk%3D&reserved=0
On Mon, Sep 12, 2022 at 05:19:44PM +0000, Varun Sethi wrote:
>
> > On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> > >
> > > There are 3rd party IP(s), which uses kernel for crypto-algorithm's operations.
> > > Modifying the algorithm name in these IP(s), is not always allowed or easy to
> > maintain.
> >
> > So the objective is to support out-of-tree modules?
> [Varun] No, the intention is not to use out of tree modules but to allow seamless use of crytpo ciphers with keys backed by security co-processors (keys only visible to security co-processors), by Linux kernel and userspace components. Hardware backed keys are being introduced as a variant of existing Trusted keys, with the difference that these are not un-sealed and released in plain to the kernel memory. With the current patchset, the existing set of ciphers can be used along with newly introduced hardware backed flag. The security co-processor driver is able to interpret the flag and subsequently program the hardware, to interpret the supplied key as a hardware backed key.
Well I asked why isn't the existing arrangement for hardware key
algorithms sufficient, and I was given the response that you needed
this for compatibility with third-party IP(s).
Now are you saying this is not the case? So the existing framework
should work then?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
Please find response inline.
Regards
Varun
> -----Original Message-----
> From: Herbert Xu <[email protected]>
> Sent: Tuesday, September 13, 2022 7:36 AM
> To: Varun Sethi <[email protected]>
> Cc: Pankaj Gupta <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-security-
> [email protected]; Sahil Malhotra <[email protected]>; Kshitiz
> Varshney <[email protected]>; Horia Geanta <[email protected]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
>
> Caution: EXT Email
>
> On Mon, Sep 12, 2022 at 05:19:44PM +0000, Varun Sethi wrote:
> >
> > > On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:
> > > >
> > > > There are 3rd party IP(s), which uses kernel for crypto-algorithm's
> operations.
> > > > Modifying the algorithm name in these IP(s), is not always allowed
> > > > or easy to
> > > maintain.
> > >
> > > So the objective is to support out-of-tree modules?
> > [Varun] No, the intention is not to use out of tree modules but to allow
> seamless use of crytpo ciphers with keys backed by security co-processors (keys
> only visible to security co-processors), by Linux kernel and userspace
> components. Hardware backed keys are being introduced as a variant of existing
> Trusted keys, with the difference that these are not un-sealed and released in
> plain to the kernel memory. With the current patchset, the existing set of ciphers
> can be used along with newly introduced hardware backed flag. The security co-
> processor driver is able to interpret the flag and subsequently program the
> hardware, to interpret the supplied key as a hardware backed key.
>
> Well I asked why isn't the existing arrangement for hardware key algorithms
> sufficient, and I was given the response that you needed this for compatibility
> with third-party IP(s).
>
> Now are you saying this is not the case? So the existing framework should work
> then?
>
[Varun] The proposed patchset makes things more scalable. With the hardware backed key flag, there's no need for the security co-processor driver to register separate set of algorithms. This makes things simpler and more scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to use standard set of algorithms and leave the key specific complexity to the driver.
> Cheers,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&data=05%7C01%7CV.Sethi%40nxp.com%7C6
> 51bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&sdata=b%2BjXwEqMEomgvSpLVnNzuWRNbmfQF4pX5hitrFh
> Frww%3D&reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7CV.Sethi%40nxp.
> com%7C651bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&sdata=6VRL5smACsEevXL8HKs2ADlni9G%2F9J0q7E
> 3Q2emxVzU%3D&reserved=0
On Tue, Sep 13, 2022 at 10:01:13AM +0000, Varun Sethi wrote:
>
> [Varun] The proposed patchset makes things more scalable. With the hardware backed key flag, there's no need for the security co-processor driver to register separate set of algorithms. This makes things simpler and more scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to use standard set of algorithms and leave the key specific complexity to the driver.
Users already need to specify which driver they are going to use in
order to actually access the hardware keys instead of getting a software
implementation of the same algorithm.
So I don't see what extra burdens are placed on them by the current
regime.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
Please find comments inline.
Regards
Varun
> -----Original Message-----
> From: Herbert Xu <[email protected]>
> Sent: Tuesday, September 13, 2022 3:59 PM
> To: Varun Sethi <[email protected]>
> Cc: Pankaj Gupta <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; linux-security-
> [email protected]; Sahil Malhotra <[email protected]>; Kshitiz
> Varshney <[email protected]>; Horia Geanta <[email protected]>
> Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
> to the tfm
>
> Caution: EXT Email
>
> On Tue, Sep 13, 2022 at 10:01:13AM +0000, Varun Sethi wrote:
> >
> > [Varun] The proposed patchset makes things more scalable. With the
> hardware backed key flag, there's no need for the security co-processor driver
> to register separate set of algorithms. This makes things simpler and more
> scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to
> use standard set of algorithms and leave the key specific complexity to the
> driver.
>
> Users already need to specify which driver they are going to use in order to
> actually access the hardware keys instead of getting a software implementation
> of the same algorithm.
>
> So I don't see what extra burdens are placed on them by the current regime.
[Varun] Problem with the current approach is that it's completely disconnected from the kernel keyrings. We are using the trusted key rings for storing the hardware backed keys. Now, for the hardware backed keys we can still continue to use the existing generic algorithms exposed by the crypto drivers. With our approach the driver can distinguish between a hardware backed key and a plain key, thus perform the relevant operation.
As a part of our patchset we are also proposing modifications to the trusted keys, in order to store additional meta data associated with the key.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2F&data=05%7C01%7CV.Sethi%40nxp.com%7C9
> df35ead51ad4143067e08da9572d5d5%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637986617695149505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&sdata=t5RXelrFDZZ7GdMyZeLcSR2hRN6O0Hs8uI2MpIwhCms
> %3D&reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7CV.Sethi%40nxp.
> com%7C9df35ead51ad4143067e08da9572d5d5%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637986617695149505%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000%7C%7C%7C&sdata=V7NXYx5pYPjte6jlw1gpYCBPftJBZGpHBN44
> e3pD0ps%3D&reserved=0