From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sun, 26 Mar 2017 20:27:20 -0600 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 22 March 2017 at 08:47, Simon Glass wrote: > Hi Mario, > > On 22 March 2017 at 08:07, Mario Six wrote: >> 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. > > Yes you can access OpenSSL - see for example os.c which is built by > the host tools and provides an interface between U-Boot and the C > libraries. > > Also bear in mind that one option is to implement a 'fake', where it > appears to do the right thing, but in fact fakes most of its actions, > so that (for example) it doesn't provide any security checks. I'm not > suggesting that, but just pointing out that the primary purpose of > test code in U-Boot is to test U-Boot., so we don't need such faithful > implementations. > >> >> So, bottom line: I'll look into it, but it will definitely take a while to have >> something usable at hand. >> OK, keep it simple! Applied to u-boot-dm, thanks!