| Message ID | 1594591536-531-3-git-send-email-iuliana.prodan@nxp.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: caam - add tagged keys functionality and tk transformations for skcipher | expand |
On Mon, Jul 13, 2020 at 01:05:36AM +0300, Iuliana Prodan wrote: > Tagged keys are keys that contain metadata indicating what > they are and how to handle them using tag_object API. > > Add support, for tagged keys, to skcipher algorithms by > adding new transformations, with _tk_ prefix to distinguish > between plaintext and tagged keys. > > For job descriptors a new option (key_cmd_opt) was added for KEY command. > Tagged keys can be loaded using only a KEY command with ENC=1 > and the proper setting of the EKT bit. The EKT bit in the > KEY command indicates which encryption algorithm (AES-ECB or > AES-CCM) should be used to decrypt the key. These options will be kept in > key_cmd_opt. > > The tk_ transformations can be used directly by their name: > struct sockaddr_alg sa = { > .salg_family = AF_ALG, > .salg_type = "skcipher", /* this selects the symmetric cipher */ > .salg_name = "tk(cbc(aes))" /* this is the cipher name */ > }; > or for dm-crypt, e.g. using dmsetup: > dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) > crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 > sector_size:512". > > Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> > Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Can this use the existing paes name instead of tk as done in other drivers? Thanks,
On 7/16/2020 10:36 AM, Herbert Xu wrote: > On Mon, Jul 13, 2020 at 01:05:36AM +0300, Iuliana Prodan wrote: >> Tagged keys are keys that contain metadata indicating what >> they are and how to handle them using tag_object API. >> >> Add support, for tagged keys, to skcipher algorithms by >> adding new transformations, with _tk_ prefix to distinguish >> between plaintext and tagged keys. >> >> For job descriptors a new option (key_cmd_opt) was added for KEY command. >> Tagged keys can be loaded using only a KEY command with ENC=1 >> and the proper setting of the EKT bit. The EKT bit in the >> KEY command indicates which encryption algorithm (AES-ECB or >> AES-CCM) should be used to decrypt the key. These options will be kept in >> key_cmd_opt. >> >> The tk_ transformations can be used directly by their name: >> struct sockaddr_alg sa = { >> .salg_family = AF_ALG, >> .salg_type = "skcipher", /* this selects the symmetric cipher */ >> .salg_name = "tk(cbc(aes))" /* this is the cipher name */ >> }; >> or for dm-crypt, e.g. using dmsetup: >> dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) >> crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 >> sector_size:512". >> >> Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> >> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> > > Can this use the existing paes name instead of tk as done in > other drivers? > This patch set adds support only for some AES-based algorithms. However, going further the plan is to add all keyed algorithms supported by caam. Thus I wouldn't tie the name to AES. Possible alternatives would be: pk - protected keys tk - with "t" standing for "trusted" instead of "tagged" Wrt. "trusted", I am not sure this term should strictly be tied to a TPM or not. Thanks, Horia
On Thu, Jul 16, 2020 at 01:35:51PM +0300, Horia Geantă wrote: > > This patch set adds support only for some AES-based algorithms. > However, going further the plan is to add all keyed algorithms > supported by caam. > > Thus I wouldn't tie the name to AES. Yes but it's still exactly the same underlying feature as paes. So I don't want to have two ways of doing the same thing in the Crypto API. Cheers,
On 7/16/2020 2:53 PM, Herbert Xu wrote: > On Thu, Jul 16, 2020 at 01:35:51PM +0300, Horia Geantă wrote: >> >> This patch set adds support only for some AES-based algorithms. >> However, going further the plan is to add all keyed algorithms >> supported by caam. >> >> Thus I wouldn't tie the name to AES. > > Yes but it's still exactly the same underlying feature as paes. > So I don't want to have two ways of doing the same thing in the > Crypto API. > So instead of tk(cbc(aes)) use paes(cbc(aes) or cbc(paes)? How would this work for hmac(sha512), paes(hmac(sha512)) or hmac(psha512), or even phmac(sha512)? Thanks, Horia
On Thu, Jul 16, 2020 at 03:07:50PM +0300, Horia Geantă wrote: > > So instead of tk(cbc(aes)) use paes(cbc(aes) or cbc(paes)? Well if we're following the existing paes model then it'd be cbc(paes). > How would this work for hmac(sha512), > paes(hmac(sha512)) or hmac(psha512), or even phmac(sha512)? Perhaps hmac(psha512). The point is whatever scheme you come up with has to be consistent across all drivers. Cheers,
> -----Original Message----- > From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of Herbert Xu > Sent: Thursday, July 16, 2020 2:20 PM > To: Horia Geantă <horia.geanta@nxp.com> > Cc: Iuliana Prodan <iuliana.prodan@nxp.com>; Aymen Sghaier <aymen.sghaier@nxp.com>; David S. Miller <davem@davemloft.net>; > Silvano Di Ninno <silvano.dininno@nxp.com>; Franck Lenormand <franck.lenormand@nxp.com>; linux-crypto@vger.kernel.org; > linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com> > Subject: Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher algorithms > > <<< External Email >>> > On Thu, Jul 16, 2020 at 03:07:50PM +0300, Horia Geantă wrote: > > > > So instead of tk(cbc(aes)) use paes(cbc(aes) or cbc(paes)? > > Well if we're following the existing paes model then it'd be > cbc(paes). > > > How would this work for hmac(sha512), > > paes(hmac(sha512)) or hmac(psha512), or even phmac(sha512)? > > Perhaps hmac(psha512). > That would make no sense though, as sha512 does not involve any keys ... It's the HMAC part that needs the keys. So phmac(sha512) then? > The point is whatever scheme you come up with has to be consistent > across all drivers. > > Cheers, > -- > Email: Herbert Xu <herbert@gondor.apana.org.au> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Pascal van Leeuwen Silicon IP Architect Multi-Protocol Engines, Rambus Security Rambus ROTW Holding BV +31-73 6581953 Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus. Please be so kind to update your e-mail address book with my new e-mail address. ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. ** Rambus Inc.<http://www.rambus.com>
On Thu, Jul 16, 2020 at 12:24:49PM +0000, Van Leeuwen, Pascal wrote: > > That would make no sense though, as sha512 does not involve any keys ... > It's the HMAC part that needs the keys. So phmac(sha512) then? You're right, that would be phmac(...). But the point is we don't want each driver to do its own thing so whatever scheme we pick should be applicable to all drivers. Thanks,
On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan <iuliana.prodan@nxp.com> wrote: > > Tagged keys are keys that contain metadata indicating what > they are and how to handle them using tag_object API. > > Add support, for tagged keys, to skcipher algorithms by > adding new transformations, with _tk_ prefix to distinguish > between plaintext and tagged keys. > > For job descriptors a new option (key_cmd_opt) was added for KEY command. > Tagged keys can be loaded using only a KEY command with ENC=1 > and the proper setting of the EKT bit. The EKT bit in the > KEY command indicates which encryption algorithm (AES-ECB or > AES-CCM) should be used to decrypt the key. These options will be kept in > key_cmd_opt. > > The tk_ transformations can be used directly by their name: > struct sockaddr_alg sa = { > .salg_family = AF_ALG, > .salg_type = "skcipher", /* this selects the symmetric cipher */ > .salg_name = "tk(cbc(aes))" /* this is the cipher name */ > }; > or for dm-crypt, e.g. using dmsetup: > dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) > crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 > sector_size:512". How to use it with cryptsetup? I'm asking because it is not clear to me why you are not implementing a new kernel key type (KEYS subsystem) to utilize tagged keys. Many tools already support the keyctl userspace interface (cryptsetup, fscrypt, ...).
On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger <richard.weinberger@gmail.com> wrote: > > On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan <iuliana.prodan@nxp.com> wrote: > > > > Tagged keys are keys that contain metadata indicating what > > they are and how to handle them using tag_object API. > > > > Add support, for tagged keys, to skcipher algorithms by > > adding new transformations, with _tk_ prefix to distinguish > > between plaintext and tagged keys. > > > > For job descriptors a new option (key_cmd_opt) was added for KEY command. > > Tagged keys can be loaded using only a KEY command with ENC=1 > > and the proper setting of the EKT bit. The EKT bit in the > > KEY command indicates which encryption algorithm (AES-ECB or > > AES-CCM) should be used to decrypt the key. These options will be kept in > > key_cmd_opt. > > > > The tk_ transformations can be used directly by their name: > > struct sockaddr_alg sa = { > > .salg_family = AF_ALG, > > .salg_type = "skcipher", /* this selects the symmetric cipher */ > > .salg_name = "tk(cbc(aes))" /* this is the cipher name */ > > }; > > or for dm-crypt, e.g. using dmsetup: > > dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) > > crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 > > sector_size:512". > > How to use it with cryptsetup? > I'm asking because it is not clear to me why you are not implementing > a new kernel key type (KEYS subsystem) > to utilize tagged keys. > Many tools already support the keyctl userspace interface (cryptsetup, > fscrypt, ...). *friendly ping*
On 9/14/2020 9:38 AM, Richard Weinberger wrote: > On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger > <richard.weinberger@gmail.com> wrote: >> >> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan <iuliana.prodan@nxp.com> wrote: >>> >>> Tagged keys are keys that contain metadata indicating what >>> they are and how to handle them using tag_object API. >>> >>> Add support, for tagged keys, to skcipher algorithms by >>> adding new transformations, with _tk_ prefix to distinguish >>> between plaintext and tagged keys. >>> >>> For job descriptors a new option (key_cmd_opt) was added for KEY command. >>> Tagged keys can be loaded using only a KEY command with ENC=1 >>> and the proper setting of the EKT bit. The EKT bit in the >>> KEY command indicates which encryption algorithm (AES-ECB or >>> AES-CCM) should be used to decrypt the key. These options will be kept in >>> key_cmd_opt. >>> >>> The tk_ transformations can be used directly by their name: >>> struct sockaddr_alg sa = { >>> .salg_family = AF_ALG, >>> .salg_type = "skcipher", /* this selects the symmetric cipher */ >>> .salg_name = "tk(cbc(aes))" /* this is the cipher name */ >>> }; >>> or for dm-crypt, e.g. using dmsetup: >>> dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) >>> crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 >>> sector_size:512". >> >> How to use it with cryptsetup? >> I'm asking because it is not clear to me why you are not implementing >> a new kernel key type (KEYS subsystem) >> to utilize tagged keys. >> Many tools already support the keyctl userspace interface (cryptsetup, >> fscrypt, ...). > > *friendly ping* > We didn't include the key management part in this series, just the crypto API support for algorithms with protected keys, to get early feedback. Wrt. key management: The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release) will have support for protected keys generation. Besides this, a dedicated ioctl-based interface will allow userspace to generate and export these keys. After this, user can use standard keyctl to add a key (as user / logon type) in the keyring, such that it would be available to dm-crypt. We know that adding new ioctls is frowned upon, so before trying to upstream the ioctl-based solution the plan is checking the feasibility of extending keyctl as David Howells suggested: https://lore.kernel.org/lkml/8060.1533226481@warthog.procyon.org.uk (Note the difference b/w adding new key type - which was rejected - and a key "subtype extension".) Horia
----- Ursprüngliche Mail ----- > Von: "horia geanta" <horia.geanta@nxp.com> >>> How to use it with cryptsetup? >>> I'm asking because it is not clear to me why you are not implementing >>> a new kernel key type (KEYS subsystem) >>> to utilize tagged keys. >>> Many tools already support the keyctl userspace interface (cryptsetup, >>> fscrypt, ...). >> >> *friendly ping* >> > We didn't include the key management part in this series, > just the crypto API support for algorithms with protected keys, > to get early feedback. > > Wrt. key management: > The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release) > will have support for protected keys generation. > Besides this, a dedicated ioctl-based interface will allow userspace to > generate and export these keys. After this, user can use standard keyctl > to add a key (as user / logon type) in the keyring, such that it would be > available to dm-crypt. > > We know that adding new ioctls is frowned upon, so before trying to upstream > the ioctl-based solution the plan is checking the feasibility of > extending keyctl as David Howells suggested: > https://lore.kernel.org/lkml/8060.1533226481@warthog.procyon.org.uk > (Note the difference b/w adding new key type - which was rejected - > and a key "subtype extension".) We have also a keyctl based patch series which should go upstream. Since we also added a new keytype, it got rejected so far. Do you have git repo with the WIP patches available? Not that we do the work twice. :-) Our patch series also supports DCP beside of CAAM. Thanks, //richard
On 9/16/2020 12:50 AM, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- >> Von: "horia geanta" <horia.geanta@nxp.com> >>>> How to use it with cryptsetup? >>>> I'm asking because it is not clear to me why you are not implementing >>>> a new kernel key type (KEYS subsystem) >>>> to utilize tagged keys. >>>> Many tools already support the keyctl userspace interface (cryptsetup, >>>> fscrypt, ...). >>> >>> *friendly ping* >>> >> We didn't include the key management part in this series, >> just the crypto API support for algorithms with protected keys, >> to get early feedback. >> >> Wrt. key management: >> The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release) >> will have support for protected keys generation. >> Besides this, a dedicated ioctl-based interface will allow userspace to >> generate and export these keys. After this, user can use standard keyctl >> to add a key (as user / logon type) in the keyring, such that it would be >> available to dm-crypt. >> >> We know that adding new ioctls is frowned upon, so before trying to upstream >> the ioctl-based solution the plan is checking the feasibility of >> extending keyctl as David Howells suggested: >> https://lore.kernel.org/lkml/8060.1533226481@warthog.procyon.org.uk >> (Note the difference b/w adding new key type - which was rejected - >> and a key "subtype extension".) > > We have also a keyctl based patch series which should go upstream. > Since we also added a new keytype, it got rejected so far. > Could you please point me to the discussion? > Do you have git repo with the WIP patches available? > Not that we do the work twice. :-) Unfortunately we haven't developed any code yet. > Our patch series also supports DCP beside of CAAM. > By looking at the DCP capabilities, I assume the OTP key that is copied in the key RAM at boot time is used as KEK. If you don't mind sharing, I could review the code. Thanks, Horia
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index b2f9882..9e4206f 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-2020 NXP * * Based on talitos crypto API driver. * @@ -58,6 +58,10 @@ #include "caamalg_desc.h" #include <crypto/engine.h> +#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API +#include "tag_object.h" +#endif /* CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API */ + /* * crypto alg */ @@ -84,6 +88,7 @@ struct caam_alg_entry { bool rfc3686; bool geniv; bool nodkp; + bool support_tagged_key; }; struct caam_aead_alg { @@ -736,9 +741,16 @@ 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); - ctx->cdata.keylen = keylen; - ctx->cdata.key_virt = key; - ctx->cdata.key_inline = true; + /* + * If the algorithm has support for tagged key, + * this is already set in tk_skcipher_setkey(). + * Otherwise, set here the algorithm details. + */ + if (!alg->caam.support_tagged_key) { + ctx->cdata.keylen = keylen; + ctx->cdata.key_virt = key; + ctx->cdata.key_inline = true; + } /* skcipher_encrypt shared descriptor */ desc = ctx->sh_desc_enc; @@ -816,6 +828,56 @@ static int arc4_skcipher_setkey(struct crypto_skcipher *skcipher, return skcipher_setkey(skcipher, key, keylen, 0); } +#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API +static int tk_skcipher_setkey(struct crypto_skcipher *skcipher, + const u8 *key, unsigned int keylen) +{ + struct caam_ctx *ctx = crypto_skcipher_ctx(skcipher); + struct device *jrdev = ctx->jrdev; + struct header_conf *header; + int ret; + + ctx->cdata.keylen = keylen; + ctx->cdata.key_virt = key; + ctx->cdata.key_inline = true; + + /* Retrieve the address of the tag object configuration */ + ret = get_tag_object_header_conf(ctx->cdata.key_virt, + ctx->cdata.keylen, &header); + if (ret) { + dev_err(jrdev, + "unable to get tag object header configuration\n"); + return ret; + } + + /* Check if the tag object header is a black key */ + if (!is_black_key(header)) { + dev_err(jrdev, + "tagged key provided is not a black key\n"); + return -EINVAL; + } + + /* Retrieve the black key configuration */ + get_key_conf(header, + &ctx->cdata.key_real_len, + &ctx->cdata.key_cmd_opt); + + /* + * Retrieve the address of the data + * and size of the tagged object + */ + ret = get_tagged_data(ctx->cdata.key_virt, ctx->cdata.keylen, + &ctx->cdata.key_virt, &ctx->cdata.keylen); + if (ret) { + dev_err(jrdev, + "unable to get data from tagged object\n"); + return ret; + } + + return skcipher_setkey(skcipher, key, keylen, 0); +} +#endif /* CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API */ + static int des_skcipher_setkey(struct crypto_skcipher *skcipher, const u8 *key, unsigned int keylen) { @@ -1833,6 +1895,25 @@ static struct caam_skcipher_alg driver_algs[] = { }, .caam.class1_alg_type = OP_ALG_ALGSEL_AES | OP_ALG_AAI_CBC, }, +#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API + { + .skcipher = { + .base = { + .cra_name = "tk(cbc(aes))", + .cra_driver_name = "tk-cbc-aes-caam", + .cra_blocksize = AES_BLOCK_SIZE, + }, + .setkey = tk_skcipher_setkey, + .encrypt = skcipher_encrypt, + .decrypt = skcipher_decrypt, + .min_keysize = TAG_MIN_SIZE, + .max_keysize = CAAM_MAX_KEY_SIZE, + .ivsize = AES_BLOCK_SIZE, + }, + .caam.class1_alg_type = OP_ALG_ALGSEL_AES | OP_ALG_AAI_CBC, + .caam.support_tagged_key = true, + }, +#endif /* CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API */ { .skcipher = { .base = { @@ -1952,6 +2033,24 @@ static struct caam_skcipher_alg driver_algs[] = { }, .caam.class1_alg_type = OP_ALG_ALGSEL_AES | OP_ALG_AAI_ECB, }, +#ifdef CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API + { + .skcipher = { + .base = { + .cra_name = "tk(ecb(aes))", + .cra_driver_name = "tk-ecb-aes-caam", + .cra_blocksize = AES_BLOCK_SIZE, + }, + .setkey = tk_skcipher_setkey, + .encrypt = skcipher_encrypt, + .decrypt = skcipher_decrypt, + .min_keysize = TAG_MIN_SIZE, + .max_keysize = CAAM_MAX_KEY_SIZE, + }, + .caam.class1_alg_type = OP_ALG_ALGSEL_AES | OP_ALG_AAI_ECB, + .caam.support_tagged_key = true, + }, +#endif /* CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API */ { .skcipher = { .base = { diff --git a/drivers/crypto/caam/caamalg_desc.c b/drivers/crypto/caam/caamalg_desc.c index d6c5818..447f7a5 100644 --- a/drivers/crypto/caam/caamalg_desc.c +++ b/drivers/crypto/caam/caamalg_desc.c @@ -1389,8 +1389,18 @@ void cnstr_shdsc_skcipher_encap(u32 * const desc, struct alginfo *cdata, JUMP_COND_SHRD); /* Load class1 key only */ - append_key_as_imm(desc, cdata->key_virt, cdata->keylen, - cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG); + if (IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API) && + cdata->key_cmd_opt) + /* + * Black keys can be loaded using only a KEY command + * with ENC=1 and the proper setting of the EKT bit. + */ + append_key_as_imm(desc, cdata->key_virt, cdata->keylen, + cdata->key_real_len, CLASS_1 | + KEY_DEST_CLASS_REG | cdata->key_cmd_opt); + else + append_key_as_imm(desc, cdata->key_virt, cdata->keylen, + cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG); /* Load nonce into CONTEXT1 reg */ if (is_rfc3686) { @@ -1464,8 +1474,18 @@ void cnstr_shdsc_skcipher_decap(u32 * const desc, struct alginfo *cdata, JUMP_COND_SHRD); /* Load class1 key only */ - append_key_as_imm(desc, cdata->key_virt, cdata->keylen, - cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG); + if (IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API) && + cdata->key_cmd_opt) + /* + * Black keys can be loaded using only a KEY command + * with ENC=1 and the proper setting of the EKT bit. + */ + append_key_as_imm(desc, cdata->key_virt, cdata->keylen, + cdata->key_real_len, CLASS_1 | + KEY_DEST_CLASS_REG | cdata->key_cmd_opt); + else + append_key_as_imm(desc, cdata->key_virt, cdata->keylen, + cdata->keylen, CLASS_1 | KEY_DEST_CLASS_REG); /* 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 62ce642..93b2ab0 100644 --- a/drivers/crypto/caam/desc_constr.h +++ b/drivers/crypto/caam/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; }; /**
Tagged keys are keys that contain metadata indicating what they are and how to handle them using tag_object API. Add support, for tagged keys, to skcipher algorithms by adding new transformations, with _tk_ prefix to distinguish between plaintext and tagged keys. For job descriptors a new option (key_cmd_opt) was added for KEY command. Tagged keys can be loaded using only a KEY command with ENC=1 and the proper setting of the EKT bit. The EKT bit in the KEY command indicates which encryption algorithm (AES-ECB or AES-CCM) should be used to decrypt the key. These options will be kept in key_cmd_opt. The tk_ transformations can be used directly by their name: struct sockaddr_alg sa = { .salg_family = AF_ALG, .salg_type = "skcipher", /* this selects the symmetric cipher */ .salg_name = "tk(cbc(aes))" /* this is the cipher name */ }; or for dm-crypt, e.g. using dmsetup: dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10) crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1 sector_size:512". Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> --- drivers/crypto/caam/caamalg.c | 107 +++++++++++++++++++++++++++++++++++-- drivers/crypto/caam/caamalg_desc.c | 28 ++++++++-- drivers/crypto/caam/desc_constr.h | 4 ++ 3 files changed, 131 insertions(+), 8 deletions(-)