From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Six Date: Wed, 22 Mar 2017 15:07:04 +0100 Subject: [U-Boot] [PATCH 1/3] tpm: Add function to load keys via their parent's SHA1 hash In-Reply-To: References: <20170320092830.3040-1-mario.six@gdsys.cc> <20170320092830.3040-2-mario.six@gdsys.cc> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Mar 22, 2017 at 2:27 PM, Simon Glass wrote: > Hi Mario, > > On 22 March 2017 at 07:20, Mario Six wrote: >> On Wed, Mar 22, 2017 at 2:05 PM, Simon Glass wrote: >>> On 20 March 2017 at 03:28, Mario Six wrote: >>>> If we want to load a key into a TPM, we need to know the designated parent >>>> key's handle, so that the TPM is able to insert the key at the correct place in >>>> the key hierarchy. >>>> >>>> However, if we want to load a key whose designated parent key we also >>>> previously loaded ourselves, we first need to memorize this parent key's handle >>>> (since the handles for the key are chosen at random when they are inserted into >>>> the TPM). If we are, however, unable to do so, for example if the parent key is >>>> loaded into the TPM during production, and its child key during the actual >>>> boot, we must find a different mechanism to identify the parent key. >>>> >>>> To solve this problem, we add a function that allows U-Boot to load a key into >>>> the TPM using their designated parent key's SHA1 hash, and the corresponding >>>> auth data. >>>> >>>> Signed-off-by: Mario Six >>>> --- >>>> cmd/tpm.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ >>>> drivers/tpm/Kconfig | 8 ++++++++ >>>> include/tpm.h | 12 ++++++++++++ >>>> lib/tpm.c | 40 ++++++++++++++++++++++++++++++++++++++++ >>>> 4 files changed, 109 insertions(+) >>> >>> Reviewed-by: Simon Glass >>> >>> Perhaps you don't need a new Kconfig option? Is that to save code space? >>> >>> >> >> Yes, it's primarily to save code space. I haven't really investigated how much >> this option does impact the overall size, but since every recent addition to >> the TPM library was guarded with a new Kconfig option, I thought it was prudent >> to emulate that. >> >> If you think it's overkill, I can drop the option, and just have it >> compiled in by default. > > I think for now it is overkill, and I'm happy to just include the new > functionality always. We have a sandbox tpm emulator - can we use that > to write tests? > > Regards, > Simon > OK, no Kconfig option is good as well. :-) As for tests, I took a quick look at tpm_tis_sandbox.c: Right now, the driver doesn't support the TPM_LoadKey2 command, which is used to implement the loading mechanism. And it's decidedly non-trivial to implement it, primarily for the reason that U-Boot, at the moment, doesn't provide all the needed cryptographic primitives (the key blob that is loaded in is cryptographically secured). I know that RSA is implemented, but we would require OAEP padding, which is not implemented, and we would also need AES-128 in CBC mode. This could be overcome if we could somehow gain access to the host system's OpenSSL library from within the sandbox driver. Would that be possible? Then again, it would be pretty nice if we had working OAEP padding available for FIT image signing, so it might be worth implementing it. So, bottom line: I'll look into it, but it will definitely take a while to have something usable at hand. Best regards, Mario