All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Howells <dhowells@redhat.com>, Udit Agarwal <udit.agarwal@nxp.com>
Cc: 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 18:57:41 +0000	[thread overview]
Message-ID: <1533236261.12916.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <8060.1533226481@warthog.procyon.org.uk>

On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> 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?

This is a symmetric key backed by a piece of hardware, which is exactly
what trusted keys are, so if we're defining common infrastructure with
callouts, trusted keys should be part of it.

Additionally, when I look at the trusted key code, I have significant
qualms about using the TPM RNG exclusively in the same way CAAM wants
to use its own RNG.  What I think both should be doing is collecting
data from their local RNGs, mixing it into the kernel entropy pool and
using a kernel generated random number (just in case these RNGs
suddenly turn out to be less random than they should be).

James



WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Howells <dhowells@redhat.com>, Udit Agarwal <udit.agarwal@nxp.com>
Cc: 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 11:57:41 -0700	[thread overview]
Message-ID: <1533236261.12916.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <8060.1533226481@warthog.procyon.org.uk>

On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> 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?

This is a symmetric key backed by a piece of hardware, which is exactly
what trusted keys are, so if we're defining common infrastructure with
callouts, trusted keys should be part of it.

Additionally, when I look at the trusted key code, I have significant
qualms about using the TPM RNG exclusively in the same way CAAM wants
to use its own RNG.  What I think both should be doing is collecting
data from their local RNGs, mixing it into the kernel entropy pool and
using a kernel generated random number (just in case these RNGs
suddenly turn out to be less random than they should be).

James



WARNING: multiple messages have this Message-ID (diff)
From: James.Bottomley@HansenPartnership.com (James Bottomley)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.
Date: Thu, 02 Aug 2018 11:57:41 -0700	[thread overview]
Message-ID: <1533236261.12916.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <8060.1533226481@warthog.procyon.org.uk>

On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:
> 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?

This is a symmetric key backed by a piece of hardware, which is exactly
what trusted keys are, so if we're defining common infrastructure with
callouts, trusted keys should be part of it.

Additionally, when I look at the trusted key code, I have significant
qualms about using the TPM RNG exclusively in the same way CAAM wants
to use its own RNG.  What I think both should be doing is collecting
data from their local RNGs, mixing it into the kernel entropy pool and
using a kernel generated random number (just in case these RNGs
suddenly turn out to be less random than they should be).

James


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Thread overview: 46+ 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:26 ` Udit Agarwal
2018-07-23 11:14 ` 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-07-23 11:26   ` Udit Agarwal
2018-07-23 11:14   ` Udit Agarwal
2018-08-02 16:14 ` [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM David Howells
2018-08-02 16:14   ` David Howells
2018-08-02 16:14   ` David Howells
2018-08-02 18:57   ` James Bottomley [this message]
2018-08-02 18:57     ` James Bottomley
2018-08-02 18:57     ` James Bottomley
2018-08-03 11:58   ` Mimi Zohar
2018-08-03 11:58     ` Mimi Zohar
2018-08-03 11:58     ` Mimi Zohar
2018-08-03 11:58     ` Mimi Zohar
2018-08-03 14:23     ` James Bottomley
2018-08-03 14:23       ` James Bottomley
2018-08-03 14:23       ` James Bottomley
2018-08-03 14:23       ` James Bottomley
2018-08-03 14:45       ` Mimi Zohar
2018-08-03 14:45         ` Mimi Zohar
2018-08-03 14:45         ` Mimi Zohar
2018-08-03 14:45         ` Mimi Zohar
2018-08-03 15:48         ` James Bottomley
2018-08-03 15:48           ` James Bottomley
2018-08-03 15:48           ` James Bottomley
2018-08-03 15:48           ` James Bottomley
2018-08-03 18:28           ` Mimi Zohar
2018-08-03 18:28             ` Mimi Zohar
2018-08-03 18:28             ` Mimi Zohar
2018-08-03 18:28             ` Mimi Zohar
2018-10-16 10:16             ` David Gstir
2018-10-16 10:16               ` David Gstir
2018-10-16 10:16               ` David Gstir
2018-08-03 14:55       ` David Howells
2018-08-03 14:55         ` David Howells
2018-08-03 14:55         ` David Howells
2018-08-03 15:23         ` Mimi Zohar
2018-08-03 15:23           ` Mimi Zohar
2018-08-03 15:23           ` Mimi Zohar
2018-08-03 15:23           ` Mimi Zohar
2020-01-17 11:52 ` Maik Otto
2020-01-17 11:52   ` Maik Otto
2020-01-23 12:55   ` Jarkko Sakkinen
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=1533236261.12916.5.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=aymen.sghaier@nxp.com \
    --cc=denkenz@gmail.com \
    --cc=dhowells@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.