linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Udit Agarwal <udit.agarwal@nxp.com>
Cc: dhowells@redhat.com, zohar@linux.vnet.ibm.com, jmorris@namei.org,
	serge@hallyn.com, denkenz@gmail.com,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, sahil.malhotra@nxp.com,
	ruchika.gupta@nxp.com, horia.geanta@nxp.com,
	aymen.sghaier@nxp.com
Subject: Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.
Date: Thu, 02 Aug 2018 17:14:41 +0100	[thread overview]
Message-ID: <8060.1533226481@warthog.procyon.org.uk> (raw)
In-Reply-To: <20180723111432.26830-1-udit.agarwal@nxp.com>

Udit Agarwal <udit.agarwal@nxp.com> wrote:

> +==========
> +Secure Key
> +==========
> +
> +Secure key is the new type added to kernel key ring service.
> +Secure key is a symmetric type key of minimum length 32 bytes
> +and with maximum possible length to be 128 bytes. It is produced
> +in kernel using the CAAM crypto engine. Userspace can only see
> +the blob for the corresponding key. All the blobs are displayed
> +or loaded in hex ascii.

To echo Mimi, this sounds suspiciously like it should have a generic
interface, not one that's specifically tied to one piece of hardware -
particularly if it's named with generic "secure".

Can you convert this into a "symmetric" type and make the backend pluggable?

> +	keyctl add secure <name> "new <keylen>" <ring>
> +	keyctl load secure <name> "load <hex_blob>" <ring>
> +	keyctl print <key_id>

There isn't a "keyctl load" that I recall.  Did you mean "keyctl add"?

I wonder if it makes sense to actually add "create" and "load" interfaces for
asymmetric and symmetric key types to aid in key management, e.g.:

	keyctl create symmetric.caam foo_munging_key len=128 @s
	keyctl load symmetric.caam foo_munging_key id=xxx @s
	keyctl create asymmetric.tpm foo_signing_key "rsa len=4096" @s
	keyctl load asymmetric.tpm foo_signing_key id=xxx @s

Note the subtype extension added to the type.  This is something I've been
meaning to add to add_key() and request_key().  It means that we don't have to
try and divine the nature of the key from the payload, but can leave the
payload as just the data if data is needed.

This might look something like:

	key = keyctl_create(const char *type, const char *desc,
			    const char *data, key_serial_t keyring);
	key = keyctl_load(const char *type, const char *desc,
			  const char *id, key_serial_t keyring);

There would probably need to be a way to query the ID of a created key also,
so that you can then pass that ID back to the loader.

	keyctl_get_id(key_serial_t key, char *buf, size_t buf_size);

David

  parent reply	other threads:[~2018-08-02 18:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23 11:14 [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM Udit Agarwal
2018-07-23 11:14 ` [PATCH v2 2/2] encrypted_keys: Adds support for secure key-type as master key Udit Agarwal
2018-08-02 16:14 ` David Howells [this message]
2018-08-02 18:57   ` [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM James Bottomley
2018-08-03 11:58   ` Mimi Zohar
2018-08-03 14:23     ` James Bottomley
2018-08-03 14:45       ` Mimi Zohar
2018-08-03 15:48         ` James Bottomley
2018-08-03 18:28           ` Mimi Zohar
2018-10-16 10:16             ` David Gstir
2018-10-16 10:16               ` David Gstir
2018-08-03 14:55       ` David Howells
2018-08-03 15:23         ` Mimi Zohar
2020-01-17 11:52 ` Maik Otto
2020-01-23 12:55   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8060.1533226481@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=aymen.sghaier@nxp.com \
    --cc=denkenz@gmail.com \
    --cc=horia.geanta@nxp.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=ruchika.gupta@nxp.com \
    --cc=sahil.malhotra@nxp.com \
    --cc=serge@hallyn.com \
    --cc=udit.agarwal@nxp.com \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).