On Fri, 2018-08-03 at 10:45 -0400, Mimi Zohar wrote:

On Fri, 2018-08-03 at 07:23 -0700, James Bottomley wrote:

quoted

On Fri, 2018-08-03 at 07:58 -0400, Mimi Zohar wrote:

quoted

On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:

quoted

Udit Agarwal [off-list ref] wrote:

quoted

+==========
+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.

quoted

 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.

James