linux-kernel - Re: One question about trusted key of keyring in Linux kernel.

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: <1575312932.24227.13.camel@linux.ibm.com>
Date:   Mon, 02 Dec 2019 10:55:32 -0800
From:   James Bottomley <jejb@...ux.ibm.com>
To:     "Zhao, Shirley" <shirley.zhao@...el.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>
Cc:     "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "'Mauro Carvalho Chehab'" <mchehab+samsung@...nel.org>,
        "Zhu, Bing" <bing.zhu@...el.com>,
        "Chen, Luhai" <luhai.chen@...el.com>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Mon, 2019-12-02 at 06:50 +0000, Zhao, Shirley wrote:
> So I guess mostly like, it is the format of policydigest,
> policyhandle is not correctly in my keyctl command. 
> But what is the correct using?
> 
> My keyctl commands are attached as below: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob

OK, looking at the actual code, it seems that whoever wrote it didn't
account for the differences between TPM1.2 and TPM2.0.  With TPM2.0
TPM2_Create returns the public and private parts plus three other tpm2b
entites used to certify and check the key.  When you load the blob back
using TPM2_Load, it only accepts the public and private parts. 
However, your blob contains the other extraneous elements, that's why
it can't be loaded.  You could make it loadable by stripping off the
extraneous pieces ... just take the first two tpm2b elements of the
blob but it looks like we need to fix the API.  I suppose the good news
is given this failure that we have the opportunity to rewrite the API
since no-one else can have used it for anything because of this.  The
fundamental problem with the current API is that most TPM2's only have
three available session registers.  It's simply not scalable to set
them up in userspace and have the kernel use them, so what we should be
doing is passing down the actual policy and having the kernel construct
the session at the point of use and then flush it, thus solving the
potential session exhaustion issue.

I'd actually propose we make a TSSLOADABLE the fundamental element of
operation for trusted keys.  The IBM and Intel TSS people have agreed
to do this as the format for TPM loadable keys, but it should also
apply to sealed data.  The beauty of TSSLOADABLE is that the ASN.1
format includes a policy specification:

/*
 * TSSLOADABLE ::= SEQUENCE {
 *	type		OBJECT IDENTIFIER
 *	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
 *	policy		[1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
 *	secret		[2] EXPLICIT OCTET STRING OPTIONAL
 *	parent		INTEGER
 *	pubkey		OCTET STRING
 *	privkey		OCTET STRING
 * }
 * TPMPolicy ::= SEQUENCE {
 *	CommandCode		[0] EXPLICIT INTEGER
 *	CommandPolicy		[1] EXPLICIT OCTET STRING
 * }
 */

James