linux-kernel - Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a57192d9d9a5a9a66d11b38d054a5a3a70466a4b.camel@linux.ibm.com>
Date:   Wed, 31 Mar 2021 11:49:47 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Richard Weinberger <richard@....at>
Cc:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        horia geanta <horia.geanta@....com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        aymen sghaier <aymen.sghaier@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        davem <davem@...emloft.net>, kernel <kernel@...gutronix.de>,
        David Howells <dhowells@...hat.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Steffen Trumtrar <s.trumtrar@...gutronix.de>,
        Udit Agarwal <udit.agarwal@....com>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        david <david@...ma-star.at>,
        Franck Lenormand <franck.lenormand@....com>,
        Sumit Garg <sumit.garg@...aro.org>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        "open list, ASYMMETRIC KEYS" <keyrings@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        LSM <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP
 CAAM-based trusted keys

On Wed, 2021-03-31 at 20:36 +0200, Richard Weinberger wrote:
> James,
> 
> ----- Ursprüngliche Mail -----
> > Von: "James Bottomley" <jejb@...ux.ibm.com>
> > > On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum <
> > > a.fatoum@...gutronix.de wrote:
> > > >     keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
> > > 
> > > Is there a reason why we can't pass the desired backend name in
> > > the
> > > trusted key parameters?
> > > e.g.
> > > keyctl add trusted $KEYNAME "backendtype caam load $(cat
> > > ~/kmk.blob)"
> > > @s
> > 
> > Why would you want to in the load?  The blob should be type
> > specific, so a TPM key shouldn't load as a CAAM key and vice versa
> > ... and if they're not they need to be made so before the patches
> > go upstream.
> 
> I fear right now there is no good way to detect whether a blob is
> desired for CAAM or TPM.

At least for the TPM the old format is two TPM2B structures, and the
new one is ASN.1 so either should be completely distinguishable over
what CAAM does.

> > I could possibly see that you might want to be type specific in the
> > create, but once you're simply loading an already created key, the
> > trusted key subsystem should be able to figure what to do on its
> > own.
> 
> So you have some kind of container format in mind which denotes the
> type of the blob?

Well, yes.  For the TPM, there's a defined ASN.1 format for the keys:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h

and part of the design of the file is that it's distinguishable either
in DER or PEM (by the guards) format so any crypto application can know
it's dealing with a TPM key simply by inspecting the file.  I think you
need the same thing for CAAM and any other format.

We're encouraging new ASN.1 formats to be of the form

SEQUENCE {
    type   OBJECT IDENTIFIER
    ... key specific fields ...
}

Where you choose a defined OID to represent the key and that means
every key even in DER form begins with a unique binary signature.

James