LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	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: Fri, 03 Aug 2018 14:28:41 -0400
Message-ID: <1533320921.4337.479.camel@linux.ibm.com> (raw)
In-Reply-To: <1533311338.4140.3.camel@HansenPartnership.com>

On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote:
> On Fri, 2018-08-03 at 10:45 -0400, Mimi Zohar wrote:
> > On Fri, 2018-08-03 at 07:23 -0700, James Bottomley wrote:
> > > On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote:
> > > > 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?
> > > > 
> > > > TPM 1.2 didn't support symmetric keys.  For this reason, the TPM
> > > > "unseals" the random number, used as a symmetric key, and returns
> > > > the
> > > > "unsealed" data to the kernel.
> > > > 
> > > > Does anyone know if CAAM or TPM 2.0 have support for symmetric
> > > > keys?
> > > 
> > > It depends what you mean by "support".  The answer is technically
> > > yes,
> > > it's the TPM2_EncryptDecrypt primitive.  However, the practical
> > > answer
> > > is that symmetric keys are mostly used for bulk operations and the
> > > TPM
> > > and its bus are way too slow to support that, so the only real,
> > > practical use case is to have the TPM govern the release conditions
> > > for
> > > symmetric keys which are later used by a fast bulk
> > > encryptor/decryptor
> > > based in software.
> > > 
> > > >  If they have symmetric key support, there would be no need for
> > > > the
> > > > symmetric key ever to leave the device in the clear.  The device
> > > > would unseal/decrypt data, such as an encrypted key.
> > > > 
> > > > The "symmetric" key type would be a generic interface for
> > > > different
> > > > devices.
> > > 
> > > It's possible, but it would only work for a non-bulk use case; do
> > > we
> > > have one of those?
> > 
> > "trusted" keys are currently being used to decrypt other keys (eg.
> > encrypted, ecryptfs, ...).
> 
> Yes, but that's just double encryption: it serves no real security
> purpose because at the end of the chain, the symmetric key is released
> into kernel memory to use in software crypto.  Unless you're using a
> high speed (and high cost) crypto accelerator with HSA, this will
> always be the case for bulk crypto.
> 
> The other slight problem with this chain of crypto is that I can impose
> conditions on the key release from the TPM (well TPM2, since TPM1.2 has
> a very weak policy engine) but if we use intermediate steps, those
> conditions might not be preserved, so I think the ideal would be a
> trusted key being released directly to LUKS or ecryptfs because the TPM
> can then verify the policy at actual unseal time.  I get that for the
> ecryptfs case you might want one key per file for sharding and sharing,
> and that's more like a bulk case because the TPM isn't going to keep up
> with the number of unseal operations required.

Agreed.  Yet there are a couple of reasons for having this sort of
indirection. By having the "encrypted" key encrypted/decrypted by a
"trusted" key, the "trusted" key could be updated without impacting
the "encrypted" key.  This could be used, for example, for key
migration.  Another reason would be to define a single "trusted" key
sealed to a set of PCRs, which could be used to encrypt/decrypt
multiple symmetric keys.

Nothing is preventing these subsystems from directly using a "trusted"
key.

This discussion is the result of Udit Agarwal's posting a "secure" key
patch. Before defining a new key type, whether it is called "secure"
or "symmetric", we need to understand how the this new key type is
going to be used.  Will it have a similar ability to impose conditions
on the key release as the TPM?  Will it have symmetric key support, so
that the symmetric key never needs to be released from the HW?

Mimi


  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-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 18:57   ` 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 [this message]
2018-10-16 10:16             ` David Gstir
2018-08-03 14:55       ` David Howells
2018-08-03 15:23         ` Mimi Zohar

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=1533320921.4337.479.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git